1

Just trying the newest Ubuntu 19.04 and it has some differences with resolv.conf when running my own bind locally. Previously in 18.04 resolv.conf looks like this

nameserver 127.0.0.1
nameserver 127.0.0.53

while in 19.04 it has changed to this

nameserver 127.0.0.53
options edns0

If I use dig or nslookup to check for a DNS lookup it does not use the local bind configuration and gets a not found.

If I put

dig www.example.com @127.0.0.1

vs the default dig www.example.com

dig www.example.com @127.0.0.53 

it is working and gets a proper response to the lookup.

I tried adding a netplan yaml file /etc/netplan/00-private-nameservers.yaml

network:
    version: 2
    ethernets:
        enp0s3:
            nameservers:
                addresses:
                - 127.0.0.1
                - 1.1.1.1
                - 1.0.0.1
                - 8.8.8.8
                - 4.4.4.4
                #search: [ nyc3.example.com ]

but it does not change resolv.conf to do the local lookup as it should I think.

This version is new to me and I am unsure if this is a bug or what? Again I am running bind locally and expect it to resolve domains lookups locally.

[I have added this in regards to the comment below.]

root@server:/tmp# systemd-resolve --status
Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (enp0s3)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 127.0.0.1
                      1.1.1.1
                      1.0.0.1
                      8.8.8.8
                      4.4.4.4
                      192.168.2.1
                      2001:569:7552:3900:4a5f:38ee:fe29:130

Without the private nameservers yaml it shows

Link 2 (enp0s3)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.2.1
                      2001:569:7552:3900:4a5f:38ee:fe29:130
  • Edit your question and show me ls -al /etc/resolv.conf and cat /etc/resolv.conf. Do you plan to use VPN? Your .yaml file is wrong if you plan on using NetworkManager, like you should on a non-server machine. Report back. – heynnema Apr 30 at 23:12
  • What does 'systemd-resolve --status' show, with the netplan config in question? – slangasek May 1 at 19:23
  • I appended the results of the status to the message above. – Master James May 3 at 7:03
  • I had responded to various ideas showing results and some might have helped people understand the issues etc. but they got deleted because the system is dysfunctional besides that I cross posting this bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320 – Master James May 8 at 8:48
0

Yeah, it also drives me crazy. And frankly, I didn't have enough patience to thoroughly analyze it so I won't answer your question in the direct way.

But basicly there is this yet-anoher-crazy-systemd-unit called systemd-resolved, that binds on 127.0.0.53:53 both tcp and udp. That's why you see nameserver 127.0.0.53 in your /etc/resolv.conf.

More than that /etc/resolv.conf is left for compatibility by systemd-resolved as a symlink to /run/systemd/resolve/stub-resolv.conf.

And this is the part I don't understand fully, but even if I set my DNS servers in /etc/systemd/resolved.conf, which seems to be systemd-resolved configfile, some programs simply don't use it. Why? No clue so far.

How I live with that? I also set my DNS servers in NetworkManager. Then with my DNS servers set inside /etc/systemd/resolved.conf and in NetworkManager I have it really set.

What about netplan.io? I don't get it yet. But when it comes to DNS servers it seems to doing nothing for me at the moment.

  • How does this answer the question? It's more of a rambling rant. Sorry. – heynnema Apr 30 at 23:13
  • I appreciated his support that I am not allow on this issue of confusion. It does give an answer about using NetworkManager (not that I tried that). – Master James May 3 at 5:56
0

