Re: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP
(Actually, I think you can't have either!) On Fri, Nov 18, 2016 at 7:14 AM, Ted Lemon wrote: > Which do you want? TLSA, or delegation? You can't have both. > > On Fri, Nov 18, 2016 at 6:52 AM, Mark Andrews wrote: >> >> As I said on the sunset4 mailing list this goes too far. >> >> I don't know about you but I want to be able to lookup TLSA records, >> SRV and other records types for foo.localhost and localhost. >> >> And by the way this also requires a insecure delegation in the root >> zone for DNSSEC to work with validating client. >> >> This isn't a good idea. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> >> ___ >> 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] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP
Which do you want? TLSA, or delegation? You can't have both. On Fri, Nov 18, 2016 at 6:52 AM, Mark Andrews wrote: > > As I said on the sunset4 mailing list this goes too far. > > I don't know about you but I want to be able to lookup TLSA records, > SRV and other records types for foo.localhost and localhost. > > And by the way this also requires a insecure delegation in the root > zone for DNSSEC to work with validating client. > > This isn't a good idea. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > 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] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP
As I said on the sunset4 mailing list this goes too far. I don't know about you but I want to be able to lookup TLSA records, SRV and other records types for foo.localhost and localhost. And by the way this also requires a insecure delegation in the root zone for DNSSEC to work with validating client. This isn't a good idea. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [OT][rant-ish] Electronics & business models (was DNSSEC operational issues long term)
>For most electronics equipment (pre-IoT) once you sold it your job as a >manufacturer was basically done. You don't have to issue security >patches for the keyboard or firmware upgrades to the monitor because >the meaning of the wires in the VGA standard has changed out from under >it. > >With anything connected to the Internet it seems the only thing that we >can do is constantly be patching and fighting against the latest >exploits of our protocols and implementations. Unless we are going to >throw away all practical engineering and only use systems that are >provably correct in a mathematics sense(*), that's probably how it is >going to stay. > >There are several possible models that would be better: subscription, >open systems (so a 3rd party can sell improvements & upgrades), and >so on. Unfortunately nobody seems to care about these issues, since the >vendors are making money by the fistful (a few pennies at a time) and >policy makers take that is a sign that everything is fine. Looking at this from a European perspective (regulations vary in different parts of the world), you can expect the manufacturer to build a device that will work correctly for some period of time. I think the European (default) minimum is 2 years. So if the device develops a fault during that period, it has to be repaired or replaced by the seller. Needless to say, security issues are manufacturing defects that are not exempt from this. If internet connected devices continue to do damage in the next years, it is not unreasonable to expect that the manufacturers will at some point be forced to pay for the damages caused by the abuse of those devices. So part of selling a device that is intended to be connected to the internet is to make sure that security issues can be patched. At the same time, if a device stops working because of a DNS root KSK roll over then it's reasonable to demand that the seller makes it work again. Of course, a manufacturer can choose whatever clumsy user interface is cheapest. My preference for general purpose, autonomous devices, is that they check if firmware updates are available. That way the manufacturer can promptly fix security updates, but it also allows for changes in key material, etc. I think this is easy to do. There are some things you can't protect against (signature keys leaking) but there are plenty of other accidents that happen already. I guess anybody can write a BCP for that device class, it doesn't even have to be the IETF. A more complex class is a device that should be able to bootstrap even if only a limited part of the internet is reachable. For example after some kind of disaster. That may require carefully documenting what protocols are used and in what way, to reach a stable secure state. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] special use names and unsecured delegation from the root
I'm going to tick people off again, but noting there is a reason you want to do this, and you think its a justified reason, and you can argue a good case for putting it in a problem statement, it would be (IMH, Very H opinion) a really bad idea (tm) to give anyone a sense that .homenet is "just going to happen" especially if you make people think "because we like them" Please, if you put references to an emerging PROBLEM (my emphasis) in homenet calling for a .homenet (or some suitable nonce: really, who picks these strings? thats part of the problem statement, right?) It has to be just that: a problem statement, not any statement pleading the cause, or assuming delegation is going to happen. I'm not a lawyer. I just think we should observe the kinds of process we expect people outside the tent to see, if they look inside. -G On Thu, Nov 17, 2016 at 10:10 PM, Ralph Droms wrote: > Ted, Suzanne - it might be helpful if the text can stand by itself, to post > the text to the homenet and snoop WG mailing lists, in addition to adding i > too the problem statement. > > - Ralph > >> On Nov 17, 2016, at 3:43 AM, Ted Lemon wrote: >> >> It's pretty clear that it needs to be added. I will do so. >> >> On Thu, Nov 17, 2016 at 5:00 PM, Suzanne Woolf >> wrote: >>> Hi all, >>> >>> For those of you who were in the HOMENET WG meeting yesterday, you probably >>> noticed a controversy that’s developed around the proposed .homenet special >>> use name as the default for homenet naming: the working group is >>> considering, among other things, whether its special use name needs an >>> unsecure delegation in the parent zone in order to prevent DNSSEC failures. >>> >>> If HOMENET is attempting to standardize a single-label special use name (a >>> “TLD”), which is their current plan, this would mean asking IANA for such >>> an unsecure delegation in the root, which may pose process problems. If >>> they want a special use name further down the tree, such as one under >>> .arpa, the unsecure delegation from the parent may still be required, but >>> shouldn’t raise the same process questions. >>> >>> I’m hereby asking the editors of the DNSOP special use names problem >>> statement document to review that discussion and determine whether it needs >>> to be added to the problem statement. >>> >>> It seems to me that it would be very helpful if the problem statement could >>> describe how DNSSEC is relevant to handling of special use names (including >>> those that use DNS resolution protocol but don’t have global scope, or >>> those that aren’t intended to resolve with DNS at all) and under what >>> conditions it can be a problem. >>> >>> >>> thanks, >>> Suzanne >>> >>> ___ >>> 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 > > ___ > 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] DNSSEC operational issues long term
Edward Lewis wrote: > > There's been a lot of research consideration of how shelved or otherwise > disconnected devices catch up. I recall 20 years ago this topic was > amongst the issues in the labs where I worked, the usual use case > involved submarines surfacing. One example which comes up a lot on the LEAPSECS mailing list is radio transmission sites, where hardware is kept on the shelf as a cold spare for installation by non-expert remote hands in case the live equipment lets out its magic smoke. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Viking, North Utsire, South Utsire, Forties, Cromarty, Forth, Tyne: Westerly or southwesterly, becoming cyclonic, 5 to 7, increasing gale 8 or severe gale 9 for a time in South Utsire and southeast Forties, decreasing 4 at times. Moderate or rough, but becoming mainly slight in southeast Forties, Cromarty, Forth and Tyne. Squally showers, thundery at times. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] special use names and unsecured delegation from the root
Ted, Suzanne - it might be helpful if the text can stand by itself, to post the text to the homenet and snoop WG mailing lists, in addition to adding i too the problem statement. - Ralph > On Nov 17, 2016, at 3:43 AM, Ted Lemon wrote: > > It's pretty clear that it needs to be added. I will do so. > > On Thu, Nov 17, 2016 at 5:00 PM, Suzanne Woolf wrote: >> Hi all, >> >> For those of you who were in the HOMENET WG meeting yesterday, you probably >> noticed a controversy that’s developed around the proposed .homenet special >> use name as the default for homenet naming: the working group is >> considering, among other things, whether its special use name needs an >> unsecure delegation in the parent zone in order to prevent DNSSEC failures. >> >> If HOMENET is attempting to standardize a single-label special use name (a >> “TLD”), which is their current plan, this would mean asking IANA for such an >> unsecure delegation in the root, which may pose process problems. If they >> want a special use name further down the tree, such as one under .arpa, the >> unsecure delegation from the parent may still be required, but shouldn’t >> raise the same process questions. >> >> I’m hereby asking the editors of the DNSOP special use names problem >> statement document to review that discussion and determine whether it needs >> to be added to the problem statement. >> >> It seems to me that it would be very helpful if the problem statement could >> describe how DNSSEC is relevant to handling of special use names (including >> those that use DNS resolution protocol but don’t have global scope, or those >> that aren’t intended to resolve with DNS at all) and under what conditions >> it can be a problem. >> >> >> thanks, >> Suzanne >> >> ___ >> 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt
On Wed, Nov 16, 2016 at 5:51 PM, Matthijs Mekking wrote: > Hi Ondřej, > > On 16-11-16 07:09, Ondřej Surý wrote: >> >> Hi, >> >> I read the document and I believe that the document goes to far >> to recommend the vendors how to implement the knobs in their >> software here: >> >>It is recommended that resolvers that implement Aggressive Negative >>Caching provide a configuration switch to disable the feature. >>Separate configuration switches may be implemented for the aggressive >>use of NSEC, NSEC3 and wildcard records, and it is recommended to >>enable aggressive negative caching by default. >> >> I would recommend (not strongly) dropping this paragraph. And if not >> dropping provide a rationale for such recommendation. (And I am sorry >> if this has been rehashed and the rational can be found in the archive. >> In that case, the msg-id would be appreciated.) > > > I am in favor of dropping the paragraph, though it is already better than it > was before (with RFC 2119 keywords). > Ask and ye shall receive! DONE (as part of the Ondrej set above). W > See these messages for a previous discussion on this topic: > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18252.html > https://www.ietf.org/mail-archive/web/dnsop/current/msg18254.html > https://www.ietf.org/mail-archive/web/dnsop/current/msg18254.html > > > Best regards, > Matthijs > > > > >> ~~~ >> (nit) missing whitespace in Section 5.4. third paragraph: >> s/RFC2308]also/RFC2308] also/ >> >> ~~~ >> Section 5.4, fourth paragraph, first line: should or SHOULD to match >> RECOMMENDED in second paragraph same section? >> ~~~ >> (nit) Section 6: s/authorative/authoritative/ >> >> ~~~ >> I think a small text to recommend signing domains because of increased >> protection would be nice in Section 6. I am happy to provide text if >> the authors poke me when I am not jet-lagged. >> >> ~~~ >> (nit) Appendix B: s/NXDOMAN/NXDOMAIN/ >> >> ~~~ >> It's unclear what Appendix B means by "discard it". Does it mean "proceed >> as normal" >> or "delete it from cache and proceed as normal"? Could you please clarify >> the text >> in the draft? >> >> Also 'ENT' is a abbreviation neither defined anywhere else nor explained >> in this >> document. >> >> ~~~ >> I would also welcome if Sections 5.1, 5.2 and 5.3 had specific examples, >> either >> in the respective sections or in separate Section or as a part of Appendix >> B. >> >> ~~~ >> Otherwise the rest of the document is in good shape (if not I blame lack >> of sleep) >> and I would be happy to review next revision. In case I am silent bug me >> until >> I do the review. >> >> Cheers, >> -- >> Ondřej Surý -- Technical Fellow >> >> CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC >> Milesovska 5, 130 00 Praha 3, Czech Republic >> mailto:ondrej.s...@nic.czhttps://nic.cz/ >> >> >> - Original Message - >>> >>> From: internet-dra...@ietf.org >>> To: i-d-annou...@ietf.org >>> Cc: "dnsop" >>> Sent: Wednesday, 16 November, 2016 03:41:29 >>> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Domain Name System Operations of the >>> IETF. >>> >>>Title : Aggressive use of NSEC/NSEC3 >>>Authors : Kazunori Fujiwara >>> Akira Kato >>> Warren Kumari >>> Filename: draft-ietf-dnsop-nsec-aggressiveuse-06.txt >>> Pages : 16 >>> Date: 2016-11-15 >>> >>> Abstract: >>> The DNS relies upon caching to scale; however, the cache lookup >>> generally requires an exact match. This document specifies the use >>> of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers >>> to generate negative answers within a range, and positive answers >>> from wildcards. This increases performance / decreases latency, >>> decreases resource utilization on both authoritative and recursive >>> servers, and also increases privacy. It may also help increase >>> resilience to certain DoS attacks in some circumstances. >>> >>> This document updates RFC4035 by allowing validating resolvers to >>> generate negative based upon NSEC/NSEC3 records (and positive answers >>> in the presence of wildcards). >>> >>> [ Ed note: Text inside square brackets ([]) is additional background >>> information, answers to frequently asked questions, general musings, >>> etc. They will be removed before publication.This document is being >>> collaborated on in Github at: https://github.com/wkumari/draft-ietf- >>> dnsop-nsec-aggressiveuse. The most recent version of the document, >>> open issues, etc should all be available here. The authors >>> (gratefully) accept pull requests.] >>> >>> >>> The IETF datatracker
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt
On Wed, Nov 16, 2016 at 3:09 PM, Ondřej Surý wrote: > Hi, > > I read the document and I believe that the document goes to far > to recommend the vendors how to implement the knobs in their > software here: > >It is recommended that resolvers that implement Aggressive Negative >Caching provide a configuration switch to disable the feature. >Separate configuration switches may be implemented for the aggressive >use of NSEC, NSEC3 and wildcard records, and it is recommended to >enable aggressive negative caching by default. > > I would recommend (not strongly) dropping this paragraph. And if not > dropping provide a rationale for such recommendation. (And I am sorry > if this has been rehashed and the rational can be found in the archive. > In that case, the msg-id would be appreciated.) > Ok (I read further downthread as well, and multiple people support this). DONE. > ~~~ > (nit) missing whitespace in Section 5.4. third paragraph: > s/RFC2308]also/RFC2308] also/ Thank you. DONE > > ~~~ > Section 5.4, fourth paragraph, first line: should or SHOULD to match > RECOMMENDED in second paragraph same section? SHOULD seems right (based upon other comments too) DONE > ~~~ > (nit) Section 6: s/authorative/authoritative/ Also caught by someone else. DONE > > ~~~ > I think a small text to recommend signing domains because of increased > protection would be nice in Section 6. I am happy to provide text if > the authors poke me when I am not jet-lagged. I just added: "As these benefits are only accrued by those using DNSSEC, it is hoped that these techniques will lead to more DNSSEC deployment." Additional / other suggestions welcome. DONE > > ~~~ > (nit) Appendix B: s/NXDOMAN/NXDOMAIN/ > > ~~~ > It's unclear what Appendix B means by "discard it". Does it mean "proceed as > normal" > or "delete it from cache and proceed as normal"? Could you please clarify > the text > in the draft? This is originally MarkA's text (CCed). I'm assuming what was meant was: If the NSEC record has not been verified as secure it should be discarded, and not placed in the cache. (as far as I can tell, non-secure NSECs should never make it into cach oh, huh, an NSEC in a non-signed zone is still a valid RR, and so it could be in the cache... so I guess it should simply be ignored... so, proceed an normal?! I've confused myself Now I think it should be "If the NSEC record has not been verified as secure it should be ignored". Mark? > > Also 'ENT' is a abbreviation neither defined anywhere else nor explained in > this > document. How is: This procedure outlines how to determine if a given name does not exist, or is an ENT (Empty Non-Terminal, see "RFC5155" Section 1.3) > > ~~~ > I would also welcome if Sections 5.1, 5.2 and 5.3 had specific examples, > either > in the respective sections or in separate Section or as a part of Appendix B. This seems like it would be really hard to capture in a readable form. I'd welcome any assistance that people might have here (i could say something like "Referring to the first example in Section 3, if the resolver were to get a query for ball.example.com, and already had an NSEC record covering albatross.example.com to elephant.example.com it should use this information to synthesize a negative answer", but this is a: imprecise, b: wordy and c: not (IMO) particularilty helpful). Happy to take any donated text. not done. > > ~~~ > Otherwise the rest of the document is in good shape (if not I blame lack of > sleep) > and I would be happy to review next revision. In case I am silent bug me > until > I do the review. Thank you. I have integrated these and posted a new version on Github: https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse I have not yet pushed a new version to the IETF as I'm trying to integrate suggestions as I get them. Please let me know if these work for you, and I'll push a new version once I've incorporated more comments. W > > Cheers, > -- > Ondřej Surý -- Technical Fellow > > CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.s...@nic.czhttps://nic.cz/ > > > - Original Message - >> From: internet-dra...@ietf.org >> To: i-d-annou...@ietf.org >> Cc: "dnsop" >> Sent: Wednesday, 16 November, 2016 03:41:29 >> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations of the IETF. >> >>Title : Aggressive use of NSEC/NSEC3 >>Authors : Kazunori Fujiwara >> Akira Kato >> Warren Kumari >> Filename: draft-ietf-dnsop-nsec-aggressiveuse-06.txt >> Pages : 16 >> Date: 2016-1
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt
Hi, Maybe I'm missing something, but it is not clear to me whether this document (-06) allows generation of NODATA answers using matching NSEC records that do not have the QTYPE set in the type bitmap. I don't see it explicitly mentioned. The RFC4035 update in section 7 seems to allow it (or at least not disallow it). However, Section 4 only mentions covering (not matching) NSEC records. Same in section 5.1: "The validating resolver needs to check the existence [...] and an NSEC RR covering the query name.". Section 5.1 does mention using NSEC to return NODATA responses, but that might also be the result of an ENT answer. Section 5.3 seems to disallow NODATA answers for wildcards: "If the corresponding wildcard record is not in the cache, it MUST fall back to send the query to the authoritative DNS servers.". I hope the intention is to allow NODATA responses for wildcards, otherwise random QNAME attacks are possible on wildcard records. And some nits, for which I'll submit a pull request: - In the abstract: s/negative based/nagative answers based/ - Section 1: s/with NXDOMAIN immediately/with negative answers immediately/ (this also catches NODATA answers for ENTs) - Section 2: "Closest Encloser" and "Next closer name" are not used in this document. - Section 3: s/starting/stating/ - Section 4, sentence of 4th paragraph ends abruptly "(for the" - Section 4, last paragraph: s/the TTL of the NSEC record is the authoritative statement/the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field are the authoritative statement/ (and/or a reference to section 5.4?) Regards, -- Ralph On 16-11-16 03:41, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Aggressive use of NSEC/NSEC3 > Authors : Kazunori Fujiwara > Akira Kato > Warren Kumari > Filename: draft-ietf-dnsop-nsec-aggressiveuse-06.txt > Pages : 16 > Date: 2016-11-15 > > Abstract: >The DNS relies upon caching to scale; however, the cache lookup >generally requires an exact match. This document specifies the use >of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers >to generate negative answers within a range, and positive answers >from wildcards. This increases performance / decreases latency, >decreases resource utilization on both authoritative and recursive >servers, and also increases privacy. It may also help increase >resilience to certain DoS attacks in some circumstances. > >This document updates RFC4035 by allowing validating resolvers to >generate negative based upon NSEC/NSEC3 records (and positive answers >in the presence of wildcards). > >[ Ed note: Text inside square brackets ([]) is additional background >information, answers to frequently asked questions, general musings, >etc. They will be removed before publication.This document is being >collaborated on in Github at: https://github.com/wkumari/draft-ietf- >dnsop-nsec-aggressiveuse. The most recent version of the document, >open issues, etc should all be available here. The authors >(gratefully) accept pull requests.] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-aggressiveuse-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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] special use names and unsecured delegation from the root
A clarifying question: Given that there are 1518 delegations from the root zone, 1369 to zones owning a DNSKEY set, 1358 having a DS record (in the root zone), is DNSSEC a distinguishing factor in this regard? That is, no other name in the Special-Use Domain Name registry currently is directly delegated from the root zone. I understand how any delegation would be precedent-setting. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] special use names and unsecured delegation from the root
It's pretty clear that it needs to be added. I will do so. On Thu, Nov 17, 2016 at 5:00 PM, Suzanne Woolf wrote: > Hi all, > > For those of you who were in the HOMENET WG meeting yesterday, you probably > noticed a controversy that’s developed around the proposed .homenet special > use name as the default for homenet naming: the working group is considering, > among other things, whether its special use name needs an unsecure delegation > in the parent zone in order to prevent DNSSEC failures. > > If HOMENET is attempting to standardize a single-label special use name (a > “TLD”), which is their current plan, this would mean asking IANA for such an > unsecure delegation in the root, which may pose process problems. If they > want a special use name further down the tree, such as one under .arpa, the > unsecure delegation from the parent may still be required, but shouldn’t > raise the same process questions. > > I’m hereby asking the editors of the DNSOP special use names problem > statement document to review that discussion and determine whether it needs > to be added to the problem statement. > > It seems to me that it would be very helpful if the problem statement could > describe how DNSSEC is relevant to handling of special use names (including > those that use DNS resolution protocol but don’t have global scope, or those > that aren’t intended to resolve with DNS at all) and under what conditions it > can be a problem. > > > thanks, > Suzanne > > ___ > 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
[DNSOP] special use names and unsecured delegation from the root
Hi all, For those of you who were in the HOMENET WG meeting yesterday, you probably noticed a controversy that’s developed around the proposed .homenet special use name as the default for homenet naming: the working group is considering, among other things, whether its special use name needs an unsecure delegation in the parent zone in order to prevent DNSSEC failures. If HOMENET is attempting to standardize a single-label special use name (a “TLD”), which is their current plan, this would mean asking IANA for such an unsecure delegation in the root, which may pose process problems. If they want a special use name further down the tree, such as one under .arpa, the unsecure delegation from the parent may still be required, but shouldn’t raise the same process questions. I’m hereby asking the editors of the DNSOP special use names problem statement document to review that discussion and determine whether it needs to be added to the problem statement. It seems to me that it would be very helpful if the problem statement could describe how DNSSEC is relevant to handling of special use names (including those that use DNS resolution protocol but don’t have global scope, or those that aren’t intended to resolve with DNS at all) and under what conditions it can be a problem. thanks, Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
