Subject: [DNSOP] Best Practice document on local copy of the root zone?

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Feb 2007 15:20:59 +0100

There is a thread on the CircleID information site:

http://www.circleid.com/posts/attack_internet_root_servers/

which, in the light of this week's attack on root name servers,
suggest to keep a local copy of the root zone.

I was surprised that there is apparently no formal document, either
RFC or else, on this subject "Local copy of the root zone considered
harmful | good". Did I miss something?

It seems that the idea comes out from time to time (often, to increase
confusion, blended with Internet Governance issues) and that there is
no "final" document to produce in the thread?

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Feb 2007 10:55:33 -0500

>suggest to keep a local copy of the root zone.

To add to "what I've heard in the past to do" list:

Also keep a list of the IP addresses of the root servers, the 
originating AS numbers, and maybe even copies of "normal" traceroutes.

>harmful | good". Did I miss something?

I don't think anything so definitive on the topic would exist.

It always pays to have a record of what's normal for your environment 
and to know when there's a deviance.  On the other hand, I wouldn't 
count on the record for operational activity. That's more common 
sense that BCP material.

It's like taking a photo of your living room after a holiday.  I 
wouldn't use it as a guide when walking around it 6 months later as 
furniture may have moved.  But showing evidence of an expensive 
stereo being there might influence an insurance claim.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"Two years ago you said we had 5-7 years, now you are saying 3-5.  What I
need from you is a consistent story..."

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Feb 2007 10:55:33 -0500

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 Feb 2007 11:09:51 -0500

> originating AS numbers, and maybe even copies of "normal" traceroutes.

One thing you typically don't get if you're running your own stealth  
root nameservers is TSIG-signed access to the zone data. This seems  
like it introduces an additional attack vector for someone who wants  
to subvert the root zone; you could announce a bogus route which  
covers a root server's address, answer AXFR requests for a short  
period with a bogus zone, then withdraw the route; the hijack window  
required might be relatively short, and the bogus zone might persist  
in those nameservers which retrieved it for a long time.

[This seems different to the problem of unauthenticated answers from  
root servers being subverted and replaced by men in the middle; that  
approach doesn't allow additional records to be added, whereas  
serving a bogus zone via AXFR does.]

I also don't know of any formal undertaking by any of the current  
"real" root nameserver operators to leave un-authenticated [AI]XFR  
access to their servers for the root zone open, so there's the  
operational issue of needing to verify regularly that transfers to  
the stealth slave are succeeding.

> I don't think anything so definitive on the topic would exist.

Would, or should?

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 Feb 2007 11:09:51 -0500

Would, or should?

Joe

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Feb 2007 12:11:04 -0500

>Would, or should?

Would.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Feb 2007 12:11:04 -0500

Would.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 9 Feb 2007 10:15:24 -0800 (PST)

> no "final" document to produce in the thread?

Local as in what? Every ISP, every corporate network?

Isn't it better to have several roots anycast and connect at every
large enough traffic exchange points (IX) so as to connect to everyone 
locally that way? So I'd say one of the better ways to achieve it
is to have IX operators sponsor DNS roots (especially those run by
non-profit) as far as providing them free colo space and connection
toexchange and announcing that to all those on the exchange as extra
service and something ISPs there should take advantage of.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 9 Feb 2007 10:15:24 -0800 (PST)

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: bert hubert <[email-masked]>
Date: Fri, 9 Feb 2007 23:03:02 +0100

> harmful | good". Did I miss something?

Depending on the ratio of bandwidth available to miscreants and how widely
dispersed the root-servers are, the advice would probably alternate between
having and not having a local copy of the root zone.

Having a local copy brings the risk of getting outdated, against the benefit
of better service.

The risk of getting outdated is more or less fixed, whereas the risk of
people being able to effectively DoS all the root-servers varies based on
the ratio mentioned above.

If, for example, ADSL were to be supplanted by technology with a far larger
upstream, I'd be worried a lot more than I am now.

So the best advice is probably not fixed, and should therefore not be set in
stone.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: bert hubert <[email-masked]>
Date: Fri, 9 Feb 2007 23:03:02 +0100

