Reverse DNS conditional forwardning
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 /
> 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
; Mach Global zone file
@ 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
@ 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
blackhole-.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...
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
More information about the bind-users