On Thu, Sep 29, 2011 at 04:52:10PM -0500, Michael Graff wrote: > I'm happy you read it, and hope to see you at the forum/customer webinar next > week! I'll be speaking, and will bring my fireproof undies.
I'm already signed up, but no worries about flaming - at least not from me ;) > We came to the conclusion that no matter how much we wanted it to not be > true, people find a way to do NXDOMAIN if they want to. The issue is not > ours to push, it's between the ISP and the customer ultimately, and people > will do it -- and more intrusively -- than BIND 9.9 will. Good point - if it's implemented in BIND 9.9, then perhaps it can be more sane than if done by someone else. Might I propose a pair of changes to the behavior that would improve its sanity level dramatically, from my perspective? Right now, the ARM describes 'redirect' thusly: "If the client has requested DNSSEC records (DO=1) and the NXDOMAIN response is signed then no substitution will occur." That's a fairly obvious choice, since it isn't possible to fake an answer if both sides of the transaction are actively doing DNSSEC. Philosophically, though, I think it's more correct to decree that if *either* side is doing DNSSEC, no substitution should occur. That is, if the query comes in with DO=1, no substitution because the client is trying to use DNSSEC, and if the response is signed, so substitution because the server is doing likewise. That means I can opt out of NXDOMAIN substitution either by running a local client (forwarder, stub or application) that sets DO=1, and on the other side can opt out by signing my zone. We hope that someday everyone will do those things anyway, at which point redirect stops working anyway. . . Bill. _______________________________________________ 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
