Hi Joe and others, Let me try to respond to several comments in one place.
1. On “knowing your parent”. I agree with Joe, in general a child is ignorant of its parent. And while there are methods like the one Mark describes that usually work there are certainly corners where they don’t. Horrible stuff like forwarding configs where folks synthesise a child unknown to the parent comes to mind. However, without claiming that I’ve done any kind of exhaustive inventory of these corners I will argue that they are among the least likely places to deploy DNSSEC in general and even if they do deploy DNSSEC the parent CDS scanner is likely to also have issues. But, for the sake of argument, lets assume that a broken corner, having deployed DNSSEC and with a parent doing CDS/CSYNC scanning is unable to figure out the parent and therefore not send these notifies. I think that’s ok. They will just have to untangle their corner or wait for the next regular scan. 2. On using UPDATE vs NOTIFY: Joe wrote (in response to Mark suggesting UPDATE): Sending a signal that the parent should investigate the child is nice because it limits the range of unpleasant consequences that might result of the signal not being authentic or of the target not being the right one. The worst that can happen is that the signal doesn't arrive or that the recipient is too busy to deal with it. In this context sending something like an UPDATE seems less nice. This is exactly my view, too. Another issue with UPDATE is that the parent (especially in the case of TLD registries) often has a strong opinion on owning the decision of making changes to the zone content. With a NOTIFY the child is maintaining exactly the same relationship with the parent as with only CDS/CSYNC, but if we switched to using UPDATE that relationship changes completely. 3. Olafur wrote: #1 this should cover normal notify as well as there is no reason parent should have to be updates every time an external DNS provider changes its distribution "top" I don’t understand what you’re saying here. Sorry. #2 I would love the examples to use a different port than 53 as there is no need for the notifies to go to that overloaded port I agree. #3 As of new type vs SRV the argument against new type at apex is always size of ANY, which I do not buy but I like new types :-) We are not suggesting that the notification address is published at the APEX, regardless of whether SRV or a new RR type us used. That said, I also like new types 😊 #4 It should be clear that there is no need to run a "nameserver code" as the target of the NOTIFY messages, similarly there is no real reason why the issuer of the Notify is a "nameserver code" i.e. both of ends are front/back ends of provision systems I agree. And not using port 53 would help with that signaling. 4. Paul wrote: The main concern at the time was they TLDs didn’t want any kind of triggers hitting their production nameservers. As having been responsible for a global anycast network for many years I obviously agree with this. But, as I think someone already pointed out, we specifically choose to avoid that by publishing information about where to send notifications. Of course, the CDS scanner is also a production system, so if a parent, like a TLD, doesn’t want notifications to hit the scanner infrastructure then they will just (assuming they want to improve service to their registrants) have to choose another notification address. 5. Joe wrote: How often do you send a NOTIFY, given that the action triggered (or not) is expected to be asynchronous? Should the draft say something about retrying? If widely deployed this mechanism has the potential to deliver a lot of traffic to a small number of targets (e.g. if this was supprted by a zone with lots of children like COM). Retries would amplify the traffic volume. We pondered this a bit and decided to leave it out of the initial draft, awaiting this discussion. My personal view is that as NOTIFY does generate a response (or at least should generate a response) the best way of dealing with retries is probably to just examine the response that the child gets back from the parent: NOERROR: all is great, the notification has been noted, FWIW, there is no need to resend. REFUSED: please don’t send any more notifications here as I’m probably a misconfigured parent. And of course, the important case of no response at all to the NOTIFY… which likely should trigger a retry. The normal behavior for NOTIFY(SOA) is trying three times if I remember correctly. But, on the topic of traffic volume, please note that there are two possible benefits to a parent listening to NOTIFY(CDS) and NOTIFY(CSYNC). One is to provide an improved service to the child. The other is that, given the usually extremely low frequency of “hits” to the scanner, the traffic generated by the scanner is most likely many orders of magnitude higher than the traffic generated by the notifications. Hence, if you want to improve the traffic volume (as a parent), then implement support for NOTIFY(CDS) and NOTIFY(CSYNC), wait a bit for children to implement this, and then decrease the scanning frequency. Hopefully by a lot. 6. Mark wrote: Separately, it might be worth specifying that all NOTIFY targets obtained through the DNS MUST be subject to DNSSEC validation and that the DNS responses involved must be verifiably secure. I can't immediately think of an exploit that would derive from the ability for a third party to receive such NOTIFY messages but it seems entirely plausible that there is one. I agree. 7. Mark wrote: In the case of conventional use of NOTIFY it's common for the NOTIFY/*XFR graph to involve servers other than those published in NS sets. In some cases it is desirable for the identity of those NOTIFY targets not to be published, e.g. since they refer to internal infrastructure and are not intended to be used/abused by others. Have you thought about whether there are any similar considerations for these new uses of NOTIFY? I guess one answer is that (just like conventional NOTIFY) local policy could override the SRV-published (NS-published) targets. My view: I don’t like the “local policy overrides” alternative. Eg., if .SE publishes a desire to receive NOTIFY(CDS) at a particular address, then that’s where we want them. Full stop. But, again using .SE as an example, we (and our service providers) have lots of internal infrastructure that we don’t want to have abused. But publishing the desired target where we *want* to have the notifications completely alleviates this issue as far as I understand. I hope I managed to get all your comments. If not, my apologies. I appreciate that so many people chose to spend time on our draft so quickly. Thanks. Regards, Johan PS. Joe wrote: I have wondered aloud about reusing NOTIFY for other purposes in the past too. In fact I seem to remember a certain tall Swede referring to draft-jabley-dnsop-dns-flush as abolutely the worst idea he had ever heard of, a review which I continue to wear as a badge of pride. This is still the absolutely worst idea I’ve ever heard of. I’m so proud of you. 😊
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
