systemd-resolved: ndots:0 invalid domain returns SERVFAIL instead of NXDOMAIN

[bradh352]

systemd version the issue has been seen with

255.4

Used distribution

Ubuntu 24.04

Linux kernel version used

6.8.0-41-generic

CPU architectures issue was seen on

aarch64

Component

systemd-resolved

Expected behaviour you didn't see

Querying a domain with no dots as a fully qualified domain should return NXDOMAIN if its not found, such as:

dig +ndots=0 www should return NXDOMAIN, but its not, its returning SERVFAIL.

But when querying for a domain with at least 1 dot, that is definitely not valid, we do indeed get NXDOMAIN:

$ dig asdfasdfasa.asdfasfasg

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> asdfasdfasa.asdfasfasg
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56010
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;asdfasdfasa.asdfasfasg.		IN	A

;; AUTHORITY SECTION:
.			86337	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2024082201 1800 900 604800 86400

;; Query time: 34 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Aug 23 00:03:39 UTC 2024
;; MSG SIZE  rcvd: 126

While this may not seem like a significant issue, we are starting to see containers deploy with ndots:0 such as in: c-ares/c-ares#734 (comment)

And the docs for resolv.conf and ndots say:

Sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it.

So if there are search domains set, ndots:0 just make it search the bare first then if that's not found, tries search suffixes.

But in general, this search logic should depend on NXDOMAIN to know to continue on, a SERVFAIL typically means there's something wrong with the upstream DNS server, so like with c-ares, the search stops as happened in c-ares/c-ares#852 (comment)

Unexpected behaviour you saw

$ dig +ndots=0 www

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +ndots www
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30078
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.				IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Aug 23 00:00:11 UTC 2024
;; MSG SIZE  rcvd: 32

Steps to reproduce the problem

attempt a bare query with no dots, when your system config allows ndots:0

Additional program output to the terminal or log subsystem illustrating the issue

No response

[rpigott]

sd-resolved refuses single-label queries by default. You can permit them with ResolveUnicastSingleLabel=yes in resolved.conf, see the justification in resolved.conf(5).

The SERVFAIL rcode is a bug though. Since #31675 (v256) the stub will return a REFUSED rcode in this case.

[rpigott]

But in general, this search logic should depend on NXDOMAIN to know to continue on, a SERVFAIL typically means there's something wrong with the upstream DNS server, so like with c-ares, the search stops as happened in c-ares/c-ares#852 (comment)

FWIW, this indicates a bug in c-ares imo since it differs from the libc resolver. To match the behavior of the libc resolver, c-ares should continue the search after a SERVFAIL, though it may retry the query first (and should advance immediately upon REFUSED).

[poettering]

Closing, since already addressed in #31675, as @rpigott stated.

[bradh352]

@rpigott implementation defined behavior of a single implementation does not mean a bug in another implementation unless you can point to a specification which states that particular implementation is correct. I'd bet a lot of other implementations out there in other libcs also wouldn't continue.

Infact RFC 1034 section 4.3.4 which is updated by RFC2308 alludes to the opposite. Since negative caching is now a required feature for resolvers, the systemd resolved specifically prevents anything downstream from being able to cache the result (c-ares is a caching stub resolver). So even if c-ares does work around this, every single query would need to still hit systemd resolved since the single label name result couldn't be a cached.

I'll try playing with ResolveUnicastSingleLabel=yes to evaluate its behavior. Its possible we'll just need to add some notes to the c-ares documentation about this.

[rpigott]

The RFCs don't have anything to say about the search behavior. I just figure if you're re-implementing the resolv.conf interface you might want to match the behavior more precisely.

If you want to stop after SERVFAIL that's fine, but libc doesn't do that. Consider that you're reporting this bug not because the result doesn't match any RFC, but because it doesn't match your expected result based on the libc resolver.

Either way I am positive that NXDOMAIN is incorrect, as it would assert that we know that this name does not exist, and that no name below it exists. REFUSED is the most sensible RCODE in this case, and the local administrator may choose to refuse a query for any number of reasons. It just happens that single label queries are refused by default in sd-resolved and may be enabled by the administrator where they are otherwise certain they will not be forwarded outside their local network.