On 04/20/2017 08:36 AM, Evan Hunt wrote:
On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote:
ANAME could just be a regular RRTYPE without any special handling,
meaning "go look there for up to date information on A/AAAA". It could
come along A/AAAA records using one of the existing bitmaps multi-type
query proposals that have been suggested in the last two years.
But, because there are always going to be legacy servers, the client would
then need to send an ANAME query, and when it got no answer, send another
query for A and AAAA.
If clients were willing to do that, then they'd have been willing to use
SRV, and we'd have standardized on that long since.
This is simply not true. SRV is broken for almost any purpose, which is
why it is only used for protocols which have mandated its use.
Most name lookup interfaces only take a name and return an address.
With these interfaces, it is technically impossible to synthesize a
query name for a SRV lookup, and return the port number in the SRV
record to the caller. (This even true for the RFC 3493 interface, which
is often used without a service name argument, or a numeric service name.)
An ANAME query to find a substitution name does not suffer from this
problem. It fits well with existing name lookup interfaces.
Which would've been
fine, but browser vendors have had years to do it, and they never have.
Why are you focusing on browsers? This is about the system name
resolution service, which browsers still use to perform NIS/WINS/LDAP
host name lookups, not just DNS. As I tried to explain above, SRV is
incompatible with most of the traditional system name resolution
interfaces. A name substitution with an ANAME redirection would not
have this problem.
Apparently, what they want is to send address queries and get redirected
answers. And if we can't make them do the smart thing, at least we can
give them an interoperable and standards-compliant way to do the dumb
thing.
I have no idea how to map most URI schemes to SRV lookups and resolve
conflicts between port numbers, transport protocols in use (e.g., if
QUIC is active), and service names (should an XMLRPC request get a
different name?). Without that mapping, there is nothing that browser
vendors could implement.
What I'm trying to say: The SRV failure is not sufficient evidence that
client-side name substitution would not see significant uptake because
SRV works at the wrong layer(s).
Thanks,
Florian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
