Possible to let clients cache NOERROR responses?

[IngmarStein]

I have a conditional forwarding zone for the local domain which forward to the gateway which runs the DHCP server.

As my network is IPv4 only, all AAAA queries for the local domain are answered by the gateway as NOERROR responses (for hostnames which have A records, otherwise it returns NXDOMAIN).

The final response unfortunately has no authority section which means that clients can't cache the response:

❯ dig AAAA service.localdomain @{technitium}
; <<>> DiG 9.17.22 <<>> AAAA nas.localdomain @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24612
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;service.localdomain.		IN	AAAA

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu Oct 10 12:58:58 CEST 2024
;; MSG SIZE  rcvd: 44

Here's the corresponding cache entry:

{
    "name": "service.localdomain",
    "type": "AAAA",
    "ttl": "0 (0 sec)",
    "rData": {
      "dataType": "DnsSpecialCacheRecordData",
      "data": "NegativeCache: NoError"
    },
    "dnssecStatus": "Unknown",
    "responseMetadata": {
      "nameServer": "192.168.1.1",
      "protocol": "Udp",
      "datagramSize": "48 bytes",
      "roundTripTime": "0.88 ms"
    },
    "lastUsedOn": "2024-10-10T10:48:24.2336336Z"
  }

The forwarding zone has a SOA record. Should this be added to NOERROR responses with the respective TTL?

[ShreyasZare]

Thanks for the post. Negative caching totally depends on clients and how they implement it. Even if there is no SOA available, they can cache it for a certain time again depending on how they implement it. The DNS server uses Negative Cache TTL value in settings in such cases.

Using SOA in forwarder is not possible since the Forwarder zone is not authoritative and the SOA is just a dummy record that exists to facilitate zone transfer support to Secondary Forwarder zones. Using this SOA will be breaking the protocol standard.

[IngmarStein]

Thanks for the response! It's a client which I can't control (https://community.home-assistant.io/t/disable-all-these-useless-aaaa-requests), so I guess I just have to live with it. Thanks again!

[ShreyasZare]

There is another option that you can try in that case. Just put an wildcard AAAA record with :: value in your forwarder zone and a high TTL value. Try that and see if the client is able to ignore this AAAA record and proceed using the A record.

[IngmarStein]

The client expects either NODATA for existing hosts or NXDOMAIN for non-existing hosts, but the unspecified address might be worth a try. I'll give that a shot!

The "Filter AAAA" app almost gets the job done (it adds a SOA record), but it only operates on non-empty AAAA responses…

[IngmarStein]

The combination of "Filter AAAA" and a wildcard AAAA record containing "::" is getting me pretty close to the ideal state:

Method	A - existing host	AAAA - existing host	A - non-existent host	AAAAA - non-existent host
Only forward	IP	NODATA, no SOA	NXDOMAIN, SOA	NXDOMAIN, no SOA
Filter AAAA	IP	NODATA, no SOA	NXDOMAIN, SOA	NXDOMAIN, no SOA
Wildcard AAAA	IP	unspecified address, SOA	NXDOMAIN, SOA	unspecified address, SOA
Filter + Wildcard AAAA	IP	NODATA, SOA	NXDOMAIN, SOA	unspecified address, SOA
Ideal	IP	NODATA, SOA	NXDOMAIN, SOA	NXDOMAIN, SOA

However, this combination has an ugly side-effect: Filter AAAA now also applies outside the localdomain zone (which is also the network search domain) which results in clients now trying to resolve names like www.googleapis.com.localdomain when they don't get an address for AAAA www.googleapis.com and receive ::.