3 ms·
> aren't DNS queries a drop in the bucket compared to the size of most web pages anyway? The client needs to wait for the result of a DNS query before it can d
by yarcob 6y ago
> aren't DNS queries a drop in the bucket compared to the size of most web pages anyway?
The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay.
Usually DNS queries are cached by a server near the user, so they are very fast. But if the authoritative name server has a very short TTL, then those cached results will often be stale, and the name server has to resolve the name recursively, which can be slow.
- hiq 6y ago> The client needs to wait for the result of a DNS query before it can do anything else. The bandwidth is irrelevant, the problem is the delay. You're right. But the article seems to claim the number of queries can be reduced with a higher TTL, which is why these should be enforced. Fair enough, but so what? In any case, the TTL is irrelevant for the first query. For the next ones, if you allow yourself to rely on the previous result (the "soft-invalidation" I mentioned, for lack of a better word), it shouldn't have any impact for the user.
- yarcob 6y ago> TTL is irrelevant for the first query With a long TTL, the chances are higher that your router or your ISP has the name cached. Round trip to your ISP is very short. If you have a short TTL, the ISPs name server may have to query the next server in the chain. If the authoritative name server is 10000km away, that means at least 60ms extra round trip time (speed of light).