Hi Iñaki,
On Tue, Jul 26, 2011 at 11:58:41AM +0200, Iñaki Baz Castillo wrote:
> 2011/7/24 Willy Tarreau <w@xxxxxx>:
> > To ensure nobody gets me wrong, I'm certain this can help solve issues
> > *if this is optional*. If it becomes a MUST, then the negative effects
> > will override the positive ones. In my opinion, the client should decide
> > whether to enable it or not.
>
> But I don't understand how a client is supposed to decide by himself
> how to resolve a URI destination.
This is well explained in RFC3986, #3.2.2. It enumerates a number of
exiting name registration methods and makes it clear that DNS usage is
not mandatory at all, only suggested. Also, it only exposes the fact that
names are resolved to addresses. It obviously does not make any asumption
on the DNS records to use for this either.
> If I give you my vcard containing my
> SIP/XMPP/MAILTO URIs, I must expect that you would use *standarized*
> mechanisms to locate the server for each service. In fact, in all
> these cases (SIP, XMPP; MAILTO) the URI domain can point to several
> IP:port (due to NAPTR / SRV / MX DNS records).
I'd say that the common practice with DNS has always been to use A records
for IPv4, AAAA for IPv6 (or CNAME for any), unless explicitly stated
otherwise for the protocol's usage. Now you could have resolver libraries
which would try SRV before trying A/AAAA and this would be transparent to
the upper application layers.
> BTW: I know that any web browser would first lookup at the /etc/hosts
> file when an URI is introduced.
I'm not a browser developer, but I think they might even simply rely on
the system's resolver. For instance, you might have an /etc/nsswitch.conf
or /etc/hosts.conf which indicates the priorities for the resolvers.
> This would "replace" a DNS A/AAAA
> query. Maybe NIS or whatever could also be used for this. It does not
> break SIP/XMPP/MAILTO URI's resolutions: Initially NAPTR / SRV / MX
> query would be performed and, if there is no such record (or there is
> so we get hostnames for which DNS A must be performed) then the client
> can check /etc/hosts for the "A" resolution (domain -> IP).
I don't know where you want to go with that example, but as I explained
it, if you want to have any chance of making SRV *usable* with WS (or
HTTP), you have to motivate both sides by showing them that :
- it's better for them to use it than not to use it (both servers and
browsers)
- the additional cost of using it is negligible
- there are no issues with not using it
- leaving the choices to the intermediaries will not cause disruptions
I'm pretty sure that can be done, but clearly not the way it's been
presented till now.
Willy
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf