Re: [DNSOP] Automated delegation management via DDNS
It appears that Johan Stenstam said: >Ok, let me rephrase: As a synchronisation mechanism based on a signed DNS >UPDATE message that carries both the data to be >modified and the proof that the change request originated with the owner (the >child) and has not been modified in transit… >it works equally well with or without DNSSEC. That is true, but it also means that the two ends have to arrange out of band to share the signing key, which is the usual scale problem that makes this stuff fail. I think that extending NOTIFY for the small set of cases in the draft is fine, particularly if we also add a case to notify for the DNS bootstrap. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
> On 30 Oct 2023, at 13:00, Johan Stenstam > wrote: > > But let’s ensure that we have identified the correct scope of the problem > rather than cherry-picking the two simplest cases. +1 IMO the discussion of this I-D has lost focus. Let’s find it and get back on track. :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
> On 28 Oct 2023, at 16:40, Paul Wouters wrote: > > On Oct 25, 2023, at 13:14, Johan Stenstam > wrote: >> >> To begin with it works equally well with or without DNSSEC. > > That statements seems a little odd? Ok, let me rephrase: As a synchronisation mechanism based on a signed DNS UPDATE message that carries both the data to be modified and the proof that the change request originated with the owner (the child) and has not been modified in transit… it works equally well with or without DNSSEC. I don’t know how to make that any clearer. >> 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. > > You seem to assume we didn’t know this when CDS and CSYNC were created. The > question to ask is, why at the time we thought those new mechanisms were > needed, and whether those reasons have changed since then. Of course we knew. But knowing doesn’t automatically result in a solution that works for everyone. If the DNSSE deployment history should teach us anything at all it is to be humble. We should be humble because we got it wrong so many times. And then we backtracked and got it wrong again. Over time we made progress, but it hasn’t exactly been a straight line. And if this happens to be yet another case where a little bit of backtracking allows us to end up with a better solution that works for a larger class of use cases then I think it would be better to argue about the technical merits of different alternatives rather than by default assume that we got everything right the first time. >> 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. > > I don’t agree that adoption rate changes any justificstions for new > protocols. I think that’s perhaps the real core for where we perhaps disagree. I do not agree that this is “a new protocol”. This mechanism is more than 15 years old. I think that one important question to ask is “given that we already have the DNS UPDATE based synchronisation mechanism, why isn’t that used?”. And my answer is that it has not been used because of two reasons: 1. Where to send the UPDATE is unclear (when crossing organisational borders). 2. Many parents cannot accept that an UPDATE with a valid signature immediately changes the zone. Additional safety checks are required (as you pointed out). Both of these issues are now being addressed. >> And so this draft was born. > > Mark pointed out we have those “where to send UPDATES” infrastructure already > ? You may have misunderstood what Mark said. We have all the infrastructure EXCEPT where to send the UPDATE. In a local context (inside a sufficiently small organisation) that is easy to figure out. But across organisational borders not so much. >> 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 fullautomation of delegation information >> between child and parent? >> >> If the answer is “no” then I’d love to hear more suggestions than this >> proposal. > > I think you are confusing two very different use cases. Generic registration > TLDs and DNS deployments within the same organization. The latter can clearly > be done with stock DNS UPDATES. The TLD case is special as it involves the > RRR ICANN model. The *g*TLD case is special as it involves the RRR ICANN model. There are however lots of other TLDs. And I don’t understand why you think I confuse these two cases. I completely agree that in the “TLD case” (that I refer to as the “parent is a registry case” CDS/CSYNC scanners + generic notifications work, and are being deployed. I primarily care about the rest of the infrastructure. However, you simplify too much when you only list two use cases. There are more. To begin with internal delegations within the “same organisation” is not quite as easy as “just do stock DNS UPDATE”. Organisations are sometimes very large. They are really not “the same organisation”. They have internal communication
Re: [DNSOP] Automated delegation management via DDNS
On Oct 25, 2023, at 13:14, Johan Stenstam wrote: > > > To begin with it works equally well with or without DNSSEC. That statements seems a little odd? > 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. You seem to assume we didn’t know this when CDS and CSYNC were created. The question to ask is, why at the time we thought those new mechanisms were needed, and whether those reasons have changed since then. > 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. I don’t agree that adoption rate changes any justificstions for new protocols. > And so this draft was born. Mark pointed out we have those “where to send UPDATES” infrastructure already ? > 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 fullautomation of delegation information > between child and parent? > > If the answer is “no” then I’d love to hear more suggestions than this > proposal. I think you are confusing two very different use cases. Generic registration TLDs and DNS deployments within the same organization. The latter can clearly be done with stock DNS UPDATES. The TLD case is special as it involves the RRR ICANN model. Any reasoning about deployments need to take this into account. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
On 28 Oct 2023, at 03:44, Paul Wouters wrote: >>> Scanners are, of course, inefficient, and notifications are a way to >>> improve that. I just think that as we are making comparisons, with >>> arguments whose strength is (in part) based on the number of queries >>> needed, we should get the order of magnitude right, to make the comparisons >>> as helpful as possible. That's all! :) >> >> Then, as usual, we’re in agreement. >> >> But to me, the place for analysis of scanner efficiency (or lack thereof) is >> in conjunction with the draft on generalised notifications and not here, as >> this draft explicitly is intended for the use cases where there is no >> scanner. :-) > > The Wheel of Time turns, and Ages come and pass, leaving memories that > become legend. Legend fades to myth, and even myth is long forgotten > when the Age that gave it birth comes again. In one Age, this discussion > was called "timers vs triggers". With no clear winner, nothing was done > and thus people were forced to implementer scanners (timers). I'm happy > to see notify (triggers) in some shape or form, although in previous > wars, people wanted the notify to go "elsewhere", eg not the primary > (or maybe not even secondary) servers as to leave the production name > servers untouched. I think most of us are in agreement here. That’s sort of the core intent of draft-ietf-dnsop-generalized-notify. > Note that I dont think scanners can be fully omitted, as any sane parent > will do some sanity checks on its child and that's really just a scanner > without a "for domain in TLD" loop around it. I think this is also mostly agreed upon. Sanity check for sure. Whether that requires a scanner or not depends (in my view) on the trigger. For a NOTIFY a scan is obviously required to get the data to sanity check. For an UPDATE it can be argued both ways. 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 Fri, 27 Oct 2023, Johan Stenstam wrote: Scanners are, of course, inefficient, and notifications are a way to improve that. I just think that as we are making comparisons, with arguments whose strength is (in part) based on the number of queries needed, we should get the order of magnitude right, to make the comparisons as helpful as possible. That's all! :) Then, as usual, we’re in agreement. But to me, the place for analysis of scanner efficiency (or lack thereof) is in conjunction with the draft on generalised notifications and not here, as this draft explicitly is intended for the use cases where there is no scanner. :-) The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, this discussion was called "timers vs triggers". With no clear winner, nothing was done and thus people were forced to implementer scanners (timers). I'm happy to see notify (triggers) in some shape or form, although in previous wars, people wanted the notify to go "elsewhere", eg not the primary (or maybe not even secondary) servers as to leave the production name servers untouched. Note that I dont think scanners can be fully omitted, as any sane parent will do some sanity checks on its child and that's really just a scanner without a "for domain in TLD" loop around it. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
> On 10/27/23 11:51, Johan Stenstam wrote: >>> Extra vantage points are a mitigation for the (prevalent) lack of >>> signatures during bootstrapping; once authentication is handled, there's no >>> need for it. >> I get that. But, as you know from both the draft and the presentation I made >> at OARC some weeks ago, this is really not about how to make scanners >> slightly less inefficient. > > Ack > >> But I have to ask: is your point just that I should get my math right or is >> your point that scanners are fine, every parent should run one and there is >> no problem to solve? > > Purely the former! > > Scanners are, of course, inefficient, and notifications are a way to improve > that. I just think that as we are making comparisons, with arguments whose > strength is (in part) based on the number of queries needed, we should get > the order of magnitude right, to make the comparisons as helpful as possible. > That's all! :) Then, as usual, we’re in agreement. But to me, the place for analysis of scanner efficiency (or lack thereof) is in conjunction with the draft on generalised notifications and not here, as this draft explicitly is intended for the use cases where there is no scanner. :-) 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 10/27/23 11:51, Johan Stenstam wrote: Extra vantage points are a mitigation for the (prevalent) lack of signatures during bootstrapping; once authentication is handled, there's no need for it. I get that. But, as you know from both the draft and the presentation I made at OARC some weeks ago, this is really not about how to make scanners slightly less inefficient. Ack But I have to ask: is your point just that I should get my math right or is your point that scanners are fine, every parent should run one and there is no problem to solve? Purely the former! Scanners are, of course, inefficient, and notifications are a way to improve that. I just think that as we are making comparisons, with arguments whose strength is (in part) based on the number of queries needed, we should get the order of magnitude right, to make the comparisons as helpful as possible. That's all! :) Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
Hi Peter, > On 10/25/23 18:19, Johan Stenstam wrote: >> 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 > > If that's the case, there's a significant problem. Do you have numbers on the > extent of the problem / how much of an issue that is for your daily runs at > .se? Not really. Sorry. There are several reasons for this. One is that our “production scanners” are designed to be really slow (largely to avoid rate limiting). Another is that a prototype fast scanner (that I wrote) ran into so much rate limiting issues as to be more or less useless. So I implemented adaptive delays per target destination to scale back the query frequency based on how much rate limiting was hurting me in the previous scan. But that also wasn’t enough so we’ve talked to the largest providers to have them whitelist our scanning. To be fair I should mention that my scanner queried for more things than just CDS and CSYNC. So my query volume is noticeably higher than a “pure” CDS and/or CSYNC scanner would have. >> And not only from one vantage point but from several, located around the >> world. > > That's only needed for unauthenticated bootstrapping; both authenticated > bootstrapping and CDS-induced DS updates don't need multiple vantage points. > > Extra vantage points are a mitigation for the (prevalent) lack of signatures > during bootstrapping; once authentication is handled, there's no need for it. I get that. But, as you know from both the draft and the presentation I made at OARC some weeks ago, this is really not about how to make scanners slightly less inefficient. I don’t think that any new mechanism for how to automate the management of delegation information will replace the CDS and CSYNC scanners in the TLD registries. The registry scanners are here to stay. And that’s why you, John Levine and I have a draft about improving the scanner efficiency via generalised notifications. THIS draft, on the other hand, is is not about scanners at all. It is about how to automate delegation management for perhaps a million parent zones that do not run scanners today, don’t want to or are unable to run scanners tomorrow and in general would benefit from a much less complex solution to the problem. >> Furthermore, for unsigned delegations, all the nameservers are queried. >> Every time. It’s a lot of DNS queries. > > Where's that written? > > I don't think it's correct. For example, if you find on the same nameserver > that you queried a CDS/CDNSKEY RRset that indicates no change over the > existing DS record, then there's no point in looking at other nameserver. > (They would either confirm that no update should happen, or they would be > contradictory, in which case no update should happen.) I have to admit that I haven’t looked at the requirements, I only looked at the implementation for our production scanner (that I did not write). So I want to revisit the design of the current scanner regardless and I’ll make sure to look at this issue also. > Together with the vantage-point considerations, I think the actual number of > queries is about 10x lower than if all NS are always asked from several > vantage points. I’m sure you’re right. But I don’t see how that matters from the POV of this draft. But I have to ask: is your point just that I should get my math right or is your point that scanners are fine, every parent should run one and there is no problem to solve? >> But do I know of any real life large scale deployments of DNSSEC for >> corporate internal zones? > > I may be wrong, but I believe Salesforce to be an example. Aha. Interesting. Let’s see if someone would like to confirm that. 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 10/25/23 18:19, Johan Stenstam wrote: 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 If that's the case, there's a significant problem. Do you have numbers on the extent of the problem / how much of an issue that is for your daily runs at .se? And not only from one vantage point but from several, located around the world. That's only needed for unauthenticated bootstrapping; both authenticated bootstrapping and CDS-induced DS updates don't need multiple vantage points. Extra vantage points are a mitigation for the (prevalent) lack of signatures during bootstrapping; once authentication is handled, there's no need for it. Furthermore, for unsigned delegations, all the nameservers are queried. Every time. It’s a lot of DNS queries. Where's that written? I don't think it's correct. For example, if you find on the same nameserver that you queried a CDS/CDNSKEY RRset that indicates no change over the existing DS record, then there's no point in looking at other nameserver. (They would either confirm that no update should happen, or they would be contradictory, in which case no update should happen.) Together with the vantage-point considerations, I think the actual number of queries is about 10x lower than if all NS are always asked from several vantage points. But do I know of any real life large scale deployments of DNSSEC for corporate internal zones? I may be wrong, but I believe Salesforce to be an example. Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Automated delegation management via DDNS
Hi Libor, > On 26 Oct 2023, at 12:26, libor.peltan > wrote: > > Hi, > I'm not sure if this helps the discussion, but Knot DNS implements "DS push", > an automated DDNS update > updating the DS (not NS) at parent. > It's mostly intended for single-organization parent-child relations, where > TSIG (or soon DDNSoQ) can > be configured easily. I was not aware of this, but “DS push” is clearly an implementation of a the special case (just the DS) of what I would like to see in the child primary. Many thanks for sharing. The limitation of intended use to single organization is easily understandable and those limitations are exactly what I would like to remove with my draft: * by defining a mechanism for how to locate the target for the dynamic update via a DNS lookup * by using SIG(0) rather than TSIG to make it more scalable across multiple organisations I also note that in the Knot-DNS documentation it says about “ds-push” that "this feature requires cds-cdnskey-publish not to be set to none.” I agree completely, this is exactly the choices we have if we want to achieve full automation of updates to delegation information: publish a CDS if we have a parent that runs a CDS scanner OR update the DS directly via a DNS UPDATE for all the cases where there is no parent scanner. 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, I'm not sure if this helps the discussion, but Knot DNS implements "DS push", an automated DDNS update updating the DS (not NS) at parent. It's mostly intended for single-organization parent-child relations, where TSIG (or soon DDNSoQ) can be configured easily. Libor Dne 25. 10. 23 v 17:30 Johan Stenstam napsal(a): 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. ___ 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
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
