Re: relays.ordb.org blacklisting all IPs (fwd)

On Apr 2, 1:58=A0am, Grant Taylor wrote:
> On 4/1/2008 11:30 PM, Res wrote:
>
> > This is exactly the point, the entire domain is moot, removing the
> > name servers from zone, setting thme to 127.0.0.1, dropping the zone
> > sicne they dont want it, it has no use these days. It has no A
> > records, www has no A records, it has no MX record, but yet they
> > still have records to block everyone querrying *.relays.ordb.org
> > petty absolutely fucking petty.
>
> For the sake of the on going discussion please clarify what you want
> ORDB to do and where you would like them to do it.
>
> Are you wanting ORDB to:
> =A0 - Remove NS records for therelays.ordb.orgsub-domain from the
> ordb.org zone?
> =A0 - Set the A record referenced in the glue records for therelays.ordb.o=
rgsub-domain to 127.0.0.1?
> =A0 - Remove all references to therelays.ordb.orgsub-domain?
> =A0 - Remove all ORDB zones?
> =A0 - Set glue records with Tucows to 127.0.0.1?
> =A0 - Remove the glue records with Tucows if possible?
>
> > since your in the business of calling others, I'll call you, show me
> > the evidence they ar ehit with 50G a month
>
> Fair enough. =A0I will first say that I do not have any ""evidence per say=

> (logs, reports, etc from ORDB), but I can run (what I believe to be)
> extremely conservative numbers to come up with the amount of traffic
> that their DNS servers would see.
>
> Please reference my 2nd & 3rd message in the Google archivehttp://groups.g=
oogle.com/group/comp.mail.sendmail/browse_thread/threa...
>
> =A0From my second message you can see how I derived the size of queries
> and replies. =A0Below are the formulas that I used to run the numbers.
>
> I found that there were (approximately) 246 country codes. =A0I'm going to=

> presume that ORDB is receiving at least one query per second per country
> code. =A0I feel confident that this is a very safe number to use.
>
> Per my other posts, I found that a query is 85 bytes and a reply is 202
> bytes, making a query and reply 287 bytes.
>
> If we take the 85 (bytes per query) * 246 (country codes) is 20910 bytes
> per second or 20.9 kB per second of DNS query traffic.
>
> If we take the 85 (bytes per query) * 246 (country codes) * 60 (second
> per minute) * 60 (minutes per hour) * 24 (hours per day) is 1806624000
> bytes per day or 1806624 kB per day or 1806.6 MB per day or 1.8 GB per
> day of DNS query traffic.
>
> If we take the 85 (bytes per query) * 246 (country codes) * 60 (second
> per minute) * 60 (minutes per hour) * 24 (hours per day) * 30 (days per
> month) is 54198720000 bytes per month or 54198720 kB per month or
> 54198.7 MB per month or 54.1 GB per month of DNS query traffic.
>
> If we use the same equations with the size of the reply and the size of
> the query and reply combined we get the following numbers:
>
> DNS reply traffic
> 202 * 246 =3D 49692 B or 49.69 kB per second
> 202 * 246 * 60 * 60 * 24 =3D 4293388800 B or 4293388.8 kB or 4293.3 MB or
> 4.2 GB per day
> 202 * 246 * 60 * 60 * 24 * 30 =3D 128801664000 B or 128801664 kB or
> 128801.6 MB or 128.8 GB per month
>
> Combined DNS query and reply traffic
> 287 * 246 =3D 70602 B or 70.6 kB per second
> 287 * 246 * 60 * 60 * 24 =3D 6100012800 B or 6100012.8 kB or 6100 MB or
> 6.1 GB per day
> 287 * 246 * 60 * 60 * 24 * 30 =3D 183000384000 B or 183000384 kB or
> 183000.3 MB or 183 GB per month
>
> I think it is fairly obvious that this is a LOT of traffic that has to
> be absorbed by someone's DNS servers. =A0What is worse is that this amount=