Okay well thanks. I was resisting the obvious because it was not included. I am pretty sure it's a bug realistically, but OS devs expectations and imagined usage must be different or changing. I think they figure if you run a DNS it looks up nothing of itself unrealistically in my opinion. It seemed bizarre to me they removed the way it worked before and didn't cover their bases properly. (Again I'll try bug reporting as it seems maybe an oversight or difference of opinions trying to be lean etc. I had hoped (and there is still a chance) that someone has found a better way (and will comment here) then restoring previous functionality manually so it actually works. Anyway until they com to there senses again in Ubuntu 20.04 or whatever do this.

apt install resolvconf

then edit or append to the resolvconf service daemon conf file to point to local ip 127.0.0.1

pico /etc/resolvconf/resolv.conf.d/head

like so it will look

nameserver 127.0.0.1

then restart that part

service resolvconf restart

and voila the dig www.example.com will return and the /etc/resolve.conf will be restored to it's appropriate state of

nameserver 127.0.0.1
nameserver 127.0.0.53
options edns0

Well the options edns0 is newly added to Ubuntu 19.04 where as that was not there in 18.04 and as you know this is since we are adding bind9 package so I guess you have to add/restore this resolveconf package too if you what the local machine to be able to resolve the DNS records it is providing. I suppose it they are properly roped into the global system you also might not need it so maybe you/we need faith more the resolveconf but one has to test it's working locally I would think and ya I want it working locally without telling each command how to find the local server first, etc.

  • actually looking at my old (didn't really work with 19.04) build script I had manually added the nameserver 127.0.0.1 to the resolv.conf.d/head before as well. It seems just adding the missing previous resolvconf package was the missing link. If anybody knows what the devs thought was the possible reason for omitting resolvconf this time please let the world know! – Master James May 1 at 7:22
  • Also note the man resolvconf says the -u flag is not supported and will fail but it still works for now I guess it's short for 'update' so it's similar to 'service resolvconf restart'. Also note resolvctl is the same man page document and that doesn't allow -u so it's also buggy documentation. – Master James May 1 at 7:28
  • You should certainly not have to install resolvconf to resolve this issue on 19.04. The resolvconf package is deprecated with respect to the Ubuntu stack. It's possible there is an oversight wrt integration with local DNS servers (bind9, etc), but simply declaring 127.0.0.1 as your preferred DNS server in netplan config should be sufficient. – slangasek May 1 at 19:29
  • Maybe you could demonstrate the netplan is new to me. I tried all sorts of things and nothing worked so I guess it's a bug or just a really weird computational problem to solve. You did see my initial script right? I put 127.0.0.1 at the top but it doesn't effect the system and dig lookups. – Master James May 3 at 6:51
  • In your question, you show a netplan config with 5 dns servers: 127.0.0.1, and 4 public DNS servers. You certainly want to do that, as this tells resolved to treat these 5 servers as equivalent. Unlike /etc/resolv.conf, where libc will try the servers in order, resolved will deliberately round-robin between the servers you have listed. This may be the source of your problem - not that 127.0.0.1 is unused, but that it's used only intermittently. – slangasek May 5 at 5:06
0

You can edit /etc/systemd/resolved.conf

and set the DNS to the locally running bind aka DNS Server via

[Resolve]
DNS=127.0.0.1

restart with

systemctl restart systemd-resolved.service

and when you dig (or lookup as explained above) you DO get (just) a www.example.com A record with a locally served DNS' zone files appropriate IP result but it doesn't display as much information as what you get if you append @127.0.0.1 or the resolv.conf has 127.0.0.1 ahead of 127.0.0.53

This is a partial answer sourced from the help in comments and should be retained and not deleted like all the other replies I added that were delete on the grounds they where not declared like this one as a valid/useful Answer or partial answers, but they probably where useful for certain situation. In my case I'm doing DNSSEC etc. and need to see more substantial results like those from @127.0.0.1 or at least that was why I didn't put more clarity on it being correct in some cases. I was of course expecting the full response you get when the resolv.conf points directly to the DNS running on the system at 127.0.0.1 and not chained via 127.0.0.53 to the DHCP provided router gateway (typically).

[Also please note the meager comments are insufficient to show work with code blocks and results, hence the importance of not deleting the communities discussion on resolving these problems together. Please consider multiple user flags for deletion status.]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.