Hacker News Reader

Comment by osrec | Hacker News Reader

A question for anyone with more knowledge: does this circumvent the need for a TTL on DNS records?

1. SOA and SRV records used for discovery have to specify TTL; Section 6.1: https://www.rfc-editor.org/rfc/rfc8765.html#section-6.1

2. A standard nonzero TTL is otherwise not very meaningful as long as subscription is active. Section 6.3.1 explains the TTL field of a PUSH message clearly: https://www.rfc-editor.org/rfc/rfc8765.html#section-6.3.1

But this mechanism does not replace normal DNS, only supplements it, so no, you probably still need to set TTL.

Unless there is another mechanism for a record to die, it'll still be important to have a TTL.

TTLs could be kept quite long, though, since they'd only be used when push updates are not occurring.

They'd also be used by any clients that don't understand DNS push notifications. That's including a lot of networking hardware, industrial hardware, medical devices, etc.

Then does anyone understand what are differences between push notifications and using a record until the TTL expires? Thanks!

After reading the spec it looks like there is alot of differences... this RFC essentially gives complete control of the resource record set lifetime to the DNS server. This would require major changes on the DNS client side.

Take a look at: https://www.rfc-editor.org/rfc/rfc8765.html#name-push-messag...

That section contains most of the RRset remove notifications.

TTL tells servers and clients in the wild how long to hold on to a query result. You'll want to set this very high if you expect a nuclear war soon. There is no push notification for this.

Push notifications occur when the primary is HUP'd or restarted, telling the secondaries to pull fresh zones so that everybody's is known to have the same serial. After this the secondaries poll the primary every 'refesh' seconds to check for a newer copy of the zone.

Reply on news.ycombinator.com