Bert

---

From: Pekka Savola <[email-masked]>
Date: Sat, 10 Feb 2007 08:42:36 +0200 (EET)

On Fri, 9 Feb 2007, william(at)elan.net wrote:
> locally that way?

How useful that approach is probably depends a lot on how the DNS 
resolvers' algorithms select DNS root servers.  If they are able to 
pick the one(s) with fastest response times, yes.

As Bert mentioned in the next message, the risk of outdated (and 
therefor out-of-sync) roots is real.  Distributing the copies too far 
would create a similar situation as already happens when new IP 
address blocks are taken to use, and other networks still filter them 
as "bogons".  Experience with bogons has shown that there are always 
people who _don't_ update lists such as these yet still use them, and 
in the process degrade their users' service.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Sat, 10 Feb 2007 08:42:36 +0200 (EET)

---

From: Peter Koch <[email-masked]>
Date: Sat, 10 Feb 2007 16:46:46 +0100

> period with a bogus zone, then withdraw the route; the hijack window  

The current root zone publication mechanism also involves a GPG signed
copy made available via FTP. Of course, this involves more maintenance
effort than inbound *XFR. However, I agree that any distribution mechanism
adds another attack target.

> the stealth slave are succeeding.

Quote from RFC 2780:

   2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
       queries from clients other than other root servers.  This
       restriction is intended to, among other things, prevent
       unnecessary load on the root servers as advice has been heard
       such as "To avoid having a corruptible cache, make your server a
       stealth secondary for the root zone."  The root servers MAY put
       the root zone up for ftp or other access on one or more less
       critical servers.

Also, I'm not sure there's really a problem to solve. Most of the assessments
I read said that the root server system as a whole, if not single server
clusters withstood the attack well. How many 'legitimate' queries to the root
name servers would an average resolver send within, say, two hours?
What problem does occur if 'garbage' questions just time out -- both in
terms of lack of response and load on the recursive resolvers?
Given the experience with root 'hints' (and others, like Pekka mentioned),
which part of a potential target audience of a BCP can be assumed to apply
changes frequently and consistently enough in the long run to have a
real benefit?
What are the requirements for a scalable zone distribution infrastructure?

<co-chair-hat on>
There's still some time left until the -00 cutoff date. Whether aiming at a
BCP or just an Informational document discussing tradeoffs or acting as an
archive for all the arguments that this or previous instances of the same
discussion revealed -- if somebody cares enough, there's always the
opportunity to submit an individual I-D.
</co-chair-hat>

-Peter

---

From: Peter Koch <[email-masked]>
Date: Sat, 10 Feb 2007 16:46:46 +0100

Quote from RFC 2780:

<co-chair-hat on>

-Peter

---

From: Mark Andrews <[email-masked]>
Date: Sun, 11 Feb 2007 04:33:47 +1100

> opportunity to submit an individual I-D.

	Well transfering the root zone was what I was going to
	suggest to cove this paragraph of
	draft-ietf-dnsop-default-local-zones.

   This document has also deliberately ignored zones immediately under
   the root.  The author believes other methods would be more applicable
   for dealing with the excess / bogus traffic these generate.

	I actually think that axfr will put less load on the root
	servers than all the junk (unqualified names, IPv4 and IPv6
	addresses, .local etc.) UDP queries caches.  Early versions
	of DNSSEC have a zone SIG record which verified the contents
	of the transferred zone matched that which was originally
	published.  There is no tecnological reason to that not to
	happen.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sun, 11 Feb 2007 04:33:47 +1100

Mark

---

From: Paul Vixie <[email-masked]>
Date: 10 Feb 2007 18:01:27 +0000

well, f-root is not RFC 2870 compliant on this point and never has been.

; <<>> DiG 9.3.1 <<>> @f.root-servers.net . axfr
; (2 servers found)
;; global options:  printcmd
...
;; Query time: 505 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Sat Feb 10 17:54:15 2007
;; XFR size: 2480 records (messages 2)

