14 ms·
DNS Push Notifications
- osrec 6y agoA question for anyone with more knowledge: does this circumvent the need for a TTL on DNS records?
- jeffalyanak 6y agoUnless 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.
- philsnow 6y agoThey'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.
- oefrha 6y ago1. 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 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 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.
- reiketsuu 6y agoThen does anyone understand what are differences between push notifications and using a record until the TTL expires? Thanks!
- Randor 6y agoAfter 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-message https://www.rfc-editor.org/rfc/rfc8765.html#name-push-messag... That section contains most of the RRset remove notifications.
- rhizome 6y agoTTL 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.
- deleted 6y ago[deleted]
- oefrha 6y agoHTML version with a TOC sidebar for easier navigation: https://www.rfc-editor.org/rfc/rfc8765.html https://www.rfc-editor.org/rfc/rfc8765.html
- twic 6y ago> The DNS Long-Lived Queries (LLQ) mechanism [RFC8764] is an existing deployed solution to provide asynchronous change notifications; it was used by Apple's Back to My Mac [RFC6281] service introduced in Mac OS X 10.5 Leopard in 2007. Back to My Mac was designed in an era when the data center operations staff asserted that it was impossible for a server to handle large numbers of TCP connections, even if those connections carried very little traffic and spent most of their time idle. Consequently, LLQ was defined as a UDP-based protocol, effectively replicating much of TCP's connection state management logic in user space and creating its own imitation of existing TCP features like flow control, reliability, and the three-way handshake. I can't help but hear the skepticism in "asserted"! Also, fun that Apple want to move a service from UDP to TCP at a time when Google are trying to move another service from TCP to UDP.
- jeffbee 6y agoIt’s still tricky to handle more than, say, a million or so TCP connections per box, but moving the connections to UDP with TCP-like state machine in user-space solves none of the issues.
- VWWHFSfQ 6y agoyeah really, aren't you just moving the buffers that track the TCP connection states from the kernel to some program in user space? how does that solve anything
- YarickR2 6y agomemory management techniques in userspace are much more diverse, you can reuse RAM efficiently.
- toast0 6y agoIt depends on how TCP like you end up being. In TCP, all outgoing data is stored for retransmit if not acked; in this application, a server wouldn't need its responses acked or stored (if the client doesn't get the response, it will resend the request), and push messages could be regenerated if not acked, rather than stored and retransmitted as-is. That reduction in required storage could be significant. User space connection tracking might also use less memory than kernel connection tracking, depending on how many non-essential things each implementation tracks. Colocation of the connection tracking data and the application level data might be beneficial as well. I didn't read the prior RFCs to see what kind of hoops they jumped to make the connections long lived though, my guess is TCP session timeouts for NAT boxes are longer than UDP, and there are more networks that disallow UDP than TCP, so TCP is probably a good idea from that standpoint.
- yingw787 6y agoWhat’s the difference between this and server sent events in http2? You don’t need a live persistent connection to issue events?
- underdeserver 6y agoWell, you can listen on UDP (which DNS uses anyway).
- WatchDog 6y agoThis proposal requires TCP.
- yingw787 6y agoThe more I think about this the less it makes sense to me. My understanding of UDP is it's supposed to be for heavy, lossy traffic where late traffic is pointless or harmful (like video streaming frames, if your frame is late better toss it out than keep it). But I kind of want my notifications even if they're late. I think I'm missing something in my understanding. I was thinking if you can stream using DNS, and cut out something like Kafka, that might be a big deal, but on second thought it doesn't make sense because DNS is more about service discovery than it is about piping load; you want an alias to a server that does the heavy lifting. Brain messy today.
- fanf2 6y agoI would be interested to of any implementation of these protocol extensions outside Apple.
- annaaa6 6y agoHi My hot photos are here... http://69-chat.club http://69-chat.club My nickname annaxx
- linsomniac 6y agoDoes anyone know what mechanism is used between Route 53 and Google DNS? When I update a record in Route 53, there seems to be 0 delay in the updated records being present in 8.8.8.8, even if I've recently request the old value. I've been imagining that they had set up some sort of "cache invalidate" message that AWS could send Google, but I haven't done any investigation.
- LorenzA 6y agoyou can do this also yourself @ https://developers.google.com/speed/public-dns/cache https://developers.google.com/speed/public-dns/cache
- ryanjkirk 6y agoalso https://1.1.1.1/purge-cache/ https://1.1.1.1/purge-cache/ for cloudfare.
- jasonjayr 6y ago8.8.8.8 is a bunch of servers, and you may be getting different server to service your request than the one that cached your recently requested old value. Make several requests, and observe the TTL -- you may notice that it jumps around as you get different servers, especially if you space your requests apart a few seconds.
- runjake 6y agoSpecifically, 8.8.8.8 is an AnyCast address. https://en.wikipedia.org/wiki/Anycast https://en.wikipedia.org/wiki/Anycast
- AndyMcConachie 6y agoI don't know, but it may be something like this. https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03 https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-ha...
- jrockway 6y ago
- kissgyorgy 6y agoI can instantly think of a gazzillion ways how this can be abused :D
- dpcan 6y agoGo on....
- LunaSea 6y agoDNS rebinding attacks is probably one of them.
- belorn 6y agoBrowsers will need to update their same-origin policy so that a change in IP address will block same requesting a different site under a different name.
- LunaSea 6y agoDNS rebinding attacks also work in non-browser environments like SSRF attacks.
- philsnow 6y agoThis would mean that long-lived single page web apps would need to be hard-refreshed every once in a while when, through no fault of the app developer, all the IP addresses that their domain name resolves to have rotated.
- steve76 6y agoMisuse. Tunneling data and commands over DNS to bypass firewalls What was used to resolve IPs from domains by research institutions is now used for hookups, trolling, zoom meetings and social media influencers selling herbal supplements.
- Ayesh 6y agoThis is what I immediately thought too. I don't think even NTP servers screamed this much potential for abuse by the time th standards were being drafted. However, I imagine this to use TCP and not UDP (didn't real the whole RFC yet), which mitigates some of the attacks.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- bottled_poe 6y agoHaven’t read the whole proposal, but some concerns that stand out to me are: 1 - impact on DNS system performance; and 2 - what infrastructure does this proposal rely upon?
- joshspankit 6y agoAs a methodology, push is always better than polling. Change my mind.
- wereHamster 6y agoPush requires more engineering effort to build the server-side of the system. Poll is easier to implement for consumers, and probably also easier to scale for most engineering teams (scaling a central DB is a well understood engineering problem). I agree that push is better overall, but… tradeoffs
- joshspankit 6y agoIn the real world: agreed on there being tradeoffs. But as a methodology?
- ubertaco 6y agoI mostly agree with you, but having spent a good part of my career dealing with data integration patterns, I'm all too familiar with the problem of missed messages from the consumer (or failed-to-send messages from the producer) that results in something downstream being in an incoherent state. The simplest fix for that incoherent state is often to also poll periodically, or something similar.
- joshspankit 6y agoSounds like it would share solutions with the “two generals problem”.
- jeffbee 6y agoPush can cause thundering herds while TTL expiration should occur uniformly over time.
- jedberg 6y agoYou need both for a robust system. Simple example: On system startup, a system should poll for the current config. It should keep polling every few minutes to verify that it hasn't missed any pushes. But it should also register for push notifications of config changes so it can get them faster. It should also renew its subscription if it finds that it missed an update during poling.
- Mojah 6y agoDoes this RFC just sherlock DNS Spy?
- mrpippy 6y agoThis getting released during WWDC does not feel like a coincidence. I wonder what Apple will be using it for, it’ll probably be mentioned in a session sometime this week.
- derhuerst 6y agoJust speculating here, but they still have a Back-to-my-Mac-like feature: The HomePod allows for remote access to things in your home WiFi, e.g. IoT devices. As IP addresses of home routers change often enough, this might be a use case for DNS push. Access has to work across work across carrier-grade NAT though, so they might still need more than DNS.
- m3047 6y agoThe DNS already supports NOTIFY, which is a push notification for updates to a zone (this is something set up by the operators of the auth servers, typically for mirrors/secondaries so that they know when to request a zone transfer); the alternative, polling, requests the SOA RR for a zone and compares serial numbers. Didn't give it a detailed read, but this looks like a more granular proposal, an example given being printer discovery.
- simonjgreen 6y agoLove that this is now in rfc. The benefits of caching with the benefits of zero caching.
- skissane 6y agoI see this is defined in terms of DNS over TLS over TCP. I don't see any mention of DNS over HTTPS or DNS over QUIC. Could this work with either of those?