resolver, stub: add require_domain argument

[hannesm]

if there's a query with only a single label (and of kind A or AAAA), we return a no data reply

[reynir]

What is the motivation for this?

With this the resolver can return a no data reply for a domain that should be nxdomain. I think that's a bit weird.

[reynir]

So ignoring the above comment i think the code changes look fine.

[hannesm]

thanks for your question. the motivation is dnsmasq "domain-needed" configuration option. as you can see (defaulta to false), I'm not sure whether it is really worth to support... I guess from a privacy perspective it may be nice (hosts asking for internal host names) -- but then people should just use a local domain name, which will be directly answered by dnsvizor.

so maybe the alternative is to skip this PR (maybe add the documentation changes), and move on (by ignoring the domain-needed flag)

[reynir]

It seems DNSmasq returns NXDomain in that case. The output from dig is as follows:

$ dig -p 5353 @172.23.0.1 foo

; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> -p 5353 @172.23.0.1 foo
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32939
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;foo.				IN	A

;; Query time: 0 msec
;; SERVER: 172.23.0.1#5353(172.23.0.1) (UDP)
;; WHEN: Fri Nov 28 14:31:24 CET 2025
;; MSG SIZE  rcvd: 32

I'm okay merging this now that I understand the use case.

[reynir]

I tested the changes in robur-coop/dnsvizor#107 (comment) I got slightly different reply, but I'm not sure if the difference matters. If @hannesm agrees I will merge.

[hannesm]

The issue I have with NXDomain is that it should mean "there's nothing below this.". So, if you reply to "type A domain .com" with a NXDomain, the DNS client would think that there's no type NS domain .com, and also nothing below .com -- i.e. no example.com etc.

That's why I'd, if we like this, use NoData instead. Now, this approach proposed here is a partial NoData since we don't even provide a SOA in the authority section.

So, thanks for your question, I'm at the moment at the point where I'd prefer to not merge this, and just not support the domain-needed. I'll pick the documentation changes and push them directly.

[hannesm]

(rebased without the documentation changes on top of main)