[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-rfc8109bis-06: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-rfc8109bis-06: Yes 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-dnsop-rfc8109bis/ -- COMMENT: -- small update to my ballot. I saw and actually do agree with Mark Andrews that the text about source port randomization should mention DNS COOKIES as well: I know this is late in the process but why is DNS COOKIE not suggested as it is much better than source port randomisation for eliminating spoofed responses? It even works when NATs that de-randomise source ports are in the path. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-zoneversion-10: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-zoneversion-10: Yes 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-dnsop-zoneversion/ -- COMMENT: -- Thanks for addressing my concerns. I have updated my Ballot to YES ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-zoneversion-08: 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-dnsop-zoneversion/
--
DISCUSS:
--
Just a few hopefully minor issues to talk about.
In section 3.2, why is NXDOMAIN not listed? When asking for "foobar.nohats.ca",
couldn't it be useful to get the zone version, if the nameserver is
authoritative for "nohats.ca" and has no delegation for "foobar.nohats.ca." ?
What should an authoritative nameserver return as zone version if it is
configured as authoritative nameserver but can't get the zone version (eg
because "no permission to read file") One way would be to allow it to return
a zero length for ANY type and define that as an error condition.
It seems DNAMEs could lead to involving two or more zones the nameserver is
authoritative for. How should this be handled? Only use the first DNAME's
zone's version?
The type leaves no room for proprietary (or somehow encrypted) zone versions,
as the DE advise states:
In particular the reference should state clear instructions for
implementers about the syntax and semantic of the data
If you did not mean to exclude encrypted zone version data, perhaps clarify
the advise to the DE? Or are those deployments meant to use the
"local/experimental" use, in which case calling it "private use" might be
better?
Have you considered leaving a small initial space for "RFC Required" policy?
Eg 0-15 ? With only 253 types available, I'd feel happier with that,
especially if this supports proprietary types.
Should implementers be warned not to blindly copy this EDNS(0)
options from the query of a DNS client onwards? Doing this could cause
amplification attacks if some server uses a non-SOA-SERIAL type with a
long length.
--
COMMENT:
--
A name server SHOULD include zone version information for
Can this be rephrased as:
When asked for a zone version, a responding name server SHOULD
include zone version information for [...]
Just to avoid implementers from reading this and adding it when the DNS
client did not ask for it.
The OPTION-LENGTH for this type MUST be set to 6 in responses.
Maybe say:
The EDNS(0) OPTION-LENGTH for this type MUST be set to 6 in
responses.
I was initially confused and assumed it was talking about what this document
calls VERSION, so alternatively instead of saying what the OPTION-LENGTH is,
perhaps say:
The VERSION length for SOA-SERIAL MUST be four octets, resulting in
the OPTION-LENGTH for this EDNS(0) type option to be set to 6.
My OCD triggers on these unbalanced parentices:
; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001
(example.com.)")
(note it seemed to render badly in my browser, but copy&paste seemed to fix it
again?)
The example dig command should have +norecurse :)
Why does the example contain an AUTHORITY SECTION for an AA answer
with data? Seems .com does that but other nameservers I tested do
not (eg nohats.ca or .nl). This makes it a bit unclear if the setting
of zoneversion requires that the Authority Section is included. Maybe
a clarifying note can be added? I assume this related to query minimalization?
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Paul Wouters' Yes on draft-ietf-dnsop-dnssec-bootstrapping-10: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dnssec-bootstrapping-10: Yes 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-dnsop-dnssec-bootstrapping/ -- COMMENT: -- Thanks for addressing all my DICSUSS items and comments. I have updated my ballot to Yes, One last comment left on the new text: If all else fails, the domain owner might have to request the removal of all DS records (e.g., by using the special-value CDS/CDNSKEY RRset specified in [RFC8078] Section 4) and have the transfer performed I think the "e.g." sentence should be removed. This is "in case the dns operator is not cooperating", so in that case one would assume they wouldn't update these records either (and the domain owner would need to go through their registrar website, which would cause the records to be removed at the parent via EPP. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dnssec-bootstrapping-08: 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-dnsop-dnssec-bootstrapping/ -- DISCUSS: -- I have a few items to discuss and some comments. I'm leaving out the discussion of _signal as a name, as this discussion is taking place on dnsop. While I have a preference, I'll abide by the consensus call of the dnsop wgchairs. All Sections: This document uses the term "bailiwick" a lot. The DNS Terminology series of RFCs recommands to avoid this term and use "in-domain" or "not in-domain". Section 1: Readers are expected to be familiar with DNSSEC, including [RFC4033], [RFC4034], [RFC4035], [RFC6781], [RFC7344], and [RFC8078]. It should say: Readers are expected to be familiar with DNSSEC [BCP237]. It includes the same RFCs but BCP237 will get updated in the future. Section 2: The DS enrollment methods described in Section 3 of [RFC8078] are deprecated and SHOULD NOT be used. I find this to be inconsistent with the Update: 8078 clause, as without "Section 3", you are basically obsoleting the entire 8078. I don't think this document should obsolete it, it should augment it. I would rewrite the above like: The DS enrollment method described in this document provides more security than the methods described in Section 3 of [RFC8078], and are therefor RECOMMENDED in favour of the methods specified in [RFC8078]. If the authors/WG insists on the "deprecated" language, it should also Obsolete: 8078. But be aware that the document currently does make references to it, which it cannot do if it obsoletes the document. Section 4.1.1: It is not clear to me if the "signaling domain" really has to be its own zone or not. eg: _dsboot.example.co.uk._signal.ns1.example.net Could this be signed using the DNSKEY of "example.net", or does the document insist on a zone cut at _signal.ns1.example.net ? I think zone cut should not be mandatory, in which case the language that uses "signaling domain" should be cleaned up to make this clear. That would also mean language like this is no longer needed: The records are accompanied by RRSIG records created using the key(s) of the respective signaling zone. It could just state something like: These records are signed with DNSSEC just like any other zone data. Later on in the Operational Considerations, the issue is mentioned and it states zone cuts are not mandatory. So I do think this needs some cleanup. in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets located at the signaling name under any signaling domain, including failure of DNSSEC validation, or unauthenticated data (AD bit not set); I think it also needs to exclude signaling signatures made by any DNSSEC keys upstream from the DNS hoster's zone. Eg if we have _signal.ns1.example.net we also do not want to see the CDS/CDNSKEY RRsets signed by .net or the root. Section 5: CDS/CDNSKEY records and corresponding signaling records MUST NOT be published without the zone owner's consent. This opens a can of worms. How is an implementer going to codify this MUST? The only usable interpretation I can see is that the DNS hoster, by being assigned the DNS hoster, has permissions to DNS host the zone as it sees fit, and thus do DNSSEC. And especially not bother the zone owner with techno-babble for permissions. Likewise, the child DNS operator MUST enable the zone owner Again, this wades into legalize and contractual matters best left outside of RFC specifications. a zone cut ensures that bootstrapping activities do not require modifications of the zone containing the nameserver hostname. Why does this matter? -- COMMENT: -- If a child DNS operator implements the protocol If a child DNS operator implements this specification (i.e. have a valid DNSSEC chain of trust) I would say: (i.e. have a valid publicly resolvable DNSSEC chain of trust) Otherwise one could argue the parent has to have some "special configuration" (eg trustanchors) and then it is "valid". that are authoritative for the signaling domains
[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-dns-error-reporting-08: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-08: Yes 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-dnsop-dns-error-reporting/ -- COMMENT: -- Thanks for the extensive discussion resolving my DISCUSS points. I've updated my ballot to Yes. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-dns-error-reporting-08: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-08: Yes 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-dnsop-dns-error-reporting/ -- COMMENT: -- Thanks for the extensive discussion resolving my DISCUSS points. I've updated my ballot to Yes. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-error-reporting-07: (with DISCUSS)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-07: 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-dnsop-dns-error-reporting/ -- DISCUSS: -- This document gives no guidance on the content of the TXT resource record RDATA for this record. Based on this, I assume the error report query is of qtype TXT, but this is not specified anywhere in the document. Someone could use a qtype of CNAME or ANY or just A or . Can this be stated explicitly ? In Section 6.1.1. Constructing the Report Query, only the QNAME construction is documented, not the QTYPE (or CLASS but there is a reference that says only IN is supported) While no guidance on (TXT?) RDATA sending is fine, there should really be a Security Consideration on what to do with any RDATA. Let's avoid another vector for log4j. The reporting resolver MUST NOT use DNS error reporting to report a failure in resolving the report query. This might be tricky to implement. The resolver might not know why another thread is resolving some A/ record. For example if nohats.ca uses a reporting fqdn of foobar.fi, why shouldn't validation failures on foobar.fi try to report that to foobar.fi, if they themselves use a reporting fqdn. Similarly, recommending disabling DNSSEC for these queries can be tricky, if resolving the reporting fqdn requires a number of related DNS queries for NS, DS, A/, CNAMEs). I think it is better to not recommend this and let failures be failures. If the reporting fqdn fails to resolve, abort trying to report the failure. Which of course brings up: Should there be a consideration for the reporting fqdn not being in-domain ? eg ns1.nohats.ca serving nohats.ca should probably not use er.nohats.ca. The er QNAME construction assumes there was only 1 QTYPE. There are drafts being floated that have more than one QTYPE. How to construct the QNAME for those? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-rfc8499bis-09: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-rfc8499bis-09: Yes 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-dnsop-rfc8499bis/ -- COMMENT: -- Thanks to the DNSOP WG for keeping this document up to date with the latest developments and language shifts in the operational communities. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-caching-resolution-failures-07: Yes 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-dnsop-caching-resolution-failures/ -- COMMENT: -- Thanks for this document and my apologies for being involved/related to two of the five outages you described :-) Consistent with [RFC2308], resolution failures MUST NOT be cached for longer than 5 minutes. If an expired RRSIG has a TTL of 3600, what should happen? The resolution failed because the signature is no longer valid but the individual components of this validation failure are all successful lookups of RRs that are now in the cache. Wouldn't this result in a resolution failure of 3600? How would an implementation limit this to 5 minutes? By deleting the RRSIG from its cache within 5 minutes, overriding its TTL? If so, is there value stating this in the document? also known as 'lame' I thought the WG agreed the definition of 'lame' was not agreed upon and the term is no longer being favoured for use. Why not just remove this part? To prevent such unnecessary DNS traffic, security-aware resolvers MUST cache DNSSEC validation failures, with some restrictions. What are these "some restrictions" ? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: Yes 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-dnsop-alt-tld/ -- COMMENT: -- Some of my comments might be DISCUSS-worthy (my apologies), but I really don't want to block this document for any further time. But please do take my comments into considerations if you can do a quick ref update. The term pseudo-TLD as defined here is not how I've seen the term used. A pseudo TLD as I've seen it used is a TLD that's one step below a real TLD and runs as a general GTLD (open registration), eg "uk.com". I guess I would qualify the use in this document more as "fake TLD", but I can see how that might come over as even more perogative. So I am fine with the current definition and use case. Perhaps a "to be confused with" note could be added, but is not strictly required. 4. Caching DNS servers SHOULD NOT recognize names in the .alt pseudo-TLD as special and SHOULD NOT perform any special handling with them. There is value for a recursor to "pre-load" the proof of non-existence of ".alt" (the entire branch in the hierarchy) to avoid any potential leakage of subdomains within alt. It could potentially also reduce error message logs if someone starts using .alt not as a real hierarchy or using non-DNS valid characters in their name, eg Ulabel stuff or even binary stuff like 0x000100013616c7400. They could also just return NXDOMAIN instead of forwarding the query to the root servers to avoid a privacy leak. Or it could modify the question foo "foo.alt" and only send "alt" to the root. I see no reason such additional protection mechanisms need to violate this "SHOULD NOT" clause. Why not flip the statement around? 4. Caching DNS servers MAY recognize names in the .alt pseudo-TLD as special and MAY perform special privacy preserving methods to return (DNSSEC signed) NXDOMAIN answers to prevent leaking entries under the .alt pseudo-TLD into the global DNS. 5. Authoritative DNS servers SHOULD NOT recognize names in the .alt pseudo-TLD as special and should not perform any special handling with them. Any reason the second "should not" is lowercase ? Note that I do agree here, and would even say MUST NOT so that people can use DNS technology even if not rooted in the global DNS for their .alt names without having to modify existing DNS software (eg run a shadow .alt using DNS on port 666 or something) 6. DNS server operators will treat names in ... I find the use of "will" here a little odd. Perhaps: 6. DNS servers and operators, which whave no special handling for the .alt pseudo-TLD will end up treating names in ... 7. DNS registries/registrars for the global DNS will never register names in the .alt pseudo-TLD because .alt will not exist in the global DNS root "will never" seems wishful thinking. I've seen some very fraudulent stuff happen with DNS registries/registrars. eg what if one of them will support pseudo-TLDs along with real DNS domains, and includes bogus .alt registrations? Perhaps: 7. DNS registries/registrars for the global DNS can never legitimately register names in the .alt pseudo-TLD because .alt will never exist in the global DNS root Again, my apologies to Warren for not balloting a blanc YES :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-catalog-zones-08: 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-dnsop-dns-catalog-zones/ -- DISCUSS: -- # Sec AD review of draft-ietf-dnsop-dns-catalog-zones-08 CC @paulwouters 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. This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows automated tools to process items (eg to produce github issues) Note that I am a happy user of catalog zones since a few months. While I originally thought this seemed like an "if all you have is a DNS hammer" solution, it actually has some very clear advantages over other configuration synchronization methods. Thanks for this work, I am a fan! I do have some issues I'd like to discuss though :) ## DISCUSS ### Section 4.3.1 Versioning What should one do if the version supported is lower than the version of zone received? Attempt to understand it? preventively fail? Are version 1 and 2 compatible? In what ways are they not? Should perhaps version 1 catalog zones always be ignored ? ### Group Properties It seems like Section 4.4.2 defines "group properties" that are standardized, while Section 4.5 specifies Private Use group properties. But there is actually no registry created for Group Properties, and no definitions other than "examples" are given. This makes the status of, for example "nodnssec", unclear. Is this a custom (eg bind implementation only) property or is this really a custom private use entry, in which case the example is bad as it belongs under .bind.ext. Since "nodnssec" seems a real use case, why does this document not create an IANA registry for Catalog Zone Group Properties and places "nodnssec" in it? ### 5.3 "MUST be removed"? ``` Only when the zone was configured from a specific catalog zone, and the zone is removed as a member from that specific catalog zone, the zone and associated state (such as zone data and DNSSEC keys) MUST be removed. ``` What is "removed" here? I think perhaps it should be limited to "MUST no longer be served". For example, it would be bad if the operator made an error, and ended up briefly removing the zone and "removing" (aka destroying) some private DNSSEC keys, complicating the zone restoration. Also, perhaps the implementation wants to simply keep the state on disk but move it to a /var/lib/xxx/zones/archived/ directory. The use of "remove" sounds like that might not be allowed. ### Operational Considerations What are the risks and benefits of Extension group properties? Should one try to standardize these instead? Why is this document not doing that based on its operational experience with eg bind and knot and powerdns ? ### Security Considerations Dealing with high value domains eg gmail.com is missing. If a large DNS hoster would enable catalog zones for its customers, how can it prevent rogue takeovers? If fully automated, it can never be safely deployed. If each zone needs a manual check, well than we don't really have "catalog zones" auto-populating name servers. Is there an expectation that nameservers can do some authorization call before adding a new domain that is already delegated elsewhere? Eg if GoDaddy uses catalog zones, and I am their tiny customer with "nohats.ca" and then add a new zone "gmail.com", that could cause a significant disruption. Especially if the malicious person would create another domain that depends on "gmail.com" in such a way that GoDaddy's servers will start sending "gmail.com" data in their additional data reply for other domains. The section only has a "consumer(s) MAY ", which in my opinion, is far too weak as a security control. As the above example shows, it is just too easy to start poisoning nameservers via implementations that skip this one MAY clause in the Security Considerations. -- COMMENT: -- ## Comments ### Appendix A The appendix implementation status only mentions version 2 for bind. Presumably, the other implementations never supported version 1, but this could be made more clear (although granted, it is a little weird so late in the process to do this as it
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-rfc5933-bis-12: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-rfc5933-bis-12: 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-dnsop-rfc5933-bis/ -- DISCUSS: -- I agree with Roman's DISCUSS on the stream of the document, and his proposed solution. Additionally, I have some items: According to RFC6840 [RFC6840], Section 5.2 systems that do not support these algorithms may ignore the RRSIG, DNSKEY and DS records created with them. I do not read that as "may" (lowercase), but more as a MUST. That is, returning a ServFail when you see these is not allowed. The "may" here means that thiswould be a valid response. Zone Signing field should be changed to "N". I believe I already mentioned this before. This change should NOT be made. The deprecated value is one that was only valid for Zone Signing. Deprecating the algorithm should not change its existing function. -- COMMENT: -- RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security Extensions, called DNSSEC. This document could be the first user of using [BCPxx] (draft-ietf-dnsop-dnssec-bcp, currently at RFC Editor) instead of referencing an incomplete set of what DNSSEC is. Note: Algorithm numbers 23 and 5 are used in this document as an example, since the actual numbers have not yet been assigned. This note should be more clearly marked using [brackets] so that the RFC Editor knows it is meant for them to remove/update and/or the authors to update upon their allocation and updated examples ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bcp-05: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dnssec-bcp-05: 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-dnsop-dnssec-bcp/ -- DISCUSS: -- Since draft-ietf-dnsop-rfc5933-bis is in IETF Last Call now, I think it is worth waiting on and updating this text: The GOST signing algorithm [RFC5933] was also adopted, but has seen very limited use, likely because it is a national algorithm specific to a very small number of countries. To add a reference that RFCXXX updates the GOST algorithms for DNSSEC (but that it is uncertain at this point whether it will be widely adopted) I could be convinced for this document to not wait, but then I do think this paragraph should state that it is NOT RECOMMENDED to implement RFC5933 since the underlying GOST algorithms have been deprecated by its issuer. -- COMMENT: -- One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. Another purpose is to move DNSSEC to Best Current Practice status. I think another purpose not mentioned, which for me was a main motivator for this document, is to provide a single RFC reference for other documents that want to point to "DNSSEC" using a single reference instead of referring to the 3 core components (in an incomplete way) More than 15 years after the DNSSEC specification was published, it is still not widely deployed. Recent estimates are that fewer than 10% of the domain names used for web sites are signed, and only around a third of queries to recursive resolvers are validated. What is the value of this paragraph? You wouldn't want to have a single IPv6 reference RFC say this either :) This document will be "the reference RFC" for a long time. It should not have dated/outdated statistics in it. However, this low level of implementation does not affect whether DNSSEC is a best current practice I don't think the level of implementation is low. It is actually quite high. Practically all DNS software implements it. I think you meant deployment ? NITS: which algorithms recursive resolver operators should or should not validate. change to: which algorithms recursive resolver operations should or should not use for validation (the algorithms themselves are not validated) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-nsec3-guidance-10: (with COMMENT)
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-nsec3-guidance-10: Yes
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-dnsop-nsec3-guidance/
--
COMMENT:
--
My DISCUSS and comments were addressed in -09. Thanks!
Good document, nice to see operations feedback back into the IETF via a new BCP.
Resolved DISCUSS:
#1: This document updates RFC 5155 but has no Updates: clause and no reference
of this in the Abstract. In case this would not be seen as an Update:able
offense, then the text "Note that this specification updates [RFC5155]" should
be changed :)
Resolved comments:
The algorithm field is not discussed by this document.
Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are
discussed?
The NSEC3PARAM flags field currently contains no flags, but
individual NSEC3 records contain the "Opt-Out" flag
This reads a little odd. Because the IANA NSEC3param registry lists 1 flat, the
opt-out flag:
https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1
Maybe a sentence more clearly stating there is currently only one flag defined
and that is opt-out and then discuss it.
are encouraged to use a flags value of 0 (zero)
And rewrite this to say "are encouraged to not use the opt-out flag" so if in
the future we define another flag, we don't have to errata or Update: this
document for this one line mentioning 0.
The first
hash is typically sufficient to discourage zone enumeration performed
by "zone walking" an NSEC or NSEC3 chain.
NSEC uses no hashing, so this sentence reads a little odd. Perhaps:
The first
hash with NSEC3 is typically sufficient to discourage zone enumeration
performed by "zone walking" an unhashed NSEC chain.
If NSEC3 must be used, then an iterations count of 0 MUST be used to
alleviate computational burdens.
I think we need a sentence here (or in the section 2.4 above) that explains the
iterations count of 0 means 1 hashing operation is done. Eg it is an "extra
iteration count". I'd like to prevent implementors from thinking nsec3 can be
unhashed completely.
Appendix D needs a note to the RFC Editor to remove itself.
Appendix E lists a bunch of implementations. Normally, this would be placed in
an Implementation Status section, that is removed before publication. Should
this section really be contained within this document?
nits:
"within the Internet" ? I'd probably use "on the Internet" :)
"tamper-resistance proof" -> "tamper-resistant proof" ?
"repeating that hashing algorithm" -> "repeating that hashing using the same
algorithm"
Remove "ftp" from the example list in Section 2.3 as we deprecated it? The less
credit we give it, the better :)
in deploying both RFC4470 or NSEC3
This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"
"and the zone resigned." -> "and the full zone needs to be resigned."
"and lower their default acceptable limits over time." -> "but lower their
default acceptable limits over time."
There is a weird rendering of {RFC8914} instead of [RFC8914]
I think Petr Špaček would like to see his last name fixed :)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-nsec3-guidance-08: 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-dnsop-nsec3-guidance/
--
DISCUSS:
--
#1: This document updates RFC 5155 but has no Updates: clause and no reference
of this in the Abstract. In case this would not be seen as an Update:able
offense, then the text "Note that this specification updates [RFC5155]" should
be changed :)
--
COMMENT:
--
Good document, nice to see operations feedback back into the IETF via a new BCP.
comments:
The algorithm field is not discussed by this document.
Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are
discussed?
The NSEC3PARAM flags field currently contains no flags, but
individual NSEC3 records contain the "Opt-Out" flag
This reads a little odd. Because the IANA NSEC3param registry lists 1 flat, the
opt-out flag:
https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1
Maybe a sentence more clearly stating there is currently only one flag defined
and that is opt-out and then discuss it.
are encouraged to use a flags value of 0 (zero)
And rewrite this to say "are encouraged to not use the opt-out flag" so if in
the future we define another flag, we don't have to errata or Update: this
document for this one line mentioning 0.
The first
hash is typically sufficient to discourage zone enumeration performed
by "zone walking" an NSEC or NSEC3 chain.
NSEC uses no hashing, so this sentence reads a little odd. Perhaps:
The first
hash with NSEC3 is typically sufficient to discourage zone enumeration
performed by "zone walking" an unhashed NSEC chain.
If NSEC3 must be used, then an iterations count of 0 MUST be used to
alleviate computational burdens.
I think we need a sentence here (or in the section 2.4 above) that explains the
iterations count of 0 means 1 hashing operation is done. Eg it is an "extra
iteration count". I'd like to prevent implementors from thinking nsec3 can be
unhashed completely.
Appendix D needs a note to the RFC Editor to remove itself.
Appendix E lists a bunch of implementations. Normally, this would be placed in
an Implementation Status section, that is removed before publication. Should
this section really be contained within this document?
nits:
"within the Internet" ? I'd probably use "on the Internet" :)
"tamper-resistance proof" -> "tamper-resistant proof" ?
"repeating that hashing algorithm" -> "repeating that hashing using the same
algorithm"
Remove "ftp" from the example list in Section 2.3 as we deprecated it? The less
credit we give it, the better :)
in deploying both RFC4470 or NSEC3
This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"
"and the zone resigned." -> "and the full zone needs to be resigned."
"and lower their default acceptable limits over time." -> "but lower their
default acceptable limits over time."
There is a weird rendering of {RFC8914} instead of [RFC8914]
I think Petr Špaček would like to see his last name fixed :)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
