Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Mikael Abrah
amsson writes:
> On Tue, 10 Oct 2017, JORDI PALET MARTINEZ wrote:
> 
> > Hi Mikael,
> >
> > So, in your opinion, if I understand it correctly:
> > 1) DNSSEC must not be ignored
> > 2) DNS64 should be supported
> 
> Correct. Don't know exactly how to do that, but that's what I'd like to 
> see.
> 
> > Could you agree in a document that describes different deployment models su
> pporting or not 1, 2, above?
> 
> I'm just speculating/brainstorming here... but let me write some text and 
> see what people think:
> 
> 1. A DNS64 resolver should do DNSSEC validation before synthesis.
> 
> 2. A device behind DNS64 that intends to do DNSSEC validataion should 
> identify the NAT64 prefix via the standard means, and then it should (if 
> DNSSEC validation fails on AAAA question) do DNSSEC validation of A record 
> and perform its own DNS64 function (if the AAAA answer that failed DNSSEC 
> validation fell within the discovered NAT64 prefix).
> 
> I wasn't there during the DNS64 work, I don't know if these things were 
> discussed and rejected for good reasons but... Have at me.

Behave failed to listen to the fact that there is NO WAY TO TELL
IF A CLIENT IS VALIDATING RESPONSES.  It decided that CD=0 meant
not validating which is NOT the case.

This is what the DNSSEC flag bits mean

	DO=0		Not validating

	DO=1 CD=0	May be validating  (DNS64 says not validating)
			(These are the type of queries many validating
			client issue by default)

	DO=1 CD=1	May be validating, do not validate responses to
			any request you make to resolve this query, just
			include them in your response.
			(DNS64 says is validating)

Both DO=1 CD=0 and DO=1 CD=1 queries need to be sent by validating
clients to get answers through a validating recursive server. DO=1
CD=0 allow the recursive server to reject spoofed or otherwise bad
responses to queries it makes on the clients behalf and retry.  DO=1
CD=1 allow the responses to get through a recusive server with bad
trust anchors or a bad clock.

Just sending DO=1 CD=1 means that there is no reject or retry and
no control over which authoritative servers are queries.  Multiple
authoritative servers are tries with DO=1 CD=0 queries on the clients
behalf.  DO=1 CD=1 are NOT REQUIRED to be validated and are not
cached unless they have been validated as secure or insecure.  They
MUST NOT be returned to DO=1 CD=0 or DO=0 queries without being
validated.

If all the servers are correctly configured and there is no spoofing
happening it doesn't matter if you send DO=1 CD=0 or DO=1 CD=1 when
you are validating you will get a response that will validate as
secure / insecure.  What you send when this is not the case however
is critical.

This was pointed out numerous times but behave went ahead and wrote
a specification that DOES NOT WORK and cannot be made to work (it
is mathematically impossible to do) and due to rough consensus it
was passed.  The "crazy DNSSEC guy" was not listened too.

Mark

> -- 
> Mikael Abrahamsson    email: [e-mail]
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]