[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Actually, we are developing an unrelated scheme that has need of the same zone structure for signaling but not involving DNSSEC itself, and would see some advantage in utilizing the same standard top level underscore naming for signaling use in general. Would you want to put the signal info in the same zones with the DNSSEC stuff? If not, you don't want the same tag. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
[another (last) attempt of reposting this as it did not get delivered to dnsop@ietf.org on May 7, as evidenced by the list archive] Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
[reposting as it did not get delivered to dnsop@ietf.org, as evidenced by the list archive] Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi all, I've read the thread multiple times, and can definitely see both sides of the conversation. As Paul W is wearing both an AD hat and the DE hat, he has asked me to make the decision and instruct him. While I really don't love it, I believe that it makes sense to stick with _signal. Reasons against: 1: It is very generic. It's not at all clear that foo.bar.baz._signal.example.com has anything to do with DNSSEC (although _dsboot.foo.bar.baz._signal.example.com is clearer) Reason for: 1: It is very generic - it another scheme happens to be able to fit well under _signal, they can use it; _cheese.foo.bar.baz._signal.com **might** be good if a parent wants to inform someone about their children's cheese preferences) 2: Strings are cheap - if another scheme happens to not fit will under _signal, they can choose another one (hopefully less generic next time!) — _flavor.foo.bar._cheese.example.com. 3: It happens to already be some what deployed - and we cannot (easily) tell who all has done so. Yes, CloudFlare presumably has this baked into a variable somewhere and it would be trivial to s/_signal/_dnssec-boot/, but someone might also have already done this manually. Yes, I fully agree that people shouldn't kvetch if they implemented from a draft and have to change — which is why I only used this as a tie-breaker. This was one of those "there is no perfect answer" situations, and at least some set of people will be unhappy (sorry!), but I think that sticking with the draft is the lesser of the two evils… W On Wed, May 15, 2024 at 4:49 PM, Peter Thomassen wrote: > Hi David, > > The DNSOP chairs have told me that the document is no longer a WG document > as it's with the IESG, so a consensus call here is not applicable. > > Given the discussion here, we'll leave it to the IESG to decide. If I hear > any news, I'll post them here. > > Thanks, > Peter > > On 5/15/24 00:03, David Dong via RT wrote: > > Hi all, > > Following up on this. Please let us know how we should proceed for this. > Thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Thu May 09 09:39:29 2024, pe...@desec.io wrote: > > [another (last) attempt of reposting this as it did not get delivered to > dnsop@ietf.org on May 7, as evidenced by the list archive] > > Hi, > > On 5/2/24 19:59, David Dong via RT wrote: > > Following up on this; does the group agree that "_dnssec" is OK? > > Looking at what's been said in this thread: > - Two people have proposed to change the label, current proposal: > _dnssec > - Two implementers have said they'd make the change but don't seem > convinced > - The authors (hats off, but also implementers and authors of current > drafts using the mechanism) are not convinced > > The authors don't feel comfortable declaring consensus in either direction > (neither do we know whether that's our role), and we're not sure how to > proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is > happening on the WG list although the document is technically out of the > door ... > > I've been reluctant adding the following argument as to not seem > insisting; OTOH it may have its own technical merit, so here is. > > The "_dnssec" label implies that the mechanism is not suitable for > signaling unrelated to DNSSEC. That's an artificial limitation, and it's > unclear why to impose the restriction. An operator could very well want to > publish other things, like > > - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse > address, > - PTR at _catalog.example.com._signal ... for catalog zone membership, > - ... > > If the signaling method is generic, I believe it should have a short > generic label. Any specificity to determine the kind of signal can go into > the first label. > > I have no specific preference for "_signal" other than I don't know what a > good alternative would be. Narrowing the scope with "_dnssec" doesn't seem > to improve the situation. > > Thanks, > Peter > + Nils (for the "we"/author statements) > > Thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: > > On 20 Apr 2024, at 19:38, Paul Wouters wrote: > > On Sat, 20 Apr 2024, Peter Thomassen wrote: > > The authors certainly don't insist, but we'd need to pick a suitable > replacement for the "_signal" label. > > John proposed "_dnssec-signal" elsewhere in this thread. > > The authors would like to note that adding "_dnssec-" eats up 8 more > bytes, increasing chances that bootstrapping will fail due to the > _dsboot.._dnssec-signal. length limitation. Other > than this (unnecessary?) use case narrowing, this choice seems > fine. > > That said, does this choice address your concerns? > > It would, but I would also be okay if it is just _dnssec. > > If the concern is that the label is too generic, “_dnssec” might be too > generic as well. If it is to be more precise, go with _ds-boot or > something more specific to the
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi David, The DNSOP chairs have told me that the document is no longer a WG document as it's with the IESG, so a consensus call here is not applicable. Given the discussion here, we'll leave it to the IESG to decide. If I hear any news, I'll post them here. Thanks, Peter On 5/15/24 00:03, David Dong via RT wrote: Hi all, Following up on this. Please let us know how we should proceed for this. Thank you. Best regards, David Dong IANA Services Sr. Specialist On Thu May 09 09:39:29 2024, pe...@desec.io wrote: [another (last) attempt of reposting this as it did not get delivered to dnsop@ietf.org on May 7, as evidenced by the list archive] Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
When I wrote my reply to Peter, I lost my comment about speaking not as the chair but as a contributor. The point I was trying to make is that the comments from Paul W as the Expert Reviewer for the IANA registry is comment/opinion/vibe that should be considered the most relevant in this discussion. tim (just a contributor) On Thu, May 9, 2024 at 10:29 PM Tim Wicinski wrote: > I wrote a note to Peter and his co-author on this discussion and > we(chairs) feel that Paul W is correct in saying _signal is too generic. > > We should not overload any underscore label for multiple purposes. If > another type of operator signalling appears, a new label can be acquired. > Being specific in this situation is a *good* thing. It is not difficult > to request a new underscore name, the process was made lightweight. > The underscore registry is used by application folks as much if not more > than DNS folks. > > Additionally in the Domain Verification Techniques document, there is a > recommended approach to use application-specific underscore prefix labels > > > https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-04.html#name-scope-indication > > I apologize to the implementers on this. > > Unless the working group speaks up, then the advice of Paul Wouters, as > one of the expert reviewers for the registry, should be the suggestion. > > thanks > tim > > > On Wed, May 8, 2024 at 4:03 PM John Levine wrote: > >> It appears that libor.peltan said: >> >Hi all, >> > >> >On the other hand, couldn't it actually be beneficial if the signalling >> >zone name is generic enough, and if (in theory on the future) it is >> >shared with possibly completely different signals, possibly unrelated to >> >DNSSEC? >> >> It doesn't seem very likely to me that someone would come up with an >> unrelated scheme that somehow used the same zone structure. And it's >> not like there's any shortage of potential name strings. >> >> _dnssec or maybe _dnssec-signal tell people what the name is used for. >> >> R's, >> John >> >> ___ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org >> > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
[reposting as it looks like this did not get delivered during Mailman transition last week; original message sent on May 7] Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
On Fri, 10 May 2024, Paul Wouters wrote: On May 10, 2024, at 05:36, jab...@strandkip.nl wrote: I'm interested in where this guidance comes from. RFC 2782 to me is the grandfather of underscore labels, and it pretty much goes out of its way to encourage a hierarchy of underscore labels to anchor SRV records under, e.g. under _tcp.name and _udp.name. But if you look at more recent RFCs such as TLSA records, it is narrowed to one specific protocol and port, eg _25._tcp.mx.nohats.ca But this isn't the same thing. The two tags on SRV and TLSA records are consecutive labels on single records. As you are both surely aware because you have read the draft, in this case, the _signal record sits atop an entire subtree, e.g. _dsboot.example.co.uk._signal.ns1.example.net _dsboot.example.co.uk._signal.ns2.example.org means that the name servers ns1.example.net and ns2.example.org have bootstrap info for example.co.uk. Since parent scanning for every possible combination of NS and domain would be rather slow, the draft has suggestions such as putting the _signal name in a separate zone that parents can walk with NSEC. There might be other tags than _dsboot for things like synchronizing multi-provider DNS updates, but it's all DNSSEC. Needless to say, this is quite DNSSEC specific and even someone invents some other thing that uses two domain names in a similar way, it's unlikely that you'd want to put it all in the same zone. So I hope we agree to call it _dnssec or something like that. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
On May 10, 2024, at 05:36, jab...@strandkip.nl wrote: > > I'm interested in where this guidance comes from. > > RFC 2782 to me is the grandfather of underscore labels, and it pretty much > goes out of its way to encourage a hierarchy of underscore labels to anchor > SRV records under, e.g. under _tcp.name and _udp.name. But if you look at more recent RFCs such as TLSA records, it is narrowed to one specific protocol and port, eg _25._tcp.mx.nohats.ca > I'm not really arguing with conclusion, but I find the guidance vague. If we > really think it's important to make clear statements about this, perhaps we > should write something down in a document and talk about it. Personally I'm > not convinced it's that important, though. I am not against that but I also feel there is some common sense that applies here. For example, experience has shown TXT record parsing of the APEX can cause lots of noisy logging because the TXT at APEX is used by widely different things that are not aware of each other. I think _dsboot or _dnssec or _dns would all be better choices and greatly reduce the risk of getting overloaded by something else, and is useful even if overloading is mostly harmless. Paul (I also liked the suggestion _dasboot , it’s a great intense movie!) ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi Tim, On May 10, 2024, at 04:29, Tim Wicinski wrote: > I wrote a note to Peter and his co-author on this discussion and we(chairs) > feel that Paul W is correct in saying _signal is too generic. > > We should not overload any underscore label for multiple purposes. If > another type of operator signalling appears, a new label can be acquired. I'm interested in where this guidance comes from. RFC 2782 to me is the grandfather of underscore labels, and it pretty much goes out of its way to encourage a hierarchy of underscore labels to anchor SRV records under, e.g. under _tcp.name and _udp.name. You could argue that those are not multiple purposes (everything under _tcp is TCP, after all) but it feels like the same argument could be made for _signal. > Being specific in this situation is a *good* thing. How is _purpose1._concept.name ... _purpose2._concept.name ... less specific than _purpose1_concept.name ... _purpose2_concept.name ... ? > Additionally in the Domain Verification Techniques document, there is a > recommended approach to use application-specific underscore prefix labels > > https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-04.html#name-scope-indication I'm struggling slightly to see how the advice in that document applies, here. I realise underscore labels are used in both cases, but in the domain validation case we are trying to avoid collisions in the absence of a registry. That's not our situation, here. I'm not really arguing with conclusion, but I find the guidance vague. If we really think it's important to make clear statements about this, perhaps we should write something down in a document and talk about it. Personally I'm not convinced it's that important, though. Joe ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
I wrote a note to Peter and his co-author on this discussion and we(chairs) feel that Paul W is correct in saying _signal is too generic. We should not overload any underscore label for multiple purposes. If another type of operator signalling appears, a new label can be acquired. Being specific in this situation is a *good* thing. It is not difficult to request a new underscore name, the process was made lightweight. The underscore registry is used by application folks as much if not more than DNS folks. Additionally in the Domain Verification Techniques document, there is a recommended approach to use application-specific underscore prefix labels https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-04.html#name-scope-indication I apologize to the implementers on this. Unless the working group speaks up, then the advice of Paul Wouters, as one of the expert reviewers for the registry, should be the suggestion. thanks tim On Wed, May 8, 2024 at 4:03 PM John Levine wrote: > It appears that libor.peltan said: > >Hi all, > > > >On the other hand, couldn't it actually be beneficial if the signalling > >zone name is generic enough, and if (in theory on the future) it is > >shared with possibly completely different signals, possibly unrelated to > >DNSSEC? > > It doesn't seem very likely to me that someone would come up with an > unrelated scheme that somehow used the same zone structure. And it's > not like there's any shortage of potential name strings. > > _dnssec or maybe _dnssec-signal tell people what the name is used for. > > R's, > John > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters) (fwd)
Actually, we are developing an unrelated scheme that has need of the same zone structure for signaling but not involving DNSSEC itself, and would see some advantage in utilizing the same standard top level underscore naming for signaling use in general. Would you want to put the signal info in the same zones with the DNSSEC stuff? If not, you don't want the same tag. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
On 08/05/2024 22:02, John Levine wrote: It appears that libor.peltan said: Hi all, On the other hand, couldn't it actually be beneficial if the signalling zone name is generic enough, and if (in theory on the future) it is shared with possibly completely different signals, possibly unrelated to DNSSEC? It doesn't seem very likely to me that someone would come up with an unrelated scheme that somehow used the same zone structure. And it's not like there's any shortage of potential name strings. Actually, we are developing an unrelated scheme that has need of the same zone structure for signaling but not involving DNSSEC itself, and would see some advantage in utilizing the same standard top level underscore naming for signaling use in general. _dnssec or maybe _dnssec-signal tell people what the name is used for. Thanks & Regards, Adam. OpenPGP_0xE4C76DBFE283909C.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
It appears that libor.peltan said: >Hi all, > >On the other hand, couldn't it actually be beneficial if the signalling >zone name is generic enough, and if (in theory on the future) it is >shared with possibly completely different signals, possibly unrelated to >DNSSEC? It doesn't seem very likely to me that someone would come up with an unrelated scheme that somehow used the same zone structure. And it's not like there's any shortage of potential name strings. _dnssec or maybe _dnssec-signal tell people what the name is used for. R's, John ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi all, On the other hand, couldn't it actually be beneficial if the signalling zone name is generic enough, and if (in theory on the future) it is shared with possibly completely different signals, possibly unrelated to DNSSEC? With this in mind, I support the signalling label _signal. Otherwise, I would prefer something of comparable (or even lower) length, not like _dnssec-signal. Libor Dne 21. 04. 24 v 1:38 Paul Wouters napsal(a): On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. The main question then is to get implementations updated. I'm thus copying a few implementers so they can comment w.r.t. making this change in their implementation. I suppose that barring their objections, it's fine to go ahead? I feel less sympathy there because I brought this up a long time ago :) But also, implementations are all young and new and I think it is still pretty easy to change. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
Hi, On 5/7/24 09:33, Peter Thomassen wrote: Hi, On 5/2/24 19:59, David Dong via RT wrote: Following up on this; does the group agree that "_dnssec" is OK? Looking at what's been said in this thread: - Two people have proposed to change the label, current proposal: _dnssec - Two implementers have said they'd make the change but don't seem convinced - The authors (hats off, but also implementers and authors of current drafts using the mechanism) are not convinced The authors don't feel comfortable declaring consensus in either direction (neither do we know whether that's our role), and we're not sure how to proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is happening on the WG list although the document is technically out of the door ... I've been reluctant adding the following argument as to not seem insisting; OTOH it may have its own technical merit, so here is. The "_dnssec" label implies that the mechanism is not suitable for signaling unrelated to DNSSEC. That's an artificial limitation, and it's unclear why to impose the restriction. An operator could very well want to publish other things, like - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse address, - PTR at _catalog.example.com._signal ... for catalog zone membership, - ... Besides the fact that keeping the current label name is a little bit more convenient for our implementation, I like the idea of a general mechanism for signaling various states in DNS. Thus I would prefer staying with '_signal'. Regards, Daniel (Knot DNS) If the signaling method is generic, I believe it should have a short generic label. Any specificity to determine the kind of signal can go into the first label. I have no specific preference for "_signal" other than I don't know what a good alternative would be. Narrowing the scope with "_dnssec" doesn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fail due to the _dsboot.._dnssec-signal. length limitation. Other than this (unnecessary?) use case narrowing, this choice seems fine. That said, does this choice address your concerns? It would, but I would also be okay if it is just _dnssec. If the concern is that the label is too generic, “_dnssec” might be too generic as well. If it is to be more precise, go with _ds-boot or something more specific to the use case. I don’t have an implementation in the mix, so it this isn’t a strong opinion. If the group agrees _dnssec is fine, then I am fine with it too. Scott = Scott Rose NIST/CTL/WND scott.r...@nist.gov ph: 301-975-8439 GoogleVoice: 571-249-3671 = OpenPGP_signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
