Re: large organization nameservers sending icmp packets to dns servers.
On Fri, 10 Aug 2007 16:11:04 -0700 Douglas Otis <[EMAIL PROTECTED]> wrote: > TCP offers a means to escape UDP related issues. On the other hand, > blocking TCP may offer the necessary motivation for having these UDP > issues fixed. After all, only UDP should be required. When TCP is > designed to readily fail, reliance upon TCP seems questionable. As > DNSSEC in introduced, TCP could be relied upon in the growing number > of instances where UDP is improperly handled. As a datapoint I ran some tests against a reasonably diverse and sizeable TLD zone I work with in another forum. I queried the name servers listed in the parent to see if I could successfuly query them for their corresponding domain name they are configured for using TCP. Out of about 9,300 unique name servers I failed to receive any answer from about 1700 of them. That is a bit more than an 18% failure rate. John
Re: Content Delivery Networks
On Aug 10, 2007, at 9:13 AM, Max Inux wrote: > Working for a content delivery network I can tell you that there > are many nameservers ignoring TTL that affect many users (AOL > being the largest american one). Coincidentally AOL users aren't So, I'd also ask this, do you know it's the recursive server, or is the behavior that you see related more to the application caching and not respecting the TTL? (IE for instance and it's default 30 minute, I think, ttl). How does a CDN tell the recursive server is doing this vice the client app?
Re: large organization nameservers sending icmp packets to dns servers.
> >>> On 8/9/2007 at 10:07 PM, Mark Andrews <[EMAIL PROTECTED]> wrote: > > > In article <[EMAIL PROTECTED]> you write: > >> > >>I suspect that the origin of the myth that DNS/TCP is more > >>dangerous than DNS/UDP is that the first root expliot of > >>named was over TCP not UDP. There were later exploits that > >>were UDP only which totally busted the myth but it continues > >>to live. > >> > >>Mark > > > > Just to make it clear. This was BIND 4/8 code and the bugs > > were addressed in the last millennia. > > > > To date there are no known root exploits for BIND 9. > > Because who runs BIND as root anymore? Lots of people. It's the only way you can handle some events. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: large organization nameservers sending icmp packets to dns servers.
On Aug 10, 2007, at 4:41 PM, Paul Vixie wrote: On the other hand, potentially larger messages may offer the necessary motivation for adding ACLs on recursive DNS, and deploying BCP 38. i surely do hope so. we need those ACLs and we need that deployment, and if message size and TCP fallback is a motivator, then let's turn UP the volume. There are so many more larger and immediate reasons for doing these things that I seriously doubt message size and TCP fallback on the DNS will have any impact at all in terms of motivating the non- motivated. But, one can always hope. ;> --- Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company
Re: large organization nameservers sending icmp packets to dns servers.
> Your comments have helped.
groovy.
> When TCP is designed to readily fail, reliance upon TCP seems questionable.
i caution against being overly cautious about DNS TCP if you're using RFC 1035
section 4.2.2 as your basis for special caution. DNS TCP only competes
directly against other DNS TCP. there are only two situations where a DNS TCP
state blob is present in a DNS target ("server") long enough to be in any
danger: when doing work upstream to fulfill the query, and in zone transfers.
when answering DNS TCP queries in an authority server, there is by definition
no "upstream work" to be done, other than possible backend database lookups
which are beyond the scope of this discussion. these responses will usually
be generated synchronous to the receipt of the last octet of a query, and the
response will be put into the TCP window (if it's open, which it usually is),
and the DNS target ("server") will then wait for the initiator ("client") to
close the connection or send another query. (usually it's a close.)
when answering DNS TCP zone transfer requests in an authority server, there is
a much larger window of doom, during which spontaneous network congestion can
close the outgoing TCP window and cause a DNS target ("server") to think that
a TCP session is "idle" for the purpose of RFC 1035 section 4.2.2 TCP resource
management. while incremental zone transfer is slightly less prone to this
kind of doom than full zone transfer, since the sessions are shorter, it can
take some time for the authority server to compute incremental zone "diffs",
during which the TCP session may appear "idle" through no fault of the DNS
initiator ("client") who is avidly waiting for its response.
lastly, when answering DNS TCP queries in a recursive caching nameserver, it
can take a while (one or more round trips to one or more authority servers)
before there is enough local state to satisfy the query, during which time the
TCP resources held by that query might be reclaimed under RFC 1035 section
4.2.2's rules.
the reason why not to be overly cautious about TCP is that in the case where
you're an authority server answering a normal query, the time window during
which network congestion could close the outbound TCP window long enough for
RFC 1034 section 4.2.2's rules to come into effect, is vanishingly short. so
while it's incredibly unwise to depend on zone transfer working from a small
number of targets to a large number of initiators, and it is in fact wise to
firewall or ACL your stealth master server so that only your designated
secondary servers can reach it, none of this comes into play for normal
queries to authority servers -- only zone transfers to authority servers.
the unmanageable risk is when a recursive caching nameserver receives a
query by TCP and forwards/iterates upstream. if this happens too often, then
the RFC 1035 section 4.2.2 rules will really hurt. and thus, it's wise, just
as you say, to try to make sure other people don't have to use TCP to fetch
data about your zone. the counterintuitive thing is that you won't be able
to measure the problems at your authority server since that's not where they
will manifest. they'll manifest at caching recursive servers downstream.
> As DNSSEC in introduced, TCP could be relied upon in the growing number of
> instances where UDP is improperly handled.
this would be true if TCP fallback was used when EDNS failed. it's not.
if EDNS fails, then EDNS will not be used, either via UDP or TCP. so if
improper handling of UDP prevents EDNS from working, then EDNS and anything
that depends on EDNS, including DNSSEC, will not be used.
> UDP handling may have been easier had EDNS been limited to 1280 bytes.
if you mean, had EDNS been limited to nonfragmentation cases, then i think
you might mean 576 bytes or even 296 bytes. 1280 is an IPv6 (new era) limit.
> On the other hand, potentially larger messages may offer the necessary
> motivation for adding ACLs on recursive DNS, and deploying BCP 38.
i surely do hope so. we need those ACLs and we need that deployment, and if
message size and TCP fallback is a motivator, then let's turn UP the volume.
Re: Content Delivery Networks
>>> On 8/10/2007 at 11:55 AM, "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote: > On Aug 10, 2007, at 12:46 PM, John Levine wrote: > >>> Very interesting. We've all heard and probably all passed along >>> that little >>> bromide at one time or another. Is it possible that at one time >>> it was true >>> (even possibly for AOL) but with the rise of CDNs, policies of not >>> honoring >>> TTL's have fallen by the wayside? >> >> I think you'll still see it in spam zombies, some of which have the >> DNS info >> pre-loaded into them in order to avoid split-horizon anti-spam >> techniques. >> >> Not much we can do about that until we get sufficient backbone to deal >> with the zombie problem and its software enablers. > > Actually, I think the fact Zombies do not honor TTLs is a feature. :) Fast-flux my MX records to avoid spam? Throw the spammers' technology back at 'em! I changed some MX records in mid-July for a domain. Spam was still flowing into the old MX hosts until I closed the firewall 25/tcp holes just today. Now just logging those zombies still banging on the gates. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: large organization nameservers sending icmp packets to dns servers.
>>> On 8/9/2007 at 10:07 PM, Mark Andrews <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]> you write: >> >> I suspect that the origin of the myth that DNS/TCP is more >> dangerous than DNS/UDP is that the first root expliot of >> named was over TCP not UDP. There were later exploits that >> were UDP only which totally busted the myth but it continues >> to live. >> >> Mark > > Just to make it clear. This was BIND 4/8 code and the bugs > were addressed in the last millennia. > > To date there are no known root exploits for BIND 9. Because who runs BIND as root anymore? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387 B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: large organization nameservers sending icmp packets to dns servers.
On Aug 9, 2007, at 2:05 PM, Paul Vixie wrote: Your comments have helped. i think you're advising folks to monitor their authority servers to find out how many truncated responses are going out and how many TCP sessions result from these truncations and how many of these TCP sessions are killed by the RFC1035 4.2.2 connection management logic, and if the numbers seem high, then they ought to change their applications and DNS content so that truncations no longer result. Monitoring is a good recommendation, as many incorrectly estimate record limits. Wildcard resources should also be checked against maximal labels. Fallback may occur with resource records encompassing a bit more than a couple hundred bytes. The assurance TCP will fail first is heartening. How this protection interacts with an emerging exploit could be interesting. I'll try to setup some tests and be less pragmatic. or perhaps you're asking that EDNS be more widely implemented, that it not be blocked by firewalls or perverted by hotelroom DNS middleboxes, and that firewalls start allowing UDP fragments (which don't have port numbers and therefore won't be allowed by UDP/53 rules). TCP offers a means to escape UDP related issues. On the other hand, blocking TCP may offer the necessary motivation for having these UDP issues fixed. After all, only UDP should be required. When TCP is designed to readily fail, reliance upon TCP seems questionable. As DNSSEC in introduced, TCP could be relied upon in the growing number of instances where UDP is improperly handled. UDP handling may have been easier had EDNS been limited to 1280 bytes. On the other hand, potentially larger messages may offer the necessary motivation for adding ACLs on recursive DNS, and deploying BCP 38. No pain, no gain might be a motto that applies equally to DNS as it does for weight lifting. -Doug
Re: Client information?
Carl Karsten wrote: I guess yes. They might implement a non swimmers basin for the windows people and a sharks only basin for the rest of us. what is a non swimmers basin ? A toilet? Or maybe a kiddie wading pool. -- Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED] Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: Client information?
Hello Guys, Thanks for the information. What I was thinking was if you get more information, can you make any use of it? Can you provide a bundled service per se? Can it help you in remote management of home consoles? Thanks On 8/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Fri, 10 Aug 2007 09:45:39 CDT, Carl Karsten said: > > > thanks. I kinda figured it was something like that, but it was just a > bit too > > unfamiliar, and around here (US) they just have 2 sides of the pool, > know as > > "the shallow end" and "the deep end". > > I think Peter was referring to the "Wading Pool" - you know, the one that > has maybe 6 inches of water in it, for the *really* tiny ones that even > the > shallow end is too deep > >
Re: Content Delivery Networks
On Aug 10, 2007, at 12:46 PM, John Levine wrote: Very interesting. We've all heard and probably all passed along that little bromide at one time or another. Is it possible that at one time it was true (even possibly for AOL) but with the rise of CDNs, policies of not honoring TTL's have fallen by the wayside? I think you'll still see it in spam zombies, some of which have the DNS info pre-loaded into them in order to avoid split-horizon anti-spam techniques. Not much we can do about that until we get sufficient backbone to deal with the zombie problem and its software enablers. Actually, I think the fact Zombies do not honor TTLs is a feature. :) -- TTFN, patrick
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>. Routing Table Report 04:00 +10GMT Sat 11 Aug, 2007 Report Website: http://thyme.apnic.net This report:http://thyme.apnic.net/ap-data/2007/08/11/0400 Analysis Summary BGP routing table entries examined: 227875 Prefixes after maximum aggregation: 119464 Deaggregation factor: 1.91 Unique aggregates announced to Internet: 110970 Total ASes present in the Internet Routing Table: 25926 Prefixes per ASN: 8.79 Origin-only ASes present in the Internet Routing Table: 22589 Origin ASes announcing only one prefix: 11046 Transit ASes present in the Internet Routing Table:3337 Transit-only ASes present in the Internet Routing Table: 75 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 21 Max AS path prepend of ASN (35389) 16 Prefixes from unregistered ASNs in the Routing Table: 7 Unregistered ASNs in the Routing Table: 3 Prefixes from 32-bit ASNs in the Routing Table: 5 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 11 Number of addresses announced to Internet: 1749388768 Equivalent to 104 /8s, 69 /16s and 141 /24s Percentage of available address space announced: 47.2 Percentage of allocated address space announced: 61.8 Percentage of available address space allocated: 76.4 Total number of prefixes smaller than registry allocations: 120402 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:53191 Total APNIC prefixes after maximum aggregation: 20712 APNIC Deaggregation factor:2.57 Prefixes being announced from the APNIC address blocks: 50139 Unique aggregates announced from the APNIC address blocks:22150 APNIC Region origin ASes present in the Internet Routing Table:3031 APNIC Prefixes per ASN: 16.54 APNIC Region origin ASes announcing only one prefix:824 APNIC Region transit ASes present in the Internet Routing Table:462 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 311122080 Equivalent to 18 /8s, 139 /16s and 88 /24s Percentage of available APNIC address space announced: 77.1 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 116/6, 120/6, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:107833 Total ARIN prefixes after maximum aggregation:62588 ARIN Deaggregation factor: 1.72 Prefixes being announced from the ARIN address blocks:79381 Unique aggregates announced from the ARIN address blocks: 31831 ARIN Region origin ASes present in the Internet Routing Table:11735 ARIN Prefixes per ASN: 6.76 ARIN Region origin ASes announcing only one prefix:4526 ARIN Region transit ASes present in the Internet Routing Table:1069 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 341862144 Equivalent to 20 /8s, 96 /16s and 103 /24s Percentage of available ARIN address space announced: 75.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks24/8, 63/
Re: Content Delivery Networks
On Aug 10, 2007, at 1:55 AM, Paul Reubens wrote: How do you engineer around enterprise and ISP recursors that don't honor TTL, instead caching DNS records for a week or more? A friend of mine was working for a place that performed some service on data (not important what, you send them some data (through this really ugly client app that they wrote in-house) and they sent you back something...). Anyway, for various reasons they needed to move out of their current data-center to a new provider. They had this truly monumental plan for doing this that they had been working on for months --- MS Project printouts that covered entire walls in this huge rainbow of colors, 400 or so pages of plans, etc etc etc -- it all boiled down to: Decrease the TTL, then swap in the new A record at midnight on Friday. As soon as the TTL expired everything would start working in the new place and it will all be transparent to the end users... Anyway, my friend calls me at like 3 in the morning on Saturday -- they have updated DNS and none of their clients are connecting to the new place... It seems that they have burnt some bridges with the old provider and will be shut off on Saturday evening -- he's really desperate, so I agree to wander over and take a look... I arrive to find utter confusion -- the CEO is screaming at the CTO, who appears to have decided that the best way to fix things is by getting drunk, random other people are screaming (apparently just for fun), etc I manage to get someone to calm down for long enough to explain the summary of the plan to me and run nslookup.. Sure enough the TTL is really low and the new IP is being handed out, etc. I ask how long it took for the client to fail over during their tests -- "Oh, no, we didn't test like that, we didn't want to impact the current service, so we tested with a different domain and checked how long it took for a IE to pick up the change... It was less than 10 minutes..." We track down one of the developers and talk to him. He explains this long and involved system with the client performing heath-checks on the server and reconnecting wit exponential back-off, etc etc etc. Its all great -- apart from the fact that he calls gethostbyname() during startup, and then never again This is a *really* common issue W On 8/7/07, Patrick W.Gilmore <[EMAIL PROTECTED]> wrote: On Aug 7, 2007, at 10:05 AM, Michal Krsek wrote: >>> 5) User redirection >>> - You have to implement a scalable mechanisms that redirects >>> users to the closes POP. You can use application redirect (fast, >>> but not so much scalable), DNS redirect (scalable, but not so >>> fast) or anycasting (this needs cooperation with ISP). >> >> What is slow about handing back different answers to the same >> query via DNS, especially when they are pre-calculated? Seems >> very fast to me. > > Yes DNS-based redirection scales very pretty. > > But there are two problems: > 1) Client may not be in same network as DNS server (I'm using my > home DNS server even if I'm at IETF or I2 meeting on other side of > globe) This has been discussed. Operational experience posted here by Owen shows < 10% of users are "far" from their recursive NS. You are the tiny minority. (Don't feel bad, so am I. :) Most "users" either use the NS handed out by their local DHCP server, or they are VPN'ing anyway. > 2) DNS TTL makes realtime traffic management inpossible. Remember > you may not distribute network traffic, but sometimes also server > load. If one server/POP fails or is overloaded, you need to > redirect users to another one in realtime. Define "real time"? To do it in 1 second or less is nigh impossible. But I challenge you to fail anything over in 1 second when IP communication with end users not on your LAN is involved. I've seen TTLs as low as 20s, giving you a mean fail-over time of 10 seconds. That's more than fast enough for most applications these days. -- TTFN, patrick
Re: Content Delivery Networks
On Aug 10, 2007, at 9:13 AM, Max Inux wrote: Working for a content delivery network I can tell you that there are many nameservers ignoring TTL that affect many users (AOL being the largest american one). Coincidentally AOL users aren't nearly so affected by that as they are that their data goes to Virginia to enter the internet negating close-to-end-user acceleration benefits. Additionally there are several networks off of Singtel (Singapore/ Southern asia/oceania), Many in Australia (Likely due to Squid caches to prevent egress), and in Europe (Mostly France) that I have specifically ran into that had this disregard for TTL impact them. In short, they are out there, and they will bite you from time to time if your network is widely enough used. Specifics? Off list is fine.
Re: Client information?
On Fri, 10 Aug 2007 09:45:39 CDT, Carl Karsten said: > thanks. I kinda figured it was something like that, but it was just a bit > too > unfamiliar, and around here (US) they just have 2 sides of the pool, know as > "the shallow end" and "the deep end". I think Peter was referring to the "Wading Pool" - you know, the one that has maybe 6 inches of water in it, for the *really* tiny ones that even the shallow end is too deep pgp3ggqf6JiDF.pgp Description: PGP signature
Re: large organization nameservers sending icmp packets to dns servers.
On Thu, 09 Aug 2007 22:58:40 -, Paul Vixie said: > > How does the (eventual) deployment of DNSSEC change these numbers? > > DNSSEC cannot be signalled except in EDNS. Right. Elsewhere in this thread, somebody discussed ugly patches to keep the packet size under 512. I dread to think how many different ways of "protecting" DNS are deployed that will break EDNS, and just haven't been noticed because there's little enough *actual* EDNS breakage that it's down in the noise of *other* "random voodoo" breakage at those sites. > > And who's likely to feel *that* pain first? > > the DNSSEC design seems to distribute pain very fairly. I actually meant "which 800 pound gorilla is going to try this first and find all the bustifications", but your answer is good too.. :) pgpFy1Ds4pwV8.pgp Description: PGP signature
RE: Content Delivery Networks
Rodney Joffe wrote: > On Aug 9, 2007, at 10:55 PM, Paul Reubens wrote: > >> How do you engineer around enterprise and ISP recursors that don't >> honor TTL, instead caching DNS records for a week or more? >> > > In my "little" bit of research and experience over the last 10 years > in this field, I have often pursued this "urban myth". It remains > largely just that. > > The most common supposed violator of this was AOL. I found myself in > a position at one stage to get to the "root" of this, and was rather > impressed to find that it was indeed a myth. > > We've just finished a small research project where we looked at > approximately 16 million recursive servers. The only ones violating > this were some CPE devices that ran local recursive services, and > they were generally along the lines of returning the appropriate TTL > the first time they were queried, and if the TTL was zero, they > returned a higher TTL (1 seconds) to subsequent queries for a > short period (5 minutes). It may have been a code bug, or a designed > behavior given that these were CPE devices. Very interesting. We've all heard and probably all passed along that little bromide at one time or another. Is it possible that at one time it was true (even possibly for AOL) but with the rise of CDNs, policies of not honoring TTL's have fallen by the wayside? Andrew
Re: Content Delivery Networks
On Aug 9, 2007, at 10:55 PM, Paul Reubens wrote: How do you engineer around enterprise and ISP recursors that don't honor TTL, instead caching DNS records for a week or more? In my "little" bit of research and experience over the last 10 years in this field, I have often pursued this "urban myth". It remains largely just that. The most common supposed violator of this was AOL. I found myself in a position at one stage to get to the "root" of this, and was rather impressed to find that it was indeed a myth. We've just finished a small research project where we looked at approximately 16 million recursive servers. The only ones violating this were some CPE devices that ran local recursive services, and they were generally along the lines of returning the appropriate TTL the first time they were queried, and if the TTL was zero, they returned a higher TTL (1 seconds) to subsequent queries for a short period (5 minutes). It may have been a code bug, or a designed behavior given that these were CPE devices. Do you have any real examples of significant recursive servers doing this?
Re: Client information?
Peter Dambier wrote: Carl Karsten wrote: I guess yes. They might implement a non swimmers basin for the windows people and a sharks only basin for the rest of us. what is a non swimmers basin ? Hi Carl, in germany our public swimming pools have pools for swimmers and pools for people who cannot swim. If swimmers accidently fall into the the non swimmers and get drowned by all those non swimmers permanently plunging onto them, its their problem and not a fault of the people running the pool :) The shark basin and the non swimmers basin are very much used in popular language here - but maybe my translation is horrible. thanks. I kinda figured it was something like that, but it was just a bit too unfamiliar, and around here (US) they just have 2 sides of the pool, know as "the shallow end" and "the deep end". Carl K
Re: large organization nameservers sending icmp packets to dns servers.
On Thu, 9 Aug 2007 15:53:12 -0700 (PDT) Doug Barton <[EMAIL PROTECTED]> wrote: How many bytes of shell code can you stuff into a 4096 byte EDNS0 UDP packet? :) Probably a lot. People used to have 4-line signatures with the PGP encryption or DECSS. I have a 152-byte C program that calculates 32K digits of PI. matthew black network services california state university, long beach
Re: Client information?
For ISP, I don't care what applications customers are running. As long as they are legitimate, it's o.k. with me. Only concern will be whether they are running malicious code such as Virus, Spam, DDoS client, or not, which means abusing network resources and other people's resource. For that purpose, pretty much nmap is performing basic function. Then if you need, you can capture the info from network. So I don't see the reason to spend additional money for finding more info about the host that connect to us. Hyun Paul Atkins wrote: Hello, I am a network researcher. One question I want to ask the ISPs here are that if they have a choice of finding more information about the hosts that connect to them, is it something they will like to spend money on? For example if the ISP can find out what applications is the host running etc. would it be useful for the ISPs? Thanks
Re: Client information?
Carl Karsten wrote: I guess yes. They might implement a non swimmers basin for the windows people and a sharks only basin for the rest of us. what is a non swimmers basin ? Hi Carl, in germany our public swimming pools have pools for swimmers and pools for people who cannot swim. If swimmers accidently fall into the the non swimmers and get drowned by all those non swimmers permanently plunging onto them, its their problem and not a fault of the people running the pool :) The shark basin and the non swimmers basin are very much used in popular language here - but maybe my translation is horrible. Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
Re: Client information?
I guess yes. They might implement a non swimmers basin for the windows people and a sharks only basin for the rest of us. what is a non swimmers basin ? Carl K
Re: Client information?
Paul Atkins wrote: Hello, I am a network researcher. One question I want to ask the ISPs here are that if they have a choice of finding more information about the hosts that connect to them, is it something they will like to spend money on? For example if the ISP can find out what applications is the host running etc. would it be useful for the ISPs? Thanks I am not exactly an ISP. Sometimes somebody is nocking at my door. If it sounds like they are knocking with a pick and a hoe, I forget about good manners and ask back with nmap. Depending an what IASON and nmap are reporting I might give botnet Gadi an email - but I dont take money for that sevice nor is that so interesting I would pay money to know more. And I see netbios ports open most of the time, so I guess it must be windows mostly and the application is a bot. The friendlier guys keep telling me their os and browser via the html interface. If they disguise a Linux Konqeror as a Winows IE that is no big problem. Would it be useful for ISPs? I guess yes. They might implement a non swimmers basin for the windows people and a sharks only basin for the rest of us. But I as a costumer would not want that. And paying money for that "sevice" - beware. Kind regards Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
The Cidr Report
This report has been generated at Fri Aug 10 21:19:42 2007 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
03-08-07231908 149811
04-08-07231815 150435
05-08-07232179 150461
06-08-07232046 150894
07-08-07231724 151796
08-08-07232316 152211
09-08-07232457 152616
10-08-07232344 152285
AS Summary
26003 Number of ASes in routing system
11020 Number of ASes announcing only one prefix
1503 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - AT&T WorldNet Services
88826880 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 10Aug07 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 232733 1524178031634.5% All ASes
AS18566 1018 99 91990.3% COVAD - Covad Communications
Co.
AS4755 1319 466 85364.7% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS6478 1115 286 82974.3% ATT-INTERNET3 - AT&T WorldNet
Services
AS4134 1329 565 76457.5% CHINANET-BACKBONE
No.31,Jin-rong Street
AS11492 367 74467.0% CABLEONE - CABLE ONE
AS4323 1323 601 72254.6% TWTC - Time Warner Telecom,
Inc.
AS9394 844 233 61172.4% CRNET CHINA RAILWAY
Internet(CRNET)
AS19262 766 232 53469.7% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS9498 994 466 52853.1% BBIL-AP BHARTI BT INTERNET
LTD.
AS15270 566 72 49487.3% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS7545 719 230 48968.0% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS17488 742 253 48965.9% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS7018 1503 1015 48832.5% ATT-INTERNET4 - AT&T WorldNet
Services
AS18101 580 109 47181.2% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS19916 568 101 46782.2% ASTRUM-0001 - OLM LLC
AS2386 1205 744 46138.3% INS-AS - AT&T Data
Communications Services
AS8151 916 463 45349.5% Uninet S.A. de C.V.
AS17676 504 66 43886.9% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS4812 529 112 41778.8% CHINANET-SH-AP China Telecom
(Group)
AS4766 800 384 41652.0% KIXS-AS-KR Korea Telecom
AS9443 482 82 40083.0% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS6197 1029 645 38437.3% BATI-ATL - BellSouth Network
Solutions, Inc
AS22773 753 372 38150.6% CCINET-2 - Cox Communications
Inc.
AS4808 478 115 36375.9% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4668 512 168 34467.2% LGNET-AS-KR LG CNS
AS16814 426 86 34079.8% NSS S.A.
AS9942 438 120 31872.6% COMINDICO-AP SOUL Converged
Communications Australia
AS7011 905 595 31034.3% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS577573 266
BGP Update Report
BGP Update Report Interval: 09-Jul-07 -to- 09-Aug-07 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS14906 205364 2.8% 41072.8 -- 2 - AS9583 150849 2.1% 129.3 -- SIFY-AS-IN Sify Limited 3 - AS701872005 1.0% 46.7 -- ATT-INTERNET4 - AT&T WorldNet Services 4 - AS21452 66724 0.9%9532.0 -- skannet-ibadan 5 - AS30850 62116 0.8% 31058.0 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 6 - AS14201 61218 0.8%6121.8 -- 7 - AS24731 60661 0.8%1444.3 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 8 - AS13285 48611 0.7%6944.4 -- OPALTELECOM-AS Opal Telecom 9 - AS462146489 0.6% 314.1 -- UNSPECIFIED UNINET-TH 10 - AS27685 40747 0.6%2396.9 -- PEOPLE ONLINE 11 - AS815140486 0.6% 44.0 -- Uninet S.A. de C.V. 12 - AS24326 39123 0.5% 222.3 -- TTT-AS-AP Maxnet, Internet Service Provider, Bangkok 13 - AS19444 36729 0.5% 573.9 -- CHARTER-STL - CHARTER COMMUNICATIONS 14 - AS24863 36588 0.5% 100.5 -- LINKdotNET-AS 15 - AS702 35249 0.5% 53.0 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 16 - AS21332 32858 0.5%1314.3 -- NTC-AS New Telephone Company 17 - AS20115 30490 0.4% 20.1 -- CHARTER-NET-HKY-NC - Charter Communications 18 - AS876430201 0.4% 18.1 -- TEOLTAB TEO LT AB Autonomous System 19 - AS11830 29722 0.4% 49.2 -- Instituto Costarricense de Electricidad y Telecom. 20 - AS26210 29459 0.4% 283.3 -- AES Communications Bolivia S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS14906 205364 2.8% 41072.8 -- 2 - AS30850 62116 0.8% 31058.0 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 3 - AS22433 16784 0.2% 16784.0 -- HRMC - Human Resource Management Center, Inc. 4 - AS22072 11190 0.1% 11190.0 -- 5 - AS27289 11070 0.1% 11070.0 -- CLEOCOMMUNICATIONS - CLEO COMMUNICATIONS INC 6 - AS21452 66724 0.9%9532.0 -- skannet-ibadan 7 - AS268298730 0.1%8730.0 -- YKK-USA - YKK USA,INC 8 - AS13285 48611 0.7%6944.4 -- OPALTELECOM-AS Opal Telecom 9 - AS19001 13225 0.2%6612.5 -- AVENTCOMMTECH - Aventure Communications 10 - AS14201 61218 0.8%6121.8 -- 11 - AS30707 14477 0.2%4825.7 -- 12 - AS213489198 0.1%4599.0 -- KOPTERIFI KOPTERIFI is autonomous system. Located in Vammala Finland 13 - AS9833 4564 0.1%4564.0 -- HICOM-AS-AP http://www.plexus.net 14 - AS430434001 0.1%4001.0 -- INTERKOM-AS Interkom Sp. z o.o. 15 - AS394083037 0.0%3037.0 -- CZ-ETHERNET AVI ethernet.cz 16 - AS319492533 0.0%2533.0 -- APEXDIGITAL - Apex Digital 17 - AS9660 7396 0.1%2465.3 -- KANNET-AS-AP Telecommunication and ISP company 18 - AS12879 14460 0.2%2410.0 -- OJSC-STN-AS Svyaztransneft Autonomus System 19 - AS27685 40747 0.6%2396.9 -- PEOPLE ONLINE 20 - AS30763 18779 0.3%2347.4 -- IOS-SECONDARY-AS Internet of Siberia ISP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 194.110.73.0/24 62090 0.8% AS30850 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 2 - 62.24.238.0/2448519 0.6% AS13285 -- OPALTELECOM-AS Opal Telecom 3 - 12.27.90.0/24 45278 0.6% AS14906 -- 4 - 12.27.91.0/24 45252 0.6% AS14906 -- 5 - 221.135.22.0/24 41104 0.5% AS9583 -- SIFY-AS-IN Sify Limited 6 - 12.27.88.0/24 40003 0.5% AS14906 -- 7 - 12.27.89.0/24 39899 0.5% AS14906 -- 8 - 221.135.253.0/24 39012 0.5% AS9583 -- SIFY-AS-IN Sify Limited 9 - 12.27.88.0/22 34932 0.5% AS14906 -- 10 - 80.243.64.0/2031466 0.4% AS21332 -- NTC-AS New Telephone Company 11 - 170.65.189.0/24 30611 0.4% AS14201 -- 12 - 170.65.176.0/22 30505 0.4% AS14201 -- 13 - 203.23.208.0/24 27307 0.3% AS7604 -- HWY1-AS Highway 1 14 - 80.250.36.0/2322259 0.3% AS21452 -- skannet-ibadan 15 - 80.250.44.0/2222075 0.3% AS21452 -- skannet-ibadan 16 - 80.250.40.0/2222073 0.3% AS21452 -- skannet-ibadan 17 - 210.214.198.0/24 20630 0.3% AS9583 -- SIFY-AS-IN Sify Limited 18 - 200.123.224.0/24 19774 0.3% AS27685 -- PEOPLE ONLINE 19 - 200.123.225.0/24 19771 0.2% AS27685 -- PEOPLE ONLINE 20 - 212.109.192.0/20 18388 0.2% AS30763 -- IOS-SECONDARY-AS Internet of Siberia ISP Details at http://bgpupdates.potaroo.net Copies of this report are mailed to: nanog@merit.edu [EMAIL PRO
Re: Content Delivery Networks
> How do you engineer around enterprise and ISP recursors that > don't honor TTL, instead caching DNS records for a week or more? Ask their users to tell them to stop being muppets brandon
Re: Client information?
--- [EMAIL PROTECTED] wrote: From: "Paul Atkins" <[EMAIL PROTECTED]> I am a network researcher. One question I want to ask the ISPs here are that if they have a choice of finding more information about the hosts that connect to them, is it something they will like to spend money on? For example if the ISP can find out what applications is the host running etc. would it be useful for the ISPs? - No, there're too many free tools that're way fun and good. For example: www.ntop.org with lsof for your particular question. But, you're asking folks who aren't afraid of the technology. Ask an exec and they'll probably give a much different answer. ;-) scott
