Jump to content

DNS issues for local network with Armbian only


emk2203

Recommended Posts

Setup:

 

I have a small home network with several SBCs, PCs, NASs and two devices are running Armbian ARMBIAN 5.59, ARMBIAN 5.59 stable Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Orange Pi Zero and ARMBIAN 5.59 testing Ubuntu 18.04.1 LTS 4.14.65-sunxi for the Cubieboard 1. The OPi Zero runs the PiHole application for the whole network. There's a MikroTik router which does DHCP for the network.

 

Problem:

 

The Armbian devices are not able to do a local name resolution, a `ping router.lan` or `ping orangepizero.lan` or `ping cubieboard.lan` from either device gives the error: "Name or service not known".  A ping by IP is without issues, same problem for services like SSH. All other devices, NAS with FreeNAS 11.2, a My Book Live with a custom Debian 8.11, Hardkernel XU4 and HC1 as well as all PCs with Linux or Windows are able to ping all local devices by name. 

 

The Armbian devices have OK outside connectivity. `ping google.com` is giving the expected results.

 

Conclusions:

 

  • The problem is restricted to the Armbian machines. PiHole might be the root cause, but all other machines are able to deal with this specific configuration, and both Armbian devices won't resolve local names.

 

Failed:

 

sudo dpkg-reconfigure resolvconf

didn't solve the problem. So far, I decided to post here to find a good way to debug this.

 

A `dig router.lan` (this is the router at 192.168.88.1) from my laptop:

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51279
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;router.lan.			IN	A

;; ANSWER SECTION:
router.lan.		547794	IN	A	192.168.88.1

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Aug 24 15:12:14 CEST 2018
;; MSG SIZE  rcvd: 55

A `dig router.lan` from an Armbian device:

 

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> router.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25576
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;router.lan.			IN	A

;; AUTHORITY SECTION:
.			86395	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2018082400 1800 900 604800 86400

;; Query time: 27 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Aug 24 15:11:50 CEST 2018
;; MSG SIZE  rcvd: 114

I clearly see that the results are different, but don't know how to fix. What's the best approach here?

 

The results of `armbianmonitor -u` are at http://ix.io/1l7x for the Cubieboard and at http://ix.io/1l7y for the OPi Zero.

Link to comment
Share on other sites

56 minutes ago, emk2203 said:

;; SERVER: 127.0.0.53#53(127.0.0.53)

 

This query has been answered by a DNS resolver running on your laptop.

 

56 minutes ago, emk2203 said:

;; SERVER: 8.8.8.8#53(8.8.8.8)

 

This query has been answered by Google's DNS server. Results as expected.

 

I would assume on your laptop systemd-resolved is resolving queries but uses the upstream DNS config obtained by DHCP and your Armbian installation does not but has been told to use 8.8.8.8

 

As usual the best idea is to always provide 'armbianmonitor -u' output since it's such a waste of time digging for information in a dialog.

Link to comment
Share on other sites

@tkaiser: Added the links to the post.
@guidol:  Network is default Armbian configuration, didn't mess with it. DHCP comes from router, correctly configured, all other devices work well. PiHole resolves whatever I throw at it. One device with Debian 8.11 has only the information for the PiHole in `/etc/resolv.conf` (coming from the router DHCP) and works excellent.

 

---

 

Actually, problem solved. I was used to not look at `/etc/resolv.conf` anymore because it's just a dummy file when `systemd-resolved` is used, but in the Armbian version, `/etc/resolv.conf` is a file with `nameserver 8.8.8.8` as the first line. Why is this in there? I use CloudFlare DNS(SEC), and not Google's servers. Definitely didn't enter this.

 

This is the contents of `/etc/resolv.conf` on my laptop, which I expected to be standard in Armbian as well.

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

Instead, I had 

nameserver 8.8.8.8
nameserver 127.0.0.53
search lan

with the first line now commented out, and now it works on the Armbian machines as well.

 

Maybe this is in there as an artifact from whatever, but it takes precedence over the `systemd-resolved` nameserver 127.0.0.53. If this a bug of the standard Armbian image?

 

Well, a lot of writing for nothing, but it helped me debug. Thanks to you all.

Link to comment
Share on other sites

28 minutes ago, emk2203 said:

Maybe this is in there as an artifact from whatever, but it takes precedence over the `systemd-resolved` nameserver 127.0.0.53. If this a bug of the standard Armbian image?

 

