BIND caching of nxdomain responses

[Matus UHLAR - fantomas]

>> On 22.10.21 09:57, Dan Hanks wrote:
>> >As I understand RFC 2308, when receiving an NXDOMAIN response, and when
>> >deciding how long to cache that NXDOMAIN response, a resolver should use
>> >whichever value is lower of the SOA TTL, and the SOA.minimum value as the
>> >length of time to cache the NXDOMAIN.
>> >
>> >I have a situation where I am seeing different behavior from that in BIND.
>> >Given the following SOA record:
>> >
>> >azure.mongodb.net.      900     IN      SOA     ns-1430.awsdns-50.org.
>> >awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60
>> >
>> >I am finding that BIND (9.11.x) is caching the NXDOMAIN response for 900s
>> >(SOA TTL), instead of the expected 60s (SOA.minimum).
>> >
>> >I have noticed that many auth servers out there will drop the SOA TTL to
>> >match the SOA.minimum value when attaching the SOA record to an NXDOMAIN
>> >response. Is BIND expecting this to happen, and just opting to use the SOA
>> >TTL value (and not the SOA.minimum value if they disagree)?

>On Fri, Oct 22, 2021 at 10:29 AM Matus UHLAR - fantomas
><uhlar at fantomas.sk> wrote:
>> are you authoritative server for azure.mongodb.net?
>> if not, BIND will use cache time that came from authoritative server adn
>> won't parse the SOA itself.

On 22.10.21 10:56, Dan Hanks wrote:
>I am not authoritative, I'm just making recursive queries against this domain.
>
>When you say, "BIND will use cache time that came from authoritative
>server", what 'cache time' are you referring to? Are you referring to
>the values in the SOA record included in the AUTHORITY section of the
>NXDOMAIN response?

I assume that BIND will keep the TTL as it was received from upstream
servers (of course, local TTL restrictions may override it)

If the upstream sends SOA record with TTL 900 second, BIND will keep it at
900 seconds, no matter what the SOA minimum says.

if the TTL returned above is 900 seconds, BIND will return 900 and cache the
record for up to 900 seconds.
-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.