but i still think that massive global "mirroring" of the root zone would be
a bad idea.  opportunities for local errors, local staleness, leaks of local
polocy additions, outrun by a lot the potential unreachability due to ddos.
check http://www.root-servers.org/ to see how many cities are now served.
note that in last week's ddos, as in the one in 2002 (which was documented
at http://c.root-servers.org/october21.txt), no operational outages were
measured -- only monitoring geeks and root server operators even noticed.

http://public.oarci.net/oarc/workshop-2005/minutes/malone-slaves treated
this matter, and IIRC, i was not the only person in the room to think that
hints were better than slaves.

do we really need negative-BCP's?  that is, do we need a WCP on this topic?
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: 10 Feb 2007 18:01:27 +0000

---

From: [email-masked]
Date: Sat, 10 Feb 2007 18:55:06 +0000

>        the root zone up for ftp or other access on one or more less

singing...

$ dig . axfr @f.root-servers.net

; <<>> DiG 9.2.2 <<>> . axfr @f.root-servers.net
;; global options:  printcmd
.                       86400   IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2007021000 1800 900 604800 86400
.                       518400  IN      NS      A.ROOT-SERVERS.NET.
.                       518400  IN      NS      B.ROOT-SERVERS.NET.
.                       518400  IN      NS      C.ROOT-SERVERS.NET.
.                       518400  IN      NS      D.ROOT-SERVERS.NET.
.                       518400  IN      NS      E.ROOT-SERVERS.NET.
.                       518400  IN      NS      F.ROOT-SERVERS.NET.
.                       518400  IN      NS      G.ROOT-SERVERS.NET.
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
.                       518400  IN      NS      L.ROOT-SERVERS.NET.
.                       518400  IN      NS      M.ROOT-SERVERS.NET.
AC.                     172800  IN      NS      A.NIC.AC.
AC.                     172800  IN      NS      B.NIC.AC.
AC.                     172800  IN      NS      B.NIC.IO.
AC.                     172800  IN      NS      B.NIC.SH.
AC.                     172800  IN      NS      NS2.JP.IO.
AC.                     172800  IN      NS      NS2.UUCP.NE.JP.
AC.                     172800  IN      NS      NS3.ICB.CO.UK.
A.NIC.AC.               172800  IN      A       64.251.31.177
B.NIC.AC.               172800  IN      A       217.160.203.158
AD.                     172800  IN      NS      NS3.NIC.FR.
AD.                     172800  IN      NS      DNS2.AD.
...
ZW.                     172800  IN      NS      NS-ZW.RIPE.NET.
ZW.                     172800  IN      NS      NEWS-TOKYO.GIP.NET.
NS1.TELONE.CO.ZW.       172800  IN      A       194.133.122.47
NS2.TELONE.CO.ZW.       172800  IN      A       194.133.122.42
.                       86400   IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2007021000 1800 900 604800 86400
;; Query time: 2179 msec
;; SERVER: 192.5.5.241#53(f.root-servers.net)
;; WHEN: Sat Feb 10 10:52:37 2007
;; XFR size: 2481 records

for example.

--bill

---

From: [email-masked]
Date: Sat, 10 Feb 2007 18:55:06 +0000

singing...

for example.

--bill

---

From: Shane Kerr <[email-masked]>
Date: Sat, 10 Feb 2007 20:56:22 +0100

> $ dig . axfr @f.root-servers.net

<snip/>

> for example.

I think this recommendation in RFC 2780 is a bad one. B, C, F, G, and K all
allow AXFR and have not had problems with it AFAIK.

- --
Shane

---

From: Shane Kerr <[email-masked]>
Date: Sat, 10 Feb 2007 20:56:22 +0100

<snip/>

- --
Shane

---

From: Paul Wouters <[email-masked]>
Date: Sat, 10 Feb 2007 21:50:43 +0100 (CET)

On Sat, 10 Feb 2007, Pekka Savola wrote:

> As Bert mentioned in the next message, the risk of outdated (and therefor
> out-of-sync) roots is real.

