Reverse DNS conditional forwardning

Grant Taylor gtaylor at tnetconsulting.net
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 
192.0.2.0/24 test network.

Adjust contents to reflect your needs.

> you just showed how parent zone (2.0.192.in-addr.arpa) 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
$ORIGIN 2.0.192.in-addr.arpa.
@    IN    SOA    prisoner.iana.org. hostmaster.root-servers.org. 
(2002040800 30m 15m 1w 1w)
1    IN    PTR    host1.example.net.
2    IN    PTR    host2.example.net.
; …
42    IN    PTR    host42.example.net.
; …

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
$ORIGIN 2.0.192.in-addr.arpa.
@    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    blackhole-1.iana.org.
42    IN    NS    blackhole-2.iana.org.
; …
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 
servers.

blackhole-[12].iana.org 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: <https://lists.isc.org/pipermail/bind-users/attachments/20180118/cb4fbaab/attachment.bin>


More information about the bind-users mailing list