[reSIProcate] Dns Caching/Blacklisting

["derek" <derek@xxxxxxxx>]

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.