3 ms·

For some purpose it's also possible to explicitly make a DNS request against the authoritative server (which you get from the NS record) to have an actual insta

by p4bl0 2y ago

For some purpose it's also possible to explicitly make a DNS request against the authoritative server (which you get from the NS record) to have an actual instantly up-to-date answer. That's how certbot and other Let's Encrypt clients work when using the DNS verification method rather than the HTTP one (using /.well-known/…), which you need to do for wildcard certificate for example. It allows verification of the _acme-challenge TXT record instantly after the update during the certificate renewal procedure.

deleted 2y ago
[deleted]
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).
obscuretone 2y ago
How slow is this? I need to get around to making a new pihole. My last one did it over tor and wasn’t noticeably slow

by p4bl0 2y ago

deleted 2y ago

[deleted]

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).

obscuretone 2y ago

How slow is this? I need to get around to making a new pihole. My last one did it over tor and wasn’t noticeably slow