Re: [homenet] [dnsdir] Dnsdir last call review of draft-ietf-homenet-front-end-naming-delegation-26
[ Top-post ] Just a very quick note to say "Thank you very much!" to Anthony for this review. This document is relatively long, contains lots of DNS related content, and has had significant number of sizable update — all of which leads to this being a much much larger than normal DNSDIR review load. Thank you! W On Tue, Jan 31, 2023 at 12:30 PM, Anthony Somerset wrote: > Reviewer: Anthony Somerset > Review result: Ready with Issues > > Hello > > I have been selected as the DNS Directorate reviewer for this draft. The > DNS Directorate seeks to review all DNS or DNS-related drafts as they pass > through IETF last call and IESG review, and sometimes on special request. > The purpose of the review is to provide assistance to the ADs. For more > information about the DNS Directorate, please see https://wiki.ietf.org/ > en/group/dnsdir > > There are are clear and direct references to various DNS RFC's and this > draft is not in any major conflict with the wider DNS space but the > following specific suggestions relating to DNS are made. > > I previously Reviewed Version 18 of this draft and am re-rereviewing in > line with the comments I made in that review - > https://datatracker.ietf.org/doc/ > review-ietf-homenet-front-end-naming-delegation-18-dnsdir-telechat-somerset-2022-10-12/ > > Having re-read the new version a few times, and keeping track of the > various reviews as not to duplicate reports for same issues i will try not > say the same things again. > > I specifically note that Geoff has done a very definitive review of > version 25 of the document and i won't repeat those comments in this review > but suffice to say i do concur with the assessment of the situation in his > review and agree with the position of Ready with Issues as well > > I am happy with the large effort to reflow the document - it does now read > in a more sensible order and helps with clarity. > > I am also happy with the additional security considerations that make > sense. > > Major Issues: None > > Minor Issues: > > Section 2 - Public Authoritative Servers - my original NIT was dealt with > but I note that anycast is now referenced here which is still extraneous, > we are not attempting to deal with the standard of how Public Authoritative > Servers be managed operationally > > Section 3 - now Section 5 - i note specifically the comment about: > > "In the case the HNA is a CPE, outsourcing to the DOI protects the home > network against DDoS for example." > > I personally would consider this a dangerously inaccurate statement. > > This offers NO protection against a DDoS, at best it (only) slightly > reduces the attack surface exposed but it provides no meaningful additional > protection. > > I specifically repeat this and recommend the statement be removed or > re-worded appropriately > > Section 3.2 - Original NIT dealt with > > 1.1 - now 3 - NIT dealt with > > 3.1 now 5.1 - Typo fixed > > 4.5.1 - now 6.5.1 - i believe this NIT to be well addressed now, the > reflowing of the document definitely helps here. > > Thanks > > -- > dnsdir mailing list > dns...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsdir > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Warren Kumari's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-homenet-front-end-naming-delegation-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ -- DISCUSS: -- Please see: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ I am (reluctantly) balloting DISCUSS on the following criteria: * The specification is impossible to implement due to technical or clarity issues. * The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. * It is unlikely that multiple implementations of the specification would interoperate, usually due to vagueness or incomplete specification. I apologize for doing this, as I know that this will be a difficult set of comments to address. This isn't just a few "here are the DISCUSS points", but rather "there are a sufficient number of lack of clarity issues (and readability issues) that I don't think it can be understood and implemented without ambiguity." I have reviewed most of the document, but have only transcribed my comments up to page 13. Because there are both nits and substantive comments on the same bits of text (and to stop this gettign even longer) I have not separated them into separate sections like I normally would. I wanted to send this out now, so that the authors, WG and AD can start reviewing and we can discuss some way to resolve this... -- COMMENT: -- Section 1: 1: O: The remaining of the document is as follows. P: The remainder of the document is as follows: C: Nit - Grammar 2: O: Section 3 provides an architectural view of the HNA, DM and DOI as well as its different communication channels P: Section 3 provides an architectural view of the HNA, DM and DOI as well as their different communication channels C: Nit - Plural. 3: O: Section 7 and Section 9 respectively details HNA security policies as well as DNSSEC P: Section 7 and Section 9 respectively detail HNA security policies as well as DNSSEC C: Nit - Grammar / plural Section 1.1: 4: O: Of these the link-local are never useful for the Public Zone, C: I don't really agree with the "never" - the document does discuss failing back to the Public zone if needed, and so this may sometimes be useful. I agree that it is much less common / useful, and this this is probably a nit... 5: O: "However, since communications are established with names which remains a global identifier, the communication can be protected by TLS the same way it is protected on the global Internet." C: "However" implies that the sentence follows on from a previous point and provides a refutation / comparison, and this sentence doesn't - it is more of a fragment / new thought. C: s/remains/remain/ (grammar) C: More text is needed here - I'm *assuming* that you are meaning that because the name is globally resolvable to an address, that this can be used to obtain a certificate for that name? If so, that's really not clear. Section 1.2: 6: O: "An alternative existing solution is to have a single zone, where a host uses a RESTful HTTP service to register a single name into a common public zone. " P: "An alternative existing solution for residential customers is to..." C: There are a number of alternative solutions, for example many companies use DHCP to populate a zone (usually using RFC 2136), Windows Active Directory does something similar, many cloud / hosting providers will add and remove entries, etc. 7: O: "This is often called "Dynamic DNS" [DDNS], and there are a number of commercial providers. While the IETF has defined Dynamic Update [RFC3007], in many - as far as the co-authors know in all cases - case commercial "Dynamic Update" solutions are implemented via a HTTPS RESTful API." C1: I think that you need to be much clearer that the "Dynamic DNS" you are talking about in the first sentence is different to Dynamic Updates. C2: I think that that is the wrong reference - RFC2136 is the Dynamic Updates RFC, RFC3007 wraps it in TSIG. C3: You have a repeated "case" (actually, "case"
Re: [homenet] Eric Rescorla's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS)
On Fri, Sep 1, 2017 at 10:41 AM, Eric Rescorla wrote: > > > On Thu, Aug 31, 2017 at 8:39 PM, Mark Andrews wrote: >> >> >> In message >> <150413520708.16860.14531912464478386147.idtrac...@ietfa.amsl.com>, >> Eric Rescorla writes: >> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-homenet-dot-13: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> > https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ >> > >> > >> > >> > -- >> > DISCUSS: >> > -- >> > >> >A. Recursive resolvers at sites using 'home.arpa.' MUST >> >transparently support DNSSEC queries: queries for DNSSEC >> >records and queries with the DO bit set ([RFC4035] section >> >3.2.1). While validation is not required, it is strongly >> >encouraged: a caching recursive resolver that does not >> >validate answers that can be validated may cache invalid >> >data. This in turn will prevent validating stub resolvers >> >from successfully validating answers. >> > >> > I don't understand the rationale for this requirement. As I understand >> > it >> > from this document, stuff ending in home.arpa cannot be DNSSEC >> > validated, >> > so what's it the business of this document to levy the requirement on >> > sites which support home.arpa that they do anything with DNSSEC at all. >> >> Wrong the responses can be validated. The output of the validation >> step is one of secure, insecure, or bogus. With the exception of >> home.arpa/DS and without private trust anchors being installed the >> output of that validation should be insecure for all answers from >> home.arpa. home.arpa/DS should validate as secure NODATA. >> >> In particular validation of the home.arpa/DS is important as it >> prevents the cache being poisoned with answers which prevent the >> stub proving that the home.arpa is supposed to exist and that it >> doesn't have a chain of trust from the root. > > > I don't see how this is different from any other kind of resolution. Jumpin' in the middle here. The root proves that .arpa exists. .arpa proves that home.arpa exists, but, as there is no DS record, it also proves that names under home.arpa are insecure, and so we can create foo.home.arpa, bar.home.arpa, etc. If recursive resolvers at sites using 'home.arpa.' DID NOT transparently support DNSSEC queries, then validating stubs would not be able to query the .arpa servers, and get back the proof showing that home.arpa is insecure, and so we would not make foo.home.arpa exist. Of course, if recursive resolvers at sites using 'home.arpa.' DID NOT transparently support DNSSEC queries they would break ALL validation, and validating stubs wouldn't be able to resolve anything at all... W > > -Ekr > >> >> Mark >> >> > ___ >> > homenet mailing list >> > homenet@ietf.org >> > https://www.ietf.org/mailman/listinfo/homenet >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-dot-14.txt
On Fri, Sep 1, 2017 at 2:46 PM, Walter H. wrote: > Hello, > > just one question for some better understanding ... > > I read this line > > "The domain name 'home.arpa.' is to be used for naming within > residential homenets." > > when this draft becomes an RFC - hopefully this year 2017 - then there > exists > an RFC, which gives you a domain name you can use in a home network/LAN > without conflicting to other things ..., the domain name 'home.arpa' > > but there still doesn't exist any for company networks, they most commonly > use > the domain name 'local', which I already noticed, that this conflicts to RFC > 6762 ... Around 2 months ago (AKA, *just* before the draft cutoff) I wrote https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00 -- this is specifically designed to be a reservation for a companies / organizations / test networks / disconnected networks, etc to be able to use. So far it has generated basically no discussion -- some of the purpose was simply to more fully discuss the issues, etc surrounding this sort of issue. Note that the document is not very well written, it was written on a plane and submitted in a rush. W > > Thanks, > Walter > > > On 01.09.2017 19:47, 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 Home Networking WG of the IETF. >> >> Title : Special Use Domain 'home.arpa.' >> Authors : Pierre Pfister >>Ted Lemon >> Filename: draft-ietf-homenet-dot-14.txt >> Pages : 11 >> Date: 2017-09-01 >> > > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Warren Kumari's No Objection on draft-ietf-homenet-dot-13: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-homenet-dot-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ -- COMMENT: -- This was originally a DISCUSS, but Ted nicely (and quickly!) addressed my concerns - clearing. Major issues: 1: I think that this document could benefit from additional review in the DNSOP WG - it got some (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that was a: while it was still homenet. b: primarily focused in terms of RFC6761 and not on the whole systems / interaction with existing behaviors, c: largely devolved into "does this do go in the root zone or not"?, d: 9 revisions back. The document feels vague about much of the details / expected behavior from all of the different players, and I think more focused review from more DNS people would help. 2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses both terms makes me think that they are different, but I don't know how. 3: The document says: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3).", but I do not see this being added to the locally served zones registry. This was raised in a previous review (Jon Mitchell, OpsDir (for v03) https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18/ ), and not implemented. I'm assuming there is a reason, but I haven't found the discussion. 4: The document describes what recursive servers should do with queries for things in home.arpa, but seems to gloss over some detail -- I think that the document would benefit from an overview showing the stub (and / or validating stub), an internal recursive / proxy, an external recursive, the local authoritative for home.arpa, and the .arpa servers, and clearly explain what the expected behavior / role for each one under various scenarios is. 5: Even with the above answered, I remain confused by the "what does a recursive resolver do" bit -- this discusses what a recursive server should do with a DS query for home.arpa - this (obviously) exists to prevent DNSSEC validating stubs from believing that foo.home.arpa is bogus. It also means that it is expected that queries from stubs will sometimes arrive at these recursive resolvers (and they "MUST behave as described in Locally Served Zones" is not simply to prevent pollution). If a query for printer.bedroom.home.arpa does arrive at a recursive, and it is configured as a locally served zone, it will return NXDOMAIN. This (obviously) breaks the lookup for printer.bedroom.home.arpa, but RFC8020 (" NXDOMAIN: There Really Is Nothing Underneath ") also says that this means that nothing exists in bedroom.home.arpa - I think that there needs to be some more text describing the deployment, and which set of queries go where. 6: Section 7. Delegation of ’home.arpa.’ This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’. I fully agree with the DS bit, but the "blackhole" bit feels VERY hand-wavey. Currently a lookup for home.arpa to these returns REFUSED instead of NXDOMAIN: $ dig +nostat +nocmd home.arpa @blackhole-2.iana.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7826 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;home.arpa. IN A The document just delegates this to ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’ - they're are not authoritative for home.arpa (and nothing in the doc makes them so), and so this does not return NXDOMAIN and instead amplifies the query load. Delegating them to RFC7535 servers *may* help, but I'm not sure. 7: "In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’." -- Ok, but how does this interact with the requirements on local-zones? I'm *guessing* it overrides it, and if I get a query for
Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)
Ok, I'm surprised - I spent much time with this review, and felt bad submitting a number of DISCUSS points close to the telechat. I thought that addressing them might end up in this going back to the WG -- but, your (really quick) responses more than adequately addresses my DISCUSS (and major concerns). Thank you, I'm clearing my discuss position -- more inline, but I'm a happy camper. On Wed, Aug 30, 2017 at 3:54 PM, Ted Lemon wrote: > On Aug 30, 2017, at 3:10 PM, Warren Kumari wrote: >> 1: Section 4. Domain Name Reservation Considerations, Subsection 4 >> If I'm a recursive server and I am configured "with a delegation to an >> authoritative server for that particular homenet’s instance of the domain >> ’home.arpa.’." then I have a local zone containing "home.arpa IN NS >> ". Unless I'm really confused, this means >> that I have to make myself authoritative for .arpa, which will a: break >> everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to >> validating stubs. (See also #5). Perhaps you mean that there should be >> something like (BINDism): zone "home.arpa" { >>type forward; >>forwarders { 192.0.2.1; 192.0.2.2; }; >> }; >> This possibility only came to me after much thought, and I do not think that >> it >> could be described as "a delegation". I also do not think that this is a >> standard / well defined behavior. > > Yup, that's bogus. Is this better? > > In addition to the behavior specified above, recursive > resolvers that can be used in > a homenet MUST be configurable to forward queries for > 'home.arpa.' and subdomains of > 'home.arpa.' to an authoritative server for 'home.arpa.'. > This server will provide > authoritative data for 'home.arpa.' within a particular > homenet. The special > handling for DS records for the 'home.arpa.' delegation is > still required. Much better, thanks. > > >> 2: Section 4. Domain Name Reservation Considerations, Subsection 4 >> "Caching resolvers conforming to this specification MUST support DNSSEC >> queries." This is a MUST, so it's important to understand, but I don't >> understand what it actually means. What is a "DNSSEC query"? It is just one >> with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I >> don't know what this means, so I don't know if it applies to me / what I >> should >> do. > > I think this is clarified in the -13 version of the document. Is this > review based on that version, or on -12? Here is the new text: > > Recursive resolvers at sites using 'home.arpa.' MUST > transparently support > DNSSEC queries: queries for DNSSEC records and queries with > the DO bit set > ( section 3.2.1). While validation > is not required, it > is strongly encouraged: a caching recursive resolver that > does not validate > answers that can be validated may cache invalid data. This > in turn will prevent > validating stub resolvers from successfully validating > answers. WFM. > >> 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST >> behave as described in Locally Served Zones ([RFC6303] Section 3). That is, >> queries for domains that are subdomains of ’home.arpa.’ MUST NOT be >> forwarded, >> with one important exception: ..." This says that I must not forward for >> *domains* that are *subdomains* of home.arpa. The example shows a lookup for >> NS >> for 'home.arpa', so presumably this is actually talking about subdomains of >> home.arpa. So, I have no idea what to do for lookups within home.arpa itself >> -- what do I do with query for the A record for printer.home.arpa? It is >> simply >> a name within home.arpa; I have no way of knowing if it is a subdomain of >> home.arpa but it certainly isn't a domain that is a subdomain of home.arpa >> (because there are only three label, not four). > > Yes, the other text had the same problem. How about "queries for > 'home.arpa.' and subdomains of 'home.arpa.'"? WFM. Thanks. > >> -- >> COMMENT: >> -- >> >> Major issues: >> >> 1: I think that this document could benefit from add
[homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-homenet-dot-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ -- DISCUSS: -- 1: Section 4. Domain Name Reservation Considerations, Subsection 4 If I'm a recursive server and I am configured "with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’." then I have a local zone containing "home.arpa IN NS ". Unless I'm really confused, this means that I have to make myself authoritative for .arpa, which will a: break everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to validating stubs. (See also #5). Perhaps you mean that there should be something like (BINDism): zone "home.arpa" { type forward; forwarders { 192.0.2.1; 192.0.2.2; }; }; This possibility only came to me after much thought, and I do not think that it could be described as "a delegation". I also do not think that this is a standard / well defined behavior. 2: Section 4. Domain Name Reservation Considerations, Subsection 4 "Caching resolvers conforming to this specification MUST support DNSSEC queries." This is a MUST, so it's important to understand, but I don't understand what it actually means. What is a "DNSSEC query"? It is just one with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I don't know what this means, so I don't know if it applies to me / what I should do. 3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3). That is, queries for domains that are subdomains of ’home.arpa.’ MUST NOT be forwarded, with one important exception: ..." This says that I must not forward for *domains* that are *subdomains* of home.arpa. The example shows a lookup for NS for 'home.arpa', so presumably this is actually talking about subdomains of home.arpa. So, I have no idea what to do for lookups within home.arpa itself -- what do I do with query for the A record for printer.home.arpa? It is simply a name within home.arpa; I have no way of knowing if it is a subdomain of home.arpa but it certainly isn't a domain that is a subdomain of home.arpa (because there are only three label, not four). -- COMMENT: -- Major issues: 1: I think that this document could benefit from additional review in the DNSOP WG - it got some (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that was a: while it was still homenet. b: primarily focused in terms of RFC6761 and not on the whole systems / interaction with existing behaviors, c: largely devolved into "does this do go in the root zone or not"?, d: 9 revisions back. The document feels vague about much of the details / expected behavior from all of the different players, and I think more focused review from more DNS people would help. 2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses both terms makes me think that they are different, but I don't know how. 3: The document says: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3).", but I do not see this being added to the locally served zones registry. This was raised in a previous review (Jon Mitchell, OpsDir (for v03) https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18/ ), and not implemented. I'm assuming there is a reason, but I haven't found the discussion. 4: The document describes what recursive servers should do with queries for things in home.arpa, but seems to gloss over some detail -- I think that the document would benefit from an overview showing the stub (and / or validating stub), an internal recursive / proxy, an external recursive, the local authoritative for home.arpa, and the .arpa servers, and clearly explain what the expected behavior / role for each one under various scenarios is. 5: Even with the above answered, I remain confused by the "what does a recursive resolver
Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt
On Mon, Jul 31, 2017 at 5:36 AM, Ted Lemon wrote: > On Jul 31, 2017, at 1:02 AM, Mark Andrews wrote: > > The delegatation is INSECURE and SIGNED not UNSIGNED. The wording > here is *important*. > > > Can you explain what the distinction is, and what the problem is that you > see in point five? The reason I ask is that we explicitly changed the > wording from "insecure" to "not signed" because someone else said that it > wasn't clear what "insecure" meant. It seems to me that the current > language is explicit and unambigious; I think this is better than being > "correct." So what is the bad outcome that might occur as a result of > using the term "not signed" rather than "insecure"? Having recently had exactly this discussion with someone, this area is fraught with opportunities for misunderstandings. Let's take example.com as an example[0]. The .com zone is signed. Example Corp hired a DNS geek, who signed the example.com zone, but never quite got around to publishing a DS record in the parent. There is now a signed, insecure delegation to a signed zone; the delegation itself is signed (.com is a signed zone and so there there is an RRSIG for the NS for example.com), but there is no DS record, so it is insecure. It really is an insecure delegation, not an unsigned delegation -- calling it unsigned would be confusing to many people. The person I was discussing it with wasn't aware of the term "insecure delegation" and assumed that it meant an "unsigned delegation", which is, um, difficult to achieve in a non-NSEC3 OO zone... I spend an almost infinite amount of time[1] trying to explain this very point (to someone who understands DNSEEC) over the phone - it's tricky to communicate without a whiteboard and / or diagram. I ended up opening an issue on the terminology-bis document to get it added: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/26#issuecomment-314275871 W [0]: For the purpose of discussion, let's pretend that .COM uses NSEC, not NSEC3 with Opt-Out. [1]: Ok, perhaps it wasn't almost infinite, but it sure felt like it... > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet