Re: IPv6 only host NAT64 requirements?

[Mark Andrews <[e-mail]>]

> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti <[e-mail]> wrote:
> 
> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews <[e-mail]> wrote:
> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have CLAT support.
> 
> That's an interesting idea. It would work in theory, but such a network would completely break devices that don't support 464xlat. That gives up one of the major advantages of NAT64/DNS64, which is that it's a 90% solution even just by itself - yes, IPv4-only applications and address literals exist, but most simple client/server applications Just Work behind it.

And that 90% “solution” has lots of down sides.  It basically requires EVERY DNS VALIDATOR ON
THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SERVER.

DNS64/NAT64 was presented as NOT REQUIRING node changes when first mooted.  It keeps on
requiring more and more highly invasive node changes to support.  It was from the very beginning
bad engineering.   To get IPv4 as a service some node changes are required.  Lets make sure they
are MINIMAL ones.

Just for the record DNSSEC validators need to send BOTH CD=0 and CD=1 queries to get answers
though a upstream VALIDATING server which includes a VALIDATING DNS64 server as CD=0 and
CD=1 address different DNSSEC threats.  I tried very hard to point that out when RFC 6147 was
being written but the working group decide that CD indicated whether the client was validating or
not.  There is NO SUCH INDICATION in a DNS message.

  If a query arrives at a vDNS64 device with the "Checking Disabled"
   (CD) bit set, it is an indication that the querying agent wants all
   the validation data so it can do checking itself.  By local policy,
   vDNS64 could still validate, but it must return all data to the
   querying agent anyway.

CD=0 queries causes the upstream validating servers to reject incoming spoofed answers
or stale answers (this is a common operational problem).

CD=1 queries allow the validation to succeed when the upstream validator has a bad trust
anchor or a bad clock which is rejecting legitimate answers.

A validating client can’t just send CD=1 queries as the upstream validator doesn’t kick in.
The upstream validator can lock onto a stale answer source.  It needs to send CD=0 queries
on validation failure to force the upstream validator to try multiple sources.

A validating client can’t just send CD=0.  It needs to send CD=1 on SERVFAIL in case the
upstream validator has a bad trust anchor (likely with the upcoming root KSK roll) or has
a bad clock (these usually get fixed fast).

Now to get a answer from a signed zone with servers with stale answers a validatiing DNS64 client
needs to send:

a) send CD=1 and validation failure send CD=0 then on AAAA validation failure send CD=1 and
    hope the TTL was not 0 and that is not cachable and there is no assurance that you won’t get
    a answer from a stale source.

	or

b) send CD=0 and on validation failure of the AAAA send CD=1 and hope the TTL was not 0 as
    that is not cachable and there is no assurance that you won’t get a answer from a stale source.

TTL=0 answers exist.

Note none of this is documented in a RFC.  You have to understand how both DNSSEC and DNS64 work to
realise this.

IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix discover for DNS VALIDATORS.
Note “ad” is set in the flags.  Yes, I’ve submitted a errata.  Yes, I’ve opened a ticket to get it fixed but
based on past experience that could take months if it happens at all.  You will note that the recursive
server is running on the loopback interface so all DNS answers are being validated here.

[rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
;; QUESTION SECTION:
;IPV4ONLY.ARPA.			IN	A

;; ANSWER SECTION:
ipv4only.arpa.		26574	IN	A	192.0.0.171
ipv4only.arpa.		26574	IN	A	192.0.0.170

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
;; MSG SIZE  rcvd: 115

[rock:bind9/bin/named] marka% 

> It's not true that all phones have clat support. Notably, Apple not only does not support it but appears ideologically opposed to it on the grounds that it does not have a good exit strategy (because it makes it possible to run IPv4-only apps forever).


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]