Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion
I've read this draft. I think its a simple and straightforward proposal. It explicitly notes the security issue that its not covered by DNSSEC, it has implementations, and it had a good discussion run 2021/2022 which was overwhelmingly positive. I had no problems understanding the intent. its really clear and straightforward. It's a debug tool. It isn't going to be something I expect to use, but I like the idea if something goes awry in the responses I am seeing I can ask the authority to tell me what SOA serial I should expect to see, that has the response state they're giving me for the specific query. Thats distinct from ZONEMD which is a DNSSEC signed state of an entire zone (assuming it can be done) which is a different class of check on zone state related to serial. I like both. They're different. That said, you COULD point to ZONEMD in this one in the security considerations, but I wouldnt make it normative. It's just another way to check the state of a zone. The non-transitive thing is about the only point of "well" -but its unsigned data: how could you trust it, if you can't verify through a third (transiting) party? And the draft says this: it's undefined behaviour. I truly think this is that very rare bird: "looks good to me ship it" in 2 WG adopted draft edits. On Thu, Apr 27, 2023 at 1:08 PM Suzanne Woolf wrote: > > Colleagues, > > > This email begins a Working Group Last Call for > draft-ietf-dnsop-zoneversion-02 > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > > If you've reviewed this document and think it's ready for publication, please > let us and the WG know, by responding on-list to this message. We > particularly need to hear from implementers and operators whether this EDNS > option is implementable and useful. > > If you don't think it's ready, and have specific concerns or suggestions, > please let us know about those too. > > The Last Call will be two weeks, ending on Thursday 11 May. > > Thanks to everyone who's offered comments and suggestions on the draft to > date. > > > Suzanne, Tim, and Benno > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] WGLC for draft-ietf-dnsop-zoneversion
Colleagues, This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). If you've reviewed this document and think it's ready for publication, please let us and the WG know, by responding on-list to this message. We particularly need to hear from implementers and operators whether this EDNS option is implementable and useful. If you don't think it's ready, and have specific concerns or suggestions, please let us know about those too. The Last Call will be two weeks, ending on Thursday 11 May. Thanks to everyone who's offered comments and suggestions on the draft to date. Suzanne, Tim, and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Glue Requirements in Referral Responses) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Glue Requirements in Referral Responses' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative Servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: 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/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: -- One comment -- Section 3.2 has "DNS server operators MAY be aware that queries for name ending in .alt are not DNS names, and queries for those names were leaked into the DNS context." The RFC 2119 MAY appears misused in this context. (Also, in that quote, s/queries for name/queries for names/) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] can someone forward this to benno?
Since that is an email/dkim discussion and this is not the right forum for it I will not argue it here. I will also not be changing my p= value. Noone should forward an email message with unmodified headers in 2023. Encapsulate it rather than forging my domain. I'd like our chairs to stop using .forward files and /etc/aliases, or change email vendors, or change mailbox providers. This email behavior is unbecoming. p vixie On Apr 26, 2023 12:04, John Levine wrote: It appears that Paul Vixie said: >-=-=-=-=-=- > >i don't know why it was rejected as spam but his sysadmin might. > It's because redbarn.org has a p=reject DMARC policy. To summarize a lot of prior discussion, "don't do that". R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] can someone forward this to benno?
It appears that Paul Vixie said: >-=-=-=-=-=- > >i don't know why it was rejected as spam but his sysadmin might. > It's because redbarn.org has a p=reject DMARC policy. To summarize a lot of prior discussion, "don't do that". R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir telechat review of draft-ietf-dnsop-alt-tld-23
Just a quick more to say thank you for your review. Warren. On Mon, Apr 24, 2023 at 11:19 AM, Vladimír Čunát wrote: > Reviewer: Vladimír Čunát > Review result: Ready > > There've only been nits between -22 and -23; certainly no objections there > and thus nothing new for me to say. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
On Mon, Apr 24, 2023 at 10:11 AM, Lars Eggert wrote:
> Lars Eggert has entered the following ballot position for
> draft-ietf-dnsop-alt-tld-23: 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/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:
> --
>
> # GEN AD review of draft-ietf-dnsop-alt-tld-23
>
> CC @larseggert
>
> Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART)
> review
> (https://mailarchive.ietf.org/arch/msg/gen-art/1LB6_ujGseyZRWPgTQZrP2pS8zk).
>
>
> ## Comments
>
> ### DOWNREFs
>
> DOWNREF `[RFC8244]` from this Proposed Standard to Informational
> `RFC8244`.
> (For IESG discussion. It seems this DOWNREF was not mentioned in the Last
> Call and also seems to not appear in the DOWNREF registry.)
>
> I think RFC8244 could be cited informatively?
>
It probably could be, but it does quite a lot feel like something very
useful for the readers to, erm, read…
> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit. Some were
> flagged by automated tools (via https://github.com/larseggert/
> ietf-reviewtool), so there will likely be some false positives. There is
> no need to let me know what you did with these suggestions.
>
> ### Grammar/style
>
> Section 2, paragraph 7
> ```
> performing aggressive use of DNSSEC- validated caches (described in
> [RFC8198
> ^
> ```
> This word seems to be formatted incorrectly. Consider fixing the spacing
> or removing the hyphen completely.
>
Thank you - it was a hidden space in the XML line break - fixed in PR.
> Section 2, paragraph 8
> ```
> will cover all names under .alt. Currently deployed projects and protocols
> t
> ^
> ```
> A comma may be missing after the conjunctive/linking adverb "Currently".
>
I disagree on this one - we are discussing currently deployed projects, not
describing how things currently are.
> Section 7.1, paragraph 2
> ```
> and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC
> 9156,
>
> ```
> Do not mix variants of the same word ("minimisation" and "minimization")
> within a single text.
>
This is an UK vs US spelling difference, but seeing as the RFC uses the 's'
form I've updated it in the editors copy / Pull Request.
Thank you,
W
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
On Sun, Apr 23, 2023 at 4:16 PM, Paul Wouters wrote: > 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. > We've been using this terming this way since at least 2015, and so changing it now would be very disruptive. Do you have proposed text to clarify that it's not used to mean something like the public suffix list? > 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 > Oh, good point. Your proposed text still make it sound like they are not allowed to support non-DNS names, and so I'm proposing: "7. It is not possible for DNS registries/registrars to register names in the .alt pseudo-TLD as the .alt will not exist in the global DNS root." This threads the needle of not trying to tell registries and registrar what they are allowed to do by simply point out that's it's an impossibility for them to register *DNS* names in an undelegated name. > Again, my apologies to Warren for not balloting a blanc YES :) > Nah, thanks for the comments…. and it's still a YES :-p W ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] can someone forward this to benno?
Thank you Paul. The problem seems to be with DKIM and header rewriting by ietfa.amsl.com. We are in contact to resolve this, but it doesn't seem easy. Turning off DKIM on my side doesn't seem like an option, but we're working on an alternative solution. If anyone else has this problem using dnsop-cha...@ietf.org and gets a message back saying the email could not be delivered, please email me directly. It will arrive. (At least one other IETF participant experienced the same problem and contacted me.) Best, -- Benno On 26/04/2023 18:49, Paul Vixie wrote: i don't know why it was rejected as spam but his sysadmin might. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
On Mon, Apr 24, 2023 at 4:04 AM, Éric Vyncke wrote: > Éric Vyncke 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: > -- > > Thanks to the authors and the DNSOP working group, and of course to > Suzanne for a detailed shepherd's write-up. > > Important document to bring some clarity for some use cases. > > Just two minor comments: > > 1/ I support Paul Wouters' issue with the name "pseudo-TLD", it is both > too late and a bike-shedding exercice... "ghost-TLD" or "filler-TLD" or > "dummy-TLD" would have been better > We had chosen pseudo-TLD because it acts like a TLD, and quacks like a TLD, but it isn't actually a TLD because, well, it isn't a Top Level *Domain* — it's more like a Top Level Reservation. If we'd done this all again, perhaps we would have selected a different term, but at this point it's been 9 years, 2 months and 16 days, and changing it now would indeed be too late… > 2/ in section 2, s/because .alt, by definition, is not a DNS name./because > .alt, by this specification, is not a DNS name./ ? > Thank you, I've made that change in the editors copy… W > > Regards > > -éric > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] can someone forward this to benno?
i don't know why it was rejected as spam but his sysadmin might. --- Begin Message --- This is the mail system at host ietfa.amsl.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system (expanded from ): host mx.soverin.net[185.233.34.143] said: 554 5.7.1 Spam message rejected (in reply to end of DATA command) Reporting-MTA: dns; ietfa.amsl.com X-Postfix-Queue-ID: EAF7AC1519A1 X-Postfix-Sender: rfc822; paul@redbarn.org Arrival-Date: Wed, 26 Apr 2023 08:56:51 -0700 (PDT) Final-Recipient: rfc822; benno@NLnetLabs.nl Original-Recipient: rfc822;expand-dnsop-chairs@virtual.ietf.org Action: failed Status: 5.7.1 Remote-MTA: dns; mx.soverin.net Diagnostic-Code: smtp; 554 5.7.1 Spam message rejected --- Begin Message --- Shumon Huque wrote on 2023-04-26 08:43: I support adoption too. As I've mentioned earlier, this mechanism is widely deployed and needs a published specification. Adopting the work will also allow us to formally specify an accurate NXDOMAIN signal (and work out its related details more fully). Shumon. +1. On Sun, Apr 16, 2023 at 8:54 PM Tim Wicinski ... Please also indicate if you are willing to contribute text, review, etc. willing to contribute and review. -- P Vixie --- End Message --- --- End Message --- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
Hi Warren! Thanks for the explanations to my feedback. From: Warren Kumari Sent: Wednesday, April 26, 2023 11:49 AM To: Roman Danyliw Cc: The IESG ; draft-ietf-dnsop-alt-...@ietf.org; dnsop-cha...@ietf.org; dnsop@ietf.org; suzworldw...@gmail.com Subject: Re: Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT) On Tue, Apr 25, 2023 at 4:54 PM, Roman Danyliw mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: 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/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: -- Thank you to Linda Dunbar for the SECDIR review. ** Section 2. Currently deployed projects and protocols that are using pseudo-TLDs are recommended to move under the .alt pseudo-TLD, but this is not a requirement. I don’t understand the basis of this recommendation. Projects and protocols using pseudo-TLDs (outside of https://www.iana.org/domains/reserved) are already not following published guidance. Why is there an expectation that this document can change behavior? It's not really an expectation, more of an invitation/suggestion. At one point this had text along the lines of "may choose to", but that was felt to be a bit weak. There was some discussion about making this "are RECOMMENDED to move", but that was felt to be too strong (and who the hell are we to tell 'em what to do anyway?!). This was the happy medium we settled on. Good enough? [Roman] Yes. I figured there long deliberation on a few set of words. Section 3.2. Item #3. Editorial. s/Writers of name resolution APIs/Creators of name resolution APIs/. Or “developers”, “implementers, or “designers” Thank you - I've updated this to be "Developers" in Pull Request #46. Backstory: This section "answers" the questions from RFC6761, and Q 3 was phrased as: "3. Name Resolution APIs and Libraries: Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?" We'd just sort of followed along from the language. ** Section 3.2. Item #7 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. Items #4 – 6 on this list use RFC2119 language to make the expected behavior clear. This text seems to be written in an aspiration form describing what registries/registrars will do, without explicitly prohibiting them with normative language. Is there a reason for that? Yup, actually 2 reasons: 1: .alt will not exist in the DNS, and so it's not possible for DNS registries and registrars to register DNS names. We don't tell pigs that they MUST NOT fly, and so telling registries and registrars that they MUST NOT do something that they are unable to seemed odd. But, Paul Wouters also pointed at this text in his ballot, and that it is unclear, so I've suggested (in PR 46) this instead: "7. It is not possible for DNS registries/registrars to register DNS names in the .alt pseudo-TLD as the .alt will not exist in the global DNS root." 2: there is some sensitivity here. ICANN regulates registries and registrars, and I was trying to be extra careful to not accidentally step on toes and imply that the IETF was telling 'em what to do… [Roman] Understood. Roman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC
Shumon Huque wrote on 2023-04-26 08:43: I support adoption too. As I've mentioned earlier, this mechanism is widely deployed and needs a published specification. Adopting the work will also allow us to formally specify an accurate NXDOMAIN signal (and work out its related details more fully). Shumon. +1. On Sun, Apr 16, 2023 at 8:54 PM Tim Wicinski ... Please also indicate if you are willing to contribute text, review, etc. willing to contribute and review. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
On Tue, Apr 25, 2023 at 4:54 PM, Roman Danyliw wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-dnsop-alt-tld-23: 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/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: > -- > > Thank you to Linda Dunbar for the SECDIR review. > > ** Section 2. > Currently deployed projects and protocols that are using pseudo-TLDs are > recommended to move under the .alt pseudo-TLD, but this is not a > requirement. > > I don’t understand the basis of this recommendation. Projects and > protocols using pseudo-TLDs (outside of https://www.iana.org/domains/ > reserved) are already not following published guidance. Why is there an > expectation that this document can change behavior? > It's not really an expectation, more of an invitation/suggestion. At one point this had text along the lines of "may choose to", but that was felt to be a bit weak. There was some discussion about making this "are RECOMMENDED to move", but that was felt to be too strong (and who the hell are we to tell 'em what to do anyway?!). This was the happy medium we settled on. Good enough? > Section 3.2. Item #3. Editorial. s/Writers of name resolution > APIs/Creators of name resolution APIs/. Or “developers”, “implementers, or > “designers” > Thank you - I've updated this to be "Developers" in Pull Request #46. Backstory: This section "answers" the questions from RFC6761, and Q 3 was phrased as: "3. Name Resolution APIs and Libraries: Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?" We'd just sort of followed along from the language. > ** Section 3.2. Item #7 > 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. > > Items #4 – 6 on this list use RFC2119 language to make the expected > behavior clear. This text seems to be written in an aspiration form > describing what registries/registrars will do, without explicitly > prohibiting them with normative language. Is there a reason for that? > Yup, actually 2 reasons: 1: .alt will not exist in the DNS, and so it's not possible for DNS registries and registrars to register DNS names. We don't tell pigs that they MUST NOT fly, and so telling registries and registrars that they MUST NOT do something that they are unable to seemed odd. But, Paul Wouters also pointed at this text in his ballot, and that it is unclear, so I've suggested (in PR 46) this instead: "7. It is not possible for DNS registries/registrars to register DNS names in the .alt pseudo-TLD as the .alt will not exist in the global DNS root." 2: there is some sensitivity here. ICANN regulates registries and registrars, and I was trying to be extra careful to not accidentally step on toes and imply that the IETF was telling 'em what to do… W ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC
I support adoption too. As I've mentioned earlier, this mechanism is widely deployed and needs a published specification. Adopting the work will also allow us to formally specify an accurate NXDOMAIN signal (and work out its related details more fully). Shumon. On Sun, Apr 16, 2023 at 8:54 PM Tim Wicinski wrote: > > Happy Monday (UTC) All, > > The chairs heard some strong support to adopt and work on this. > > This starts a Call for Adoption for draft-huque-dnsop-compact-lies > > The authors did do some updates in the draft around the "lies" moniker. > Once adopted perhaps someone can suggest a better draft name. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and send any comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: April 29, 2023 > > Thanks, > tim wicinski > For DNSOP co-chairs > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
On Fri, Apr 14, 2023 at 9:20 PM Mark Andrews wrote: > > Similarly add an unknown EDNS option (pick a value between 1000 and 1999) > to every QUERY until 1 Jan 2025 and if it comes back FORMERR with an OPT > record present, drop the response. 10 years after cleaning up the EDNS > specification we still have .5% of servers not updated. BIND is > effectively > doing this with DNS COOKIE but it is painful when people say “but the > lookup > works with large recursive server”. > Yeah, I've mentioned the same sort of thing in the past too, when I first learned of TLS Grease (RFC 8701). Speaking from experience though, and despite the efforts of EDNS flag day, dropping the responses without fallback still may be too high a bar :( We had to disable Cookies when we upgraded to a post EDNS flag day BIND implementation because of hue and cry from some large customers still running broken DNS implementations :( (I mentioned more details on the dns-operations list at that time). Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
On Fri, Apr 14, 2023 at 7:04 PM Puneet Sood wrote: > I wanted to respond to this thread earlier, so apologies in advance > for late posting and if this is a no-op at this point. Me getting > confused about the last call for this draft > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/) > and https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ > being combined didn't help either. > I'm answering very late too, my apologies ... > The draft does not contain any reference to the rfc8499bis I-D or to > RFC 8499. It would be helpful to have a reference. > That's a reasonable suggestion. We can add it. If it's not too late in the process: > Given the numbers presented upthread, at a minimum could we have one > sentence in section 2.3 Glue Cyclic Sibling Domain Name Server, > discouraging implementers from doing this? > As I've mentioned earlier, I'm okay with adding such a sentence. And perhaps you mean operators rather than implementers. I see that the chairs have pushed the button on 'Publication Requested' for this draft. Maybe you can broach this subject again during "IETF last call", and we'll see if we can get others to chime in then. (Personally, I'd also like to see some big TLD operators speaking up in agreement with this. Otherwise, we might just be writing something that will be ignored). Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Publication has been requested for draft-ietf-dnsop-glue-is-not-optional-08
Suzanne Woolf has requested publication of draft-ietf-dnsop-glue-is-not-optional-08 as Proposed Standard on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
