Subject: [sunset4] future of dnssec?

From: "Heatley, Nick" <[email-masked]>
Date: Wed, 22 Feb 2017 12:23:40 +0000

Post exhaustion, the majority of cellular networks and some public wifi networks will use DNS64.
DNSSEC and DNS64 do not get along. DNSSEC for "A records only" is broken.
Is this the reason why all content must go v6?
Or is the case for DNSSEC still questionable?
Or do end hosts need to perform DNS64 so "DNSSEC for A records only" can be intact?

NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. 
If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. 
If you've received this email in error, please let me know immediately on the email address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited 
Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

From: Ca By <[email-masked]>
Date: Wed, 22 Feb 2017 13:51:58 +0000

On Wed, Feb 22, 2017 at 4:23 AM Heatley, Nick <[email-masked]> wrote:

> DNSSEC and DNS64 do not get along. DNSSEC for “A records only” is broken.
>

It is demonstrably true that the case for DNSSEC is questioned by smart
people.

Let's assume that dnssec adds value.

We cannnot do any dnssec without EDNS0.

And, no mobile operating system i am aware of supports EDNS0

So first, we need to solve the EDNS0 issue and the total lack of mobile end
point support

Then, we may discuss how having ipv6 and aaaa is a requirement (thusly no
dns64) for dnssec to function correctly end to end.

Or do end hosts need to perform DNS64 so “DNSSEC for A records only” can be
> intact?
>
>
>
> NOTICE AND DISCLAIMER
> This email contains BT information, which may be privileged or
> confidential. It's meant only for the individual(s) or entity named above.
> If you're not the intended recipient, note that disclosing, copying,
> distributing or using this information is prohibited.
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2017 09:03:16 -0500

Operating systems don't support EDNS0: resolvers do.   What do you mean when you say "no mobile operating system supports EDNS0"?

> On Feb 22, 2017, at 8:51 AM, Ca By <[email-masked]> wrote:
> 
> 
> On Wed, Feb 22, 2017 at 4:23 AM Heatley, Nick <[email-masked] <mailto:[email-masked]>> wrote:
> It is demonstrably true that the case for DNSSEC is questioned by smart people. 
> 
> So first, we need to solve the EDNS0 issue and the total lack of mobile end point support  
> 
> Then, we may discuss how having ipv6 and aaaa is a requirement (thusly no dns64) for dnssec to function correctly end to end. 
> 
> 
> Or do end hosts need to perform DNS64 so “DNSSEC for A records only” can be intact?
> 
>  
> 
> NOTICE AND DISCLAIMER
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sunset4 <https://www.ietf.org/mailman/listinfo/sunset4>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sunset4 <https://www.ietf.org/mailman/listinfo/sunset4>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2017 09:04:02 -0500

Nick, the solution to this is to do DNS64 in the validator.   If the validator is a stub resolver, do the DNS64 hack there.   AFAIK the technology to support this already exists.

> On Feb 22, 2017, at 7:23 AM, Heatley, Nick <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Feb 2017 01:13:29 +1100

> And, no mobile operating system i am aware of supports EDNS0

I'm aware of apps that support EDNS.  That said phone vendors and
mobile ISP's should be ashamed that they don't support DNSSEC today.

15% of the world lives behind validating resolvers. 

> > If you've received this email in error, please let me know immediately
> on
> > the email address above. Thank you.
> >

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Feb 2017 01:36:29 +1100

In message <[email-masked]>, Ted Lemon writes:
>
> Nick, the solution to this is to do DNS64 in the validator.   If the
> validator is a stub resolver, do the DNS64 hack there.   AFAIK the
> technology to support this already exists.

DNS64 really should just be made historic.  It does not work with
DNSSEC.  There has NEVER been a NEED for NAT64 or DNS64.  They
provides NO BENEFIT over other methods.  Every proported benefit
turns out not to exist.

Go do the comparitive analysis.

> on the email address above. Thank you.
> >
> <https://www.ietf.org/mailman/listinfo/sunset4>

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 22 Feb 2017 10:00:30 -0500

> Go do the comparitive analysis.

I respectfully disagree. dual-stack incur many additional costs 
operationally. deploying v6only infrastructure is more cost effective, 
specially over the long run. nowadays, statistics show that a large 
amount of trafic could be carried over IPv6, which means then that you 
« just » need to care about the tail of the IPv4-only destinations, 
which is where nat64/dns64 comes. But I guess you know all this.

Marc.

