On Fri, May 31, 2013 at 5:05 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > > > On Fri, May 31, 2013 at 2:02 PM, Ted Hardie <ted.ietf@gmail.com> wrote: > >> On Fri, May 31, 2013 at 1:44 PM, Eric Rescorla <ekr@rtfm.com> wrote: >> I personally think S-NAPTR could work here, but there are two trade-offs >> to consider: >> >> S-NAPTR targets are domain names, which means you may incur a round-trip >> in discovering the associated addresses for the domain names. In some >> cases, they are pointers to services which also require S-NAPTR look ups >> (see section 4.3 of RFC 3958 for an example); those may incur two round >> trips. There are ways to optimize this, but it can incur extra latency. >> >> S-NAPTR (and other DDDS approaches) really give you two things: data >> about what's available and data about the ordering that is preferred by the >> service owner. While that might come into play here, I have heard a use >> case for it. Is there one >> > > And in this case, that data is in JS that came from the server, so it > could express those opinions > directly in the API. > > In the best case, the web server can return IP addresses directly to JS with the pageload, eliminating any DNS lookup. I think that S-NAPTR for STUN/TURN will probably only require a single lookup, but the larger concern is that IIRC, DNS on Windows XP does not support S-NAPTR, which would break this for a sizable chunk of the Internet population (10%+)
Received on Friday, 31 May 2013 23:36:31 UTC