Subject: Re: [DNSOP] AS112 for TLDs

From: Sebastian Castro Avila <[email-masked]>
Date: Tue, 01 Apr 2008 10:35:42 -0700

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":
> 
> Category            Percent of Total (see slide for all cat's)
> Unknown TLD          12.5
> ...
> Legitimate            2.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%
localhost	 8.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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Sebastian Castro Avila <[email-masked]>
Date: Tue, 01 Apr 2008 10:35:42 -0700

C-root		19.15%
F-root		46.79%
K-root		10.01%
M-root		20.96%

local		20.29%
localhost	 8.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%

Regards
Sebastian Castro, CAIDA

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Apr 2008 13:51:54 -0400

>Doing an analysis per root, the numbers vary

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Apr 2008 13:51:54 -0400

---

From: Sebastian Castro <[email-masked]>
Date: Tue, 1 Apr 2008 14:23:19 -0400

> 1) That there such wide variation

We investigated that situation on request and found some F-root
instances were receiving very high volume of queries for invalid TLD.

> 2) from sampling just a minority of the root ('s 13) "nodes"

That's true, is want we can answer with the data avaFrom [email-masked]  Tue Apr  1 11:23:35 2008
Date: Tue, 1 Apr 2008 14:23:19 -0400
From: Sebastian Castro <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] AS112 for TLDs
Sender: [email-masked]

> 1) That there such wide variation

We investigated that situation on request and found some F-root
instances were receiving very high volume of queries for invalid TLD.

