DNS64 and DNSSEC - AD bit not set (RFC 6147)

[Tom Lanyon]

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?

Tom