I'm trying to set up reverse zones in nsd for the netblock I've been
delegated. I'm having trouble getting it to work, and I'm not sure
why. I've done this on bind many times before. So, at this point,
I'm trying to determine if the problem is on my end, or the delegation
(ISP's) end. Would someone mind walking me through the steps to get
this running on nsd (and/or to debug the delegator).
What I find strange is that I've been asked to allow AXFR from one of
their DNS servers (I guess it's going to secondary my PTR's... but
why?), and to include it (the NS record for their server) in my
reverse zone file. I've never had to do this before, so maybe someone
on here can give me hints as to how to do this correctly. Here's what
I've done (provide-xfr IP's mangled for security reasons):
RFC-2317 (e.g., 0/27.3.168.192.in-addr.arpa) <<-- verified with ISP
that's how they're providing them.
Quick reply before I log off, but it seems you are missing
zone:
name: "192/26.187.206.74.in-addr.arpa"
zonefile: db.192-255.187.206.74.rev
provide-xfr: 24.456.879.932/26 intrakey
notify: 24.456.879.91 intrakey # this
provide-xfr: 74.96.313.32 interkey
notify: provide-xfr: 74.96.313.32 interkey # and this
Note that the notify is not a netblock but a specific address.
Also the key could be NOKEY for the notify (if their software cannot
handle TSIGs on notifies).
So, your config provides the axfr, but does not send a notify to the
secondary, so it does not know when to ask...
The above sends notifies to the two servers.
That PTR record also looks fishy; it points to itself. Maybe you mangled
this in this email only.
As an aside, we provide a way to configure axfr permission and notify
separately, to help deployment in different situations. I believe that
BIND needs the server listed in the NS records to send it notifies. NSD
does not need that, it needs notify: lines. I thought BIND had
also-notify {}; to do the same thing.
Best regards (and a happy christmas break ),
Wouter
the background was to enable the parent to respond with the CNAME target
at the same time as the CNAME (so the CNAME wouldn't have to be followed
by either the responding server or the resolver). With all the new
restrictions on the answer section, indirection and CNAME (and DNAME) targets,
this migfht no longer be too important today, indeed.
What is and has been a good idea, though, is to have a (stealth) secondary
of the delegating zone (the one with the RFC 2317 CNAME RRs) on the side of the
client, so the reverse resolution works independent of any connection to the ISP.
Both issues could go into an update of or amendment to RFC 2317.
),