Problem to transfer reverse zone DNS on secondary DNS servers

Grant Taylor gtaylor at tnetconsulting.net
Fri Dec 27 15:58:04 UTC 2019


On 12/27/19 7:04 AM, Matus UHLAR - fantomas wrote:
> there's  obviously something broken in this setup.  You don't have to 
> call the ISP if the reverse DNS changes.

Why do you say that?

What do you see that's broken in the OP's configuration?

I personally didn't see anything broken.  Hence why reverses DNS worked 
when querying the local server.

The only thing that I saw was a slip in that there is something outside 
the local DNS server that needs to be configured for reverse DNS.

> Either they set up reverse DNS for you completely, or they tell yuou 
> what domain to set up, you set it up

I don't have any overt objection to that part of the statement.

> they configure it for fetching from your servers.

I do object to this part of the statement.

This seems to imply that the ISP is a secondary DNS server and doing 
zone transfers off of their customer.

This can be made to work, but it still suffers from the typical problems 
associated with shared administration of the 247.2.186.in-addr.arpa zone.

> However, you should not set up multiple domains like those:
> 19.247.2.186.in-addr.arpa
> 17.246.2.186.in-addr.arpa
> 22.246.2.186.in-addr.arpa
> 26.246.2.186.in-addr.arpa
> 30.246.2.186.in-addr.arpa

This may not be typical, but it can work perfectly fine.  I've done this 
many times in the past.  (I'd still be doing it if I had a need for it.)

The ISP inserts an NS record to delegate each subdomain 
{17,19,22,26,30}.247.2.186.in-addr.arpa to the client's DNS server which 
is authoritative for said zones.  Said zones would include a PTR in 
their apex.  It works perfectly fine.

17.246.2.186.in-addr.arpa.	IN	SOA	rname.example.net. mname.example.net. (…)
				IN	NS	mname.example.net.
				IN	PTR	smtp.pasteur-cayenne.fr.

> rfc 2317 describes how reverse DNS should be set up and it should work 
> automatically.

RFC 2317 Classless IN-ADDR.ARPA Delegation is one possible way to set 
things up.  There are others.  E.g.

  · Proper DNS delegation (as described above).
  · ISP allowing Dynamic DNS updates of their in-addr.arpa. zone.
  · Cross delegation hack.
  · Reverse DNS zone backed by something more intelligent than a 
traditional zone file.  E.g. LDAP (AD) or a database.

I personally dislike RFC 2317's CNAME based delegation.

  · I find it be unnecessarily complex and error prone, particularly for 
people not accustom to it.
  · It includes possible suggestions that many DNS servers can't use 
("/" as the separator character).
  · It imples that the sub-domain has some relation to the network size 
being delegated.  When in fact, the sub-domain could easily be any 
arbitrary identifier.  The customer ID might be a good choice.
  · It does not lend itself to discontinuous IPs, particularly if 
following the prefix related subdomain recommendations.
  · I find it's wording to be abstracted to the point of being ambiguous 
to a fault.

I strongly prefer standard DNS delegation via NS records.  This can go 
to discrete zones like the OP has / my example above.  Or it can be a 
cross delegation hack.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20191227/784272a2/attachment.bin>


More information about the bind-users mailing list