The behavior below has been observed on BSD/OS and FreeBSD servers running
bind 9.2.1.
SUMMARY
Bind9 as caching resolver will update the TTL of cached NS records in such
a way that a redelegation might not be discovered. This must be considered
to be a bug or bad design.
DETAILS
When bind9 runs as caching resolver it will update the NS records from
authoritative data from authoritative response. Say that namn.se has the
following delegation from the SE zone:
namn.se. 86400 NS ns1.localhost.se.
Let say we have the follwing data in the zone (on ns1.localhost.se),
namn.se. 3600 NS ns1.localhost.se.
namn.se. 60 A 192.0.2.3
If a bind9 resolver gets a query for "namn.se. A ?" and the response
contains the NS record in the authoritative section then the cache of
the bind9 resolver will store the TTL from the namn.se zone instead of
keeping the TTL from the SE.
This is new behavior of bind9. A bind8 resolver will keep the TTL of the
SE zone. The behavior of bind9 seems reasonable, so far.
If the A record namn.se has timed out, next time the resolver receives a
query for the same A record, then the bind9 resolver will use the cached
NS records to find authoritative data for namn.se. Before we send the
query the NS records might have only 1800 seconds left of TTL. What
happens after the response comes back?
If the response contains the same data as before (the A record in the
answer section and the NS record in the authoritative section), then the
bind9 resolver will update its cache with both the A record *AND* the NS
record. That means that after the response the TTL will have the maximum
zone value again without any query to the SE zone.
The consequence of this behavior is that the NS records of a zone could be
"frozen" in the resolver if the they are updated before the TTL times out.
Say that there is a query for "namn.se. A ?" every 10 minutes, then the
resolver will never find out if the delegation has changed in the SE zone
as long as the old servers continue to answer.
I would say that the behavior is a bug or bad design.
* A resolver must never update cached NS records when the records came
from an authoritative source without requerying the delegating zone.
* If the resolver has cached NS records that came from a non-authoritative
source, then it may (or must) update the NS record it receives data from
an authoritative source, but never if data comes from a non-authoritative
source.
PROTOCOL
What does the DNS protocol say about updating cached NS records?
Mats
----------------------------------------------------------------------
Mats Dufberg Registry TeliaNet
dufberg@xxxxxxxxx Skanova/Nwi
+46 8 71 354 38 Mårbackagatan 11, hus L
+46 70 258 2588 SE-123 86 Farsta
----------------------------------------------------------------------
|