>>> Post exhaustion, the majority of cellular networks and some public 
>>> wifi
>> networks will use DNS64.
>>> DNSSEC and DNS64 do not get along. DNSSEC for “A records only” 
>>> is
>> broken.
>>> Or do end hosts need to perform DNS64 so “DNSSEC for A records 
>>> only”
>> can be intact?
>>>
>>> NOTICE AND DISCLAIMER
>>> Registered office:Trident Place, Mosquito Way, Hatfield, 
>>> Hertfordshire,
>> AL10 9BW

---

From: Ca By <[email-masked]>
Date: Wed, 22 Feb 2017 16:19:40 +0000

>From a network with 10s of millions of nat64 users and zero dnssec, I
disagree and suggest dnssec move to historic since it is a ddos attack
vector and provides no privacy element and generally weak cryto ... also it
has caused many wide scale outages for networks that have elected to use
it.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2017 11:35:26 -0500

> provides NO BENEFIT over other methods.  Every proported benefit

(A) I find NAT64 to be a very convenient solution, and best of all it tests IPv6 functionality in apps, so I know which apps will not work on a v6-only network.
(B) DNS64 works _fine_ with DNSSEC as long as you do the DNS64 translation _after you validate_.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 22 Feb 2017 17:45:54 +0100

>has caused many wide scale outages for networks that have elected to use

With 2.5 million DNSSEC signed zones in just the nl TLD (45% of all zones in
.nl) and Google's highly popular public resolvers performing DNSSEC validation,
it is also safe to say that millions of people use DNSSEC daily without
nat64.

At least for me personally, I come across expired (or otherwise broken)
certificates a lot more often than domains that fail DNSSEC validation. 

As for weak crypto, I'm not aware of a single serious (published and executed)
attack on deployed DNSSEC.

So it seems that both operationally and from a security point of view,
DNSSEC is stricly better than TLS. 

By and large, the DNSSEC problems (and the IPv4 literal problems) can be
solved by using 464xlat instead of DNS64. 

However, NAT64 is such a 'success' that at least one high profile content
provider had to rush to roll out IPv6 because the deployed NAT64 was
breaking their service.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2017 12:08:07 -0500

> provider had to rush to roll out IPv6 because the deployed NAT64 was

And that, right there, completely justifies all the work that went into the NAT64 process.   :)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Feb 2017 13:19:08 -0500

Heatley, Nick <[email-masked]> wrote:
    > Or do end hosts need to perform DNS64 so DNSSEC for A records only
    > can be intact?

This is my take as being the only reasonable solution.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Feb 2017 08:03:05 +1100

In message <[email-masked]>, "Marc Blanchet" 
> which is where nat64/dns64 comes. But I guess you know all this.

Stop with the knee jerk reactions.  What gave you the idea that I
wasn't talking about IPv6-only networks?

So use DS-LITE in HOST MODE.  The only DS with that is in the host
which you cannot avoid if you are using IPv4 literals or is that
too much dual stack.  A little bit inside the node with a fixed
IPv4 address.  No routing.  No address assignments.

As I said NAT64/DNS64 does not provide any benefits that are not
available via other IPv4 as a service mechanisms with the added
benefit that you don't have to teach applications / OS stack about
DNS64 prefix discovery to deal with IPv6 literals.

For NAT64/DNS64 and 464XLAT in the host *every* DNSSEC validator
in the DNS path needs to be taught how to do DNS64 prefix discovery
and therefor that it need to lie about AAAA results whether or not
they are going to be used for a IPv6 connection or not.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Feb 2017 08:14:46 +1100

In message <[email-masked]>
, Ca By writes:
> --f403045f4faec156e8054920dd00
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 

Well I was meaning to compare with other IPv4 as a service solutions
but if you want to go here.

DNSSEC issues are really no worse that any other DNS delegation
misconfigurations that happen.  Have you actually run behind a
valdating DNSSEC resolver or are you looking in from the outside.
DNSSEC really isn't that hard to do right.  I've actually been
running behind DNSSEC validating resolvers for a decade now using
DNS data that is signed all the way down.

Mark

