Name resolution

Hi All,

I have been struggling with network name resolution - yes, I know this off topic but I have not been able to solve despite google being my friend…

I have a Asus 66U running Merlin firmware. I am running a windows server 2016 domain. Name resolution works great between the windows machines.

My first foray into Linux was setting up the PI with OH. That has gone great, I can log on to the PI using the machine name openhabianpi. Can you that from any of the windows machines in my network.

I am adding several other devices (ie ESP8266, ESP32, Pi Zero’s) - but I cannot get name resolution working. More frustrating, is my router sees the devices, and knows there names, but I cannot putty into them without using their IP address. More importantly, I don’t want to hard code my MQTT broker address. But I cannot get reliable name resolution work for these device. Despite an pretty exhaustive search and trying to understand how name resolution works, I am quite lost. I especially don’t understand how my router can see the devices but they can’t find each other…

Mike

Hi, Michael (@mjcumming).

I don’t run Windows here unless I have no other choice, but I’ll see if I can help.

  1. What system on your LAN provides DNS services, is it your router, your domain controller, or some other server?
  2. Also, I assume you have a DHCP server somewhere on your network, is that the same system as the one that provides DNS services or a different one?
  3. If you are running a DHCP server, how is it configured?

On my system here, the DHCP server specifies host IP addresses, subnet mask and default gateway, which all DHCP servers do. In addition to these settings, my DHCP server also specifies search domains and DNS servers. I would check all of these settings. If you have already done so, and everything seems copacetic, I would install dnsutil on your RPi and, from an SSH session on the RPi, execute the following:

[09:27:26] root@rpi3:~# cat /etc/resolv.conf 
# Generated by resolvconf
domain karnstech.com
search karnstech.com karnsfamily.org
nameserver 192.168.1.254
[09:27:30] root@rpi3:~# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
[09:27:52] root@rpi3:~# dig -x 192.168.1.205

; <<>> DiG 9.10.3-P4-Raspbian <<>> -x 192.168.1.205
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48871
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;205.1.168.192.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
205.1.168.192.in-addr.arpa. 3600 IN     PTR     rpi3.karnsfamily.org.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 86400   IN      NS      firewall.karnstech.com.

;; ADDITIONAL SECTION:
firewall.karnstech.com. 3600    IN      A       192.168.1.254
firewall.karnstech.com. 3600    IN      A       172.20.0.1

;; Query time: 0 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Mon Dec 24 09:35:48 MST 2018
;; MSG SIZE  rcvd: 157

[09:27:39] root@rpi3:~# dig rpi3.karnsfamily.org

; <<>> DiG 9.10.3-P4-Raspbian <<>> rpi3.karnsfamily.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60317
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rpi3.karnsfamily.org.          IN      A

;; ANSWER SECTION:
rpi3.karnsfamily.org.   3600    IN      A       192.168.1.205

;; AUTHORITY SECTION:
karnsfamily.org.        86400   IN      NS      firewall.karnstech.com.

;; ADDITIONAL SECTION:
firewall.karnstech.com. 3600    IN      A       172.20.0.1
firewall.karnstech.com. 3600    IN      A       192.168.1.254

;; Query time: 1 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Mon Dec 24 09:27:52 MST 2018
;; MSG SIZE  rcvd: 133

I ran the above on my OH2 RPi, the FQDN of which is rpi3.karnsfamily.org, and got the responses shown. Hopefully the results you get will help shed some light on whatever may be wrong with DNS on your system.

[Updated to include reverse hostname lookup.]

Hi Scott, the router is set to do DHCP and DNS. The server/domain controller also offers DNS services.

Running dnsutils cat /etc/resolv.conf I see.

# Generated by resolvconf
nameserver 192.168.1.2
nameserver 192.168.1.1

That’s useful info. I would check the IP address of one of the hosts that can’t be reached by name at each of your nameservers:

dig @192.168.1.2 myhost.mydomain
dig @192.168.1.1 myhost.mydomain

I suspect your two nameservers aren’t in sync and each considers itself to be the master DNS server for 192.168.1.0/24. Do you really need both nameservers? If so, one should be configured as the master and the other as slave to the master server. Here is one howto for such a setup. I am not familiar with how a Windows hosted DNS server is configured, perhaps someone how is will chime in.

I will look that master/slave setup. I have the windows server configured to forward requests to the router.

I have tried using nslookup - all the windows machines resolve correctly but my Linux devices do not.

That sounds to me like your windows server is not the authoritative DNS server for your LAN zone, which is reasonable. What do you get from each server when you query (in an SSH session on your RPi) for both forward (FQDN -> IP address) and reverse (IP address --> FQDN) lookups for one of the hosts that can’t be referenced by name?

dig @192.168.1.2 host1.mydomain
dig -x @192.168.1.2 <host1 IP address>
dig @192.168.1.1 host1.mydomain
dig -x @192.168.1.1 <host1 IP address>

Also, are all of the other hosts on your network configured with manually assigned, static IP addresses, or do they all get IP addresses from your DHCP server?

Here is the output from my pi using nslookup to a windows box

> kitchenenvy
;; Got SERVFAIL reply from 192.168.1.2, trying next server
Server:         192.168.1.1
Address:        192.168.1.1#53

Name:   kitchenenvy
Address: 192.168.1.170
>

and this is the output from nslookup from a windows box to a windows box


kitchenenvy
Server: UnKnown
Address: 192.168.1.2

Name: kitchenenvy.QUEEN.local
Address: 192.168.1.170

What are the contents of /etc/resolv.conf on your pi?

> ^C[11:40:57] openhabian@openHABianPi:~$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.1.2
nameserver 192.168.1.1

That would seem to be the problem. No domain and no search domain(s). kitchenenvy is not a fully qualified domain name. What happens if you query your router for kitchenenvy.local?

Wouldn’t the problem be on the windows box with name resolution as I can’t find the PI from my windows box?

Same thing goes for looking up kitchenenvy on a windows box – an FQDN is needed for lookup . WIthout a search domain, it can’t come up with an FQDN.

I think I don’t fully understand :slight_smile:

within my local network, I have always just used the machine name not a FDQN. Ie if I want to RDP into a machine I just type the name in. Using ping with the machine name resolves to the right IP address.

and my Linux machines can find each other just using their machine names. Its a windows to Linux problem

Take a look at the contents of my /etc/resolv.conf in my first post of this thread, domain is set to karnstech.com and search is set to a two element list, karnstech.com and karnsfamily.org. If I lookup a non-FQDN from my pi, it will first seach for non-FQDN-name.karnstech.com, then, if that hostname isn’t found, it will try non-FQDN-name.karnsfamily.org.

OK, now I understand which of your hosts have the problem. I suspect that windows needs those non-FQDN hostnames in a config file (lmhosts?), or it needs to be configured with a base domain name consistent with whatever base domain name your linux systems are using. From the information you have provided, I suspect they are using mDNS, which is a somewhat different problem.

Is QUEEN.local the name of your windows DNS server, or is that the subdomain it is using?

right, I could use lmhosts, and I have in the past but that is an ugly solution long term. After working throught the above I think the problem is the DNS on the windows server is not forwarding the requests to the router when it cannot resolve

The domain is Queen, the DC is named Server.

This is what happens when a weekend warrior sets up a network too complex for them to manage :smile:

Have you tried this query from your pi:

dig @192.168.1.1 kitchenenvy

?