NXDOMAIN redirection in BIND 9.9

[Bill Owens]

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.