5

What is the effect of the nameservers/addresses field in the yaml configuration file?

Any application I've tried uses the /etc/resolv.conf nameservers. This happens even with resolvconf stopped.

This is using systemd as resolver. No errors on generate or apply.

RESOLUTION

Thanks to all who responded. The netplan config yaml configures the nameservers after I do this:

  1. Purge resolvconf;
  2. Put my LAN DNS as forwarder in /etc/bind/named.conf.options;

  3. Replace the /etc/resolv.conf link with a static file as

    search nameserver 127.0.0.53

And that works. I find I have to include the search in the resolv.conf even though I have a search field in my netplan config yaml. Puzzle for another day.

Stephen Boston
  • 3,944
  • What's not clear to me from your question is whether you are experiencing a problem with name lookups or if you are asking only to understand the system better. – slangasek May 11 '18 at 23:54
  • @slangesk Understand the system and hoping to configure it correctly. DNS is working. I have a LAN DNS that forwards to google servers and all is okay but I suspect something's amiss because the nameservers in netplan config seems to be ignored. – Stephen Boston May 12 '18 at 00:22
  • What makes you think the name servers are being ignored? They should show up in the output of 'systemd-resolve --status'. – slangasek May 13 '18 at 02:13
  • @slangasek dig did not use the netplan configured NS. think it was because of running resolvconf? This process wrote to the /etc/resolv.conf , taking its content from the template files in resolvconf config directory. From what Chilli says I think I could have been confused at first by some cached values. This all comes about because I recently set up a LAN DNS and am wandering in new territory for me. I don't believe my anecdotes are a sound basis for meaningful discovery at this point. I need to muddle about some more. – Stephen Boston May 13 '18 at 02:54
  • "dig did not use" - I'm unclear what you mean here. In the standard configuration, systemd-resolved will be running, and /etc/resolv.conf will point to a local resolver at 127.0.0.53, so running 'dig' without specifying a nameserver will use this local resolver. In turn, the local resolver should be configured to look to the netplan-configured nameservers as its upstream resolvers. Maybe this answers your question? Note that resolvconf may be present but the design here is the same with or without resolvconf (which is no longer installed by default in 18.04 new installs). – slangasek May 14 '18 at 16:55
  • So there it is. I see. I think! It all depends upon the configuration of the systemd-resolved. However this portion of the man page for systemd-resolved leaves me in utter chaos. Perhaps you can provide some order. ''''Three modes of handling /etc/resolv.conf (see resolv.conf(5)) are supported:'''' These three modes suggest a flexibility that can be provided only through a horrendous complexity. Awful lot to sort through. Any tips on that sorting? – Stephen Boston May 14 '18 at 21:49
  • Is the root cause of the complexity coming from the variety of name resolution interfaces expected by the various applications that expect the service? It does seem rather messy. – Stephen Boston May 14 '18 at 22:17
  • Is the root cause of the complexity coming from the variety of name resolution interfaces expected by the various applications that expect the service? It does seem rather messy. – Stephen Boston May 14 '18 at 22:17
  • Ah! So I find it wonderful that one of the three modes of resolv.conf supported is a static file! I like that very much. – Stephen Boston May 18 '18 at 00:26

2 Answers2

5

NOTE: This may duplicate information from chili555, however in discussion with them, the aforementioned individual suggested posting an 'authoritative' answer as I have worked with this exact issue/question before.

The behavior witnessed in your environment is the systemd-resolved equivalent of what dnsmasq on pre-18.04 was doing. The netplan updates affect the nameservers that systemd-resolved use for its lookups. This is detailed in the last section of the answer.

But first, for the curious, some history about this behavior, and how it differs from the 'older' Ubuntu versions which use Network Manager and dnsmasq. (Feel free to skip past the next section of this answer if you only want the 18.04-related stuff)

Before 18.04: dnsmasq as a local caching resolver

Prior to 18.04, whenever you used the GUI Ubuntu, it would install dnsmasq alongside Network Manager. The Network Manager integration with dnsmasq would update the dnsmasq list of 'next hop' servers (upstream DNS servers) for where to send a query.

Therefore, a DNS query for google.com would pass from whatever application is requesting the resolution, into dnsmasq, and if dnsmasq doesn't know the IP address or has had a cached entry expire, would then pass the DNS request to whatever upstream DNS server (for this example, 8.8.8.8 or 8.8.4.4). You would then have to check Network Manager or the dnsmasq config to see where the 'upstream' DNS servers were.

This is typical behavior in a graphical Ubuntu installed from the Desktop ISOs.

