Bug 425 - Unbound sticks to old NS when "prefetch yes"
Unbound sticks to old NS when "prefetch yes"
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
1.4.14
All All
: P5 minor
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-23 08:46 CET by Daisuke HIGASHI
Modified: 2012-01-10 10:45 CET (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daisuke HIGASHI 2011-12-23 08:46:58 CET
With "prefetch no" Unbound DOES NOT re-cache NS record in
authoritative section from authoritative namesever.

With "prefetch yes" Unbound DOES re-cache NS record in
authoritative section from authoritative namesever (by prefetch).

  This leads Unbound, with "prefetch yes", to sticks to "old NS"
in some case of zone's nameserver migration (old NS -> new NS). 

Without "prefetch yes" I don't see this issue.


- Problem description

Consider this case (also see Appendix below):

(1) At initial state, parent zone (com) delegates "example.com"
    zone to old-ns.example.com. Unbound cache entry is
    "example.com NS old-ns.example.com.", "www.example.com A 10.1.1.1".

(2) For nameserver migration parent zones delegation has been
    modifed to "new-ns.example.com."  Unbound cache entry is
    still "example.com NS old-ns.example.com" until this extry expires.


With "prefetch no":
    When www.example.com expires Unbound again asks to OLD-NS for www.example.com.
    OLD-NS says "www.example.com A 10.1.1.1" and "exmaple.com NS old-ns".
    Unbound re-caches "www.example.com A" and DOES NOT re-cache "example.com NS".

    After cache entry "example.com NS" expires Unbound fetches NS record
    from parent zone and learns "exmaple.com NS new-ns.example.com"

With "prefetch yes":
 When www.example.com entries TTL reaches 10% of original TTL,
 Unbound again asks to OLD-NS for www.example.com.
 OLD-NS says "www.example.com A 10.1.1.1" and "exmaple.com NS old-ns".
 At this time,
   Unbound re-caches "www.example.com A".
   Unbound also re-caches "example.com NS old-ns" from OLD-NS.

 This leads Unbound to sticks to "OLD-NS".


RFC 2181 5.4.1 doesn't specifies whether cache server should updates entry
when receiving same rank data. Furthermore this migration contains
operational error (old NS's zone file also should point new NS).
So it is not bug, but may be unexpected behavior.


Appendix. Nameserver Migration

(1) Initial state

--- Parent (com.) zone
; delegation example.com
exmaple.com.        86400 NS old-ns.example.com. ; delegation
old-ns.example.com. 86400 A  192.168.0.1


--- example.com OLD NS (old-ns.example.com)
; example.com zone data

example.com.       86400 NS old-ns.example.com.
old-ns.example.com 86400 A  192.168.0.1
www.example.com.    3600 A  10.1.1.1


--- example.com NEW NS (new-ns.example.com)
; example.com zone data
example.com.       86400 NS new-ns.example.com.
old-ns.example.com 86400 A  172.16.0.1
www.example.com.    3600 A  10.2.2.2



(2) Parent zone delegation modified

--- Parent (com.) zone
; glue to example.com
exmaple.com.        86400 NS new-ns.example.com. ; *** modified delegation
new-ns.example.com. 86400 A  172.16.0.1


--- example.com OLD NS (old-ns.example.com)
example.com.       86400 NS old-ns.example.com.
old-ns.example.com 86400 A  192.168.0.1
www.example.com.    3600 A  10.1.1.1


--- example.com NEW NS (new-ns.example.com)
example.com.       86400 NS new-ns.example.com.
old-ns.example.com 86400 A  172.16.0.1
www.example.com.    3600 A  10.2.2.2
Comment 1 Wouter Wijngaards 2012-01-02 14:41:43 CET
Hi Daisuke Higashi,

Thank you for the bug report, I'll look into it.  I think it mostly works, but perhaps there are explicit queries for this NS record which make it different from cases where there are no explicit (user-)queries for these NS records.  Unbound must not stick to the child NS records.

Best regards and a happy new year,
   Wouter
Comment 2 Wouter Wijngaards 2012-01-10 10:45:13 CET
Hi Daisuke Higashi,

The svn commit r2581 resolves this issue.

It did not really stick to the child domain.  It reported wrong TTL for the NS record.  The fix is that it reports the lower TTL (from the cache).

The TTL that it reported was the TTL (max TTL) from the authority server, but in reality the TTL in the cache was lower because the NS record does not get updated.

Best regards,
   Wouter