pihole-FTL will not return SOA records if NXDOMAIN is cached for A records

[schuettecarsten]

Try to guery message-waiting-indication02.service.sipgate.net from pi-hole. On the first try, it will return a SOA record in the authority section and a NXDOMAIN for the A record:

pi@raspberrypi:~ $ dig message-waiting-indication02.service.sipgate.net
[...]

;; QUESTION SECTION:
;message-waiting-indication02.service.sipgate.net. IN A

;; AUTHORITY SECTION:
sipgate.net.            10610   IN      SOA     ns1.netzquadrat.de. dnsadmin.netzquadrat.de. 2023083100 10800 3600 604800 86400

;; Query time: 15 msec

On the second and all subsequent tries, it will return NXDOMAIN. This seems to happen because pi-hole caches the NXDOMAIN for the A record and does not handle any SOA any more:

pi@raspberrypi:~ $ dig message-waiting-indication02.service.sipgate.net
[...]

;; QUESTION SECTION:
;message-waiting-indication02.service.sipgate.net. IN A

;; Query time: 3 msec

When querying google.dns or quad9 directly, I always get a SOA response. I am not sure if this is really a bug, I just can see that I have connection issues with sipgate and siproxd when usin Pi-Hole without any blocking lists. The only difference that I can see is the SOA record.

[yubiuser]

Thanks for your report. I'm not sure if this is a bug on our side or the others. I think the relevant section is https://datatracker.ietf.org/doc/html/rfc2308#section-5

Like normal answers negative answers have a time to live (TTL). As there is no record in the answer section to which this TTL can be applied, the TTL must be carried by another method. This is done by including the SOA record from the zone in the authority section of the reply. When the authoritative server creates this record its TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This TTL decrements in a similar manner to a normal cached answer and upon reaching zero (0) indicates the cached negative answer MUST NOT be used again.

As the TTL is set to 3600 caching NXDOMAIN for 3600 seconds seems appropriate. dnsmasq (which Pi-hole uses internally) manual state:

--neg-ttl= Negative replies from upstream servers normally contain time-to-live information in SOA records which dnsmasq uses for caching. If the replies from upstream servers omit this information, dnsmasq does not cache the reply. This option gives a default value for time-to-live (in seconds) which dnsmasq uses to cache negative replies even in the absence of an SOA record.

I'll transfer this issue to the FTL realm.

[DL6ER]

SOA (start of authority) records contain administrative information about the zone. They are (mostly) always reported by recursive resolvers. Caching DNS servers (such as pihole-FTL) are not supposed to cache and thereafter distribute it from cache. The reasons why SOA records exist is that they needed for zone transfers. Caching resolvers will, however, never (or only in very rare circumstances) have a full copy of a zone available and, hence, are unsuitable for zone transfers to begin with. Accordingly, missing SOA information in cached replies is actually expected and not a bug.

edit Your sipgate/sipproxy issues are not related to SOA records (I can see no way they could be). Try running PI-hole without any cache (remember to also disable DNSSEC validation) and check if this changes anything.

[schuettecarsten]

Thank you for explanation.