Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
I have a different perspective on this question Mark. Firstly, I find use of .magic as the extreme RHS of a name, to force special behaviour architecturally disqueting. I really do worry about what we think we're building when we encode this behaviour into name strings. It leads to all kinds of bad places. Some of them, like the homoglyph problems John Klensin has raised, simply don't have good answers (the assumption the string .onion is the literal ASCII 'o' 'n' 'i' 'o' 'n' is not well founded) We were here a long time ago, when we had pre-Internet mail and used things like .UUCP as magic break-out signals in email. This rapidly becomes the problem: its bound to applications-level decisions about when to honour magic, and when not, and it certainly doesn't avoid lower level gethostbyname() calls everywhere. So the .magic label winds up being half-true, depending. Secondly, While I think I now understand some of the problems you have in web/apps layer (from talking to Wendy Seltzer) and I have sympathies about the syntactic constructs welded into code around URL forms, I think these problems are different to the architectural/layer violation explicit in forcing .magic names into the namespace. What really got me floored, was the qualities of cryptographic protection which a project like TOR needs, and the implication a public/commercial CA service embedded in the browser TA set is the right path. I'm frankly horrified, even under certificate pinning, that we've gone to a space where any TA can claim to sign over .onion, and excluding the pinned applications, lead people into paths where their assumptions of TLS backed security are simply not true. As I understand things, TOR *wanted* .onion to get X509 PKI over the label in a browser, and the CA community refused unless its TLD status was confirmed. Is this the kind of rigour in technical process we expect, to make technical calls to pre-empt the namespace? (which btw, we passed otherwise to another body, reserving an RFC backed process to get names, but I think that was a hugely unwise decision) To protect .onion certs, the TOR developers are going to have to code in cert pinning behaviour, all kinds of things, which frankly sound to me a lot like the cost of not having the name, or having a name buried under a 2LD instead. So I come to a different place. I come to a place where requests for magic names look like violations of any spirit of an architectural view of the network, and where retaining some technical basis to reserve them looks like violations of the separation of functional roles between ICANN and IETF, absent very very clear, strong reasons to have the name held back. I don't entirely see these reasons emerging. I see the opposite. I see expediency from apps communities, seeking to use .magic tricks to avoid cost explicitly in their layer, but at a cost of polluting the public commons. I am pretty firmly in the camp which says the revision of the RFC should be complete: we stop doing this, and people who want names go into ICANN process to establish them. -G On Thu, Nov 26, 2015 at 9:59 PM, hellekin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 11/26/2015 06:38 AM, Mark Nottingham wrote: > > > > Given this context, I was disturbed to hear the design team presentati > on > > in Yokohama > > > > So you mean there's an already working team on the revision of RFC6761, > and that team had the time to prepare a presentation, while the DNSOP > chairs didn't have the time to respond to volunteers nor to announce > this team. This is simply unacceptable. I concur that the revision of > RFC6761 should go to another group where "Internet community" makes some > sense and corporate dissent is not silenced by ignoring legitimate > requests. Please don't expect any apologies from me for telling the > truth. This is a carnival of an inclusive process. > > Thank you Mark for the heads up. > > == > hk > > -BEGIN PGP SIGNATURE- > > iQJ8BAEBCgBmBQJWVvQ8XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 > ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9ewoQALD1dF/Wqyh2Lo5qZ35PUANA > bvq2k5BZd1UsN488+V4v7PnAHxO7XgR8IQSYYnp1oYNaZl5WbFEPjT6HOSR3O4lr > 7iSVeSxPux8hssSxorkWtBVk8oAnImGEPyIlYunBLcTyasXLY5+2fzmR1+P4/9Kk > ahjHvuQa6dOAXhqTMBizwb3kZ2PC2hFlM5LKMIBcf9GfTVmH//fbEalHYPYEwMCY > AvX9mkMvvWcWhn15OXRi50r3kQl65d0KQA2euQ8mUIe5qafDHASBtZLc81t0rAXv > fjaWT4REu+KUHexWKgI7NFF3uZ0M0Cm7imYN6+YG+AWFtPrr4SPh1BA0L4td93q8 > bGxGEJrDTWRVaW2c98UO5bFxm3kqcM4oTdBD1Rg4yC1OatvuKzZp6nPrFG09G5rn > PjorrqoNx0MHxwejrTHkkhnmvmgTfPUTvkT/7zUYLTwRITDrjzOyj932COrZV+A3 > dak5M5hRLhR8jswx/lh+SmY1RFAtCuNDcoFuXTOJygwSpj7WvigIORiT6ATLFlfW > mxYxkVP/Tc76anRTk5O/AIu87c5K9fr6TPiFRIL/0eKnFBEMn2qbaW7TLvAl6o89 > kgYYp4u59ve0vCL6gE2sn1w1EYnctFVxpzcg9HkFl/MFuQyWdc4yb5OdFWW8sema > 8hpTT/KiW1/KDHGj0kcB > =IZoh > -END PGP SIGNATURE- > > ___ > DNSOP mailing
Re: [DNSOP] I-D Action: draft-andrews-dns-no-response-issue-16.txt
Most of the tests now contain references to the relevent sections of the RFCs being tested. Seperated the tests that cover Basic DNS behaviour and Extended DNS behaviour into two sub sections. Yes, the references to RFC5395 needs to be updated to the latest RFC6195 before anyone tells me. -- 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] I-D Action: draft-andrews-dns-no-response-issue-16.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 Working Group of the IETF. Title : A Common Operational Problem in DNS Servers - Failure To Respond. Author : M. Andrews Filename: draft-andrews-dns-no-response-issue-16.txt Pages : 16 Date: 2015-11-26 Abstract: The DNS is a query / response protocol. Failure to respond or to respond correctly to queries causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common classes of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for TLD and other similar zone operators to apply to help reduce / eliminate the problem. The document does not look at the DNS data itself, just the structure of the responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-andrews-dns-no-response-issue-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-andrews-dns-no-response-issue-16 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
Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
On 26 Nov 2015, at 18:05, Joe Abley wrote:
> On 25 Nov 2015, at 0:40, Patrik Fältström wrote:
>
>> I have read this draft and have a number of comments. I can not say these
>> are the only ones, but at least some :-)
>>
>> The dominant protocol for name resolution on the Internet is the
>> Domain Name System (DNS). However, other protocols exist that are
>> fundamentally different from the DNS, but which have syntactically-
>> similar namespaces.
>>
>> I claim that if it is syntactically similar and the names are used
>> interchangeable in protocols (see below) we actually DO talk about use of
>> the same namespace. This is the camel in the tent, and I think we should
>> just admit, or say clearly whether we do talk about, which I think we do,
>> one name space with multiple resolution mechanisms.
>
> That's a possible direction. However, I don't know how far we will get with
> that approach, since every additional example of a name resolution protocol
> comes with an attendant list of exceptions, e.g.
>
> - LOCALHOST -- it's a single, dotless name, and there's no hierarchy
> - LOCAL -- child labels can contain spaces and UTF-8-encoded symbols,
> single-label depth
> - ONION -- a single, fixed-width second-level label (base32-encoded first 80
> bits of a SHA-1 hash) and anything at all under that (not relevant to the
> name resolution protocol, but perhaps useful to applications)
>
> I think the useful point to make is that the intersection of all these sets
> of possible names is non-empty -- that is, you can trivially find examples of
> names that are legitimate to more than one name resolution protocol, and
> hence a potential source of confusion to end-users and applications.
Hmm...I think I understand what you mean here. What I was after was that the
strings are replaceable in the various protocol definitions where "domain name"
is supposed to be. Then of course certain combination of octet values are not
possible depending on various rules. By the protocol where the string is in
use, and (as you point out) because of the different resolution mechanisms.
When thinking of what comes below, what do you say about EXAMPLE? What are the
rules for that? ;-)
>> It is not so much different protocols as different resolution mechanisms. If
>> you say "protocol" here, it might sounds like if with the DNS protocol you
>> can not use multiple different resolution mechanisms (which I think one can
>> -- one of them using the root managed by ICANN).
>
> Yes, I think it would be better to choose a distinct phrase for what we're
> talking about here and define it early. I've used "name resolution protocol"
> for this, but no doubt there are better alternatives.
Hmm...if I knew a good name, I would suggest it. I just stumbled myself over
the word "protocol".
>> What about EXAMPLE?
>
> I think (but have no citations handy to support my thinking) that EXAMPLE is
> a reserved top-level label in the DNS, not an example of what Alain called a
> protocol switch.
;-)
To some degree it is a protocol switch, right? It should never ever be used.
/dev/null comes to mind... :-)
>> Well...in the architecture we have both the URI scheme and if you look
>> further the URN definition to manage all different kind of switches. And we
>> do not have to wake up the old discussion again whether HTTP://EXAMPLE.COM/
>> in reality should be URI:HTTP://EXAMPLE.COM/
>
> I think we were imagining that if we could go back in time and insist that
> URIs such as
>
> http://blah-blah-base32-blah-blah!onion/index.html
>
> unambiguously referred to the onion name resolution protocol, then there
> would be little chance that these names would leak into other name resolution
> protocols' infrastructure (like the DNS) and that might provide the basis of
> some kind of solution to the problem of random (e.g.) e-mailed URLs causing
> leakage when encountered by end-users and robots that don't know about (say)
> onion names.
>
> Unfortunately, all attempts to confirm that time travel will be available to
> me in the future have failed, to date. So either returning to the past to
> change the URI specification would cause a world-ending rift in space-time,
> or time travel is fictional. Just quietly, I suspect it's the former.
...or of course ask whether all HTTP scheme URIs use DNS, which imply one
should place the switch regarding resolution in the URI scheme...
> So, given that it's too dangerous to cross the time streams to fix the URI
> format, let's go with the ugly but de-facto identifier we have, which is the
> top label. We don't have to like it, we just have to acknowledge begrudgingly
> that it exists. That's the intended message in the text.
Yes.
>> What about not-yet-allocated strings in this catalog?
>
> The problem space includes the problem of how a future name resolution
> protocol architect should register a selector ("switch") for her protocol,
> how that registration should be han
Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
Hi Patrik, On 25 Nov 2015, at 0:40, Patrik Fältström wrote: > I have read this draft and have a number of comments. I can not say these are > the only ones, but at least some :-) > > The dominant protocol for name resolution on the Internet is the > Domain Name System (DNS). However, other protocols exist that are > fundamentally different from the DNS, but which have syntactically- > similar namespaces. > > I claim that if it is syntactically similar and the names are used > interchangeable in protocols (see below) we actually DO talk about use of the > same namespace. This is the camel in the tent, and I think we should just > admit, or say clearly whether we do talk about, which I think we do, one name > space with multiple resolution mechanisms. That's a possible direction. However, I don't know how far we will get with that approach, since every additional example of a name resolution protocol comes with an attendant list of exceptions, e.g. - LOCALHOST -- it's a single, dotless name, and there's no hierarchy - LOCAL -- child labels can contain spaces and UTF-8-encoded symbols, single-label depth - ONION -- a single, fixed-width second-level label (base32-encoded first 80 bits of a SHA-1 hash) and anything at all under that (not relevant to the name resolution protocol, but perhaps useful to applications) I think the useful point to make is that the intersection of all these sets of possible names is non-empty -- that is, you can trivially find examples of names that are legitimate to more than one name resolution protocol, and hence a potential source of confusion to end-users and applications. > When an end-user triggers resolution of a name on a system which > supports multiple, different protocols for name resolution, it is > desirable that the protocol to be used is unambiguous, and that > requests intended for one protocol are not inadvertently addressed > using another. > > It is not so much different protocols as different resolution mechanisms. If > you say "protocol" here, it might sounds like if with the DNS protocol you > can not use multiple different resolution mechanisms (which I think one can > -- one of them using the root managed by ICANN). Yes, I think it would be better to choose a distinct phrase for what we're talking about here and define it early. I've used "name resolution protocol" for this, but no doubt there are better alternatives. > Such usage, which a few commenters have referred to as "protocol > switching," is not limited to "protocol switch" in the strict sense > of indicating specific protocols on the wire. It could indicate to > switch to another name space (eg .onion), use a different protocol > (eg tor, or mdns), or indicate to use a local DNS scope by not using > the DNS root for name resolution (eg .home in homenet) or something > else altogether. > > It is important (which I think also Stephane indicated) that we talk about > different resolution mechanisms for the name itself. We do not talk about how > to access the service in question. I agree. > At the time of writing, three top-level domain names reserved by > inclusion in the Registry are used by name resolution protocols other > than the DNS: > >LOCALHOST is used to refer to the host on which the name >resolution takes place, without reference to the DNS; > >LOCAL is used by the Multicast DNS protocol specified in [RFC6762] >which is similar in some respects to the DNS, but which uses >different well-known port number and is limited to a particular >multicast scope; > >ONION is used to construct names that designate anonymous hidden >services reachable via the Tor network using onion routing. > > I think a better text to describe ONION would be: > >ONION is used to construct names that designate >services reachable via the Tor network using onion routing. > > What about EXAMPLE? I think (but have no citations handy to support my thinking) that EXAMPLE is a reserved top-level label in the DNS, not an example of what Alain called a protocol switch. > The lack of a more elegant way to specify a > name resolution protocol in (for example) a URI amounts to an > architectural oversight. > > Well...in the architecture we have both the URI scheme and if you look > further the URN definition to manage all different kind of switches. And we > do not have to wake up the old discussion again whether HTTP://EXAMPLE.COM/ > in reality should be URI:HTTP://EXAMPLE.COM/ I think we were imagining that if we could go back in time and insist that URIs such as http://blah-blah-base32-blah-blah!onion/index.html unambiguously referred to the onion name resolution protocol, then there would be little chance that these names would leak into other name resolution protocols' infrastructure (like the DNS) and that might provide the basis of some kind of solution to the problem of random (e.g.) e-mailed URLs causing leakage when encountered b
Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/26/2015 06:38 AM, Mark Nottingham wrote: > > Given this context, I was disturbed to hear the design team presentati on > in Yokohama > So you mean there's an already working team on the revision of RFC6761, and that team had the time to prepare a presentation, while the DNSOP chairs didn't have the time to respond to volunteers nor to announce this team. This is simply unacceptable. I concur that the revision of RFC6761 should go to another group where "Internet community" makes some sense and corporate dissent is not silenced by ignoring legitimate requests. Please don't expect any apologies from me for telling the truth. This is a carnival of an inclusive process. Thank you Mark for the heads up. == hk -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJWVvQ8XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9ewoQALD1dF/Wqyh2Lo5qZ35PUANA bvq2k5BZd1UsN488+V4v7PnAHxO7XgR8IQSYYnp1oYNaZl5WbFEPjT6HOSR3O4lr 7iSVeSxPux8hssSxorkWtBVk8oAnImGEPyIlYunBLcTyasXLY5+2fzmR1+P4/9Kk ahjHvuQa6dOAXhqTMBizwb3kZ2PC2hFlM5LKMIBcf9GfTVmH//fbEalHYPYEwMCY AvX9mkMvvWcWhn15OXRi50r3kQl65d0KQA2euQ8mUIe5qafDHASBtZLc81t0rAXv fjaWT4REu+KUHexWKgI7NFF3uZ0M0Cm7imYN6+YG+AWFtPrr4SPh1BA0L4td93q8 bGxGEJrDTWRVaW2c98UO5bFxm3kqcM4oTdBD1Rg4yC1OatvuKzZp6nPrFG09G5rn PjorrqoNx0MHxwejrTHkkhnmvmgTfPUTvkT/7zUYLTwRITDrjzOyj932COrZV+A3 dak5M5hRLhR8jswx/lh+SmY1RFAtCuNDcoFuXTOJygwSpj7WvigIORiT6ATLFlfW mxYxkVP/Tc76anRTk5O/AIu87c5K9fr6TPiFRIL/0eKnFBEMn2qbaW7TLvAl6o89 kgYYp4u59ve0vCL6gE2sn1w1EYnctFVxpzcg9HkFl/MFuQyWdc4yb5OdFWW8sema 8hpTT/KiW1/KDHGj0kcB =IZoh -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
