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