> of traffic is very unlikely to taper off very fast at all if nothing is
> done to encourage people to stop querying the servers. =A0Hence why I
> believe ORDB decided to switch to collateral damage after being closed
> for 14+ months all the wile handling 183 GB (or more) traffic for a
> defunct service.
>
> With these numbers in mind, let's see how what I believe you are wanting
> ORDB to do stacks up.
>
> =A0 - Remove NS records for therelays.ordb.orgsub-domain from the
> ordb.org zone?
>
> =A0 =A0 Systems will still be querying the ordb.org zone for the sub-domai=
n,
> thus the traffic numbers still apply. =A0Adjust the size of queries and
> replies for the sizes of packets if need be. =A0However this number will
> still be very large.
>
> =A0 - Set the A record referenced in the glue records for therelays.ordb.o=
rgsub-domain to 127.0.0.1?
>
> =A0 =A0 (same as above)
>
> =A0 - Remove all references to therelays.ordb.orgsub-domain?
>
> =A0 =A0 (same as above)
>
> =A0 - Remove all ORDB zones?
>
> =A0 =A0 Systems will still query the ORDB zone name servers looking for
> records. =A0Still very similar to above.
>
> =A0 - Set glue records with Tucows to 127.0.0.1?
>
> =A0 =A0 Root name servers will still receive traffic looking for the name
> servers for the ORDB zone.
>
> =A0 - Remove the glue records with Tucows if possible?
>
> =A0 =A0 Root name servers will still be queried.
>
> What is worse with doing the above is that most of the systems that are
> still querying ORDB after being closed for 14+ months will continue to
> do so for quite a while to come. =A0What incentive do all the companies
> like aoberlin is referring to have to bring someone in to correct the
> problem if at worst they have a DNS timeout per message passing through
> their system? =A0How long do you think it will be before someone does
> remove ORDB from the config? =A0I'm betting that ORDB will stay in the
> config until the system is replaced with something new, so most likely
> sometime with in the next 5 years (give or take). =A0What if someone
> copies the old config to the next system? =A0How many new systems down the=

> road will be able to use the old config file or .mc file? =A0Let's say 3
> generations with a 5 year life cycle. =A0Now we are up to 11 years if we
> say the replacement cycle is every 3 years and we take off the 14 months
> that have passed. =A0All this time will add up to a *LOT* of wasted
> bandwidth and $$$ because people do not update their config.
>
> This is why I think it perfectly reasonable for ORDB to result to some
> action that will ensure that people will want to update their config.
> ORDB has been defunct for 14+ months. =A0Any one that was going to update
> their config on their own accord has done so already. =A0I'm willing to
> bet that a very large majority of systems that were querying ORDB a week
> ago are no longer querying ORDB. =A0Let's just say that the number is cut
> bu 10%. =A0Here is a simple list of the number of queries per second for
> each week for the next 6 months:
>
> Week =A0 =A0Query / Sec
> 1 =A0 =A0 =A0 246
> 2 =A0 =A0 =A0 221.4
> 3 =A0 =A0 =A0 199.2
> 4 =A0 =A0 =A0 179.2
> 5 =A0 =A0 =A0 161.2
> 6 =A0 =A0 =A0 145
> 7 =A0 =A0 =A0 130.5
> 8 =A0 =A0 =A0 117.4
> 9 =A0 =A0 =A0 105.6
> 10 =A0 =A0 =A095
> 11 =A0 =A0 =A085.5
> 12 =A0 =A0 =A076.9
> 13 =A0 =A0 =A069.2
> 14 =A0 =A0 =A062.2
> 15 =A0 =A0 =A055.9
> 16 =A0 =A0 =A050.3
> 17 =A0 =A0 =A045.2
> 18 =A0 =A0 =A040.6
> 19 =A0 =A0 =A036.5
> 20 =A0 =A0 =A032.8
> 21 =A0 =A0 =A029.5
> 22 =A0 =A0 =A026.5
> 23 =A0 =A0 =A023.8
> 24 =A0 =A0 =A021.4
>
> If I run the numbers out with a 10% drop per week, all queries should be
> stopped by the 60 weeks. =A0For the curious, if the number of queries per
> week is cut in half, with in 13 weeks all queries should be stopped.
> Cut in to a quarter and you are down to 7 weeks.
>
> Compare the operational costs of doing this verses answering queries for
> the coming years.
>
> Grant. . . .

Impressive.