DNS resolving problem with Ubuntu *solved

Hello,
Please forgive my lack of DNS understanding in Linux. When I “Google” for solutions there are just too many to understand what the best approach is.

Router:
TurrisOS 5.2.6 9d082556fecfe2e971f964ebcd6b13fe30d208af / LuCI branch git-21.222.69112-b41f377
Kernel Version 4.14.244

My Windows setup works flawlessly. However with Ubuntu, local host names do not resolve properly. I have narrowed the problem down somewhat to systemd-resolved.

From my /etc/resolv.conf:

This file is managed by man:systemd-resolved(8). Do not edit.

nameserver 208.67.220.220
nameserver 8.26.56.26
nameserver 91.239.100.100
//Too many DNS servers configured, the following entries may be ignored.
nameserver 192.168.1.1 <--------- Move this to the top of the file it works, but I have to do this every boot
search lan

Is there an easy way to make Linux use more DNS names or just always resolve via the router? I want host names on my lan to be resolved by the router, I have way too many to be mucking with static hosts files and I certainly don’t want to stop using DHCP.

Thank you for any assistance,
J
Setting in reForis

I don’t think this would be related to Turris or its settings. (unless you explicitly configured its DHCP to do such things) These lines are normal from Turris

nameserver 192.168.1.1
# and IPv6 equivalent if you have it
search lan

I’m certainly no expert on setting these in resolved/networkmanager/… The other addresses appear to be regular public resolvers (OpenDNS, Comodo, censurfridns.dk), though the third one doesn’t work well for me.

How many network interfaces do you have on your Ubuntu box and how did you setup them? Using the default Settings GUI?

What you have in your resolv.conf is not what Ubuntu does by default; it does put nameserver 127.0.0.53 and search your-dhcp-domain into resolv.conf and that’s it. Then the systemd-resolved service listens on your localhost and handles the dns requests.

The reason for that is, that there is no way to configure in resolv.conf all the things that systemd-resolved can do. One of them is scoped requests; normally, all the nameservers in resolv.conf are considered equal (that they can return equally the same results) and might not be queries in the order (although glibc resolver does that). Systemd-resolved has its own configuration, and unless you changed that also, it is derived from NetworkManager provided information (i.e. what DHCP or PPP or static network connection configured).

So in your case, the 192.168.1.1 is probably DHCP configured. But where the first three items are coming from? resolvectl status will tell you, which network interfaces have it configured. Then you can check their configuration and if they are static entries, remove them from there. Presto, only your 192.168.1.1 DHCP configured entry will remain.

Yes, see above. Check your network interfaces configuration using your favorite NetworkManager frontend (probably Gnome Settings for most Ubuntu users).

I have a default config, whatever the Linux installer did for 20.04 LTS. My mobo has two adapters, but one is disabled.

Where are these coming from? If not the router? Does Linux just decide to add these? It seems like they are coming from the Quad9 unfiltered setting?
208.67.220.220
8.26.56.26
91.239.100.100

From resolve status:

