You are not logged in.
To use systemd-resolved the wiki says:
For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link:
# ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf
Once I've made that symbolic link should I be editing '/etc/resolv.conf' and setting my name server manually? Right now /usr/lib/systemd/resolv.conf says:
nameserver 127.0.0.53
But this doesn't work, isn't systemd-resolved supposed to be managing this?
If I don't seem like this and just set resolv.conf to my router manually, everything works fine, but the wiki says to use networkd with containers and have them set up DHCP automatically, you should be using resolvd.
Offline
I am not an expert on this, to say the least. but the wiki says
For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link:
whetever that is supposed to mean. For my generic home network where the router acts as a DNS server, I did not make that change to the link:
ewaller@turing ~ 1001 %ll /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Oct 23 2015 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
ewaller@turing ~ 1002 %cat /etc/resolv.conf
# This file is managed by systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known DNS servers.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 192.168.1.1
nameserver 2602:100:8ae5:dac6::1
ewaller@turing ~ 1003 %cat /usr/lib/systemd/resolv.conf
# This is a static resolv.conf file for connecting local clients to
# systemd-resolved via its DNS stub listener on 127.0.0.53.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
ewaller@turing ~ 1004 %systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2016-09-05 14:12:19 PDT; 18h ago
Docs: man:systemd-resolved.service(8)
http://www.freedesktop.org/wiki/Software/systemd/resolved
http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 525 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4915)
CGroup: /system.slice/systemd-resolved.service
└─525 /usr/lib/systemd/systemd-resolved
Sep 05 14:12:19 turing systemd[1]: Starting Network Name Resolution...
Sep 05 14:12:19 turing systemd-resolved[525]: Positive Trust Anchors:
Sep 05 14:12:19 turing systemd-resolved[525]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Sep 05 14:12:19 turing systemd-resolved[525]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.17
Sep 05 14:12:19 turing systemd-resolved[525]: Using system hostname 'turing'.
Sep 05 14:12:19 turing systemd[1]: Started Network Name Resolution.
ewaller@turing ~ 1005 %
One can see that I am using the router for both IPv4 and IPv6. Try it configured my way and see what happens.
In parting, the man page says
Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved. Note however that it is strongly recommended that local programs use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS protocol.
. Mayhaps it is about this which the obscure note about compatibility is hinting
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
I am not an expert on this, to say the least. but the wiki says
For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link:
whetever that is supposed to mean. For my generic home network where the router acts as a DNS server, I did not make that change to the link
Same here, I did not have to change it.Router provides DNS addresses. Users should not have to do this actually, this breaks packages.
Offline
I am not an expert on this, to say the least. but the wiki says
For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link:
whetever that is supposed to mean. For my generic home network where the router acts as a DNS server, I did not make that change to the link:
ewaller@turing ~ 1001 %ll /etc/resolv.conf lrwxrwxrwx 1 root root 32 Oct 23 2015 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf ewaller@turing ~ 1002 %cat /etc/resolv.conf # This file is managed by systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients directly to # all known DNS servers. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 192.168.1.1 nameserver 2602:100:8ae5:dac6::1 ewaller@turing ~ 1003 %cat /usr/lib/systemd/resolv.conf # This is a static resolv.conf file for connecting local clients to # systemd-resolved via its DNS stub listener on 127.0.0.53. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 ewaller@turing ~ 1004 %systemctl status systemd-resolved.service ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-09-05 14:12:19 PDT; 18h ago Docs: man:systemd-resolved.service(8) http://www.freedesktop.org/wiki/Software/systemd/resolved http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 525 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 4915) CGroup: /system.slice/systemd-resolved.service └─525 /usr/lib/systemd/systemd-resolved Sep 05 14:12:19 turing systemd[1]: Starting Network Name Resolution... Sep 05 14:12:19 turing systemd-resolved[525]: Positive Trust Anchors: Sep 05 14:12:19 turing systemd-resolved[525]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Sep 05 14:12:19 turing systemd-resolved[525]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.17 Sep 05 14:12:19 turing systemd-resolved[525]: Using system hostname 'turing'. Sep 05 14:12:19 turing systemd[1]: Started Network Name Resolution. ewaller@turing ~ 1005 %
One can see that I am using the router for both IPv4 and IPv6. Try it configured my way and see what happens.
In parting, the man page says
Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved. Note however that it is strongly recommended that local programs use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS protocol.
. Mayhaps it is about this which the obscure note about compatibility is hinting
So you symlinked /etc/resolv.conf -> /run/systemd/resolve/resolv.conf?
Is that what I should be doing? If my DNS is all working without resolvd, do I even need to use it? Is the whole point of using it so that it manages DHCP and DNS for containers?
Offline
Don't know about containers. I believe that I created that link -- but I don't recall. It works for me. If it works for you, terrific.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Don't know about containers. I believe that I created that link -- but I don't recall. It works for me. If it works for you, terrific.
And what exactly is the reason for symlinking there?
Offline
The behaviour of systemd-resolved appears to have changed in version 231 of systemd.
There are a few caveats attached to the recommendation that is duplicated on the ArchWiki page:
https://github.com/systemd/systemd/blob … /NEWS#L137
Previous to that version, the man page recommend symlinking resolv.conf to /run/systemd/resolve/resolv.conf
This is the configuration that I use and it works well with the nameservers being set according to the systemd-networkd configuration files.
If I symlink resolv.conf to /usr/lib/systemd/resolv.conf my nameserver resolution also fails.
This suggests that the so-called "stub" DNS resolver supplied by systemd at 127.0.0.53 doesn't work properly, at least with Firefox.
From `man systemd-resolved`:
systemd-resolved maintains the /run/systemd/resolve/resolv.conf file for compatibility with traditional Linux programs. This file may be symlinked from /etc/resolv.conf and is always kept up-to-date, containing information about all known DNS servers.
I think perhaps the ArchWiki page should be changed but there has been some discussion about this on the Talk page.
Jin, Jîyan, Azadî
Offline
The behaviour of systemd-resolved appears to have changed in version 231 of systemd.
There are a few caveats attached to the recommendation that is duplicated on the ArchWiki page:
https://github.com/systemd/systemd/blob … /NEWS#L137Previous to that version, the man page recommend symlinking resolv.conf to /run/systemd/resolve/resolv.conf
This is the configuration that I use and it works well with the nameservers being set according to the systemd-networkd configuration files.
If I symlink resolv.conf to /usr/lib/systemd/resolv.conf my nameserver resolution also fails.
This suggests that the so-called "stub" DNS resolver supplied by systemd at 127.0.0.53 doesn't work properly, at least with Firefox.
From `man systemd-resolved`:
systemd-resolved maintains the /run/systemd/resolve/resolv.conf file for compatibility with traditional Linux programs. This file may be symlinked from /etc/resolv.conf and is always kept up-to-date, containing information about all known DNS servers.
I think perhaps the ArchWiki page should be changed but there has been some discussion about this on the Talk page.
So you deleted /etc/resolv.conf and linked /run/systemd/resolve/resolv.conf to /etc/resolv.conf?
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Offline
Yes.
Last edited by Head_on_a_Stick (2016-09-07 19:58:19)
Jin, Jîyan, Azadî
Offline