On 25 Jun 2008, at 18:20, Dean Anderson wrote:
So why deny AXFR from roots, then?
I'll note that this is a matter for individual root operators, so the
question is better directed at them, individually. However, as a
trivial refutation of the implication that all root servers deny AXFR,
see the following:
[calamari:~]% for n in $(jot -w "%c.root-servers.net" 13 a); do
for> echo -n "${n} does "
for> dig @${n} . axfr | grep -q 'Transfer failed' && echo -n "not "
for> echo "leave AXFR wide open, at least for this client"
for> done
a.root-servers.net does not leave AXFR wide open, at least for this
client
b.root-servers.net does leave AXFR wide open, at least for this client
c.root-servers.net does leave AXFR wide open, at least for this client
d.root-servers.net does not leave AXFR wide open, at least for this
client
e.root-servers.net does not leave AXFR wide open, at least for this
client
f.root-servers.net does leave AXFR wide open, at least for this client
g.root-servers.net does leave AXFR wide open, at least for this client
h.root-servers.net does not leave AXFR wide open, at least for this
client
i.root-servers.net does not leave AXFR wide open, at least for this
client
j.root-servers.net does not leave AXFR wide open, at least for this
client
k.root-servers.net does leave AXFR wide open, at least for this client
l.root-servers.net does not leave AXFR wide open, at least for this
client
m.root-servers.net does not leave AXFR wide open, at least for this
client
[calamari:~]%
BTW, did the root zone actually change today (2008062500)?
Yes. (The SOA RDATA changed, at least). Forming your own deltas by
doing a zone transfer every day and exercising diff is not rocket
science, either. The implication that the nature of changes is somehow
secret seems to fly in the face of common sense.
To all those who are about to mail me privately about feeding trolls,
no need, I know, I know.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
