Kitz Forum
Chat => Tech Chat => Topic started by: Weaver on October 15, 2018, 01:08:42 AM
-
Say you are a big ISP. You run a DNS relay proxy cache for your customers. Knowing what the pattern of requests in the cache is, you could decide on a ‘greatest hits’ ‘top ten’ or whatever, a list of most requested domain names. Using this, you could then actively re-query these domain names from an upstream source or from the authoritative server even, just before the cache entry expires. That way, when a user re-queries the domain name she will get an answer instantly as you will already have done the work.
A second option, a further improvement would be to query the domain name from the authoritative servers at half the time to live, thus getting an extension on the time to live, that would mean a better, longer-lived, result for users who re-query the domain name later within the original time-to-live validity period. This of course would be unkind to the authoritative servers by putting unnecessary extra load on them, but since it is only large ISPs doing this, not millions of individual users, the net effect would be a reduction in load that more than offsets the extra imposed by this small trick.
Do you think it would work? Would it be any good?
If someone had knowledge that certain domain names are important then that user could pre-query such names in advance, just to make sure that the cache is always populated.
I realise that I don’t know what happens when a domain name is unnecessarily re-queried within the validity time. Do you get a new response with the same end time, that is a shortened validity time? (Because the server is not re-querying the authoritative server and so there is less and less of the original validity period left.) I have absolutely no idea at all of what I am talking about. Of course it seems like a really bad idea to start giving out shorter and shorter validity time values. If you as a server just ignore the whole thing, and just give out certain fixed validity times then you are at least not going with the madness of eventually shortening validity times down to nothing, but then the idea of a certain actual defined validity time window with a real start and end point goes out of the window, but perhaps a very approximate concept which is vague is very much more than good enough.
-
Do you think it would work? Would it be any good?
possibly, and no
-
Probably a topic to do some more research on. Musing over things you, in your own words, 'have absolutely no idea at all of what I am talking about it' is a fairly rapid route to a head-spinning experience :)
Just as a thought, though, how much of a time saving are you expecting from this? The only time people querying a caching DNS server are actually going to hit the delay you want to avert is in between TTL expiry and the first query that goes to the authoritative, and you've said you want a 'greatest hits' list so the percentage of requests this would actually benefit is miniscule.
-
That is a very good point about the greatest hits thing. I was just thinking, or rather not thinking properly, about limiting the amount of load, the thing not going too crazy, but this turns out to be rather a backwards approach.
-
on my phone so shortened reply
lookup dns prefetch existing tech
also lookup unbound serve-expired < killer feature
also major dns providers like google will have so many hits from clients that major dns names will stay cached a lot
-
So how / when do validity times get extended - this is what I need to look into. If clients keep querying popular names and the answer is in the cache so nothing happens, then there is never any recheck that the name has not changed, not until the cache entry expires, then presumably the first unlucky client gets a delay - is that right? So the idea would be to extend some validity periods, by doing an unnecessary query straight to the authority, never mind cache entries, and then write a new cache entry with an extended validity period that stretches further into the future, and then no client is randomly unlucky, getting the avoidable delay. Am I completely wrong on this?
The thing is possibly not to extend lifetimes of entries that no one has any more interest in. How to decide that ?
It doesn’t amount to more load on the authoritative servers, if you are getting the design vaguely right and not prolonging stuff noone has any interest in. You are doing a query a bit earlier that’s all, before the point when validity period would have run out anyway.
I presume that I couldn’t just try and change this by doing ordinary queries anyway? Because they would just get answered from the cache and nothing would happen?
-
Hi weaver
I’m sorry, I hope I have understood your post correctly but apologies if I have not
In simple terms, the person in charge of the domain dns sets the TTL, and I suspect they would not want that to be altered in any way away from their set time. I certainly would not.
So if your idea is to say bring a new query into cache to extend the time, then that’s wrong, even if your query say brought the record into cache 1 second early to extend from say TTL 3600 to TTL 3601, which you would be doing.
Also, you are still querying so I am not sure what you are trying to achieve fully
Lastly, how is your idea going to change the users router/computer/etc dns cache
As I said, not fully understanding your post sorry but think you periodically keep raising this as a thread
Many thanks
John
-
There's nothing intricately wrong with re-fetching early as you will also get the current TTL - so exactly the same as if the entry had expired from the cache and had to be fetched anyway.
I'm sure that the operators of the major DNS services and writers of the DNS server software will have looked at every way possible of optimising their systems to get the best performance. People using https://www.grc.com/dns/benchmark.htm (https://www.grc.com/dns/benchmark.htm) and similar will have driven them to make sure they come out in the best light. When it comes to ISP and hosting providers DNS servers I'd bet that hardware and network configuration is far more significant than minor tweaks to optimise the method.
Speculating with our very limited knowledge and without the masses of data to analyse performance of actual servers strikes me as a waste of time!
-
If clients keep querying popular names and the answer is in the cache so nothing happens, then there is never any recheck that the name has not changed, not until the cache entry expires, then presumably the first unlucky client gets a delay - is that right?
That's not my understanding of how DNS works.
You click a link, www.somesite.com
Your client (your iPad) will query the DNS server you have set. It will get the IP from the DNS server and it will cache it for the current TTL set.
There's no more querying of DNS servers for that particular hostname/IP by the iPad until the TTL expires.
It's your comment
then presumably the first unlucky client gets a delay - is that right?
that has me lost.
What unlucky client are you referring to?
Every client needs to query the DNS server. Each individual client has their own DNS cache.
Looks like (from the extremely limited documentation I can find) that the Firebrick does a form of DNS cache/relaying where it stores recently queried addresses for a short period.
Firebrick docs don't say how long for, if they use TTL, who knows.
Not all routers have their own DNS cache.
A DNS query only takes me about 20ms.
I can't see how you could optimize this.
You reference a "greatest hits". Can you explain how that would help? You would still need to query the DNS server to get this greatest hits list and it's associated IP's.
The current system works perfect. You query a host, the DNS server responds. Your client (and router in some cases) will cache it for a set time period so it doesn't need queried again.
-
You are looking at it from the point of view of a user doing DNS lookups on EU equipment. Weaver's opening post made it clear he wasn't speculating about this:
Say you are a big ISP. You run a DNS relay prix cache for your customers. Knowing what the pattern of requests in the cache is, you could decide on a ‘greatest hits’ ‘top ten’ or whatever, a list of most requested domain names.
...
-
weaver both prefetch and serve expired still fetch updated records they just dont make the client wait for it they do it in background to update cache for future lookups
they superior in that respect to the older techniques of bumping up ttl against domain admin wishes
jelv a dns relay that caches is a dns cache they the same thing, so tricks a home user can do apply tp isps as well, e.g. google dns is really just a dns cache hosted by google.
-
You are looking at it from the point of view of a user doing DNS lookups on EU equipment. Weaver's opening post made it clear he wasn't speculating about this:
Point still applies.
I can't think of a single scenario where a "greatest hits" would make any difference.
The customer still needs to query every single hostname once. It gets cached and the customer doesn't need to query the DNS server again till TTL.
DNS is pretty efficient and if it could be easily optimised I'm sure it would have been already.
-
> still fetch updated records they just dont make the client wait for it they do it in background to update cache for future lookups
I am no completely clear about the context, but this is good news, sound like someone is already doing the kind of thing I was looking for. But what limits the number of calls on through to the authoritative server? Apologies if I have failed to understand.
And to d2d4j, my sincere apologies if I have been guilty of repeating myself, which is highly likely, repeated posting. I can only ask your indulgence. Searching the database of posts is often difficult as deciding exactly what queries to use is not easy. The amount of drugs is the culprit, the pain medication means that my memory is completely shot and I can’t even remember stuff that happened only a week or two back. So mea maxima culpa,
-
Hi weaver
Many thanks and I fully understand sorry.
There’s more to this though then mention, eg geolocation, specific dns depending upon query il address, load balancers etc... so your just scratching the surface but as been mentioned, these have already been optimized and is still ongoing. Eg powerdns
Many thanks and have a lovely night
John
-
I would indeed love to find out more about this, about the innards of it. Then my questions might be a little less annoying, not so completely ill-informed. If I could find the source code for one popular DNS subsystem then I could read it, drugs permitting.
[Reading other people’s code is something that I loathe and I am very bad at it. But I am good at spotting performance cockups and bad practice, having done code reviews on occasion. (Am obsessive about micro performance for speed as I am an asm programmer through and through, and often look at the compiled asm output from a high level language compiler to see what kind of sins it is committing or to clarify exactly what some code is actually really doing.)]
-
Ok now I am on my PC I can be more clear.
So without prefetch or serve-expired its something like this.
First DNS lookup is not in the cache, so the DNS cache/forwarder has to send the query upstream, much slower query as a result, may have to query multiple DNS authoritative servers to get the result.
A DNS record has a TTL value, this value in seconds is how long it should be cached for, we assume it is been honoured.
If another lookup is done before the TTL hits 0, then the cached result is served with no upstream requests required.
When TTL hits 0, it expires from the cache and the next lookup will need upstream queries.
With prefetch it is similar except if the client requests a DNS record and the TTL is under 10% of time remaining, then the cached result will be served, but also the forwarder/cache will do another upstream request in the background to repopulate the cache with the full TTL again, making it more likely the next request will hit a cached result.
With serve-expired, the record will stay in the cache even when TTL has hit 0, the first request after this event will be served from the cache with no delay, but it will trigger the cache/forwarder to do a background request upstream to fetch a fresh result to repopulate the cache and reset the TTL. This pretty much ensures you always get some kind of cached results, in newer versions of unbound this feature has been expanded now that it can also serve cached results if the upstream DNS server fails to respond.
As an example my firewall (pfsense) runs unbound DNS resolver, it has both prefetch and serve-expired enabled, all my LAN dns queries go via this resolver, even if an app/software tries to hardcode a different DNS server, I have a firewall rule that forcefully redirects DNS queries to my LAN's DNS resolver. Browser's and operating systems often also have their own cache systems, to mitigate DNS latency, but if these are empty, and they will be often as many DNS records now only have TTL of under 30 seconds, then the cache will be hit on my firewall and DNS results served without going out to the internet. If queries do go upstream, my upstream DNS servers are private one's run by myself over dnscrypt so my isp (sky) cannot sniff my DNS traffic, and as backup I use DNS over TLS 1.1.1.1 (cloudflare) public DNS service.
I would be surprised if google, cloudflare etc. dont employ any of these techniques on their own DNS forwarders.
But what limits the number of calls on through to the authoritative server?
Well for a start, I think prefetch was deliberately designed to only work if someone requests inside that 10% TTL expiry window, for the purpose of restricting upstream requests, if prefetch was proactive and constantly auto refreshing cache, then yes you might consider that excessive requests.
Generally speaking a higher TTL value decreases DNS traffic, a decade ago, it was normal for a DNS record to have a TTL of at least 2 hours, not too uncommon for it to even be 24 hours. But now in the world of geo routing, ddos, and load balancing the fashion is extremely low expiries so traffic can be rerouted quickly if required. This inevitably increase traffic to authoritive servers, and if the admin's are making these decisions it is a reasonable assumption to make they are ensuring their DNS authoritative servers are capable of handling the load.
But one of the most popular DNS servers (bind), as an example is able to rate limit queries, so you can e.g. only allow an ip or an ip block only do X amount of queries per Y seconds. If the limit is exceeded they get blocked. You can also add multiple extra authoritative servers to lower the load for each individual server.
-
Thank you so much for your generous and extremely helpful reply. So it sounds like my idea was indeed a good one, in fact so much so that someone has already implemented it, but in my ignorance, I did not know this.
I need to clarify, as I am not understanding some crucial bits. Is ‘prefetch’ a certain service in an api of a certain software component? Or is it a feature of a certain protocol? You see, I am so deeply ignorant that I do not even know these basics, and I am very eager to learn. You mentioned certain dns server implementations, certain software products. Am I to understand that the availability of these excellent facilities/features depends very much on the choice of DNS server?