How to resolve names

Norbert Kolvenbach <noko4711@t-online.de> writes:

>Ian Northeast wrote:

>> On Sun, 18 Mar 2007 17:56:35 +0100, Norbert Kolvenbach wrote:
>>
>>> Dear experts,
>>>
>>> this is possibly a very dumb problem/question and that may be the reason
>>> I do not get a resolution.
>>>
>>> i have 3 Linux pc connected to the internet via WLAN DSL router. 2 are
>>> conencted via WLAN one is directly connected via LAN cable. The router
>>> uses DHCP to assign dynamic IP addresses.
>>>
>>> So I can ping and try to ssh/telnet the 2 other machines from my PC via
>>> ip-address (no supprise).
>>>
>>> I cannot do it by using their host names although I get proper
>>> name/address resolution via nslookup.

What is in your /etc/resolv.conf? What does route -n say?


>>
>> As it stands this doesn't add up. If ping etc. by IP works and nslookup of
>> the names works (nslookup is a broken and outdated tool BTW, you should
>> use dig instead, but its brokenness does not extend to returning answers
>> when none are available) then ping etc. by name should too.
>>
>> I assume that the router is acting as the DNS server, can you confirm
>> this?

>Yes. Router is DNS and DHCP server

>>
>> What output/errors are issued when you:
>>
>> ping <name>

>ping: unknown host <name>

>>
>> dig <name>
>~> dig <name>

>; <<>> DiG 9.3.2 <<>> debach
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5425
>;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

>;; QUESTION SECTION:
>;debach. IN A

>;; ANSWER SECTION:
><name>. 10 IN A 192.168.2.101

>;; Query time: 1 msec
>;; SERVER: 192.168.2.1#53(192.168.2.1)
>;; WHEN: Mon Mar 19 17:48:01 2007
>;; MSG SIZE rcvd: 46

>>
>> host <name>
>~> host <name>
><name> has address 192.168.2.101
>Host <name> not found: 3(NXDOMAIN)
>Host <name> not found: 3(NXDOMAIN)

>>
>> getent hosts <name>
>>
>~>getent hosts <name>
>~>
>zero oputput!

>>
>>
>> Note that dig does not append the domain name specified in
>> /etc/resolv.conf, you have to include it in the command, i.e. dig
>> <host>.<domain>.
>>
>> what is in /etc/resolv.conf?

>cat /etc/resolv.conf
>### BEGIN INFO
>#
># Modified_by: dhcpcd
># Backup: /etc/resolv.conf.saved.by.dhcpcd.eth0
># Process: dhcpcd
># Process_id: 2644
># Script: /sbin/modify_resolvconf
># Saveto:
># Info: This is a temporary resolv.conf created by service dhcpcd.
># The previous file has been saved and will be restored later.
>#
># If you don't like your resolv.conf to be changed, you
># can set MODIFY_{RESOLV,NAMED}_CONF_DYNAMICALLY=no. This
># variables are placed in /etc/sysconfig/network/config.
>#
># You can also configure service dhcpcd not to modify it.
>#
># If you don't like dhcpcd to change your nameserver
># settings
># then either set DHCLIENT_MODIFY_RESOLV_CONF=no
># in /etc/sysconfig/network/dhcp, or
># set MODIFY_RESOLV_CONF_DYNAMICALLY=no in
># /etc/sysconfig/network/config or (manually) use dhcpcd
># with -R. If you only want to keep your searchlist, set
># DHCLIENT_KEEP_SEARCHLIST=yes in /etc/sysconfig/network/dhcp
>or
># (manually) use the -K option.
>#
>### END INFO
>domain localdomain
>nameserver 192.168.2.1
>~>

>> What does the "hosts:" entry in
>> /etc/nsswitch.conf read?

>cat /etc/nsswitch.conf
>#
># /etc/nsswitch.conf
>#
># An example Name Service Switch config file. This file should be
># sorted with the most-used services at the beginning.
>#
># The entry '[NOTFOUND=return]' means that the search for an
># entry should stop if the search in the previous entry turned
># up nothing. Note that if the search failed due to some other reason
># (like no NIS server responding) then the search continues with the
># next entry.
>#
># Legal entries are:
>#
># compat Use compatibility setup
># nisplus Use NIS+ (NIS version 3)
># nis Use NIS (NIS version 2), also called YP
># dns Use DNS (Domain Name Service)
># files Use the local files
># [NOTFOUND=return] Stop searching if not found so far
>#
># For more information, please read the nsswitch.conf.5 manual page.
>#

># passwd: files nis
># shadow: files nis
># group: files nis

>passwd: compat
>group: compat

