Bug#192744: libc6: dns resolving problems
reassign 192744 host
retitle 192744: host: doesn't use search list
thanks
On Sat, May 10, 2003 at 12:35:14AM +0200, Ingo Juergensmann wrote:
> Package: libc6
> Version: 2.3.1-17
> Severity: normal
>
> There is a problem with resolving hostnames in current sid.
>
> First, here is a working one from a woody system (arrakis m68k autobuilder
> that is):
>
> [ij@arrakis:]~$ host -v muaddib
> Trying "muaddib.os.localnet"
> Trying "muaddib.hro.localnet"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55915
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;muaddib.hro.localnet. IN A
>
> ;; ANSWER SECTION:
> muaddib.hro.localnet. 172800 IN A 192.168.0.1
>
> ;; AUTHORITY SECTION:
> hro.localnet. 172800 IN NS muaddib.hro.localnet.
>
> ;; ADDITIONAL SECTION:
> muaddib.hro.localnet. 172800 IN A 192.168.0.1
>
> Received 84 bytes from 192.168.1.1#53 in 46 ms
>
>
>
>
> On the local nameserver to arrakis itself this doesn?t work with sid:
>
> [root@fremen:]/etc/bind# host -v muaddib
> Query about muaddib for record types A
> Trying muaddib within os.localnet ...
> Query failed, 0 answers, authoritative status: non-existent domain
> Authority information:
> os.localnet 172800 IN SOA fremen.os.localnet
> root.localhost (
> 1999092907 ;serial (version)
> 86400 ;refresh period (1 day)
> 7200 ;retry interval (2 hours)
> 604800 ;expire time (1 week)
> 172800 ;default ttl (2 days)
> )
> muaddib.os.localnet does not exist (Authoritative answer)
>
>
> Both machines have identical /etc/resolv.conf files, same /etc/nsswitch.conf
> hosts order, but different host tools. Arrakis is using bind9-host, fremen
> instead uses host package in version 20000331-8.
>
> As you can see, host resolving don?t following the search directive in
> /etc/resolv.conf (which is: search os.localnet hro.localnet). It only try to
> resolv the first domain listed.
>
> This bug was reproduced on different machines and by a second person
> on a different network/bind setup.
>
This is actually a problem of the host package, which does much of the
resolving process by itself. For example, telnet that uses
gethostbyname() does not suffer for this problem.
I am therefore reassigning the bug.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: