Well, it's not a bind(8) problem. Nor is it a generic libc problem, by the sounds of it. The GSSAPI thing is a royal PITA - I have to turn it off for significant numbers of hosts in ~/.ssh/config, and that’s in an environment *with* functional forward and reverse IPv6 mappings. (Yes, it's Kerberos-related. Usually. At least nothing else we're ever likely to run into uses GSSAPI.) On the rare occasions that GSSAPI works (ssh as yourself to another machine joined to the same AD domain, for example) it's mildly handy but not exactly a life-changing feature. TBH, it's more surprising/startling than helpful... Also, my mistake - it was nslookup(1) that was deprecated. And apparently then rewritten and un-deprecated in BIND 9.9.0a3 (see https://kb.isc.org/article/AA-00496/0/BIND-9.9.0a3-Release-Notes.htm, #1700). I suppose it could be a libc bug... you'd think it would affect more than just host(1) and sshd(8), though...? Or is that the extent of software that normally does reverse lookups nowadays? In the problematic host(1) call, add "-d", and specify "A" records only using "-t", is the best I can suggest. You can also influence resolver behaviour with /etc/gai.conf and /etc/host.conf - not sure if any of those knobs will solve your exact problem or not. I think promoting the IPv4-compatibility rules in gai.conf *might* be useful to you, not sure. -Adam
-----Original Message----- From: Roundtable [mailto:roundtable-bounces@muug.ca] On Behalf Of Trevor Cordes Sent: November 22, 2016 00:03 To: Adam Thompson athompso@athompso.net Cc: Continuation of Round Table discussion roundtable@muug.ca Subject: Re: [RndTbl] help! dns zone delegation wonky for AAAA
On 2016-11-21 Adam Thompson wrote:
Sounds like a bug in host(1), which has been deprecated for several years now. Recommended solution: switch to "dig +short" instead.
I know host is outdated and maybe obsolete, but I see/saw no mention that it is deprecated (or unsupported). I guess I could try filing a bug for it to see. I use it mostly out of habit, and to save typing +short :-)
The reason this bug piqued my interest is actually not host(1), it is ssh when connecting to one of the "out" boxes from BOX1. Periodically all ssh attempts to the out box will take about 1-2 mins to startup. If I do ssh -vvv I can see it taking about 10s to do the initial name lookup (meaning it too is fetching more than just A records), but worst is the GSSAPI negotiation takes about 30s for each (of 3) attempts.
GSSAPI always fails to all my boxes it seems (maybe because no kerberos??) but the failures happen in a fraction of a second, so I don't care. Google says to disable all GSSAPI in ssh config but it seems to be there by default now, and it doesn't hurt anything in every case except for this buggy one, so my preference is to leave it as-is and fix the DNS issue. (Besides, it's in my nature to solve the root problem and not resort to workarounds.)
So far, it's just host and ssh that seem to exhibit this behavior, but I guessed there would be more. Maybe that's wrong. There might be a way to force ssh to not do other-than-A lookups, and that would be a possible solution to this... I'll investigate some more.
I can't believe there's not more BIND gurus in the club?? _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable