Bug 298901 – app-portage/layman-1.2.4 only tries first configured DNS server

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Robin Bankhead 2009-12-29 18:36:29 UTC]

The first configured DNS server on my system is a local IP running dnsmasq to provide hostnames for other machines on my LAN. It only serves the local hostnames, so for any external FQDNs an application must turn to the second configured DNS server (which is my ISP's).

All other network-aware applications (firefox, konqueror, thunderbird, skype, mplayer, and of course portage) on my system obey this behaviour, but layman does not.  With the DNS configuration described above, any commands that require a DNS lookup, e.g. layman -S or layman -L, fail with a urlopen error.

If the local nameserver is commented-out from /etc/resolv.conf (so the ISP nameserver is checked first), all operations succeed as expected.

Expected behaviour: layman should try all configured nameservers until the requested hostname is resolved, or the list is exhausted.

Will provide emerge --info if required; not doing so initially as it doesn't seem relevant in this case.

[Comment 1 Sebastian Pipping 2009-12-30 04:28:11 UTC]

I'm a bit puzzled by that bug report.  Let me ask two questions:
- Is a DNS server listed in resolve.conf required to do full iterative lookups? If not why is it in there?
- I don't know how to configure the way Python talks to DNS, yet.  Do you?

[Comment 2 Robin Bankhead 2009-12-30 12:10:58 UTC]

Hello Sebastian,

>- Is a DNS server listed in resolve.conf required to do full iterative lookups?
If not why is it in there?
I can't answer the first question as I don't know, I'm afraid. As for the second, the purpose of the local nameserver is to resolve the hostnames on my LAN, which an external nameserver can't do. I don't want that machine acting as nameserver for WAN hostnames too, as it would overwork it.

>- I don't know how to configure the way Python talks to DNS, yet.  Do you?
No, but then I didn't know it was python's behaviour and not that of layman itself.

[Comment 3 Robert Buchholz (RETIRED) 2009-12-31 02:10:23 UTC]

All resolvers in resolv.conf are handled equally and (unless rotation is specified) queried in the same order. If your primary configured name server returns NXDOMAIN for a name (which it probably does, try `dig gentoo.org @localdns'), then layman (and every other application) is correct to assume the name does not exist. If it were to query all name servers, you would experience long wait times for every unknown name if any of the servers is unreachable or slow.
For your use case, either configure the local DNS to do recursive lookups, or configure a bind instance with two zones on the local machine.

[Comment 4 Robin Bankhead 2010-01-03 01:11:14 UTC]

'dig @localnamesrver gentoo.org' returns REFUSED, not NXDOMAIN. I don't know if this affects your remark about "any other application", but as I mentioned above, no other application I've used in the months since I embarked on this setup has had any timeouts or failures in resolution.

[Comment 5 Sebastian Pipping 2010-01-03 02:43:44 UTC]

(In reply to comment #4)
> 'dig @localnamesrver gentoo.org' returns REFUSED, not NXDOMAIN.

I think Robert meant "localdns" to be a place holder for the actual IP from resolv.conf. Can you attach the resolv.log file produced by this command? Should be all one one line:

for i in $(grep '^nameserver ' /etc/resolv.conf | cut -d ' ' -f 2) ; do echo ====$i==== ; dig @$i gentoo.org ; done | tee resolv.log

[Comment 6 Robin Bankhead 2010-01-03 12:34:42 UTC]

Yes, I figured his meaning from the manpage; I was just echoing his style ;)
Anyway, here's the output from the local nameserver (the second one resolves normally):

minime ~ # dig @192.168.2.6 gentoo.org

; <<>> DiG 9.6.1-P2 <<>> @192.168.2.6 gentoo.org
; (1 server found)                              
;; global options: +cmd                         
;; Got answer:                                  
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 13362
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gentoo.org.                    IN      A

;; Query time: 7 msec
;; SERVER: 192.168.2.6#53(192.168.2.6)
;; WHEN: Sun Jan  3 12:28:30 2010
;; MSG SIZE  rcvd: 28

[Comment 7 Sebastian Pipping 2010-02-26 18:34:23 UTC]

So what can we do?

[Comment 8 Robin Bankhead 2010-02-27 17:04:18 UTC]

What can I say?  The feedback so far seems to be that mine is an edge-case and perhaps counterintuitive, so if that's the feeling then perhaps I ought to withdraw it.

I still don't share that feeling because (a) it doesn't seem unreasonable to me to have a minimal DNS resolver whose purpose is to resolve only a single domain and its subdomains in a local context in cases where it can't be done any other way; and (b) all other applications I've used seem happy to try secondary nameservers if the first returns a REFUSED.  However I'm not a maven of RFCs so it's not for me to say what's "proper".

It's up to your judgement; all I can really do is withdraw the bug and settle for a workaround, if you judge against.

[Comment 9 Sebastian Pipping 2010-07-05 14:20:36 UTC]

Closing as wontfix as I really wont be able to.
I hope you found a workaround in the mean time.