Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

AXFR root zone

421 views
Skip to first unread message

Ronald F. Guilmette

unread,
Sep 28, 2014, 4:41:02 PM9/28/14
to bind-...@lists.isc.org

Is it possible to use dig to AXFR the root zone? I mean without having
any special foreknowledge of which specific root zone servers will and
will not accept the AXFR request? If so, how would I do that, exactly?

I tried this:

dig . axfr

but I just got back a "Transfer failed" error message.


Regards,
rfg


P.S. Strangely, this rather different query _does_ work:

dig @k.root-servers.net . axfr

So, um, it appears that "k" will allow the AXFR but, I gather, other
root zone servers won't (?)

As Seinfeld would say "What's up with that?"

Anand Buddhdev

unread,
Sep 28, 2014, 5:23:11 PM9/28/14
to Ronald F. Guilmette, bind-...@lists.isc.org
On 28/09/2014 22:41, Ronald F. Guilmette wrote:

Hi Ronald,

> Is it possible to use dig to AXFR the root zone? I mean without having

Yes, it is.

> any special foreknowledge of which specific root zone servers will and
> will not accept the AXFR request? If so, how would I do that, exactly?
>
> I tried this:
>
> dig . axfr
>
> but I just got back a "Transfer failed" error message.

This query is sent to one of the *recursive* servers in your
/etc/resolv.conf file, so it can't provide you with a zone transfer of
the root zone. Unlike other query types, an AXFR is not recursively
looked up by a resolver.

> P.S. Strangely, this rather different query _does_ work:
>
> dig @k.root-servers.net . axfr
>
> So, um, it appears that "k" will allow the AXFR but, I gather, other
> root zone servers won't (?)

Speaking as the operator of K-root, I can confirm that K allows zone
transfers. That's why this query works.

Regards,

Anand Buddhdev
RIPE NCC

Ronald F. Guilmette

unread,
Sep 28, 2014, 5:59:06 PM9/28/14
to bind-...@lists.isc.org

In message <54287C3...@ripe.net>,
Anand Buddhdev <ana...@ripe.net> wrote:

>... Unlike other query types, an AXFR is not recursively
>looked up by a resolver.

Ah! Ok. That certainly explains the failure then. Thank you for
enlightening me!

>> P.S. Strangely, this rather different query _does_ work:
>>
>> dig @k.root-servers.net . axfr
>>
>> So, um, it appears that "k" will allow the AXFR but, I gather, other
>> root zone servers won't (?)
>
>Speaking as the operator of K-root, I can confirm that K allows zone
>transfers. That's why this query works.

Wow! I am delighted that I've been able to get an answer to my
question direct "from the horse's mouth" as we say... and on a
Sunday even! So, um, THANK YOU for that.

But please allow me a couple of follow-up questions also...

It appears to me that the "a" root server _does not_ allow the
zone transfer. My guess is that the operators of that server
wished to prevent every impertinent fellow (like me) and his
brother from all writing scripts which would run frequently and
which would always suck copies of the root zone from the most
obvious candidate, i.e. a.root-servers.net. Is that approximately
correct? Or are the operators of the "a" server just less
friendly/accomodating folks than you? ;-)

Do 100% of the other (non-a) root zone servers support axfr for
the root zone? (I only checked "b", "c", and your's, "k", but
those all seem to do so.)

Is the openness of your server (to root zone axfrs) a policy choice
that I can rely on, i.e. that is likely to be in place for the
forseeable future?

I ask because I have indeed written a script which I will be running
on the order of once per day, and which needs to be able to suck
down a copy of the root zone. May I rely on this continuing to
work for the forseeable future if I hardcode my little script with
the name "k.root-servers.net"? Or is there a better choice for
the long term?


Regards,
rfg

staticsafe

unread,
Sep 28, 2014, 6:02:58 PM9/28/14
to bind-...@lists.isc.org
On 9/28/2014 17:59, Ronald F. Guilmette wrote:
>
> I ask because I have indeed written a script which I will be running
> on the order of once per day, and which needs to be able to suck
> down a copy of the root zone. May I rely on this continuing to
> work for the forseeable future if I hardcode my little script with
> the name "k.root-servers.net"? Or is there a better choice for
> the long term?
>
>
> Regards,
> rfg

