[bind10-dev] recursor cache requirements - input required

[Jerry Scharf]

[...]
> On 8 Dec 2010, at 19:31, Jerry Scharf wrote:
>> I like Shane's idea of one class per cache. Since the cache in not a once per server entity (each view requires its own cache), if someone wants hesiod queries (the only other class I know of) build a separate cache for that. It will decrease the size and increase the speed of each class in this case.
> The actual IANA DNS Class registry is:
>
> Registry:
> Decimal      Hexadecimal    Name                            Reference
> -----------  -----------    ------------------------------  ---------
> 0            0x0000         Reserved                        [RFC5395]
> 1            0x0001         Internet (IN)                   [RFC1035]
> 2            0x0002         Unassigned
> 3            0x0003         Chaos (CH)                      [Moon1981]
> 4            0x0004         Hesiod (HS)                     [Dyer1987]
> 5-253        0x0005-0x00FD  Unassigned
> 254          0x00FD         QCLASS NONE                     [RFC2136]
> 255          0x00FF         QCLASS * (ANY)                  [RFC1035]
> 256-65279    0x0100-0xFEFF  Unassigned
> 65280-65534  0xFF00-0xFFFE  Reserved for Private Use        [RFC5395]
> 65535        0xFFFF         Reserved                        [RFC5395]
>
> Unless we filter the class request, we have to cope with the possibility creating up to 65,536 caches - hence my comment above.
>

All these classes except for hesiod are defunct AFAIK. Hesoid is used at 
MIT but I don't think that hesiod was carried over to MS active 
directory. As such, I would set up the default to allow IN and HS and 
not allow the rest. None and any are not cached. Chaos net is long dead. 
The bigger problem with cache instancing is when people have multiple 
views. One person in the user survey reported having 100 views on one 
machine. Not surprisingly , he complained about memory footprint. 
(Patient: "doctor, it hurts when I do this." Doctor: "stop doing it.")

>> I do not think you should keep any message in the cache. I have been involved in more than one recursive server and have never seen the response message from the upstream cache fill or the answer created for the client kept. You always have to regenerate the answer from the validated data in the cache to prevent cache poisoning attacks, so keeping the upstream message is a bad idea. You also have situations where the answer from before is no longer correct. (a classic example of this is that the first answer used the glue NS rrset for the authority data and that rrset was later replaced by the authoritative zone NS rrset or a new query within the zone included a new NS rrset in its authority section.) You need to build everything you need from the current cache information.
> I appreciate that, yet I would think that in some situations - queries for www.google.com for example - a pre-formatted reply that can be sent immediately could be a big performance improvement.
>
> Stephen
>

I haven't done this for a few years, When I last looked at recursive 
server traffic, things like www.google.com are queried less than you 
think. Most endpoint resolver keep a cache so you don't look up 
www.google.com every time you get a new page. The ones that hurt are 
ones like facebook and yahoo that use short (<=120 s) ttls. Since the 
data invalidates on the server the same time it invalidates on the 
client, there is no win in keeping the message around for these.

Since you are saying it needs to be its own resource with its own LRU, 
you always need to have the ability to build the message from the cache. 
Leave a couple hooks in place and get the server working first. There 
are all sorts of corner cases to be found and addressed. Paul and Vern, 
with me kibitzing, spent 4+ months finding all sorts of corner cases out 
in the wild and fixing the server to handle them correctly. Pretty much, 
if it resolved in the prior version of BIND, you are not allowed to 
break it. I wonder if merit.edu's delegation is as FU as it was 4 years 
ago. It's an ugly namespace out there and a recursive server gets to see 
it all.

jerry