3 ms·

The problem is that the DNS TTL is a feature designed for a static internet of the 70's or 80's. What this points to is a need for an authenticated DNS pushes

The problem is that the DNS TTL is a feature designed for a static internet of the 70's or 80's. What this points to is a need for an authenticated DNS pushes for refresh/invalidation. All supporting resolvers could keep a list of supporting clients that were told that "foo is at address 42". If the record changes, the authoritative DNS server sends a DNSSEC signed unsolicited response to all previous requesters to update their records. Obviously the TTL can be extended to keep the cache of requestor IPs reasonably sized. Will this happen? Well, for UDP DNS it depends on DNSSEC, which is already not well supported, and it fixes something that is broken but not terribly so. One could imagine Google arranging this between its DNS resolvers and Chrome, for instance. For DNS over HTTPS, this becomes much more feasible.

topranks 6y ago
That is an insane amount of state for auth dns servers to maintain. “Pushing” the message out that the record has changed would also prove tricky to implement I’d say.
- avidiax 6y ago
  Worst case, 2^32 bits is 500MB. If you think that you'll get less than 134 million distinct queries, a simple list or a sparse array may be better. Obviously you need one of these bitmaps for every change domain (i.e. 1 per zone, or 1 per A/AAAA/CNAME record set, operator choice), and you need to clear it every (extended) TTL. So a CDN with 100,000 dynamic IP records might split themselves into 1,000 change domains of 100 records each, have a 1 hour TTL (expiry's staggered), and use 500GB ram to do this.
  - znpy 6y ago
    so that also means that the client has to be kept connected to the dns server ? if so, that's a nice spot for user tracking. if not, how do you push data to clients behind a nat, without a stateful and persistant tcp connection? for most dns queries udp is sufficient (although sometimes tcp is necessary). 500GB ram for 100k records seems quite a lot btw.
sondel 6y ago
What you're describing is somewhat like DNS Push Notifications (RFC 8765): https://tools.ietf.org/html/rfc8765 https://tools.ietf.org/html/rfc8765

topranks 6y ago

That is an insane amount of state for auth dns servers to maintain. “Pushing” the message out that the record has changed would also prove tricky to implement I’d say.

avidiax 6y ago
Worst case, 2^32 bits is 500MB. If you think that you'll get less than 134 million distinct queries, a simple list or a sparse array may be better. Obviously you need one of these bitmaps for every change domain (i.e. 1 per zone, or 1 per A/AAAA/CNAME record set, operator choice), and you need to clear it every (extended) TTL. So a CDN with 100,000 dynamic IP records might split themselves into 1,000 change domains of 100 records each, have a 1 hour TTL (expiry's staggered), and use 500GB ram to do this.
- znpy 6y ago
  so that also means that the client has to be kept connected to the dns server ? if so, that's a nice spot for user tracking. if not, how do you push data to clients behind a nat, without a stateful and persistant tcp connection? for most dns queries udp is sufficient (although sometimes tcp is necessary). 500GB ram for 100k records seems quite a lot btw.

sondel 6y ago

What you're describing is somewhat like DNS Push Notifications (RFC 8765): https://tools.ietf.org/html/rfc8765 https://tools.ietf.org/html/rfc8765