<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [ga] Disinformation about DNS attacks
- To: George Kirikos <gkirikos@xxxxxxxxx>
- Subject: Re: [ga] Disinformation about DNS attacks
- From: Jeff Williams <jwkckid1@xxxxxxxxxxxxx>
- Date: Fri, 09 Mar 2007 01:12:37 -0800
- Cc: ga@xxxxxxxxxxxxxx, Paul Vixie <paul@xxxxxxx>, Joe Baptista <baptista@xxxxxxxxxxx>, Joe Baptista - New <baptista@xxxxxxxxxxx>, "vinton g. cerf" <vint@xxxxxxxxxx>, Kathy Smith <KSMITH@xxxxxxxxxxxx>, icann board address <icann-board@xxxxxxxxx>, icann staff <icann-staff@xxxxxxxxx>, Dan Swanson <dswanson_2005@xxxxxxxxx>
- Organization: INEGroup Spokesman
- References: <20070308212754.79748.qmail@web50011.mail.re2.yahoo.com>
- Sender: owner-ga@xxxxxxxxxxxxxx
George and all,
All very good information here George and most of which
Joe Baptista and I along with a few others like Paul Vixie
have been over several times before on this forum when
similar Disinformation about DNS, DNS attacks, and
other DNS related technical discussions circling around
Bind, ect. of a few years ago now had discussed...
Remember also, ICANN seemingly cannot survive without
caviar, helicopter transport, exotic fact finding "Junkets",
five star hotel rooms, ect., ect.... >;) I mean really now,
you really don't want these folks to actually WORK for a
living now do you? Heaven and DOC/NTIA forbid...
Such a notion would be paramount to sacrilege now
wouldn't it?
George Kirikos wrote:
> Hello,
>
> ICANN has posted a *cough* "factsheet" *cough* on the recent DNS
> attacks, see:
>
> http://blog.icann.org/?p=37
> http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf
>
> The timing of the report is perfect, as I just posted:
>
> http://gnso.icann.org/mailing-lists/archives/ga/msg06114.html
>
> Everytime I see these reports of "attacks", my wallet starts to tingle,
> as the scaremongering seems to always result in later demands for "more
> money".
>
> I'll take issue with 1 specific example of disinformation. On page 2,
> it says "In theory, if even one of the 13 root servers is up and
> running, then the Internet will continue to run unhindered as the
> directory will still be visible to the network."
>
> This is very misleading. Indeed, due to caching, the internet can
> function with only minor hiccups if ZERO root servers are up and
> running. The root zone file is very tiny. You can see a copy of it at:
>
> http://www.internic.net/zones/root.zone
>
> How long did that file take to load? Not long, since it is only 68
> KBytes in size! And, if you ignore all the minor banana republic
> countries and TLDs, there really is much less "important" information
> in that 68 KByte file (i.e. due to Zipf's law, see:
>
> http://nms.lcs.mit.edu/papers/dns-ton2002.pdf
> http://www.cs.cornell.edu/people/egs/papers/codons-prenanog.pdf
> http://en.wikipedia.org/wiki/Zipf's_law
>
> i.e. for most people, .com, .net, .org, .gov, and a few major ccTLDs
> matter most).
>
> What's really important is what happens when the "cache" is stale (i.e.
> the time-to-live (TTL) of the data has expired). Using a telephone book
> analogy, the "TTL" is related to "how often you should check to make
> sure that a phone number has changed." DNS itself can be considered
> like a hierarchical directory of phonebooks, i.e. the root is the
> directory of addresses of where to find the white pages for each
> country (or city), all the way down to the local city phonebook which
> is typically published once per year.
>
> Of course, with DNS, the "TTL" is typically a lot less than the 1 year
> of physical phonebooks. However, this notion that the internet "breaks"
> if zero root servers are available is like saying that the telephone
> system will break if you don't get a copy of this year's phonebook.
>
> An expired cache is similar to using the 2006 phonebook, instead of the
> current 2007. If you look up my phone number in 2006's phonebook, or
> even 2005's whitepages, you'll be fine, as the number is the same as it
> for me in 2007. For a few people, though, the number will be incorrect.
> In a DNS context, thus, having expired cache data need not be greatly
> costly. For example, the IP address for ICANN's website has been the
> same for the past 2 years:
>
> http://whois.domaintools.com/icann.org
>
> IP History: 1 change. Using 1 unique IP address in 2 years.
>
> I suspect you'll find ICANN's website at 192.0.34.163 tomorrow, and the
> day after that too...these things don't change very often.
>
> For its nameservers: NS History: 6 changes. Using 3 unique name servers
> in 6 years.
>
> Our pals at VeriSign:
>
> http://whois.domaintools.com/verisign.com
>
> IP History: 1 change. Using 1 unique IP address in 2 years
> NS History: 2 changes. Using 2 unique name servers in 5 years.
>
> So, what *really* matters is how often the data in the root zone file
> changes. That will determine how much damage occurs if a stale cache is
> used (i.e. like the damage that would occur if you used 2006's
> phonebook instead of 2007's). I suspect most TLD operators are not
> constantly renumbering their networks, so the root zone file should be
> changing very slowly over time, and ICANN should provide data to prove
> otherwise. Indeed, if the root zone was static, and non changing, we'd
> have no need for root zone servers at all. Since memory and hard disks
> are cheap these days, caching is *very* cheap (68 KB is trivial),
> indeed one can have a basically infinite cache (or multi-Gigabytes at
> the very least).
>
> The 2nd prong is distribution of the root zone file. Back in the early
> days of the internet, there was no BitTorrent. There was no RSS. There
> is no reason that the 68 KB file at the heart of the internet could not
> be distributed to the biggest ISPs using alternative measures. e.g. do
> you really think that AOL couldn't get a copy of the 68 KB root zone
> file (to serve its 20 million users) through some "push" mechanism like
> RSS or even email, or "pull" methods like FTP or BitTorrent? Heck, you
> can even have a dialup modem distribute the 68 KB file to AOL just like
> the Fidonet BBS days of the 1980's. The same goes for other big ISPs.
> The reliability of those torrent networks in serving up movies and
> music show that they're highly scalable and resilient to attacks (if
> they were easily attacked, I assume the MPAA and RIAA would have taken
> them down by now). How difficult would it be to serve up 68 KB files
> (signed appropriately, to ensure authenticity) to thousands, if not
> millions of users? Too trivial to ponder, if there's a will to do so.
> What percentage of the internet worldwide users would be represented by
> the top 1000 ISPs? I suspect more than half, and if not, it wouldn't be
> hard to scale this to the top 10,000 or 100,000. How many millions of
> people receive multi-megabyte Windows or Mac operating system security
> updates daily, without incident?
>
> Instead of fear-mongering and trying to justify its exploding $30+
> million annual budget:
>
> http://gnso.icann.org/mailing-lists/archives/ga/msg06091.html
>
> with pretty graphs, ICANN should talk about real solutions. Real
> solutions don't put caviar on the table for lazy bureaucrats, but they
> definitely benefit the public through lower costs and greater
> reliability.
>
> Sincerely,
>
> George Kirikos
> http://www.kirikos.com/
Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln
"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt
"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng. INEG. INC.
ABA member in good standing member ID 01257402
E-Mail jwkckid1@xxxxxxxxxxxxx
Registered Email addr with the USPS
Contact Number: 214-244-4827
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|