3 ms·

That's right: you can either run your DNS query against a (frequently automatically configured) resolver that will pursue the query on your behalf up to the aut

by ryandv 2y ago

That's right: you can either run your DNS query against a (frequently automatically configured) resolver that will pursue the query on your behalf up to the authoritative nameserver declared in the NS record and have that resolver cache the authoritative or "real" response returned by that nameserver (hopefully) according to the TTL specified in the answer, potentially receiving stale answers on subsequent requeries if the authoritative record changes before the resolver's cache expires; or directly query the authoritative nameserver yourself to get the most up-to-date answer without having to wait for the resolver's caches to expire. In the former case you may get a stale answer, up to the (possibly nonconformant) caching behaviour of the resolver and how long the cached value has left to live; in the latter case you are probably assured to receive the most up-to-date answer for that record.

mercora 2y ago
The recursive resolver you describe would adhere to the same TTL as would do any reasonable public resolver. The difference in cache behaviour, if any, only depends on if the resolver already has a cached record that's still valid or doesn't have it. That it won't have it just happens to be more likely as the amount of requests your resolver received is smaller as the case if you are it's sole user. It's possible to force the behaviour you described by using specialised tools that are meant to be used for analysis like binds dig utility with its trace flag. It can bypass any resolver by querying up from the root servers to the designated label without any caches being involved. You still only will know that other resolvers will receive the desired answer eventually. Only safe bet is to assume it will take the TTL until every will receive the updated record.
- ryandv 2y ago
  That's correct, "directly query the authoritative nameserver yourself" is precisely what dig +trace does. > You still only will know that other resolvers will receive the desired answer eventually. That's also correct. DNS is an eventually consistent system where if you stop updating the authoritative records, all resolvers will eventually converge to the latest answer once their cached records expire (presuming that they actually respect the cached records' TTLs as expected).

by ryandv 2y ago

mercora 2y ago

The recursive resolver you describe would adhere to the same TTL as would do any reasonable public resolver. The difference in cache behaviour, if any, only depends on if the resolver already has a cached record that's still valid or doesn't have it. That it won't have it just happens to be more likely as the amount of requests your resolver received is smaller as the case if you are it's sole user. It's possible to force the behaviour you described by using specialised tools that are meant to be used for analysis like binds dig utility with its trace flag. It can bypass any resolver by querying up from the root servers to the designated label without any caches being involved. You still only will know that other resolvers will receive the desired answer eventually. Only safe bet is to assume it will take the TTL until every will receive the updated record.

ryandv 2y ago
That's correct, "directly query the authoritative nameserver yourself" is precisely what dig +trace does. > You still only will know that other resolvers will receive the desired answer eventually. That's also correct. DNS is an eventually consistent system where if you stop updating the authoritative records, all resolvers will eventually converge to the latest answer once their cached records expire (presuming that they actually respect the cached records' TTLs as expected).