On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz <bem...@google.com> wrote:
> On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> I really don't like the proposal at all. The idea of beginning the TLS >> handshake in DNS is sound. But it is a completely new handshake and >> authentication layer. >> > > What you're proposing does sound like a completely new handshake. To be > clear, this proposal makes no change to TLS. > Well there is your problem. There is little point in doing this unless you feed the result into the TLS handshake to follow. Right now we have a bit of a mess with service discovery. We have a solid >> proposal that makes sense written up as a standard >> > > Could you point me to which document you're referring to? > https://tools.ietf.org/html/rfc6763 > and we have a lot of folk saying we should do something different, either >> for legacy reasons or because they find it impure. >> >> The solid proposal is as follows: >> >> * Discover all services using SRV *without exception* >> >> * Use TXT records to provide additional data *that is required for >> discovery and binding* >> >> * TXT records may be bound to the service definition, thus covering all >> hosts or be bound to a specific host instance. >> >> * Domain names used for services MAY use CNAME or DNAME. Domain names >> that identify services MUST NOT. >> > > I'm not sure I understand this distinction. > Ooops... Domain names that identify HOSTS MUST NOT. A service is an abstract Internet service which may be provided by any host chosen from group of hosts specified in an SRV record. A host is a physical machine. SRV records map services to hosts. A and AAAA records map hosts to IP addresses. > How many DNS and destination roundtrips does this require? My impression > is that SRV records have proven unpopular in part because they generally > add a DNS roundtrip delay to each initial connection. > One if it is done right. You are going to want to lock down your client to resolver DNS and you might as well fix the protocol at the same time. That is why standardizing on DNS-SD for everything is the way to go.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
