Reverse DNS conditional forwardning

[Grant Taylor]

On 01/25/2018 07:29 AM, Matus UHLAR - fantomas wrote:
> so, in fact you want the whole zone locally, override anything you like, 
> but forward some records to other servers?

Yes.

> DNS does not work that way.

I have successfully used this technique many times, including for 
resolvers in the wild and local.

I've specifically used this a number of times for IN-ADDR.ARPA 
delegation with great success.  -  No problems have been reported by 
anybody and all tests that I've repeatedly run over the years from 
multiple locations have always worked without any problems.

So, I do believe that it does in fact work.  It may not be proper and 
pure, but it does function exactly as I need it to.

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

That would require configuring multiple zones.  Why would I want to do 
that when my method works flawlessly (with every test that I and others 
have thrown at it) and uses a single zone.

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

Thank you for an example of proper syntax.

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

I've not had any troubles with this technique in 10+ years.

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

I've had problems with multiple things not properly following the CNAME 
chain in RFC 2317 Classless IN-ADDR.ARPA Delegation.  Years ago I had a 
notable and popular RBL completely fail at following RFC 2317 Classless 
IN-ADDR.ARPA Delegation and black list multiple servers that were 
perfectly configured.  (Read: RBL script parsing bug.)  Ultimately email 
servers were erroneously black listed indirectly because of RFC 2317 
Classless IN-ADDR.ARPA Delegation.

Around the same time I learned about the delegation method that I now 
use.  All of my tests showed that the delegation worked the way that I 
wanted and no side effects or problems.

I also collaborated with the RBL operator (that's how I found out that 
it was a bug) and he admitted that his script(s) did not process RFC 
2317 Classless IN-ADDR.ARPA Delegation.  (I believe that he updated his 
scripts after I reported the problem to him.)  We also discussed the 
method that I'm using and he confirmed that his scripts would not have 
had any problem with it.

So, in light of the problems I experienced while correctly using RFC 
2317 Classless IN-ADDR.ARPA Delegation and issues helping others get it 
set up, combined with the simplicity of simple cross delegation, I 
decided to favor delegation in lieu of RFC 2317.

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

I've had this deployed for in-addr.arpa delegation for a number of 
different prefixes over the last 10 years and it has worked 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/20180125/876b3335/attachment.bin>