** Summary changed: - apt-get "Could not resolve" DNS names (64-bit Jaunty Alpha 4) + [Jaunty] Multiple DNS resolver issues on ia32 and AMD64
** Description changed: - Binary package hint: apt + [EDIT: This bug was originally filed against apt as "apt-get "Could not resolve" DNS names (64-bit Jaunty Alpha 4)"] + [It has since become obvious that I have uncovered at least two separate bugs or unexpected behaviors in system-wide resolver behavior, though I haven't ruled out further fragility in apt-get itself!] + [I am hesitant to completely rewrite this "Description" which describes my first experience of the problem; please see the further comments and attachments on this bug that expand the scope of the issue.] + [Of course, prior to this edit, the original "Binary package hint:" for this bug was "apt".] + + ===ORIGINAL DESCRIPTION BELOW:=== apt-get seems to get into trouble resolving DNS names when other programs, including nslookup and dig, Firefox, and ping are unaffected. This results in warnings like: W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/jaunty-security/Release.gpg Could not resolve 'security.ubuntu.com' ...and obviously makes it difficult to use apt! In researching the problem, people seem fond of blaming nsswitch/mdns/avahi, specific DNS servers or the phase of the moon. However, there is clearly some real bug (or unexpected behavior) here. Not aiding my attempts to debug the issue: when I attempt to use tcpdump to monitor the DNS lookups, e.g. with `sudo tcpdump -ni eth0 -vvvv > dump`, it often goes away! Then, without tcpdump running, it's back! Perhaps this is actually a kernel bug of some flavor? I am having a bit of trouble following the actual lookups (and results) in the strace output [produced via `sudo strace -v -s4096 apt-get update`] attached. Can someone have a look at what is going on there? At the time that was taken: resolv.conf was/is: # Generated by NetworkManager domain gateway.2wire.net search gateway.2wire.net nameserver 172.16.0.1 [This is a 2Wire Homeportal gateway, which has some sort of DNS cache/DNS proxy in it -- at least enough to let you address the device by the hostname 'homeportal'. I've never had any trouble running lookups through it on numerous other Linux, BSD, and Windows systems.] nsswitch.conf was: # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: compat group: compat shadow: compat #hosts: files mdns4_minimal [NOTFOUND=continue] dns mdns4 hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis [The behavior was first observed with Jaunty's default nsswitch.conf; I first tried the [NOTFOUND=continue] edit for mdns lookups commented above, then chopped it down to only files and dns, and have since chopped it down to *only* "dns." Mysteriously, chopping it down to only "dns" has "switched the bug around" -- now apt-get can resolve us.archive.ubuntu.com but security.ubuntu.com fails. Unless I'm running tcpdump on the interface - then everything works!?] ** Tags added: apt dns jaunty kernel linux resolver -- [Jaunty] Multiple DNS resolver issues on ia32 and AMD64 https://bugs.launchpad.net/bugs/326718 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
