Re: git_inetd_server: run git-http-backend using inetd

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

Hi,

Kyle J. McKay wrote:

quoted

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