Problem to transfer reverse zone DNS on secondary DNS servers

Matus UHLAR - fantomas uhlar at
Fri Dec 27 17:48:06 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.

On 27.12.19 08:58, Grant Taylor via bind-users wrote:
>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 

I think that it should be either change local DNS or call ISP to change it,
not both at once.  Having both usually creates/hides different kinds of

>>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 
> zone.

the ISP should the client what zone to configure, e.g.
and they put RFC 2317-like CNAME delegations to that.

As an ISP, I'd like to be configured as slave for that domain.

>>However, you should not set up multiple domains like those:
>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.)

Yes, it can work, but I personally don't like setting up multiple reverse
subdomains like this.  I believe configuring single domain for multiple
records is theway to go.

>The ISP inserts an NS record to delegate each subdomain 
>{17,19,22,26,30} 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.
>	IN	SOA (…)
>				IN	NS
>				IN	PTR
>>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 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.

in any case, if the OP needs to fixing things on the local side AND to call
ISP to change it, something is broken, or at least inefficiently

Matus UHLAR - fantomas, uhlar at ;
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fighting for peace is like fucking for virginity...

More information about the bind-users mailing list