DNS64 and DNSSEC - AD bit not set (RFC 6147)
tom+bind at oneshoeco.com
Thu Mar 27 05:05:39 UTC 2014
On 27 Mar 2014, at 14:48, Mark Andrews <marka at isc.org> wrote:
> No. If the answer is secure and DO=1 then it won't synthesis.
> RFC 6147 just gets DO and CD semantics completely wrong. The WG
> wanted there to be signaling that the client was going to validate
> and DNSSEC does not have such signaling. The best DNSSEC can do
> is DO=1 indicates that the client might validate. This is independent
> of CD.
Isn't this signalling defined as the purpose of the CD bit in RFC 4035?
My naive understanding is something like:
DS=1 CD=0 "I am not going to validate this, I want you to check it"
DS=1 CD=1 "I am going to validate this, so I don't care if you check it"
> A validating stub resolver should send it queries with CD=0 so that
> the recursive server can filter out bad responses from upstream.
> Only if it gets SERVFAIL should it attempt the query with CD=1 in
> case the resolver has bad time or bad trust anchors.
Right, this is what our current stub resolvers are doing (well, I'm not sure about the retry with CD=1 on SERVFAIL, but they're sending DS=1 CD=0 queries to our recursive resolvers).
> Named doesn't lie when DO=1 *and* it is possible to detect the lie.
> "break-dnssec yes;" tells named to lie even when it is possible to
> detect the lie.
So, what is a "lie" here? Assuming that the response received upstream (i.e. a negative AAAA and positive A response) has been validated, is inserting a synthesised AAAA for DNS64 "lying"?
> Stub resolvers don't currently set DO=1 so DNS64 synthesis happens
> for them.
Our real-world case, and why I'm looking into this, is that our BIND 9.8.2 validating recursive resolvers are *not* returning synthesised AAAA DNS64 responses for DNSSEC signed zones because the downstream stub resolvers query with DS=1 and CD=0. This breaks connectivity from our IPv6-only clients for DNSSEC signed zones.
As far as I can see, my two options are to enable break-dnssec in BIND, or disable DNSSEC validation in the stub resolvers. Are there any other options, and if not, are either of these two more preferred than the other?
More information about the bind-users