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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