>hosts: files dns
>networks: files dns

>services: files
>protocols: files
>rpc: files
>ethers: files
>netmasks: files
>netgroup: files nis
>publickey: files

>bootparams: files
>automount: files nis
>aliases: files

>~>
>
>> Regards, Ian

>That's the infroamtion which you ask for. Does this give an indication?

>Thanks for helping and looking into it!

>NoKo
>--
>"Careful with that VAX, Eugene!"

Unruh wrote:

> Norbert Kolvenbach <noko4711@t-online.de> writes:
>
>>Ian Northeast wrote:
>
>>> On Sun, 18 Mar 2007 17:56:35 +0100, Norbert Kolvenbach wrote:
>>>
>>>> Dear experts,
>>>>
>>>> this is possibly a very dumb problem/question and that may be the
>>>> reason I do not get a resolution.
>>>>
>>>> i have 3 Linux pc connected to the internet via WLAN DSL router. 2 are
>>>> conencted via WLAN one is directly connected via LAN cable. The router
>>>> uses DHCP to assign dynamic IP addresses.
>>>>
>>>> So I can ping and try to ssh/telnet the 2 other machines from my PC via
>>>> ip-address (no supprise).
>>>>
>>>> I cannot do it by using their host names although I get proper
>>>> name/address resolution via nslookup.
>
> What is in your /etc/resolv.conf?

please see below.

> What does route -n say?

/sbin/route -n
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0

>
>
>>>
<SNIP> .....
>>>
>>>
>>> Note that dig does not append the domain name specified in
>>> /etc/resolv.conf, you have to include it in the command, i.e. dig
>>> <host>.<domain>.
>>>
>>> what is in /etc/resolv.conf?
>
>>cat /etc/resolv.conf
>>### BEGIN INFO
>>#
>># Modified_by: dhcpcd
>># Backup: /etc/resolv.conf.saved.by.dhcpcd.eth0
>># Process: dhcpcd
>># Process_id: 2644
>># Script: /sbin/modify_resolvconf
>># Saveto:
>># Info: This is a temporary resolv.conf created by service dhcpcd.
>># The previous file has been saved and will be restored
>># later.
>>#
>># If you don't like your resolv.conf to be changed, you
>># can set MODIFY_{RESOLV,NAMED}_CONF_DYNAMICALLY=no. This
>># variables are placed in /etc/sysconfig/network/config.
>>#
>># You can also configure service dhcpcd not to modify it.
>>#
>># If you don't like dhcpcd to change your nameserver
>># settings
>># then either set DHCLIENT_MODIFY_RESOLV_CONF=no
>># in /etc/sysconfig/network/dhcp, or
>># set MODIFY_RESOLV_CONF_DYNAMICALLY=no in
>># /etc/sysconfig/network/config or (manually) use dhcpcd
>># with -R. If you only want to keep your searchlist, set
>># DHCLIENT_KEEP_SEARCHLIST=yes in
>># /etc/sysconfig/network/dhcp
>>or
>># (manually) use the -K option.
>>#
>>### END INFO
>>domain localdomain
>>nameserver 192.168.2.1
>>~>

<SNIP> ....

>>NoKo
>>--
>>"Careful with that VAX, Eugene!"
NoKo
--
"Careful with that VAX, Eugene!"

On Mon, 19 Mar 2007 18:42:00 +0100, Norbert Kolvenbach wrote:

> Ian Northeast wrote:
>
>> On Mon, 19 Mar 2007 17:54:54 +0100, Norbert Kolvenbach wrote:
>>
>>> Ian Northeast wrote:
>>
>>>> What output/errors are issued when you:
>>>>
>>>> ping <name>
>>>
>>> ping: unknown host <name>
>>>
>>>
>>>> dig <name>
>>> ~> dig <name>
>>>
>>> ; <<>> DiG 9.3.2 <<>> debach
>>> ;; global options: printcmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5425 ;; flags: qr
>>> aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>>>
>>> ;; QUESTION SECTION:
>>> ;debach. IN A
>>>
>>> ;; ANSWER SECTION:
>>> <name>. 10 IN A 192.168.2.101
>>>
>>> ;; Query time: 1 msec
>>> ;; SERVER: 192.168.2.1#53(192.168.2.1) ;; WHEN: Mon Mar 19 17:48:01
>>> 2007 ;; MSG SIZE rcvd: 46
>>
>> Now that's odd. I assume you issued the dig command with the unqualified
>> name, i.e. not followed by ".localdomain" which as per your resolv.conf
>> is your domain name. That shouldn't have worked. That response is for a
>> fully qualified name of just <name> - see that "." at the end. This
>> isn't right. I think your router's DNS server is misbehaving.
>>
>>
> Yes I issued "dig name" and not "dig name.localdomain". The latter does
> not work as you laid out.
>
>> Try issuing "ping <name>." complete with the trailing ".".
>>
>> Are any firmware updates available for your router?
>>
>>
> Interestingly "ping <name>." works!