Link 3 (enp4s0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 208.67.220.220
8.26.56.26
91.239.100.100
192.168.1.1
DNS Domain: ~.
lan

I looked through all the network settings. It just set to defaults:

Windows is working perfectly and shows the same addresses. My point is that everything is default, but 192.168.1.1 gets put on the bottom and then becomes unused in linux (so it seems).

If they are not coming from Turris where do they come from? All my machines get the same set of DNS IP’s from DHCP. From the turris:

root@Omnia_Turris:~# cat /etc/resolver/dns_servers/99_quad9_unfiltered.conf
name=“99_quad9_unfiltered.conf”
description=“Quad9 Unfiltered (TLS)”
enable_tls=“1”
port=“853”
ipv4=“9.9.9.10 149.112.112.10”
ipv6=“2620:fe::10 2620:fe::fe:10”
hostname=“dns.quad9.net
#pin_sha256=“G+ullr8exb9aHemu3vmI9Jwquuqe0DwnBdFHss8UfVw=”
ca_file="/etc/ssl/certs/ca-certificates.crt"
root@Omnia_Turris:~#

9.9.9.10 149.112.112.10 ← these are what I really want.

Thanks,
J

Looking at the DHCP from my cable modem, it is giving the router these:

DNS 1: 209.18.47.62
DNS 2: 209.18.47.63

So at least those are not being passed on to my client machines.

As an experiment I switched from Quad9 to CZ.NIC. Nothing changed. I switched it to Google, and rebooted the router, again nothing changed.

Wireshark DHCP ack capture:

Frame 544: 371 bytes on wire (2968 bits), 371 bytes captured (2968 bits) on interface \Device\NPF_{3C34E1A4-5939-462B-810B-CADA620C7C08}, id 0
Ethernet II, Src: CZNICzsp_00:43:b9 (d8:58:d7:xx:xx:xx), Dst: TRENDnet_ed:73:32 (3c:8c:xx:xx:xx:xx)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.12
User Datagram Protocol, Src Port: 67, Dst Port: 68
Dynamic Host Configuration Protocol (ACK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xe24c39d2
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 192.168.1.12
Your (client) IP address: 192.168.1.12
Next server IP address: 192.168.1.1
Relay agent IP address: 0.0.0.0
Client MAC address: TRENDnet_ed:73:32 (3c:8c:f8:ed:73:32)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (ACK)
Length: 1
DHCP: ACK (5)
Option: (54) DHCP Server Identifier (192.168.1.1)
Length: 4
DHCP Server Identifier: 192.168.1.1
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (100000s) 1 day, 3 hours, 46 minutes, 40 seconds
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (45269s) 12 hours, 34 minutes, 29 seconds
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (82769s) 22 hours, 59 minutes, 29 seconds
Option: (1) Subnet Mask (255.255.255.0)
Length: 4
Subnet Mask: 255.255.255.0
Option: (28) Broadcast Address (192.168.1.255)
Length: 4
Broadcast Address: 192.168.1.255
Option: (3) Router
Length: 4
Router: 192.168.1.1
Option: (15) Domain Name
Length: 3
Domain Name: lan
Option: (81) Client Fully Qualified Domain Name
Length: 18
Flags: 0x03, Server overrides, Server
A-RR result: 255
PTR-RR result: 255
Client name: KowloonTong.lan
Option: (6) Domain Name Server
Length: 16
Domain Name Server: 208.67.220.220
Domain Name Server: 8.26.56.26
Domain Name Server: 91.239.100.100
Domain Name Server: 192.168.1.1
Option: (255) End
Option End: 255

1 Like

Nice packet capture. The addresses really do seem to come from Turris DHCP.

This really is out of my range, but I’d inspect /etc/config/dhcp (on Turris), in particular lines with list dhcp_option '6,...' but you’d probably recognize the addresses. And I have absolutely no idea how you could arrive at such a configuration.

Well… there they are! How is this configured using the GUI?

config dhcp ‘lan’
option interface ‘lan’
option dhcpv6 ‘server’
option ra ‘server’
option ra_management ‘1’
option limit ‘100’
option leasetime ‘100000’
list dhcp_option ‘6,208.67.220.220,8.26.56.26,91.239.100.100,192.168.1.1’
option start ‘110’

Update: Found it! I don’t even remember doing this. Can I just delete that line? As a last question, how can I verify that the router is using the forwarder I configured? Thanks!

I don’t think there’s anything in (re)Foris for this. In luci [deleted] what you’ve found.

I’d use some web test probably. I don’t know… e.g. https://www.dnsleaktest.com

EDIT: these test also client and browser issues, i.e. they check where all your DNS traffic exits (towards authoritative servers; it may be a NAT e.g. if you uncheck forwarding).

1 Like

As you’ve found bad config you weren’t aware of, I’d personally consider a factory reset and configuring from scratch.

1 Like

Ouch… after I deleted that line, I don’t even have the router set as DNS. Do I need that DHCP-options entry to say:

6,192.168.1.1

“consider a factory reset and configuring from scratch.”

Not a bad I idea… I would like to keep my extensive static DNS entries though.

Yes, normal text line is

list dhcp_option '6,192.168.1.1'

(in the lan section, assuming that is your configured router address)

1 Like

208.67.220.220 is the IP of OpenDNS maybe this will remind you something. Anyway mark as solved!

In summary:

  1. My flavor of Linux doesn’t like more than 3 DNS entries.
  2. I had at some point added three more static entries to the option line.

Do you mean click the “Solution” check boxes?

Thanks,
J

1. is not really true. The thing is, that all nameservers in resolv.conf are considered equal - in the sense that they are supposed to return identical answers. Resolver goes from the first to last one, asks the first nameserver about the hostname and if it receives an answer (including NXDOMAIN, i.e. it doesn’t exists), it considers the answer final and won’t ask the second nameserver in the file, just to be sure. After all, they are supposed to return identical answers. It will switch to second server only if the first server stops responding. Similarly, it will ask the third one only if the second one stops responding, in round-robin fashion.

You cannot have there servers providing different answers. For that to work, you need 1. configured scoped servers (i.e. configuration telling which of the servers are “special”) 2. resolver different than the glibc one, i.e. either dnsmasq or systemd-resolved (in this case, Ubuntu has it covered with systemd-resolved). You cannot configure scoped nameservers using resolv.conf, you must use dnsmasq or systemd-resolved specific configuration. Linux is not special in how it handles this; similarly, in MacOS you have to use mDNSResponder and /etc/resolver configuration and in Windows, you have to use NRPT.

So your problem was, that you configured four nameservers, three of them providing different results that the fourth one and then wondered, why you never get an answer by the fourth one. The reason for that is in paragraphs above. In you case with Windows, Windows just went from the last one, instead of first one, so it never manifested.

The issue has two possible solutions:

  1. Configure just a single DNS server in your DHCP, the one that knows about the zone you want to ask about, and forwards/caches queries for other zones (i.e. the one running on your Turris);
  2. Configure scoped DNS on your machine. You can have the resolver ask for your zone’s hostnames your Turris DNS and all the other queries can go to other, public DNS servers. Since this has to be configured manually on the client and not via DHCP (at least not with a single connection, it is possible with multiple conections), most people won’t bother and go with option 1.
1 Like

When systemd-resolved provided the following message, I believe it:

//Too many DNS servers configured, the following entries may be ignored.
192.168.1.1

I may be off base here, but that says to me my flavor of Linux had too many DNS entries and it ignored the last one.

You still do not seem to understand what I wrote above. Configuring nameservers that return different answers is the error here.

1 Like

I freely admit I have no idea what you are talking about. I only care that my local hosts were unable to resolve.