Please see

 

It seems writing something to /etc/resolvconf/resolv.conf.d/head at image creation time creates this issue and removing the file should solve it. @Igor wanted to look into but no idea what happened.

 

IMO neither using Google's DNS nor Cloudflare's is a brilliant idea and we should really change this so user's local config always wins. Details: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/

 

Link to comment
Share on other sites

Thanks for letting me know, I purged the contents of `/etc/resolvconf/resolv.conf.d/head` to get rid of the `nameserver 8.8.8.8` line. Otherwise, `systemd-resolved` would probably sneak it in again next time it has a chance.

 

I agree, leaving it in there at image creation time can create a lot of unnecessary confusion. As you said, user's local config should take preference, maybe with a commented line with Google's nameserver and the additional comment `# In case of DNS problems, try uncommenting this for debugging` or similar. 

Link to comment
Share on other sites

4 hours ago, emk2203 said:

maybe with a commented line with Google's nameserver and the additional comment `# In case of DNS problems, try uncommenting this for debugging` or similar.

 

Tried a fix with https://github.com/armbian/build/commit/f10acc0080825faf711eb6e6b7425910d75d840c

 

Would be great if you could try next nightly version and report back.

Link to comment
Share on other sites

35 minutes ago, emk2203 said:

dl.armbian.com has no nightlies

 

I tested myself and now it looks like this:

root@nanopct4:~# cat /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
#LLMNR=yes
#DNSSEC=no
#Cache=yes
#DNSStubListener=udp
root@nanopct4:~# cat /etc/resolvconf/resolv.conf.d/head
# In case of DNS problems, try uncommenting this and reboot for debugging
# nameserver 1.1.1.1

Problem solved I would say...

Link to comment
Share on other sites

i'm running Ubuntu Xenial Armbian distribution, apparently one of the setups is that Avahi / bonjour / mdns is used

as all i need for now is to be able to 'find my board', i simply set publish-workstation=yes in /etc/avahi/avahi-daemon.conf

using that i'm able to query my board using avahi-browse -a from another linux host.

 

** solution **

i compared /etc/nsswitch.conf and noted that on my pc the "hosts:" line read similar to this

 hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

while that in the Armbian install is missing that mdns_minimal plug, then i go about reading/researching other things

https://www.avahi.org/

https://github.com/lathiat/nss-mdns

 

and i noted libnss-mdns isn't installed on the Armbian sbc, and so i did this:

apt-get install libnss-mdns

after this, i noted the mdns4_minimal plug is added in /etc/nsswitch.conf and i'm able to ping my linux host from Armbian as hostname.local, i'm not sure about other os e.g. windows etc

 

*** notes ***

that means in effect the other hosts (be they linux, windows, routers) etc on the same segment needs to run mdns / bonjour / avahi in order that they can be dynamically resolved. alternatively, you may need to run a local dns on the lan to resolve them, in which those 'other hosts' are manually statically patched into the dns database / files. Make sure your lans is *private and secure*, mdns simply let the hosts (including an armbian sbc) broadcast their own hostname on the lan, so any host can claim to be any name, no authentication

Link to comment
Share on other sites

another way as it turns out is even more illusive, that is based on windows *active directory* dynamic dns updates

https://docs.microsoft.com/en-us/windows/desktop/ad/active-directory-servers-and-dynamic-dns

https://www.piersc.uk/posts/active-directory-dynamic-dns-and-linux-clients.html
https://help.ubuntu.com/lts/serverguide/sssd-ad.html.en

as i do not use an active directory for that matter above are some of the links i stumbled into on a google search

apparently that would require things like sssd-ad, samba etc

Link to comment
Share on other sites

another way as it goes is to use nsupdate for a dynamic dns

https://www.semicomplete.com/articles/dynamic-dns-with-dhcp/

http://linux.yyz.us/nsupdate/

http://wiki.inisec.com/index.php/Nsupdate_for_windows

you'd need to setup a dns with nsupdate capability and all the hosts (workstations, servers, sbc, etc) to do nsupdate. this isn't a 'default' setup and some work / additional apps (i.e. nsupdate) is needed. you'd also need to setup dhcp to point to your nsupdate equipped dns

 

the good thing about this is the delivered dhcp setup would 'just work', probably no changes required, but that there would be some setup for dhcpd to update the dns via nsupdate or that each host register themselves with the dns after setting up a valid ip address

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines