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