how to protect name servers against cache corruption
a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do, see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/. (the root name servers are all running modern software at this point.) alternic's corruption works by locating authoritative name servers via the "NS RR"'s published in various zones. if you run these as authoritative- only (recursion disabled) then they will never fetch any data from anywhere. (the root name servers are configured this way, for example.) the downside is that you can't list such nameservers in your "resolv.conf" files or PC equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.) this means you need more name servers if you separate recursive from non- recursive.
Isolating recursive from non-recursive servers has a ton of benefits: 1. measuring your external from internal queries becomes easier, hence budgeting for the appropriate servers has a cost matching ability 2. to use distributed director from cisco, you need non-recursive authoritative servers 3. your authoritative servers become less susceptible to corruption from a looped delegation, hence isolating your DNS problems to the recursive resolvers instead of taking down all your authoritative abilities etc. etc. Rob
a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do, see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/. (the root name servers are all running modern software at this point.)
alternic's corruption works by locating authoritative name servers via the "NS RR"'s published in various zones. if you run these as authoritative- only (recursion disabled) then they will never fetch any data from anywhere. (the root name servers are configured this way, for example.) the downside is that you can't list such nameservers in your "resolv.conf" files or PC equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.) this means you need more name servers if you separate recursive from non- recursive.
a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do, see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/. (the root name servers are all running modern software at this point.)
... but not all run BIND 4.9.6 or 8.1.1: $ for i in a b c d e f g h i j k l m; do
echo $i.root-servers.net host -t txt -c chaos version.bind $i.root-servers.net done a.root-servers.net VERSION.BIND TXT "named 4.9.5-P1 Tue Apr 22 16:46:54 EDT 1997\ root@premier1:/usr/local/src/bind/bind-4.9.5-P1-MAK/named" b.root-servers.net VERSION.BIND TXT "8.1.1" c.root-servers.net VERSION.BIND TXT "named 4.9.5-REL Wed Feb 19 16:23:19 EST 1997\ arthur@sol25.sa.psi.com:/opt/dist/sol25/Generic/src/bind-4.9.5p1/bind-ns /named" d.root-servers.net VERSION.BIND TXT "4.9.6-REL+terp_mods" e.root-servers.net VERSION.BIND TXT "8.1.1" f.root-servers.net VERSION.BIND TXT "8.1.1" g.root-servers.net VERSION.BIND TXT "8.1.1" h.root-servers.net version.bind TXT record in class CH not found, server failure i.root-servers.net VERSION.BIND TXT "8.1.1" j.root-servers.net VERSION.BIND TXT "8.1.1" k.root-servers.net VERSION.BIND TXT "8.1.1" l.root-servers.net VERSION.BIND TXT "8.1.1" m.root-servers.net VERSION.BIND TXT "8.1.1"
Juergen Georgi BelWue Network Operations Center RUS University of Stuttgart, Allmandring 30A, 70550 Stuttgart, Germany E-Mail: georgi@belwue.de, Phone: +49 711 685 5739, Fax: +49 711 682357
if you run these as authoritative- only (recursion disabled) then they will never fetch any data from anywhere. (the root name servers are configured this way, for example.) the downside is that you can't list such nameservers in your "resolv.conf" files or PC equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.) this means you need more name servers if you separate recursive from non- recursive.
Correct me if I'm wrong, but this implies that nameservers whose sole purpose is to act as primary and secondary for customer domains can run with recursion disabled. I.e. all those nameservers whose identity is readily discernable from public databases such as the Internic, RIPE, etc., could run in this configuration as long as they are not also intended to do lookups for local machines on your local network. ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
Correct me if I'm wrong, but this implies that nameservers whose sole purpose is to act as primary and secondary for customer domains can run with recursion disabled. I.e. all those nameservers whose identity is readily discernable from public databases such as the Internic, RIPE, etc., could run in this configuration as long as they are not also intended to do lookups for local machines on your local network.
That's the way we run ours (non-recursive) It keeps performance up too while keeping tabs on memory usage. In fact, we secondary commonly accessed domains directly from their authoritative nameservers and keep regular tabs on them to ensure our pointers are correct. -Deepak. AINet
Since I believe that the security aspects of DNS are relevant to network operations, I'm explicitly choosing to answer some messages here today even though Paul Ferguson has issued a very reasonable request that DNS *politics* not be discussed.
Correct me if I'm wrong, but this implies that nameservers whose sole purpose is to act as primary and secondary for customer domains can run with recursion disabled. I.e. all those nameservers whose identity is readily discernable from public databases such as the Internic, RIPE, etc., could run in this configuration as long as they are not also intended to do lookups for local machines on your local network.
Yes, that's what it is and that's why it works. I couldn't've said it better.
On Tue, Jul 22, 1997 at 01:24:59PM -0700, Paul A Vixie wrote:
a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do, see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/. (the root name servers are all running modern software at this point.)
alternic's corruption works by locating authoritative name servers via the "NS RR"'s published in various zones. if you run these as authoritative- only (recursion disabled) then they will never fetch any data from anywhere. (the root name servers are configured this way, for example.) the downside is that you can't list such nameservers in your "resolv.conf" files or PC equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.) this means you need more name servers if you separate recursive from non- recursive.
Well, Alternic's persona-non-grata (Eugene) is about to find himself in a LOT of hot water for what he's done. I have been told by a media figure who called me that the civil charges, including a petition to seize *all* of his hardware, are being read tomorrow. I expect that there may be criminal issues involved here as well. Playing "hahaha, www.biteme.eugene resolves now" is a childish prank of no significance. Hijacking someone else's web site using the same trick, however, is an entirely different thing and is no laughing matter. I'm with Paul on this one (see, Paul, we can agree on something once in a while :-) -- update your code to either 4.9.6 or (preferrably) 8.1.1 -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
In article <199707222024.NAA14009@wisdom.rc.vix.com>, you wrote:
a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do, see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/. (the root name servers are all running modern software at this point.)
Immune to which attack? The poisoned resource-record attack? The ID guessing attack? How have you confirmed that 8.1.1 is not vulnerable to related attacks? Since, as you say, this has an "operations" context (the integrity of the Internet domain service in realistic danger), it might be appropriate and appreciated for you to detail the steps you and the ISC have taken to resolve these problems in BIND 8.1.1. Does 8.1.1 validate resource records? Does it use random query IDs? My understanding of Kashpureff's attack was that it was of minimal complexity (specifically, that he ripped off some kid's cname-bouncing script). I am therefore concerned at what appears to be the use of his apparently unsophisticated attack as a metric for the security of BIND 8.1.1. Thanks for reading this, and for your time! -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));
Since, as you say, this has an "operations" context (the integrity of the Internet domain service in realistic danger), it might be appropriate and appreciated for you to detail the steps you and the ISC have taken to resolve these problems in BIND 8.1.1.
I'm happy to help, sure.
Does 8.1.1 validate resource records?
To the extent possible without DNSSEC, yes.
Does it use random query IDs?
In a noncryptorandom way, yes. (With 16 bits it almost doesn't matter.)
My understanding of Kashpureff's attack was that it was of minimal complexity (specifically, that he ripped off some kid's cname-bouncing script). I am therefore concerned at what appears to be the use of his apparently unsophisticated attack as a metric for the security of BIND 8.1.1.
I wrote <URL:ftp://ftp.vix.com/pri/vixie/bindsec.psf> in September of 1995 and presented it at the 5th Usenix Security Symposium in Salt Lake City. Noone in the security field has any right to expect any implementation of DNS to be secure until DNSSEC is widely implemented. I'm sorry if something I said misled you to believe otherwise.
Noone in the security field has any right to expect any implementation of DNS to be secure until DNSSEC is widely implemented.
I'm sorry if something I said misled you to believe otherwise.
So BIND 8.1.1 is NOT "immune" to the poisoned resource-record attack? I ask because you specifically stated that it was. Sorry to nag, I'd just like to see this clarified to the operations community. Again, thanks for your time and patience! ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
Noone in the security field has any right to expect any implementation of DNS to be secure until DNSSEC is widely implemented.
I'm sorry if something I said misled you to believe otherwise.
So BIND 8.1.1 is NOT "immune" to the poisoned resource-record attack? I ask because you specifically stated that it was. Sorry to nag, I'd just like to see this clarified to the operations community.
BIND 4.9.6 and 8.1.1 are immune to all known attacks, including the one Eugene Kashpureff copied and put into wide public use recently. I know of attacks we are not immune to, which cannot be stopped without DNSSEC. My paper, whose URL I gave in the previous message, alludes to some of these without exactly giving a road map for their use.
BIND 4.9.6 and 8.1.1 are immune to all known attacks, including the one
[ splice ]
I know of attacks we are not immune to, which cannot be stopped without
Um. I hate to play semantic games, but if you know of attacks that BIND 8.1.1 is not immune to, then BIND 8.1.1 is not immune to all known attacks. Since this is not a security list, I'll refrain from (rhetorically) informing you that history doesn't back up your assertion of the existence of "holes that only the good guys know". Oops. Sorry about that. Thanks for clearing this up! ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
Let me put this another more interesting and more direct way. Postulate a name server with the following properties: 1. Actually works on and is connected to the live Internet. 2. RFC compliant except as nec'y to comply with #1 above. 3. No DNSSEC, no TSIG, no SECUPD. 4. Completely bug free. You go right ahead and build that name server, and I will drive a truck, no, better still a bus or even a backhoe, right through its front window. DNS is not secure and cannot be made so. BIND-8.1.1 is the best there is, and it's what you should run, but as long as you run DNS without DNSSEC, your confidence level should be set accordingly. PS: BIND is definitely #1, is almost #2, is definitely #3, and trying to be #4.
i say again that although it cannot be made completely secure in the DNSSEC sense, it can absolutely be made far more resistant to some *known* attacks without significant code changes. ben On Tue, 29 Jul 1997, Paul A Vixie wrote:
Let me put this another more interesting and more direct way.
Postulate a name server with the following properties:
1. Actually works on and is connected to the live Internet. 2. RFC compliant except as nec'y to comply with #1 above. 3. No DNSSEC, no TSIG, no SECUPD. 4. Completely bug free.
You go right ahead and build that name server, and I will drive a truck, no, better still a bus or even a backhoe, right through its front window.
DNS is not secure and cannot be made so. BIND-8.1.1 is the best there is, and it's what you should run, but as long as you run DNS without DNSSEC, your confidence level should be set accordingly.
PS:
BIND is definitely #1, is almost #2, is definitely #3, and trying to be #4.
Paul has made it clear that there are holes in the DNS protocols that cannot be fixed without DNSSEC. He isn't papering anything over -- he is merely describing reality. If you want to be sarcastic to him for doing his best and being honest in public, well, that's fine, but frankly I think you are doing the community a serious disservice by attacking Paul. .pm "Thomas H. Ptacek" writes:
BIND 4.9.6 and 8.1.1 are immune to all known attacks, including the one
[ splice ]
I know of attacks we are not immune to, which cannot be stopped without
Um. I hate to play semantic games, but if you know of attacks that BIND 8.1.1 is not immune to, then BIND 8.1.1 is not immune to all known attacks.
Since this is not a security list, I'll refrain from (rhetorically) informing you that history doesn't back up your assertion of the existence of "holes that only the good guys know".
Oops. Sorry about that.
Thanks for clearing this up!
---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
Paul has made it clear that there are holes in the DNS protocols that cannot be fixed without DNSSEC. He isn't papering anything over -- he
Thank you for clearing this up. For the record, my only intention is to clarify the facts surrounding the DNS security issues that have been popularized by the recent Alternic attacks. I think I have done this. To reiterate: BIND 8.1.1 is not immune to all the variants of the attack used by the Alternic, and there are very real security problems that remain (and will continue to remain) until the implementation of DNSSEC (according to Mr. Vixie). As this thread is now rapidly losing it's operations context (as well as it's informative value), I'd suggest we now move towards killing it. Thanks! ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
To reiterate: BIND 8.1.1 is not immune to all the variants of the attack used by the Alternic,
False. The attacks which remain are not variants of the bug exploited by AlterNIC, which was a program bug rather than a protocol misfeature.
and there are very real security problems that remain (and will continue to remain) until the implementation of DNSSEC (according to Mr. Vixie).
True.
As this thread is now rapidly losing it's operations context (as well as it's informative value), I'd suggest we now move towards killing it.
As soon as messages containing misstatements like the one above stop appearing, I for one will be happy to return to lurk status.
"Thomas H. Ptacek" writes:
Paul has made it clear that there are holes in the DNS protocols that cannot be fixed without DNSSEC. He isn't papering anything over -- he
Thank you for clearing this up. For the record, my only intention is to clarify the facts surrounding the DNS security issues that have been popularized by the recent Alternic attacks. I think I have done this. To reiterate: BIND 8.1.1 is not immune to all the variants of the attack used by the Alternic,
No, it *is* immune to all variants on *THAT* attack. It isn't immune to other sorts of attacks. Perry
No, it *is* immune to all variants on *THAT* attack. It isn't immune to other sorts of attacks.
I think you are speaking in fairly blatant factual error here, or we are in micommunication with respect to the meaning of the word "variant". ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
"Thomas H. Ptacek" writes:
No, it *is* immune to all variants on *THAT* attack. It isn't immune to other sorts of attacks.
I think you are speaking in fairly blatant factual error here, or we are in micommunication with respect to the meaning of the word "variant".
No, my facts here are more or less accurate. Eugene's attack was very crude. He just put some bogus NS records into his alternic.net zone so that queries for www.alternic.net would pick up those bogus servers and their associated A records. His "sophisticated hack" consisted of typing "dig @victim -t a www.alternic.net", or something like it. I did tcpdumps of his "attack" in progress when he hit my machines so I have logs of what he did, not that they are very interesting. An attack like this, done just by putting bogus data into your DNS boot files in a similar manner, isn't going to work against the latest versions of BIND -- indeed, none of the reasonable "variants" on the attack would work, either. There *are* attacks that will work against the BIND 8.1.1, but they require that you actually learn how to program in C and do something active, and they won't do for you what one of Eugene's hacks did. I'm sure our friends at 2600 will be publishing them any day, but really, there isn't much to be done about them other than implementing DNSSEC. Perry
crude. He just put some bogus NS records into his alternic.net zone so that queries for www.alternic.net would pick up those bogus servers and their associated A records. His "sophisticated hack" consisted of
This is true, and it is essentially the textbook/cookbook version of the "poisoned resource-record" attack that was outlined by Johannes Erdfelt a few months ago on Bugtraq. What I am asserting to you is that there are variants on this attack which are not currently fixed by BIND 8.1.1. On a related note, there are things that can be done to strengthen DNS implementations (such as BIND) against these attacks that do not involve DNSSEC. So, again, I think you are either in error or we're not in understanding on the meaning of the word "variant". Perhaps, by the word "variant", you refer solely to attacks that involve modifications to a shell script, and my reference to attacks that involve programming ability cease to be classified as "variants" of the attack. So, I'd like to convey the fact that, by using the word "variant", I refer to attacks that operate at a protocol level in a manner resembling the attack performed by Mr. Kashpureff. Thanks for providing me with an opportunity to clarify this. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
On Tue, Jul 29, 1997 at 09:55:48PM -0500, Thomas H. Ptacek wrote:
What I am asserting to you is that there are variants on this attack which are not currently fixed by BIND 8.1.1. On a related note, there are things that can be done to strengthen DNS implementations (such as BIND) against these attacks that do not involve DNSSEC.
(This being still basically on-topic as it relates to the security of a critical component..) Would either you or Ben Black please give an example of a change that fits the characteristics you have described? I see a lot of "Yes it can. No it can't. Yes it can." but nobody has actually supplied any _details_. Paul has written papers on DNS security, along with BIND itself, and I'm inclined to believe him when he says there are no more trivial fixes. If you know of one, why don't you share it? I'm not asking for code, just a description of what you want changed. Then someone will either implement it or find that it is flawed. -- = Christopher Masto = chris@netmonger.net = http://www.netmonger.net/ = = NetMonger Communications = finger for PGP key = $19.95/mo unlimited access = = Director of Operations = (516) 221-6664 = mailto:info@netmonger.net = v---(cut here)---v -- yourname@some.dumb.host.com "Keep in mind that anything Kibo says makes a great sig." -- Kibo ^---(cut here)---^
In article <19970730001246.22933@netmonger.net>, you wrote:
_details_. Paul has written papers on DNS security, along with BIND itself, and I'm inclined to believe him when he says there are no more trivial fixes. If you know of one, why don't you share it? I'm not
Fair enough. Here's a simple piece of input. If BIND 8.1.1 receives a DNS query response with an invalid query ID, it logs it and drops the packet. However, the invalid query ID is evidence of an attack in progress. Why doesn't BIND parse the packet, find out what question is being answered, and immediately re-issue the query with a different ID? In other words, it's possible for BIND to detect that it is under attack (in a response-forged query-ID guessing situation). BIND doesn't do anything about this. Why? Just the simplest suggestion I can come up with (without having this go into multiple pages) to convey the idea that I am trying to be constructive here. I'm not sure this is the appropriate forum for this discussion (*copout*Ididn'tstartthisthread*copout*), but if you want further details as to my harebrained suggestions, I'm happy to give them! -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));
On Wed, Jul 30, 1997 at 04:38:59AM -0000, tqbf@smtp.enteract.com wrote:
itself, and I'm inclined to believe him when he says there are no more trivial fixes. If you know of one, why don't you share it? I'm not
Fair enough.
Here's a simple piece of input. If BIND 8.1.1 receives a DNS query response with an invalid query ID, it logs it and drops the packet. However, the invalid query ID is evidence of an attack in progress. Why doesn't BIND parse the packet, find out what question is being answered, and immediately re-issue the query with a different ID?
If a copy of BIND _receives_ a query, decides it's bogus, logs it, and drops it, then a question isn't _being_ answered, it's bing _asked_. Why _would_ BIND re-issue a query. it hadn't _issued_ that query in the first place. Or, in simpler terms, "huh"?
In other words, it's possible for BIND to detect that it is under attack (in a response-forged query-ID guessing situation). BIND doesn't do anything about this. Why?
This isn't so much a security bug, but more a lack of a security-enhancing feature. It _certainly_ doesn't merit the veiled character assination you've been using it to justify.
Just the simplest suggestion I can come up with (without having this go into multiple pages) to convey the idea that I am trying to be constructive here.
You've failed.
I'm not sure this is the appropriate forum for this discussion (*copout*Ididn'tstartthisthread*copout*), but if you want further details as to my harebrained suggestions, I'm happy to give them!
Time to move this to bind-workers, no? Perry, Paul? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
tqbf@smtp.enteract.com writes:
In article <19970730001246.22933@netmonger.net>, you wrote:
_details_. Paul has written papers on DNS security, along with BIND itself, and I'm inclined to believe him when he says there are no more trivial fixes. If you know of one, why don't you share it? I'm not
Fair enough.
Here's a simple piece of input. If BIND 8.1.1 receives a DNS query response with an invalid query ID, it logs it and drops the packet. However, the invalid query ID is evidence of an attack in progress. Why doesn't BIND parse the packet, find out what question is being answered, and immediately re-issue the query with a different ID?
Oh, beautiful. I'd love a tool like that -- it would give me a way of forcing copies of BIND that had been rigged not to accept arbitrary outside queries to make queries of my choice. Were I a systems cracker, I would love such a tool. I can think of some other mean hacks I could do with that facility, too. The problem is not a lack of "clever hacks". The problem is a lack of security in the DNS protocols without DNSSEC.
In other words, it's possible for BIND to detect that it is under attack (in a response-forged query-ID guessing situation). BIND doesn't do anything about this. Why?
Because the idea isn't very intelligent? Because not everyone on earth is an idiot and stuff like this has been considered before by other people and rejected because it wasn't a brilliant idea?
Just the simplest suggestion I can come up with (without having this go into multiple pages) to convey the idea that I am trying to be constructive here.
No, what you are, Mr. Ptacek, is someone none of us have ever heard of who is coming in like a bull in a china shop informing us that although the people who build and maintain things like BIND aren't very bright, you are out there willing to save us. Thanks, but no thanks. Perry
In article <199707301403.KAA08865@jekyll.piermont.com>, you wrote:
Oh, beautiful. I'd love a tool like that -- it would give me a way of forcing copies of BIND that had been rigged not to accept arbitrary
I'm sorry I'm not being more clear about this, but I figured the word "re-issued" would convey the point. I will reiterate clearly: BIND, upon detecting forged responses to an OPEN QUERY, INVALIDATES the old query (which currently means taking the query's ID off the list of in-use query IDs) and initiates a NEW query. BIND, upon receiving a response to a query that isn't even open, logs and ignores the packet.
outside queries to make queries of my choice. Were I a systems cracker, I would love such a tool. I can think of some other mean hacks I could do with that facility, too.
Well, it's a good thing nobody has proposed that "tool".
The problem is not a lack of "clever hacks". The problem is a lack of security in the DNS protocols without DNSSEC.
The problem is that DNSSEC is not going to happen within the next 3 months; what are people running production networks using the old protocols going to do until it IS completely available? Put more directly: if I publish an exploit for a problem in the DNS protocol that cannot be fixed completely without DNSSEC, /What do you do/? You operate a highly available network used by thousands of customers daily, all of whom are angrily calling and asking why they're seeing PORN when they fire up their copy of Netscape, which happily resolves HOME.NETSCAPE.COM to WWW.PORNSHOP.COM. Remember, this is a problem that can't be fixed without a globally-deployed protocol re-vamp. What do you do? -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));
Wouldn't a behavior like this be able to be used to bring name servers down by simply killing CPU time? -Deepak. On 30 Jul 1997 tqbf@smtp.enteract.com wrote:
In article <19970730001246.22933@netmonger.net>, you wrote:
_details_. Paul has written papers on DNS security, along with BIND itself, and I'm inclined to believe him when he says there are no more trivial fixes. If you know of one, why don't you share it? I'm not
Fair enough.
Here's a simple piece of input. If BIND 8.1.1 receives a DNS query response with an invalid query ID, it logs it and drops the packet. However, the invalid query ID is evidence of an attack in progress. Why doesn't BIND parse the packet, find out what question is being answered, and immediately re-issue the query with a different ID?
In other words, it's possible for BIND to detect that it is under attack (in a response-forged query-ID guessing situation). BIND doesn't do anything about this. Why?
Just the simplest suggestion I can come up with (without having this go into multiple pages) to convey the idea that I am trying to be constructive here.
I'm not sure this is the appropriate forum for this discussion (*copout*Ididn'tstartthisthread*copout*), but if you want further details as to my harebrained suggestions, I'm happy to give them!
-- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));
Wouldn't a behavior like this be able to be used to bring name servers down by simply killing CPU time?
Yes, and it's easier than killing CPU time; there's a targetted attack wherein I can pick a resource record and continuously throw forged responses for it, with bad query IDs, at a nameserver - that server is now unable to resolve requests for that record. And, of course, this ties in nicely with other unfixed servers, since, right now, any problem that allows me to prevent a BIND server from responding to queries will allow me to spoof anything it's authoritative for. Attack detection is a tool, not an answer. I'm curious as to why it hasn't been discussed further; it's certainly not MY idea, and it's certainly been talked about on other forums. There are other tools available as well. I suppose the point (right now) is that there are things that can be done to strengthen the current DNS protocol (as well as it's implementations) that won't break naieve servers and will make attacks far harder, even in the absence of DNSSEC. What do you think the timeline is on global deployment of DNSSEC? It's surprising to me that people aren't more concerned, in light of the fact that you've just been told flat out, by myself as well as by Mr. Vixie, that there are exploitable problems that can't be entirely fixed until the entire protocol is modified. I suppose the operations context to this is, "hey, you realize DNS is COMPLETELY BROKEN? What are your plans for dealing with the possibility of someone posting exploits?" Do we simply stop using DNS? ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
On Wed, 30 Jul 1997, Thomas H. Ptacek wrote:
I suppose the operations context to this is, "hey, you realize DNS is COMPLETELY BROKEN? What are your plans for dealing with the possibility of someone posting exploits?" Do we simply stop using DNS?
The same could be said of IP. If you forge packets and ICMP or UDP attack someone, as long as your packets cross a busy enough NAP (say one of the MAE's) you can do it with impunity and effectively knock entire ISP's off the internet. "And how do I configure my router for that?" Use access-lists to prevent your networks from accepting spoofed packets from your customers, or insist that they use such filters on their routers. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
The same could be said of IP. If you forge packets and ICMP or UDP attack
MAE's) you can do it with impunity and effectively knock entire ISP's off the internet.
I'm unaware of any attacks occurring now that do not leverage superior bandwidth (ie, ping flooding from a DS3 a DS1 circuit) that are not addressed in some manner at an operating system or user level.
"And how do I configure my router for that?" Use access-lists to prevent your networks from accepting spoofed packets from your customers, or insist that they use such filters on their routers.
This is not a valid answer. People who think that the entire Internet can be globally configured to prevent packet forgery from occurring in the first place are deluding themselves, and I think we, as Internet professionals with an understanding of how these protocols work, understand that. Unfortunately, a bizarre faction of people have decided that the best way to address problems that are made difficult to repair by the design of legacy software is to deny that they A.) exist or B.) are fixeable. "Wait for IPsec" and "Wait for DNSsec" are, in my opinion, inadequate answers. "Prevent packet forgery from happening" seems ludicrous. Apologies for the quantity of opinion here. Thanks for writing. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
"Thomas H. Ptacek" writes:
The same could be said of IP. If you forge packets and ICMP or UDP attack MAE's) you can do it with impunity and effectively knock entire ISP's off the internet.
I'm unaware of any attacks occurring now that do not leverage superior bandwidth (ie, ping flooding from a DS3 a DS1 circuit) that are not addressed in some manner at an operating system or user level.
You aren't aware of lots of things. As it stands, I suspect that a large fraction of the network infrastructure could be brought down by a sufficiently determined jerk with a single DS0 bandwidth circuit, although things are not nearly as bad as they were a year ago. And no, I'm not going to tell you how. And yes, I and the other real security geeks *do* care and are trying to do our best to fix the situation.
Unfortunately, a bizarre faction of people have decided that the best way to address problems that are made difficult to repair by the design of legacy software is to deny that they A.) exist or B.) are fixeable.
You don't know what you are talking about. Let me rephrase that. You REALLY don't know what you are talking about. Might I sugest that you quit playing network and security engineer and leave those of us who are trying to get work done alone? Perry
On Thu, 31 Jul 1997, Thomas H. Ptacek wrote:
MAE's) you can do it with impunity and effectively knock entire ISP's off the internet.
I'm unaware of any attacks occurring now that do not leverage superior bandwidth (ie, ping flooding from a DS3 a DS1 circuit) that are not addressed in some manner at an operating system or user level.
Many educational institutions have greater than T1 bandwidth to the net, and these seem to be the easiest places for anyone to just walk in and get ethernet access (with no authentication) to a T1 or better, and proceed to wreak havoc on the net. I'd wager I could walk into a computer lab at the local university, and using either windows tools or linux on a floppy, do incredibly destructive things without being caught...probably without being noticed...assuming they do no filtering of traffic (based on source address) leaving their network, and assuming I don't sit there indefinitely.
This is not a valid answer. People who think that the entire Internet can be globally configured to prevent packet forgery from occurring in the first place are deluding themselves, and I think we, as Internet
Can or will? If there are reasons the entire net cannot be made IP source address forgery safe, enlighten me. I don't disagree that the likelyhood of this actually happening are right up there with me being declared Emperor of the US next week, but just because total success is highly improbable doesn't mean resistance is futile. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
This is not a valid answer. People who think that the entire Internet can be globally configured to prevent packet forgery from occurring in tone he first place are deluding themselves, and I think we, as Internet professionals with an understanding of how these protocols work, understand that.
Unfortunately, a bizarre faction of people have decided that the best way to address problems that are made difficult to repair by the design of legacy software is to deny that they A.) exist or B.) are fixeable.
"Wait for IPsec" and "Wait for DNSsec" are, in my opinion, inadequate answers. "Prevent packet forgery from happening" seems ludicrous.
Thomas, you seem to have a misconception about the audience you are addressing here. The people on this list are network operators. We operate backbone networks with national or international scope. We operate regional networks. And we operate networks in large organizations such as universities. We are not protocol designers and we are not programmers. Some of us are indeed capable of both protocol design and programming but that is not the hat we wear in this group. Here we are concerned with the nuts and bolts of keeping IP packets flowing through are networks and through the gateways we maintain with other networks using tools such as routers and switches. Since we are operators, we mainly concern ourselves with things that we can implement in the field in fullscale production networks right now. If we have any horizon into the future it is short, perhaps 6 months at the most. If a topic does not concern equipment or configurations that we can use withing 4-6 months, there is no point in discussing it here. If we were really interested in that sort of thing we would join the appropriate IETF working group or read it in USENET. So, rather than discuss what attacks people *COULD* mount on our networks and how they would build exploit tools to mount these attacks, if you would explain the things that we could do to protect ourselves from these attacks or to track down these attacks then we would be more receptive I think. In fact, I think that the discussion to dat regarding possible DNS attacks has led us all down the wrong path. If this sort of attack did occur there is not much that a network operator can do to harden themselves against it. However there is probably a *LOT* that could be done to track down the source of the attacks so that the FBI, RCMP, Interpol, etc. can solve the real problem. I certainly am not denying that problems exist but whenever someone claims to have the real solution to a problem I always ask myself wFrom owner-nanog@merit.edu Sat Aug 2 23:52:45 1997 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.4/8.8.5) with ESMTP id XAA29758 for <hyper_nanog@nic.merit.net>; Sat, 2 Aug 1997 23:52:44 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.6/8.8.5) with SMTP id PAA05845; Fri, 1 Aug 1997 15:07:12 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 1 Aug 1997 15:01:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.6/8.8.5) id PAA05685 for nanog-outgoing; Fri, 1 Aug 1997 15:01:35 -0400 (EDT) Received: from lovefm.cisco.com (lovefm.cisco.com [171.68.228.35]) by merit.edu (8.8.6/8.8.5) with SMTP id PAA05681 for <nanog@merit.edu>; Fri, 1 Aug 1997 15:01:31 -0400 (EDT) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by lovefm.cisco.com (8.6.12/8.6.5) with ESMTP id MAA14999; Fri, 1 Aug 1997 12:00:01 -0700 Message-Id: <199708011900.MAA14999@lovefm.cisco.com> To: nanog@merit.edu cc: tbates@cisco.com, eof-list@ripe.net, apops@apnic.net Subject: The Cidr Report Date: Fri, 01 Aug 1997 12:00:01 -0700 From: Tony Bates <tbates@cisco.com> Sender: owner-nanog@merit.edu This is an auto-generated mail on Fri Aug 1 12:00:00 PDT 1997 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 01Aug97 0) General Status Table History ------------- Date Prefixes 250797 45900 260797 47548 270797 47781 280797 47316 290797 47619 300797 47321 310797 46933 010897 47318 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 2533 Number of ASes announcing only one prefix: 1123 (579 cidr, 544 classful) Largest number of cidr routes: 516 announced by AS3561 Largest number of classful routes: 1320 announced by AS1221 1) Gains by aggregating at the origin AS level --- 01Aug97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 799 473 326 40.8% iSTAR Internet, Inc. AS1221 1320 1025 295 22.3% AARNET-AS AS174 949 725 224 23.6% Performance Systems International AS376 417 201 216 51.8% RISQ Backbone AS3602 515 308 207 40.2% Sprint Canada Inc. AS4293 319 144 175 54.9% IMCI AS2048 253 119 134 53.0% LANET-1 AS701 1048 942 106 10.1% Alternet AS839 125 26 99 79.2% North West Territories Regional N AS1 1006 908 98 9.7% BBNPLANET AS1967 159 67 92 57.9% Middle East Technical University AS816 364 282 82 22.5% UUNET Canada (ASN-UUNETCA-AS4) AS7195 123 41 82 66.7% INTERRED AS3804 215 134 81 37.7% Bell Solutions AS2704 255 181 74 29.0% HOOKUP-NET-A AS549 255 192 63 24.7% ONet Backbone AS1239 666 603 63 9.5% SprintLink Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4763 129 70 59 45.7% Telstra New Zealand AS4648 188 133 55 29.3% NZIX 2 AS72 83 29 54 65.1% Schlumberger Information Network AS3464 115 61 54 47.0% ASC-NET AS719 577 524 53 9.2% LANLINK autonomous system AS3561 961 908 53 5.5% MCI AS97 173 125 48 27.7% JvNCnet AS4454 76 29 47 61.8% TNET-AS AS8013 104 60 44 42.3% PSINET-CA AS4747 114 73 41 36.0% Taiwan Telecommunication Network AS2711 102 61 41 40.2% SUNBELT-AS AS271 98 57 41 41.8% BCnet Backbone --- 31Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 799 473 326 40.8% iSTAR Internet, Inc. AS1221 1105 847 258 23.3% AARNET-AS AS174 951 728 223 23.4% Performance Systems International AS376 422 204 218 51.7% RISQ Backbone AS3602 515 308 207 40.2% Sprint Canada Inc. AS4293 318 146 172 54.1% IMCI AS2048 253 122 131 51.8% LANET-1 AS701 1034 930 104 10.1% Alternet AS839 125 26 99 79.2% North West Territories Regional N AS1 1004 907 97 9.7% BBNPLANET AS6541 163 71 92 56.4% GTE Intelligent Network Services AS1967 158 66 92 58.2% Middle East Technical University AS7195 123 41 82 66.7% INTERRED AS3804 215 134 81 37.7% Bell Solutions AS816 359 279 80 22.3% UUNET Canada (ASN-UUNETCA-AS4) AS2704 258 183 75 29.1% HOOKUP-NET-A AS549 255 192 63 24.7% ONet Backbone AS1239 668 605 63 9.4% SprintLink Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4648 192 137 55 28.6% NZIX 2 AS719 577 524 53 9.2% LANLINK autonomous system AS3561 952 900 52 5.5% MCI AS3464 112 61 51 45.5% ASC-NET AS97 175 127 48 27.4% JvNCnet AS4454 76 29 47 61.8% TNET-AS AS8013 100 56 44 44.0% PSINET-CA AS1691 173 131 42 24.3% BCTEL AS2711 102 61 41 40.2% SUNBELT-AS AS271 98 57 41 41.8% BCnet Backbone AS813 186 146 40 21.5% UUNET Canada (ASN-UUNETCA-AS1) --- 30Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 798 472 326 40.9% iSTAR Internet, Inc. AS1221 1104 850 254 23.0% AARNET-AS AS174 954 730 224 23.5% Performance Systems International AS376 422 201 221 52.4% RISQ Backbone AS6235 363 150 213 58.7% Intermedia Communications, Inc. AS3602 515 308 207 40.2% Sprint Canada Inc. AS4293 318 147 171 53.8% IMCI AS2048 251 123 128 51.0% LANET-1 AS701 1025 923 102 10.0% Alternet AS1 1008 906 102 10.1% BBNPLANET AS839 125 26 99 79.2% North West Territories Regional N AS1967 168 71 97 57.7% Middle East Technical University AS6541 162 69 93 57.4% GTE Intelligent Network Services AS7195 123 41 82 66.7% INTERRED AS3804 214 133 81 37.9% Bell Solutions AS816 343 266 77 22.4% UUNET Canada (ASN-UUNETCA-AS4) AS2704 258 188 70 27.1% HOOKUP-NET-A AS549 257 193 64 24.9% ONet Backbone AS1239 668 605 63 9.4% SprintLink Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4763 129 70 59 45.7% Telstra New Zealand AS4648 194 138 56 28.9% NZIX 2 AS72 83 29 54 65.1% Schlumberger Information Network AS719 575 522 53 9.2% LANLINK autonomous system AS3561 955 902 53 5.5% MCI AS97 175 127 48 27.4% JvNCnet AS3464 109 61 48 44.0% ASC-NET AS4454 79 32 47 59.5% TNET-AS AS8013 99 56 43 43.4% PSINET-CA AS813 198 156 42 21.2% UUNET Canada (ASN-UUNETCA-AS1) --- 29Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1507 1066 441 29.3% AARNET-AS AS2493 799 473 326 40.8% iSTAR Internet, Inc. AS174 951 727 224 23.6% Performance Systems International AS376 422 202 220 52.1% RISQ Backbone AS3602 517 309 208 40.2% Sprint Canada Inc. AS6235 346 143 203 58.7% Intermedia Communications, Inc. AS4293 304 156 148 48.7% IMCI AS2048 251 120 131 52.2% LANET-1 AS701 1017 914 103 10.1% Alternet AS839 125 26 99 79.2% North West Territories Regional N AS1 1005 907 98 9.8% BBNPLANET AS1967 167 70 97 58.1% Middle East Technical University AS7195 124 41 83 66.9% INTERRED AS3804 214 133 81 37.9% Bell Solutions AS816 341 265 76 22.3% UUNET Canada (ASN-UUNETCA-AS4) AS6541 144 71 73 50.7% GTE Intelligent Network Services AS2704 260 189 71 27.3% HOOKUP-NET-A AS1239 669 606 63 9.4% SprintLink Backbone AS549 244 184 60 24.6% ONet Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4763 129 70 59 45.7% Telstra New Zealand AS4648 194 138 56 28.9% NZIX 2 AS72 83 29 54 65.1% Schlumberger Information Network AS719 575 522 53 9.2% LANLINK autonomous system AS97 174 126 48 27.6% JvNCnet AS4454 78 31 47 60.3% TNET-AS AS3561 950 904 46 4.8% MCI AS813 200 157 43 21.5% UUNET Canada (ASN-UUNETCA-AS1) AS1691 174 131 43 24.7% BCTEL AS2711 102 61 41 40.2% SUNBELT-AS --- 28Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1835 1311 524 28.6% UNKNOWN AS2493 798 473 325 40.7% UNKNOWN AS174 951 722 229 24.1% UNKNOWN AS376 419 202 217 51.8% UNKNOWN AS3602 517 307 210 40.6% UNKNOWN AS6235 347 141 206 59.4% UNKNOWN AS4293 320 144 176 55.0% UNKNOWN AS2048 249 119 130 52.2% UNKNOWN AS701 1017 912 105 10.3% UNKNOWN AS839 125 26 99 79.2% North West Territories Regional N AS1967 168 71 97 57.7% Middle East Technical University AS1 1004 908 96 9.6% UNKNOWN AS6541 165 71 94 57.0% GTE Intelligent Network Services AS7195 123 42 81 65.9% INTERRED AS816 338 265 73 21.6% UNKNOWN AS2704 257 186 71 27.6% UNKNOWN AS3804 164 99 65 39.6% Bell Solutions AS549 255 191 64 25.1% UNKNOWN AS1239 672 608 64 9.5% UNKNOWN AS5668 72 13 59 81.9% Century Telephone Inc. AS4763 129 70 59 45.7% Telstra New Zealand AS4648 193 138 55 28.5% NZIX 2 AS72 83 29 54 65.1% Schlumberger Information Network AS719 576 523 53 9.2% UNKNOWN AS3561 960 907 53 5.5% UNKNOWN AS97 175 127 48 27.4% JvNCnet AS3464 108 60 48 44.4% ASC-NET AS4454 78 31 47 60.3% TNET-AS AS813 200 156 44 22.0% UNKNOWN AS1691 173 130 43 24.9% BCTEL --- 27Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1826 1309 517 28.3% AARNET-AS AS2493 798 473 325 40.7% iSTAR Internet, Inc. AS174 957 728 229 23.9% Performance Systems International AS376 419 202 217 51.8% RISQ Backbone AS3602 517 307 210 40.6% Sprint Canada Inc. AS6235 347 141 206 59.4% Intermedia Communications, Inc. AS4293 318 147 171 53.8% IMCI AS2048 249 119 130 52.2% LANET-1 AS3804 247 135 112 45.3% Bell Solutions AS701 1014 909 105 10.4% Alternet AS839 125 26 99 79.2% North West Territories Regional N AS6541 163 70 93 57.1% GTE Intelligent Network Services AS1 1003 910 93 9.3% BBNPLANET AS7195 124 41 83 66.9% INTERRED AS816 337 262 75 22.3% UUNET Canada (ASN-UUNETCA-AS4) AS2704 259 188 71 27.4% HOOKUP-NET-A AS549 257 193 64 24.9% ONet Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4763 129 70 59 45.7% Telstra New Zealand AS4648 195 139 56 28.7% NZIX 2 AS72 83 29 54 65.1% Schlumberger Information Network AS3561 956 903 53 5.5% MCI AS1239 576 523 53 9.2% SprintLink Backbone AS719 574 522 52 9.1% LANLINK autonomous system AS3464 108 60 48 44.4% ASC-NET AS4454 78 31 47 60.3% TNET-AS AS813 198 155 43 21.7% UUNET Canada (ASN-UUNETCA-AS1) AS1691 173 130 43 24.9% BCTEL AS97 169 127 42 24.9% JvNCnet AS2711 103 61 42 40.8% SUNBELT-AS --- 26Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1833 1312 521 28.4% AARNET-AS AS2493 794 470 324 40.8% iSTAR Internet, Inc. AS174 960 730 230 24.0% Performance Systems International AS376 424 203 221 52.1% RISQ Backbone AS3602 517 307 210 40.6% Sprint Canada Inc. AS4293 319 144 175 54.9% IMCI AS2048 249 119 130 52.2% LANET-1 AS3804 246 134 112 45.5% Bell Solutions AS839 125 26 99 79.2% North West Territories Regional N AS701 999 900 99 9.9% Alternet AS1967 168 71 97 57.7% Middle East Technical University AS6541 164 70 94 57.3% GTE Intelligent Network Services AS7195 124 41 83 66.9% INTERRED AS816 341 265 76 22.3% UUNET Canada (ASN-UUNETCA-AS4) AS1 949 875 74 7.8% BBNPLANET AS2704 259 186 73 28.2% HOOKUP-NET-A AS549 255 194 61 23.9% ONet Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4763 129 70 59 45.7% Telstra New Zealand AS4648 193 137 56 29.0% NZIX 2 AS72 83 29 54 65.1% Schlumberger Information Network AS719 576 523 53 9.2% LANLINK autonomous system AS3561 962 909 53 5.5% MCI AS3464 113 60 53 46.9% ASC-NET AS1239 577 524 53 9.2% SprintLink Backbone AS97 175 126 49 28.0% JvNCnet AS4454 78 31 47 60.3% TNET-AS AS813 199 156 43 21.6% UUNET Canada (ASN-UUNETCA-AS1) AS1691 173 130 43 24.9% BCTEL AS2711 103 61 42 40.8% SUNBELT-AS --- 25Jul97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 794 470 324 40.8% iSTAR Internet, Inc. AS174 958 734 224 23.4% Performance Systems International AS376 424 203 221 52.1% RISQ Backbone AS3602 519 306 213 41.0% Sprint Canada Inc. AS4293 318 146 172 54.1% IMCI AS2048 249 119 130 52.2% LANET-1 AS3804 246 134 112 45.5% Bell Solutions AS701 1014 910 104 10.3% Alternet AS839 125 26 99 79.2% North West Territories Regional N AS1967 167 70 97 58.1% Middle East Technical University AS6541 164 70 94 57.3% GTE Intelligent Network Services AS1 1003 909 94 9.4% BBNPLANET AS7195 124 41 83 66.9% INTERRED AS816 341 265 76 22.3% UUNET Canada (ASN-UUNETCA-AS4) AS2704 258 189 69 26.7% HOOKUP-NET-A AS549 257 193 64 24.9% ONet Backbone AS5668 72 13 59 81.9% Century Telephone Inc. AS4648 194 138 56 28.9% NZIX 2 AS1221 442 386 56 12.7% AARNET-AS AS3464 115 60 55 47.8% ASC-NET AS72 83 29 54 65.1% Schlumberger Information Network AS719 577 524 53 9.2% LANLINK autonomous system AS3561 956 903 53 5.5% MCI AS1239 577 524 53 9.2% SprintLink Backbone AS4763 108 62 46 42.6% Telstra New Zealand AS4454 72 26 46 63.9% TNET-AS AS97 173 128 45 26.0% JvNCnet AS813 199 156 43 21.6% UUNET Canada (ASN-UUNETCA-AS1) AS1691 171 128 43 25.1% BCTEL AS2711 101 59 42 41.6% SUNBELT-AS 2) Weekly Delta This a daily snapshot of changes in classful routes being withdrawn and added. the deltas are calculated over a rolling 7 day period. Please bear in mind this is purely a "snapshot" and a large flucuation could be caused by a connectivity problem for example. However, this does give some indication of service providers that are moving to classless routing. Top 20 Withdrawn Classful Routes from 25Jul97 to 01Aug97 -151 AS6541 GTE Intelligent Network Services -37 AS225 VIRGINIA-AS -31 AS3804 Bell Solutions -24 AS7314 Traveller Information Services -19 AS6235 Intermedia Communications, Inc. -16 AS5872 DDN-ASNBLK -15 AS813 UUNET Canada (ASN-UUNETCA-AS1) -14 AS4239 Coast to Coast Telecommunications -13 AS4452 America Net, Inc. -11 AS7900 HOOSIER -10 AS4736 Magnadata Australia Pty Ltd -9 AS568 JIS (Joint Interconnection Servic -8 AS1967 Middle East Technical University -7 AS4433 Access One Pty Ltd (ASN-ACCESS-ON -6 AS4648 NZIX 2 -5 AS1852 UCNet -4 AS3602 Sprint Canada Inc. -3 AS591 NSTN-AS -2 AS3208 ARN Network -1 AS22 NOSC (Naval Ocean Systems Center) Top 20 Added Classful Routes from 25Jul97 to 01Aug97 878 AS1221 AARNET-AS 198 AS4740 OzEmail ISP 89 AS1239 SprintLink Backbone 49 AS7545 TPG Internet Pty Ltd 40 AS705 ALTERNET-AS 38 AS2386 INS-AS 34 AS701 Alternet 28 AS7475 The University of Queensland 23 AS816 UUNET Canada (ASN-UUNETCA-AS4) 22 AS3576 PREPnet-EAST 21 AS6365 I1 16 AS6113 Gridnet International 14 AS4857 Mira Networking Pty Ltd 12 AS6138 CIOE 10 AS6975 LEX2 8 AS2715 REDERIO-AS 7 AS3932 VoiceNet 6 AS7476 The University of Queensland 5 AS3561 MCI 4 AS1273 ECRC Network This a daily snapshot of changes in classles routes being withdrawn and added. Top 20 Withdrawn Classles Routes from 25Jul97 to 01Aug97 -138 AS2056 AOL-AS -18 AS1292 ITESM Campus -- Monterrey -12 AS376 RISQ Backbone -9 AS4200 AGIS (Apex Global Information Ser -7 AS6235 Intermedia Communications, Inc. -4 AS2871 Internet Services GmbH & Co -3 AS4609 Companhia de Telecomunicacoes de -2 AS3388 UNM-AS -1 AS5486 Euronet Digital Communications Top 20 Added Classles Routes from 25Jul97 to 01Aug97 106 AS1221 AARNET-AS 35 AS1239 SprintLink Backbone 22 AS4454 TNET-AS 19 AS174 Performance Systems International 17 AS4740 OzEmail ISP 12 AS701 Alternet 9 AS1347 Minnesota Regional Network 8 AS3267 RUNNet 7 AS4736 Magnadata Australia Pty Ltd 6 AS7475 The University of Queensland 5 AS4738 South Australian Academic Researc 4 AS7962 ExisNet 3 AS2529 Demon Internet Ltd 2 AS2828 InterNex Information Services 1 AS6648 SKY-INTERNET 3) Interesting aggregates List of possibly interesting aggregates --------------------------------------- Aggregate | Origin | AS Description | Netname ------------------------------------------------------------------------------- 160.43.253.0/24 | AS8188 | Bloomberg Financial Mar | Bloomberg Financial Mar 24.231.0.0/19 | AS8160 | FUNDY AS object | @Home Network (NETBLK-A 151.204.0.0/18 | AS8114 | Bell Atlantic Internet | Bell Atlantic (NETBLK-B 157.22.160.0/19 | AS8046 | NAPANET | Zocalo Engineering (NET 157.22.192.0/21 | AS8046 | NAPANET | Zocalo Engineering (NET 24.226.0.0/19 | AS7992 | COGECOWAVE | @Home Network (NETBLK-A 147.160.224.0/20 | AS7816 | NORTHWESTCTCNET | Concurrent Technologies 24.130.0.0/18 | AS7757 | CCI-AS2-BLK | @Home Network (NETBLK-A 24.131.128.0/18 | AS7756 | CCI-AS2-BLK | @Home Network (NETBLK-A 142.205.36.0/23 | AS7734 | AS for TDBANK | Canadian Research Netwo 142.205.64.0/23 | AS7734 | AS for TDBANK | Canadian Research Netwo 142.205.208.0/23 | AS7734 | AS for TDBANK | Canadian Research Netwo 142.205.212.0/23 | AS7734 | AS for TDBANK | Canadian Research Netwo 142.205.232.0/23 | AS7734 | AS for TDBANK | Canadian Research Netwo 142.205.240.0/23 | AS7734 | AS for TDBANK | Canadian Research Netwo 142.205.248.0/23 | AS7734 | AS for TDBANK | Canadian Research Netwo 24.88.0.0/18 | AS7725 | MEDIA1-CAB | @Home Network (NETBLK-A 169.153.0.0/17 | AS7687 | APNIC-AS-2-BLOCK | Tech Data Corporation ( 169.153.128.0/17 | AS7687 | APNIC-AS-2-BLOCK | Tech Data Corporation ( 163.195.192.0/19 | AS7460 | LIA-NET | Cape Provincial Adminis 129.231.48.0/21 | AS7435 | ATM-CIN | Digital Commnications A 129.231.56.0/24 | AS7435 | ATM-CIN | Digital Commnications A 129.231.59.0/24 | AS7435 | ATM-CIN | Digital Commnications A 138.87.1.0/24 | AS7386 | ILLINOIS-STATE-UNIV | Illinois State Universi 138.87.7.0/24 | AS7386 | ILLINOIS-STATE-UNIV | Illinois State Universi 138.87.8.0/24 | AS7386 | ILLINOIS-STATE-UNIV | Illinois State Universi 138.87.11.0/24 | AS7386 | ILLINOIS-STATE-UNIV | Illinois State Universi 138.87.57.0/24 | AS7386 | ILLINOIS-STATE-UNIV | Illinois State Universi 138.87.58.0/24 | AS7386 | ILLINOIS-STATE-UNIV | Illinois State Universi 138.87.126.0/24 | AS7386 | ILLINOIS-STATE-UNIV | Illinois State Universi 146.115.132.0/23 | AS7174 | Onward Technologies, In | * 132.45.120.0/21 | AS7170 | DISC/DREN | * 192.77.198.0/25 | AS7068 | PFIZERNET | Performance Systems Int 192.77.198.128/25 | AS7068 | PFIZERNET | Performance Systems Int 130.213.0.0/17 | AS7046 | UUNET-CUSTOMER | * 130.213.128.0/17 | AS7046 | UUNET-CUSTOMER | * 24.129.0.0/18 | AS7017 | CCI-AS-BLK | @Home Network (NETBLK-A 24.131.0.0/18 | AS7016 | CCI-AS-BLK | @Home Network (NETBLK-A 24.128.0.0/18 | AS7015 | CCI-AS-BLK | @Home Network (NETBLK-A 24.128.64.0/19 | AS7015 | CCI-AS-BLK | @Home Network (NETBLK-A 24.113.0.0/19 | AS6997 | Rogers Network Services | @Home Network (NETBLK-A 130.140.146.0/24 | AS6920 | TRADEMED-AS | Philips Components BV ( 130.140.150.0/24 | AS6920 | TRADEMED-AS | Philips Components BV ( 130.140.152.0/24 | AS6920 | TRADEMED-AS | Philips Components BV ( 53.53.53.0/24 | AS6878 | debis ASN | cap debis ccs (NET-DB-N 152.158.84.0/24 | AS6755 | ASN - TURNET | * 149.224.128.0/17 | AS6705 | Hassler & Mair GmbH | c/o University of Dortm 24.96.0.0/18 | AS6541 | GTE Intelligent Network | @Home Network (NETBLK-A 24.72.0.0/18 | AS6539 | Broadband1 | @Home Network (NETBLK-A 142.194.32.0/19 | AS6537 | UNITEL-PDA | CA*Net (NETBLK-CANET-B- 142.194.96.0/19 | AS6537 | UNITEL-PDA | CA*Net (NETBLK-CANET-B- 142.194.128.0/19 | AS6537 | UNITEL-PDA | CA*Net (NETBLK-CANET-B- 142.194.160.0/19 | AS6537 | UNITEL-PDA | CA*Net (NETBLK-CANET-B- 142.194.224.0/19 | AS6537 | UNITEL-PDA | CA*Net (NETBLK-CANET-B- 146.126.2.0/24 | AS6501 | SOUTHERNET | Southern Company Servic 146.126.51.0/24 | AS6501 | SOUTHERNET | Southern Company Servic 146.126.86.0/24 | AS6501 | SOUTHERNET | Southern Company Servic 156.28.4.0/24 | AS6474 | FLASHNET-AS | Turbomeca (NET-TURBOMEC 156.28.5.0/24 | AS6474 | FLASHNET-AS | Turbomeca (NET-TURBOMEC 156.28.26.0/24 | AS6474 | FLASHNET-AS | Turbomeca (NET-TURBOMEC 142.42.242.0/24 | AS6463 | Rogers Network Services | National Archives of Ca 24.112.0.0/19 | AS6463 | Rogers Network Services | @Home Network (NETBLK-A 168.234.128.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d 168.234.135.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d 147.249.3.0/24 | AS6419 | IDD | IDD Information Service 148.212.48.0/20 | AS6332 | TELNOR | Universidad Autonoma de 148.212.64.0/18 | AS6332 | TELNOR | Universidad Autonoma de 148.212.128.0/17 | AS6332 | TELNOR | * 24.64.0.0/19 | AS6327 | Shaw Fiberlink Ltd. | @Home Network (NETBLK-A 24.64.32.0/19 | AS6327 | Shaw Fiberlink Ltd. | @Home Network (NETBLK-A 150.187.40.0/21 | AS6306 | T-NET-AS | Consejo Nacional de Inv 134.129.0.0/18 | AS6263 | NDIN | North Dakota State Univ 134.129.64.0/18 | AS6263 | NDIN | North Dakota State Univ 134.129.128.0/17 | AS6263 | NDIN | North Dakota State Univ 165.88.1.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.10.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.11.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.14.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.15.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.16.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.17.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.19.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.23.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.24.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.27.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.28.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.29.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.30.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.32.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.33.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.34.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.35.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.36.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.37.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.38.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.39.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.40.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.102.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.103.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.104.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.105.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.106.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.107.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.108.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.109.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.110.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.111.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.112.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.113.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.114.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.115.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.116.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.117.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.118.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.119.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.121.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.122.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.123.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.124.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.125.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.126.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.128.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.129.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.130.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.131.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.132.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.133.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.134.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.135.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.151.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.152.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.154.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.155.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.158.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.159.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.160.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.166.0/24 | AS6254 | EGGINC | EG&G, Inc./ Corporate H 165.88.41.0/24 | AS6254 | EGGINC | * 165.88.42.0/24 | AS6254 | EGGINC | * 165.88.43.0/24 | AS6254 | EGGINC | * 165.88.44.0/24 | AS6254 | EGGINC | * 165.88.45.0/24 | AS6254 | EGGINC | * 165.88.46.0/24 | AS6254 | EGGINC | * 165.88.47.0/24 | AS6254 | EGGINC | * 165.88.49.0/24 | AS6254 | EGGINC | * 165.88.50.0/24 | AS6254 | EGGINC | * 165.88.94.0/24 | AS6254 | EGGINC | * 165.88.100.0/24 | AS6254 | EGGINC | * 165.88.101.0/24 | AS6254 | EGGINC | * 165.88.168.0/24 | AS6254 | EGGINC | * 165.88.177.0/24 | AS6254 | EGGINC | * 165.88.179.0/24 | AS6254 | EGGINC | * 165.88.182.0/24 | AS6254 | EGGINC | * 165.88.195.0/24 | AS6254 | EGGINC | * 165.88.200.0/24 | AS6254 | EGGINC | * 165.88.206.0/24 | AS6254 | EGGINC | * 165.88.217.0/24 | AS6254 | EGGINC | * 165.88.219.0/24 | AS6254 | EGGINC | * 165.88.230.0/24 | AS6254 | EGGINC | * 165.88.235.0/24 | AS6254 | EGGINC | * 165.88.236.0/24 | AS6254 | EGGINC | * 165.88.240.0/24 | AS6254 | EGGINC | * 165.88.242.0/24 | AS6254 | EGGINC | * 165.88.243.0/24 | AS6254 | EGGINC | * 165.88.251.0/24 | AS6254 | EGGINC | * 165.88.252.0/24 | AS6254 | EGGINC | * 165.88.253.0/24 | AS6254 | EGGINC | * 165.88.254.0/24 | AS6254 | EGGINC | * 146.115.96.0/22 | AS6249 | UltraNet RI | * 24.227.0.0/19 | AS6235 | Intermedia Communicatio | @Home Network (NETBLK-A 169.228.128.0/19 | AS6192 | UCDAVIS-CORE | University of Californi 169.228.160.0/20 | AS6192 | UCDAVIS-CORE | University of Californi 163.195.0.0/17 | AS6187 | Global One South Africa | Cape Provincial Adminis 163.195.128.0/18 | AS6187 | Global One South Africa | Cape Provincial Adminis 24.0.0.0/14 | AS6172 | HOME-NET-1 | @Home Network (NETBLK-A 24.0.0.0/18 | AS6172 | HOME-NET-1 | @Home Network (NETBLK-A 24.1.0.0/17 | AS6172 | HOME-NET-1 | @Home Network (NETBLK-A 24.4.0.0/17 | AS6172 | HOME-NET-1 | @Home Network (NETBLK-A 169.130.52.0/24 | AS6153 | ASN-SPRN-NYSERNET | Sprint, Business Servic 162.122.9.0/24 | AS6140 | ImpSat Corp | Maraven S.A. (NET-MARAV 162.122.12.0/24 | AS6140 | ImpSat Corp | Maraven S.A. (NET-MARAV 200.31.0.0/25 | AS6140 | ImpSat Corp | IMPSAT MEXICO (NETBLK-I 165.113.197.0/24 | AS6086 | INFOMAGIC | CRL Network Services, I 165.113.198.0/24 | AS6086 | INFOMAGIC | CRL Network Services, I 165.113.199.0/24 | AS6086 | INFOMAGIC | CRL Network Services, I 165.113.211.0/24 | AS6086 | INFOMAGIC | CRL Network Services, I 161.223.90.0/23 | AS6077 | Network Intensive - A D | Indian Health Service ( 165.244.32.0/19 | AS6068 | LG-AS | Systems Technology Mana 165.244.64.0/18 | AS6068 | LG-AS | Systems Technology Mana 148.94.35.0/24 | AS5714 | EDS-WEBS | EDS Network Naming & Ad 148.94.210.0/24 | AS5714 | EDS-WEBS | EDS Network Naming & Ad 135.14.65.0/24 | AS5696 | GoodNet AS | Lucent Technologies (NE 139.61.102.0/23 | AS5696 | GoodNet AS | Litton Computer Service 165.247.10.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.31.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.33.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.36.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.38.0/25 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.47.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.49.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.50.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.58.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.70.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.73.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.76.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.77.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.78.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.81.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.88.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.92.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.101.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.134.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.241.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.245.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.246.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 165.247.248.0/24 | AS5696 | GoodNet AS | Internet Direct, Inc. ( 157.232.100.0/24 | AS5696 | GoodNet AS | Health Data Sciences Co 165.247.210.0/24 | AS5696 | GoodNet AS | * 165.247.236.0/24 | AS5696 | GoodNet AS | * 165.215.191.0/24 | AS5683 | Cable and Wireless Inte | Bell & Howell Company ( 207.212.197.0/27 | AS5678 | PBI-NET-BLK | * 148.160.6.0/24 | AS5556 | Telenordia AB | Boras Energi (NET-BS-EN 158.177.32.0/19 | AS5551 | Corinet Internet Servic | KPMG Peat Marwick (NET- 153.96.76.0/24 | AS5501 | Fraunhofer Gesellschaft | * 153.97.64.0/18 | AS5501 | Fraunhofer Gesellschaft | * 153.97.128.0/18 | AS5501 | Fraunhofer Gesellschaft | * 164.39.244.0/24 | AS5484 | BT Netherlands Regional | No match for "164.39.0. 57.12.0.0/16 | AS5384 | Etisalat Emirates Inter | SITA-Societe Internatio 132.155.204.0/24 | AS5384 | Etisalat Emirates Inter | * 195.204.42.0/25 | AS5381 | PowerTech Information S | European Regional Inter 195.204.43.0/27 | AS5381 | PowerTech Information S | European Regional Inter 195.204.43.32/27 | AS5381 | PowerTech Information S | European Regional Inter 199.125.7.32/32 | AS5086 | ID-Net, Inc. Network Op | Innovative Data Service 199.125.7.64/32 | AS5086 | ID-Net, Inc. Network Op | Innovative Data Service 199.125.1.101/32 | AS5086 | ID-Net, Inc. Network Op | Innovative Data Service 199.125.1.124/32 | AS5086 | ID-Net, Inc. Network Op | Innovative Data Service 199.125.1.128/32 | AS5086 | ID-Net, Inc. Network Op | Innovative Data Service 199.125.1.131/32 | AS5086 | ID-Net, Inc. Network Op | Innovative Data Service 147.73.192.0/18 | AS5050 | PSC AS for connect to M | Pittsburgh Supercomputi 160.81.101.0/24 | AS4861 | Global IP / Global Spri | Sprint International (N 163.44.224.0/23 | AS4853 | Justsystem Corporation | Justsystem Corporation 139.175.24.0/22 | AS4780 | INSTITUTE FOR INFORMATI | Institution for Informa 139.175.28.0/23 | AS4780 | INSTITUTE FOR INFORMATI | Institution for Informa 139.175.118.0/24 | AS4780 | INSTITUTE FOR INFORMATI | Institution for Informa 139.175.161.0/24 | AS4780 | INSTITUTE FOR INFORMATI | Institution for Informa 139.175.183.0/24 | AS4780 | INSTITUTE FOR INFORMATI | Institution for Informa 139.175.184.0/22 | AS4780 | INSTITUTE FOR INFORMATI | Institution for Informa 164.100.80.0/24 | AS4755 | Videsh Sanchar Nigam Lt | National Informatics Ce 164.100.199.0/24 | AS4755 | Videsh Sanchar Nigam Lt | National Informatics Ce 138.206.254.0/24 | AS4742 | AT&T EasyLink Services | Potter Partners Limited 136.1.30.0/24 | AS4742 | AT&T EasyLink Services | Ford Motor Company (NET 158.40.3.0/24 | AS4740 | OzEmail ISP | Department of Prime Min 158.40.4.0/24 | AS4740 | OzEmail ISP | Department of Prime Min 150.207.128.0/24 | AS4739 | Commerical Internet eXc | AWA Defence Industries 134.65.92.0/24 | AS4736 | Magnadata Australia Pty | Avon Products Incorpora 165.244.0.0/19 | AS4668 | AS Object of LGEDS in K | Systems Technology Mana 202.69.3.192/26 | AS4639 | Planet Internet Limited | Asia Pacific Network In 146.222.7.0/24 | AS4637 | Hong Kong Telecom | Hewlett-Packard Company 146.222.11.0/24 | AS4637 | Hong Kong Telecom | Hewlett-Packard Company 146.222.198.0/23 | AS4637 | Hong Kong Telecom | Hewlett-Packard Company 152.160.0.0/17 | AS4595 | ICNET | * 152.160.128.0/17 | AS4595 | ICNET | * 24.234.0.0/19 | AS4565 | Epoch Internet - Former | @Home Network (NETBLK-A 129.171.32.0/19 | AS4511 | MIAMI-EDU | University of Miami (NE 129.171.64.0/19 | AS4511 | MIAMI-EDU | University of Miami (NE 129.171.96.0/19 | AS4511 | MIAMI-EDU | * 129.171.128.0/19 | AS4511 | MIAMI-EDU | * 129.171.160.0/19 | AS4511 | MIAMI-EDU | * 152.129.186.0/24 | AS4478 | PNET-STL | Department of Veterans 165.90.16.0/24 | AS4263 | CERNET-ASN-BLOCK | Pagesat Inc. (NET-PAGES 165.90.128.0/19 | AS4263 | CERNET-ASN-BLOCK | Pagesat Inc. (NET-PAGES 165.90.224.0/19 | AS4263 | CERNET-ASN-BLOCK | Pagesat Inc. (NET-PAGES 165.90.2.0/24 | AS4263 | CERNET-ASN-BLOCK | * 128.193.32.0/19 | AS4201 | Oregon State University | Oregon State University 128.193.64.0/19 | AS4201 | Oregon State University | Oregon State University 128.193.96.0/19 | AS4201 | Oregon State University | Oregon State University 128.193.128.0/19 | AS4201 | Oregon State University | Oregon State University 128.193.160.0/19 | AS4201 | Oregon State University | Oregon State University 128.193.192.0/19 | AS4201 | Oregon State University | Oregon State University 128.193.224.0/19 | AS4201 | Oregon State University | Oregon State University 206.250.40.0/25 | AS4200 | AGIS (Apex Global Infor | Overland Network (NET-O 206.250.40.128/25 | AS4200 | AGIS (Apex Global Infor | Overland Network (NET-O 166.102.93.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.94.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.95.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.96.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.97.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.98.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.99.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.101.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.102.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.103.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.104.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.105.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.106.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.107.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.108.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.109.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.110.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.111.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.112.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.113.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.114.0/23 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.116.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.117.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.118.0/23 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.120.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 166.102.121.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET 206.85.22.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 206.250.27.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 205.199.213.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 206.250.203.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 206.250.204.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 206.250.27.64/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 206.85.22.128/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 205.199.213.128/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9 209.14.31.0/26 | AS4200 | AGIS (Apex Global Infor | * 166.102.122.0/24 | AS4200 | AGIS (Apex Global Infor | * 166.102.123.0/24 | AS4200 | AGIS (Apex Global Infor | * 166.102.150.0/23 | AS4200 | AGIS (Apex Global Infor | * 166.102.152.0/24 | AS4200 | AGIS (Apex Global Infor | * 166.102.161.0/24 | AS4200 | AGIS (Apex Global Infor | * 157.248.160.0/24 | AS4183 | CompuServe, Incorporate | Guaranty National Insur 163.124.7.0/24 | AS4058 | Primary AS for LinkAGE | Lehman Brothers (NET-SH 163.124.221.0/24 | AS4058 | Primary AS for LinkAGE | Lehman Brothers (NET-SH 156.5.252.0/23 | AS4004 | Global IP | Unilever (NET-UNILEVER2 147.85.17.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.21.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.25.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.39.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.44.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.51.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.54.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.98.0/24 | AS3951 | ICONNET | Nomura Research Institu 147.85.115.0/24 | AS3951 | ICONNET | Nomura Research Institu 161.200.0.0/17 | AS3839 | CHULANET | Chulalongkorn Universit 161.200.144.0/20 | AS3839 | CHULANET | Chulalongkorn Universit 161.200.160.0/19 | AS3839 | CHULANET | Chulalongkorn Universit 149.112.251.0/24 | AS3803 | UltraNet MA | US Robotics (NET-USR-1) 149.112.252.0/23 | AS3803 | UltraNet MA | US Robotics (NET-USR-1) 149.112.254.0/24 | AS3803 | UltraNet MA | US Robotics (NET-USR-1) 138.35.221.0/24 | AS3758 | SINGNET | Compaq (NET-CPQINTL) 144.141.4.0/22 | AS3739 | NEWNET | Shore Intermediate Main 163.249.43.0/24 | AS3739 | NEWNET | Commanding Officer Navy 163.249.53.0/24 | AS3739 | NEWNET | Commanding Officer Navy 163.249.54.0/24 | AS3739 | NEWNET | Commanding Officer Navy 163.249.57.0/24 | AS3739 | NEWNET | * 163.249.140.0/22 | AS3739 | NEWNET | * 163.249.160.0/21 | AS3739 | NEWNET | * 163.249.168.0/23 | AS3739 | NEWNET | * 163.249.170.0/24 | AS3739 | NEWNET | * 24.229.0.0/19 | AS3737 | PenTeleData Inc. (ASN-P | @Home Network (NETBLK-A 163.244.64.0/23 | AS3615 | DELL-BLK | Dell Computer Corporati 138.155.40.0/24 | AS3593 | Eastern Pennsylvania In | NCTC (NET-CISCO-BLOCK2) 163.12.23.0/24 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.24.0/21 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.32.0/19 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.64.0/18 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.64.0/20 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.81.0/24 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.82.0/23 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.84.0/22 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.88.0/21 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.96.0/19 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.128.0/21 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.136.0/22 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.144.0/20 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.160.0/19 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.192.0/21 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.240.0/20 | AS3576 | PREPnet-EAST | navy aviation supply of 163.12.0.0/23 | AS3576 | PREPnet-EAST | * 163.12.5.0/24 | AS3576 | PREPnet-EAST | * 163.12.6.0/23 | AS3576 | PREPnet-EAST | * 163.12.16.0/22 | AS3576 | PREPnet-EAST | * 163.12.21.0/24 | AS3576 | PREPnet-EAST | * 163.12.22.0/23 | AS3576 | PREPnet-EAST | * 163.12.22.0/24 | AS3576 | PREPnet-EAST | * 163.12.8.0/21 | AS3576 | PREPnet-EAST | 157.126.209.0/24 | AS3563 | Pilot Network Services, | J.M. Huber Corp. (NET-H 148.188.16.0/20 | AS3563 | Pilot Network Services, | Boehringer Ingelheim Ph 148.188.144.0/20 | AS3563 | Pilot Network Services, | Boehringer Ingelheim Ph 161.6.0.0/17 | AS3561 | MCI | Western Kentucky Univer 161.6.128.0/17 | AS3561 | MCI | Western Kentucky Univer 158.106.253.0/24 | AS3561 | MCI | VA Power Co. (NET-VANCP 165.237.108.0/24 | AS3561 | MCI | Time Warner Cable (NET- 165.237.220.0/24 | AS3561 | MCI | Time Warner Cable (NET- 167.166.248.0/21 | AS3561 | MCI | The Times Union (NET-TU 161.38.67.0/24 | AS3561 | MCI | The Art Institutes Inte 164.103.3.0/24 | AS3561 | MCI | Telecommunications Depa 163.49.131.0/24 | AS3561 | MCI | TDK Corporation (NET-TD 163.49.132.0/22 | AS3561 | MCI | TDK Corporation (NET-TD 163.49.136.0/22 | AS3561 | MCI | TDK Corporation (NET-TD 163.49.140.0/23 | AS3561 | MCI | TDK Corporation (NET-TD 163.49.142.0/24 | AS3561 | MCI | TDK Corporation (NET-TD 150.20.13.0/24 | AS3561 | MCI | Sumitomo Electric Hight 168.14.1.0/24 | AS3561 | MCI | State of Georgia/Board 168.14.2.0/23 | AS3561 | MCI | State of Georgia/Board 168.14.4.0/22 | AS3561 | MCI | State of Georgia/Board 168.14.8.0/21 | AS3561 | MCI | State of Georgia/Board 168.14.16.0/20 | AS3561 | MCI | State of Georgia/Board 166.150.0.0/18 | AS3561 | MCI | Service Provider Corpor 166.151.0.0/18 | AS3561 | MCI | Service Provider Corpor 166.147.64.0/18 | AS3561 | MCI | Service Provider Corpor 166.150.64.0/18 | AS3561 | MCI | Service Provider Corpor 166.151.64.0/18 | AS3561 | MCI | Service Provider Corpor 166.147.128.0/18 | AS3561 | MCI | Service Provider Corpor 166.147.192.0/18 | AS3561 | MCI | Service Provider Corpor 166.150.128.0/18 | AS3561 | MCI | Service Provider Corpor 166.150.192.0/18 | AS3561 | MCI | Service Provider Corpor 166.151.128.0/18 | AS3561 | MCI | Service Provider Corpor 166.151.192.0/18 | AS3561 | MCI | Service Provider Corpor 134.204.14.0/24 | AS3561 | MCI | Seagate Technology (NET 134.204.176.0/24 | AS3561 | MCI | Seagate Technology (NET 147.206.20.0/24 | AS3561 | MCI | Ochsner Foundation (NET 161.120.6.0/24 | AS3561 | MCI | Norton Company (NET-SGC 32.71.118.0/24 | AS3561 | MCI | Norsk Informasjonstekno 161.181.37.0/24 | AS3561 | MCI | Nordstrom, Inc. (NET-NO 164.100.64.0/20 | AS3561 | MCI | National Informatics Ce 164.100.81.0/24 | AS3561 | MCI | National Informatics Ce 164.100.82.0/23 | AS3561 | MCI | National Informatics Ce 164.100.84.0/22 | AS3561 | MCI | National Informatics Ce 164.100.88.0/21 | AS3561 | MCI | National Informatics Ce 164.100.96.0/19 | AS3561 | MCI | National Informatics Ce 164.100.167.0/24 | AS3561 | MCI | National Informatics Ce 134.241.50.0/24 | AS3561 | MCI | Massachusetts Higher Ed 134.241.51.0/24 | AS3561 | MCI | Massachusetts Higher Ed 134.241.52.0/24 | AS3561 | MCI | Massachusetts Higher Ed 134.241.167.0/24 | AS3561 | MCI | Massachusetts Higher Ed 134.241.168.0/24 | AS3561 | MCI | Massachusetts Higher Ed 134.241.169.0/24 | AS3561 | MCI | Massachusetts Higher Ed 134.241.170.0/24 | AS3561 | MCI | Massachusetts Higher Ed 134.241.232.0/24 | AS3561 | MCI | Massachusetts Higher Ed 159.179.0.0/24 | AS3561 | MCI | MIGROSBANK (NET-MIGROSB 166.38.40.0/24 | AS3561 | MCI | MCI Telecommunications 166.49.222.0/24 | AS3561 | MCI | MCI Telecommunications 166.49.223.0/24 | AS3561 | MCI | MCI Telecommunications 166.49.254.0/24 | AS3561 | MCI | MCI Telecommunications 166.49.255.0/24 | AS3561 | MCI | MCI Telecommunications 162.54.120.0/21 | AS3561 | MCI | MCI (Systems Engineerin 165.166.123.0/24 | AS3561 | MCI | Info Avenue Internet Se 165.108.130.0/23 | AS3561 | MCI | ITOCHU Corporation (NET 165.108.132.0/22 | AS3561 | MCI | ITOCHU Corporation (NET 165.108.136.0/21 | AS3561 | MCI | ITOCHU Corporation (NET 165.108.144.0/22 | AS3561 | MCI | ITOCHU Corporation (NET 165.108.148.0/23 | AS3561 | MCI | ITOCHU Corporation (NET 147.116.63.0/24 | AS3561 | MCI | Hercules, Inc. (NET-HER 147.116.64.0/23 | AS3561 | MCI | Hercules, Inc. (NET-HER 147.116.160.0/21 | AS3561 | MCI | Hercules, Inc. (NET-HER 147.116.168.0/22 | AS3561 | MCI | Hercules, Inc. (NET-HER 167.208.125.0/24 | AS3561 | MCI | Harcourt Brace & Co. (N 158.60.20.0/24 | AS3561 | MCI | Gage Marketing Group (N 137.170.136.0/24 | AS3561 | MCI | Freudenberg-NOK (NET-FN 136.140.9.0/24 | AS3561 | MCI | Ford Motor Company (NET 167.77.32.0/24 | AS3561 | MCI | Dequesne Light Company 164.84.105.0/24 | AS3561 | MCI | Cytec Industries Inc. ( 167.105.232.0/24 | AS3561 | MCI | Coca-Cola Enterprises ( 159.140.213.0/24 | AS3561 | MCI | Cerner Corporation (NET 159.140.254.0/24 | AS3561 | MCI | Cerner Corporation (NET 168.97.37.0/24 | AS3561 | MCI | Carlson Companies (NET- 135.40.66.0/24 | AS3561 | MCI | AT&T ITS (NETBLK-ATT-13 135.37.2.0/24 | AS3561 | MCI | AT&T ITS (NET-ATT-135-3 135.37.4.0/24 | AS3561 | MCI | AT&T ITS (NET-ATT-135-3 135.37.10.0/24 | AS3561 | MCI | AT&T ITS (NET-ATT-135-3 138.108.100.0/24 | AS3561 | MCI | A.C. Nielsen Company (N 24.92.0.0/19 | AS3561 | MCI | @Home Network (NETBLK-A 24.104.0.0/19 | AS3561 | MCI | @Home Network (NETBLK-A 24.124.0.0/18 | AS3561 | MCI | @Home Network (NETBLK-A 24.225.0.0/19 | AS3561 | MCI | @Home Network (NETBLK-A 24.92.32.0/19 | AS3561 | MCI | @Home Network (NETBLK-A 166.147.0.0/18 | AS3561 | MCI | * 132.235.204.0/24 | AS3561 | MCI | * 163.180.96.0/19 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer 163.180.128.0/17 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer 162.33.32.0/19 | AS3491 | CAIS Internet | RAM Communications Cons 162.33.64.0/18 | AS3491 | CAIS Internet | RAM Communications Cons 162.33.128.0/17 | AS3491 | CAIS Internet | RAM Communications Cons 143.222.116.0/24 | AS3407 | Interpath | Cummins Engine Company 149.172.150.0/24 | AS3402 | TerraNet, Inc. | Ikos Systems Incorporat 164.167.103.0/24 | AS3392 | Infinet Norfolk - MAE-E | Bureau of Medicine and 163.49.143.0/24 | AS3384 | New York Net | TDK Corporation (NET-TD 163.49.144.0/22 | AS3384 | New York Net | TDK Corporation (NET-TD 167.170.6.0/23 | AS3313 | I.Net S.p.A. | MEMC Electronic Materia 167.170.32.0/23 | AS3313 | I.Net S.p.A. | MEMC Electronic Materia 152.95.0.0/17 | AS3308 | TeliaNet Denmark | Dansk Data Electronik A 152.95.128.0/18 | AS3308 | TeliaNet Denmark | Dansk Data Electronik A 152.95.253.0/24 | AS3308 | TeliaNet Denmark | Dansk Data Electronik A 194.255.55.0/26 | AS3308 | TeliaNet Denmark | * 194.255.109.0/27 | AS3308 | TeliaNet Denmark | * 194.255.109.64/26 | AS3308 | TeliaNet Denmark | * 194.255.109.128/25 | AS3308 | TeliaNet Denmark | * 156.51.150.0/24 | AS3301 | TeliaNet Sweden | Vasakronan (NET-VASAKRO 156.51.204.0/24 | AS3301 | TeliaNet Sweden | Vasakronan (NET-VASAKRO 171.25.128.0/19 | AS3301 | TeliaNet Sweden | European Regional Inter 148.160.250.0/24 | AS3301 | TeliaNet Sweden | Boras Energi (NET-BS-EN 161.36.160.0/23 | AS3301 | TeliaNet Sweden | Black & Decker Corporat 146.75.251.0/24 | AS3301 | TeliaNet Sweden | * 146.75.254.0/24 | AS3301 | TeliaNet Sweden | * 164.10.140.0/24 | AS3301 | TeliaNet Sweden | * 164.10.27.128/26 | AS3301 | TeliaNet Sweden | * 149.212.96.0/20 | AS3293 | Telenor Internett - SN | Siemens-Nixdorf Informa 149.212.0.0/18 | AS3292 | Tele Danmark Internet E | Siemens-Nixdorf Informa 193.162.145.128/30 | AS3292 | Tele Danmark Internet E | European Regional Inter 160.97.224.0/19 | AS3269 | TELECOM ITALIA | Universita' della Calab 193.125.154.20/30 | AS3267 | RUNNet | European Regional Inter 194.85.40.44/30 | AS3267 | RUNNet | * 194.85.40.52/30 | AS3267 | RUNNet | * 194.85.40.56/30 | AS3267 | RUNNet | * 194.85.40.58/32 | AS3267 | RUNNet | * 194.85.40.229/32 | AS3267 | RUNNet | * 152.95.252.0/24 | AS3240 | Sektornet, DK Ministry | Dansk Data Electronik A 139.160.64.0/22 | AS3215 | RAIN | Merlin Gerin (NET-MGLAN 171.18.1.0/24 | AS3215 | RAIN | European Regional Inter 161.132.116.0/22 | AS3132 | Red Cientifica Peruana | Red Cientifica Peruana 165.212.158.0/24 | AS2941 | CSCNS-AS | USA.NET, Inc. (NET-USAN 165.212.230.0/24 | AS2941 | CSCNS-AS | USA.NET, Inc. (NET-USAN 160.92.129.0/24 | AS2917 | OLEANE - UUNET PIPEX In | Axime S.A. (NET-SEGIN) 149.244.16.0/21 | AS2871 | Internet Services GmbH | Knorr-Bremse AG, Muench 146.193.60.0/22 | AS2860 | IP Global, Informatica | INESC (NET-INESC) 145.17.100.0/24 | AS2856 | BTnet UK Regional netwo | Unilever Research Labor 143.252.80.0/24 | AS2856 | BTnet UK Regional netwo | News International (NET 171.30.170.0/24 | AS2856 | BTnet UK Regional netwo | BR Telecommunications L 132.146.220.0/24 | AS2856 | BTnet UK Regional netwo | * 139.44.13.0/24 | AS2764 | connect.com.au pty ltd | Port of Melbourne Autho 159.142.0.0/18 | AS2714 | GSA_GOV | General Services Admini 159.142.64.0/18 | AS2714 | GSA_GOV | General Services Admini 159.142.128.0/18 | AS2714 | GSA_GOV | General Services Admini 159.142.192.0/18 | AS2714 | GSA_GOV | General Services Admini 144.127.110.0/23 | AS2707 | WEC | Elkem A/S (NET-ELKEM-NO 144.127.112.0/20 | AS2707 | WEC | Elkem A/S (NET-ELKEM-NO 144.127.128.0/19 | AS2707 | WEC | Elkem A/S (NET-ELKEM-NO 144.127.160.0/21 | AS2707 | WEC | Elkem A/S (NET-ELKEM-NO 144.127.168.0/23 | AS2707 | WEC | Elkem A/S (NET-ELKEM-NO 145.248.112.0/24 | AS2706 | HKSUPER | No match for "145.248.0 164.53.55.0/24 | AS2706 | HKSUPER | National Australia Bank 134.6.160.0/22 | AS2706 | HKSUPER | Maxtor Corporation (NET 134.6.180.0/24 | AS2706 | HKSUPER | Maxtor Corporation (NET 145.248.155.0/24 | AS2706 | HKSUPER | * 145.248.156.0/23 | AS2706 | HKSUPER | * 145.248.159.0/24 | AS2706 | HKSUPER | * 145.248.161.0/24 | AS2706 | HKSUPER | * 145.248.165.0/24 | AS2706 | HKSUPER | * 145.248.181.0/24 | AS2706 | HKSUPER | * 9.20.0.0/17 | AS2686 | Autonomous System numbe | IBM Corporation (NET-IB 155.39.191.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET 155.39.230.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET 32.96.0.0/16 | AS2685 | IBM Global Network - US | Norsk Informasjonstekno 131.114.192.0/18 | AS2598 | Consiglio Nazionale del | * 137.98.204.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.208.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.209.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.223.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.224.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.225.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.235.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.239.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.240.0/24 | AS2571 | DHLNET | DHL Systems, Inc. (NET- 137.98.96.0/24 | AS2571 | DHLNET | * 137.98.97.0/24 | AS2571 | DHLNET | * 137.98.98.0/24 | AS2571 | DHLNET | * 137.98.99.0/24 | AS2571 | DHLNET | * 137.98.100.0/24 | AS2571 | DHLNET | * 137.98.101.0/24 | AS2571 | DHLNET | * 137.98.102.0/24 | AS2571 | DHLNET | * 137.98.196.0/24 | AS2571 | DHLNET | * 137.98.200.0/24 | AS2571 | DHLNET | * 137.98.203.0/24 | AS2571 | DHLNET | * 159.221.132.0/24 | AS2551 | NETCOM On-line Communic | * 141.227.111.0/24 | AS2529 | Demon Internet Ltd | Societe Nationale Elf A 156.114.200.0/24 | AS2529 | Demon Internet Ltd | Baring Securities Limit 160.21.12.0/22 | AS2514 | NTT_PC_communications | * 142.5.35.0/24 | AS2493 | iSTAR Internet, Inc. | Transcandada Pipelines 142.70.168.0/23 | AS2493 | iSTAR Internet, Inc. | Noranda, Inc. (NET-NORA 162.73.252.0/24 | AS2493 | iSTAR Internet, Inc. | Information Technology 162.73.253.0/24 | AS2493 | iSTAR Internet, Inc. | Information Technology 162.73.254.0/24 | AS2493 | iSTAR Internet, Inc. | Information Technology 155.194.200.0/24 | AS2493 | iSTAR Internet, Inc. | City of Kitchener (NET- 137.15.34.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 137.15.35.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 137.15.39.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 137.15.41.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 137.15.43.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 137.15.44.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 137.15.52.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 137.15.54.0/24 | AS2493 | iSTAR Internet, Inc. | Central Mapping Agency 142.101.32.0/24 | AS2493 | iSTAR Internet, Inc. | Canadian Research Netwo 163.155.120.0/24 | AS2493 | iSTAR Internet, Inc. | Canada Mortgage and Hou 142.70.171.0/24 | AS2493 | iSTAR Internet, Inc. | * 131.232.193.0/24 | AS2493 | iSTAR Internet, Inc. | * 161.173.243.0/24 | AS2386 | INS-AS | Wal-Mart Stores, Inc. ( 145.247.128.0/18 | AS2120 | DAXnet (Tele 3) | No match for "145.247.0 146.192.0.0/17 | AS2119 | Telenor Internett, Norw | Allianse Informasionssy 146.192.128.0/17 | AS2116 | EUnet Norway | Allianse Informasionssy 152.168.184.0/21 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.192.0/21 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.200.0/21 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.208.0/22 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.216.0/22 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.228.0/22 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.240.0/21 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.248.0/22 | AS2056 | AOL-AS | America Online, Inc (NE 152.168.32.0/20 | AS2056 | AOL-AS | * 152.168.56.0/21 | AS2056 | AOL-AS | * 152.168.64.0/21 | AS2056 | AOL-AS | * 152.168.72.0/21 | AS2056 | AOL-AS | * 152.168.80.0/20 | AS2056 | AOL-AS | * 152.168.128.0/21 | AS2056 | AOL-AS | * 152.168.136.0/21 | AS2056 | AOL-AS | * 152.168.160.0/21 | AS2056 | AOL-AS | * 152.168.168.0/21 | AS2056 | AOL-AS | * 152.168.180.0/22 | AS2056 | AOL-AS | * 136.198.82.0/24 | AS2042 | MIMOS BHD | Victor Company of Japan 144.199.161.0/24 | AS2042 | MIMOS BHD | Sarawak Shell Berhad (N 157.151.64.0/19 | AS2041 | CRL-GATE | Information Access Tech 169.24.186.0/24 | AS2019 | JP MORGAN | J.P. Morgan & Co. (NETB 161.231.0.0/21 | AS2011 | WACHOVIA | Wachovia Operational Se 161.231.8.0/21 | AS2011 | WACHOVIA | Wachovia Operational Se 161.231.248.0/21 | AS2011 | WACHOVIA | Wachovia Operational Se 164.52.249.0/24 | AS1982 | Northwest Nexus, Inc. | Associated Grocers, Inc 140.35.155.0/29 | AS1913 | DLA4 | Defense Information Sys 159.77.149.0/24 | AS1913 | DLA4 | DISA-EUROPE/DEKC (NET-D 153.98.0.0/17 | AS1891 | EUnet Belgium AS | * 157.25.64.0/23 | AS1887 | NASK | Advanced Technology Man 161.51.224.0/20 | AS1849 | UUNET UK (PIPEX, Public | The M.W. Kellogg Compan 148.176.225.0/24 | AS1849 | UUNET UK (PIPEX, Public | ScottishPower (NET-SCOT 137.33.165.0/24 | AS1849 | UUNET UK (PIPEX, Public | Kemira Group (HKIISA-HS 137.33.166.0/24 | AS1849 | UUNET UK (PIPEX, Public | Kemira Group (HKIISA-HS 170.194.51.0/24 | AS1849 | UUNET UK (PIPEX, Public | Deloitte Touche Tohmats 159.245.84.0/22 | AS1849 | UUNET UK (PIPEX, Public | * 159.245.104.0/22 | AS1849 | UUNET UK (PIPEX, Public | * 150.185.128.0/18 | AS1800 | ICM-Atlantic | Consejo Nacional de Inv 150.185.192.0/18 | AS1800 | ICM-Atlantic | Consejo Nacional de Inv 169.130.31.0/24 | AS1785 | NYSERNet Backbone | Sprint, Business Servic 169.130.54.0/24 | AS1785 | NYSERNet Backbone | Sprint, Business Servic 149.212.64.0/20 | AS1759 | Telecom Finland iNET | Siemens-Nixdorf Informa 9.2.0.0/16 | AS1747 | IBM Watson, Yorktown He | IBM Corporation (NET-IB 137.33.254.0/24 | AS1741 | FUNET autonomous system | Kemira Group (HKIISA-HS 166.50.243.0/24 | AS1691 | BCTEL | MCI Telecommunications 166.50.244.0/22 | AS1691 | BCTEL | MCI Telecommunications 166.50.248.0/23 | AS1691 | BCTEL | MCI Telecommunications 166.50.250.0/24 | AS1691 | BCTEL | MCI Telecommunications 24.48.0.0/18 | AS1677 | ANS Hartford - CNSS 53 | @Home Network (NETBLK-A 152.175.0.0/17 | AS1668 | AOL-PRIMEHOST | America Online, Inc (NE 152.164.0.0/21 | AS1667 | ANS-DC2 | * 157.184.150.0/24 | AS1330 | ANS St. Louis - DNSS 83 | Lexmark International I 149.112.249.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1) 149.112.246.0/24 | AS1327 | ANS Washington D.C. - D | * 149.112.247.0/24 | AS1327 | ANS Washington D.C. - D | * 149.112.248.0/24 | AS1327 | ANS Washington D.C. - D | * 198.83.135.36/30 | AS1325 | ANS Cleveland - DNSS 43 | Advanced Network and Se 24.48.33.0/24 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A 24.48.34.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A 24.48.36.0/22 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A 24.48.40.0/21 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A 24.48.48.0/22 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A 24.48.52.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A 24.48.54.0/24 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A 152.182.0.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.4.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.8.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.12.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.16.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.20.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.24.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.28.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.32.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.36.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.38.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.40.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.44.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.48.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.52.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.56.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.60.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.64.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.66.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.68.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.70.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.72.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.76.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.80.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.84.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.86.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.88.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.92.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.96.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.12.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.16.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.20.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.24.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.28.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.32.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.36.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.38.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.40.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.44.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.48.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.52.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.56.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.60.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.64.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.66.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.68.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.70.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.72.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.76.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.80.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.84.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.86.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.88.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.92.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.96.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.100.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.182.104.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.100.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.104.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.106.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.108.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.110.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.112.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.116.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.118.0/24 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.120.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.124.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.128.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.132.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.136.0/23 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.144.0/22 | AS1323 | ANS Chicago - DNSS 27 | ANS CO+RE Systems, Inc. 152.190.0.0/22 | AS1323 | ANS Chicago - DNSS 27 | * 152.190.4.0/22 | AS1323 | ANS Chicago - DNSS 27 | * 152.190.8.0/22 | AS1323 | ANS Chicago - DNSS 27 | * 149.112.96.0/24 | AS1323 | ANS Chicago - DNSS 27 | * 149.112.150.0/24 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.106.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.108.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.110.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.112.0/22 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.116.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.118.0/24 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.120.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.124.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.128.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.132.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.136.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.182.144.0/22 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.192.0/21 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.200.0/22 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.208.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.212.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.220.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.224.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.228.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.240.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.183.248.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.192.0/21 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.200.0/22 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.208.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.212.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.220.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.224.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.228.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.240.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 152.191.248.0/23 | AS1323 | ANS Chicago - DNSS 27 | * 160.104.128.0/17 | AS1290 | PSINet UK Ltd. | Tadpole Technology, Inc 192.151.12.171/32 | AS1290 | PSINet UK Ltd. | Hewlett Packard (NET-HP 195.130.192.64/26 | AS1290 | PSINet UK Ltd. | European Regional Inter 145.227.75.192/26 | AS1290 | PSINet UK Ltd. | CFM Network Services (N 193.23.5.0/28 | AS1273 | ECRC Network | European Regional Inter 193.23.5.16/28 | AS1273 | ECRC Network | European Regional Inter 193.23.5.32/30 | AS1273 | ECRC Network | European Regional Inter 193.23.5.48/30 | AS1273 | ECRC Network | European Regional Inter 193.23.5.64/30 | AS1273 | ECRC Network | European Regional Inter 193.23.5.68/30 | AS1273 | ECRC Network | European Regional Inter 193.23.5.72/30 | AS1273 | ECRC Network | European Regional Inter 193.23.5.96/28 | AS1273 | ECRC Network | European Regional Inter 193.23.5.128/28 | AS1273 | ECRC Network | European Regional Inter 193.23.5.144/28 | AS1273 | ECRC Network | European Regional Inter 193.23.5.160/28 | AS1273 | ECRC Network | European Regional Inter 193.23.5.208/28 | AS1273 | ECRC Network | European Regional Inter 193.189.231.1/32 | AS1273 | ECRC Network | European Regional Inter 141.1.13.0/24 | AS1273 | ECRC Network | European Computer Resea 192.121.158.108/30 | AS1273 | ECRC Network | Ebone Consortium (NET-A 146.75.253.0/24 | AS1257 | SWIPnet Swedish IP Netw | * 147.27.1.0/24 | AS1241 | FORTHnet | Technical University of 147.27.2.0/24 | AS1241 | FORTHnet | Technical University of 147.27.5.0/24 | AS1241 | FORTHnet | Technical University of 147.27.15.0/24 | AS1241 | FORTHnet | Technical University of 147.27.20.0/24 | AS1241 | FORTHnet | Technical University of 24.235.0.0/19 | AS1239 | SprintLink Backbone | @Home Network (NETBLK-A 163.180.0.0/18 | AS1237 | SERI Autonomous System | Kyunghee Univ. Computer 163.180.64.0/19 | AS1237 | SERI Autonomous System | Kyunghee Univ. Computer 164.112.249.0/24 | AS1221 | AARNET-AS | Queensland Police Servi 139.163.18.0/24 | AS1221 | AARNET-AS | QANTAS Airways Limited 139.163.82.0/24 | AS1221 | AARNET-AS | QANTAS Airways Limited 159.99.0.0/17 | AS1221 | AARNET-AS | Honeywell Ltd Australia 159.99.128.0/19 | AS1221 | AARNET-AS | Honeywell Ltd Australia 159.99.160.0/21 | AS1221 | AARNET-AS | Honeywell Ltd Australia 159.153.200.0/24 | AS1221 | AARNET-AS | Electronic Arts, Inc. ( 158.155.24.0/22 | AS1221 | AARNET-AS | Computer Generation (NE 144.55.12.0/24 | AS1221 | AARNET-AS | Australian Securities C 150.207.2.0/24 | AS1221 | AARNET-AS | AWA Defence Indushether they are solving the right problem and whether the context of the situation was considered when making the problem statement. ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ******************************************************** tries 161.50.48.0/24 | AS1221 | AARNET-AS | ACT Institute of TAFE ( 24.192.0.0/18 | AS1221 | AARNET-AS | @Home Network (NETBLK-A 162.27.201.0/24 | AS1136 | Unisource Internet Serv | R. R. Donnelley & Sons 139.162.128.0/17 | AS1136 | Unisource Internet Serv | Nedlloyd Computer Servi 163.175.152.0/21 | AS1136 | Unisource Internet Serv | CCN Automatisering (NET 129.81.10.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.18.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.30.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.34.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.38.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.40.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.48.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.58.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.66.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.174.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.184.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.186.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.200.0/24 | AS10349 | TULANE | Tulane University (NET- 129.81.225.0/24 | AS10349 | TULANE | Tulane University (NET- 24.108.0.0/18 | AS852 | AGT Advance Communicati | @Home Network (NETBLK-A 142.57.1.0/24 | AS816 | UUNET Canada (ASN-UUNET | The Law Society of Uppe 142.218.30.0/24 | AS816 | UUNET Canada (ASN-UUNET | George Weston Ltd. (NET 24.226.0.0/24 | AS816 | UUNET Canada (ASN-UUNET | @Home Network (NETBLK-A 159.254.164.0/24 | AS816 | UUNET Canada (ASN-UUNET | * 142.77.40.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.63.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.70.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.80.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.100.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.180.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.181.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.203.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.246.0/24 | AS813 | UUNET Canada (ASN-UUNET | UUNET Canada Incorporat 142.77.1.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 142.77.11.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 142.77.12.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 142.77.15.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 142.77.27.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 142.77.31.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 142.77.34.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 142.77.39.0/24 | AS813 | UUNET Canada (ASN-UUNET | * 24.112.32.0/19 | AS812 | Rogers Communications I | @Home Network (NETBLK-A 24.112.64.0/19 | AS812 | Rogers Communications I | @Home Network (NETBLK-A 24.112.96.0/20 | AS812 | Rogers Communications I | @Home Network (NETBLK-A 24.113.32.0/19 | AS812 | Rogers Communications I | @Home Network (NETBLK-A 24.112.112.0/20 | AS812 | Rogers Communications I | @Home Network (NETBLK-A 160.5.0.0/24 | AS786 | The JANET IP Service | * 163.1.0.0/24 | AS786 | The JANET IP Service | * 168.86.1.0/24 | AS701 | Alternet | United Artists Theater 160.104.0.0/17 | AS701 | Alternet | Tadpole Technology, Inc 182.65.17.0/24 | AS701 | Alternet | No match for "182.65.0. 182.65.18.0/24 | AS701 | Alternet | No match for "182.65.0. 134.6.77.0/24 | AS701 | Alternet | Maxtor Corporation (NET 158.118.10.0/24 | AS701 | Alternet | Matsushita Electric Wor 158.118.51.0/24 | AS701 | Alternet | Matsushita Electric Wor 167.152.251.0/24 | AS701 | Alternet | EMI Communications Corp 134.33.100.0/24 | AS701 | Alternet | Codex Corporation (NET- 164.218.95.0/24 | AS701 | Alternet | Bureau of Naval Personn 155.134.60.0/24 | AS701 | Alternet | Best Foods Baking Group 170.253.124.0/23 | AS701 | Alternet | Arthur Andersen & Co., 24.96.9.0/24 | AS701 | Alternet | @Home Network (NETBLK-A 155.7.0.0/19 | AS701 | Alternet | * 155.7.40.0/23 | AS701 | Alternet | * 149.20.64.0/24 | AS701 | Alternet | * 130.188.2.0/24 | AS565 | VTT autonomous system | Technical Research Cent 130.188.170.0/24 | AS565 | VTT autonomous system | Technical Research Cent 130.188.250.0/24 | AS565 | VTT autonomous system | Technical Research Cent 131.117.0.0/17 | AS559 | SWITCH, Swiss Academic | * 53.64.4.0/22 | AS517 | Xlink | cap debis ccs (NET-DB-N 143.93.32.0/19 | AS517 | Xlink | Fachhochschule Rheinlan 153.96.80.0/21 | AS517 | Xlink | * 153.96.92.0/24 | AS517 | Xlink | * 153.96.230.0/24 | AS517 | Xlink | * 153.98.128.0/17 | AS517 | Xlink | * 129.181.208.0/21 | AS517 | Xlink | * 129.181.216.0/22 | AS517 | Xlink | * 128.102.32.0/20 | AS297 | NASA Internet | NASA Ames Research Cent 137.39.250.24/30 | AS174 | Performance Systems Int | UUNET Technologies, Inc 38.1.2.0/24 | AS174 | Performance Systems Int | Performance Systems Int 38.1.3.0/24 | AS174 | Performance Systems Int | Performance Systems Int 204.6.106.0/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.106.4/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.116.0/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.116.2/32 | AS174 | Performance Systems Int | Performance Systems Int 204.6.117.0/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.117.4/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.118.0/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.119.0/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.119.8/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.119.12/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.119.16/30 | AS174 | Performance Systems Int | Performance Systems Int 204.6.119.25/32 | AS174 | Performance Systems Int | Performance Systems Int 204.6.119.29/32 | AS174 | Performance Systems Int | Performance Systems Int 204.6.119.36/30 | AS174 | Performance Systems Int | Performance Systems Int 128.145.228.0/24 | AS174 | Performance Systems Int | Performance Systems Int 199.99.247.32/27 | AS174 | Performance Systems Int | Performance Systems Int 136.161.17.0/24 | AS174 | Performance Systems Int | PSI Network One (NET-PS 149.127.6.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.35.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.37.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.39.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.40.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.41.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.42.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.43.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.44.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.45.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.46.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.47.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.48.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.106.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.137.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.139.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.140.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 149.127.141.0/24 | AS174 | Performance Systems Int | PSI (NET-PSINET-B-127) 206.157.77.168/30 | AS174 | Performance Systems Int | MCI Internet Services ( 199.99.177.0/27 | AS174 | Performance Systems Int | Hitachi Telecom (NET-HI 162.121.244.0/22 | AS114 | Sesquinet Primary AS | St. Luke's Episcopal Ho 129.207.44.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.45.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.47.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.50.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.55.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.60.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.63.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.65.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.70.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.75.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.80.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.81.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.82.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.85.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.87.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.90.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.93.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.100.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.105.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.106.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.107.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.110.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.115.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.123.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.125.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.133.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.145.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.146.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.200.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.210.0/24 | AS114 | Sesquinet Primary AS | Prairie View A&M Univer 129.207.10.0/24 | AS114 | Sesquinet Primary AS | * 129.207.15.0/24 | AS114 | Sesquinet Primary AS | * 129.207.25.0/24 | AS114 | Sesquinet Primary AS | * 129.207.30.0/24 | AS114 | Sesquinet Primary AS | * 129.207.32.0/24 | AS114 | Sesquinet Primary AS | * 129.207.35.0/24 | AS114 | Sesquinet Primary AS | * 129.207.37.0/24 | AS114 | Sesquinet Primary AS | * 129.207.40.0/24 | AS114 | Sesquinet Primary AS | * 129.207.43.0/24 | AS114 | Sesquinet Primary AS | * 129.207.17.0/24 | AS114 | Sesquinet Primary AS | 128.174.209.128/25 | AS38 | University of Illinois | University of Illinois, 207.227.0.216/30 | AS38 | University of Illinois | * 166.4.174.0/24 | AS1 | BBNPLANET | US Forest Service (NETB 161.38.1.0/24 | AS1 | BBNPLANET | The Art Institutes Inte 161.38.27.0/24 | AS1 | BBNPLANET | The Art Institutes Inte 161.38.37.0/24 | AS1 | BBNPLANET | The Art Institutes Inte 161.38.57.0/24 | AS1 | BBNPLANET | The Art Institutes Inte 130.105.100.0/24 | AS1 | BBNPLANET | Open Software Foundatio 189.93.55.0/24 | AS1 | BBNPLANET | No match for "189.93.0. 161.223.220.0/22 | AS1 | BBNPLANET | Indian Health Service ( 161.223.224.0/24 | AS1 | BBNPLANET | Indian Health Service ( 144.175.1.0/24 | AS1 | BBNPLANET | Hood College (NET-HOOD- 142.218.120.0/24 | AS1 | BBNPLANET | George Weston Ltd. (NET 163.244.100.0/24 | AS1 | BBNPLANET | Dell Computer Corporati 159.87.34.0/24 | AS1 | BBNPLANET | Arizona State Governmen 135.16.150.0/24 | AS1 | BBNPLANET | AT&T ITS (NET-ATT-135-1
On Tue, Jul 29, 1997 at 09:33:25PM -0500, Thomas H. Ptacek wrote:
No, it *is* immune to all variants on *THAT* attack. It isn't immune to other sorts of attacks.
I think you are speaking in fairly blatant factual error here, or we are in micommunication with respect to the meaning of the word "variant".
And to think that _I_ was getting yelled at last week. Furrfu! I'm having no trouble at all understanding Messrs. Vixie and Metzger. Why, Thomas, do _you_ seem to be unable to get it? Do you have, perhaps, (say it softly) a hidden agenda? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
so a statement from paul that the internet is effectively broken until DNSSEC is acceptable to you even if there are known ways to combat known attacks? stop worshipping long enough to think about the ramifications of this. ben On Tue, 29 Jul 1997, Perry E. Metzger wrote:
Paul has made it clear that there are holes in the DNS protocols that cannot be fixed without DNSSEC. He isn't papering anything over -- he is merely describing reality. If you want to be sarcastic to him for doing his best and being honest in public, well, that's fine, but frankly I think you are doing the community a serious disservice by attacking Paul.
.pm
"Thomas H. Ptacek" writes:
BIND 4.9.6 and 8.1.1 are immune to all known attacks, including the one
[ splice ]
I know of attacks we are not immune to, which cannot be stopped without
Um. I hate to play semantic games, but if you know of attacks that BIND 8.1.1 is not immune to, then BIND 8.1.1 is not immune to all known attacks.
Since this is not a security list, I'll refrain from (rhetorically) informing you that history doesn't back up your assertion of the existence of "holes that only the good guys know".
Oops. Sorry about that.
Thanks for clearing this up!
---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
Ben Black writes:
so a statement from paul that the internet is effectively broken until DNSSEC is acceptable to you even if there are known ways to combat known attacks?
I will be charitable and not comment on your ancestry or intelligence at this time. I will only say that there *are* no ways to combat the attacks Paul is speaking of. All the attacks that can be defended against without DNSSEC are properly handled by Bind 8.1.1. The attacks that cannot be stopped can't be stopped, period. Paul didn't design the DNS and you don't get to change history to fix existing problems after the fact. What we should be doing is deploying DNSSEC, of course. If people would donate sufficient funds to ISC I suspect that would happen faster -- as it stands, Paul develops BIND out of money from his own pocket, and I don't get the impression he's drowning in cash.
stop worshipping long enough to think about the ramifications of this.
The major ramification appears to be that you don't have the sense to keep from speaking about topics you don't understand. This is an ever so common failing. Perry
Ben, At 10:30 PM 7/29/97 -0400, Ben Black wrote:
so a statement from paul that the internet is effectively broken until DNSSEC is acceptable to you even if there are known ways to combat known attacks?
stop worshipping long enough to think about the ramifications of this.
Reponsible participation in public discussion is a difficult challenge for even the most capable contributor. For others, the challenge is quite basic. They must listen carefully. They must consider carefully. They must stay on the topic. They must use professional language and avoid ad hominem distractions. The fact that the security on your house is not optimal, it does not mean that your house has no security. The fact that there are attacks which are still feasible on the DNS does not mean that the DNS doesn't work. ("Broken" means doesn't work, in case there is confusion about your use of language.) So please note that your response to this thread reduce it to an inaccurate assessment. Given the importance of the DNS and the difficulty which the general public has dealing with network security issues, it would be highly irresponsible to propagate inaccurate statements like the one above. d/ -------------------- Dave Crocker Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org
Noone in the security field has any right to expect any implementation of DNS to be secure until DNSSEC is widely implemented.
this statement bothers me. certainly without DNSSEC there can be no *assurances* of security, but there is a gaping chasm between the current system and DNSSEC that could be closed significantly with proper design. simply stating that until DNSSEC arrives these attacks are going to be allowed is a copout. ben
I'm sorry if something I said misled you to believe otherwise.
So BIND 8.1.1 is NOT "immune" to the poisoned resource-record attack? I ask because you specifically stated that it was. Sorry to nag, I'd just like to see this clarified to the operations community.
Again, thanks for your time and patience!
---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
if you want to know how to configure your router, hit "D" now.
Noone in the security field has any right to expect any implementation of DNS to be secure until DNSSEC is widely implemented.
this statement bothers me. certainly without DNSSEC there can be no *assurances* of security, but there is a gaping chasm between the current system and DNSSEC that could be closed significantly with proper design.
please explain further. perhaps i've been in this trench too long, i'm just not getting what you mean. (how do i configure my router for that?)
simply stating that until DNSSEC arrives these attacks are going to be allowed is a copout.
better yet, send diffs. perhaps the bind-workers group are all idiots and this could actually be done better if we'd just rewrite it all in C++. jim fleming keeps saying that that's the problem. perhaps you and he could work together on a robust replacement for BIND.
At 06:23 PM 7/29/97 -0700, Paul A Vixie wrote:
if you want to know how to configure your router, hit "D" now.
Is not knowing how to configure your router for a given issue an operational problem? `[8-)) Speaking of router config questions, ... {waiting on permission from moderator to ask a router config question}
well, the router comment wasn't mine so i don't think it really needs explanation. as for the childish attempt to imply that somehow the statement of a problem is tantamount to insanity, well...i guess i thought you could do better. there *is* a problem with query ID spoofing, as you have known for years, *but* there is a way to significantly harden a nameserver against this sort of attack *without* going against RFC and without rewriting it in C++ with the help of Jim Phlegming. i did not come up with the algorithm to win the spoof race, so i will leave that in the capable hands of tom ptacek. ben ps - perry, you can get off your knees now. On Tue, 29 Jul 1997, Paul A Vixie wrote:
if you want to know how to configure your router, hit "D" now.
Noone in the security field has any right to expect any implementation of DNS to be secure until DNSSEC is widely implemented.
this statement bothers me. certainly without DNSSEC there can be no *assurances* of security, but there is a gaping chasm between the current system and DNSSEC that could be closed significantly with proper design.
please explain further. perhaps i've been in this trench too long, i'm just not getting what you mean. (how do i configure my router for that?)
simply stating that until DNSSEC arrives these attacks are going to be allowed is a copout.
better yet, send diffs. perhaps the bind-workers group are all idiots and this could actually be done better if we'd just rewrite it all in C++. jim fleming keeps saying that that's the problem. perhaps you and he could work together on a robust replacement for BIND.
On Tue, 29 Jul 1997, Ben Black wrote:
[...] but there is a gaping chasm between the current system and DNSSEC that could be closed significantly with proper design.
Well, in the words of internet, fidonet, and other developers worldwide.... Send Code <tm> If you have "proper design" that significantly closes the holes, I'm sure we'd all, Mr. Vixie included, appreciate your patch files which illustrate proper design.
simply stating that until DNSSEC arrives these attacks are going to be allowed is a copout.
Simply stating that there's a better way without Sending Code is a copout.
yes, how dare i not say a word about a problem before fixing it? what scum i am. gimme a break. On Tue, 29 Jul 1997, Lon R. Stockton, Jr. wrote:
On Tue, 29 Jul 1997, Ben Black wrote:
[...] but there is a gaping chasm between the current system and DNSSEC that could be closed significantly with proper design.
Well, in the words of internet, fidonet, and other developers worldwide....
Send Code <tm>
If you have "proper design" that significantly closes the holes, I'm sure we'd all, Mr. Vixie included, appreciate your patch files which illustrate proper design.
simply stating that until DNSSEC arrives these attacks are going to be allowed is a copout.
Simply stating that there's a better way without Sending Code is a copout.
In article <Pine.LNX.3.91.970729213405.4111A-100000@luna.moonstar.com>, you wrote:
Simply stating that there's a better way without Sending Code is a copout.
I realize I'm dragging this on, and I apologize, but: It's totally valid to report a problem that affects the operations community without providing a fix. Knowledge of the fact that a problem exists is valuable, even without a cookbook resolution. In this case, a few people (some not on this list) would like the operations community to realize that there are, in fact, some very doable attacks that remain unaddressed by BIND 8.1.1. -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));
At 01:57 AM 07/30/97 -0000, tqbf@smtp.enteract.com wrote:
In this case, a few people (some not on this list) would like the operations community to realize that there are, in fact, some very doable attacks that remain unaddressed by BIND 8.1.1.
Sure, smart guy. And there are also issues with IP packets which are passed across untrusted nodes in the Internet. What exactly is your point? - paul
Sure, smart guy. And there are also issues with IP packets which are passed across untrusted nodes in the Internet. What exactly is your point?
Why are you asking me questions after having placed me in your killfile? To answer your question briefly: there are fixes for both the poisoned-RR problem (extensive validity checking and non-caching cut-through responses), as explained by Johannes Erdfelt, and there are fixes for the guessable-ID problem (randomized query IDs backed up by server-survival assurances using "cookie" queries, along with a attack detection mechanism that reduces the entire problem to a denial-of-service attack). Neither of these involve DNSSEC. You are being told that the Internet is essentially broken until DNSSEC is implemented. Some people feel this is not the case. I am one of them. You have my apologies if my means of expressing this seem unacceptable to you. Thanks for taking the time to write! ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
I'm in receipt of some private e-mail from Thomas Ptacek on this topic, and I feel that to the extent this thread deserves any further attention, private e-mail is a more appropriate forum than the NANOG mailing list. To give the flavour of what such a discussion would look like, so that those who aren't part of it won't feel they are missing anything, I'll respond to Thomas Ptacek's latest (and last, perhaps?) NANOG message:
To answer your question briefly: there are fixes for both the poisoned-RR problem (extensive validity checking and non-caching cut-through responses), as explained by Johannes Erdfelt,
Those patches were against BIND-4 as I recall, and have not been updated or even discussed since BIND-8.1.1 and BIND-4.9.6 came out. If there are "variants" of what you're here calling the "poisoned-RR problem" (which makes it sound a little like what AlterNIC was doing), which have been shown to work against BIND-8.1.1 or BIND-4.9.6, I have *not* been shown. What I would like to see is at least a typescript of "dig" commands which demonstrate the vulnerability, though I'm willing to accept a line by line description of how the code can be misdirected. Based on the speed with which the community responded to the MD4 challenge, I can only assume that if a "white hat" learns of a way BIND-8.1.1 is vulnerable, they will beat a pathway to the press and to my inbox.
and there are fixes for the guessable-ID problem (randomized query IDs backed up by server-survival assurances using "cookie" queries, along with a attack detection mechanism that reduces the entire problem to a denial-of-service attack). Neither of these involve DNSSEC.
Here, I'd like to quote from the Lout source code for my Usenix Security Symposium (#5, Salt Lake City, September 1995) paper, which is online in PostScript(tm) form at <URL:ftp://ftp.vix.com/pri/vixie/bindsec.psf>: @SubSection @Title{Query @S{ID} Prediction} @Begin @DP With only 16 bits worth of query @S{ID} and 16 bits worth of @S{UDP} port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available @S{BIND} source code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all. In an extended dialogue with one of the authors of a recent BugTraq report on BIND security, I suggested that as long as resolvers do not scoreboard *and* cryptographically randomize their query ID's, and as long as routers do not do source-address verification, and as long as hosts do not prevent source address 127.0.0.1 from being used on packets arriving from the net, it *does*not*matter* what we do in the name servers. In fact, I have working code for a scoreboarding resolver, but it requires a 64Kbit bitmap as well as a *lot* of dynamic memory to do "the right thing". (It's also asynchronous with its own "eventlib" context, but it's not a thing you'd want to run on PC grade machine or workstation.) 10 million instruct- ions and 1 million data references seems too expensive for a hostname lookup. And if you followed all of that you now know why I proposed TSIG. The Point: Any security conscious person who reads RFC 1034 and RFC 1035 will come up with a half dozen ideas for how to pervert any RFC-compliant name service. Only two of the easy half dozen will work in practice, the others just sound like good ideas. I am always willing to accept diffs and trouble reports about BIND, and the ones which solve real problems become part of official patches and releases. If anybody has a suggestion as to how I can be more reasonable than that, I am listening hard.
On Wed, Jul 30, 1997 at 01:57:07AM -0000, tqbf@smtp.enteract.com wrote:
In article <Pine.LNX.3.91.970729213405.4111A-100000@luna.moonstar.com>, you wrote:
Simply stating that there's a better way without Sending Code is a copout.
I realize I'm dragging this on, and I apologize, but:
It's totally valid to report a problem that affects the operations community without providing a fix. Knowledge of the fact that a problem exists is valuable, even without a cookbook resolution.
In this case, a few people (some not on this list) would like the operations community to realize that there are, in fact, some very doable attacks that remain unaddressed by BIND 8.1.1.
Ahem. Yes, reporting a problem you can't personally fix is acceptable. Casting asparagus upon the design of code other people have written because it has those problems, however, is another matter. Given that the author thereof is known to be on the list, it's tantamount to a personal attack... which is off-topic, per point 6 of the AUP. :-) My turn: this is off-topic. Please move it to bind-workers, or some other acceptable forum. (I don't mean you, Paul, I mean Messrs. Black and Ptacek.) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
this statement bothers me. certainly without DNSSEC there can be no *assurances* of security,
While there are often assurances of security, there can never be assurance of security.
there is a gaping chasm between the current system and DNSSEC that could be closed significantly with proper design.
simply stating that until DNSSEC arrives these attacks are going to be allowed is a copout.
Send code. randy
participants (18)
-
Ben Black
-
Christopher Masto
-
Dave Crocker
-
Deepak Jain
-
Jay R. Ashworth
-
Jon Lewis
-
Juergen Georgi
-
Karl Denninger
-
Larry Vaden
-
Lon R. Stockton, Jr.
-
Michael Dillon
-
Paul A Vixie
-
Paul Ferguson
-
Perry E. Metzger
-
randy@psg.com
-
Robert Bowman
-
Thomas H. Ptacek
-
tqbf@smtp.enteract.com