I just compared the root zone as RedHat shipped it on Fri 07 Sep 2001,
with the root zone as published on root-servers.org, and only B and J
are different. So even using a 6 year old root zone will work fine in
the case of a flat out successfull attack against all root servers. I
will buy a beer for everyone on this list who doesn't have 6 year old
or newer root zone lying around within two hops of their desktop.

(and heck, if those are down, the collateral damage of that attack will
cause so much trouble than running with your 6 year old copy of the
root zone).

So, I think the "risk of outdated roots" is not something that has any
operational impact.

> Distributing the copies too far would create a
> similar situation as already happens when new IP address blocks are taken to
> use, and other networks still filter them as "bogons".  Experience with bogons
> has shown that there are always people who _don't_ update lists such as these
> yet still use them, and in the process degrade their users' service.

Note that the root zone and the bogon list are quite different issues and
shouldn't be compared. Using a six year old root zone has no impact, while
a week old bogon list will cause someone somewhere some serious pains.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 10 Feb 2007 21:50:43 +0100 (CET)

Paul

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 10 Feb 2007 23:07:47 +0100

> or newer root zone lying around within two hops of their desktop.

The root zone is slightly more than the hint file. You are confusing them. 

	(some output edited away for brevity...)

ftp> ls 
500 'EPSV': command not understood.
227 Entering Passive Mode (198,41,0,6,89,237)
150 Opening ASCII mode data connection for directory listing.
total 184
-rw-r--r--   1 9998     213          2517 Jan 28  2004 named.root
-rw-r--r--   1 9998     213         18051 Feb 10 12:06 root.zone.gz
226 Transfer complete.

The named.cache file does not change very often, not since 2004 according
to this list. The root zone changes more often, like every day. 

-- 
Måns Nilsson                     Systems Specialist
+46 70 681 7204   cell                       KTHNOC
+46 8 790 6518  office                  MN1334-RIPE

I didn't order any WOO-WOO ... Maybe a YUBBA ... But no WOO-WOO!
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 10 Feb 2007 23:07:47 +0100

ftp> ls

---

From: bert hubert <[email-masked]>
Date: Sat, 10 Feb 2007 23:53:47 +0100

> are different. So even using a 6 year old root zone will work fine in

That is the 'hints' file - the discussion is about the full root zone as
found on rs.internic.net, which has changed significantly over the years.

	Bert

---

From: bert hubert <[email-masked]>
Date: Sat, 10 Feb 2007 23:53:47 +0100

Bert

---

From: [email-masked]
Date: Sat, 10 Feb 2007 22:58:49 +0000

> or newer root zone lying around within two hops of their desktop.

	really?  there have been several new TLDs added in the past few years
	and dozens of glue changes.  I'd posit that the root zone of six years
	ago is quite a bit different than the root zone of today.

	and if B & J are different that A,C-I,K-M, then this should only be
	due to "rounding" error" of a few hours.

--bill

---

From: [email-masked]
Date: Sat, 10 Feb 2007 22:58:49 +0000

--bill

---

From: Akira Kato <[email-masked]>
Date: Sun, 11 Feb 2007 08:47:49 +0900 (JST)

> found on rs.internic.net, which has changed significantly over the years.

I think Paul's statement tells us that any update mechanisms depend on
operator interaction doesn't work rather than "root zone" or "hint"
thing.

If a caching server has the following functionality, the idea of "local
copy" may work:
- checks periodically (once in 86400sec?) if the zone has been updated
  recently
- download the zone with an automated process
  (question: what protocol to be used? from where?)

As the number of working caching server is huge, we may also need to ask
the caching server implementations which may not be straightforward:
- checks how many queries sent to the root servers in past 86400? sec
- goes into local copy mode if the count exceeds threshold value
- it also needs to identify if the query can be resolved with its regular
  cached record or with the local copy so that it can return back to
  non-local copy mode
- if transfer didn't succeded in past 172800? sec, goes back to non-local
  copy mode

-- Akira Kato, WIDE Project

---

From: Akira Kato <[email-masked]>
Date: Sun, 11 Feb 2007 08:47:49 +0900 (JST)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 11 Feb 2007 21:59:33 +0100

