Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
On Fri, Aug 23, 2019 at 05:08:59PM -0700, Erik Kline wrote a message of 237 lines which said: > +1 from me, fwiw. No discussion since, and the draft is expired. Any news? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
On Sun, Aug 25, 2019 at 5:57 PM Martin Thomson wrote: > > Abstract: > >This document reserves a string (ALT) to be used as a TLD label in > >non-DNS contexts. It also provides advice and guidance to developers > >developing alternative namespaces. > > In discussion, the alternative name .arc was proposed as short for > "alternative resolution context". That sounds like an amazing discussion! > Unless the intent was a direct invocation of the best parts of Usenet, in > which case carry on. Yeah! thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
> Abstract: >This document reserves a string (ALT) to be used as a TLD label in >non-DNS contexts. It also provides advice and guidance to developers >developing alternative namespaces. In discussion, the alternative name .arc was proposed as short for "alternative resolution context". Unless the intent was a direct invocation of the best parts of Usenet, in which case carry on. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
+1 looks good to me :) - Cynthia On Fri, Aug 23, 2019 at 11:18 PM wrote: > > 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 : The ALT Special Use Top Level Domain > Authors : Warren Kumari > Andrew Sullivan > Filename: draft-ietf-dnsop-alt-tld-12.txt > Pages : 11 > Date: 2019-08-23 > > Abstract: >This document reserves a string (ALT) to be used as a TLD label in >non-DNS contexts. It also provides advice and guidance to developers >developing alternative namespaces. > >[Ed note: Text inside square brackets ([]) is additional background >information, answers to frequently asked questions, general musings, >etc. They will be removed before publication. This document is >being collaborated on in Github at: https://github.com/wkumari/draft- >wkumari-dnsop-alt-tld. The most recent version of the document, open >issues, etc should all be available here. The authors (gratefully) >accept pull requests. ] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-12 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-12 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
On 8/25/2019 9:21 AM, Paul Wouters wrote: > > > On Fri, 23 Aug 2019 at 14:18, wrote: > >> 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 : The ALT Special Use Top Level Domain >> Authors : Warren Kumari >> Andrew Sullivan >> Filename : draft-ietf-dnsop-alt-tld-12.txt >> Pages : 11 >> Date : 2019-08-23 > > I am not a big fan, and I don't think many alternative projects will > pick .alt even if just for cosmetic reasons, but I don't have any > reason to object either. It's cheap and if it remains unused, that > is okay. > > And one advantage is that if people want to claim a TLD, we can point > them to .alt, so it should decrease the pressure on using RFC 6761 which > will prevent more bureaucratic time used up in dnsop meetings. The expected advantage is that any resolver could respond to a DNS query for names under .alt with an NX domain error code, unless they have specific code to handle the 2LD under .alt. This provides a semantic of "won't leak by default", which is nice. This is reasonably well explained in section 3.1, and is indeed a significant difference from constructs like ".home.arpa", in which the name leaks by default unless the resolver has special knowledge of the 2LD. On the other hand, resolvers should by now have implemented a filter for ".local" similar from the one planned for ".alt". Yet leaked requests for names in ".local" represent over 3% of requests sent to the root, so there are clearly a bunch of resolvers out there that did not bother with RFC 6761. I would not bet that these same resolvers would program anything special for .alt. > > Has Issues: > > I think the document is contradicting and not clear at all on what to do > with queries. It mixes up "should not be resolved" with "should not be > handled specially" based on some assumed difference of stub resolver and > resolver and Caching Server. On top of that, a stub resolver and caching > server are likely to use the same underlying library calls, so asking > for different behaviour is unrealistic for implementors. > > It would also be good to stick to the DNS Terminology, which I think it > does not do with the list of different players in the resolving chain. > > > > Writers of name resolution APIs and libraries which operate in > the DNS context should not attempt to look these names up in the > DNS. > > vs: > > Caching DNS servers SHOULD NOT recognize these names as special > > These two cannot both be true. The latter is also really false since the > ..alt is marked as Special Domain, so caching resolvers _should_ > handle it > specially. +1 I find it rather confusing that the advice to implementers is in the IANA section. I understand that RFC 6761 prescribes a checklist, but I would rather see a "deployment considerations" section of its own, and then quote that section from the RFC 6761 checklist. The deployment section should basically say something like "DNS Servers MUST recognize the .alt names as special and reply to any request with a No Such Domain error." This has two rationales: - It ensures that requests that are meant to be private to a specific domain cannot be observed on the global Internet, which is good for privacy. - It ensures that requests that are meant for a different resolution method do not create extra load for DNS servers after the first resolver, which reduces operation overhead. It is pretty clear that not all servers will be updated overnight. By default, the requests will progress all the way to the root, which will issue an NX Domain response, just like it does for requests to .local or ..home today. If recursive resolvers cache the negative responses, they will end up with an "almost correct" behavior. The main point of contention is probably DNSSEC. Recursive resolvers that recognize ".alt" as special can issue an NX Domain response, but secure denial requires caching a negative response signed by the root. What if the client requires DNSSEC? Should there be some guidance in the deployment considerations? > > Likely the best advise to implementors is to use a Query Minimization > based answer of the non-existence of .alt that prevents further leakage > of the specific name within .alt that was used. I would like to see this > very prominently stated instead of the scattered bullet list on what to > do. > > Authoritative DNS servers SHOULD NOT recognize these names as > special > > Why not? I think they should refuse to load any .alt zones. It is > supposed to be Special Use for non-DNS protocols. Why let it be abused > as "real" DNS zones? Do we want to support "almost DNS like" protocols > that would re-use authoritative DNS server code? That seems very >
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
On Fri, 23 Aug 2019 at 14:18, wrote: 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 : The ALT Special Use Top Level Domain Authors : Warren Kumari Andrew Sullivan Filename : draft-ietf-dnsop-alt-tld-12.txt Pages : 11 Date : 2019-08-23 I am not a big fan, and I don't think many alternative projects will pick .alt even if just for cosmetic reasons, but I don't have any reason to object either. It's cheap and if it remains unused, that is okay. And one advantage is that if people want to claim a TLD, we can point them to .alt, so it should decrease the pressure on using RFC 6761 which will prevent more bureaucratic time used up in dnsop meetings. Has Issues: I think the document is contradicting and not clear at all on what to do with queries. It mixes up "should not be resolved" with "should not be handled specially" based on some assumed difference of stub resolver and resolver and Caching Server. On top of that, a stub resolver and caching server are likely to use the same underlying library calls, so asking for different behaviour is unrealistic for implementors. It would also be good to stick to the DNS Terminology, which I think it does not do with the list of different players in the resolving chain. Writers of name resolution APIs and libraries which operate in the DNS context should not attempt to look these names up in the DNS. vs: Caching DNS servers SHOULD NOT recognize these names as special These two cannot both be true. The latter is also really false since the ..alt is marked as Special Domain, so caching resolvers _should_ handle it specially. Likely the best advise to implementors is to use a Query Minimization based answer of the non-existence of .alt that prevents further leakage of the specific name within .alt that was used. I would like to see this very prominently stated instead of the scattered bullet list on what to do. Authoritative DNS servers SHOULD NOT recognize these names as special Why not? I think they should refuse to load any .alt zones. It is supposed to be Special Use for non-DNS protocols. Why let it be abused as "real" DNS zones? Do we want to support "almost DNS like" protocols that would re-use authoritative DNS server code? That seems very dangerous. DNS server operators SHOULD be aware that queries for names ending in .alt are not DNS names I read this first as "DNS servers" not as "humans". I don't think RFC 2119 language should apply to humans (well, I think it should but I think we are not the Human Police either :) DNS Registries/Registrars MUST NOT grant requests to register ".alt" names in the normal way to any person or entity. This is outside the scope of IETF. If ICANN wants to make a statement about this, they should do so elsewhere? Since registrars/registries cannot do this anyway, the advise is silly. And for any alt-root operators, this line isn't going to change their behaviour anyway. Plus, due to the above processing rules, DNS libraries will prevent them from running an alt-root .alt DNS zone anyway. Earlier versions of this document requested I think this section can be removed, or moved to an appendix. (and their stub resolver library has not been updated to ignore queries for names ending in .alt) This again goes against the "do not treat special" directive. Apparently, it is wanted that stub resolvers threat this differently. configured iterative resolver Stick to DNS Terminology... (or, if the resolver implements [RFC8198], a entry for .alt) this query will likely be sent to the DNS root servers. This does not parse. Also, I think the "local root" drafts/RFC would be more appropriate to cite here than Aggressive NSEC. But really, none of this should be cited here I think. It is not needed for the explanation at this place. One of the motivations for the creation of the .alt pseudo-TLD is that unmanaged labels in the managed root name space are subject to unexpected takeover. This could occur if the manager of the root name space decides to delegate the unmanaged label. This reads as if ICANN is the MITM this document is protecting for, which I don't think is the intension. I would also place the actual concern (your squatted domain might get delegated for real by another legitimate entity) in the introduction or abstract. It is not a security consideration of the draft itself. So it does not belong in the Security Considerations. The unmanaged and "registration not required" nature of labels beneath .alt provides the opportunity for an attacker to
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
On Fri, Aug 23, 2019 at 5:09 PM Erik Kline wrote: > > +1 from me, fwiw. > Seems fine to me, as well. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.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 : The ALT Special Use Top Level Domain Authors : Warren Kumari Andrew Sullivan Filename: draft-ietf-dnsop-alt-tld-12.txt Pages : 11 Date: 2019-08-23 Abstract: This document reserves a string (ALT) to be used as a TLD label in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- wkumari-dnsop-alt-tld. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-12 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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
