Re: Last Call: RFC 6346 successful: moving to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Dec 5, 2014 at 5:16 PM, Mark Andrews <marka@xxxxxxx> wrote:

In message <9C0A9641-1FDC-4456-95DC-C12536CDF22C@xxxxxxxxx>, =?utf-8?Q?=F0=9F=9
4=93Dan_Wing?= writes:
> On Dec 4, 2014, at 9:00 PM, Mark Andrews <marka@xxxxxxx> wrote:
>
> > In message <74DF5B53-055C-4235-A8FA-E8B38E007F45@xxxxxxxxxxx>, Ted
> Lemon writes
> > :
> >> On Dec 4, 2014, at 10:02 PM, George Michaelson <ggm@xxxxxxxxxxxx>
> wrote:
> >>> Hang on.. the deployment of DNSSEC backed applications is a bit iffy
> if
> >> we depend on deployment of DNS based tricks to cover for V4/V6
> >> interoperation surely?
> >>
> >> DNS64 can be done by the client, in which case DNSSEC validation can be
> >> performed _before_ translating the IPv4 address from the A record into
> an
> >> IPv6 address in the NAT64 prefix.
> >
> > Which requires every DNSSEC aware client to also be DNS64 aware.
> > I though we were trying to remove NAT kludges requires that they
> > be kept forever.
>
> The BEHAVE working group was unable to find any other approach to get
> DNSSEC and NAT64 to work together.  If you have a proposal, please share.

Which should have been a reason to reject DNS64 and NAT64 as anything
other than a interim measure.

That depends on what you believe the role of DNSSEC should be and where you think validation should take place.

Right now we don't have any platform vendor committed to the client validation model and my interactions with the two main platform vendors were consistently negative.

We do have interest in DNSSEC validation of TLSA records but as I point out, that is a different issue.


We need to deploy IPv6. That is absolutely essential. Maintaining the purity of the 'end-to-end' model is not. If DNSSEC has to bend to make IPv6 transition viable then so be it.

One of the core problems here is that the DNS should be central to the Internet architecture but it is still treated as optional. 

According to our current architecture, an application performs discovery by either using an IP address or a DNS name and these are treated as both being application layer concerns. These should be considered two different layers. The application should only deal in DNS names that are resolved by its chosen resolution service.

Any application interaction with IP addresses should be strictly for debugging purposes.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]