Re: [DNSOP] AS112 for TLDs
[EMAIL PROTECTED] (William F. Maton Sotomayor) writes: At this point, I'd like to see the current pair of drafts move forward, and would cast this particular issue as the subject of some sort of other document. likewise, me. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Dear colleagues, Not to pick on Mark, but I have the sinking feeling that this discussion is a good example of why some operators think the IETF doesn't understand operational problems. On Sat, Apr 05, 2008 at 10:07:54AM +1100, Mark Andrews wrote: I said COPY. I did not say THEIR OWN ROOT. A copy needs to be kept up to date or it ceases to be a copy. It becomes a snapshot. The point of this exercise, as far as I recall, was to solve the problem that junk queries go to the roots -- things like .local and .txt. Now, if I'm a mom pop ISP being crunched by large carriers (who are using every trick in the book to drive me out of business) and expensive customer calls, I'm going to do whatever will make my customers happy, right now, and get them off the phone. So I'm going to say, What's the harm in adding the entries for .local into this instance that I'm already running for other TLDs anyway? It will make one failure mode go away for the customer, and it will reduce my load on my systems. By telling everyone to run their own authoritative copy for the top level, you are effectively telling them that they can add _anything_ at the top level. After all, you just told them to respond authoritatively at that level. And since they have the authority server at that level, who's to tell them that they shouldn't add the extra entries? It solves their operational problem, makes things easy for their customers, and (since the point of this effort is to stop leaking queries) doesn't harm anyone else. Right? The harm, of course, will come when people change ISPs and things don't work quite the same; or when they run into surprises by carrying their laptops into another network with a disjunct set of these non-IANA-root entries. This scheme more or less guarantees the end of the pretense of a unified namespace (which is related, I think, to the arguments elsewhere in this thread that such has already happened anyway). A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Dear colleagues,
Not to pick on Mark, but I have the sinking feeling that this
discussion is a good example of why some operators think the IETF
doesn't understand operational problems.
On Sat, Apr 05, 2008 at 10:07:54AM +1100, Mark Andrews wrote:
I said COPY. I did not say THEIR OWN ROOT. A copy needs to
be kept up to date or it ceases to be a copy. It becomes a
snapshot.
The point of this exercise, as far as I recall, was to solve the
problem that junk queries go to the roots -- things like .local and
.txt. Now, if I'm a mom pop ISP being crunched by large carriers
(who are using every trick in the book to drive me out of business)
and expensive customer calls, I'm going to do whatever will make my
customers happy, right now, and get them off the phone.
Which in all cases results in processing the junk queries locally.
So I'm going to say, What's the harm in adding the entries for .local
into this instance that I'm already running for other TLDs anyway?
It will make one failure mode go away for the customer, and it will
reduce my load on my systems.
You bring .local into existance for sites that are not using
.local.
The existing uses of AS112 don't bring zones into existance.
They just *replicate* existing zones for local processing.
By telling everyone to run their own authoritative copy for the top
level, you are effectively telling them that they can add _anything_
at the top level.
No, I am not telling them that. If I said run your own root
I would be telling them that.
After all, you just told them to respond authoritatively at that level.
With the contents that they have copied from an authoritative
source. local COPY * of the root zone
And since they have the authority
server at that level, who's to tell them that they shouldn't add the
extra entries?
They can add entries today without having their own copy of the
root zone. Having a local copy of the root does not change that.
zone tld {
type stub;
masters { ; };
file tld.stub;
};
It solves their operational problem, makes things easy
for their customers, and (since the point of this effort is to stop
leaking queries) doesn't harm anyone else. Right?
Creating a .local changes the response. It also restricts
future changes.
The harm, of course, will come when people change ISPs and things
don't work quite the same; or when they run into surprises by carrying
their laptops into another network with a disjunct set of these
non-IANA-root entries. This scheme more or less guarantees the end of
the pretense of a unified namespace (which is related, I think,
to the arguments elsewhere in this thread that such has already
happened anyway).
That happens today. There are ISP's which feel the need
to use a alternate root. Do you think they actually edit
the local root zone or do they transfer it?
Mark
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
* Mark Andrews: There really is only one solution to preventing bogus traffic reaching the root servers and that is to run a local copy of the root zone. Or sign the root and use aggressive negative caching (which is currently prohibited by the RFCs, I'm told). I agree that information leakage is a problem. Curiously enough, no root server or TLD operators that I know of has published some sort of privacy statement that underlines how they deal with this issue. It's also the reason why I think that AS112 for TLDs will not fly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
* Joe Baptista: I agree that information leakage is a problem. Curiously enough, no root server or TLD operators that I know of has published some sort of privacy statement that underlines how they deal with this issue. They are not the ones generating this traffic. Its users as they cross over dns zones. i.e. travelers from china staying at a hotel in the USA who can't access their language script idn national china tlds via the legacy IANA root. This doesn't exempt them from protecting that traffic (which they actually do in some form, you can't download it on a public FTP site, for instance). It's also the reason why I think that AS112 for TLDs will not fly. It will. Makes the perfect dns equivalent of the bin bucket trash can. It means that everybody who can make a BGP announcement can legitimately hijack DNS traffic to those TLDs. Is this really what we want? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Sun, Apr 6, 2008 at 9:15 AM, Florian Weimer [EMAIL PROTECTED] wrote: It means that everybody who can make a BGP announcement can legitimately hijack DNS traffic to those TLDs. Is this really what we want? Thats an AS112 security issue. Are they to be trusted? Maybe? Maybe not. AS112 can be easily replicated to operate on any dns servers including local roots. So that issue can be put to rest. Like I said before - it makes a great trash can. Now should you trust the communal trash can. Those who don't can run heir own AS112, and those who do can point to AS112. What we want and need is stability and world wide resolvability. What were getting is a revolution. regards joe baptista ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Fri, Apr 04, 2008 at 11:19:58AM -0400, Andrew Sullivan wrote: On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote: ... I can just imagine the hue and cry that would happen when new top level domains don't work for everybody. Or in a future, actually very far from today, when DS records are not updated during a rollover. Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Apr 4, 2008, at 8:30 AM, Frederico A C Neves wrote: On Fri, Apr 04, 2008 at 11:19:58AM -0400, Andrew Sullivan wrote: On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote: ... I can just imagine the hue and cry that would happen when new top level domains don't work for everybody. Or in a future, actually very far from today, when DS records are not updated during a rollover. A self-correcting problem. The folks that are affected are the ones using the non-updated server and no one else. Ideally, there would be a way to use standard zone transfer semantics to refresh the zone, but the hue and cry would likely serve to put the lackadaisical caching server operator on notice that they'd screwed up. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Andrew, On Apr 4, 2008, at 10:08 AM, Andrew Sullivan wrote: A self-correcting problem. The folks that are affected are the ones using the non-updated server and no one else. The problem is that those folks are _exactly_ the people who don't understand any of this Internet plumbing anyway. All they know is, This thing isn't working, or, The Internet is down, or something similar. The idea that they're going to put pressure on someone to fix it entails a great deal of optimism about what naive users might know about how the Internet functions and who can solve their problems. If the Internet is down, those folks are going to whine to their provider. I refer you to Vijay Gill's statements about the impact of a single support call. While it is admittedly in a different context, I'd still argue it is in the best interests of the name service provider to fix things to minimize the amount of gnashing of teeth they'd be subjected to. However, with that said, I would agree that it would be far better to minimize the chances of stale data in a copied root. I'd think having a way of automating the copying, via oh say zone transfer using regular zone transfer semantics would be the right way to go (Mark Andrews: hint, hint). Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Hi all. I fully agree with Andrew that the cause is far worse than the disease. I don't think the disease is life threatening. I keep hearing about the Problem of bogus queries to the root. It is certainly messy and ugly but from my perspective as an operator it is more of irritant than anything else. The capacity building for root operators, at least in our case, is not built around those bogus queries, it's build around other problems such as the number of hosts with weak security that are available for use in DDOS attacks. In % terms the 90%+ of bogus queries is irritating, moving those queries out to the ISPs doesn't stop them, just shares the pain a little and probably hides the problem somewhat. For now I still believe the best answer is to keep answering with NXDOMAIN and hoping that one day, this is where I am delusional, that those do the querying will fix their end of the problem... John Crain On 04/04/2008 08:19, Andrew Sullivan [EMAIL PROTECTED] wrote: On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote: leakage to the root servers is enormous. This sounds to me like a cure that is quite possibly worse than the disease. In what way? It rather depends on how much the root zone changes. The targets of run your own root copy are the people who don't know how to capture and appropriately isolate (or don't care to do it) their bogus traffic. The proposed solution is to tell them to get a copy of the root zone and run that. What makes us think that they'll keep that copy up to date, do sensible things with it, c? I am familiar with one largeish zone that had its infrastructure on the wrong end of an expensive link between it and the largest ISP in the country. Their answer to this was to transfer the zone to the ISP. Unfortunately, nobody at the ISP was monitoring the log files, and someone failed to keep the TSIG keys in sync, so their copy of the zone gradually came to be wrong. Since none of this copying-of-zone-around was documented anywhere, it took some time to debug the problem, during which time large sections of that domain were unavailable to a substantial population in the country in question. I can just imagine the hue and cry that would happen when new top level domains don't work for everybody. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote:
On Apr 4, 2008, at 7:02 AM, Andrew Sullivan wrote:
On Fri, Apr 04, 2008 at 02:16:32PM +1100, Mark Andrews wrote:
er, it (the bogus ttraffic) still reaches the root.
just your copy of the root, not mine.
Yep. This should be seen as a good thing. The information
leakage to the root servers is enormous.
This sounds to me like a cure that is quite possibly worse than the
disease.
In what way?
Mark made the claim that a local copy of the root would stop the
traffic, which is false. a local copy of the root simply diffuses
the traffic.
the down sides to local copies of the root as seen from the
peanut gallery:
) coherence of the avowed single namespace. There have been
a few threads over the past decade on bit rot in the root-hints
data. Local copies of the root zone will have the same bit-rot
characteristics
) the IANA sanctioning alternate roots/namespaces ... let a
thousand roots bloom...
) just how is the poor application/end user supposed to know
or discriminate some local, walled garden root varient from
the one true ICANN root varient?
I said COPY. I did not say THEIR OWN ROOT. A copy needs to
be kept up to date or it ceases to be a copy. It becomes a
snapshot.
zone . {
type slave;
masters { addresses of root servers; };
};
Mark
but you, no doubt, see a much clearer picture. please convince
me that my doubts are groundless... that bit-rot won't happen,
It is possible to check the masters similarly to the way
we check the roots servers today.
that the avowed single namespace will remain intact,
It will if you keep the copy up to date.
and that
there will be trival ways for end users to discover the root of
the namespace they are using...
dig NS .
if the recommendation to run your own copy of the root is approved.
Note the zone will expire if you don't keep the masters up
to date unlike failures to keep the root hints up to date.
Mark
--bill
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Thu, Apr 03, 2008 at 12:00:11AM -0500, Joe Abley wrote: it's barely worth suggesting them. Call me cynical :-) Or on the money. Whichever fits :-) A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
There really is only one solution to preventing bogus traffic reaching the root servers and that is to run a local copy of the root zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On 1 Apr 2008, at 13:38 , William F. Maton Sotomayor wrote: I suppose I should dust off my notes on this issue and hammer something out, as there were some on this list who were interested in seeing a proposal. Mind you, I wonder if the WG might be out of scope for dealing with 'junk' TLD. I think that any proposal that involved adding delegations to the root zone, even if to prisoner and friends, and even if for such domains that are thought never to be candidates for conventional delegation (txt, local, etc.) would be so mired in political controversy that it's barely worth suggesting them. Call me cynical :-) Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Edward Lewis wrote: At 12:57 -0800 12/3/07, Brian Dickson wrote: What are the pros/cons of this, other than the obvious offloading of junk TLD lookups? From http://www.nanog.org/mtg-0310/pdf/wessels.pdf: See (unnumbered) slide Punchline from Last Year's Talk: CategoryPercent of Total (see slide for all cat's) Unknown TLD 12.5 ... Legitimate2.15 Of course, that is 2002/2003 data. 6:1 bad TLD to good query. Off-loading bad TLDs from the roots is a big win. As with any research citation, I encourage readers to look it up too - to see if you agree with what I yanked out. Sorry for the late response. About this matter, using the data collected at the root server instances participating in DITL 2007, we found 24.73% of the queries seen at the roots were for invalid TLD's. Doing an analysis per root, the numbers vary C-root 19.15% F-root 46.79% K-root 10.01% M-root 20.96% within the queries for invalid TLD, the distribution is local 20.29% localhost8.92% domain 3.15% invalid 2.43% lan 2.06% belkin 1.76% home 1.30% localdomain 1.29% wpad 0.74% txt 0.74% You may want to check the presentation including this numbers at http://public.oarci.net/files/workshop-2007/Castro-DITL2007-analysis.pdf Regards Sebastian Castro, CAIDA ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
At 10:35 -0700 4/1/08, Sebastian Castro Avila wrote:
Sorry for the late response. About this matter, using the data collected
at the root server instances participating in DITL 2007, we found 24.73%
of the queries seen at the roots were for invalid TLD's.
Doing an analysis per root, the numbers vary
C-root 19.15%
F-root 46.79%
K-root 10.01%
M-root 20.96%
Wow, what a dispersion. I'm not calling into question the effort,
etc., but seeing these numbers makes me wonder about the value of the
results. The reasons for my suspicion are:
1) That there such wide variation
2) from sampling just a minority of the root ('s 13) nodes
3) considering that the topology/architecture of each sampled node is
vastly different
(I should ask - for, say, F, are the samples across all nodes of the
[F] any cast cloud or just sampling at a few of the node's any cast
members?)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Tue, 1 Apr 2008, Sebastian Castro wrote: So the data seems to be useful (but not complete). Once we got all the data for DITL 2008 we could try to run the same test and look for trends. But it is a good start in having a look at the problem (or if anyone could consider to be a problem). I suppose I should dust off my notes on this issue and hammer something out, as there were some on this list who were interested in seeing a proposal. Mind you, I wonder if the WG might be out of scope for dealing with 'junk' TLD. wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
* Stephane Bortzmeyer: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. All the non-existing TLDs queried are local domains (such as Apple's .local), leaking through a configuration error. This looks like a job for AS112. How do you prevent people from serving a non-empty .local TLD? This change would make AS112 more attractive to miscreants, I guess. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
[EMAIL PROTECTED] (Masataka Ohta) wrote: Zone transfer is the mechanism. You then don't have to use AS112 to absorb the load. The local resolver will answer the query. It will be an interesting experiment to let AS112 nameservers offer root zone transfer for any client. Would certainly boost the MegBit of traffic the box here pushes... I'm not certain if this wouldn't necessitate an upgrade ;) Elmar. -- Hinken ist kein Mangel eines Vergleichs, sondern sollte als wesentliche Eigenschaft von Vergleichen angesehen werden. (Marius Fränzel in desd) --[ ELMI-RIPE ]--- ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Mon, 3 Dec 2007, Phil Regnauld wrote: The first step is to decide whether delegating to AS112 is reserved to standardized (read: RFC) zones, like RFC1918, 169.254, etc..., or whether anything sufficiently large -- and bogus -- is sufficient. Step 0 of course is to get the as112 docs moving. :-) wfms ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On 03 Dec, Brian Dickson wrote: | I wonder if it is even necessary to enumerate/instantiate the junk TLDs? | | Given that root servers have (by definition) *the* authoritative list of | TLDs, everything else is junk. | | Would not it make sense to put in wildcard delegations to AS112? | | What are the pros/cons of this, other than the obvious offloading of | junk TLD lookups? == If I understand correctly your suggestion: OK for the first querie, but as the referal to AS112 NS's will lead to a lame delegation (so no negative caching), for further queries for those same junk TLDs, root servers will be sollicited again? So what would you have gained at the end? Mohsen. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Mark Andrews wrote: We should be looking at mechanisms to allow the root zone to be distributed to every iterative resolver in the world. You then don't have to use AS112 to absorb the load. The local resolver will answer the query. For the last two years we have been advocating just that. Root should be broadly distributed. But even with that AS112 would still be needed to redirect some errors. If only ICANN used AS112 to redirect bogus request they would see less of a load. Right now AS112 is mainly available to those who willing participate. Not many do. Not many know about AS112. regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 10:55:44AM +0100, Peter Koch wrote: On Tue, Nov 27, 2007 at 02:35:29PM -0800, John Crain wrote: Currently about 60% New IP to 40% old IP... and rising slowly So clearly a lot of folks still need to up date their hints files :( part of that traffic will be due to old hints files, but priming was actually supposed to accelerate the migration. 40% of total L traffic seems a bit much for 1/13 of the priming traffic? There is a bug in all current PowerDNS recursor versions where it neglects to erradicate the contents of the hints file from its cache. This means that both the old and the new IP address of l.root-servers.net will continue to be used, until the hints file expires from the cache, which is sadly only after 40 days of uptime. I apologise for this bug, and promise that a fixed PowerDNS recursor will be released swiftly. However, I don't think 40% of the world is running the PowerDNS Recursor, so there must be something else to blame, as well. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, 28 Nov 2007, Peter Koch wrote: On Tue, Nov 27, 2007 at 02:35:29PM -0800, John Crain wrote: Currently about 60% New IP to 40% old IP... and rising slowly So clearly a lot of folks still need to up date their hints files :( part of that traffic will be due to old hints files, but priming was actually supposed to accelerate the migration. 40% of total L traffic seems a bit much for 1/13 of the priming traffic? Why old root server IP addresses recieve so much traffic is a great mystery and has been for several years. We addressed this in 2004 in the Life and Times of J-root presentation for NANOG 32: http://www.nanog.org/mtg-0410/pdf/kosters.pdf Note that at the time, I fingerprinted the responsive queriers and many were late-model BIND, all of which are known to prime. As I write this, J root's old IP address is receiving 1000 queries per second and that's over five years after we changed its address. Perhaps this is some sort of DNS equivlanet to cosmic background radiation, dating back the beginning of the Internet? Matt ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 10:58:17AM -0500, Matt Larson wrote: On Wed, 28 Nov 2007, Peter Koch wrote: On Tue, Nov 27, 2007 at 02:35:29PM -0800, John Crain wrote: Currently about 60% New IP to 40% old IP... and rising slowly So clearly a lot of folks still need to up date their hints files :( part of that traffic will be due to old hints files, but priming was actually supposed to accelerate the migration. 40% of total L traffic seems a bit much for 1/13 of the priming traffic? Why old root server IP addresses recieve so much traffic is a great mystery and has been for several years. We addressed this in 2004 in the Life and Times of J-root presentation for NANOG 32: http://www.nanog.org/mtg-0410/pdf/kosters.pdf Note that at the time, I fingerprinted the responsive queriers and many were late-model BIND, all of which are known to prime. As I write this, J root's old IP address is receiving 1000 queries per second and that's over five years after we changed its address. Perhaps this is some sort of DNS equivlanet to cosmic background radiation, dating back the beginning of the Internet? Matt and perhaps more interesting, the old address for B showed a tapering off of traffic and then an INCREASE last year. Old L and J got their numbers less than a decade ago. ... so i would not go back as far as the begining of the Internet. Old B has been around for quite a while longer. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 05:15:59PM +0100, bert hubert wrote: On Wed, Nov 28, 2007 at 04:07:59PM +, [EMAIL PROTECTED] wrote: and perhaps more interesting, the old address for B showed a tapering off of traffic and then an INCREASE last year. Old L and J got their numbers less than a decade ago. ... so i would not go back as far as the begining of the Internet. Old B has been around for quite a while longer. The increase in traffic might easily be due to more favourable connectivity to 'B', which would lead many resolver implementations to shift more queries to it. Bert old B topolgy didnt change... :) --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 04:22:41PM +, [EMAIL PROTECTED] wrote: The increase in traffic might easily be due to more favourable connectivity to 'B', which would lead many resolver implementations to shift more queries to it. Bert old B topolgy didnt change... :) Admittedly, you have a far better view of the internet than I do :-) - But I'm not ruling out changes *other* people made to their networks. Also, perhaps the other roots just became less attractive. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: B-Root address change [Re: [DNSOP] AS112 for TLDs]
On Wed, Nov 28, 2007 at 05:28:47PM +0100, bert hubert wrote: On Wed, Nov 28, 2007 at 04:22:41PM +, [EMAIL PROTECTED] wrote: The increase in traffic might easily be due to more favourable connectivity to 'B', which would lead many resolver implementations to shift more queries to it. Bert old B topolgy didnt change... :) Admittedly, you have a far better view of the internet than I do :-) - But I'm not ruling out changes *other* people made to their networks. Also, perhaps the other roots just became less attractive. Bert the increase in queries occured after we stopped running a nameserver on the address and more than a year after the public announcement and change in the hints files. not saying other topology change didn't have the effects you describe, it just seems odd. --bill ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, boutique TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's .local), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages. This data was obtained from f.root. f.root is one of the oldest roots on the net while l.root is one of the newest. In fact if as per the ICANN blog this data was collected on November 26 then it would of come from IP 199.7.83.42 that was implemented on 1 November 2007 and replaced the previous IP address of 198.32.64.12. http://l.root-servers.org/ip-change-26nov07.htm The data is unclear if it was collected from 199.7.83.42 or 198.32.64.12. In any case what is certain is that both versions of the L.root run by ICANN are very new and that means the amount of traffic to them would be very low in comparison to f.root - which in my opinion provides a more accurate reflection of traffic patterns on the net. So in conclusion is this data in any way reflective of the impact of Karl, boutique TLDs? The answer in this case would be NO. It is however reflective of the data one would associate with a recently launched root server that few people are yet dependent on. Hope my comments help you interpret the data. kindest regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Hi Joe, It is exactly reflective of traffic as seen at l.root-servers.net and measured by DSC. there is no trickery, plots or evil schemes involved. Shame that your paranoia gets the better of you;) Those are percentages not queries indeed. Total queries varies between 8Kq/s and 10Kq/s on a normal day. So you can do the math if you really want to see it by q/s. Also it only shows the TOP scores, not all TLDs. For clarity: The data is from both current and old IPv4 addresses (Across all instances of L) I have already spoken to CAIDA about supplying them with L-root data for future projects and we will be taking part in their day in the life of project so you should see L-root included in their future analysis. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 08:07, Joe Baptista wrote: Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, boutique TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's .local), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/ dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages. This data was obtained from f.root. f.root is one of the oldest roots on the net while l.root is one of the newest. In fact if as per the ICANN blog this data was collected on November 26 then it would of come from IP 199.7.83.42 that was implemented on 1 November 2007 and replaced the previous IP address of 198.32.64.12. http://l.root-servers.org/ip-change-26nov07.htm The data is unclear if it was collected from 199.7.83.42 or 198.32.64.12. In any case what is certain is that both versions of the L.root run by ICANN are very new and that means the amount of traffic to them would be very low in comparison to f.root - which in my opinion provides a more accurate reflection of traffic patterns on the net. So in conclusion is this data in any way reflective of the impact of Karl, boutique TLDs? The answer in this case would be NO. It is however reflective of the data one would associate with a recently launched root server that few people are yet dependent on. Hope my comments help you interpret the data. kindest regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 baptista.vcf___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
John Crain wrote: Hi Joe, It is exactly reflective of traffic as seen at l.root-servers.net and measured by DSC. there is no trickery, plots or evil schemes involved. Shame that your paranoia gets the better of you;) Your right. There is no trickery, plots or evil schemes involved. I misspoke in the message to the GA. The only one misleading us using the data was stephane and I doubt that was intentional. We are having a discussion concerning TLDs there and the data was used to make a point, which on reflection does not exist due to the particulars made in my reply. Those are percentages not queries indeed. Total queries varies between 8Kq/s and 10Kq/s on a normal day. So you can do the math if you really want to see it by q/s. Also it only shows the TOP scores, not all TLDs. For clarity: The data is from both current and old IPv4 addresses (Across all instances of L) I know - in both cases recent deployments of a root server. It would be very beneficial to see this data across the other roots for comparison. As I have said the L.root is not reflective of the overall traffic patterns to all the roots as L is a very new instance of a root, either old or new IPv4 address. Incidentally - just how much traffic is this representative of? How many queries came in during the period the data was captured? Thanks for the clarification. regards joe baptista regards joe baptista I have already spoken to CAIDA about supplying them with L-root data for future projects and we will be taking part in their day in the life of project so you should see L-root included in their future analysis. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 08:07, Joe Baptista wrote: Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, boutique TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's .local), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/ dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages. This data was obtained from f.root. f.root is one of the oldest roots on the net while l.root is one of the newest. In fact if as per the ICANN blog this data was collected on November 26 then it would of come from IP 199.7.83.42 that was implemented on 1 November 2007 and replaced the previous IP address of 198.32.64.12. http://l.root-servers.org/ip-change-26nov07.htm The data is unclear if it was collected from 199.7.83.42 or 198.32.64.12. In any case what is certain is that both versions of the L.root run by ICANN are very new and that means the amount of traffic to them would be very low in comparison to f.root - which in my opinion provides a more accurate reflection of traffic patterns on the net. So in conclusion is this data in any way reflective of the impact of Karl, boutique TLDs? The answer in this case would be NO. It is however reflective of the data one would
Re: [DNSOP] AS112 for TLDs
John Crain wrote: Hi Joe. I didn't do the math, I was using DSC. I'm sure I could figure it out with some DSC tweaking... However with beign completely unscientific and measuring rates averaging from 8kq/s (low) to 10kq/s (high) over a 24hr period it's between 691.2 million and 864 million queries. So a fairly big sample.. I would estimate that it is somewhere inbetween at about 750 million. Interesting. Just doing some more estimating - what percentage of those queries, or how are they divided between the old and new IP. regards joe baptista I'll leave more in depth analysis to the likes of CAIDA, they're better at it than me. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 14:05, Joe Baptista wrote: John Crain wrote: Hi Joe, It is exactly reflective of traffic as seen at l.root-servers.net and measured by DSC. there is no trickery, plots or evil schemes involved. Shame that your paranoia gets the better of you;) Your right. There is no trickery, plots or evil schemes involved. I misspoke in the message to the GA. The only one misleading us using the data was stephane and I doubt that was intentional. We are having a discussion concerning TLDs there and the data was used to make a point, which on reflection does not exist due to the particulars made in my reply. Those are percentages not queries indeed. Total queries varies between 8Kq/s and 10Kq/s on a normal day. So you can do the math if you really want to see it by q/s. Also it only shows the TOP scores, not all TLDs. For clarity: The data is from both current and old IPv4 addresses (Across all instances of L) I know - in both cases recent deployments of a root server. It would be very beneficial to see this data across the other roots for comparison. As I have said the L.root is not reflective of the overall traffic patterns to all the roots as L is a very new instance of a root, either old or new IPv4 address. Incidentally - just how much traffic is this representative of? How many queries came in during the period the data was captured? Thanks for the clarification. regards joe baptista regards joe baptista I have already spoken to CAIDA about supplying them with L-root data for future projects and we will be taking part in their day in the life of project so you should see L-root included in their future analysis. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 08:07, Joe Baptista wrote: Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, boutique TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's .local), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/ dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages. This data was obtained from f.root. f.root is one of the oldest roots on the net while l.root is
Re: [DNSOP] AS112 for TLDs
Hi Joe. I didn't do the math, I was using DSC. I'm sure I could figure it out with some DSC tweaking... However with beign completely unscientific and measuring rates averaging from 8kq/s (low) to 10kq/s (high) over a 24hr period it's between 691.2 million and 864 million queries. So a fairly big sample.. I would estimate that it is somewhere inbetween at about 750 million. I'll leave more in depth analysis to the likes of CAIDA, they're better at it than me. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 14:05, Joe Baptista wrote: John Crain wrote: Hi Joe, It is exactly reflective of traffic as seen at l.root-servers.net and measured by DSC. there is no trickery, plots or evil schemes involved. Shame that your paranoia gets the better of you;) Your right. There is no trickery, plots or evil schemes involved. I misspoke in the message to the GA. The only one misleading us using the data was stephane and I doubt that was intentional. We are having a discussion concerning TLDs there and the data was used to make a point, which on reflection does not exist due to the particulars made in my reply. Those are percentages not queries indeed. Total queries varies between 8Kq/s and 10Kq/s on a normal day. So you can do the math if you really want to see it by q/s. Also it only shows the TOP scores, not all TLDs. For clarity: The data is from both current and old IPv4 addresses (Across all instances of L) I know - in both cases recent deployments of a root server. It would be very beneficial to see this data across the other roots for comparison. As I have said the L.root is not reflective of the overall traffic patterns to all the roots as L is a very new instance of a root, either old or new IPv4 address. Incidentally - just how much traffic is this representative of? How many queries came in during the period the data was captured? Thanks for the clarification. regards joe baptista regards joe baptista I have already spoken to CAIDA about supplying them with L-root data for future projects and we will be taking part in their day in the life of project so you should see L-root included in their future analysis. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 08:07, Joe Baptista wrote: Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, boutique TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's .local), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/ dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages. This data was obtained from f.root. f.root is one of the oldest roots on the net while l.root is one of the newest. In fact if as per the ICANN blog this data was collected on November 26 then it would of come from IP 199.7.83.42 that was implemented on 1 November 2007
