[arin-announce] IN-ADDR.ARPA Zone Transfer Complete
dougb at dougbarton.us
Wed Feb 16 18:18:35 CST 2011
On 02/16/2011 15:13, Franck Martin wrote:
> ----- Original Message -----
>> From: "Joe Abley"<jabley at hopcount.ca>
>> To: "Doug Barton"<dougb at dougbarton.us>
>> Cc: "John Curran"<jcurran at arin.net>, "NANOG"<nanog at merit.edu>
>> Sent: Thursday, 17 February, 2011 12:05:16 PM
>> Subject: Re: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete
>> On 2011-02-16, at 17:33, Doug Barton wrote:
>>> 2. Is there any objection to having those servers listed in publicly
>>> available documentation on how to configure resolvers to slave the
>>> 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 places :-)
> Would 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 184.108.40.206.0.2.ip6.arpa. ns +dnssec
; <<>> DiG 9.8.0rc1 <<>> @127.0.0.1 220.127.116.11.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:
;18.104.22.168.0.2.ip6.arpa. IN NS
;; ANSWER SECTION:
22.214.171.124.0.2.ip6.arpa. 172800 IN NS sns-pb.isc.org.
126.96.36.199.0.2.ip6.arpa. 172800 IN NS sec3.apnic.net.
188.8.131.52.0.2.ip6.arpa. 172800 IN NS sunic.sunet.se.
184.108.40.206.0.2.ip6.arpa. 172800 IN NS tinnie.arin.net.
220.127.116.11.0.2.ip6.arpa. 172800 IN NS ns3.nic.fr.
18.104.22.168.0.2.ip6.arpa. 172800 IN NS sec1.apnic.net.
22.214.171.124.0.2.ip6.arpa. 172800 IN NS ns-pri.ripe.net.
126.96.36.199.0.2.ip6.arpa. 172800 IN NS munnari.oz.au.
188.8.131.52.0.2.ip6.arpa. 172800 IN RRSIG NS 5 8 172800 20110318135006
20110216125006 63865 184.108.40.206.0.2.ip6.arpa.
;; 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
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/
More information about the NANOG