[Bug 1950520] [NEW] systemd-resolved delivers SOA information when it should not

[Sergio Callegari]

Public bug reported:

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 <ip address of A>

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.

** Affects: systemd (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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 <ip address of A>

  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