[reSIProcate] Dns Caching/Blacklisting

[derek]

Implementation has started on Dns caching, here's the latest design + open
issues.  

 

Cache Approach:

 

There is a set of cached RR lists for each supported RR type; adding new
supported RR types will be easy.  Each RRList has a absoluteExpiryTime based
on the min TTL encountered in the RRs.  Absolute cache size will be
maintained using an LRU list.

 

The DnsStub object will follow CNAME to a maximum depth of 5(or
configurable).  The user of the DnsStub api never has to deal w/ CNAME
directly.

 

BlackListing:

 

There is a list of elements for each target (RR + FQDN), which is the RRList
class.  Blacklisting an element will be accomplished by pushing it to the
back of the list and marking it with a generation/marker to avoid constantly
looping through the list.  When all elements have failed, the TTL for that
RRList will be adjusted to expire in magic amount of time which may involve
querying the user.  This magic time will not apply if the real expiry time
was sooner.  This assumes that you never want to re-use an element that has
been marked as bad until you have exhausted all the alternatives.  While the
re-query may not strictly be necessary, it only happens when all
alternatives fail and it has the nice property of picking up desirable dns
changes before the ttl expires.

 

Implementation Tradeoffs:

 

1. The current implementation approach has a set rather than a map to avoid
keeping a back pointer/duplicate key but will require caching CNAME,
although only the last step of the CNAME 'path' will need to be cached.  I
suspect this will be cheaper overall.

 

2. David proposed just using an LRU list and not greedily invalidating
elements with an expired TTL.  If the cache has hit it's maximum size the
LRU object will always be removed.  Also, whenever the cache gets cycles it
will do N amount of cleanup work.  The proposed algorithm for each pass is:

 

1.	look at the oldest element in the cache
2.	If it TTL expired remove it, over wise mark it a youngest.

 

Dns Questions:

 

A couple of questions that affect the implementation: from page 4 of 2782,
it states that name compression is not permitted for the Target field,
unless permitted by future standards.  Should we support name compression
for that field?

 

3.2.1 ff rfc1035 says the following about the NAME portion of an RR:  NAME
an owner name, i.e., the name of the node to which this resource record
pertains.  

 

Is the NAME of each RR the same across all RRs in a result, and always the
same as a containing node?

 

--Derek

his email and any files transmitted with it contains proprietary information
and, unless expressly stated otherwise, all contents and attachments are
confidential. This email is intended for the addressee(s) only and access by
anyone else is unauthorized. If you are not an addressee, any disclosure,
distribution, printing or copying of the contents of this email or its
attachments, or any action taken in reliance on it, is unauthorized and may
be unlawful. If you are not an addressee, please inform the sender
immediately and then delete this email and any copies of it. Thank you for
your co-operation.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050304/e7a84710/attachment.htm>