The default install from the Server ISOs, conversely, followed the traditional "update /etc/resolv.conf" method via the resolvconf package and utilized /etc/resolv.conf directly instead of communicating via dnsmasq.

18.04: netplan, and systemd-resolved

With 18.04, the default DNS system is systemd-resolved. This operates like the dnsmasq of old does, except it does this for both Desktop and Server ISO installations currently. It also can integrate with Network Manager (used in the GUI environments for managing wifi and such), and with Netplan (which better handles ethernets)

systemd-resolved is handed from netplan (servers or custom desktops) or Network Manager (default Desktop images) the list of DNS servers to send queries to (whether statically configured or configured via DHCP). Therefore, using the same example from above, a DNS query to google.com would pass through systemd-resolved's stub resolver which would either return the cached lookup value or pass it on to upstream DNS servers.

This emulates the default behavior of dnsmasq, but also adds some additional lookup handling for how 'localhost', and other local-related addresses can be queried.

With NetPlan, or Network Manager, you can get the list of upstream DNS servers through systemd-resolved with the following command:

systemd-resolve --status

which will give you a bunch of output. The relevant section would look like this (taken from chili555's answer for expediency):

DNS Servers: 8.8.8.8
             8.8.4.4
             2600:1700:5aa0:830::1
Thomas Ward
  • 74,764
  • I'm using 18.04. I'm missing something. From your post I understand that with netplan, name resolution is performed by systemd-resolved using the configuration in the netplan config (the yaml file used by netplan generate and apply). Using this understanding I disabled resolvconf and rebooted. Thinking I should get resolvconf out of the way. (I had installed resolvconf because it did not come standard in 18.04.) systemd-resolve --status displays some in-addr-arpa IPs but does not have a DNS Server or Domain field. So... Do we need resolvconf? Or something? – Stephen Boston May 12 '18 at 00:36
  • @StephenBoston Without seeing the specific configuration in your system and the specific output of your systemd-resolve --status which you are referring to, I can't really give you an answer. Consider this example output though from one of my LXD containers - DNS nameservers are link-based - line 36 of that output is where the DNS nameservers start... – Thomas Ward May 12 '18 at 05:06
  • There is another issue that I will mention here but which I think should probably be another question. You might have some insight though. This is that the search field in the netplan yaml doesn't have effect. I have to enter that into the resolv.conf. – Stephen Boston May 12 '18 at 13:43
  • My netplan configured nameservers appear on the systemd-resolve output with resolvconf disabled. I have access through those nameservers. I find however that I have to create /etc/resolv.conf and put nameserver 127.0.0.53. I suspect that is wrong. The file should be generated, true? – Stephen Boston May 12 '18 at 14:01
2

Disclaimer: This is a well-educated guess and not a canonical, documented answer.

Any application I've tried uses the /etc/resolv.conf nameservers.

On my 18.04 system, the un-commented, that is, actually operational, section of /etc/resolv.conf says:

nameserver 127.0.0.53

That is, I believe, a symptom of the use of dnsmasq, the system that caches DNS information. That means, I believe, look in the local cache first, before asking external nameservers.

But the local cache won’t contain any nameserver information about a website that has never been visited before. In that case, the system uses declared external DNS nameservers. These may be declared in /etc/network/interfaces in older systems; in /etc/netplan/*.yaml in newer systems or, in almost all desktop installations, in Network Manager.

In fact, /etc/resolv.conf tells us how the external nameservers can be found.

Run "systemd-resolve --status" to see details about the uplink DNS servers currently in use.

On my system, the report says, in part:

DNS Servers: 8.8.8.8
             8.8.4.4
             2600:1700:5aa0:830::1

In short, I believe that DNS nameservers are declared in netplan to tell the system where to look if the DNS information is not found in the local cache.

chili555
  • 60,188
  • 1
    systemd-resolved, not dnsmasq. systemd-resolved runs a 'stub' DNS resolver that does much of what dnsmasq did in pre-18.04 for DNS resolutions as the 'interim' server that then passes off lookups to the upstream DNS servers defined in network configs or from DHCP. Other than that, the rest of this information is pretty more accurate/spot-on. (I've got a few 18.04 servers and have dug into this fairly heavily) – Thomas Ward May 11 '18 at 14:40
  • "Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. " quote from man systemd-resolved.service. So /etc/resolv.conf is system generated. TIPP: If you want to do it the brutal way and override and fixate /etc/resolv.conf do apply "chattr +i /etc/resolv.conf" as true root. Thanks to Arch documentation bringing this up. Not recommended but relieving. – opinion_no9 Jan 17 '19 at 09:52