> 2) from sampling just a minority of the root ('s 13) "nodes"

That's true, is want we can answer with the data availilable. However, the
data sample is not small: 61 root instances, 24 hours of data.

> [F] any cast cloud or just sampling at a few of the node's any cast 

For that study we use the following data:

24 hour traces collected between 01-09-2007 12:00 and 01-10-2007 12:00,
on 61 root server anycast nodes

C-root, all 4 instances
F-root, 36 out of 40
K-root, 15 out of 17
M-root, all 6 instances

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.

Regards
Sebastian

-- 
Sebastian E. Castro Avila             [email-masked]
Enviado Especial (a.k.a. New Elf)     [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

able. However, the
data sample is not small: 61 root instances, 24 hours of data.

> [F] any cast cloud or just sampling at a few of the node's any cast 

For that study we use the following data:

24 hour traces collected between 01-09-2007 12:00 and 01-10-2007 12:00,
on 61 root server anycast nodes

C-root, all 4 instances
F-root, 36 out of 40
K-root, 15 out of 17
M-root, all 6 instances

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.

Regards
Sebastian

-- 
Sebastian E. Castro Avila             [email-masked]
Enviado Especial (a.k.a. New Elf)     [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Tue, 1 Apr 2008 14:38:07 -0400 (EDT)

> data for DITL 2008 we could try to run the same test and look for

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

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Tue, 1 Apr 2008 14:38:07 -0400 (EDT)

wfms

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Apr 2008 14:39:44 -0400

At 14:23 -0400 4/1/08, Sebastian Castro wrote:
>
>That's true, is want we can answer with the data available. However, the
...
>M-root, all 6 instances

It's not the size of the sample, but knowing that resolvers change 
their preferred server from time to time the numbers would be a lot 
more meaningful if we saw all the instances.

Especially given the 4:2:1 ratio (F's 40% to the others).  Such a 
skew makes me suspicious that something else is going on.  If all 
were consistent, I'd take it at face value.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Apr 2008 14:39:44 -0400

...

---

From: Joe Abley <[email-masked]>
Date: Thu, 3 Apr 2008 00:00:11 -0500

> proposal.  Mind you, I wonder if the WG might be out of scope for  

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

---

From: Joe Abley <[email-masked]>
Date: Thu, 3 Apr 2008 00:00:11 -0500

Joe

---

From: Paul Vixie <[email-masked]>
Date: 03 Apr 2008 14:20:55 +0000

> it's barely worth suggesting them. Call me cynical :-)

that's not the least iota cynical.
-- 
Paul Vixie
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: 03 Apr 2008 14:20:55 +0000

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Apr 2008 10:31:37 -0400

> it's barely worth suggesting them. Call me cynical :-)

Or "on the money."  Whichever fits :-)

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Apr 2008 10:31:37 -0400

A

---

From: Edward Lewis <[email-masked]>
Date: Thu, 3 Apr 2008 10:40:55 -0400

>it's barely worth suggesting them. Call me cynical :-)

I agree with Paul and Andrew - it's not cynical.  There's no registry 
of "ersatz" domains so you'd never be sure you've covered them all 
and without the registry there's no guarantee of uniqueness.  (One's 
.local might be another's .lo-cal.)

It's not just a political/economic/policy problem.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Thu, 3 Apr 2008 10:40:55 -0400

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Apr 2008 09:05:25 +1100

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-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Apr 2008 09:05:25 +1100

Mark

---

From: [email-masked]
Date: Fri, 4 Apr 2008 02:59:08 +0000

> 	traffic reaching the root servers and that is to run a local

	er, it (the bogus ttraffic) still reaches the root.
	just your copy of the root, not mine.

--bill

---

From: [email-masked]
Date: Fri, 4 Apr 2008 02:59:08 +0000

--bill

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Apr 2008 14:16:32 +1100

> 	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.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Apr 2008 14:16:32 +1100

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Apr 2008 10:02:11 -0400

> 	leakage to the root servers is enormous.

This sounds to me like a cure that is quite possibly worse than the
disease.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Apr 2008 10:02:11 -0400

A

---

From: David Conrad <[email-masked]>
Date: Fri, 4 Apr 2008 07:37:31 -0700

> This sounds to me like a cure that is quite possibly worse than the

In what way?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 4 Apr 2008 07:37:31 -0700

In what way?

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Apr 2008 11:19:58 -0400

> > This sounds to me like a cure that is quite possibly worse than the

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Apr 2008 11:19:58 -0400

A

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 4 Apr 2008 12:30:14 -0300

...
> 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

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 4 Apr 2008 12:30:14 -0300

...

Fred

---

From: David Conrad <[email-masked]>
Date: Fri, 4 Apr 2008 08:46:21 -0700

> 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

---

From: David Conrad <[email-masked]>
Date: Fri, 4 Apr 2008 08:46:21 -0700

Regards,
-drc

---

From: [email-masked]
Date: Fri, 4 Apr 2008 15:56:38 +0000

> > This sounds to me like a cure that is quite possibly worse than the

	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?

	but you, no doubt, see a much clearer picture.  please convince
	me that my doubts are groundless... that bit-rot won't happen,
	that the avowed single namespace will remain intact, and that
	there will be trival ways for end users to discover the root of
	the namespace they are using...   if the recommendation to run
	your own copy of the root is approved.

--bill

---

From: [email-masked]
Date: Fri, 4 Apr 2008 15:56:38 +0000

--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Apr 2008 13:08:16 -0400

I agree almost completely (and that "almost" is only there to cover me
in case I think of an objection later) with what Bill Manning said.
But I'm particularly concerned about this:

On Fri, Apr 04, 2008 at 08:46:21AM -0700, David Conrad wrote:

> 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.  

I think I should have put this another way than "cure worse than the
disease."  I agree that having lots of dispersed copies of the root
with at best very loosely coupled management of those copies would
solve the disease we have.  But this seems to me like solving the
problem of yellow fever by comFrom [email-masked]  Fri Apr  4 10:08:16 2008
Date: Fri, 4 Apr 2008 13:08:16 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] AS112 for TLDs
Sender: [email-masked]

I agree almost completely (and that "almost" is only there to cover me
in case I think of an objection later) with what Bill Manning said.
But I'm particularly concerned about this:

On Fri, Apr 04, 2008 at 08:46:21AM -0700, David Conrad wrote:

> 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.  

I think I should have put this another way than "cure worse than the
disease."  I agree that having lots of dispersed copies of the root
with at best very loosely coupled management of those copies would
solve the disease we have.  But this seems to me like solving the
problem of yellow fever by complpletely draining all the swamplands of
the world: it may be great for the humans, but it's pretty lousy if
you're one of the animals that lives in the swamp.

A

etely draining all the swamplands of
the world: it may be great for the humans, but it's pretty lousy if
you're one of the animals that lives in the swamp.

A

---

From: David Conrad <[email-masked]>
Date: Fri, 4 Apr 2008 10:35:12 -0700

Andrew,

> know about how the Internet functions and who can solve their

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

---

From: David Conrad <[email-masked]>
Date: Fri, 4 Apr 2008 10:35:12 -0700

Andrew,

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Apr 2008 14:32:39 -0400

>single support call.  While it is admittedly in a different context,

Not being facetious, but is there a reference into any archives where 
that nugget is recorded?  I ask because I have used that and have 
tried to find an "original" but haven't come up with it yet.

I believe it was from a NANOG 4-5 years ago.  Anyone have another recollection?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Apr 2008 14:32:39 -0400

---

From: "John L. Crain" <[email-masked]>
Date: Fri, 4 Apr 2008 15:51:16 -0700

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-masked]> wrote:

A

---

From: "John L. Crain" <[email-masked]>
Date: Fri, 4 Apr 2008 15:51:16 -0700

Hi all.

John Crain

A

---

From: Mark Andrews <[email-masked]>
Date: Sat, 05 Apr 2008 10:07:54 +1100

> 	  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

> 	me that my doubts are groundless... that bit-rot won't happen,

	It is possibFrom [email-masked]  Fri Apr  4 16:08:00 2008
To: [email-masked]
From: Mark Andrews <[email-masked]>
Date: Sat, 05 Apr 2008 10:07:54 +1100
Cc: [email-masked], David Conrad <[email-masked]>,
	Andrew Sullivan <[email-masked]>
Subject: Re: [DNSOP] AS112 for TLDs
Sender: [email-masked]

> 	  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

> 	me that my doubts are groundless... that bit-rot won't happen,

	It is possle 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
> 	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

ible 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
> 	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

---

From: "Joe Baptista" <[email-masked]>
Date: Fri, 4 Apr 2008 20:42:23 -0400

> >       traffic, which is false. a local copy of the root simply diffuses

Depends on the root you use.  If you use an inclusive name space root you
will see a significant reduction in traffic.  If you use the iana root thats
when you'll diffuse the traffic.

Also of interest, If you answer the localhost TLD you'll reduce alot of
traffic.  And if you can redirect a wild card in the root to AS112 you'll be
ahead on NXDOMAIN.

> >       ) the IANA sanctioning alternate roots/namespaces ... "let a

yes - while you eliminate dependence on the legacy root.  i think thats the
best approach.  one thing is clear from all these errors to the root is that
the icann root has withered.  let a million roots bloom.

Dependence on a central root is illogical.  Very soviet era.

> >         the one true ICANN root varient?

ICANN is not a functional root anymore.  It does not see all of the
Internet.  Can't see china.  Has no idea of the arab tlds.  Can't see
India.  Can't see turkey or the Netherlands.  Lots of TLDs on the Internet
and ICANN can't see them.  Thats why you have so much bogus root traffic.

>                masters { <addresses of root servers>; };

Just AXFR.

regards
joe baptista

---

From: "Joe Baptista" <[email-masked]>
Date: Fri, 4 Apr 2008 20:42:23 -0400

Just AXFR.

regards
joe baptista

---

From: [email-masked]
Date: Sat, 5 Apr 2008 03:44:45 +0000

> 		masters { <addresses of root servers>; };

		er... a rather narrow, constrained view of the
	term "copy".   I have copies of some datasets that go back
	20 years or more.  same data set, at different points in time.
	apparently you mean a copy of the database, plus/minus some
	temporal value and not augmented/diminished in any material
	way.  

	your example of how to obtain a copy, that meets most of the 
	criteria - seems to have a couple of assuptions... 
	
		) yFrom [email-masked]  Fri Apr  4 20:46:23 2008
Date: Sat, 5 Apr 2008 03:44:45 +0000
From: [email-masked]
To: Mark Andrews <[email-masked]>
Cc: Andrew Sullivan <[email-masked]>, [email-masked],
	[email-masked], David Conrad <[email-masked]>
Subject: Re: [DNSOP] AS112 for TLDs
Sender: [email-masked]

> 		masters { <addresses of root servers>; };

		er... a rather narrow, constrained view of the
	term "copy".   I have copies of some datasets that go back
	20 years or more.  same data set, at different points in time.
	apparently you mean a copy of the database, plus/minus some
	temporal value and not augmented/diminished in any material
	way.  

	your example of how to obtain a copy, that meets most of the 
	criteria - seems to have a couple of assuptions... 
	
		)ou state < addresses of root servers> ... which
		  ones?  
		) can you ensure that the "root-servers" listed actually
		  wills erve accurate data via xfr?

	wrt "copy" vs "their own root"...

you and i started this discussion w/ the following:

--bill

	your statement that people should be encouraged to 
	run a local copy of the root zone begs the question,
	run it where?  to which my assumption is ... they 
	run in on their own server, which, being authoritative
	for the root now, becomes their own root server.
	Did I err?

	and where is the "thou shalt NOT" modify/augment/diminish
	the contents of the database in the "local" copy ...
	
> 	It is possible to check the masters similarly to the way

	coordinating btwn a dozen orgs is one thing, coordinating
	btwn an unbounded number is something else.  as an analogy,
	how many AS112 instances are there and how can one check
	for coherent data ebing served by them?

> 	It will if you keep the copy up to date.

	"copy up to date"... so you acknowledge copies can and will
	age/diverge over time.   and you assume that augmentation
	"frosting" will not be applied to the local copy each time
	a fresh copy is aquired... presumably from some well known
	set of servers

> > 	the namespace they are using...

	please...  get real here.

> 	to date unlike failures to keep the root hints up to date.

	rndc reload .... to use a bind specific example of reloading

 you state < addresses of root servers> ... which
		  ones?  
		) can you ensure that the "root-servers" listed actually
		  wills erve accurate data via xfr?

	wrt "copy" vs "their own root"...

you and i started this discussion w/ the following:

--bill

	your statement that people should be encouraged to 
	run a local copy of the root zone begs the question,
	run it where?  to which my assumption is ... they 
	run in on their own server, which, being authoritative
	for the root now, becomes their own root server.
	Did I err?

	and where is the "thou shalt NOT" modify/augment/diminish
	the contents of the database in the "local" copy ...
	
> 	It is possible to check the masters similarly to the way

	coordinating btwn a dozen orgs is one thing, coordinating
	btwn an unbounded number is something else.  as an analogy,
	how many AS112 instances are there and how can one check
	for coherent data ebing served by them?

> 	It will if you keep the copy up to date.

	"copy up to date"... so you acknowledge copies can and will
	age/diverge over time.   and you assume that augmentation
	"frosting" will not be applied to the local copy each time
	a fresh copy is aquired... presumably from some well known
	set of servers

> > 	the namespace they are using...

	please...  get real here.

> 	to date unlike failures to keep the root hints up to date.

	rndc reload .... to use a bind specific example of reloading

---

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Apr 2008 14:43:34 +0200

> 	traffic reaching the root servers and that is to run a local

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Apr 2008 14:43:34 +0200

---

From: "Joe Baptista" <[email-masked]>
Date: Sun, 6 Apr 2008 09:05:24 -0400

> prohibited by the RFCs, I'm told).

Think extra zone :)

> root server or TLD operators that I know of has From [email-masked]  Sun Apr  6 06:05:34 2008
Date: Sun, 6 Apr 2008 09:05:24 -0400
From: "Joe Baptista" <[email-masked]>
To: "Florian Weimer" <[email-masked]>
Cc: [email-masked], Mark Andrews <[email-masked]>,
	Edward Lewis <[email-masked]>
Subject: Re: [DNSOP] AS112 for TLDs
Sender: [email-masked]

