Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt
I'd also like it to say more clearly up front that .ALT is for names that are totally outside the DNS protocols, not for names handled locally using DNS protocols. It's for things like .onion, not like .local. Both .onion and .local use protocols other than the DNS, acknowledging of course that the protocol used for names under .local is quite DNS-like. My wording wasn't great -- .local resolves to an IP address while .alt doesn't. Did I miss the conversation where the working group decided to pivot? (Not a rhetorical question! I am very prepared for the answer to be yes :-) If anybody has a handy pointer to the relevant part of the mailing list archive I'd appreciate it. If you mean draft-arends-private-use-tld, that was tilting at a different windmill. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt
Unfortunately, having multiple resolution systems using the same namespace and syntax does not provide a signal to denote which resolution mechanism should be used - clearly .com is "in the DNS" and .onion isn't -- but this doesn't scale, and simply saying "the DNS is the only resolution system" doesn't either It would have been nice if ToR used onion://drugmart rather than http://drugmart.onion, but we lost that fight a long time ago. I have occasionally wondered whether we could define an agreed set of levels for DNS-ish name semantics, e.g.: * application data stream (onion) * resolve to a perhaps nonroutable IP address that can connect to a data stream (various LAN level proxy hacks) * resove to an IP address that acts like a real IP address (most DNS resolution behind a NAT) * resolve to a real IP address (DNS resolution without a NAT) These are just examples, please consdider the overall idea, not the color of the bikeshed. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt
On Jun 24, 2021, at 14:37, John Levine wrote: > It appears that Ben Schwartz said: >> I think the "Privacy Considerations" section should probably mention QNAME >> minimization, which ought to help a little. > > I'd also like it to say more clearly up front that .ALT is for names that are > totally outside the DNS protocols, not for names handled locally using DNS > protocols. > It's for things like .onion, not like .local. Both .onion and .local use protocols other than the DNS, acknowledging of course that the protocol used for names under .local is quite DNS-like. More generally, if the intention of the .ALT proposal is to anchor namespaces that don't use the DNS protocol then I'm confused. I thought it was intended exactly to anchor namespaces that use the DNS protocol, just in a way that deliberately didn't provide any guarantee of uniqueness. The -13 text says otherwise in the introduction, however, so either my memory is more faulty than I thought or the direction has changed. Did I miss the conversation where the working group decided to pivot? (Not a rhetorical question! I am very prepared for the answer to be yes :-) If anybody has a handy pointer to the relevant part of the mailing list archive I'd appreciate it. ObReviewContribution: the authors list includes one A. Sullivan; let it be known that Mr Sullivan no longer works for Oracle. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt
On Thu, Jun 24, 2021 at 2:38 PM John Levine wrote: > > It appears that Ben Schwartz said: > >I think the "Privacy Considerations" section should probably mention QNAME > >minimization, which ought to help a little. > > I'd also like it to say more clearly up front that .ALT is for names that are > totally outside the DNS protocols, not for names handled locally using DNS > protocols. > It's for things like .onion, not like .local. Yup, what John said. The important part is: "This document reserves a string (ALT) to be used as a TLD label **in non-DNS contexts.**" (emphasis added). There are a bunch of different name resolution mechanisms - DNS is the most common, but there are also an increasing number of things like .onion, various blockchain-based systems (some of which have some cool privacy features), etc. For obvious reasons "alternate"[0] resolution systems use the same format/style of names as the DNS (LDH, case insensitivity, etc) - people want to be able to enter the identifiers into "normal" applications and have them just work (e.g things like "foo:bar:baz" don't work - ssh[1] for example won't pass this to a resolution call). There are similar issues with defining new schemas, etc; there is a reason that it's e.g http://www.facebookcorewwwi.onion/ and not http://www.facebookcorewwwi.¯\_(ツ)_/¯/ or hQQp://www.facebookcorewwwi.onion/. Unfortunately, having multiple resolution systems using the same namespace and syntax does not provide a signal to denote which resolution mechanism should be used - clearly .com is "in the DNS" and .onion isn't -- but this doesn't scale, and simply saying "the DNS is the only resolution system" doesn't either I'm guessing that everyone knows all this, but we had lots of *long* discussions around the various options in ~2014 - 2017, and I figured that much of the state might have been paged out... Some other background: https://www.iab.org/activities/workshops/explicit-internet-naming-systems-ename/ https://www.ietf.org/blog/ename-workshop/ > > > >I would also be interested in seeing some guidance about interaction > >between the relative form (.alt) and good old-fashioned search domains. It > >seems to me that the interaction there is poor... perhaps bad enough to > >recommend using the absolute form only. > > I thought we all agreed that search lists are bad when .CS was added to the > root. Yup. There should indeed be some more text around search-lists and search-list processing; much of the purpose of this is to be able to differentiate the namespaces, and search-lists are a place where they may bump into each other again. John's right again -- we *did* all agree that search lists are bad when .CS was added... and also in RFC 1123 (specifically, section 6.1.4.3 (2)), RFC 1535, and RFC 1536. Andrew McConachie and I even started writing "DNS Search Lists Considered Dangerous", before deciding that this was probably tilting at windmills... W [0]: This isn't intended to be pejorative, I'm just trying to separate these from what we normally assume in this community when we talk about a name resolution system [1]: OpenSSH_8.6p1, OpenSSL 1.1.1k 25 Mar 2021 > > > R's, > John > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-rfc8499bis-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Terminology Authors : Paul Hoffman Kazunori Fujiwara Filename: draft-ietf-dnsop-rfc8499bis-02.txt Pages : 54 Date: 2021-06-24 Abstract: The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 8499 and updates RFC 2308. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8499bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc8499bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt
It appears that Ben Schwartz said: >I think the "Privacy Considerations" section should probably mention QNAME >minimization, which ought to help a little. I'd also like it to say more clearly up front that .ALT is for names that are totally outside the DNS protocols, not for names handled locally using DNS protocols. It's for things like .onion, not like .local. >I would also be interested in seeing some guidance about interaction >between the relative form (.alt) and good old-fashioned search domains. It >seems to me that the interaction there is poor... perhaps bad enough to >recommend using the absolute form only. I thought we all agreed that search lists are bad when .CS was added to the root. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-avoid-fragmentation-05
Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-05. Please review it. https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-05 https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-05 Major changes are the following: 1. Moved some text from Introduction to Appendix A. Weaknesses of IP fragmentation. 2. Section 3.3 Default Maximum DNS/UDP payload size Generated Table 1 Default maximum DNS/UDP payload size 1400 as "Authors' recommendation". Moved details to Appendix B. Details of maximum DNS/UDP payload size discussions. Changed texts about " operators of DNS servers SHOULD measure their path MTU to UDP payload size. the Internet at setting up DNS servers" 3. added "IP_DONTFRAG option" definition in Terminology section. IP_DONTFRAG option is not defined by any RFCs. It is similar to IPV6_DONTFRAG option defined in [RFC3542]. IP_DONTFRAG option is used on BSD systems to set the Don't Fragment bit [RFC0791] when sending IPv4 packets. On Linux systems this is done via IP_MTU_DISCOVER and IP_PMTUDISC_DO. # IP_DONTFRAG is a macro used in BSD socket API. # IPV6_DONTFRAG is defined by RFC 3452, but it is BSD's IPv6 API. # Then, # We may need to change "IP_DONTFRAG" to "DF" bit. ([RFC0791]) # We may need to change "IPV6_DONTFRAG" to "Sending without Fragmentation". # (Good texts required.) # IPv6 experts, please advice. 4. Appendix sections reordered. Appendix A. Weaknesses of IP fragmentation Appendix B. Details of maximum DNS/UDP payload size discussions Appendix C. How to retrieve path MTU value to a destination from applications Appendix D. How to retrieve minimal MTU value to a destination Appendix E. Minimal-responses 5. Added some names in Acknowledgeent section -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
