[DNSOP] Dnsdir last call review of draft-ietf-dnsop-must-not-sha1-03
Reviewer: Florian Obser Review result: Ready with Issues 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 Issue = | 2. Deprecating RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms in DNSSEC | Validating resolvers MUST continue to support validation using these | algorithms as they are diminishing in use but still actively in use | for some domains as of this publication. Thus, validating resolvers | MAY treat RRSIG records created from DNSKEY records using these | algorithms as an unsupported algorithm. Éric flagged the previous wording in his AD review of version -02. I still do not get what the new wording is trying to say. How does one MAY do a thing that one MUST do at the same time? Are you maybe trying to say that a validating resolver has two choices: 1. Implement RSASHA1 and RSASHA1-NSEC3-SHA1 and do proper validation 2. Stop implementing RSASHA1 and RSASHA1-NSEC3-SHA1 and treat the answer as insecure But a validating resolver MUST NOT treat an answer as bogus solely because it uses RSASHA1 or RSASHA1-NSEC3-SHA1. Once that issue is resolved the document is ready to go. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Speaking of names that don't exist
On 2025-02-06 08:56 +01, Philip Homburg wrote: >>What we all keep ignoring is that .internal DOES NOT WORK WITH >>BRING YOUR OWN DEVICE scenarios Reverse for RFC1918 addresses >>work with BYOD because we have public AS112 servers that serve >>UNSIGNED reverse zones. This breaks the DNSSEC chain of trust >>cleanly allowing the zones to be used by everyone. We have >>FAILED to do this for >>.internal. So either every device needs to know a priori that DNSSEC >>doesn't work for .internal which makes it a special use domain >>or we add .internal to the root with an insecure delegation to >>break the chain of trust cleanly. > > I think it is clear that IANA (or ICANN) do not want a delegation in the > root for internal. So we need to find another way. > > It is safe to say that the only software running on a host that needs > to be aware of .internal is software that does DNSSEC validation. Most stub > resolvers, non-validating forwarders, etc. They don't need to do anything > special. > > So the requirement we should place on validators in that they come by > default with a negative trust anchor for .internal. [Dreaming of a future where every / most stubs do their own validation.] That is a very big hammer and I don't think we should do that. I agree that .internal will not work with BOYD but I'd argue that the majority of devices will not be brought to a place where they have to resolve .internal. I think having an NTA is surprising and nontransparent. It opens up devices that don't care about .internal to attacks. An insecure delegation in the root OTOH is at least transparent. > > So that would indeed make INTERNAL a special-use domain name. > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- In my defence, I have been left unsupervised. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: New draft regarding RFC7050
On 2024-10-24 09:28 +11, Jen Linkova wrote: > On Tue, Oct 22, 2024 at 1:42 AM Florian Obser wrote: >> It occurred to me that a validating stub resolver still needs to know if >> its upstream is messing with DNS. With RFC9606 we can just ask the >> resolver what it's doing, so I put up >> https://datatracker.ietf.org/doc/draft-fobser-resinfo-dns64/ >> >> A validating stub can then avoid that resolver or do more fancy things >> like spotting that the resolver did DNS64 synthesis, ignore that answer >> and do its own synthesis using the 8781 prefix... > > Do you think it might be useful to explain those scenarios in the draft? > Because an uneducated reader (like me) might wonder "why does the > resolver need to know" and "what problem does this new feature > solve?". Yes, thanks for requesting this. Turns out I was wrong, I'm always forgetting about the CD (checking disabled) flag. I went back to RFC 6147 and re-read 5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode All the way at the end it has: 3. If the CD bit is set and DO is set, then vDNS64 MAY perform validation, but MUST NOT perform synthesis. It MUST return the data to the query initiator, just like a regular recursive resolver, and depend on the client to do the validation and the synthesis itself. I also went back to check my code and it does the right thing. Basically a validating DNS client that talks to an upstream resolver MUST set DO and CD if it wants to do its own validation. That is true regardless of DNS64. I'm preparing an -02 that rips out all the DNSSEC commentary to not have a draft with misleading information lingering. Maybe someone over in ADD still has use for this, but I only need PREF64. 7050 can just go away ;) Thanks, Florian > > P.S. Thank you for posting -01 and removing yet another way to > discover the prefix ;) > > -- > Cheers, Jen Linkova -- In my defence, I have been left unsupervised. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [EXTERNAL] Re: New draft regarding RFC7050
Hi, On 2024-10-21 15:53 UTC, Tommy Jensen wrote: > Hey Florian, > > Thank you for the feedback, and thank you for sharing your draft. My main > concern with your -00 is the introduction of yet another mechanism for > discovering the prefix: > > The DNS resolver MAY return an IPv6 prefix or a comma separated > list of prefixes to indicate not just that DNS64 is being > performed but also to let the client know which prefix or prefixes > are in use. The prefixes MUST be represented using the canonical > representation format of [RFC5952]. > > Please do not give implementors the temptation. We do not need another > discovery mechanism and the conflict resolution guidance that would require. I'm happy to drop this and just have a flag. I thought I had a use for it. If the RESINFO and PREF64 do not agree one could deduce that one is talking to the "wrong" resolver. But that's probably not very useful and the risk people doing stupid things with it is probably too high. > > Thanks, > Tommy > >> -Original Message- >> From: Florian Obser >> Sent: Monday, October 21, 2024 7:43 AM >> To: Nick Buraglio >> Cc: dnsop@ietf.org; Jen Linkova ; Tommy Jensen >> >> Subject: [EXTERNAL] Re: [DNSOP] New draft regarding RFC7050 >> >> On 2024-09-09 17:51 -05, Nick Buraglio wrote: >> > dnsop folks, >> > >> > Based on some conversations and discussions at the end of the second >> > session at 120, several of us worked out a draft to address what we >> > believe are some notable details in RFC7050. This draft was just >> > submitted to the datatracker, and we would appreciate any input, >> > comments, corrections, and productive discussion from the expertise of >> > the group. The draft can be read at >> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata >> > tracker.ietf.org%2Fdoc%2Fdraft-buraglio-deprecate7050%2F&data=05%7C02% >> > >> 7CJensen.Thomas%40microsoft.com%7Cd8fc7fd951164c6fef2108dcf1dea66d%7 >> C7 >> > >> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638651185889707957%7CU >> nknown >> > >> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL >> CJ >> > >> XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z0wnaQB6DepNHsEOTTQoEwKDSSaVp >> V%2BmixKSZ >> > e2dnFE%3D&reserved=0 >> > >> > Thanks in advance, we look forward to anything the list is willing to >> > provide. >> >> I think this plain needs killing, RFC8781 is so much better. >> >> It occurred to me that a validating stub resolver still needs to know if its >> upstream >> is messing with DNS. With RFC9606 we can just ask the resolver what it's >> doing, >> so I put up >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack >> er.ietf.org%2Fdoc%2Fdraft-fobser-resinfo- >> dns64%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Cd8fc7fd951 >> 164c6fef2108dcf1dea66d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% >> 7C638651185889729988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM >> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat >> a=RzAZTujnuR79y7vYjzkJSFdUidrcq1YqJZszZbW5TOI%3D&reserved=0 >> >> A validating stub can then avoid that resolver or do more fancy things like >> spotting >> that the resolver did DNS64 synthesis, ignore that answer and do its own >> synthesis using the 8781 prefix... >> >> > >> > Thanks! >> > >> > nb >> > ___ >> > DNSOP mailing list -- dnsop@ietf.org >> > To unsubscribe send an email to dnsop-le...@ietf.org >> > >> >> -- >> In my defence, I have been left unsupervised. > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- In my defence, I have been left unsupervised. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: New draft regarding RFC7050
On 2024-09-09 17:51 -05, Nick Buraglio wrote: > dnsop folks, > > Based on some conversations and discussions at the end of the second > session at 120, several of us worked out a draft to address what we believe > are some notable details in RFC7050. This draft was just submitted to the > datatracker, and we would appreciate any input, comments, corrections, and > productive discussion from the expertise of the group. The draft can be > read at https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/ > > Thanks in advance, we look forward to anything the list is willing to > provide. I think this plain needs killing, RFC8781 is so much better. It occurred to me that a validating stub resolver still needs to know if its upstream is messing with DNS. With RFC9606 we can just ask the resolver what it's doing, so I put up https://datatracker.ietf.org/doc/draft-fobser-resinfo-dns64/ A validating stub can then avoid that resolver or do more fancy things like spotting that the resolver did DNS64 synthesis, ignore that answer and do its own synthesis using the 8781 prefix... > > Thanks! > > nb > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > -- In my defence, I have been left unsupervised. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: DNSOPPossible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01
On 2024-10-15 07:49 -07, Wes Hardaker wrote: > Paul Hoffman writes: > >> In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC >> Delegation" do not make sense if there is more than one "MUST" in that >> column. You cannot use two algorithms to sign or delegate at the same >> time. > > Thank you for the analysis. I think there are three (obvious) paths forward: > > 1. Define what MUST means in the context for the Use columns. > 2. Use RECOMMENDED instead. > 3. Only allow a single MUST in the Use column because that's what we > want people to really use (which does sound more like a SHOULD). IE, > if we believe ideally there should be one cryptographic algorithm > deployed to simplify the deployed base, we could pick this route. I > doubt it would be popular though, as we already have a fractured > ecosystem and it is generally working. > > Feedback from the WG appreciated :-) #2 makes sense to me. -- In my defence, I have been left unsupervised. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis
I did the dnsdir early review of -00, all my nits have been addressed. As a root server operator I don't see anything wrong with the document, not that it would effect me... I think it's good to go to be published as an RFC. -- In my defence, I have been left unsupervised. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-hinden-v6ops-dns
Take note of the intended status. I thought that to be... ambitious ;) -- In my defence, I have been left unsupervised. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-06.txt
On 2024-03-18 10:33 +01, Philip Homburg wrote: > In your letter dated Mon, 18 Mar 2024 08:01:38 +0100 you wrote: >>On 2024-03-17 20:12 -07, internet-dra...@ietf.org wrote: >>> Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It >>is >> >>| 7. Security Considerations >>| [...] >>| In case of non DNSSEC validating >>| resolvers, an attacker controlling a rogue name server for the root >>| has potentially complete control over the entire domain name space >>| and can alter all unsigned parts undetected. >> >>can alter *all* parts undetected. >> >>It's a non-DNSSEC validating resolver, it doesn't care about signed or >>unsigned. Maybe just drop that sentence, it doesn't add much. > > A non DNSSEC validation resolver may have downstream validators that can > detect changes to signed data. So an attacker that wishes to stay undetected > has to > be careful not to modify signed data. ah yes, true. > > I guess the authors should add some clarifying text here to make clear why > in the case of a non validating resolver the attacker can only alter the > unsigned parts. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-06.txt
On 2024-03-17 20:12 -07, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It is | 7. Security Considerations | [...] | In case of non DNSSEC validating | resolvers, an attacker controlling a rogue name server for the root | has potentially complete control over the entire domain name space | and can alter all unsigned parts undetected. can alter *all* parts undetected. It's a non-DNSSEC validating resolver, it doesn't care about signed or unsigned. Maybe just drop that sentence, it doesn't add much. -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc8109bis-02.txt
Sorry for being very late, I was swamped with other stuff | 4.2. Completeness of the Response | | At the time this document is published, there are 13 root server | operators operating a total of more than 1500 root server instances. There are only *12* operators, operating 13 letters. a-root and j-root are both operated by verisign. | Each has one IPv4 address and one IPv6 address. The combined size of that's not true for the instances (there are IPv4 only instances in operation). It's also confusing now, it could be read as "there are more than 1500 IPv4 and IPv6 addresses in use." Of course these are anycasted so each instance of a letter has the same IPv4/IPv6 addresses... On 2024-01-22 10:44 -08, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-dnsop-rfc8109bis-02.txt is now available. It is a > work item of the Domain Name System Operations (DNSOP) WG of the IETF. > >Title: Initializing a DNS Resolver with Priming Queries >Authors: Peter Koch > Matt Larson > Paul Hoffman >Name:draft-ietf-dnsop-rfc8109bis-02.txt >Pages: 11 >Dates: 2024-01-22 > > Abstract: > >This document describes the queries that a DNS resolver should emit >to initialize its cache. The result is that the resolver gets both a >current NS Resource Record Set (RRset) for the root zone and the >necessary address information for reaching the root servers. > >This document, when published, obsoletes RFC 8109. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8109bis-02 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-02 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-zoneversion-03.txt
Sorry for being very late. I find the usage of FLAG- weird. I think FLAG-LABELS should just be LABELS or LABELCOUNT. What really tripped me was FLAG-NUMBER. It is introduced in section 2, without any indication what it does. I think it should be called TYPE, a flag is a thing that's "on" or "off", but this is not. What's called FLAG-NUMBER distinguishes the type of FLAG-DATA. I don't think we need FLAG-LENGTH at all, it follows trivially from the EDNS0 OPTION-LENGTH. FLAG-DATA could be called VERSIONDATA. Again, sorry for being late, Florian -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt
On 2023-07-17 12:40 -04, "John Levine" wrote: > It appears that Florian Obser said: >>I gave this a once-over. >>3. Common Pitfalls >>> If the size of the response is large enough that it does not fit into >>> a single DNS UDP packet (UDP being the most common DNS transport >>> today), this may result in fragmentation >> >>That's not correct. If the response does not fit into a single DNS UDP >>packet, it's not a valid response and can't be send. >> >>New: If the size of the response is large enough that it does not fit >>into a single IP packet this may result in fragmentation > > That's not right either. If it doesn't fit in a UDP packet, the true > response will be truncated and the client will retry over TCP. If the > UDP packet exceeds PMTU, the packet will be fragmented in transit but > there's no simple way to know that at the application level. There's a > reason EDNS0 let the client suggest a packet size limit, and people > have been tuning their use of it since 1999. > > The entire discussion of response size seems like a throwback to the > 1990s and I would remove it. These days if your DNS doesn't handle yeah, that might be best. > TCP, you already have worse problems, like DNSSEC doesn't work. > > R's, > John -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt
I gave this a once-over. 1. Introduction > Generally only one temporary DNS record is sufficient for > proving domain ownership, although sometimes the DNS record must be > kept in the zone to prove continued ownership of the domain. I understand what it's trying to say, but I think "a" instead of "one" would be better. "One" sounds like there will ever be exactly one temporary DNS record in the zone to prove ownership. Which is probably not true if you need to prove ownership to multiple services. Therefore: old: Generally only one temporary DNS record is sufficient new: Generally a temporary DNS record is sufficient 3. Common Pitfalls > If the size of the response is large enough that it does not fit into > a single DNS UDP packet (UDP being the most common DNS transport > today), this may result in fragmentation That's not correct. If the response does not fit into a single DNS UDP packet, it's not a valid response and can't be send. New: If the size of the response is large enough that it does not fit into a single IP packet this may result in fragmentation > Other possible issues may occur. If a TXT record (or any other > record type) is designed to be place at the same domain name... s/place/placed/ 5.2. TXT Record > when the DNS administrator receives the information, especially to > consumers who are not DNS experts. s/to consumers/from consumers/ 5.2.1. Metadata For Expiry > Providers MUST provide clear instructions I don't think there would be an interoperability issue or the protocol would fail when providers provide unclear instructions or no instructions at all, so: s/MUST/SHOULD/ I'd like to see a definition / reference for the time format. xkcd 1179 is relevant... -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements
On 2023-06-07 13:08 -04, Tim Wicinski wrote: > Just a reminder we're looking for any feedback on continuing work on this > document. The Chairs/OverLord Warren feel significant work on this > document is needed, but that may not be relevant. The document seems to have a rather pessimistic view on running a validator. It has this huge list of things that an operator has to do and does not assign any importance to them - everything seems to be equally important. If I were to read this as the person responsible for running the recursive resolver at an enterprise or at an ISP I'd think: That sounds like effort and incredibly fragile, it's probably best to not enable validation. It would be nice to have an informational RFC on the topic, but I'm not convinced this is it. Maybe Andrew's suggestion to split this up is the way forward. Maybe have one document with minimum requirements (correct time, stuff like that) and take it from there. > > We're wrapping this feedback up this Sunday 11 June. > > (and Thanks Andrew for your comments) > > tim -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
On 2023-03-28 05:51 -07, Paul Vixie wrote: > see inline. > > Viktor Dukhovni wrote on 2023-03-27 18:00: >> [ Multi-response to four upthread messages. ] >> --- >> ... >> A possibly inconvenient question, just to make sure we're not >> ignoring >> the obvious sceptical position: >> * How compelling is compact DoE? > > that may depend on the beholder's eye. for perspective, no root name > server has deployed this alternative form of Denial of Existence, and > i believe this includes the f-root anycast instances operated by > cloudflare under ISC's management. root name servers receive an awful > lot of junk, and aren't in general overfunded, so if compactness of > DoE was compelling for anybody, it seems like it would be for > them. yet: It would be scary if any of the root name servers could deploy this because that meant that they have access to the zone signing private key. Which they don't. -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
I might not be caffeinated enough yet, but I think the next domain name in section 5 should be \000.ent1.example.net: ent1.example.net. 3600 IN NSEC \000.ent1.example.net. RRSIG NSEC ENT In section 6, calling getaddrinfo() return values exit codes is a bit odd, maybe this will do? Address lookup functions typically invoked by applications won't see a practical impact from this indistinguishability. For a non- existent name, the getaddrinfo() function for example will return a value of EAI_NODATA rather than EAI_NONAME. But either way the effect on the caller is the same: it will obtain a response with a non-zero return value and no available addresses. -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
On 2022-11-25 12:26 -05, Daniel Migault wrote: > On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát > wrote: >> I am surprised you would not recommend RFC 5011 >> >> 5011 needs persistent state, a thing that resolvers/validators often don't >> need at all otherwise (cache is safe to delete). 5011 doesn't always work, >> so you need to combine with some fallback mechanism(s) anyway - for new >> installations and for stale ones (missed rotation). Root rollover has >> happened only once in history, non-root TAs aren't that common, and 5011 >> algorithm isn't very simple, so the code can easily get some bugs without >> anyone noticing until it's too late. >> >> Lots of down-sides, so I rather put the TAs into SW updates, for the root >> TA case at least. I'd recommend trying to avoid non-root TAs, but if I had >> to choose, I'd put them into configuration. Again a thing that I have to >> provision *anyway*, so I get the occasional TA updates basically for free, >> without needing to worry about those 5011 disadvantages. (occasional = >> 5011 defaults to requiring 30 days of overlap) >> >> > Oh! sure for the TA. My understanding of the text is that it recommends > 5011 for running instances, but that new instances are configured with > up-to-date TA that in most cases are updated by software update. So yes I > agree and will check this appears clearly. Another issue with 5011 is that it needs cooperation from the entity signing the zone during a KSK rollover. 7583 spells this out in section 2.2. I think Vladimír is hinting at this already, I'd say it should be spelled out. Especially since this is aimed at non-DNSSEC-Experts as you were saying earlier in the thread. If a DRO unilaterally decides to put in a TA for example.com as suggested in section 7.1.1 and using 5011 this will not end well if they don't tell the people operating the signer. They will probably not follow the correct timing during a KSK roll. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-00.txt
I finally got around to use a more sensible setting for my personal domains, i.e. the recommended one. I did have to refresh my memory on how NSEC3PARAM works by glancing at RFC 5155 though. Maybe something like this at the end of "3. Best-practice for zone publishers" would be helpful: | Since the NSEC3PARAM RR is not used by validating resolvers (see | [RFC5155] section 4) the iterations and salt parameters can be changed | without the need to wait for RRsets to expire from caches. A complete | new NSEC3 chain needs to be constructed and the zone resigned. Section 2.4 is already hinting at this, this spells it out. Thanks, Florian -- I'm not entirely sure you are real. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
