DNS Resolver Caching
-
I have DNS Resolver configured as a resolver and I'd like to know how, if possible, I can keep the cache current on a small network?
If I resolve and cache a site, I'll get 0 ms reply via DNS for the TTL period, but 1 second after that resolver is going out again for that record.
I have prefetch enabled, but according to what I've read with unbound that will only work if a request is made while the TTL is less than 10%.Messing with cache-min-ttl seems like a bad idea too….
So... is there something I can do to force my records to stay current in the cache?Thanks for the help!
-
There's nothing you can do about it if the authoritative server for a domain sets a a low TTL for its records. You never want to extend the TTL on your own even if it looks like a lucrative option, you may end up breaking things because those TTL values are not just set at random, they very likely have a purpose.
-
Can you give an example site? What is their ttl? It shouldn't take 1 second to resolve something.. Something is not right there - either their authoritative ns are just BAD.. or your latency is horrific atleast to where their ns are..
is this all sites? Or just some specific ones? Or one?
I agree extending a TTL from what the owners intended is not something that should be done very often.. Maybe they are in the process of a move and have the low ttl for a reason to min issues after the move? Maybe they serve up from a lot of different IPs and use some sort of round robin to distribute load?
What you could do, which could cause its own issues. But if your having a problem with a specific site for whatever reason. And you know the sites IP for specific records is not changing.. You could put in a host override for the specific fqdn your having issues with.
-
It shouldn't take 1 second to resolve something..
No, that's not the case. Sorry for the bad wording, what I was trying to say is "right after" the TTL expires it fully resolves again - not that it takes 1 second.
My lookups, according to dig, take on average 80 ms when a record is not in cache - not a big deal. However, other than security concerns, is there really a reason for a SOHO to NOT use forwarding if that server is faster?
-
How is forwarder going to be faster? While it might be faster for a specific record and a specific example query based upon if that forwarder had something in cache already..
You really need to look at the big picture, in that your still caching stuff local once your users have asked for it, for the FULL length of the TTL.. When you just ask some forwarder.. This query is going to take as long as it does to ask the forwarder, and if that forwarder does not have it cached, then its possible the actual query for what your looking for could take longer then if you would of just resolved it anyway..
Now its possible that if someone else using that forwarder had asked for what your looking for then it could be cached and you could get a faster response then if you resolved it. But then your only going to get the partial TTL.. And then you would have to ask again!! once that ttl has expired. Which then again would just be a partial of the TTL again.
In the big picture once your userbase has built up the cache in your resolver, users should not see any noticeable delay in looking up stuff. Even if your talking a few extra ms on average if you take a large sample.. What is the issue? Your sure with a resolver that your getting the information from the horses mouth and have use of dnssec, etc.
If you want to use forwarder, then go right ahead and user forwarder. But your seems like your basing that its "faster" on limited sample size specific queries and not taking into account the actual full picture of what is going on.. Depending on what your userbase queries for, how often, and what the forwarder(s) your using.. It could be possible that using a forwarder actually causing more wan queries then just resolving on your own.
You would have to really do a full study with large sample size to determine.. But then again your talking a difference of few ms here and there, etc.
If your more familiar with how forwarding works vs resolving - then sure use the forwarder.. Vast majority of the internet just forward their queries to their isp dns, or google or open, etc..
-
Forwarding is generally faster because you are (usually) forwarding to DNS servers that have many more users and thus more records already in their cache, and usually without DNSSEC involved.
Acting as a recursive validating DNS Resolver is slower because there are more operations for the resolver to take (contact roots, then authoritative name servers which might be slow, etc) plus the time to validate DNSSEC.
The default is to use the DNS Resolver in resolver mode with DNSSEC by default because it's a much more secure and stable default – It validates the integrity of DNS responses when possible and there is no need to bother configuring DNS servers, it Just Works(TM).
Once things are in the cache responses are faster, and cache sizes can be tuned, but if all you care about is speed then by all means use the forwarder and point it toward some large and fast DNS servers like Google's 8.8.8.8/8.8.4.4
-
All good stuff there jimp.. And I agree with you for a specific record. Yes it might be faster to forward to somewhere that has it cached.
But what is the round trip time of that query, even if cached to that NS your forwarding too.
What is the TTL of the specific record? What is the TTL of the NSers down the tree.. So lets say I am looking up www.domainX.tld, once the resolver caches the NS for domainX.tld.. As long as that TTL is valid it does not have to go ask anything up the tree. He has cached the NS for domainX.tld cached. So if looking for record www, he just has to go direct to the NS for domainX.tled.
Which you never know might actually be quicker to respond than who your forwarding too ;) Even if that forwarder has it cached, if he doesn't then he has to either forward it or resolve it.. Which for sure could be slower than you just directly asking the NS for domainx.tld for www
So lets say the ttl on www is 5 minutes. So when your resolver looks it up again the ttl is always going to be 5 minutes.. But depending on exactly when your client asks for it and what the forwarder ttl time is.. And then when your client(s) ask for it again. You could actually cause 2 wan queries for it when you would of only needed 1 if you would of just resolved it.
If you get back a expiring ttl of 1 min, you can only cache it for 1 minute.. So if you have another client on your network ask for say at 2 min now you have to go ask the forwarder again. But if you would of resolved it you would of had full 5 min ttl. So your client that asked for it at the 2 min mark would of just gotten a cached value and a 3 min ttl for his cache.
Yes your dnssec is going to add some time to your overall speed, etc.. But to be honest in the big picture you really should just run a resolver, unless you have some specific issue why you can not, like your isp intercepts dns, etc. Or you have just really bad latency and don't want the added over head of walking down the tree from roots and extra overhead of dnssec.
But once you get your cache going and depending on the actual use of your clients.. The difference that you might have now and then from having to resolve vs forward, with the added benefit dnssec, I don't see how couple ms here or there make a difference.
To be honest if the user is looking speed up their internet because they think the resolver is slowing them down - then they prob have more issues than a couple extra ms to lookup something.