Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Cache DNS records based on the record requested #56
Currently amp/dns caches records returned from the dns server indexed by their returned type instead of the requested type. that means if we look up a DNAME record and instead receive a
This commit changes this behavior and instead caches the record with the
Currently Amp/DNS will only cache (in-memory) for the record type returned from the DNS server. that means if we look up a DNAME record and instead receive a CNAME record, it'll be cached under CNAME, leading amp to make additional requests for the DNAME record it technically already received. This commit changes this behavior and instead caches the record with the requested type as the key rather than the returned type.
As I read that, the short answer is yes, unless the DNAME record itself has changed.
The long answer, considering the wider implications, is a thing that I am going to need to think about a lot more and probably read that entire RFC through another 10+ times before I even have an opinion :-P
That said, it is still my view that we should not be explicitly querying for DNAME records, because servers are required to perform substitutions themselves. Thus (apart from the very specific use case of writing a DNS cache server application) we shouldn't actually be querying them at all in the normal name resolution flow - i.e. when we are attempting to resolve any explicit RR type other than DNAME itself.
thanks @DaveRandom. fwiw, this commit would also apply to other record types and not just DNAME => CNAME. ie when requesting an AAAA type record and getting a CNAME in return from the server, should it be cached under CNAME and AAAA, or just under AAAA as that was the type requested?
before this commit, AAAA resolving in CNAME would only be cached under CNAME. so i doubt caching under both keys would break anything. or at least it hasn't been brought up.
Sure I understand that
I'm sorry but I've not really had time to properly review this patch and the implications of it, and I'm probably not going to be able to in the next week or so, but if others are happy with it I'll defer to them.
It may make sense to have a 2-layered approach to caching - caching entire responses, so that if a response is cached for a with an exact match for the query that can be used, if that isn't present then a "record"-level cache can be used to try and build a complete response. This is complicated somewhat by the fact that some servers will transparently dereference CNAMEs in some scenarios (e.g. most of the time if you send an A query for an fqn constructed from a CNAME, you will get the actual target A-record back).
That is beyond the scope of this PR though, which from a cursory look seems to stand on it's own and provide a useful change.