Hi,

I suggest using:
xfr.lax.dns.icann.org
xfr.cjr.dns.icann.org

As mentioned on http://www.dns.icann.org/services/axfr/. I found out
about it via a comment in the named.conf shipped in the FreeBSD ports
version.

--
staticsafe
https://staticsafe.ca

Jaap Akkerhuis

unread,
Sep 28, 2014, 6:27:32 PM9/28/14
to Ronald F. Guilmette, bind-...@lists.isc.org
>
> I ask because I have indeed written a script which I will be running
> on the order of once per day, and which needs to be able to suck
> down a copy of the root zone. May I rely on this continuing to

some of the root-servers allow an axfr, but you are probably better off
looking at <http://www.internic.net>, especially
<http://www.internic.net/domain/>.

jaap

Ronald F. Guilmette

unread,
Sep 28, 2014, 6:39:59 PM9/28/14
to bind-...@lists.isc.org

In message <54288592...@staticsafe.ca>,
Oh! Excellent! This is *exactly* what I needed! Thanks ever so
much.


Regards,
rfg

Anand Buddhdev

unread,
Sep 28, 2014, 6:54:13 PM9/28/14
to Ronald F. Guilmette, bind-...@lists.isc.org
On 28/09/2014 23:59, Ronald F. Guilmette wrote:

Hi Ronald,

> Wow! I am delighted that I've been able to get an answer to my
> question direct "from the horse's mouth" as we say... and on a
> Sunday even! So, um, THANK YOU for that.

You're welcome :)

> It appears to me that the "a" root server _does not_ allow the
> zone transfer. My guess is that the operators of that server
> wished to prevent every impertinent fellow (like me) and his
> brother from all writing scripts which would run frequently and
> which would always suck copies of the root zone from the most
> obvious candidate, i.e. a.root-servers.net. Is that approximately
> correct? Or are the operators of the "a" server just less
> friendly/accomodating folks than you? ;-)

I'm afraid I cannot speak for Verisign, the operator of A-root.

> Do 100% of the other (non-a) root zone servers support axfr for
> the root zone? (I only checked "b", "c", and your's, "k", but
> those all seem to do so.)

Some do, and some don't. I don't know off the top of my head, but you
can query and find out.

> Is the openness of your server (to root zone axfrs) a policy choice
> that I can rely on, i.e. that is likely to be in place for the
> forseeable future?

Yes, we have chosen to allow zone transfers, so we will keep providing
them for the foreseeable future.

> I ask because I have indeed written a script which I will be running
> on the order of once per day, and which needs to be able to suck
> down a copy of the root zone. May I rely on this continuing to
> work for the forseeable future if I hardcode my little script with
> the name "k.root-servers.net"? Or is there a better choice for
> the long term?

If you wanted your script to be robust, then you would program it with
the names of all 13 root name servers, and have it try the zone
transfers from a random server each time, and trying another one in case
of failure.

However, you're better off using ICANN's dedicated zone transfer
servers. See this URL for details:

http://www.dns.icann.org/services/axfr/

Ronald F. Guilmette

unread,
Sep 28, 2014, 7:08:16 PM9/28/14
to bind-...@lists.isc.org

In message <54289195...@ripe.net>,
Anand Buddhdev <ana...@ripe.net> wrote:

>If you wanted your script to be robust, then you would program it with
>the names of all 13 root name servers, and have it try the zone
>transfers from a random server each time, and trying another one in case
>of failure.

Yes, actually. Thank you. A prior version of my script did exactly
that. But I just hacked out all of that rather clumsy code, because
it seems that it is no longer necessary.

>However, you're better off using ICANN's dedicated zone transfer
>servers. See this URL for details:
>
>http://www.dns.icann.org/services/axfr/

YESSSSSS! I'm already on it...

=============================================================================
...
my $res = Net::DNS::Resolver->new (nameservers => ['xfr.lax.dns.icann.org',
'xfr.cjr.dns.icann.org']);
my @rr_list = $res->axfr ('.');
...
=============================================================================

Works great!

Thanks again.


Regards,
rfg
0 new messages