In message <203e2636-1391-4100-9b1a-4f2dcc9a3...@gmail.com>, Ralph Droms writes: > > > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > > > > On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote: > >> Mark, I don't think you've actually given an answer to my question. > >> I understood that .ALT was for alternative naming systems, not for > >> DNS locally-served zones. We simply need to decide whether or not > >> that's true. I think either answer is fine; we just need to pick > >> one. > > > > I agree with this. I will say that, when I first started working on > > this with Warren, it was really for the use-case where people would > > tread on the namespace as a protocol switch -- we wanted a sandbox in > > which things like onion could live. My memory is that only after that > > did we start thinking of a sort of 1918-style part of the DNS as > > well. That may have been a mistake, since as this discussion is > > showing the properties of an in-protocol, in-DNS namespace without > > delegations are somewhat different to alternative-protocol uses that > > do not rely on the DNS at all. > > Andrew - I have come around to agree that the properties and requirements > of non-DNS resolution mechanisms are different from those of DNS re > solution that does not use the root zone as a resolution context. I believe > that these properties and requirements cannot be served by the single .alt > delegation, so, in my opinion, draft-ietf-dnsop-alt-tld should specify .alt > for use of non-DNS resolution mechanisms. > > How to proceed with DNS resolution that does not use the root zone as a > resolution context is open for discussion. > > - Ralph
Whether a DNS transport is use or not for the names. Any scheme where names in use needs to have a insecure delegation if we expect recursive server to answer for that namespace even if it is just to stop query / name leaks. That is basic DNSSEC. .ONION needs this treatment. If the ISP's recursive server is answering for leaked .ONION names and the ISP's clients validating recursive server is forwarding to the ISP's server (this is a common configuration for some Linux distributions) then there will be reties to all the ISP's servers. No set of systems, when configured as specified by RFC, should ever result in SERVFAIL being returned. That is just poor engineering. That will have the punters chasing configuration bugs that don't exist. Mark > > 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 -- 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
