Reverse DNS conditional forwardning

Grant Taylor gtaylor at
Thu Jan 18 19:58:45 UTC 2018

On 01/18/2018 12:08 PM, Matus UHLAR - fantomas wrote:
> you can create something very similar, not necessarily classless. 
> simply redirect reverse names via CNAME to other zone. very standard.

Yes.  But that requires that something is done in the authoritative / 
parent zone.

> what's the point of redirecting reverse DNS to blackholes?

I was using blackholes as the example, which should be accurate for the test network.

Adjust contents to reflect your needs.

> you just showed how parent zone ( must be configured 
> for it.

No, I did not.  The following zone is the authoritative zone, as seen by 
the world.

; Mach Global zone file
@    IN    SOA 
(2002040800 30m 15m 1w 1w)
1    IN    PTR
2    IN    PTR
; …
42    IN    PTR
; …

Note that nothing has been done in the authoritative zone.

The following is the zone that would go on the local server that would 
override the globally authoritative zone.

; Mach local zone file
@    IN    SOA    myLocalServer.myLocalDomain.myTld. 
myEmail.myPublicDomain.myTld. (2002040800 30m 15m 1w 1w)
1    IN    PTR    client1.myLocalDomain.myTld.
2    IN    PTR    client2.myLocalDomain.myTld.
; …
42    IN    NS
42    IN    NS
; …
96    IN    PTR    server3.myLocalDomain.myTld.
97    IN    PTR    oldServer3.myLocalDomain.myTld.
; …

This local copy is where the changes are made to override what the 
globally authoritative zone serves.  (Like I think the OP was indicating 
s/he was doing.)

The NS records for 42 in the local zone ""delegate back to the parent 

blackhole-[12] happen to be the NS servers for the example 
zone.  Modify as appropriate for what you want to do.

> what you describe is how dj bernstein proposed reverse delegation.

I was not aware of that.  I'll have to look into his proposed solution.

> However it's much better to define subzone and redirect records via 
> CNAMEs to it. it's easier to define one subzone with a few NS records 
> pointing to it and replace each PTR with CNAME than replace each PTR 
> with multiple NSes.

I'm going to have to disagree with you.  I have used both RFC 2317 
Classless IN-ADDR.ARPA (type) delegation and the delegation that I'm 
suggesting multiple times.  Every time I've used Classless IN-ADDR.ARPA 
(type) delegation has resulted in heartache or worse.  I've even 
personally experienced cases where Spam RBLs failed miserably with RFC 
2317 Classless IN-ADDR.ARPA and ended up black listing things 
inappropriately.  I have had zero problems with the type of delegation 
that I'm advocating.

Combining the fact that 2317 Classless IN-ADDR.ARPA (type) delegation 
requires support in the authoritative / parent zone with the problems 
that I've seen and the fact that I've not seen any problems with my 
alternate, I'll continue using my alternate.

As a bonus, it's entirely possible to do cross delegation using my 
method without any problems.  I can have two clients using /25, each 
cross delegating the others part, and things work out quite well.

Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the bind-users mailing list