On Fri, Feb 09, 2007 at 11:09:51AM -0500,
 Joe Abley <[email-masked]> wrote 

> the stealth slave are succeeding.

Actually, the very old (I do not think there is a new version) RFC
2870 says the opposite:

   2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
       queries from clients other than other root servers.  

And I do not think there is a formal undertaking from Verisign to
publish ftp://rs.internic.net/domain/root.zone.gz either?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 11 Feb 2007 21:59:33 +0100

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 11 Feb 2007 22:38:15 +0100

On Sat, Feb 10, 2007 at 06:01:27PM +0000,
 Paul Vixie <[email-masked]> wrote 

> do we really need negative-BCP's?  that is, do we need a WCP on this

I don't know. What is the opinion of the group? And of our beloved
chairs? Any example of a WCP already existing in the IETF? 

And a volunteer to write one?

My first opinion would be that, yes, commonly held errors must be
documented and refuted. But, since I'm not volunteer to do it... (I
presume most people will prefer to attach their name to a "positive"
document.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 11 Feb 2007 22:38:15 +0100

---

From: Joe Abley <[email-masked]>
Date: Sun, 11 Feb 2007 16:54:54 -0500

> chairs? Any example of a WCP already existing in the IETF?

A WCP is just a BCP with a different title, surely. And there are  
plenty of examples of RFCs (whether published as BCP or not)  
suggesting that things should not be done:

http://www.google.com/search?q=rfc+%22considered+harmful%22

> And a volunteer to write one?

I have no problem putting fingers to keyboard if there seems at least  
some interest in the result.

Joe

---

From: Joe Abley <[email-masked]>
Date: Sun, 11 Feb 2007 16:54:54 -0500

Joe

---

From: Joao Damas <[email-masked]>
Date: Mon, 12 Feb 2007 11:03:19 +0100

Aren't you forgetting the users in all this thread?
Shouldn't users be able to get the DNS data clean from the actual  
authoritative servers or caching servers getting the information from  
there? rather than a who-knows-what-is-in-there zone served by a  
server which I can't verify?
If DNSSEC were deployed now at the root, problems would be less, but  
right now, I would rather be able to get info from the list of  
authoritative servers. Yes, I know about man in the middle, still, I  
would rather that not be my ISP.

Joao Damas
ISC

On 11 Feb 2007, at 22:54, Joe Abley wrote:

> I have no problem putting fingers to keyboard if there seems at  
> least some interest in the result.
>
>
> Joe
>
>

---

From: Joao Damas <[email-masked]>
Date: Mon, 12 Feb 2007 11:03:19 +0100

Joao Damas
ISC

---

From: Joe Abley <[email-masked]>
Date: Mon, 12 Feb 2007 06:35:47 -0500

> Aren't you forgetting the users in all this thread?

No, I don't think so.

> authoritative servers or caching servers getting the information  
> from there? rather than a who-knows-what-is-in-there zone served by  
> a server which I can't verify?

In my opinion, yes.

> If DNSSEC were deployed now at the root, problems would be less,  
> but right now, I would rather be able to get info from the list of  
> authoritative servers. Yes, I know about man in the middle, still,  
> I would rather that not be my ISP.

Seems we are in agreement on this point.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 12 Feb 2007 06:35:47 -0500

No, I don't think so.

In my opinion, yes.

Joe

---

From: Florian Weimer <[email-masked]>
Date: Thu, 22 Feb 2007 17:49:58 +0100

> measured -- only monitoring geeks and root server operators even noticed.

If I were looking for a reason to make resolvers authoritative for the
root, I'd favor accidental data leaks over increased reliability.  For
instance, if you hit the middle mouse button in a web browser window,
the data in the X selection might end up at the root servers, which is
probably not what you intended.  (It's harder to fix this than a name
server change because the .COM fallback is pretty widely implemented
AFAIK.)

On the other hand, if you care about such data leaks, you probably
shouldn't be using the Internet, at least from some computers.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 22 Feb 2007 17:49:58 +0100