> > > > Post exhaustion, the majority of cellular networks and some public wi=
> fi
> > > networks will use DNS64.
> > > > DNSSEC and DNS64 do not get along. DNSSEC for =E2=80=9CA records only=
> =E2=80=9D is
> > > broken.
> > > > Or do end hosts need to perform DNS64 so =E2=80=9CDNSSEC for A record=
> s only=E2=80=9D
> > > can be intact?
> > > >
> > > > NOTICE AND DISCLAIMER
> > > > If you've received this email in error, please let me know immediatel=
> y
> > > > Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshir=
> e,
> > > AL10 9BW
> --f403045f4faec156e8054920dd00
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div><br><div class=3D"gmail_quote"><div>On Wed, Feb 22, 2017 at 6:36 AM Ma=
> rk Andrews &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote=
> :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
> der-left:1px #ccc solid;padding-left:1ex"><br class=3D"gmail_msg">
> In message &lt;<a href=3D"mailto:B5E8C545-55B9-4ECB-B0C8-C3EEFEECD320@fugue=
> .com" class=3D"gmail_msg" target=3D"_blank">B5E8C545-55B9-4ECB-B0C8-C3EEFEE=
> [email-masked]</a>&gt;, Ted Lemon writes:<br class=3D"gmail_msg">
> &gt;<br class=3D"gmail_msg">
> &gt; Nick, the solution to this is to do DNS64 in the validator.=C2=A0 =C2=
> =A0If the<br class=3D"gmail_msg">
> &gt; validator is a stub resolver, do the DNS64 hack there.=C2=A0 =C2=A0AFA=
> IK the<br class=3D"gmail_msg">
> &gt; technology to support this already exists.<br class=3D"gmail_msg">
> <br class=3D"gmail_msg">
> DNS64 really should just be made historic.=C2=A0 It does not work with<br c=
> lass=3D"gmail_msg">
> DNSSEC.=C2=A0 There has NEVER been a NEED for NAT64 or DNS64.=C2=A0 They<br=
>  class=3D"gmail_msg">
> provides NO BENEFIT over other methods.=C2=A0 Every proported benefit<br cl=
> ass=3D"gmail_msg">
> turns out not to exist.<br class=3D"gmail_msg">
> <br class=3D"gmail_msg">
> Go do the comparitive analysis.</blockquote><div><br></div><div>From a netw=
> ork with 10s of millions of nat64 users and zero dnssec, I disagree and sug=
> gest dnssec move to historic since it is a ddos attack vector and provides =
> no privacy element and generally weak cryto ... also it has caused many wid=
> e scale outages for networks that have elected to use it.=C2=A0</div><div><=
> br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
>  0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class=3D"gmail_m=
> sg">
> <br class=3D"gmail_msg">
> &gt; &gt; On Feb 22, 2017, at 7:23 AM, Heatley, Nick &lt;<a href=3D"mailto:=
> [email-masked]" class=3D"gmail_msg" target=3D"_blank">nick.heatley@e=
> e.co.uk</a>&gt;<br class=3D"gmail_msg">
> &gt; wrote:<br class=3D"gmail_msg">
> &gt; &gt;<br class=3D"gmail_msg">
> &gt; &gt; Post exhaustion, the majority of cellular networks and some publi=
> c wifi<br class=3D"gmail_msg">
> &gt; networks will use DNS64.<br class=3D"gmail_msg">
> &gt; &gt; DNSSEC and DNS64 do not get along. DNSSEC for =E2=80=9CA records =
> only=E2=80=9D is<br class=3D"gmail_msg">
> &gt; broken.<br class=3D"gmail_msg">
> &gt; &gt; Is this the reason why all content must go v6?<br class=3D"gmail_=
> msg">
> &gt; &gt; Or is the case for DNSSEC still questionable?<br class=3D"gmail_m=
> sg">
> &gt; &gt; Or do end hosts need to perform DNS64 so =E2=80=9CDNSSEC for A re=
> cords only=E2=80=9D<br class=3D"gmail_msg">
> &gt; can be intact?<br class=3D"gmail_msg">
> &gt; &gt;<br class=3D"gmail_msg">
> &gt; &gt; NOTICE AND DISCLAIMER<br class=3D"gmail_msg">
> &gt; &gt; This email contains BT information, which may be privileged or<br=
>  class=3D"gmail_msg">
> &gt; confidential. It&#39;s meant only for the individual(s) or entity name=
> d<br class=3D"gmail_msg">
> &gt; above.<br class=3D"gmail_msg">
> &gt; &gt; If you&#39;re not the intended recipient, note that disclosing, c=
> opying,<br class=3D"gmail_msg">
> &gt; distributing or using this information is prohibited.<br class=3D"gmai=
> l_msg">
> &gt; &gt; If you&#39;ve received this email in error, please let me know im=
> mediately<br class=3D"gmail_msg">
> &gt; on the email address above. Thank you.<br class=3D"gmail_msg">
> &gt; &gt;<br class=3D"gmail_msg">
> &gt; &gt; We monitor our email system, and may record your emails.<br class=
> =3D"gmail_msg">
> &gt; &gt;<br class=3D"gmail_msg">
> &gt; &gt; EE Limited<br class=3D"gmail_msg">
> &gt; &gt; Registered office:Trident Place, Mosquito Way, Hatfield, Hertford=
> shire,<br class=3D"gmail_msg">
> &gt; AL10 9BW<br class=3D"gmail_msg">
> &gt; &gt; Registered in England no: 02382161<br class=3D"gmail_msg">
> &gt; &gt;<br class=3D"gmail_msg">
> &gt; &gt; EE Limited is a wholly owned subsidiary of:<br class=3D"gmail_msg=
> ">
> &gt; &gt;<br class=3D"gmail_msg">
> &gt; &gt; British Telecommunications plc<br class=3D"gmail_msg">
> &gt; &gt; Registered office: 81 Newgate Street London EC1A 7AJ<br class=3D"=
> gmail_msg">
> &gt; &gt; Registered in England no: 1800000<br class=3D"gmail_msg">
> &gt; &gt;<br class=3D"gmail_msg">
> &gt; &gt; _______________________________________________<br class=3D"gmail=
> _msg">
> &gt; &gt; sunset4 mailing list<br class=3D"gmail_msg">
> &gt; &gt; <a href=3D"mailto:[email-masked]" class=3D"gmail_msg" target=3D=
> "_blank">[email-masked]</a> &lt;mailto:<a href=3D"mailto:[email-masked]=
> " class=3D"gmail_msg" target=3D"_blank">[email-masked]</a>&gt;<br class=
> =3D"gmail_msg">
> &gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/sunset4" rel=3D"=
> noreferrer" class=3D"gmail_msg" target=3D"_blank">https://www.ietf.org/mail=
> man/listinfo/sunset4</a><br class=3D"gmail_msg">
> &gt; &lt;<a href=3D"https://www.ietf.org/mailman/listinfo/sunset4" rel=3D"n=
> oreferrer" class=3D"gmail_msg" target=3D"_blank">https://www.ietf.org/mailm=
> an/listinfo/sunset4</a>&gt;<br class=3D"gmail_msg">
> <br class=3D"gmail_msg">
> --<br class=3D"gmail_msg">
> Mark Andrews, ISC<br class=3D"gmail_msg">
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br class=3D"gmail_msg">
> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0 =C2=A0INTERNET: <a href=3D"mailto:[email-masked]" class=3D"gmail_msg" ta=
> rget=3D"_blank">[email-masked]</a><br class=3D"gmail_msg">
> <br class=3D"gmail_msg">
> _______________________________________________<br class=3D"gmail_msg">
> sunset4 mailing list<br class=3D"gmail_msg">
> <a href=3D"mailto:[email-masked]" class=3D"gmail_msg" target=3D"_blank">s=
> [email-masked]</a><br class=3D"gmail_msg">
> <a href=3D"https://www.ietf.org/mailman/listinfo/sunset4" rel=3D"noreferrer=
> " class=3D"gmail_msg" target=3D"_blank">https://www.ietf.org/mailman/listin=
> fo/sunset4</a><br class=3D"gmail_msg">
> </blockquote></div></div>
> 
> --f403045f4faec156e8054920dd00--

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Feb 2017 08:20:04 +1100

In message <[email-masked]>, Ted Lemon writes:
> (A) I find NAT64 to be a very convenient solution, and best of all it =
> tests IPv6 functionality in apps, so I know which apps will not work on =
> a v6-only network.
> (B) DNS64 works _fine_ with DNSSEC as long as you do the DNS64 =
> translation _after you validate_.

And have managed to update EVERY DNSSEC validator in the DNS path
from the DNS64 server to the final DNSSEC validator to do DNS64
prefix discovery and that you are willing to forego any other use
of AAAA records other than to lookup host addresses.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Feb 2017 16:23:47 -0500

> of AAAA records other than to lookup host addresses.

Given that the number of such validators is typically zero, this isn't a particularly daunting task.

---

From: "Heatley, Nick" <[email-masked]>
Date: Thu, 23 Feb 2017 10:53:30 +0000

Some networks do not work successfully with the additional encapsulation.
Mobile networks are the case in point.
So the translation tech rightfully exists.

-----Original Message-----
From: sunset4 [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: 22 February 2017 21:03
To: Marc Blanchet
Cc: [email-masked]
Subject: Re: [sunset4] future of dnssec?

writes:
> > In message <[email-masked]>, Ted 
> > Lemon
> > writes:
> >>

Stop with the knee jerk reactions.  What gave you the idea that I wasn't talking about IPv6-only networks?

So use DS-LITE in HOST MODE.  The only DS with that is in the host which you cannot avoid if you are using IPv4 literals or is that too much dual stack.  A little bit inside the node with a fixed
IPv4 address.  No routing.  No address assignments.

As I said NAT64/DNS64 does not provide any benefits that are not available via other IPv4 as a service mechanisms with the added benefit that you don't have to teach applications / OS stack about
DNS64 prefix discovery to deal with IPv6 literals.

For NAT64/DNS64 and 464XLAT in the host *every* DNSSEC validator in the DNS path needs to be taught how to do DNS64 prefix discovery and therefor that it need to lie about AAAA results whether or not they are going to be used for a IPv6 connection or not.

Mark

> >>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
> >>> England no: 1800000
> >>>

NOTICE AND DISCLAIMER

EE Limited

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2017 00:06:52 +1100

In message <[email-masked]
> So the translation tech rightfully exists.

464XLAT is encapsulation with translation.  It drops the IPv4 path
MTU from 1500 to 1480.  DS-Lite drops the IPv4 MTU to 1460.  You
can't avoid the issue with tethered equipement.

For TCP connection initiatiate from the host you shouldn't be seeing
PMTU issues with either 464XLAT or DS-Lite as both should be
presenting iterface MTU that doesn't result in PTB's being generated
by the teco's equipement.  For 464XLAT the mss should be that of
IPv6.  For DS-Lite in the host mode the mss should be 20 bytes
smaller.

Or can't the phone manufactures actually do DS-Lite host mode
properly if they were to try?

Encapsulation in the connection initiating device is different to
encapsulation in the middle of the path.  You start out with a
smaller MTU.

Mark

> From: sunset4 mailto:[email-masked] On Behalf Of Mark Andrews
> Subject: Re: sunset4 future of dnssec?
>
>
> > just need to care about the tail of the IPv4-only destinations,
> So use DS-LITE in HOST MODE.  The only DS with that is in the host which
> you cannot avoid if you are using IPv4 literals or is that too much dual
> stack.  A little bit inside the node with a fixed
> available via other IPv4 as a service mechanisms with the added benefit
> that you don't have to teach applications / OS stack about
> For NAT64/DNS64 and 464XLAT in the host *every* DNSSEC validator in the
> DNS path needs to be taught how to do DNS64 prefix discovery and therefor
> that it need to lie about AAAA results whether or not they are going to
> be used for a IPv6 connection or not.
>
> Mark
>
> > Marc.
> >
> > >
> > >>> DNSSEC and DNS64 do not get along. DNSSEC for A records only
> > >>> is
> > >> broken.

---

From: "Heatley, Nick" <[email-masked]>
Date: Thu, 23 Feb 2017 14:11:36 +0000

It is not the phone where the blocker is, Mark.
It is Core Network "policy, control and charging".
Encapsulation obstructs any IP function that must be performed prior to the NAT to the outside.

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: 23 February 2017 13:07
To: Heatley, Nick
Cc: Marc Blanchet; [email-masked]
Subject: Re: [sunset4] future of dnssec?

> So the translation tech rightfully exists.

464XLAT is encapsulation with translation.  It drops the IPv4 path MTU from 1500 to 1480.  DS-Lite drops the IPv4 MTU to 1460.  You can't avoid the issue with tethered equipement.

For TCP connection initiatiate from the host you shouldn't be seeing PMTU issues with either 464XLAT or DS-Lite as both should be presenting iterface MTU that doesn't result in PTB's being generated by the teco's equipement.  For 464XLAT the mss should be that of IPv6.  For DS-Lite in the host mode the mss should be 20 bytes smaller.

Or can't the phone manufactures actually do DS-Lite host mode properly if they were to try?

Encapsulation in the connection initiating device is different to encapsulation in the middle of the path.  You start out with a smaller MTU.

Mark

NOTICE AND DISCLAIMER

EE Limited

---

From: Sander Steffann <[email-masked]>
Date: Thu, 23 Feb 2017 18:38:10 +0100

Hi,

> Op 22 feb. 2017, om 17:35 heeft Ted Lemon <[email-masked]> het volgende geschreven:
> 

This.

I have tested different implementations and used others that work like this, and it works fine. I'm at Cisco Live in Berlin and I have been behind a DNSSEC validating NAT64 resolver the whole week (thanks to Jan Žorž for providing it!).

Cheers,
Sander

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2017 07:19:18 +1100

In message <[email-masked]>, Sander Steffann 
writes:
> > (A) I find NAT64 to be a very convenient solution, and best of all it
> tests IPv6 functionality in apps, so I know which apps will not work on a
> v6-only network.
> I have tested different implementations and used others that work like
> this, and it works fine. I'm at Cisco Live in Berlin and I have been
> behind a DNSSEC validating NAT64 resolver the whole week (thanks to Jan
> Žorž for providing it!).

I presume the configuration was:

Internet <-> ISP validating DNS64 <-> clients.

That's the trivial configuration.

You need to think about all the other ways networks are set up today.

Internet <-> ISP validating DNS64 <-> validating recursive server <-> clients.
Internet <-> ISP validating DNS64 <-> validating recursive server <-> validating clients.

then to get them to work you need to add DNS64 prefix learning to every
validating device in the path.

How often does the validating recursive server attempt to do DNS64
prefix discovery?  Every time it gets a NODATA to AAAA lookups?
Even one non-DNS64 prefix discovering validating resolver in the
path breaks DNS64 for everything behind it.  Fiddling with DO and
CD doesn't get the synthesised DNS64 records through a non-DNS64
prefix discovery aware validating resolver.

Then there are clients that do

Internet <-> 8.8.8.8 <-> validating recursive server <-> validating clients.

How do they learn the DNS64 prefix?  Too many ISP's mangle DNS to
trust responses from them.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2017 08:49:08 +1100

In message <[email-masked]
O.UK>, "Heatley, Nick" writes:
> Encapsulation obstructs any IP function that must be performed prior to t=
> he NAT to the outside.

Why does a telco *need* to look inside a encapsulated packet?  You
charge the customer based on the encapsulating packet.  If you
really need to look inside it isn't hard to take of the IPv6 header
while still remembering who the customer is based on the IPv6
addresses.

Oh dear we are a telco and we are going to play the 800lb gorrilla
and require that every device on the planet be updated do that we
can do NAT64.

RFC 6147 needs updates RFC 4034 as things currently stand.  It's
not a minor extension that only those using DNS64 need to support.
It update *every* validating product on the planet so some telco
don't need to unwrap a encapsulating header to get their accounting
correct.

Mark

---

From: Sander Steffann <[email-masked]>
Date: Thu, 23 Feb 2017 23:06:14 +0100

Hi Mark,

> Internet <-> ISP validating DNS64 <-> clients.

Correct

> Internet <-> ISP validating DNS64 <-> validating recursive server <-> validating clients.

Those setups are so uncommon in the places where DNS64 is used that it causes no problems. 

I realise that there are plenty of ways this can break, but in reality it works pretty well. But I agree it's a hack and the sooner we can get rid of IPv4 the better. In that context I'll happily use it.

Cheers,
Sander

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2017 09:37:53 +1100

In message <[email-masked]>, Sander Steffann 
> Those setups are so uncommon in the places where DNS64 is used that it

Except people seem to think that NAT64/DNS64 and 464XLAT is a good
future solution to the places where the above without DNS64 is
currently in use today.

We need to be delivering tech today that will work when the ISPs
that are currently IPv4-only or dual stack today become IPv6-only
tomorrow.  Those ISPs have people with validating resolvers that
point at the ISP's resolvers or they point to resolvers like Google's
8.8.8.8 service or they just talk directly to the root servers.
Not all of those validating resolvers are on border routers.

Now the resolvers that use 8.8.8.8 just need to add 2001:4860:4860::8888
to the list of forwarders to work in a IPv6-only environment.

Those that talk directly to the root need to add a server of last
resort like 2001:4860:4860::8888 so they can lookup data from zones
with IPv4 only servers.  We added code to our nameserver product
over a decade ago to support this sort of behaviour.  We knew that
recursive servers would end up behind IPv6-only links that needed
to lookup data from IPv4-only zones.

Mark

> I realise that there are plenty of ways this can break, but in reality it
> works pretty well. But I agree it's a hack and the sooner we can get rid
> of IPv4 the better. In that context I'll happily use it.
>
> Cheers,
> Sander
>
>