On 11 October 2017 at 15:25, Matthias Fratz <1714...@bugs.launchpad.net> wrote: > Tried that, and it started using the DHCP-provided search path (yay!). > > Setting the search path in NetworkManager (which is responsible for the > interface in question) works, ie. honors the search path and doesn't > break resolving for those domains, with both single and multiple search > paths: > > [ipv4] > dns-search=disy.inf.uni-konstanz.de;inf.uni-konstanz.de;uni-konstanz.de > method=auto > > [ipv6] > addr-gen-mode=stable-privacy > dns-search=disy.inf.uni-konstanz.de;inf.uni-konstanz.de;uni-konstanz.de > method=auto > > Having to do this for each connection and for both IPv4 and IPv6 sucks, > but it's better than not having a search path. > > > Trying to set the search path to Domains=ubuntu.com globally in resolved.conf > still breaks ubuntu.com, of course. Out of curiosity, I then put this in > resolved.conf: > > Domains=uni-konstanz.de inf.uni-konstanz.de disy.inf.uni-konstanz.de > ubuntu.com > > This works for the domains listed in the interface, honoring the search > path and correctly resolving both short (git) and long (git.uni- > konstanz.de) domains. But it breaks resolution completely for ubuntu.com > and subdomains. > > So: Does systemd-resolved need to have a network interface "associated" > with each search domain?? This is very much not how DNS works but it's a > boundary case that might be easy to get wrong. > > (This is all on the 17.10 VM, and with resolved.conf empty apart from > [Resolve] and the Domains= line, where mentioned.) >
If there is per-interface configuration available resolved will use that, and it is preferred mode of operation. Anything else is ambiguous. This is to support split-dns situations such that company.internal.vpn on a a VPN interface can have Domains specified and thus not leak VPN-intended queries to the general intenet / gateway nameserver. I'm still struggling to comprehend the obsession of adding "ubuntu.com" in your examples. Please stop doing that. This is not a domain you control, and not something one should be trying to override, as that carries risk of failing to resolve or miss-resolve domain names used for updates. If DHCP is not providing you the correct domains all clients should be using on a given connection -> please fix your DHCP server config. If that is not possilbe -> you can fix that up locally on per-connection basis. Lease ubuntu.com alone. Can you describe in general terms, what network configuration exists, and how is it broken by default when artful is used as a DHCP client? It is intentional that DHCP server is not providing the correct search domains? Why are you overriding them on each client? Why are you trying to override resolution of ubuntu.com domains? It is intentional that one has to maintain correct per-link configuration. This used to happen with resolvconf, as each dhcp v4 and v6 configs were kept separately internally, and were correctly removed each time a lease/link was lost. Now in addition to keeping track of which nameserver belogs to which link, we also only send queries to the right nameservers and matching domains by default. This improves security and privacy. https://www.freedesktop.org/software/systemd/man/systemd.network.html#UseDomains= for more information on a tri-state option for this, in Ubuntu this option is set to 'true' by default. -- Regards, Dimitri. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1714803 Title: Search list in resolv.conf breaks resolving for that domain Status in systemd package in Ubuntu: Incomplete Bug description: Ubuntu 17.04 systemd 232-21ubuntu5 Adding a domain to the search list in /etc/resolv.conf breaks resolving for that domain. Not only does the search list not get used as expected, but host names in the domain cannot be resolved by systemd-resolved at all. I just ran into this after upgrading from ubuntu 16.04 to 17.04 which enabled systemd-resolved. I have for a long time used resolveconf to add a 'search my-domain'-line to my /etc/resolv.conf. Example of expected behaviour. With Googles DNS server (8.8.8.8) and ubuntu.com in the search list in /etc/resolv.conf. Both dig and systemd-resolve can resolve www.ubuntu.com and www: $ cat /etc/resolv.conf nameserver 8.8.8.8 search ubuntu.com $ dig +nostat +nocmd www.ubuntu.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55037 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.ubuntu.com. IN A ;; ANSWER SECTION: www.ubuntu.com. 501 IN A 91.189.89.115 $ dig +search +nostat +nocmd www ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25772 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.ubuntu.com. IN A ;; ANSWER SECTION: www.ubuntu.com. 382 IN A 91.189.89.103 $ systemd-resolve www.ubuntu.com www.ubuntu.com: 91.189.89.115 -- Information acquired via protocol DNS in 2.7ms. -- Data is authenticated: no $ systemd-resolve www www: 91.189.90.59 (www.ubuntu.com) -- Information acquired via protocol DNS in 3.8ms. -- Data is authenticated: no Ubuntu 17.04 default config, with the systemd-resolved name server in /etc/resolv.conf and no search list. www.ubuntu.com can still be resolved correctly: $ cat /etc/resolv.conf nameserver 127.0.0.53 $ dig +nostat +nocmd www.ubuntu.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64646 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;www.ubuntu.com. IN A ;; ANSWER SECTION: www.ubuntu.com. 482 IN A 91.189.89.110 $ systemd-resolve www.ubuntu.com www.ubuntu.com: 91.189.90.58 -- Information acquired via protocol DNS in 18.2ms. -- Data is authenticated: no Broken behaviour, using the systemd-resolved name server and specify ubuntu.com in search list. Resolving fails for www.ubuntu.com and www, both using dig (DNS) and using sytemd-resolve: $ cat /etc/resolv.conf nameserver 127.0.0.53 search ubuntu.com $ dig +nostat +nocmd www.ubuntu.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33334 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;www.ubuntu.com. IN A $ dig +search +nostat +nocmd www ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50588 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;www.ubuntu.com. IN A $ systemd-resolve www.ubuntu.com www.ubuntu.com: resolve call failed: No appropriate name servers or networks for name found $ systemd-resolve www www: resolve call failed: All attempts to contact name servers or networks failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1714803/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
