BIND 10 #492: Search cache for closest enclosing name NS

BIND 10 Development do-not-reply at isc.org
Sat Feb 19 03:24:48 UTC 2011


#492: Search cache for closest enclosing name NS
-------------------------------------+-------------------------------------
                 Reporter:  shane    |                Owner:  jinmei
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:  R-Team-
                 Priority:  major    |  Sprint-20110222
                Component:           |           Resolution:
  resolver                           |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  1.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:4 zhanglikun]:
 > Yeah, the interface is used to search cache for closest enclosing name,
 currently seems only used for NS record, so it's a little different with
 the "closest encloser" in NSEC/NSEC3. So how about lookupClosestNS()?

 It sounds much better.  Personally, though, I think "closest" is a bit
 ambiguous because it may also mean the exact or immediately
 before/after the given name in terms of DNSSEC ordering.  And in that
 sense I'd prefer the term "deepest", but it may be a matter of
 preference.

 FYI, BIND 9's equivalent function is named dns_view_findzonecut(),
 i.e., it uses the term "zonecut" (and doesn't say closest or deepest
 although what it does is to find the deepest NS).

 > Do we have the requirement for other types in future?

 If we consider the context, we'd find it meaningless.  The notion of
 "deepest" (or "closest") in terms of name resolution only matters in
 the context of delegation.  When we are thinking about
 www.example.com/A, it doesn't help anything even if we detect there's
 no such RR but example.com/A.

 So, I'd say "no" to this question, and I'd suggest revising the
 interface by removing the 'qtype' parameter.  FWIW, BIND 9's
 dns_view_findzonecut() doesn't have a parameter for RR type.

-- 
Ticket URL: <http://bind10.isc.org/ticket/492#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list