Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
It appears that Peter Thomassen said: >Hi John, > >On 6/20/23 20:27, John Levine wrote: >> It appears that Peter Thomassen said: >Do you mean that there needs to be a way for registrars to tell a registry >what their NOTIFY listening endpoint is? > >EPP, to my knowledge, is for management of domain registrations, while that >endpoint is a global property ... Good point. They'd still need to invent something to manage the endpoints, and there's the painful ICANN process to allow putting anything new in the TLD zone file. >>> How would a random DNS operator know the registrar of their customer zones? >>> How would they learn when it changes? >> >> They'd ask the customer "who's your registrar" when they set up the >> zone. > >Ah, but then that's not what we're trying to do, which is improving CDS >processing. So far, it's done via CDS scanning which does not >involve the registrant but is automatic (that's already in the title of RFC >7344). > >Unfortunately, the timing of the scanning queries does not align well with >when a CDS change is actually happening. This is precisely the same situation we have always had with zone updates and AXFR. If you don't care how fast your secondaries sync, you can just wait for them to scan for SOA changes. If you do care, you figure out where to send the NOTIFY messages. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
Hi John, On 6/20/23 20:27, John Levine wrote: It appears that Peter Thomassen said: My take is that the parent should create a _signal subdomain (preferably as a delegation). The per-child target can be queried by prepending, e.g. _notify.example._signal.parent. IN NOTIFY CDS scheme port scanner.registrar.example. This way, the parent can announce the registrar's NOTIFY endpoint. This can be synthesized dynamically, no need to maintain a large zone. As _signal can be delegated, only one (rather normal) NS RRset is required in the parent, and the magic can be done on a different nameserver. While I can see how that might work in principle, I find it hard to imagine registries and registrars making it work. At the least it'd need new EPP stuff to tell the registry what signal records to add or delete. Do you mean that there needs to be a way for registrars to tell a registry what their NOTIFY listening endpoint is? EPP, to my knowledge, is for management of domain registrations, while that endpoint is a global property of the registrar's account with the registry. It need not necessarily be conveyed via EPP: one could use whatever other channel is available for account changes. I guess there would usually be a web portal for filling in details like your EPP client net ranges, billing details, tax number etc. It would be really interesting to hear from a registry. I'll reach out to some and try to figure out what they think. I guess if the targets are fairly static, then putting it in the configuration rather than sticking it in the DNS will be good enough. How would a random DNS operator know the registrar of their customer zones? How would they learn when it changes? They'd ask the customer "who's your registrar" when they set up the zone. Ah, but then that's not what we're trying to do, which is improving CDS processing. So far, it's done via CDS scanning which does not involve the registrant but is automatic (that's already in the title of RFC 7344). Unfortunately, the timing of the scanning queries does not align well with when a CDS change is actually happening. The NOTIFY mechanism is trying to improve on that, but without turning the automated method back into one that requires manual steps by the customer. If the customer changes registrars, they have to tell the DNS operator I wouldn't bet that this wouldn't be forgotten except for < 10% of cases. Realistically, the DNS operator would have to ask again -- but how would they know when it would be good to ask? Perhaps the DNS operator could ask daily *scnr* Cheers, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
It appears that Peter Thomassen said: >My take is that the parent should create a _signal subdomain (preferably as a >delegation). The per-child target can be queried by prepending, e.g. > > _notify.example._signal.parent. IN NOTIFY CDS scheme port > scanner.registrar.example. > >This way, the parent can announce the registrar's NOTIFY endpoint. This can be >synthesized dynamically, no need to maintain a large zone. >As _signal can be delegated, only one (rather normal) NS RRset is required in >the parent, and the magic can be done on a different >nameserver. While I can see how that might work in principle, I find it hard to imagine registries and registrars making it work. At the least it'd need new EPP stuff to tell the registry what signal records to add or delete. >> I guess if the targets are fairly static, then putting it in the >> configuration rather than sticking it in the DNS will be good enough. > >How would a random DNS operator know the registrar of their customer zones? >How would they learn when it changes? They'd ask the customer "who's your registrar" when they set up the zone. This still misses the hard part about how the notify knows where to expect the notifies from. I suppose by default it could be the delegated NS, but in interestingly large setups, that's not likely to be adequate. If the customer changes registrars, they have to tell the DNS operator but that's easier than the current hacks to try and move DS records from one registrar to another. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On 6/20/23 17:48, Paul Wouters wrote: I like this draft because of it tackles the issues of wasteful CDS polling and it uses NOTIFY, a mechanism that is well known, already exists in implementations, and actually feels like a good fit (as opposed to overloading). Agreed. That's not what the TLDs said during "timers vs triggers". They did not want NOTIFY's towards their production nameservers. The draft does not propose that. That might have changed, but I would like to hear from the big TLDs that they are now in favour of this and would deploy. The drive is this time not coming from the parent side, but from discussions around DS automation at recent ICANN DNSSEC workshops, and DNSSEC multi-signer scenarios. The main two arguments made there were scaling concerns for large parent zones (although I don't think these concerns are supported by data), and better predictability (for child-side entities) of when C* records can be expected to be discovered and processed. It would indeed be interesting to learn what TLD registries have to say, specifically those who already have quite advanced CDS scanners (e.g. SWITCH, who also have implemented authenticated bootstrapping). If not, perhaps a level of indirection via service record should be used to point to a specific server (which could still accept NOTIFY) outside of the parental NS RRset. That's the point of the NOTIFY record (whose field list may be reduced, perhaps eventually to a CNAME, see other postings). Also the registrars did not like being circumvented. While now some registars might have changed their mind (or don't care since they are both registrar and dns hosting for most of their domains), it would be good to hear from them. Agreed; there are various good arguments for why the scanning should be done by the registrar (if there is one). But I don't see why this would be a problem with regards to NOTIFY (we can make it work by prepending the child label to the service record qname). Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On 6/20/23 17:51, Paul Wouters wrote: parent. IN NOTIFY CDS scheme port scanner.parent. Why a new RRtype ? Why more stuff in the APEX? Why not: _notify_cds.parent. IN CNAME targetservice.parent. targetservice.parent. IN A . targetservice.parent. IN . Personally, I'm fine with simplifying to your approach; I would only add the child label prefix to allow for per-child flexibility (and if you don't need that, just set a wildcard). The authors' thinking was that a new record type would allow both specifying the port and a scheme field, anticipating that people might appreciate flexibility for future mechanisms and stir discussion about that. But if it's not needed -- the simpler the better! Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On Tue, 20 Jun 2023, Matthijs Mekking wrote: If there are different targets for different children of the same parent, then a generic NOTIFY record like below won't work anyway. parent. IN NOTIFY CDS scheme port scanner.parent. Why a new RRtype ? Why more stuff in the APEX? Why not: _notify_cds.parent. IN CNAME targetservice.parent. targetservice.parent. IN A . targetservice.parent. IN . I guess if the targets are fairly static, then putting it in the configuration rather than sticking it in the DNS will be good enough. I would like to not ship such hardcoded lists with my OS :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On Tue, 20 Jun 2023, John Levine wrote: It appears that Matthijs Mekking said: Hi, I like this draft because of it tackles the issues of wasteful CDS polling and it uses NOTIFY, a mechanism that is well known, already exists in implementations, and actually feels like a good fit (as opposed to overloading). Agreed. That's not what the TLDs said during "timers vs triggers". They did not want NOTIFY's towards their production nameservers. That might have changed, but I would like to hear from the big TLDs that they are now in favour of this and would deploy. If not, perhaps a level of indirection via service record should be used to point to a specific server (which could still accept NOTIFY) outside of the parental NS RRset. Also the registrars did not like being circumvented. While now some registars might have changed their mind (or don't care since they are both registrar and dns hosting for most of their domains), it would be good to hear from them. A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. The DNS hoster needs to reach the DNS parent. Why wouldn't the parent, eg via a single service record, have a service suitable for all of its children? The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. So you now have 2 half problems? TLDs need (AFAIK from previous discussion) a way to receive NOTIFYs that's not on the IPs of their NS RRset. Let's give them one. I don't think an ACL is needed, just a rate limit to block abusive IP blocks should be enough? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
Hi, On 6/20/23 17:37, Matthijs Mekking wrote: A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. If there are different targets for different children of the same parent, then a generic NOTIFY record like below won't work anyway. parent. IN NOTIFY CDS scheme port scanner.parent. My take is that the parent should create a _signal subdomain (preferably as a delegation). The per-child target can be queried by prepending, e.g. _notify.example._signal.parent. IN NOTIFY CDS scheme port scanner.registrar.example. This way, the parent can announce the registrar's NOTIFY endpoint. This can be synthesized dynamically, no need to maintain a large zone. As _signal can be delegated, only one (rather normal) NS RRset is required in the parent, and the magic can be done on a different nameserver. Alternatively, the parent can deploy a static wildcard: *._signal.parent. IN NOTIFY CDS scheme scanner.parent. That would be a very small, static zone. This applies when the parent does the scanning themself, or when they want to forward the NOTIFY to the registrar behind the scenes. (I'm not saying this should be done; I'm saying that this method is suitable for all kinds of scenarios.) The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. I guess if the targets are fairly static, then putting it in the configuration rather than sticking it in the DNS will be good enough. How would a random DNS operator know the registrar of their customer zones? How would they learn when it changes? Cheers, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On 6/20/23 17:14, John Levine wrote: It appears that Matthijs Mekking said: Hi, I like this draft because of it tackles the issues of wasteful CDS polling and it uses NOTIFY, a mechanism that is well known, already exists in implementations, and actually feels like a good fit (as opposed to overloading). Agreed. A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. If there are different targets for different children of the same parent, then a generic NOTIFY record like below won't work anyway. parent. IN NOTIFY CDS scheme port scanner.parent. The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. I guess if the targets are fairly static, then putting it in the configuration rather than sticking it in the DNS will be good enough. Matthijs R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
It appears that Matthijs Mekking said: >Hi, > >I like this draft because of it tackles the issues of wasteful CDS >polling and it uses NOTIFY, a mechanism that is well known, already >exists in implementations, and actually feels like a good fit (as >opposed to overloading). Agreed. >A note on where to send CDS and CSYNC notifications. I sort of >understand why the NOTIFY record includes a RRtype field, but will >parental entities really have a different target for receiving notifies >for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
Hi, I like this draft because of it tackles the issues of wasteful CDS polling and it uses NOTIFY, a mechanism that is well known, already exists in implementations, and actually feels like a good fit (as opposed to overloading). A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? For the sender of the notifies, this may be cumbersome to do different lookups that probably end up being the same target. Related to this, when it comes to the multi-signer model, you do not only need to send DNSKEY notifications, but also CDS and CSYNC notifications to the other signers, especially if you want these RRsets to be consistent with each other. Follwing up on the example in Section 5.1 that would mean we need additional NOTIFY records: child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerA. child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerB. child.parent. IN NOTIFY DNSKEY 1 5361 ctrl.multi-signer.example. child.parent. IN NOTIFY CDS 1 5361 scanner.signerA. child.parent. IN NOTIFY CDS 1 5361 scanner.signerB. child.parent. IN NOTIFY CDS 1 5361 ctrl.multi-signer.example. child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerA. child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerB. child.parent. IN NOTIFY CSYNC 1 5361 ctrl.multi-signer.example. That becomes quite a set already. Perhaps we should differentiate on type of server (parent, signer, ...) rather than RRtype? Finally, about the open question for DNSKEY notifications. You say: As the number of signers for a particular zone is low, there is no major problem caused by not knowing which signer sent the notification and instead always check all the signers for updates to the DNSKEY RRset. How would you identify which is the newer DNSKEY RRset? If the multi-signer controller checks two signers and receives the following RRsets: example.nl. 3600 IN DNSKEY 257 3 13 I5Cq... example.nl. 3600 IN DNSKEY 257 3 13 Hkpb... example.nl. 3600 IN DNSKEY 257 3 13 I5Cq... example.nl. 3600 IN DNSKEY 257 3 13 Hkpb... example.nl. 3600 IN DNSKEY 257 3 13 1Wut... How would it know if a DNSKEY was added or removed from the RRset. This obviously requires some state. And I suspect it works slightly different again in a decentralized model. This likely can all be solved, but it needs to be specified, and cannot be dismissed as "probably not a major problem". Best regards, Matthijs On 2/20/23 13:20, Peter Thomassen wrote: Dear DNSOP, Thank you for the very helpful feedback provided by several people on the -00 revision back in November. Johan and I made changes to the document that incorporate the insights from the crowd, and resolved some other issues. The result is -01, attached below. If you are interested, please take a read. We're looking forward to further feedback here and/or at IETF 116. Thanks! Best, Peter Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-generalized-dns-notify-01.txt Date: Fri, 10 Feb 2023 08:25:23 -0800 From: internet-dra...@ietf.org To: Johan Stenstam , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-01.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-generalized-dns-notify Revision: 01 Title: Generalized DNS Notifications Document date: 2023-02-10 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.txt Status: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ Html: https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify Diff: https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-generalized-dns-notify-01 Abstract: Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation maintenance are usually detected through scheduled scans run by the consuming party (e.g. top-level domain registry), incurring an uncomfortable trade-off between scanning cost and update latency. A similar problem exists when scheduling zone transfers, and has been solved using the well-known DNS NOTIFY mechanism ([RFC1996]). This mechanism enables a primary nameserver to proactively inform secondaries about zone changes, allowing the secondary to initiate an ad-hoc transfer independently of when the next SOA check would be due. This document extends the use of DNS NOTIFY beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC
[DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
Dear DNSOP, Thank you for the very helpful feedback provided by several people on the -00 revision back in November. Johan and I made changes to the document that incorporate the insights from the crowd, and resolved some other issues. The result is -01, attached below. If you are interested, please take a read. We're looking forward to further feedback here and/or at IETF 116. Thanks! Best, Peter Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-generalized-dns-notify-01.txt Date: Fri, 10 Feb 2023 08:25:23 -0800 From: internet-dra...@ietf.org To: Johan Stenstam , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-01.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-generalized-dns-notify Revision: 01 Title: Generalized DNS Notifications Document date: 2023-02-10 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.txt Status: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ Html: https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify Diff: https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-generalized-dns-notify-01 Abstract: Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation maintenance are usually detected through scheduled scans run by the consuming party (e.g. top-level domain registry), incurring an uncomfortable trade-off between scanning cost and update latency. A similar problem exists when scheduling zone transfers, and has been solved using the well-known DNS NOTIFY mechanism ([RFC1996]). This mechanism enables a primary nameserver to proactively inform secondaries about zone changes, allowing the secondary to initiate an ad-hoc transfer independently of when the next SOA check would be due. This document extends the use of DNS NOTIFY beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC key rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY) messages, and quicker changes to a delegation's NS record set via NOTIFY(CSYNC) messages. Furthermore, this document proposes a new DNS record type, tentatively referred to as "NOTIFY record", which is used to publish details about where generalized notifications should be sent. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-thomassen-dnsop-generalized- dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop- generalized-dns-notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
