Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

[Ted Lemon <[e-mail]>]

Hm.   For the cloud case, with NAT, that seems kind of problematic anyway,
because now you have A records in the public DNS pointing at RFC1918
addresses.   The right way to handle this is with PCP and an SRV record
pointing at the NAT router's public address and using the PCP-assigned
port.   I didn't document this because I think it's kind of an extra-cost
option, but that's how it would have to work.

On Thu, Jul 12, 2018 at 5:39 PM, Toke Høiland-Jørgensen <[e-mail]>
wrote:

> Ted Lemon <[e-mail]> writes:
>
> > Yes, this requires separate registrations for IPv4 and IPv6. I think
> > that's okay. What's a bit chancy is that it also means that if you
> > have a ULA and a GUA, you have to pick one, or do two updates. As for
> > NAT, I think we have to assume that the network is not double-natted.
> > If it's a homenet, that will be true. If it's a campus network, that
> > will be true. If it's a bunch of crappy routers plugged together, it's
> > unlikely that service registration will be available anyway, so we
> > don't care. Do you buy that? :)
>
> Heh. For now, probably; by the time this becomes a standard, who knows?
> (but surely there will be no more IPv4 by then, right? ;))
>
> My concern is that requiring client address visibility breaks my
> deployment use case, where the registration server lives in the cloud...
> Or rather, I could probably live without v4, but I wouldn't be surprised
> if someone else got the same idea (DNSSD as a service? One could
> potentially run a dyndns type service using the same mechanism...).
>
> -Toke
>