Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?
On 23.10.22 05:40, John Levine wrote: It appears that Eliot Lear said: As a matter of practicality, a registry surely will be form. It is simply a matter of whether the IANA will host it. If the IANA does not host it, then by shifting it elsewhere this group is actually weakening the IANA function, and that would be sad. But trying to turn IANA and .alt into a junior version of ICANN would be much worse than sad. Nobody is trying to do that. Eliot OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?
It appears that Eliot Lear said: >As a matter of practicality, a registry surely will be form. It is >simply a matter of whether the IANA will host it. If the IANA does not >host it, then by shifting it elsewhere this group is actually weakening >the IANA function, and that would be sad. But trying to turn IANA and .alt into a junior version of ICANN would be much worse than sad. Anyone who has spent any time at all anywhere near ICANN will assure you that anything that looks even a little bit like a place where party A can exclude party B from using name C will attract a whole lot of attention from people you do not want to waste time with. I agree that nature abhors a vacuum, but for this particular vacuum, I would be delighted for the suckage to happen elsewhere. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] protocol switches, was Possible alt-tld last call?
It appears that Wes Hardaker said: >The probably *right* solution is to fix all the documents specifying >implementation with respect to naming that assumes the DNS is the only >system (URLs) [1], and all the APIs that make use of it (getaddrinfo). >The list of RFCs to update to allow namespace selection is far from short. I can think of at least three places where I've seen DNS protocol switches: - turning a name into an IP address like getaddrinfo() - turning a name into a set of RRs, like when you stick local stuff into your DNS cache config - turning a name into a socket, like with .onion These are not mutually exclusive and there may be others. I'm not sure whether this is an IETF topic or an IRTF topic, but I do think it is long overdue for attention. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] a correction
Not to the content, but a note I sent earlier was sent from the wrong address (as ISE). The content is below, and should have been sent from my personal address (this one). My apologies for any confusion. Eliot I'm with Dave on this. There is nothing wrong with telling endpoints, “Don't transmit queries for .ALT." That is indeed the whole point. Paul, you're right: we can't stop applications from not doing this, but we can tell them what Good looks like. Eliot On 21.10.22 23:39, David Conrad wrote: This is true for all IETF protocols/specifications. Are you arguing RFC 2119 “MUST” is pointless? As far as I understand, the point of 2119 language is to be explicit in expected behaviors, not to imply that the Internet Police will hunt you down if you violate them. If the intent here is that .alt names should never be looked up via the DNS, then MUST NOT is the expected behavior, no? OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hi David, [Still with no hats] > -Original Message- > From: David Conrad > Sent: 22 October 2022 17:40 > To: Rob Wilton (rwilton) > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? > > Rob, > > On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) wrote: > > If this was a MUST NOT, then at the point that the RFC is published, would > that not mean that all DNS stub (and maybe recursive) resolvers immediately > become non complaint with the new standard? > > The draft says “Informational”. It is (maybe) recommending the partitioning > of > the domain name namespace, explicitly creating a sub-space that is for non- > DNS use. It makes no sense to me to then pretend it’s "just fine” to issue > DNS > queries in that sub-namespace. As I read it, the partitioning of the domain name namespace is really to achieve two aims: 1) to guarantee that .alt, and no domains under .alt, will ever exist in the DNS, and hence it will need be impossible for an alternative name resolution system to "shadow" valid .alt entries in the DNS (since there can be none). 2) it gives a place to experiment with alternative naming systems in a way that doesn't interfere with the DNS. As I understand it , some of these alternative name services are squatting on unallocated TLDs, and some browsers are resolving names in these alternative name services. This is not ideal, particularly if those unallocated TLDs end up getting sold by ICANN to companies that expect to use them with the regular DNS rather than any alternative name service. > > > My interpretation of Paul's comment is that nothing bad happens if a client > does attempt to resolve .alt names in the DNS because they will just fail in > the > same way as any other domain that doesn't exist in the DNS, and that is okay. > > But it is not OK. Yes, the root servers are surely provisioned to handle the > additional load the use of .alt might create, but it adds to the useless > noise — > why would the IETF encourage this? Worse, it exposes .alt traffic to > potential > eavesdroppers. I’m confused why the IETF would publish an informational > document that says both of those are not protocol violations. My assumption is that a browser, application, or even the OS, that supports any of these alternative name resolution services will have some code switch that decides to either look up the name in the DNS or look the name up in the alternative service. E.g., If my browser supports GNS, then the browser knows to try and resolve https://myfunkyname.gns.alt/ using GNS. If the browser has the code to do that, then I would also hope then it wouldn't also try and resolve the same domain in the DNS on failure to resolve it using GNS. But even if they did, I don't see that as really being a problem, it will just fail the same way as any other unknown domain. If a user types the same URL into a different browser that doesn’t support GNS, then stub resolver would naturally try and resolve https://myfunkyname.gns.alt/ in the DNS, which must fail because there can never be any domains in the DNS that end with .alt. It fails in the same way as if I mistype a URL and try and resolve "https:://google.con" rather than "https://google.com";. But I don't understand why this alternative browser, that doesn't care about alternative name resolution schemes at all, must change their code. This is outside my area of expertise, but I'm not convinced that the global DNS would see any significant increase in load, because the stub resolver would generally not be sending the requests to the DNS assuming that they are valid domains, and if they are not valid domains then that would seem to be the same as what DNS already handles today. And as for the eavesdropping concern, doesn't this equally apply for all domain lookups, particularly invalid ones? Regards, Rob > > > Possibly, the draft could have some text that allows stub resolves to > > filter out > DNS requests for .alt names if they wish. > > The point is that DNS resolvers of any kind are explicitly not supposed to see > .alt queries — .alt is NOT a DNS namespace. If they do (and they obviously > will), something is broken and should be fixed. > > Regards, > -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Rob, On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) wrote: > If this was a MUST NOT, then at the point that the RFC is published, would > that not mean that all DNS stub (and maybe recursive) resolvers immediately > become non complaint with the new standard? The draft says “Informational”. It is (maybe) recommending the partitioning of the domain name namespace, explicitly creating a sub-space that is for non-DNS use. It makes no sense to me to then pretend it’s "just fine” to issue DNS queries in that sub-namespace. > My interpretation of Paul's comment is that nothing bad happens if a client > does attempt to resolve .alt names in the DNS because they will just fail in > the same way as any other domain that doesn't exist in the DNS, and that is > okay. But it is not OK. Yes, the root servers are surely provisioned to handle the additional load the use of .alt might create, but it adds to the useless noise — why would the IETF encourage this? Worse, it exposes .alt traffic to potential eavesdroppers. I’m confused why the IETF would publish an informational document that says both of those are not protocol violations. > Possibly, the draft could have some text that allows stub resolves to filter > out DNS requests for .alt names if they wish. The point is that DNS resolvers of any kind are explicitly not supposed to see .alt queries — .alt is NOT a DNS namespace. If they do (and they obviously will), something is broken and should be fixed. Regards, -drc signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) wrote: > > If this was a MUST NOT, then at the point that the RFC is published, would > that not mean that all DNS stub (and maybe recursive) resolvers immediately > become non complaint with the new standard? That is exactly right. My bigger concern is the recursive resolvers you have in parentheses. The more new things that we say they must or should do, the more fragmented the DNS becomes because some will and some won't and many won't ever. Equally important: adding these new fragmenting rules have absolutely no effect on DNS users. > E.g., if I try and access https://somedomain.alt in my browser today then it > attempts to lookup the domain and fails because it doesn't exist. > My interpretation of Paul's comment is that nothing bad happens if a client > does attempt to resolve .alt names in the DNS because they will just fail in > the same way as any other domain that doesn't exist in the DNS, and that is > okay. Exactly right. The definition of the .alt SUDN is that it will not appear in the root zone, so that lookups will always just fail in the normal failure fashion. No new rules on resolvers are needed. > Possibly, the draft could have some text that allows stub resolves to filter > out DNS requests for .alt names if they wish. I.e., filtering does no harm, > performing the DNS lookup also does no harm, and the implementations can > decide if they want to add a special code path for this case or just follow > the standard code path. Decades of experience with RFCs has shown that MAY-level text like that confuses some implementers. Implementers that understand the protocol might already put in such a rule, possibly behind a configuration switch, as some do for names that they consider special. Implementers that don't understand the protocol are more likely to make mistakes if we say "you MAY $action", and in this case, $action will have no effect on DNS users. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hi David, If this was a MUST NOT, then at the point that the RFC is published, would that not mean that all DNS stub (and maybe recursive) resolvers immediately become non complaint with the new standard? E.g., if I try and access https://somedomain.alt in my browser today then it attempts to lookup the domain and fails because it doesn't exist. My interpretation of Paul's comment is that nothing bad happens if a client does attempt to resolve .alt names in the DNS because they will just fail in the same way as any other domain that doesn't exist in the DNS, and that is okay. Possibly, the draft could have some text that allows stub resolves to filter out DNS requests for .alt names if they wish. I.e., filtering does no harm, performing the DNS lookup also does no harm, and the implementations can decide if they want to add a special code path for this case or just follow the standard code path. Regards, Rob // No hats. // Also not a DNS expert, so apologies if I'm using the wrong terms/words ... > -Original Message- > From: DNSOP On Behalf Of David Conrad > Sent: 22 October 2022 00:55 > To: Paul Hoffman > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? > > Paul, > > On Oct 21, 2022, at 3:34 PM, Paul Hoffman > wrote: > >> If the intent here is that .alt names should never be looked up via the > DNS, then MUST NOT is the expected behavior, no? > > There is no such intent of the draft. > > Ah. Then I guess I don’t support the draft and the rest of my input is > irrelevant. > > Regards, > -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
