[Touch-packages] [Bug 1950520] Re: systemd-resolved delivers SOA information when it should not
Thanks, I'll try that and try to report. I have already asked on various forums if there is any way to replace /only/ the stub resolver (systemd- resolved) with a more recent version without replacing all the code related to init and the system initialization and been told there is no safe way, hence I understand the fact that ubuntu has a single package for the whole of systemd. Unfortunately, that means that even if https://launchpad.net/~ubuntu- support-team/+archive/ubuntu/systemd fixes the issue in a vm it will probably be impossible to practically deploy daily updated init, etc on a machine that must be reliably on daily use. On the other side, I have found that it is relatively easy to workaround the issue in systemd-resolved by making the local DNS server slightly deviate from standards so that it responds SERVERFAIL instead of NXDOMAIN for queries in .local. As a final note, as mentioned above, I have moved this discussion by closing this issue and opening a new one, where the problem in systemd- resolved is properly identified. Please see bug 1950850. -- 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/1950520 Title: systemd-resolved delivers SOA information when it should not Status in systemd package in Ubuntu: Invalid Bug description: I have a setup where a host (say A) in the network runs knot-resolver as a caching nameserver. Among the other hosts, some of them run ubuntu 20.04 and use systemd- resolved. The dhcp setup make all these host use A as their nameserver. The issue with systemd- The issue is that if I do: host -t SOA foo.local the hosts running systemd-resolved answer foo.local has SOA record foo.local. nobody.invalid. 1 3600 1200 604800 10800 making up the SOA record from nowhere (sort of). In fact, if I do the same query pointing directly at A host -t SOA foo.local I correctly get no SOA record. The incorrect response of resolved breaks mDNS resolution. In fact, if nsswitch.conf is set at hosts: files mdns4_minimal [NOTFOUND=return] dns any call requiring name resolution first goes through the hosts files, then mdns is attempted. However, the nss mdnd implementation first checks if the DNS server responds to SOA queries for the top level local name and if this is the case, it gives up. As a consequence, trying to access hosts on the .local domain always fail. The reason why systemd-resolved makes up a SOA record for hosts such as foo.local is that knot resolver replies to queries about it without an answer, but including an authority section ;; AUTHORITY SECTION: foo.local. 10800 IN SOA foo.local. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid.10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml"; and systemd-resolved turns that AUTHORITY section into a SOA record. It is not totally clear to me if the fault is on knot-resolver, systemd-resolved or both, but I tend to think it is the second one. Unfortunately, trying to inquire upstream about systemd-resolved appears to be forbidden for anybody not running the last two releases of systemd. Furthermore, I understand that the nature of systemd makes it extra hard or impossible to test a more recent version of systemd-resolved than the one shipped in ubuntu focal. Interestingly, the issue seems to bite those running omnia turris router too (see https://forum.turris.cz/t/avahi-local-domain-warning- on-ubuntu/13437). Maybe they use knot-resolver as their caching nameserver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950520/+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
[Touch-packages] [Bug 1950520] Re: systemd-resolved delivers SOA information when it should not
> Is there a ppa with a more recent systemd-resolved to try on focal yes, https://launchpad.net/~ubuntu-support-team/+archive/ubuntu/systemd however that includes the entire upstream systemd code, not only systemd-resolved; i'd suggest you test inside a VM and not on your main system. -- 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/1950520 Title: systemd-resolved delivers SOA information when it should not Status in systemd package in Ubuntu: Invalid Bug description: I have a setup where a host (say A) in the network runs knot-resolver as a caching nameserver. Among the other hosts, some of them run ubuntu 20.04 and use systemd- resolved. The dhcp setup make all these host use A as their nameserver. The issue with systemd- The issue is that if I do: host -t SOA foo.local the hosts running systemd-resolved answer foo.local has SOA record foo.local. nobody.invalid. 1 3600 1200 604800 10800 making up the SOA record from nowhere (sort of). In fact, if I do the same query pointing directly at A host -t SOA foo.local I correctly get no SOA record. The incorrect response of resolved breaks mDNS resolution. In fact, if nsswitch.conf is set at hosts: files mdns4_minimal [NOTFOUND=return] dns any call requiring name resolution first goes through the hosts files, then mdns is attempted. However, the nss mdnd implementation first checks if the DNS server responds to SOA queries for the top level local name and if this is the case, it gives up. As a consequence, trying to access hosts on the .local domain always fail. The reason why systemd-resolved makes up a SOA record for hosts such as foo.local is that knot resolver replies to queries about it without an answer, but including an authority section ;; AUTHORITY SECTION: foo.local. 10800 IN SOA foo.local. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid.10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml"; and systemd-resolved turns that AUTHORITY section into a SOA record. It is not totally clear to me if the fault is on knot-resolver, systemd-resolved or both, but I tend to think it is the second one. Unfortunately, trying to inquire upstream about systemd-resolved appears to be forbidden for anybody not running the last two releases of systemd. Furthermore, I understand that the nature of systemd makes it extra hard or impossible to test a more recent version of systemd-resolved than the one shipped in ubuntu focal. Interestingly, the issue seems to bite those running omnia turris router too (see https://forum.turris.cz/t/avahi-local-domain-warning- on-ubuntu/13437). Maybe they use knot-resolver as their caching nameserver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950520/+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
[Touch-packages] [Bug 1950520] Re: systemd-resolved delivers SOA information when it should not
Marked by myself the issue as invalid, since when I reported the issue my understanding of it was to o modest. Will open a new more appropriate issue. ** Changed in: systemd (Ubuntu) Status: New => Invalid -- 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/1950520 Title: systemd-resolved delivers SOA information when it should not Status in systemd package in Ubuntu: Invalid Bug description: I have a setup where a host (say A) in the network runs knot-resolver as a caching nameserver. Among the other hosts, some of them run ubuntu 20.04 and use systemd- resolved. The dhcp setup make all these host use A as their nameserver. The issue with systemd- The issue is that if I do: host -t SOA foo.local the hosts running systemd-resolved answer foo.local has SOA record foo.local. nobody.invalid. 1 3600 1200 604800 10800 making up the SOA record from nowhere (sort of). In fact, if I do the same query pointing directly at A host -t SOA foo.local I correctly get no SOA record. The incorrect response of resolved breaks mDNS resolution. In fact, if nsswitch.conf is set at hosts: files mdns4_minimal [NOTFOUND=return] dns any call requiring name resolution first goes through the hosts files, then mdns is attempted. However, the nss mdnd implementation first checks if the DNS server responds to SOA queries for the top level local name and if this is the case, it gives up. As a consequence, trying to access hosts on the .local domain always fail. The reason why systemd-resolved makes up a SOA record for hosts such as foo.local is that knot resolver replies to queries about it without an answer, but including an authority section ;; AUTHORITY SECTION: foo.local. 10800 IN SOA foo.local. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid.10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml"; and systemd-resolved turns that AUTHORITY section into a SOA record. It is not totally clear to me if the fault is on knot-resolver, systemd-resolved or both, but I tend to think it is the second one. Unfortunately, trying to inquire upstream about systemd-resolved appears to be forbidden for anybody not running the last two releases of systemd. Furthermore, I understand that the nature of systemd makes it extra hard or impossible to test a more recent version of systemd-resolved than the one shipped in ubuntu focal. Interestingly, the issue seems to bite those running omnia turris router too (see https://forum.turris.cz/t/avahi-local-domain-warning- on-ubuntu/13437). Maybe they use knot-resolver as their caching nameserver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950520/+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
[Touch-packages] [Bug 1950520] Re: systemd-resolved delivers SOA information when it should not
Unfortunately, I have no idea on how to bisect this, due to the fact that there is not an independent repo for systemd-resolved and attempting to work on the whole systemd seems to dounting and risky as an experience for me. Is there a ppa with a more recent systemd- resolved to try on focal without the risk of breaking all the system init? Is it possible to compile just the resolve subtree from the systemd sources? -- 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/1950520 Title: systemd-resolved delivers SOA information when it should not Status in systemd package in Ubuntu: New Bug description: I have a setup where a host (say A) in the network runs knot-resolver as a caching nameserver. Among the other hosts, some of them run ubuntu 20.04 and use systemd- resolved. The dhcp setup make all these host use A as their nameserver. The issue with systemd- The issue is that if I do: host -t SOA foo.local the hosts running systemd-resolved answer foo.local has SOA record foo.local. nobody.invalid. 1 3600 1200 604800 10800 making up the SOA record from nowhere (sort of). In fact, if I do the same query pointing directly at A host -t SOA foo.local I correctly get no SOA record. The incorrect response of resolved breaks mDNS resolution. In fact, if nsswitch.conf is set at hosts: files mdns4_minimal [NOTFOUND=return] dns any call requiring name resolution first goes through the hosts files, then mdns is attempted. However, the nss mdnd implementation first checks if the DNS server responds to SOA queries for the top level local name and if this is the case, it gives up. As a consequence, trying to access hosts on the .local domain always fail. The reason why systemd-resolved makes up a SOA record for hosts such as foo.local is that knot resolver replies to queries about it without an answer, but including an authority section ;; AUTHORITY SECTION: foo.local. 10800 IN SOA foo.local. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid.10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml"; and systemd-resolved turns that AUTHORITY section into a SOA record. It is not totally clear to me if the fault is on knot-resolver, systemd-resolved or both, but I tend to think it is the second one. Unfortunately, trying to inquire upstream about systemd-resolved appears to be forbidden for anybody not running the last two releases of systemd. Furthermore, I understand that the nature of systemd makes it extra hard or impossible to test a more recent version of systemd-resolved than the one shipped in ubuntu focal. Interestingly, the issue seems to bite those running omnia turris router too (see https://forum.turris.cz/t/avahi-local-domain-warning- on-ubuntu/13437). Maybe they use knot-resolver as their caching nameserver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950520/+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
[Touch-packages] [Bug 1950520] Re: systemd-resolved delivers SOA information when it should not
Tested on a manjaro system that being rolling uses the latest systemd. There is no issue there. Hence the problem appears to be a systemd-resolved bug specific to the systemd version shipped with ubuntu 20.04. Because the issue breaks local resolution via mDNS in some configurations, I think that the fix that has evidently been made in recent systemd-resolved should be backported. -- 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/1950520 Title: systemd-resolved delivers SOA information when it should not Status in systemd package in Ubuntu: New Bug description: I have a setup where a host (say A) in the network runs knot-resolver as a caching nameserver. Among the other hosts, some of them run ubuntu 20.04 and use systemd- resolved. The dhcp setup make all these host use A as their nameserver. The issue with systemd- The issue is that if I do: host -t SOA foo.local the hosts running systemd-resolved answer foo.local has SOA record foo.local. nobody.invalid. 1 3600 1200 604800 10800 making up the SOA record from nowhere (sort of). In fact, if I do the same query pointing directly at A host -t SOA foo.local I correctly get no SOA record. The incorrect response of resolved breaks mDNS resolution. In fact, if nsswitch.conf is set at hosts: files mdns4_minimal [NOTFOUND=return] dns any call requiring name resolution first goes through the hosts files, then mdns is attempted. However, the nss mdnd implementation first checks if the DNS server responds to SOA queries for the top level local name and if this is the case, it gives up. As a consequence, trying to access hosts on the .local domain always fail. The reason why systemd-resolved makes up a SOA record for hosts such as foo.local is that knot resolver replies to queries about it without an answer, but including an authority section ;; AUTHORITY SECTION: foo.local. 10800 IN SOA foo.local. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid.10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml"; and systemd-resolved turns that AUTHORITY section into a SOA record. It is not totally clear to me if the fault is on knot-resolver, systemd-resolved or both, but I tend to think it is the second one. Unfortunately, trying to inquire upstream about systemd-resolved appears to be forbidden for anybody not running the last two releases of systemd. Furthermore, I understand that the nature of systemd makes it extra hard or impossible to test a more recent version of systemd-resolved than the one shipped in ubuntu focal. Interestingly, the issue seems to bite those running omnia turris router too (see https://forum.turris.cz/t/avahi-local-domain-warning- on-ubuntu/13437). Maybe they use knot-resolver as their caching nameserver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950520/+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
