Subject: Re: [BEHAVE] DNSSEC and NAT64 Discovery Heuristic [was RE: I-D Action:draft-ietf-behave-nat64-discovery-heuristic-05.txt]

From: <[email-masked]>
Date: Mon, 30 Jan 2012 21:52:21 +0000

Mark, we have even prototype implementation done with EDNS0.

One problem with EDNS0 is that it requires explicit access network support to work, while for generic NAT64 detection we cannot assume access network is helping us. Hence heuristics is the only option.

Now what comes to the secure prefix discovery, it is kinda hard to do that without network assistance. Hence introduction of DNSSEC into picture.

Teemu

----- Original message -----
>
> In message <[email-masked]<mailto:[email-masked]>>, Andrew Sullivan
> writes:
> > On Tue, Jan 31, 2012 at 01:54:01AM +1100, Mark Andrews wrote:
> >
> > > And CD=1 will not help with this senario.  The non-validating
> > > resolver will cache the DNS64 translated responses and will return
> > > those translated responses to DO=1,CD=1 queries which will then
> > > fail to validate.  Or if the DO=1,CD=1 query is the first query
> > > then the non validating stub resolvers will get NODATA responses
> > > to AAAA queries instead of synthesised responses.
> >
> > Ah, wait.  You are worried about the case where a caching
> > security-aware non-validating dns64-oblivious recursive resolver is
> > behind a DNS64, and providing service for other clients inside that
> > network?  Yeah, that won't work.  There's a rather clumsy and
> > too-short discussion of some (but not all) of these issues in RFC6147,
> > section 6.
> >
> > > Put a DNS64 recursive server (as described in RFC6147) in front of
> > > a non validating DO=1 recursive server in front of a validating
> > > recursive server.
> >
> > No, don't.  It won't work reliably, I agree.  Basically, if the DNS64
> > isn't the last hop before the validation point, then you're screwed.
>
> And RFC6147 doesn't provide any way for a caching server to learn
> the DNS64 prefixes to apply from upstream.  It doesn't provide a
> away for answers to DO=1 queries not to be tainted.
>
> The EDNS option I suggested earlier in the thread would be sufficient.
> Maintain a reference counted cache of learned prefix sets and record
> a reference to it with the AAAA nodata negative cache entry.  The
> DNS64 prefixes would timeout when the nodata negative cache entry
> times out.
>
> Alternatively we could make it more complicated and send the full
> policy, client address to match (IPv4 and IPv6) and exclusion address
> (IPv4 and IPv6) and TTL.  Upstream requests would include a 32 (64?)
> bit hash of the DNS64 policy so that it doesn't have to be transmitted
> on every AAAA response.  Sending that hash in the response would
> update the TTL entry.
>
> > At the same time, I'm a little alarmed at the prospect of caches that
> > hand out queries discovered with CD=0 to clients querying with CD=1,
> > regardless of whether they are a DNS64 or a DNS server.  That should
> > likely be taken up on another list, however.
>
> While it is fodder for the other list, it isn't wrong as the RFC 4035
> now stands.  Additionally asking upstream again on CD=1 is not
> sufficient
> as there is no control of which server is queried.
>
> > > > there is twofold.  First, since the only way to be sure you get
> all
> > > > the necessary validation data is to set CD=1,
> > >
> > > Not true.
> >
> > I think we are just talking with different implicit scope here, but
> > that's a general DNS issue and not, I think, a subject for this list.
> > I believe what I said, however, and I think a careful reading of RFC
> > 4035 backs me up.
> >
> > Best,
> >
> > A
> >
> > --
> > Andrew Sullivan
> > [email-masked]<mailto:[email-masked]>
> > _______________________________________________
> > Behave mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/behave
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                                INTERNET: [email-masked]<mailto:[email-masked]>
> _______________________________________________
> Behave mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/behave
>