Negative cache results from dnsmasq do not include SOA as required in RFC2308

Hello Eric,

Thank you for providing this bug report. When testing in Jammy I see the same behavior. We will look into the issue this week.

Acknowledge that RFC non-compliance. Fixing this is actually a fairly
big ask, since the problem is not that dnsmasq omits the SOA when
answering from cache, but that dnsmasq doesn't cache SOA records. The
design philosophy was (and is) to cache only a few RR types to make the
code and data structures simple and small (remember that dnsmasq's niche
is "lightweight", for low capability hardware). There's been a implied
assumption that clients using dnsmasq would typically be stub-resolvers,
and not full-service DNS servers.

That said, the set of cached RR types has increased over the years,
notably with the introduction of DNSSEC and the RR types needed to
suuport that. Adding caching of SOA records is possible, but I'm not
sure it's worth the effort.

A reasonable workaround might be to disable negative caching in dnsmasq
and rely on systemd-resolved to do that for itself.

Simon.

On 19/05/2022 20:51, Eric Blevins wrote:
> Public bug reported:
>
> RFC2308 states:
> 6 - Negative answers from the cache
>
> When a server, in answering a query, encounters a cached negative
> response it MUST add the cached SOA record to the authority section
> of the response with the TTL decremented by the amount of time it was
> stored in the cache. This allows the NXDOMAIN / NODATA response to
> time out correctly.
>
> The effect is that the negative cache results returned by dnsmasq cannot
> be cached by other resolvers such as systemd-resolved.
>
> A good example of why this is a problem:
> Two clients with systemd-resolved send DNS queries to dnsmasq for the same record
> The first one makes a query and gets NXDOMAIN with SOA.
> This results in systemd-resolved caching the negative result.
>
> The second client makes a query and gets NODATA without the SOA.
> This results in systemd-resolved not caching the negative result.
>
> Consider a domain name that only has an A record published.
> When connecting to that domain a lookup happens for the AAAA and A record.
> One can end up in a situation where systemd-resolved has the A record cached locally, but it still goes out to the network to perform the AAAA lookup only to get the same negative cache result that is missing the SOA
>
> I see this behavior in 18.04 and 22.04
>
>
> First query to dnsmasq can be cached:
> dig @10.0.1.21 a.google.com
>
> ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3107
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;a.google.com. IN A
>
> ;; AUTHORITY SECTION:
> google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 449437361 900 900 1800 60
>
> ;; Query time: 15 msec
> ;; SERVER: 10.0.1.21#53(10.0.1.21)
> ;; WHEN: Thu May 19 15:00:12 EDT 2022
> ;; MSG SIZE rcvd: 91
>
>
> Cached response from dnsmasq cannot be cached:
> dig @10.0.1.21 a.google.com
>
> ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com
> ; (1 server found)
> ;; global op...

Status changed to 'Confirmed' because the bug affects multiple users.

Thanks Simon to pick this up with your SME,
have you opened a tracker bug for this in Debian or Upstream so that we can track it if it is implemented some day.