On Jul 17, 2014, at 15:10, Jonathan Nieder wrote:
Hi,
Kyle J. McKay wrote:
When I then try to fetch using a "git://host/..." URL where "host"
is an mDNS host name, the 0010 patch causes git to attempt to lookup
a DNS SRV record on the non-mDNS regular DNS service (a violation of
RFC 6762 [4] section 22) and this is what has to time out before the
real fetch can start.
That patch uses res_query from libresolv to do the lookup. It doesn't
know what DNS server to use and relies on system libraries to get it
right.
If I understand the libresolv implementation correctly, it only
supports DNS and not mDNS. And as far as I know, the nss plugins only
support A and AAAA lookups, not SRV lookups. However, it looks like
there are some attempts to add mDNS support directly to res_query and
friends [4]. Maybe that code could serve as a model.
It was added to respond to a feature request within Debian but it is
intended to eventually go upstream. I'm glad you found this issue
before that could happen. :)
Is there some reason the patch is not opt-in at runtime? In other
words the code is there, but not enabled unless you do something like
'git config --system --bool git.srvlookup true'? If it's off by
default it doesn't matter so much that it's standards violating as it
won't bite you unless you turn it on and then presumably if you do you
know what you're doing and understand the possible downside.
Should git automatically disable the SRV lookups when it sees one of
the six domains named in RFC6762, or is there some system library call
that can use mDNS when appropriate automatically (or get partway there
without having to hard-code the domains)?
Sadly I think mDNS support is relegated to an add-on package on
Linux. And Avahi [1] is the package that generally provides it
there. The recommended interface for C is the avahi-client API (see
[2]). However, that is Avahi-only.
If the patch is to go upstream it probably needs to use the dns-sd.h
header API for maximum compatibility (Avahi provides an avahi-compat-
libdns_sd interface via the libavahi-compat-libdnssd-dev package). I
believe the correct function would be DNSServiceQueryRecord in this
case.
That said, for the code to work properly it would need to:
1) Get the canonical name of the host. If "local" is one of the
search domains or the default domain you could have a mDNS name
without an explicit .local suffix. I'm not sure best how to do this.
The getaddrinfo function has an AI_CANONNAME flag but the call will
fail if the host does not have an A or AAAA record and in the case of
redirection-by-SRV it may have neither. You probably just have to
loop through the search domains keeping in mind the Security
Considerations of section 21 of RFC 6762 [3] (a host MUST NOT append
the search suffix ".local.", if present, to any relative (partially
qualified) host name containing two or more labels. Appending
".local." to single-label relative host names is acceptable). So if a
host name does not end in .local (or .local.) it can only be an mDNS
name if it contains no dots ('.') AND "local" is one of the search
domains or is the default domain.
2) For mDNS either use the #include <dns_sd.h> DNSServiceQueryRecord
functionality if available or just skip it if not available.
3) For non-mDNS use the same query as it does now.
Even if the choice is to just disable SRV lookups for mDNS hosts at a
minimum the code will have to determine whether or not the given host
name is a mDNS name and it can't reliably do that for a host name
without any dots in it without at least looking at the default domain
name and possibly the search domain(s) as well.
I think it would be much simpler just to make this opt-in via a config
option rather than baked in as it's probably going to be rather messy
without direct mDNS support in the res_query interface.
--Kyle
[1] http://avahi.org/
[2] http://avahi.org/download/doxygen/index.html
[3] http://tools.ietf.org/html/rfc6762#page-52
[4] https://www.mail-archive.com/tech@xxxxxxxxxxx/msg06100.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html