Re: [DNSOP] unrelated name server name recommendation
On Sun, Mar 3, 2024 at 11:34 PM Kazunori Fujiwara wrote: > dnsop WG, > > "unrelated" (or, previosly called as out-of-bailiwick) name server names > are > necessary for DNS hosting providers. > Fujiwara-san, I have to nitpick your very first statement above. Many DNS providers do offer the ability to pick "vanity" or "custom" nameserver names, which their customers can use to deploy in-domain nameservers. This could be because the customer really does want to make DNS resolution efficient. But it could be for other reasons (branding, or some other perceived security reason). My employer uses such features extensively. This is not simply the customer pointing their own names at the provider's DNS server addresses. This is a contract with the provider that they will maintain that association and won't change the IP addresses from under them (the "going stale" problem) without advance notice and coordination. I think I agree with your general goal, but as others have remarked, there is no way to enforce this, so at best this could be a recommendation. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On Mon, Mar 4, 2024 at 3:29 AM Philip Homburg wrote: > > What I mean is that if we take all of the standards track DNSSEC RFCs and > we > add a new RFC that says something to the effect: > 1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key >tags. > 2) An authoritative DNS server MUST not serve a set of RRSIG records that >corresponds to a single RRset where the collection of RRSIG records has > a >duplicate key tag. > > then as far as I can tell, there is no conflict with currently published > standards track DNSSEC RFCs. > > In addition for most signers and authoritative servers it will be easy to > meet > those requirements and many signers are already in line with those > requirements. > > The only thing that prevents us from publishing such an update is an > informational RFC about multi-signers (or other practices that are not > documented or standardized within the IETF). Note that RFC 8901 is an IETF consensus document that was produced in the DNS Operations working group. So, we can't just dismiss it and propose protocol changes without considering effects on that (and other documents). As I also noted earlier, its status will likely be upgraded when we revise it. Furthermore, it is not as some have previously tried to characterize it, a niche configuration that only a few large enterprises will use. Multi-signer is a key enabler of non-disruptive transfers of signed zones across distinct providers. There is a currently adopted working group document (intended category: Standards Track) that is laying out the details of that process: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-automation/ Here's a presentation from Christian Elmerot, of a real world example of a recent successful multi-signer transition (.GOV from Verisign to Cloudflare): https://indico.dns-oarc.net/event/48/contributions/1038/attachments/1005/1948/gov-transition-nsec-nsec3.pdf Some (single) organizations are also looking at multi-signer techniques for deployments across distinct HSM vendors. Separately from multi-signer, I agree with John Levine's comments about not breaking existing configurations that are deployed in the field. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unrelated name server name recommendation
Paul Wouters wrote on 2024-03-04 11:14: On Mar 4, 2024, at 14:04, Paul Vixie wrote: this means a zone will always be reachable through at least one in-zone data path (name server name and associated address records.) the result would be that a full resolver would never have to pause its current lookup while searching for address records matching an out-of-zone name server name. i think it's a solid recommendation, It means every registrant, who doesn’t know about DNS, has to create host objects for glue and whenever the ISP changes nameserver names (eg gets bought, sold or merges), or IP address, the ISP has to talk to the registrant to fix things at their registry. I can promise you those in-domain name servers will quickly become very unreliable. not. the rest of the paragraph you quoted six words from above was: i think it's a solid recommendation, but can only be a SHOULD not a MUST, both because of the installed base / long tail, and the impossibility of enforcing it, and the market needs of parking lots. it's not a "has to". i expect it either won't be used when a sale is possible, or will be removed prior to such sale. i see fujiwara's proposal as a way to reduce distributed system complexity for those who can behave this way, and strictly as a recommendation. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft agenda IETF 119 DNSOP published
All, We are pleased to announce that the draft agenda for the IETF 119 DNSOP sessions has been published. The sessions are scheduled as follows: - Monday, March 18, 2024, from 15:30 to 17:00 AEST (05:30-07:00 UTC) - Friday, March 22, 2024, from 15:00 to 16:30 AEST (05:00-06:30 UTC) You can view the draft agenda on the datatracker at the following link: https://datatracker.ietf.org/doc/agenda-119-dnsop/. Best, Suzanne, Tim and Benno ___ 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' 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] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt
Forwarded Message Subject: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt Date: Mon, 04 Mar 2024 13:12:26 -0800 From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Internet-Draft draft-toorop-dnsop-ranking-dns-data-00.txt is now available. Title: Ranking Domain Name System data Authors: Paul Hoffman Shumon Huque Willem Toorop Name:draft-toorop-dnsop-ranking-dns-data-00.txt Pages: 4 Dates: 2024-03-04 Abstract: This document extends the list ranking the trustworthiness of domain name system (DNS) data (see Section 5.4.1 of [RFC2181]). The list is extended with entries for root server names and addresses built-in resolvers, and provided via a root hints file with the lowest trustworthiness, as wel as an entry for data which is verifiable DNSSEC secure with the highest trustworthiness. This document furthermore assigns ranked values to the positions of the list for easier reference and comparison of trustworthiness of DNS data. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-toorop-dnsop-ranking-dns-data/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-toorop-dnsop-ranking-dns-data-00 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
[DNSOP] Martin Duke's No Objection on draft-ietf-dnsop-avoid-fragmentation-17: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-17: 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-avoid-fragmentation/ -- COMMENT: -- Thanks for addressing my DISCUSS. Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for responding. (1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it unless the OS makes it impossible" is a typical use of SHOULD. (2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under what circumstances would it be reasonable to keep it? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt
Internet-Draft draft-ietf-dnsop-compact-denial-of-existence-03.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Compact Denial of Existence in DNSSEC Authors: Shumon Huque Christian Elmerot Olafur Gudmundsson Name:draft-ietf-dnsop-compact-denial-of-existence-03.txt Pages: 12 Dates: 2024-03-04 Abstract: This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimal NSEC record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/shuque/id-dnssec-compact-lies. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-compact-denial-of-existence-03.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-compact-denial-of-existence-03 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
[DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-05.txt
Internet-Draft draft-ietf-dnsop-ns-revalidation-05.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Delegation Revalidation by DNS Resolvers Authors: Shumon Huque Paul Vixie Willem Toorop Name:draft-ietf-dnsop-ns-revalidation-05.txt Pages: 9 Dates: 2024-03-04 Abstract: This document recommends improved DNS [RFC1034] [RFC1035] resolver behavior with respect to the processing of Name Server (NS) resource record sets (RRset) during iterative resolution. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and ) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be requeried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the child delegation by re-quering the parent zone at the expiration of the TTL of the parent side NS RRset. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-05 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-ns-revalidation-05 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
[DNSOP] I-D Action: draft-ietf-dnsop-qdcount-is-one-02.txt
Internet-Draft draft-ietf-dnsop-qdcount-is-one-02.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: In the DNS, QDCOUNT is (usually) One Authors: Ray Bellis Joe Abley Name:draft-ietf-dnsop-qdcount-is-one-02.txt Pages: 7 Dates: 2024-03-04 Abstract: This document clarifies the allowable values of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) and specifies the required behaviour when values that are not allowed are encountered. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-qdcount-is-one-02 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-qdcount-is-one-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
Re: [DNSOP] unrelated name server name recommendation
> On 4 Mar 2024, at 19:14, Paul Wouters wrote: > > It means every registrant, who doesn’t know about DNS, has to create host > objects for glue and whenever the ISP changes nameserver names (eg gets > bought, sold or merges), or IP address Er, no. It’ll be the registant’s registrar who will screw this up - not the registrant (who can’t even spell DNS). Besides in most cases, the it’ll be the registrar who looks after that delegation info and also provides DNS service for the registant’s domain name. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-rfc7958bis-01.txt
Internet-Draft draft-ietf-dnsop-rfc7958bis-01.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: DNSSEC Trust Anchor Publication for the Root Zone Authors: Joe Abley Jakob Schlyter Guillaume Bailey Paul Hoffman Name:draft-ietf-dnsop-rfc7958bis-01.txt Pages: 12 Dates: 2024-03-04 Abstract: The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc7958bis-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc7958bis-01 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
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one
Hi, We're leaving this open a few more days to allow for any other comments. We'd like to submit it for publication before IETF 119. Thanks, Suzanne For the chairs On Feb 15, 2024, at 10:57 AM, Suzanne Woolf wrote: Hi, The qdcount draft is brief and straightforward, and there have been no new changes proposed or issues introduced since the -01 version was posted. We think there’s likely consensus to advance it for publication. This note starts a Working Group Last Call for draft-ietf-dnsop-qdcount-is-one. Current version of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/ The Current Intended Status of this document is: Proposed Standard Please review the draft and offer relevant comments. For WGLC, we need positive support and constructive comments; lack of objection is not enough. So if you think this draft should be published as an RFC, please say so. If you feel the document is *not* ready for publication, please speak out with your reasons. This starts a two week Working Group Last Call process, and ends on: 29 February, 2024. thanks, Suzanne (for the chairs) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-generalized-notify-01.txt
Hi, This revision has the following changes from -00: - Describe endpoint discovery - Rename NOTIFY rrtype to DSYNC (to distinguish from NOTIFY message) - Reserve scheme values 128-255 - Expanded discussion on amplification risks and garbage notifications - Clean-up, editorial changes Looking forward to the WG's feedback. Best, Johan/John/Peter On 3/4/24 16:35, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-dnsop-generalized-notify-01.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Generalized DNS Notifications Authors: Johan Stenstam Peter Thomassen John Levine Name:draft-ietf-dnsop-generalized-notify-01.txt Pages: 16 Dates: 2024-03-04 Abstract: This document extends the use of DNS NOTIFY ([RFC1996] beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC key rollovers hints, and quicker changes to a delegation's NS record set. To enable this functionality, a method for discovering the receiver endpoint for such notification message is introduced, via the new NOTIFY record type. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify (https://github.com/peterthomassen/draft-ietf-dnsop-generalized- notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-generalized-notify-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-generalized-notify-01 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 -- Like our community service? Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-generalized-notify-01.txt
Internet-Draft draft-ietf-dnsop-generalized-notify-01.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Generalized DNS Notifications Authors: Johan Stenstam Peter Thomassen John Levine Name:draft-ietf-dnsop-generalized-notify-01.txt Pages: 16 Dates: 2024-03-04 Abstract: This document extends the use of DNS NOTIFY ([RFC1996] beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC key rollovers hints, and quicker changes to a delegation's NS record set. To enable this functionality, a method for discovering the receiver endpoint for such notification message is introduced, via the new NOTIFY record type. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify (https://github.com/peterthomassen/draft-ietf-dnsop-generalized- notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-generalized-notify-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-generalized-notify-01 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
[DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-08.txt
Internet-Draft draft-ietf-dnsop-dns-error-reporting-08.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: DNS Error Reporting Authors: Roy Arends Matt Larson Name:draft-ietf-dnsop-dns-error-reporting-08.txt Pages: 12 Dates: 2024-03-04 Abstract: DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in [RFC8914]. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME, thus the very act of sending the query is to report the error. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-08 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dns-error-reporting-08 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
Re: [DNSOP] [Ext] Nothing more useful to say About key tags
It appears that Philip Homburg said: >>Not at all. This would be an incompatible change that breaks existing >>working DNS configurations, for at most a trivial simplification in >>load limiting code many years from now, even assuming people were to >>implement it. > >Opinions difference how much this change will help. > >The point I wanted to make is that this change does not lead to issues at >level of DNSSEC standard protocols. But that point is completely wrong. What you propose is a breaking change. It is incompatible with existing DNS standards. So, no. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unrelated name server name recommendation
I understood Fujiwara’s proposal to be slightly different: If you are a DNS provider (hosting other zones) then the provider should use in-domain name servers. DW > On Mar 4, 2024, at 3:14 PM, Paul Wouters wrote: > > On Mar 4, 2024, at 14:04, Paul Vixie > wrote: >> >> >> >> this means a zone will always be reachable through at least one in-zone data >> path (name server name and associated address records.) the result would be >> that a full resolver would never have to pause its current lookup while >> searching for address records matching an out-of-zone name server name. >> >> i think it's a solid recommendation, > > It means every registrant, who doesn’t know about DNS, has to create host > objects for glue and whenever the ISP changes nameserver names (eg gets > bought, sold or merges), or IP address, the ISP has to talk to the registrant > to fix things at their registry. I can promise you those in-domain name > servers will quickly become very unreliable. > > Paul > ___ > DNSOP mailing list > DNSOP@ietf.org > https://secure-web.cisco.com/1a3MNvrMgvJke3ozLjb1HCuRHhuKPU4kcf25J9eCUq4p-aOa0Aqy6qmiTdxMr02KJy3Ai80ZFNKl9j_c-7cA3MZpUD5480mMQT5pKWiSiUhWWeiTjjFCC6bZdqrh-FHCqvl1sM64AGrDIt4zjPKgcxERVilTSw7U3KPYhiGQ1IMY8wwa-dVkcU7s4T0z9flJabKEE7sH-IvWVC-Sv4i0fKZUk1g-ek5vkhx5JIA8TeMvtjP17WZaKrO79M9HpU6TNwB0ypkRbRMX8btrJZ9nSBar6W3gL2W4TKNRPrzyBFB8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unrelated name server name recommendation
On 3/4/24 15:14, Paul Wouters wrote: It means every registrant, who doesn’t know about DNS, has to create host objects for glue and whenever the ISP changes nameserver names (eg gets bought, sold or merges), or IP address, the ISP has to talk to the registrant to fix things at their registry. I can promise you those in-domain name servers will quickly become very unreliable. For reference, Viktor's analysis from last year, on glue in .org: https://mailarchive.ietf.org/arch/msg/dnsop/EBT2_wg8XJkArA1boRX7GNSKdKw/ The analysis is focuses on sibling glue, not only in-domain, but my main takeaway is that 75% of them are stale. Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Nothing more useful to say About key tags
>Not at all. This would be an incompatible change that breaks existing >working DNS configurations, for at most a trivial simplification in >load limiting code many years from now, even assuming people were to >implement it. Opinions difference how much this change will help. The point I wanted to make is that this change does not lead to issues at level of DNSSEC standard protocols. Yes, there might be some implementations that need to adjust. That's often the case with protocol changes. If we cannot make protocol changes any more out of fear that implementations may need to change then we have reached the top of ossification. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unrelated name server name recommendation
On Mar 4, 2024, at 14:04, Paul Vixie wrote: > > > > this means a zone will always be reachable through at least one in-zone data > path (name server name and associated address records.) the result would be > that a full resolver would never have to pause its current lookup while > searching for address records matching an out-of-zone name server name. > > i think it's a solid recommendation, It means every registrant, who doesn’t know about DNS, has to create host objects for glue and whenever the ISP changes nameserver names (eg gets bought, sold or merges), or IP address, the ISP has to talk to the registrant to fix things at their registry. I can promise you those in-domain name servers will quickly become very unreliable. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unrelated name server name recommendation
Ben Schwartz wrote on 2024-03-04 07:20: To rephrase, it sounds like you are proposing a rule that zones should be configured to use at most one glueless delegation step. i think it's the inverse. according to fujiwara-san's comments each zone must have at least one in-zone name server name:> this means a zone will always be reachable through at least one in-zone data path (name server name and associated address records.) the result would be that a full resolver would never have to pause its current lookup while searching for address records matching an out-of-zone name server name. i think it's a solid recommendation, but can only be a SHOULD not a MUST, both because of the installed base / long tail, and the impossibility of enforcing it, and the market needs of parking lots. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Nothing more useful to say About key tags
It appears that Philip Homburg said: >What I mean is that if we take all of the standards track DNSSEC RFCs and we >add a new RFC that says something to the effect: >1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key > tags. >2) An authoritative DNS server MUST not serve a set of RRSIG records that > corresponds to a single RRset where the collection of RRSIG records has a > duplicate key tag. > >then as far as I can tell, there is no conflict with currently published >standards track DNSSEC RFCs. Not at all. This would be an incompatible change that breaks existing working DNS configurations, for at most a trivial simplification in load limiting code many years from now, even assuming people were to implement it. No. Just plain no. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unrelated name server name recommendation
To rephrase, it sounds like you are proposing a rule that zones should be configured to use at most one glueless delegation step. Under this rule, one cannot place an "unrelated nameserver name" anywhere beneath a zone cut that itself uses an unrelated nameserver. Effectively, all zones below such a zone cut are "second class" zones for this purpose. This breaks a symmetry of the DNS: there are now two different kinds of zones, where previously there was only one. It's also strange that this distinction depends on the configuration of some parent or grandparent zone that is not controlled by the zone in question, and can change at any time. I appreciate that glueless delegations have some downsides, and may be worth avoiding in some cases, but I think the proposed rule is too restrictive. I would be more interested in a document (perhaps non-IETF) showing how adding complexity to your zone's resolution process impacts resolution time, error rate, and frequency of misconfigurations. --Ben Schwartz From: DNSOP on behalf of Kazunori Fujiwara Sent: Sunday, March 3, 2024 11:34 PM To: dnsop@ietf.org Subject: [DNSOP] unrelated name server name recommendation !---| This Message Is From an Untrusted Sender You have not previously corresponded with this sender. |---! dnsop WG, "unrelated" (or, previosly called as out-of-bailiwick) name server names are necessary for DNS hosting providers. However, it increases name resolution costs. Furthermore, it makes it easy to make mistakes like cyclic dependencies. So, I would like to make some recommendations on "unrelated" name server names. I submitted "draft-fujiwara-dnsop-unrelated-name-server-00" as a first step. https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-unrelated-name-server/ I prposed that the domain names that host the name server names MUST be resolvable by delegations using one or more in-domain name server names. I'm not able to write well, I'm looking for good text. Let's improve the current DNS before DELEG RR. -- Kazunori Fujiwara, JPRS ___ 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] [Ext] About key tags
In your letter dated Sat, 2 Mar 2024 16:55:59 -0400 you wrote: >The core DNSSEC protocol includes multi-signer. RFC 8901 just spells out expli >citly how it is covered by the protocol; that's why its status is Informationa >l. > >> The first step to conclude is that for the core DNSSEC protocol, requiring >> unique key tags is doable. > >No. There is no core and non-core part of the spec. Support for multiple keys, > including keytag collisions, simply is part of that protocol. What I mean is that if we take all of the standards track DNSSEC RFCs and we add a new RFC that says something to the effect: 1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key tags. 2) An authoritative DNS server MUST not serve a set of RRSIG records that corresponds to a single RRset where the collection of RRSIG records has a duplicate key tag. then as far as I can tell, there is no conflict with currently published standards track DNSSEC RFCs. In addition for most signers and authoritative servers it will be easy to meet those requirements and many signers are already in line with those requirements. The only thing that prevents us from publishing such an update is an informational RFC about multi-signers (or other practices that are not documented or standardized within the IETF). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