Right. So we know what's wrong with your router's DNS server. Instead of
serving a domain called "localdomain" with its clients' names in it, it
is serving out each name as a top level domain itself. It shouldn't be
doing this. I assume it was DHCP which put the "domain localdoain" in your
resolv.conf was it? This must have come from the router's DHCP server.

> Firmware updates are notr available yet. It is a brand new hardware.

Unfortunate. I suspect there will be one soon. Is there anything you can
see in its menus which could control this - anything about appending the
domain name to DNS names or some such? Or somewhere to specify a local
domain name?

But Linux should still be able to resolve the names. It should try the
qualified name first then if that doesn't exist, try it on its own. It
doesn't seem to be doing this. Try this:

In one terminal window, as root, run:

tcpdump -i eth0 -s 1500 host <router's IP address> port 53

Which will trace the DNS traffic between the client and the router.

In another terminal on the same machine, issue the ping (without the
trailing ".").

Then post the output of the tcpdump. Exit tcpdump with ctrl-C.

What is your Linux distro? And what version of libc do you have (ls -l
/lib/libc-*)?

Regards, Ian

Ian Northeast wrote:

> On Mon, 19 Mar 2007 18:42:00 +0100, Norbert Kolvenbach wrote:
>
>> <SNIP ...>
>
> Unfortunate. I suspect there will be one soon. Is there anything you can
> see in its menus which could control this - anything about appending the
> domain name to DNS names or some such? Or somewhere to specify a local
> domain name?
>
> But Linux should still be able to resolve the names. It should try the
> qualified name first then if that doesn't exist, try it on its own. It
> doesn't seem to be doing this. Try this:
>
> In one terminal window, as root, run:
>
> tcpdump -i eth0 -s 1500 host <router's IP address> port 53
>
The dump output is according to th commands:

dig debach.
dig debach
ping debach.
ping debach

where ping debach gives the "unknown host error"

tcpdump -i eth0 -s 1500 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
17:43:58.755006 IP noko1.iad1 > speedport.ip.domain: 5688+ A? debach. (24)
17:43:58.756238 IP speedport.ip.domain > noko1.iad1: 5688* 1/0/0 A debach
(46)
17:44:00.853439 IP noko1.iad1 > speedport.ip.domain: 41882+ A? debach. (24)
17:44:00.854448 IP speedport.ip.domain > noko1.iad1: 41882* 1/0/0 A debach
(46)
17:44:15.583300 IP noko1.iad1 > speedport.ip.domain: 47189+ A?
debach.localdomain. (36)
17:44:15.628229 IP speedport.ip.domain > noko1.iad1: 47189 NXDomain 0/1/0
(111)
17:44:21.690971 IP noko1.iad1 > speedport.ip.domain: 40642+ A?
debach.localdomain. (36)
17:44:21.735626 IP speedport.ip.domain > noko1.iad1: 40642 NXDomain 0/1/0
(111)

8 packets captured
16 packets received by filter
0 packets dropped by kernel


> Which will trace the DNS traffic between the client and the router.
>
> In another terminal on the same machine, issue the ping (without the
> trailing ".").
>
> Then post the output of the tcpdump. Exit tcpdump with ctrl-C.
>
> What is your Linux distro? And what version of libc do you have (ls -l
> /lib/libc-*)?
>
This is Suse 10.1

Kernel: Linux 2.6.16.27-0.9-default x86_64

libc: libc-2.4.so

> Regards, Ian

Hope this gives some more input for clarification.

Regards,

NoKo
--
"Careful with that VAX, Eugene!"

Norbert Kolvenbach wrote:

> Ian Northeast wrote:
>
>> On Mon, 19 Mar 2007 18:42:00 +0100, Norbert Kolvenbach wrote:
>>
>>> <SNIP ...>
>>
>> Unfortunate. I suspect there will be one soon. Is there anything you can
>> see in its menus which could control this - anything about appending the
>> domain name to DNS names or some such? Or somewhere to specify a local
>> domain name?
>>
>> But Linux should still be able to resolve the names. It should try the
>> qualified name first then if that doesn't exist, try it on its own. It
>> doesn't seem to be doing this. Try this:
>>
>> In one terminal window, as root, run:
>>
>> tcpdump -i eth0 -s 1500 host <router's IP address> port 53
>>
> The dump output is according to th commands:
>
> dig debach.
> dig debach
> ping debach.
> ping debach
>
> where ping debach gives the "unknown host error"
>
> tcpdump -i eth0 -s 1500 port 53
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
> 17:43:58.755006 IP noko1.iad1 > speedport.ip.domain: 5688+ A? debach.
> (24)
> 17:43:58.756238 IP speedport.ip.domain > noko1.iad1: 5688* 1/0/0 A debach
> (46)
> 17:44:00.853439 IP noko1.iad1 > speedport.ip.domain: 41882+ A? debach.
> (24)
> 17:44:00.854448 IP speedport.ip.domain > noko1.iad1: 41882* 1/0/0 A
> debach (46)
> 17:44:15.583300 IP noko1.iad1 > speedport.ip.domain: 47189+ A?
> debach.localdomain. (36)
> 17:44:15.628229 IP speedport.ip.domain > noko1.iad1: 47189 NXDomain 0/1/0
> (111)
> 17:44:21.690971 IP noko1.iad1 > speedport.ip.domain: 40642+ A?
> debach.localdomain. (36)
> 17:44:21.735626 IP speedport.ip.domain > noko1.iad1: 40642 NXDomain 0/1/0
> (111)
>
> 8 packets captured
> 16 packets received by filter
> 0 packets dropped by kernel
>
>
>> Which will trace the DNS traffic between the client and the router.
>>
>> In another terminal on the same machine, issue the ping (without the
>> trailing ".").
>>
>> Then post the output of the tcpdump. Exit tcpdump with ctrl-C.
>>
>> What is your Linux distro? And what version of libc do you have (ls -l
>> /lib/libc-*)?
>>
> This is Suse 10.1
>
> Kernel: Linux 2.6.16.27-0.9-default x86_64
>
> libc: libc-2.4.so
>
>> Regards, Ian
>
> Hope this gives some more input for clarification.
>
> Regards,
>
> NoKo

No Ideas? Still strange behaviour....

NoKo
--
"Careful with that VAX, Eugene!"

On Sat, 24 Mar 2007 14:33:14 +0100, Norbert Kolvenbach wrote:

> Norbert Kolvenbach wrote:

>> The dump output is according to th commands:
>>
>> dig debach.
>> dig debach
>> ping debach.
>> ping debach
>>
>> where ping debach gives the "unknown host error"
>>
>> tcpdump -i eth0 -s 1500 port 53
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode listening on eth0, link-type EN10MB (Ethernet), capture size 1500
>> bytes 17:43:58.755006 IP noko1.iad1 > speedport.ip.domain: 5688+ A?
>> debach. (24)
>> 17:43:58.756238 IP speedport.ip.domain > noko1.iad1: 5688* 1/0/0 A
>> debach (46)
>> 17:44:00.853439 IP noko1.iad1 > speedport.ip.domain: 41882+ A? debach.
>> (24)
>> 17:44:00.854448 IP speedport.ip.domain > noko1.iad1: 41882* 1/0/0 A
>> debach (46)
>> 17:44:15.583300 IP noko1.iad1 > speedport.ip.domain: 47189+ A?
>> debach.localdomain. (36)
>> 17:44:15.628229 IP speedport.ip.domain > noko1.iad1: 47189 NXDomain
>> 0/1/0 (111)
>> 17:44:21.690971 IP noko1.iad1 > speedport.ip.domain: 40642+ A?
>> debach.localdomain. (36)
>> 17:44:21.735626 IP speedport.ip.domain > noko1.iad1: 40642 NXDomain
>> 0/1/0 (111)

>> This is Suse 10.1
>>
>> Kernel: Linux 2.6.16.27-0.9-default x86_64
>>
>> libc: libc-2.4.so

> No Ideas? Still strange behaviour....

Sorry, I've been away (no Internet access at my parents' place).

I don't know why it's failing to try looking up "debach." when
"debach.localdomain" doesn't work. That isn't correct IME, it should. All
my systems do, but I don't have SUSE 10.

There's one interesting thing in your tcpdump output. Your other machine's
name is being resolved to "noko1.iad1". Is this coming from its
/etc/hosts? If not, then it's coming from the nameserver. Does
"debach.iad1" resolve? If so you could try adding "search iad1" to
resolv.conf and following the instructions therein to prevent DHCP
overwriting the search list.

Also the nameserver appears to be resolving its own address to
"speedport.ip.domain". So you could try adding "ip.domain" to the search
list too (unlike the domain keyword, search can take multiple values).

Regards, Ian