> prohibited by the RFCs, I'm told).

Think extra zone :)

> root server or TLD operators that I know of has pupublished 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.

> It's

It will.  Makes the perfect dns equivalent of the bin bucket trash can.
However the question remains - does it help the user in the end.  Would it
be more appropriate in my example above that the legacy root simply
recognize Chinese national tlds?  That would get rid of some of the error
traffic of the root and do a service to travelers from china.

Think users - not roots.

cheers
joe baptista

---

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Apr 2008 15:15:40 +0200

> can't access their language script idn national china tlds via the legacy

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 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Apr 2008 15:15:40 +0200

---

From: "Joe Baptista" <[email-masked]>
Date: Sun, 6 Apr 2008 09:33:32 -0400

> 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

---

From: "Joe Baptista" <[email-masked]>
Date: Sun, 6 Apr 2008 09:33:32 -0400

regards
joe baptista

---

From: Dean Anderson <[email-masked]>
Date: Mon, 7 Apr 2008 14:54:40 -0400 (EDT)

> instances were receiving very high volume of queries for invalid TLD.

Do you have the source IP's that are generating the invalid tld's?

I'm wondering why those ip's aren't distributing their queries across
all the roots.

> data for DITL 2008 we could try to run the same test and look for

This is quite interesting. F-root is also the most anycasted of this
subset...  The next highest anycasted member has the least amount of bad
TLD queries. Seems to be more variability with more highly anycasted
servers. I wonder why...

Do you have the number of anycast instances for all 13 roots?

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Mon, 7 Apr 2008 14:54:40 -0400 (EDT)

--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Apr 2008 15:36:45 -0400

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.

> 	be kept up to date or it ceases to be a copy.  It becomes a

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'sFrom [email-masked]  Mon Apr  7 12:36:43 2008
Date: Mon, 7 Apr 2008 15:36:45 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] AS112 for TLDs
Sender: [email-masked]

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.

> 	be kept up to date or it ceases to be a copy.  It becomes a

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

 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

---

From: "Joe Baptista" <[email-masked]>
Date: Mon, 7 Apr 2008 17:16:30 -0400

> to the arguments elsewhere in this thread that such has already

Exactly - such happened a long time ago - the multi root universe.

regards
joe baptista

---

From: "Joe Baptista" <[email-masked]>
Date: Mon, 7 Apr 2008 17:16:30 -0400

regards
joe baptista

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Apr 2008 09:40:50 +1000

> customers happy, right now, and get them off the phone.

	Which in all cases results in processing the junk queries locally.

> 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.

> 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
> 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

	Creating a ".local" changes the response.  It also restricts
	future changes.
 
> to the arguments elsewhere in this thread that such has already

	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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Apr 2008 09:40:50 +1000

zone tld {
		type stub;
		masters { ....; };
		file "tld.stub";
	};

 

	Mark

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Apr 2008 11:38:38 +0200

Not all resolvers are equal. Some lock on on servers, others don't

If you look at this,

    > > >Doing an analysis per root, the numbers vary

You'll note that C & M has less instances then K, but more of this
traffic. To me it seems too little data conclude anything.

As far as I know public information is available at
http://www.root-servers.org/

	jaap

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 08 Apr 2008 11:38:38 +0200

If you look at this,

	jaap

---

From: Dean Anderson <[email-masked]>
Date: Tue, 8 Apr 2008 14:13:38 -0400 (EDT)

> Not all resolvers are equal. Some lock on on servers, others don't

The law of large numbers should still apply. They should lock on to
servers equally often...

> traffic. To me it seems too little data conclude anything.

I did notice that.  There is more variation in this statistic with
greater anycasting than there is with less anycasting: F and K differ by
36.78, while C and M differ by 1.81.From [email-masked]  Tue Apr  8 11:13:30 2008
Date: Tue, 8 Apr 2008 14:13:38 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Jaap Akkerhuis <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] AS112 for TLDs
Sender: [email-masked]

> Not all resolvers are equal. Some lock on on servers, others don't

The law of large numbers should still apply. They should lock on to
servers equally often...

> traffic. To me it seems too little data conclude anything.

I did notice that.  There is more variation in this statistic with
greater anycasting than there is with less anycasting: F and K differ by
36.78, while C and M differ by 1.81.    This is quite interesting and
needs more investigation. But I agree there is little to go on and more
data is necessary.

> http://www.root-servers.org/

There is a lot missing from root-servers.org:

For example, it's not clear from the root-servers.org what roots just
have backups at other sites that they turn on when the primary fails, vs
what roots are anycasted.  Those with 30+ sites are probably anycasted,
but who can say about those with just 2 or 4 sites? Also, its never been
clear what the chain of authority has been to approve anycasting.  I've
found some RSSAC meeting minutes, but no written approvals.  The status
reports to DoC are unclear as well.  Who approved this practice, and on
what scientific basis did they make that approval? There is also an
economic question: Root server operators are not supposed to charge for
root server operations. This seems to be violated by anycast operators
selling anycasted root servers.  Its not clear who approved that change.
If you know the answers to any of these, I'd appreciate knowing.

Thanks,

		--Dean

This is quite interesting and
needs more investigation. But I agree there is little to go on and more
data is necessary.

> http://www.root-servers.org/

There is a lot missing from root-servers.org:

For example, it's not clear from the root-servers.org what roots just
have backups at other sites that they turn on when the primary fails, vs
what roots are anycasted.  Those with 30+ sites are probably anycasted,
but who can say about those with just 2 or 4 sites? Also, its never been
clear what the chain of authority has been to approve anycasting.  I've
found some RSSAC meeting minutes, but no written approvals.  The status
reports to DoC are unclear as well.  Who approved this practice, and on
what scientific basis did they make that approval? There is also an
economic question: Root server operators are not supposed to charge for
root server operations. This seems to be violated by anycast operators
selling anycasted root servers.  Its not clear who approved that change.
If you know the answers to any of these, I'd appreciate knowing.

Thanks,

		--Dean

---

From: Peter Koch <[email-masked]>
Date: Mon, 14 Apr 2008 17:54:45 +0200

> 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 i…

thanks, John, for bringing this up.  The topic is re-occuring and for judging the
cure vs. the disease we would need to know not only how widespread the disease
is (in percent of the queries), but whether the patient actually suffers.
Also, it would be interesting to not only watch the "bogus" queries but also
at the ratio of "bogus" vs. "legitimate" queries per source IP address, also
taking into account other query parameters.  This would help getting an idea
whether measures implemented in the average recursive full resolver would
actually lead to a significant change.

For the "AS112 for TLDs" I sense there is consensus to go to WGLC with maintaining
the drafts' current focus.

> 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...

Since "information leakage" has been mentioned already and additional delay
is another concern on the client side, it might be worth addressing the "disease"
from this end. However, we have no indication that anybody actually suffers here.

So, unless we'd like to live with the topic popping up over again, we could try
a "trade offs document" for a start.  Not sure this will end up as something
to be reasonably published as an RFC, but it might at least serve as a pointer
target next time the idea comes up.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Mon, 14 Apr 2008 17:54:45 +0200

-Peter

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Mon, 14 Apr 2008 12:19:34 -0400 (EDT)

> the drafts' current focus.

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.

wfms

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Mon, 14 Apr 2008 12:19:34 -0400 (EDT)

wfms

---

From: Paul Vixie <[email-masked]>
Date: 14 Apr 2008 18:29:59 +0000

> and would cast this particular issue as the subject of some sort of 

likewise, me.

---

From: Paul Vixie <[email-masked]>
Date: 14 Apr 2008 18:29:59 +0000

likewise, me.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Apr 2008 15:15:22 -0400

+1

--
"Let's just say that if complete and utter chaos was lightning, he'd  
be the sort to stand on a hilltop in a thunderstorm wearing wet copper  
armour and shouting 'All gods are bastards'."

     -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of  
Magic)

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Apr 2008 15:15:22 -0400

+1