[DNSOP] DRAFT Agenda for IETF118 DNSOP Sessions
All, We've uploaded a draft agenda for IETF118, but we do feel we could use some guidance from the working group. We did ask folks if they had conflicts with either session, and we've had a few specific requests for Tuesday, including one document marked For Consideration. We also tentatively scheduled 10 minutes for Hackathon discussions, but we have not talked with anyone involved with the Hackathon (such as Petr). We'll work with them on this. Please send us feedback updates, etc. thanks Tim for Benno/Suzanne # DNS Operations (DNSOP) Working Group ## IETF 118 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Twitter ietf_wg_dnsop](https://twitter.com/ietf_wg_dnsop) * [Mastodont @ietf_wg_dn...@hachyderm.io](https://hachyderm.io/@ietf_wg_dnsop) ## Session I * Date: November 7, 2023 * Time: 1700-1800 CET (1600-1700 UTC) * Room: Congress Hall 3 * [MeetEcho](https://meetings.conf.meetecho.com/ietf118/?session=31560) * [OnSiteTool](https://meetings.conf.meetecho.com/onsite118/?session=31560) * [Minutes](https://notes.ietf.org/notes-ietf-118-dnsop) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Upload Slides](https://datatracker.ietf.org/meeting/118/session/31560/slides) ## Agenda ### Administrivia * Updates of Old Work, Chairs, 10 min * Hackathon Results, Tentative, 10 min ### Current Working Group Business * draft-ietf-dnsop-domain-verification-techniques - https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ - Shumon Huque, , 15 - Remark: request for slot on Tuesday - Chairs Action: * draft-ietf-dnsop-generalized-notify - https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/ - Peter Thomassen, , 20 - Remark: request for slot on Tuesday - Chairs Action: ### For Consideration (requested due to travel schedule. open for WG discussion) * draft-many-dnsop-dns-isolated-networks - https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/ - Marc Blanchet, , 10 - Remark: request for slot on Tuesday - Chairs Action: ## Session II * Date: November 10, 2023 * Time: 09:30-11:30 CET (08:30-10:30 UTC) * Room: Congress Hall 2 * [MeetEcho](https://meetings.conf.meetecho.com/ietf118/?session=31559) * [OnSiteTool](https://meetings.conf.meetecho.com/onsite118/?session=31559) * [Minutes](https://notes.ietf.org/notes-ietf-118-dnsop) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Upload Slides](https://datatracker.ietf.org/meeting/118/session/31559/slides) ## Agenda ### Current Working Group Business * draft-ietf-dnsop-rfc8109bis - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ - Paul Hoffman, , 5 - Chairs Action: * draft-ietf-dnsop-rfc7958bis - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/ - Paul Hoffman, , 10 - Chairs Action: * draft-ietf-dnsop-compact-denial-of-existence - https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/ - Shumon Huque, , 15 - Chairs Action: * draft-ietf-dnsop-svcb-dane - https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-dane/ - Ben Schwartz, , 10 - Chairs Action: ### For Consideration * draft-homburg-dnsop-igadp - https://datatracker.ietf.org/doc/draft-homburg-dnsop-igadp/ - Philip Homburg, , 10 - Chairs Action: * draft-peltan-edns-presentation-format - https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/ - Libor Peltan, , 10 - Chairs Action: * draft-johani-dnsop-delegation-mgmt-via-ddns - https://datatracker.ietf.org/doc/draft-johani-dnsop-delegation-mgmt-via-ddns/ - Johan Stenstam, , 20 - Chairs Action: * draft-momoka-dnsop-3901bis - https://datatracker.ietf.org/doc/draft-momoka-dnsop-3901bis/ - Momoka Yamamoto, , 10 - Chairs Action: ### Liaison with other WGs * draft-hollenbeck-regext-epp-delete-bcp - https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/ - Scott Hollenbeck, , 10 - Chairs Action: * draft-ietf-core-dns-over-coap and draft-lenders-dns-cbor - https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/ - Martine Lenders, , 15 - Chairs Action: ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
Just picking one of these emails.
What’s all the FUD here about?
There is *nothing* new here. CPE boxes have done UPDATE to change their
addresses to *non authoritative* servers using UPDATE for at least a decade
now. DYN DNS did this. The updates used TSIG for authentication. Mac also
does this. There is a SRV prefix registered for finding the update server.
Apple registered SRV prefixes at least twice for this _dns-update._tcp,
_dns-update._udp in 2019 and there where earlier ones which I can’t find on the
current IANA website.
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=dns
This one may be a re-registration. They have also registered a one using TLS.
Using SIG(0) to update delegations has been part of the protocol since the RFC
2931 was published. The reason UPDATE has a ZONE section is to allow parent
zones to be updated. NS and glue records initially. DS once it came into
existence.
Having a update policy that allows you to update the name derived from the key
name and its children is also straight forward. The obvious one is a one to
one mapping. It was so obvious that we just implement it approximately 2
decades ago. The original policy set had “self”. We added sub domains of the
key a little later. We added record count restrictions by type later still.
commit 6e373c502584f9292e964378411d296c8259026b
Author: Mark Andrews
Date: Thu Feb 16 01:34:24 2006 +
1983. [func] Two new update policies. "selfsub" and "selfwild".
[RT #12895]
Now the only thing here is to formalise what has been supported for DECADES now
by saying everyone should JUST DO IT.
I wrote a draft in 2013
https://www.ietf.org/archive/id/draft-andrews-dnsop-update-parent-zones-04.txt
about how to do this. It used TSIG but SIG(0) works just as well. Nothing
proposed then was new.
--
Mark Andrews
> On 26 Oct 2023, at 04:21, Johan Stenstam
> wrote:
>
>
>
>> On 25 Oct 2023, at 18:58, Joe Abley wrote:
>>
>> On 25 Oct 2023, at 18:46, Johan Stenstam
>> wrote:
>>
>>> I agree. But it is bad to design a system where the key CANNOT be rolled.
>>
>> I agree. I was just expressing doubt that you can find a single automated
>> mechanism that is appropriate to use in all possible compromise scenarios.
>>
>> For a hopefully rare event that might need careful handling, perhaps a good
>> manual plan is actually better.
>
> I agree with this also.
>
> And that functionality is already there. If you’re using BIND9 it is your
> decision, in the update-policy {} section, whether to allow dynamic updates
> to update the key (i.e. roll the key) or only update NS, glue and DS RRsets.
> My own code does the same. And in most cases manual fallback in case of a key
> compromise is likely the best option.
>
> Johan
>
>
> ___
> 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] Automated delegation management via DDNS
> On 25 Oct 2023, at 18:58, Joe Abley wrote:
>
> On 25 Oct 2023, at 18:46, Johan Stenstam
> wrote:
>
>> I agree. But it is bad to design a system where the key CANNOT be rolled.
>
> I agree. I was just expressing doubt that you can find a single automated
> mechanism that is appropriate to use in all possible compromise scenarios.
>
> For a hopefully rare event that might need careful handling, perhaps a good
> manual plan is actually better.
I agree with this also.
And that functionality is already there. If you’re using BIND9 it is your
decision, in the update-policy {} section, whether to allow dynamic updates to
update the key (i.e. roll the key) or only update NS, glue and DS RRsets. My
own code does the same. And in most cases manual fallback in case of a key
compromise is likely the best option.
Johan
smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
Hi Paul, > On 25 Oct 2023, at 17:20, Paul Wouters wrote: > > On Oct 25, 2023, at 10:11, Paul Vixie > wrote: >> > > [speaking as individual] > >> i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone >> modification. perhaps propose a new RCODE having the same message form as >> UPDATE? > > I agree. To begin with, the DNS UPDATE is for the purpose of parent zone modification. Secondly, I think many people may be missing the fact that using DNS UPDATE to modify delegation information in the parent zone is not new, we’ve had this for many years. This is not in any way a change to either protocol nor implementation. BIND9 has had this functionality for many years (thanks Mark!). What this draft does is to propose a mechanism for how to locate the TARGET of the DNS UPDATE. This is needed because such information is not necessarily available across organisational boundaries. And for this the draft leverages from the mechanism proposed in the draft on generalized notifications. >>> 2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate >>> the management of delegation information for *all* zones, regardless of >>> whether the parent is signed or not, regardless of whether the child is >>> signed or not, is an advantage. >> >> some years back this working group adopted a ubiquity regime for DNSSEC in >> that all new specifications "must" expect DNSSEC to be in use and "should" >> depend on it when in-scope functionality is needed. has that changed? > > I agree here as well. The longer we pretend DNSSEC is “optional” and make DNS > the last protocol lacking simple spoof protection, the longer we put a brake > on deployment of DNSSEC. And the longer we need to write drafts hacking > around this. Assuming you consider this draft an example of “hacking around a lack of DNSSEC” I have to strongly disagree. To begin with it works equally well with or without DNSSEC. Furthermore it is a cleaner solution than what we currently have (i.e. child zone published CDS and/or CSYNC and parent at some future time will get around to scan for it). Replacing all this this with a single DNS UPDATE is something we should have (and could have) done long before either CDS or CSYNC were invented. The reason we didn’t was to some extent that we had higher hopes for DNSSEC deployment rate than were justified, but primarily that we didn’t address the question of how to figure out were to send the UPDATE when used across organisational boundaries. Now we know more about the DNSSEC deployment rate and we also have a proposal for locating the target for the UPDATE. And so this draft was born. How many parent zones do we have in the universe? Millions, most likely. How many of these parents have deployed CDS and CSYNC scanners? Perhaps a couple of dozen. Compared to the deployment rate of DNSSEC in general the deployment rate of CDS and CSYNC scanners is so completely lacking that I think we, i.e. the DNS community, should ponder the following question very seriously: Do we really think that CDS/CSYNC scanners are the only answer we need to the question of how to achieve full automation of delegation information between child and parent? If the answer is “no” then I’d love to hear more suggestions than this proposal. Regards, Johan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
On 25 Oct 2023, at 18:46, Johan Stenstam wrote: > I agree. But it is bad to design a system where the key CANNOT be rolled. I agree. I was just expressing doubt that you can find a single automated mechanism that is appropriate to use in all possible compromise scenarios. For a hopefully rare event that might need careful handling, perhaps a good manual plan is actually better? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
Hi, > On 25 Oct 2023, at 17:50, Joe Abley wrote: > > On 25 Oct 2023, at 17:31, Johan Stenstam > wrote: > >> On 25 Oct 2023, at 11:32, Joe Abley wrote: >> >>> I am not at all familiar with SIG(0), so bear with me. What is the key >>> distribution mechanism for the DNS UPDATE originator's public key? RFC 2931 >>> suggests an unsigned KEY RR, I think? >> >> My answer is “whatever mechanism the child and parent is using today for >> communicating critical information like that”. > > Isn't the usual answer to that the same kind of ad-hoc, manual mechanisms you > are trying to avoid? The difference is that if we set this up once (i.e. the public SIG(0) key is available to the parent) then we’re done. The same logic in the child primary that today cause it to publish a CDS or a CSYNC record could be trivially extended to issue a dynamic update that is sent to the parent. So, yes, to go from a system that is manual today to something that is fully automated tomorrow it is necessary to make one more, hopefully final, manual operation. I think that’s almost universally true. >> The problem I have with that is that this leaves out major parts of the >> namespace. I.e. I want a mechanism that works for the University of Foobar >> to automate the delegation information for a ~100 departments. > > I understand the desire for automation. > > I'm not sure I understand the part where automation is predicated on a manual > exchange of a token. If manual exchange is an option, why not just manually > exchange the DS RDATA? Se above. It’s only a bootstrapping process. > I'm also not sure I understand why bending the DNS into providing an > authenticated API to signal between the system signing the child zone and the > system producing the parent zone is better than building one using more > conventional techniques like TLS, HTTP, REST, etc. That’s a fair argument. We’ve had the same argument around the generalised notifications draft. My answer is that for the case where the parent is a well-resourced and clueful registry we could do this in essentially any of several ways. But I want to make this viable also for the smaller, less DNS-focused parents. And for that reason I want to minimise complexity. If complexity wasn’t an issue, well, then every parent could run CDS and CSYNC scanners and we would all be happy. I wonder why that isn’t happening. But for these smaller parents that don’t have DNS as their core interest, well they already have a primary name server. I think that in a non trivial number of cases the best alternative may actually be the child running something like BIND 9.28, which issues DDNS updates when it detects that delegation stuff has changed and the parent runs perhaps BIND 9.25, which is able to receive and process those updates and automatically update the child delegation in the parent zone. Oh, wait, mea culpa, that should be BIND 9.14-ish (or something). Guess what, we’ve already had this exact functionality for many years. If you run BIND-something at home you already have this and there is zero new complexity, zero new services to run, zero new code to write and debug. It’s already there! I don’t know if you’ve read the entire draft or not, but the key issue with the draft is not using DDNS for updating delegation information, we’ve had that for many years. The key issue is how to figure out where to SEND the DDNS update (and there I borrow the exact same mechanism that we use for generalised notifications). > Lastly, I'm not sure why people want to roll non-compromised keys anyway, or > under what circumstances it's ok to trust a compromised system to automate a > key replacement under those circumstances. I mean, there surely are some, but > this feels like a difficult thing to match to a general solution. I agree. But it is bad to design a system where the key CANNOT be rolled. And in this case, once bootstrapped, the key can be rolled, if the child so chooses. Regards, Johan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
Hi Paul, > On 25 Oct 2023, at 16:10, Paul Vixie > wrote: > > see inline. > > Johan Stenstam wrote on 2023-10-25 01:09: >> Greetings Working Group, >> As many of you are aware Peter Thomassen, John Levine and I have been >> working on the generalised notifications for a while. The key idea there is >> obviously that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to the >> parent scanner will allow the scanner to fast track the scan of that >> particular child thereby making everything converge faster and presumably >> make the child happier. >> But scanners still suck in general. > > can you more closely define "scan" in this context? i would expect a query > for the notified type at the notified name, but not some kind of enumeration > of multiple possibilities. With “scanners” I refer to CDS scanners and CSYNC scanners. These things issue a gazillion DNS queries, over and over and over, with an extremely small catch of “new CDS” or “new CSYNC” records. They get hit by rate limiting measures from the large DNS providers (for good reason, given the query volumes) and they are still slow. The issue is not the one query for "redbarn.org. CDS” or for “johani.se. CSYNC”, but the queries for CDS and CSYNC RRs for *all* the delegations for .SE (both signed and unsigned), over and over. And not only from one vantage point but from several, located around the world. Furthermore, for unsigned delegations, all the nameservers are queried. Every time. It’s a lot of DNS queries. You’re the author of RFC1996 which we build upon. Of course you have to agree that “push” is a better mechanism than “pull” when it comes to propagating information about a change in one end to the other end. >> So now there’s a new draft, that further extends the same core idea (locate >> the target for the information being sent via a DNS lookup in the parent >> zone). However, the new draft >> (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes that instead of >> sending a NOTIFY (triggering a scan from the recipient) the child sends a >> DNS UPDATE containing the exact change with a signature that can be verified >> by the recipient. >> The recipient is typically not the primary name server for the parent, but >> rather a small service that does the same policy verifications, etc, that a >> scanner would do before committing the change. > > i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone > modification. perhaps propose a new RCODE having the same message form as > UPDATE? Why is this unrelated to zone modification? Au contraire, zone modification is absolutely the intent. But I don’t think you meant RCODE, you meant a new message type? And, sure, that would of course also work. But I think it is unnecessary. >> There are two key advantages to this alternative: >> 1. ... >> 2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate the >> management of delegation information for *all* zones, regardless of whether >> the parent is signed or not, regardless of whether the child is signed or >> not, is an advantage. > > some years back this working group adopted a ubiquity regime for DNSSEC in > that all new specifications "must" expect DNSSEC to be in use and "should" > depend on it when in-scope functionality is needed. has that changed? That’s not my decision to make. However, I do note that it’s been 13 years since the root zone was signed and today, .SE, which is one of the TLDs with the highest percentage of DNSSEC deployment worldide, has a DNSSEC adoption ratio of… less than 60%. In the rest of the world the situation is even worse. So there are many, many, many zones out there that are still not signed. And that’s not their fault, it’s our fault for failing to make the DNSSEC value proposition sufficiently attractive. In some cases the reason they are not signed is because the value proposition simply doesn’t work out, attractive or not. For example, any major organisation with internal delegations will have to think long and hard about running DNSSEC-signed internal zones. It can certainly be done, and I’ve done it myself. But do I know of any real life large scale deployments of DNSSEC for corporate internal zones? No, I don’t. Would all those internal zones benefit from automatic maintenance of the delegation information? Yes they would. I’m all in favour of DNSSEC, but if we actively choose NOT to do something that would eliminate an age-old source of problems (delegation information getting out of sync) BECAUSE it just happens to work nicely also for the non-DNSSEC use case… then I think we need to take a hard look in the mirror to ensure that we’re part of the solution and not the problem. Johan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
On 25 Oct 2023, at 17:31, Johan Stenstam wrote: > On 25 Oct 2023, at 11:32, Joe Abley wrote: > >> I am not at all familiar with SIG(0), so bear with me. What is the key >> distribution mechanism for the DNS UPDATE originator's public key? RFC 2931 >> suggests an unsigned KEY RR, I think? > > My answer is “whatever mechanism the child and parent is using today for > communicating critical information like that”. Isn't the usual answer to that the same kind of ad-hoc, manual mechanisms you are trying to avoid? > The problem I have with that is that this leaves out major parts of the > namespace. I.e. I want a mechanism that works for the University of Foobar to > automate the delegation information for a ~100 departments. I understand the desire for automation. I'm not sure I understand the part where automation is predicated on a manual exchange of a token. If manual exchange is an option, why not just manually exchange the DS RDATA? I'm also not sure I understand why bending the DNS into providing an authenticated API to signal between the system signing the child zone and the system producing the parent zone is better than building one using more conventional techniques like TLS, HTTP, REST, etc. Lastly, I'm not sure why people want to roll non-compromised keys anyway, or under what circumstances it's ok to trust a compromised system to automate a key replacement under those circumstances. I mean, there surely are some, but this feels like a difficult thing to match to a general solution. (People in Hamburg this week are tired of hearing me go on about this. Hopefully they have already pressed delete and are not freshly irritated by reading the same thing here.) Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
Hi Joe, > On 25 Oct 2023, at 11:32, Joe Abley wrote: > > On 25 Oct 2023, at 10:10, Johan Stenstam > wrote: > >> So now there’s a new draft, that further extends the same core idea (locate >> the target for the information being sent via a DNS lookup in the parent >> zone). However, the new draft >> (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes that instead of >> sending a NOTIFY (triggering a scan from the recipient) the child sends a >> DNS UPDATE containing the exact change with a signature that can be verified >> by the recipient. > > I am not at all familiar with SIG(0), so bear with me. What is the key > distribution mechanism for the DNS UPDATE originator's public key? RFC 2931 > suggests an unsigned KEY RR, I think? My answer is “whatever mechanism the child and parent is using today for communicating critical information like that”. The thing here is that I do not primarily expect the TLD registries to change from the current path of either no automation of synchronisation of delegation information OR running a CDS (and perhaps CSYNC) scanner. The problem I have with that is that this leaves out major parts of the namespace. I.e. I want a mechanism that works for the University of Foobar to automate the delegation information for a ~100 departments. I want a mechanism that works for the Stockholm Health Care district to deal with hundreds of hospitals, care givers and other parts of the local health care infora structure. Etc. Neither of those have DNS as a major focus, DNSSEC even less and they are extremely unlikely to run any CDS and/or CSYNC scanners in the foreseeable future. So what do all these parents that are not registries use today? All sorts of semi crappy mechanisms, from email, via webforms to various local APIs, etc. All of these mechanisms have drawbacks, all have security issues and all of them have a certain failure rate because there is manual labor involved. I want to completely get rid of the manual part of maintaining existing delegations and the proposal is to transport the public key to the parent in any way that is acceptable to both child and parent. I don’t think an unsigned KEY RR is a particularly attractive alternative, but I have nothing against a DNSSEC signed KEY RR. Johan PS. In the case where the parent *is* a registry, and there are registrars then I think an EPP extension for the submission of the public SIG(0) keys will work just fine. But, as I said, that’s not my primary goal at this time. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
On Oct 25, 2023, at 10:11, Paul Vixie wrote: > [speaking as individual] > i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone > modification. perhaps propose a new RCODE having the same message form as > UPDATE? I agree. >> 2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate the >> management of delegation information for *all* zones, regardless of whether >> the parent is signed or not, regardless of whether the child is signed or >> not, is an advantage. > > some years back this working group adopted a ubiquity regime for DNSSEC in > that all new specifications "must" expect DNSSEC to be in use and "should" > depend on it when in-scope functionality is needed. has that changed? I agree here as well. The longer we pretend DNSSEC is “optional” and make DNS the last protocol lacking simple spoof protection, the longer we put a brake on deployment of DNSSEC. And the longer we need to write drafts hacking around this. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
see inline. Johan Stenstam wrote on 2023-10-25 01:09: Greetings Working Group, As many of you are aware Peter Thomassen, John Levine and I have been working on the generalised notifications for a while. The key idea there is obviously that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to the parent scanner will allow the scanner to fast track the scan of that particular child thereby making everything converge faster and presumably make the child happier. But scanners still suck in general. can you more closely define "scan" in this context? i would expect a query for the notified type at the notified name, but not some kind of enumeration of multiple possibilities. So now there’s a new draft, that further extends the same core idea (locate the target for the information being sent via a DNS lookup in the parent zone). However, the new draft (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes that instead of sending a NOTIFY (triggering a scan from the recipient) the child sends a DNS UPDATE containing the exact change with a signature that can be verified by the recipient. The recipient is typically not the primary name server for the parent, but rather a small service that does the same policy verifications, etc, that a scanner would do before committing the change. i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone modification. perhaps propose a new RCODE having the same message form as UPDATE? There are two key advantages to this alternative: 1. ... 2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate the management of delegation information for *all* zones, regardless of whether the parent is signed or not, regardless of whether the child is signed or not, is an advantage. some years back this working group adopted a ubiquity regime for DNSSEC in that all new specifications "must" expect DNSSEC to be in use and "should" depend on it when in-scope functionality is needed. has that changed? -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
On 25 Oct 2023, at 10:10, Johan Stenstam wrote: > So now there’s a new draft, that further extends the same core idea (locate > the target for the information being sent via a DNS lookup in the parent > zone). However, the new draft > (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes that instead of > sending a NOTIFY (triggering a scan from the recipient) the child sends a DNS > UPDATE containing the exact change with a signature that can be verified by > the recipient. I am not at all familiar with SIG(0), so bear with me. What is the key distribution mechanism for the DNS UPDATE originator's public key? RFC 2931 suggests an unsigned KEY RR, I think? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Automated delegation management via DDNS
Greetings Working Group, As many of you are aware Peter Thomassen, John Levine and I have been working on the generalised notifications for a while. The key idea there is obviously that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to the parent scanner will allow the scanner to fast track the scan of that particular child thereby making everything converge faster and presumably make the child happier. But scanners still suck in general. So now there’s a new draft, that further extends the same core idea (locate the target for the information being sent via a DNS lookup in the parent zone). However, the new draft (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes that instead of sending a NOTIFY (triggering a scan from the recipient) the child sends a DNS UPDATE containing the exact change with a signature that can be verified by the recipient. The recipient is typically not the primary name server for the parent, but rather a small service that does the same policy verifications, etc, that a scanner would do before committing the change. There are two key advantages to this alternative: 1. No need for the scanner. While some registries and registrars already run scanners this would really help all other, smaller, parent zones that don’t have scanners and, more importantly, don’t want scanners. 2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate the management of delegation information for *all* zones, regardless of whether the parent is signed or not, regardless of whether the child is signed or not, is an advantage. Note that this mechanism is proposed as a complement to the generalized notifications, not as a replacement. Both have roles to fulfill. Please take a look if you’re at all interested in these issues. I will present the draft in Prague. Regards, Johan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
