Reverse DNS conditional forwardning

[Matus UHLAR - fantomas]

>>you just showed how parent zone (2.0.192.in-addr.arpa) must be 
>>configured for it.

On 18.01.18 12:58, Grant Taylor via bind-users wrote:
>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.

so, in fact you want the whole zone locally, override anything you like, but
forward some records to other servers?

DNS does not work that way.

in BIND this is not done by configuring zone data, but by configuring named
to forward zones.

zone "42.2.0.192.in-addr.arpa" {
	type static-stub;
	server-names {
		blackhole-1.iana.org;
		blackhole-2.iana.org;
	};
};

>>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.

I'm not sure this will help you. What you want is apparently asking for
troubles.

>>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 don't remember having any troubles with classless delegation.
unless someone misconfigured it, of course. but misconfigured DNS is a
problem of different kind.

>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.

what do dns blacklist have in common with classless delegation?
classless delegation means you are delegating subzone to other server.
Which blacklist ever tried to delegate subzone to other blacklist?

>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.

this may "work" when you have your own reverze zone and agree with other
owners on sharing. But from the internet, and from the DNS point of view,
you are creating problematic mess.

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.