On Jul 17, 2014, at 15:10, Jonathan Nieder wrote:

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

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.


[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@openbsd.org/msg06100.html

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to