Re: [sunset4] future of dnssec?

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, "Marc Blanchet" 
writes:
> On 22 Feb 2017, at 9:36, Mark Andrews wrote:
> 
> > In message <[e-mail]>, 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.
> 
> 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.

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

> Marc.
> 
> >
> >>> On Feb 22, 2017, at 7:23 AM, Heatley, Nick <[e-mail]>
> >> wrote:
> >>>
> >>> 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
> >>>
> >>> _______________________________________________
> >>> sunset4 mailing list
> >>> [e-mail] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/sunset4
> >> <https://www.ietf.org/mailman/listinfo/sunset4>
> >
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone]                 INTERNET: [e-mail]
> >
> > _______________________________________________
> > sunset4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sunset4
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]