NXDOMAIN redirection in BIND 9.9
Bill Owens
owens at nysernet.org
Fri Sep 30 21:15:01 UTC 2011
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.
More information about the bind-users
mailing list