[Bug 1850762] Re: stub-resolver no longer optional, systemd dns broken
[Expired for systemd (Ubuntu) because there has been no activity for 60 days.] ** Changed in: systemd (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850762 Title: stub-resolver no longer optional, systemd dns broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1850762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850762] Re: stub-resolver no longer optional, systemd dns broken
Dimitri, indeed, my bad. In other news: it seems that this issue has been known for a while and somebody has been (trying to) solv(e|ing) it - I guess the solution will come to Ubuntu at some stage... https://github.com/systemd/systemd/pull/12004 Thanks for the feedback, looking forward to a working version in the future (not looking forward to increasingly complex interdependencies, but hey, who am I to complain, I could always start my own distribution without systemd, I know...) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850762 Title: stub-resolver no longer optional, systemd dns broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1850762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1850762] Re: stub-resolver no longer optional, systemd dns broken
On Thu, 31 Oct 2019 at 12:40, ts <1850...@bugs.launchpad.net> wrote: > > This was a problem before, I fixed it unlinking /run/systemd/stub- > resolv.conf and linking /run/systemd/resolv.conf to /etc/ > Neither of the paths mentioned are correct... did you mean one of: /run/systemd/resolve/stub-resolv.conf /run/systemd/resolve/resolv.conf Both files should still be available, and usable as providers of /etc/resolv.conf -- Regards, Dimitri. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850762 Title: stub-resolver no longer optional, systemd dns broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1850762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850762] Re: stub-resolver no longer optional, systemd dns broken
OK, I've just talked to the admins for quite some time and while I'm sure that the previous workaround was fine I'm now not so sure how to deal with the situation (or: why it worked). Here we go: Connecting to the wifi configures two wifi-internal DNS servers and one internal search zone ( say IPv4_1 and IPv4_2 and search cc.dd.edu) correctly. Connecting to the lan configures two LAN-internal DNS servers and one internal search zone correctly (say IPv4_3 and search xx.dd.edu) - but from the LAN the system is not allowed to send UDP DNS requests to IPv4_1 nor IPv4_2 (nor direct UDP DNS requests to anything else than a set of accepted local DNS servers, which is fine, of course). Now, being connected to _both_ wifi and LAN and searching for a name within the former zone (name1.cc.dd.edu) the system seems to attempt to reach IPv4_1 (which would be fine to reach on the wifi but can't be reached from lan). I don't know why circumventing systemd stub resolution solved the issue before, but I guess what I would need is the ubuntu name resolution to respect the configuration of the interface that is actually used to send the DNS queries (hence: ignore the search zone cc.dd.edu, do not attempt to send the request to the respective DNS server (configured for wifi) through the interface which in this case is "wrong" (namely: LAN)). Any static setting doesn't help, stuff works when I'm connected to wifi or LAN, I just can't resolve names from the search zone configured through wifi when also connected to the LAN (and interestingly enough I cannot reach some of the services in the search zone cc.dd.edu from the wifi, for security reasons - so I have to go through the LAN)... Testing the hypothesis and manually disconnecting from the wifi does solve the connection problem (but of course this is no solution to the underlying issue). Brief explanatory output: $ resolvectl status Global LLMNR setting: no MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no DNS Domain: xx.dd.edu cc.dd.edu DNSSEC NTA: 10.in-addr.arpa --8<--- Link 5 (enx00249b4c7732) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: IPv4_3 DNS Servers: IPv4_3 <- not allowed to be reached on UDP/53 through LAN IPv4_4 DNS Domain: ~. xx.dd.edu --8<--- Link 3 (wlp61s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: IPv4_1 DNS Servers: IPv4_1 IPv4_2 DNS Domain: ~. cc.dd.edu --8<--- Link 2 (enp0s31f6) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no (that last nic isn't configured nor connected) $ dig name.cc.dd.edu ; <<>> DiG 9.11.5-P4-5.1ubuntu2-Ubuntu <<>> name.cc.dd.edu ;; global options: +cmd ;; connection timed out; no servers could be reached $ dig @IPv4_3 name.cc.dd.edu ; <<>> DiG 9.11.5-P4-5.1ubuntu2-Ubuntu <<>> @IPv4_3 name.cc.dd.edu ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6951 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 463b1ed1f09e7286207545c95dbad8797c7593d8a2de32d5 (good) ;; QUESTION SECTION: ;name.cc.dd.edu.IN A ;; ANSWER SECTION: name.cc.dd.edu. 51243 IN A SOME_IP ;; Query time: 2 msec ;; SERVER: IPv4_3#53(IPv4_3) ;; WHEN: Thu Oct 31 13:50:01 CET 2019 ;; MSG SIZE rcvd: 88 $ dig @IPv4_1 name.cc.dd.edu ; <<>> DiG 9.11.5-P4-5.1ubuntu2-Ubuntu <<>> @IPv4_1 name.cc.dd.edu ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Thanks -- ts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850762 Title: stub-resolver no longer optional, systemd dns broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1850762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850762] Re: stub-resolver no longer optional, systemd dns broken
Hi Dan, thanks for the feedback. Being at the office (University) my interface is configured correctly, but name resolution fails for specific (local) names. This was a problem before, I fixed it unlinking /run/systemd/stub- resolv.conf and linking /run/systemd/resolv.conf to /etc/ I then upgraded to 19.10 a few days ago, which left me with the same problem as before (which unfortunately does not seem to be fixable using the workaround above, anymore). I'll be happy to provide any dig output, I have to admit that I don't know enough about the resolution internals in Ubuntu to explore this path on my own, though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850762 Title: stub-resolver no longer optional, systemd dns broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1850762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850762] Re: stub-resolver no longer optional, systemd dns broken
> please advise as to how systemd name resolution through its local service can > be > disabled now (as it is broken). I won't tell you it's not possible/supported to disable/bypass resolved (although that's most likely the general response you will get), but I'm happy to look into what's broken in resolved for you. Do you have any more details about what in resolved doesn't work for you? ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850762 Title: stub-resolver no longer optional, systemd dns broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1850762/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
