Re: [DNSOP] back to: Some distinctions and a request
On 2July2015Thursday, at 18:21, Robert Edmonds wrote: > manning wrote: >> There in lies the problem. These systems have no way to disambiguate a >> local v. global scope. >> It seems like the obvious solution is to ensure that these nodes do >> NOT have global scope, i.e. No connection to the Internets >> and no way to attempt DNS resolution. Or they need to ensure that >> DNS resolution occurs after every other “name lookup technology” >> which is not global in scope. > > I don't understand this point. Since Onion hidden service names are > based on hashes derived from public keys surely they're globally scoped > (barring hash collisions)? > > -- > Robert Edmonds If they _are_ globally scoped, what part of the local system decides which namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the DECnetV, the IXP, or the DNS… where is search order determined? Does first match in any namespace win? What is the tiebreaker when there are label collisions between namespaces? /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
manning wrote: > There in lies the problem. These systems have no way to disambiguate a > local v. global scope. > It seems like the obvious solution is to ensure that these nodes do > NOT have global scope, i.e. No connection to the Internets > and no way to attempt DNS resolution. Or they need to ensure that > DNS resolution occurs after every other “name lookup technology” > which is not global in scope. I don't understand this point. Since Onion hidden service names are based on hashes derived from public keys surely they're globally scoped (barring hash collisions)? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 16:44, Robert Edmonds wrote: > > Have a look at the later HTTP/1.1 RFCs (7230) and the URI generic syntax > RFC (3986). RFC 7230 defines http URIs, but it relies on the URI > generic syntax (RFC 3986) to define "uri-host"'s, and that specification > explicitly declines to require that "domain-looking-strings" be Internet > DNS names: > > 3.2.2. Host > > [...] > > This specification does not mandate a particular registered name > lookup technology and therefore does not restrict the syntax of reg- > name beyond what is necessary for interoperability. […] > . However, a globally scoped naming > system, such as DNS fully qualified domain names, is necessary for > URIs intended to have global scope. URI producers should use names > that conform to the DNS syntax, even when use of DNS is not > immediately apparent, and should limit these names to no more than > 255 characters in length. > > [...] > > -- > Robert Edmonds There in lies the problem. These systems have no way to disambiguate a local v. global scope. It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets and no way to attempt DNS resolution. Or they need to ensure that DNS resolution occurs after every other “name lookup technology” which is not global in scope. Paul Vixies point about an escape method not being apparently visible comes to mind. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
manning wrote: > Hum… “domain-looking-string” … Per RFC 1945, we read: > "3.2.2 http URL > > >The "http" scheme is used to locate network resources via the HTTP >protocol. This section defines the scheme-specific syntax and >semantics for http URLs. > >http_URL = "http:" "//" host [ ":" port ] [ abs_path ] > >host = or IP address (in dotted-decimal form), > as defined by > Section 2.1 of RFC 1123 > > > >port = *DIGIT” > > So then the question on the table is, What is a “legal host domain name”? > RFC 1123, using SMTP as the example, says: > > "5.3.5 Domain Name Support > > SMTP implementations MUST use the mechanism defined in > Section 6.1 for mapping between domain names and IP addresses. This > means that every Internet SMTP MUST include support for the > Internet DNS.” > > This STRONGLY suggests that “domain-looking-string” is , in fact, a host > that is identified using the Internet DNS. Have a look at the later HTTP/1.1 RFCs (7230) and the URI generic syntax RFC (3986). RFC 7230 defines http URIs, but it relies on the URI generic syntax (RFC 3986) to define "uri-host"'s, and that specification explicitly declines to require that "domain-looking-strings" be Internet DNS names: 3.2.2. Host [...] This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg- name beyond what is necessary for interoperability. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. However, a globally scoped naming system, such as DNS fully qualified domain names, is necessary for URIs intended to have global scope. URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length. [...] -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
the ^G registration was done prior to RFC 1123 being written. I think, this whole discussion (particularly Ed Lewis’s POV about wire formats v. readings from RFC 1034 suggest reopening the can’o’worms that was/is the IDN debate and 8bit clean, native Unicode, etc. Regarding Andrew S. recognition that the horse has left the barn (.local, .onion, etc.) there are two options open: 1) close the door before others escape and completely pollute the watershed, 2) throw in the towel and give up manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 15:26, Mark Andrews wrote: > > In message , Edward Lewis writes: >> On 7/2/15, 13:34, "DNSOP on behalf of Paul Vixie" > on behalf of p...@redbarn.org> wrote: >> >>> manning wrote: ... STRONGLY suggests that =E2=80=9Cdomain-looking-string=E2=80=9D is , in >> fact, a host that is identified using the Internet DNS. >>> >>> i agree with this interpretation, which means, it's the spec itself >>> that's wrong, not hugo's interpretation of it. the internet people >>> didn't love .UUCP addresses either but that didn't stop them from working. >>> >>> what the internet should be doing is defining escape mechanisms for >>> non-internet systems, rather than saying "we are the only thing you can >>> use". >> >> At the risk of further annoying Andrews ... if there was a definition of >> domain name in contexts external to the DNS, that would be helpful. Plus, >> in each context, what are the escape rules, if needed? >> >> E.g., At one time, some "funny guy" tried to register ctrl-G as a TLD. >> (He knows who he is.) How would that be written in a URL? > > In a domain name: \007 (RFC 1034 presentation encoding) > In a host name: not possible as it is outside the allowable syntax. > In a url it would depend upon the scheme. It would not be valid for > http:, https: or mailto: to start with as all three are restricted to > using hostnames. For those schemes where it is valid input %07. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > 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] back to: Some distinctions and a request
Edward Lewis wrote:
> To me a domain name is: a sequence of bits that, when rendered in hex
> notation, can look like this:
>
> 0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00
>
> That is what is sent over the wire, through ports and is deposited in
> memory of name servers. Note the lack of dots. And this is why I can't
> see a difference between domain names and DNS names. To me, they are one
> in the same.
>
> This dates back to a discussion had while the labs I was in was developing
> DNSSEC code. Our boss (Russ Mundy) made the statement that there are two
> versions of a domain name, on-the-wire and in-the-file and it was the
> on-the-wire format that mattered. Later in my career I worked with a firm
> that developed it's own DNS code based on some legacy stuff from it's
> start-up days. The start-up operated on the in-the-file format,
> converting to and from on-the-wire format constantly. This was not a good
> approach.
>
> So when I hear "domain name" I think of the format that includes an octet
> with flags and a number and then that number of octets of data,
> terminating with a null octet. What is seen in files is just a
> transliteration of that, "abc.example." is just a conventional way to
> represent the domain name above.
Hi, Ed:
I have a somewhat different understanding. I read in 1034 §3.1 that:
The domain name space is a tree structure. Each node and leaf on
the tree corresponds to a resource set (which may be empty). [...]
The domain name of a node is the list of the labels on the path from
the node to the root of the tree. [...]
These definitions use abstract data types like trees and lists. (They
shouldn't be confused with concrete data structure implementations of
those types.)
The same section then defines two concrete representations of domain
names:
[DNS wire format names.] Internally, programs that manipulate
domain names should represent them as sequences of labels, where
each label is a length octet followed by an octet string. [...]
[DNS "presentation format" names.] When a user needs to type a
domain name, the length of each label is omitted and the labels are
separated by dots ("."). Since a complete domain name ends with the
root label, this leads to a printed form which ends in a dot. [...]
So, I take the octet sequence \# 13 03616263076578616D706C6500 and the
character string "abc.example." to be two different representations of
the domain name whose list of labels is "abc", "example", and "". But I
don't see how one of the concrete forms is a transliteration of the
other.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
agreed. but a “reserved string” registry isn’t the way to do that… at least in a scaleable fashion. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 10:34, Paul Vixie wrote: > > > manning wrote: >> ... STRONGLY suggests that “domain-looking-string” is , in fact, a >> host that is identified using the Internet DNS. > > i agree with this interpretation, which means, it's the spec itself > that's wrong, not hugo's interpretation of it. the internet people > didn't love .UUCP addresses either but that didn't stop them from working. > > what the internet should be doing is defining escape mechanisms for > non-internet systems, rather than saying "we are the only thing you can > use". > > -- > Paul Vixie > > ___ > 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] back to: Some distinctions and a request
On Thu, Jul 02, 2015 at 10:34:42AM -0700, Paul Vixie wrote: > what the internet should be doing is defining escape mechanisms for > non-internet systems, rather than saying "we are the only thing you can > use". The Internet _has_ done that. Unfortunately (and I do think it's unfortunate), the Internet did this by in-band signalling in things that go in domain name slots in protocol strings. That what local. (and, given its deployment, onion.) are doing. I don't have to like it to recognize that this has happened, and that as people who are trying to design systems to maximize interoperability we have to cope with those facts. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
In message , Edward Lewis writes: > On 7/2/15, 13:34, "DNSOP on behalf of Paul Vixie" on behalf of p...@redbarn.org> wrote: > > >manning wrote: > >> ... STRONGLY suggests that =E2=80=9Cdomain-looking-string=E2=80=9D is , in > fact, a > >> host that is identified using the Internet DNS. > > > >i agree with this interpretation, which means, it's the spec itself > >that's wrong, not hugo's interpretation of it. the internet people > >didn't love .UUCP addresses either but that didn't stop them from working. > > > >what the internet should be doing is defining escape mechanisms for > >non-internet systems, rather than saying "we are the only thing you can > >use". > > At the risk of further annoying Andrews ... if there was a definition of > domain name in contexts external to the DNS, that would be helpful. Plus, > in each context, what are the escape rules, if needed? > > E.g., At one time, some "funny guy" tried to register ctrl-G as a TLD. > (He knows who he is.) How would that be written in a URL? In a domain name: \007 (RFC 1034 presentation encoding) In a host name: not possible as it is outside the allowable syntax. In a url it would depend upon the scheme. It would not be valid for http:, https: or mailto: to start with as all three are restricted to using hostnames. For those schemes where it is valid input %07. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
On 7/2/15, 13:34, "DNSOP on behalf of Paul Vixie" wrote: > > >manning wrote: >> ... STRONGLY suggests that “domain-looking-string” is , in fact, a >> host that is identified using the Internet DNS. > >i agree with this interpretation, which means, it's the spec itself >that's wrong, not hugo's interpretation of it. the internet people >didn't love .UUCP addresses either but that didn't stop them from working. > >what the internet should be doing is defining escape mechanisms for >non-internet systems, rather than saying "we are the only thing you can >use". At the risk of further annoying Andrews ... if there was a definition of domain name in contexts external to the DNS, that would be helpful. Plus, in each context, what are the escape rules, if needed? E.g., At one time, some "funny guy" tried to register ctrl-G as a TLD. (He knows who he is.) How would that be written in a URL? smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
On 7/2/15, 12:04, "DNSOP on behalf of Hugo Maxwell Connery" wrote: > >I believe that you are making a category error here. The key >point is that the softwares that are using the domain name (dot >separated network identifier) labeling system do not wish to >use the DNS architecture for name to address resolution, at all. That's well understood. >However, they may wish to use the excellent transport mechanisms >that IETF have defined over the years, including the latest version(s) >of TLS. I come back to this below when considering the failure >mode of communication to a URI. Instead of "transport" which for me and others means things like TCP and UDP, I think you mean applications. If I understand correctly, Tor uses web browsers and URLs because the existing base does what Tor needs. Which is fine. Code reuse, etc. >Additionally, they wish to protect the privacy of their users by >having the DNS reject to resolve these names. That's not a way to protect privacy. Just asking a DNS server "leaks" some information. The DNS can't prevent anyone from asking, rejecting the query is too late. OTOH, as someone managing DNS operations, the queries don't leak enough of the right information (although they may leak the wrong information, with "right/wrong" a subjective call). >We have a mechanism which reliably translates www.example.org >into some on-the-wire byte representation and works. This does not need >to change, or even be investigated. My point about on-the-wire was a tad bit obtuse. I was trying to explain what I thought a domain name was and relied upon the DNS protocol's version of what goes out the socket, through the port and out over the electromagnetic waves. I figure the DNS itself is unique in the formatting. When URLs go into the electromagnetic medium, I bet they are converted into something ascii-compatible or unicode encoded (I haven't checked). When X.509 certificates go out, the subjectAltName holding a domain name would be passed through ASN.1, then maybe a DER/BER/etc., and so on. If that's what is meant by a domain name, it's not what I was thinking. I wasn't trying to say all applications use the DNS format, just that when it comes to DNS names and domain names, I think of them as the same because I usually operate on the DNS wire format. Still, I'd like to see a common definition of what a "domain name" is in the context of domain name use in URLs, email addresses, X.509 subjectAltName and other places I'm not listing because I'm not thinking of them. >Here is what I believe the non-DNS resolution softwares want: > >1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) >within the root zone as "not a domain". i.e if anyone asks the >answer for anything in or under that pTLD the answer is NXDOMAIN. To some extent this is just a registration of the string in the root TLD. Just like registering a name that will "work" the impact is about the same up though registration. I thought about how to scale this and make this work seeing that there's a high application fee for positive registrations. I don't have a clear answer. An alt-TLD is a good partial solution, i.e., reserving one string the root is something I can see as possible but not a TLD per "not a domain" domain-looking namespace. E.g., One concern is confusability between names. Like, is example. and exmple. the same thing? This has been an issue amongst commercial names. But what about .bit and .b1t? Neglecting money, cost, budget, there's still work to be done to avoid the ensuing operational issues that would likely follow. >2. Iterative resolution software to also be aware of this, such that >they have a permanent in cache response to hand out NXDOMAIN >without bothering the root zone's resolvers (and exposing the query). That's a lot of code to distribute. And existing code bases don't do this now. (Yes, the usual excuse for not innovating.) The reality is you can't stop someone from asking overnight. I could see such software consulting the special use domain name registry and dynamically deciding how to resolve the name. But that's generations (of code) off into the future. >3. qname minimisation to be approved and implemented. In this case, >if 2. is not achieved the exposure of the end user system is dramatically >limited. I see this as a non-sequitir. If one is not supposed to ask the DNS, then it doesn't matter. If one is leaking, this only means that some of the authoritative servers don't see the intended name, the recursive does. >All of the above is "worst case usage" from these softwares. Normal >operation is that the DNS architecture does not even see these name >resolutions happening -- they use whichever mechanism they have >designed and implemented -- the end user is satisfied (assuming their >mechanism works) and the DNS knows nothing. > >Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ > >When entered into the Tor browser, the DNS sees
Re: [DNSOP] back to: Some distinctions and a request
manning wrote: > ... STRONGLY suggests that “domain-looking-string” is , in fact, a > host that is identified using the Internet DNS. i agree with this interpretation, which means, it's the spec itself that's wrong, not hugo's interpretation of it. the internet people didn't love .UUCP addresses either but that didn't stop them from working. what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying "we are the only thing you can use". -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
Hum… “domain-looking-string” … Per RFC 1945, we read: "3.2.2 http URL The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs. http_URL = "http:" "//" host [ ":" port ] [ abs_path ] host = port = *DIGIT” So then the question on the table is, What is a “legal host domain name”? RFC 1123, using SMTP as the example, says: "5.3.5 Domain Name Support SMTP implementations MUST use the mechanism defined in Section 6.1 for mapping between domain names and IP addresses. This means that every Internet SMTP MUST include support for the Internet DNS.” This STRONGLY suggests that “domain-looking-string” is , in fact, a host that is identified using the Internet DNS. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 9:59, Hugo Maxwell Connery wrote: > manning, > > The "defense" is the defense of the privacy of their community > due to the commonality of the URI format. > > (protocol)://(domain-looking-string)/(path). > > Open that with the "right" software and all is good, no privacy is > lost, and the DNS is not involved. Open it with > DNS based software and you leak information / lose privacy. > > It is that simple. > > The negative registration is to minimize info leakage and loss of > privacy, which apparently we care about. > > Hugo Connery > -- > 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman. > > From: DNSOP [dnsop-boun...@ietf.org] on behalf of manning > [bmann...@karoshi.com] > Sent: Thursday, 2 July 2015 18:40 > To: Hugo Maxwell Connery > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] back to: Some distinctions and a request > > If that is the case, that these folks don’t want to use the DNS > name-address resolution at all, then > there should be no objection to use of those labels in the DNS by folks who > DO wish to use DNS > for its intended purpose. If House Finch Feathers OY applies to ICANN for > the .ONION TLD, there > should be zero objection, since other use is outside the scope of the DNS. > > the use of a “reserved label” registry simply for “defensive” purposes is > properly outside > the scope of the IETF goal of defining and developing Internet Protocols. > > As to Andrews excellent attempt to disambiguate name space for domains and > the DNS, I appreciate > effort, but the facts are that overlaps occur in real life (see also: > acronym overload) and the name space > in question is the DNS view of the name space, not domain name space en-toto. >(whee - hows that for > a run-on sentence!) > > manning > bmann...@karoshi.com > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > > > On 2July2015Thursday, at 9:04, Hugo Maxwell Connery wrote: > >> >> Hi Mr Lewis, and list, >> >> I believe that you are making a category error here. The key >> point is that the softwares that are using the domain name (dot >> separated network identifier) labeling system do not wish to >> use the DNS architecture for name to address resolution, at all. >> >> However, they may wish to use the excellent transport mechanisms >> that IETF have defined over the years, including the latest version(s) >> of TLS. I come back to this below when considering the failure >> mode of communication to a URI. >> >> Additionally, they wish to protect the privacy of their users by >> having the DNS reject to resolve these names. >> >> We have a mechanism which reliably translates www.example.org >> into some on-the-wire byte representation and works. This does not need >> to change, or even be investigated. >> >> Here is what I believe the non-DNS resolution softwares want: >> >> 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) >> within the root zone as "not a domain". i.e if anyone asks the >> answer for anything in or under that pTLD the answer is NXDOMAIN. >> >> 2. Iterative resolution software to also be aware of this, such that >> they have a permanent in cache response to hand out NXDOMAIN >> without bothering the root zone's resolvers (and exposing the query). >> >> 3. qname minimisation to be approved and implemented. In this case, >> if 2. is not achieved the exposure of the end user system is dramatically >> limited. >> >> All of the above is "
Re: [DNSOP] back to: Some distinctions and a request
manning, The "defense" is the defense of the privacy of their community due to the commonality of the URI format. (protocol)://(domain-looking-string)/(path). Open that with the "right" software and all is good, no privacy is lost, and the DNS is not involved. Open it with DNS based software and you leak information / lose privacy. It is that simple. The negative registration is to minimize info leakage and loss of privacy, which apparently we care about. Hugo Connery -- 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman. From: DNSOP [dnsop-boun...@ietf.org] on behalf of manning [bmann...@karoshi.com] Sent: Thursday, 2 July 2015 18:40 To: Hugo Maxwell Connery Cc: dnsop@ietf.org Subject: Re: [DNSOP] back to: Some distinctions and a request If that is the case, that these folks don’t want to use the DNS name-address resolution at all, then there should be no objection to use of those labels in the DNS by folks who DO wish to use DNS for its intended purpose. If House Finch Feathers OY applies to ICANN for the .ONION TLD, there should be zero objection, since other use is outside the scope of the DNS. the use of a “reserved label” registry simply for “defensive” purposes is properly outside the scope of the IETF goal of defining and developing Internet Protocols. As to Andrews excellent attempt to disambiguate name space for domains and the DNS, I appreciate effort, but the facts are that overlaps occur in real life (see also: acronym overload) and the name space in question is the DNS view of the name space, not domain name space en-toto. (whee - hows that for a run-on sentence!) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 9:04, Hugo Maxwell Connery wrote: > > Hi Mr Lewis, and list, > > I believe that you are making a category error here. The key > point is that the softwares that are using the domain name (dot > separated network identifier) labeling system do not wish to > use the DNS architecture for name to address resolution, at all. > > However, they may wish to use the excellent transport mechanisms > that IETF have defined over the years, including the latest version(s) > of TLS. I come back to this below when considering the failure > mode of communication to a URI. > > Additionally, they wish to protect the privacy of their users by > having the DNS reject to resolve these names. > > We have a mechanism which reliably translates www.example.org > into some on-the-wire byte representation and works. This does not need > to change, or even be investigated. > > Here is what I believe the non-DNS resolution softwares want: > > 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) > within the root zone as "not a domain". i.e if anyone asks the > answer for anything in or under that pTLD the answer is NXDOMAIN. > > 2. Iterative resolution software to also be aware of this, such that > they have a permanent in cache response to hand out NXDOMAIN > without bothering the root zone's resolvers (and exposing the query). > > 3. qname minimisation to be approved and implemented. In this case, > if 2. is not achieved the exposure of the end user system is dramatically > limited. > > All of the above is "worst case usage" from these softwares. Normal > operation is that the DNS architecture does not even see these name > resolutions happening -- they use whichever mechanism they have > designed and implemented -- the end user is satisfied (assuming their > mechanism works) and the DNS knows nothing. > > Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ > > When entered into the Tor browser, the DNS sees absolutely no traffic, at all, > irrespective of whether the "domain name" exists. E.g if > asdfasdfasdfasdf.onion > is not defined within the Tor network, still the DNS sees nothing. > However, some configuration of a recently defined TLS transport is used > (https). > > When opened with a regular browser, the use of the Tor network is > exposed, as described above. The communication will fail, as > the asdfasdfasdfasdf sub-domain is not registered (and hopefully > not registerable). We are talking about *how* it fails, and reducing > the leaking of information in that process. > > All of these on-list discussions are about point 1. above; Negative > registration > in the root zone via RFC6761. > > Steps 2 and 3 are, I expect, also on the agendas for these overlay networks, > because they care about the privacy of their community. > > If point 2 could be universally achieved, points 1 and 3 are moot. > But, that is never doing to happen, thus the current approach.
Re: [DNSOP] back to: Some distinctions and a request
If that is the case, that these folks don’t want to use the DNS name-address resolution at all, then there should be no objection to use of those labels in the DNS by folks who DO wish to use DNS for its intended purpose. If House Finch Feathers OY applies to ICANN for the .ONION TLD, there should be zero objection, since other use is outside the scope of the DNS. the use of a “reserved label” registry simply for “defensive” purposes is properly outside the scope of the IETF goal of defining and developing Internet Protocols. As to Andrews excellent attempt to disambiguate name space for domains and the DNS, I appreciate effort, but the facts are that overlaps occur in real life (see also: acronym overload) and the name space in question is the DNS view of the name space, not domain name space en-toto. (whee - hows that for a run-on sentence!) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 9:04, Hugo Maxwell Connery wrote: > > Hi Mr Lewis, and list, > > I believe that you are making a category error here. The key > point is that the softwares that are using the domain name (dot > separated network identifier) labeling system do not wish to > use the DNS architecture for name to address resolution, at all. > > However, they may wish to use the excellent transport mechanisms > that IETF have defined over the years, including the latest version(s) > of TLS. I come back to this below when considering the failure > mode of communication to a URI. > > Additionally, they wish to protect the privacy of their users by > having the DNS reject to resolve these names. > > We have a mechanism which reliably translates www.example.org > into some on-the-wire byte representation and works. This does not need > to change, or even be investigated. > > Here is what I believe the non-DNS resolution softwares want: > > 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) > within the root zone as "not a domain". i.e if anyone asks the > answer for anything in or under that pTLD the answer is NXDOMAIN. > > 2. Iterative resolution software to also be aware of this, such that > they have a permanent in cache response to hand out NXDOMAIN > without bothering the root zone's resolvers (and exposing the query). > > 3. qname minimisation to be approved and implemented. In this case, > if 2. is not achieved the exposure of the end user system is dramatically > limited. > > All of the above is "worst case usage" from these softwares. Normal > operation is that the DNS architecture does not even see these name > resolutions happening -- they use whichever mechanism they have > designed and implemented -- the end user is satisfied (assuming their > mechanism works) and the DNS knows nothing. > > Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ > > When entered into the Tor browser, the DNS sees absolutely no traffic, at all, > irrespective of whether the "domain name" exists. E.g if > asdfasdfasdfasdf.onion > is not defined within the Tor network, still the DNS sees nothing. > However, some configuration of a recently defined TLS transport is used > (https). > > When opened with a regular browser, the use of the Tor network is > exposed, as described above. The communication will fail, as > the asdfasdfasdfasdf sub-domain is not registered (and hopefully > not registerable). We are talking about *how* it fails, and reducing > the leaking of information in that process. > > All of these on-list discussions are about point 1. above; Negative > registration > in the root zone via RFC6761. > > Steps 2 and 3 are, I expect, also on the agendas for these overlay networks, > because they care about the privacy of their community. > > If point 2 could be universally achieved, points 1 and 3 are moot. > But, that is never doing to happen, thus the current approach. > > Sincerely, Hugo Connery > > NB: I am not a member of the community for any of these networks, and > I certainly dont speak on their behalf. I do use Tor regularly. > ____ > From: Edward Lewis [edward.le...@icann.org] > Sent: Thursday, 2 July 2015 14:51 > To: Hugo Maxwell Connery; Andrew Sullivan; dnsop@ietf.org > Subject: Re: [DNSOP] back to: Some distinctions and a request > > On 7/2/15, 6:02, "DNSOP on behalf of Hugo Maxwell Connery" > wrote: > >> Hi, >> >> I think that Andrew's effort to distinguish between a domain name and >> a DNS name is useful. It gives us some clear terminology to use to >> discuss domain names that wish to use a non-DNS name resolution >> method. &g
Re: [DNSOP] back to: Some distinctions and a request
Hi Mr Lewis, and list, I believe that you are making a category error here. The key point is that the softwares that are using the domain name (dot separated network identifier) labeling system do not wish to use the DNS architecture for name to address resolution, at all. However, they may wish to use the excellent transport mechanisms that IETF have defined over the years, including the latest version(s) of TLS. I come back to this below when considering the failure mode of communication to a URI. Additionally, they wish to protect the privacy of their users by having the DNS reject to resolve these names. We have a mechanism which reliably translates www.example.org into some on-the-wire byte representation and works. This does not need to change, or even be investigated. Here is what I believe the non-DNS resolution softwares want: 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) within the root zone as "not a domain". i.e if anyone asks the answer for anything in or under that pTLD the answer is NXDOMAIN. 2. Iterative resolution software to also be aware of this, such that they have a permanent in cache response to hand out NXDOMAIN without bothering the root zone's resolvers (and exposing the query). 3. qname minimisation to be approved and implemented. In this case, if 2. is not achieved the exposure of the end user system is dramatically limited. All of the above is "worst case usage" from these softwares. Normal operation is that the DNS architecture does not even see these name resolutions happening -- they use whichever mechanism they have designed and implemented -- the end user is satisfied (assuming their mechanism works) and the DNS knows nothing. Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ When entered into the Tor browser, the DNS sees absolutely no traffic, at all, irrespective of whether the "domain name" exists. E.g if asdfasdfasdfasdf.onion is not defined within the Tor network, still the DNS sees nothing. However, some configuration of a recently defined TLS transport is used (https). When opened with a regular browser, the use of the Tor network is exposed, as described above. The communication will fail, as the asdfasdfasdfasdf sub-domain is not registered (and hopefully not registerable). We are talking about *how* it fails, and reducing the leaking of information in that process. All of these on-list discussions are about point 1. above; Negative registration in the root zone via RFC6761. Steps 2 and 3 are, I expect, also on the agendas for these overlay networks, because they care about the privacy of their community. If point 2 could be universally achieved, points 1 and 3 are moot. But, that is never doing to happen, thus the current approach. Sincerely, Hugo Connery NB: I am not a member of the community for any of these networks, and I certainly dont speak on their behalf. I do use Tor regularly. From: Edward Lewis [edward.le...@icann.org] Sent: Thursday, 2 July 2015 14:51 To: Hugo Maxwell Connery; Andrew Sullivan; dnsop@ietf.org Subject: Re: [DNSOP] back to: Some distinctions and a request On 7/2/15, 6:02, "DNSOP on behalf of Hugo Maxwell Connery" wrote: >Hi, > >I think that Andrew's effort to distinguish between a domain name and >a DNS name is useful. It gives us some clear terminology to use to >discuss domain names that wish to use a non-DNS name resolution >method. Until this message, I wasn't clear on Andrew's distinction - we have been talking off-list for the past few days too. To me a domain name is: a sequence of bits that, when rendered in hex notation, can look like this: 0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00 That is what is sent over the wire, through ports and is deposited in memory of name servers. Note the lack of dots. And this is why I can't see a difference between domain names and DNS names. To me, they are one in the same. This dates back to a discussion had while the labs I was in was developing DNSSEC code. Our boss (Russ Mundy) made the statement that there are two versions of a domain name, on-the-wire and in-the-file and it was the on-the-wire format that mattered. Later in my career I worked with a firm that developed it's own DNS code based on some legacy stuff from it's start-up days. The start-up operated on the in-the-file format, converting to and from on-the-wire format constantly. This was not a good approach. So when I hear "domain name" I think of the format that includes an octet with flags and a number and then that number of octets of data, terminating with a null octet. What is seen in files is just a transliteration of that, "abc.example." is just a conventional way to represent the domain name above. Now, if times have changed and a broader audience thinks "abc
Re: [DNSOP] back to: Some distinctions and a request
On 7/2/15, 6:02, "DNSOP on behalf of Hugo Maxwell Connery"
wrote:
>Hi,
>
>I think that Andrew's effort to distinguish between a domain name and
>a DNS name is useful. It gives us some clear terminology to use to
>discuss domain names that wish to use a non-DNS name resolution
>method.
Until this message, I wasn't clear on Andrew's distinction - we have been
talking off-list for the past few days too.
To me a domain name is: a sequence of bits that, when rendered in hex
notation, can look like this:
0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00
That is what is sent over the wire, through ports and is deposited in
memory of name servers. Note the lack of dots. And this is why I can't
see a difference between domain names and DNS names. To me, they are one
in the same.
This dates back to a discussion had while the labs I was in was developing
DNSSEC code. Our boss (Russ Mundy) made the statement that there are two
versions of a domain name, on-the-wire and in-the-file and it was the
on-the-wire format that mattered. Later in my career I worked with a firm
that developed it's own DNS code based on some legacy stuff from it's
start-up days. The start-up operated on the in-the-file format,
converting to and from on-the-wire format constantly. This was not a good
approach.
So when I hear "domain name" I think of the format that includes an octet
with flags and a number and then that number of octets of data,
terminating with a null octet. What is seen in files is just a
transliteration of that, "abc.example." is just a conventional way to
represent the domain name above.
Now, if times have changed and a broader audience thinks "abc.example." is
a domain name, there's a need to document that. In an old RFC there are
rules for representing a domain name in a file, rules that are
inconsistently understood and applied. Maybe it's not times, it's
perspectives. I'm coming up through the DNS, I didn't come across the DNS
from application space.
What I mean by rules inconsistently applied is a case of apparently
mis-aligned RFCs on ENUM. In one RFC, domain names were presented as
conversions to ASCII and the other following the rules of the old RFC for
escaping characters. Specifically, a back-slash was the issue, in one RFC
it was bare, in the the other escaped, and this difference caused
implementers of ENUM code headaches.
(I should look this up. I lost the notes on that incident, but probably
can try to dig up the references.)
I'll ask this, are these (thought to be) domain names:
\097\098\099.example. { 97 is the decimal equivalent of 'a' in RFC 20's
ascii table }
\a\b\c.example.
example.中国. {latter two characters are Chinese, meaning the country of
China}
现在我跟老婆住华盛顿可是以后我飞到IETF.练习 { a sequence of Chinese
charaters, IDNA2008 code
says label too long }
The latter is a placeholder for names that would be "too long" for the DNS
but otherwise look like, in a file, a domain name. This is said to be
true in Tor's use.
I am not asking to be facetious. I have had to deal with these questions
over the years. The latter I have code to test because I'd been asked to
look at official names of geographic regions and whether what would
'appear' to be a domain name from that could possibly be carried across
port 53.
If there is a distinction to be made between domain names and DNS names,
the former needs to be defined first. What are the rules in an http:// or
ftp:// URL? Colloquially I think the first name is a 'domain name' but I
have never been able to trace that down. I doubt that the 'domain name'
there is ever processed in on-the-wire format (as I started with) until
the DNS stub resolver accepts the request and spits out something to a
recursive server at port 53 somewhere.
(This omits the other under-worldly distinction of what names are eligible
for registration, etc., which is a distinction I've had to deal with. In
a world where one can write in any script with any kind of pen or pencil,
you have to know where do, um, draw, the line. IDNA2008? Punycode?
Different rules for different systems? And, is the "domain" of the
problem all code, all protocols, or what's in common use on the global
public Interent?)
smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
Hi, I think that Andrew's effort to distinguish between a domain name and a DNS name is useful. It gives us some clear terminology to use to discuss domain names that wish to use a non-DNS name resolution method. RFC6761 introduces a mechanism for the handling of these types of cases. In the recent cases of .onion, .gnu, .zkey etc. we have software using domain names but wishing to use a non-DNS name resolution mechanism. This is a "hand in glove" use of RFC6761. For persons wishing not to allow the use of RFC6761 for these names, it would seem that you have two options: 1. Invalidate RFC6761 indicating it was a mistake. This is not a disaster, mistakes are made and sometimes need to be rectified. 2. Form a different community for the assessment of these issues, and decide not to participate in that process. Thus, "you" are not allowing the use. Option 2 may not be such a silly idea. Some members of the community made it clear that they do not wish for DNSOP to be a clearing house for RFC6761. I assume that .gnu, .zkey, .bit communities would have the patience to wait for the formation of an alternative processing mechanism, but there is time pressure on .onion due to the upcoming work with certificates. Thus, it would seem that a decision is required from this community for the .onion case. Needless to say, I support all of these cases where software is using the domain name syntax but using a non-DNS name resolution mechanism. I provide that support because they are addressing the issue of privacy which the greater IETF community embraced with RFC7258. The DPRIVE WG are working on privacy enhancements *within* the DNS system. It is a difficult problem, though many useful contributions are emerging. The above non-DNS using softwares approach the same issue in a different manner: dont use DNS at all. The advantage of this approach is that all of the challenges that DPRIVE are wrestling with are not encountered at all. The only requirement is the registration via RFC6761. Hugo Connery -- 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman. From: DNSOP [dnsop-boun...@ietf.org] on behalf of Andrew Sullivan [a...@anvilwalrusden.com] Sent: Thursday, 2 July 2015 03:42 To: dnsop@ietf.org Subject: Re: [DNSOP] More after onion? was Re: Some distinctions and a request Hi Ed, On Wed, Jul 01, 2015 at 12:26:43PM +, Edward Lewis wrote: > I'm sympathetic to the use the path of least resistance - e.g., use names > that syntactically are DNS names I note that the Subject: line of your note still contains a vestigial reference to the thread I started recently on this, and your message nevertheless returns to collapsing "domain names" and "DNS names". I don't know whether I've simply failed to explain the distinction I'm trying to make, or whether you reject the premise. Could you please be clear about which it is? To me, the _point_ of onion. is that it is not a DNS name. You're right that it has the same syntax -- because it is a domain name, but not (intended to be) a DNS name. The registration of the name in the special use registry would achieve that end. You might object that this distinction is extremely hard, because there's nothing about the label itself to signal this namespace shift, and unaware clients will therefore automatically just treat such names as DNS names, not special-use domain names. I happen to agree with that, but we cannot hold back this tide: it was let loose once local. became an in-band protocol switch, without any registration, in Apple's widely-deployed Bonjour service. We might wish that people hadn't abused the namespace to turn it into protocol switches as well as everything else, but the history of SRV through Bonjour shows that this technique is popular and unlikely to go away. Commanding the tide to stay back when you are neck deep in water is not likely to work. Therefore, I claim, we need to make some clear distinctions and understand what has actually happened, and then adjust to the new reality. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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
