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 options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61408 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;a.google.com. IN A > > ;; Query time: 0 msec > ;; SERVER: 10.0.1.21#53(10.0.1.21) > ;; WHEN: Thu May 19 15:00:13 EDT 2022 > ;; MSG SIZE rcvd: 41 > > ** Affects: dnsmasq (Ubuntu) > Importance: Undecided > Status: New >