Apologies for cross-posting, but I believe this relevant to the NANOG operator community.
FYI,
/John
John,
Congratulations to you and ICANN for this significant step, at all the various layers and meanings of significant. 
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:
1. Was that a conscious decision, and if so why?
2. Is there any hope that axfr could be permitted in the future?
Of course, if you're not the right person to ask feel free to redirect me.
Best regards,
Doug
Doug -
Excellent questions (of which I do not know the answer)
Allow me some time for research.
Thanks!
/John
John Curran
President and CEO
ARIN
No no, thank YOU.
Doug
Hi Doug,
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:
1. Was that a conscious decision, and if so why?
It's a question for the individual operators of the servers. I can only speak for the particular servers that ICANN operates.
ICANN operates B.IN-ADDR-SERVERS.ARPA and B.IP6-SERVERS.ARPA. As with L-Root, we don't permit zone transfers from the servers themselves; our goal with the nameservers themselves is to provide them with as much headroom as possible for answering DNS queries, and it has never seemed to us that also responding to AXFR is going to help with that.
We do however support open zone transfers for the root zone, ARPA, IN-ADDR.ARPA and IP6.ARPA from two locations for anybody who cares to use them:
xfr.lax.dns.icann.org
xfr.cjr.dns.icann.org
The availability of these servers for AXFR is documented at <http://dns.icann.org/services/axfr/>\.
Joe
Hi Doug,
Relevant to another post today, I've noticed that neither the
*.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which
leads to the following questions:
1. Was that a conscious decision, and if so why?
It's a question for the individual operators of the servers. I can
only speak for the particular servers that ICANN operates.
ICANN operates B.IN-ADDR-SERVERS.ARPA and B.IP6-SERVERS.ARPA. As with
L-Root, we don't permit zone transfers from the servers themselves; our
goal with the nameservers themselves is to provide them with as much
headroom as possible for answering DNS queries, and it has never seemed
to us that also responding to AXFR is going to help with that.
We do however support open zone transfers for the root zone, ARPA,
IN-ADDR.ARPA and IP6.ARPA from two locations for anybody who cares to
use them:
xfr.lax.dns.icann.org
xfr.cjr.dns.icann.orgThe availability of these servers for AXFR is documented
at<http://dns.icann.org/services/axfr/>\.
Joe,
Thanks for clarifying. I almost included "is axfr available from any
other source?" as a 3rd question, but figured that would come out in the
wash. 
This leads to 2 additional questions:
1. Is the zone available from those 2 locations "the same" as what's
available on the authoritative servers, or is there a lag time between
updates on the auth and the xfr servers?
2. Is there any objection to having those servers listed in publicly
available documentation on how to configure resolvers to slave the root
and related zones?
Thanks again,
Doug
- --
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. http://SupersetSolutions.com/
This leads to 2 additional questions:
1. Is the zone available from those 2 locations "the same" as what's
available on the authoritative servers, or is there a lag time between
updates on the auth and the xfr servers?
The two servers mentioned transfer the zone from the same place as the *.in-addr-servers.arpa servers. They're a little closer than some of the other servers. I imagine some propagation lag between them would be visible with the right instrumentation. The speed of light is the speed of light.
2. Is there any objection to having those servers listed in publicly
available documentation on how to configure resolvers to slave the root
and related zones?
My personal opinion is that such advice is misguided, but we place no restrictions on the soundness of the reasons for transferring zones from those places
Joe
Would it break DNSSEC ?
From: "Joe Abley"<jabley@hopcount.ca>
To: "Doug Barton"<dougb@dougbarton.us>
Cc: "John Curran"<jcurran@arin.net>, "NANOG"<nanog@merit.edu>
Sent: Thursday, 17 February, 2011 12:05:16 PM
Subject: Re: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete2. Is there any objection to having those servers listed in publicly
available documentation on how to configure resolvers to slave the
root
and related zones?My personal opinion is that such advice is misguided,
Yes, I know. I obviously believe that reasonable minds can differ on this topic, but as we've gone round about this before and I don't want to get too deep in the DNS weeds I'll just say that I respect your perspective on this topic, even though I disagree with it.
I should also add that the fact that this configuration can get out of sync and cause problems is not to be taken lightly. When I first started using and recommending this configuration 10 years ago my feeling was that the days of "set it and forget it" DNS were coming to an end since DNSSEC was "just around the corner." I was wrong about that on both counts, but I still believe that for those that are willing and able to take appropriate care with their DNS infrastructure that this configuration is a win.
but we place no
restrictions on the soundness of the reasons for transferring zones
from those placesWould it break DNSSEC ?
No. In my current configuration I have the root zone trust anchor configured and I just re-configured it to download ip6.arpa and in-addr.arpa from the ICANN servers Joe mentioned. Note the "ad" bit:
dig @127.0.0.1 6.0.1.0.0.2.ip6.arpa. ns +dnssec
; <<>> DiG 9.8.0rc1 <<>> @127.0.0.1 6.0.1.0.0.2.ip6.arpa. ns +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39677
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;6.0.1.0.0.2.ip6.arpa. IN NS
;; ANSWER SECTION:
6.0.1.0.0.2.ip6.arpa. 172800 IN NS sns-pb.isc.org.
6.0.1.0.0.2.ip6.arpa. 172800 IN NS sec3.apnic.net.
6.0.1.0.0.2.ip6.arpa. 172800 IN NS sunic.sunet.se.
6.0.1.0.0.2.ip6.arpa. 172800 IN NS tinnie.arin.net.
6.0.1.0.0.2.ip6.arpa. 172800 IN NS ns3.nic.fr.
6.0.1.0.0.2.ip6.arpa. 172800 IN NS sec1.apnic.net.
6.0.1.0.0.2.ip6.arpa. 172800 IN NS ns-pri.ripe.net.
6.0.1.0.0.2.ip6.arpa. 172800 IN NS munnari.oz.au.
6.0.1.0.0.2.ip6.arpa. 172800 IN RRSIG NS 5 8 172800 20110318135006 20110216125006 63865 6.0.1.0.0.2.ip6.arpa. fe3wJGI5KHjrR2HasKojm8gpJxpQXcPY5Piy7c58XmSyzKlONxOTwvdC +Cjlw/XCfWCSc6IjNlmJm7kACRtQrOrv2PnvYan+1yslAJyguoTvl56j N+nOTD0VDlNeInKkonn/attHWvV+c05gxdXLEkW11PSdF1xtkDKgPkwV n54=
;; Query time: 376 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 16 16:07:34 2011
;; MSG SIZE rcvd: 435
Sorry, this probably should be moved to dns-ops, but this may
interest some of the network operators here.
Doug Barton (dougb) writes:
I should also add that the fact that this configuration can get out
of sync and cause problems is not to be taken lightly. When I first
started using and recommending this configuration 10 years ago my
feeling was that the days of "set it and forget it" DNS were coming
to an end since DNSSEC was "just around the corner." I was wrong
about that on both counts, but I still believe that for those that
are willing and able to take appropriate care with their DNS
infrastructure that this configuration is a win.
Not to tread on a landmine, but reading /etc/namedb/named.conf
on a (recent) FreeBSD, it states:
[...]
Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
[...]
(note that other zones can be configured to be slaved per the
above setup, but I'm only mentioning root for the sake of the
discussion)
In order:
Point 1:
After the NS has primed itself, and has been running for a few
minutes, how much faster are we talking about ? Is this something
you have some numbers on ? Is it measurable from a user experience
point of view ? Is there a sweet spot/ROI of sorts on scale ranging
from "small network" to "large corporation" ?
With ~300 TLDs in the forward space (don't know how many
subdelegations in-addr.arpa has off the top of my head), is this a
real, noticeable win ?
Imagining that the new vTLDs are a success, and this grows to
potentially thousands of new TLDs, what's the projected improvement
value from this setup ? Does it become a handicap ?
Point 2:
I've heard that 98% of traffic to the root is junk, but since
NXDOMAINs get quickly neg cached, how much bandwidth conservation
and resource preservation are we talking about ? If one takes
AS112 into account, how much improvement is this ?
Point 3:
Do we have a historical scenario where DDoS has effectively
hindered DNS resolution for caching nameservers to the extent
that they couldn't look up non-cached TLD records/prime themselves
at startup ?
Analysis of a big DoS attack in 2006, IIRC, did nothing more
that slow down somewhat some of the affected anycast instances.
Now, I'm not being skeptical here, but you put the arguments for
slaving the top level zones as a win-only situation. So I feel
compelled to ask you to back those claims, especially considering
the tradeoff in complexity and stability it entails with regards to
monitoring requirements.
The days of "set if and forget it" for DNS may be gone, but it's
no reason to make life unnecessarily complex for system administrators,
and while it's a personal choice to enable slaving, your recommending
it should be thoroughly justified
Cheers,
Phil
Congrats to all on getting this done! It's been a long time in coming. Good to see it finally finished.
Regards,
-drc
If that's the CAIDA paper I'm thinking of, a lot of the 98% junk was the sort
of stuff you'd expect from broken sites who probably won't do neg caching
right - and in fact, a significant portion (30%?) was *specifically* sources
that failed to negative cache a reply and asking over and over again, often
multiple times a second.
Of course, those sort of broken sites probably will manage to screw up
deploying a local hints file, resulting in *more* traffic at the roots
Not to tread on a landmine,
Actually it seems like you want to jump up and down on it. Given that both the benefits and the potential problems have been extensively debated elsewhere, I'll simply say that you raise interesting questions that I think people interested in this method should answer for themselves.
Now, I'm not being skeptical here, but you put the arguments for
slaving the top level zones as a win-only situation.
And for me, and a lot of others it has been. If you have something new to contribute in regards to the negatives I'm happy to listen, although this might not be the best forum.
Doug
Doug Barton (dougb) writes:
Actually it seems like you want to jump up and down on it. Given
that both the benefits and the potential problems have been
extensively debated elsewhere, I'll simply say that you raise
interesting questions that I think people interested in this method
should answer for themselves.
So, you're advocating a method that potentially fragilizes one's
DNS infrastructure, but you're not providing factual data backing
up the purported advantages, and actually leave it up to the users to
find out for themselves ? Gee, that's a seller
> Now, I'm not being skeptical here, but you put the arguments for
> slaving the top level zones as a win-only situation.And for me, and a lot of others it has been. If you have something
new to contribute in regards to the negatives I'm happy to listen,
although this might not be the best forum.
Well, I was trying to raise constructive criticism - and hoped you
would reply by providing links to resources/references summarizing the
advantages, with more than empirical claims.
But agreed, this is best discussed elsewhere
Cheers,
Phil
Doug Barton (dougb) writes:
Actually it seems like you want to jump up and down on it. Given
that both the benefits and the potential problems have been
extensively debated elsewhere, I'll simply say that you raise
interesting questions that I think people interested in this method
should answer for themselves.So, you're advocating
This is the second time you've made this claim, I ignored it the first time, but let me be clear. I'm not advocating anything. Someone else asked if it made sense to do so, and I responded. Yes, the FreeBSD named.conf states that there are advantages to this method, it also states that there are things to be careful about.
a method that potentially fragilizes one's
DNS infrastructure, but you're not providing factual data backing
up the purported advantages,
Nope, I'm saying that it's all been discussed before, and this isn't the forum to discuss it in more detail.
and actually leave it up to the users to
find out for themselves ? Gee, that's a seller
I think you'd be pretty foolish to not carefully weigh the pros and cons for yourself before making any change of this nature to something as critical as DNS, and I include things that I _do_ advocate in that category like DNSSEC and IPv6.
Now, I'm not being skeptical here, but you put the arguments for
slaving the top level zones as a win-only situation.And for me, and a lot of others it has been. If you have something
new to contribute in regards to the negatives I'm happy to listen,
although this might not be the best forum.Well, I was trying to raise constructive criticism - and hoped you
would reply by providing links to resources/references summarizing the
advantages, with more than empirical claims.But agreed, this is best discussed elsewhere
Funny how you keep saying that ....
Doug
Hi,
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa
nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:1. Was that a conscious decision, and if so why?
Speaking for the operator of f.in-addr-servers.arpa and f.ip6-servers.arpa this
was simply not on our radar.
2. Is there any hope that axfr could be permitted in the future?
Since we are also operating k.root-servers.net and have provided XFR from it for
all this time we will do so for these servers as well. This has now been enabled
on our systems.
Regards,
Wolfgang Nagele
RIPE NCC DNS Group Manager
You're very welcome however, the work is not quiet yet done. Next steps are:
week of 2011-02-21: IN-ADDR.ARPA zone dropped from B, C, E, G, I, M root servers
week of 2011-02-28: IN-ADDR.ARPA zone dropped from A, D, F, H, K, L root servers
week of 2011-03-06: DS record for IN-ADDR.ARPA inserted into ARPA zone
At the end of this process every subdomain of ARPA will be fully DNSSEC-signed.
Query rates on the new servers (those operated by the RIRs and ICANN) are currently low, but are expected to increase as the IN-ADDR.ARPA zone is dropped from root servers. Some stats on the ICANN-operated servers can be found here:
http://dns.icann.org/services/inaddr-arpa/
http://dns.icann.org/services/ip6-arpa/
(click through on the graphs for more detail)
Joe
At the end of this process every subdomain of ARPA will be fully DNSSEC-signed.
Cool.
Query rates on the new servers (those operated by the RIRs and ICANN) are currently low, but are expected to increase as the IN-ADDR.ARPA zone is dropped from root servers.
It'll be interesting to see what the corresponding drop in traffic in the root servers will be...
Regards,
-drc
Hi,
It'll be interesting to see what the corresponding drop in traffic in the root servers will be...
We expect it to be around 2000qps (or ~8% of the total traffic) for
k.root-servers.net. PTR query rates are very steady and do not follow the
general diurnal cycle.
Regards,
Wolfgang
Thanks! I sort of suspected that this was the case at least for the servers operated by RIPE NCC because of the history with K as you pointed out above. I appreciate your quick attention to this issue, and my (admittedly non-comprehensive) tests indicate that f.ip6-servers.arpa and f.in-addr-servers.arpa are indeed now allowing transfers.
Best Regards,
Doug