On 27 Mar 2014, at 14:48, Mark Andrews <ma...@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 _______________________________________________ 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
