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

[Mark Andrews]

In message <D1BFA064-5AFD-4009-A650-1034180409C4 at oneshoeco.com>, Tom Lanyon wri
tes:
> 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"

Which is incorrect.  I presume you mean DO not DS.

DO=1 says "I understand DNSSEC records, send them to me if you have them"
	  it also says "set AD as appropriate" (AD=1 can also be used to
	  request setting AD as appropriate in the response).

CD=1 says "Do not validate records from upstream if you have to make
	  upstream queries, pass them through to me without checking"
	  it also stop validation checks being made on other lookups
	  needed to complete the lookup being made.  Think of CD=1
	  as "Give me the answer even if the lookup would normally
	  fail due to DNSSEC validation failures".

There is no "I will be validating responses" on either of these.
DNSSEC does not have a way to signal "I will be validating responses".

The authors of RFC 6147 really wanted there to be such a signal and
tried to twist the DNSSEC signaling bits into signaling this.  This
is like defining pi to be 3.  It does not work.

> > 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"?

Yes, it is lying.  It's deliberate lying but it is lying.  The same
policy applies to othe places where named can be configured to lie.

> > 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?

Or teach the stub resolvers how to discover the DNS64 parameters.
The sane way to do that would have been a EDNS option but the working
group decided heuristics are good enough.

> Tom
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org