Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote: > What I envision for the future is an insecure delegation of .alt, and an > option in future cable modems to enable a local "homenet.alt" domain, which > would just work, even if some stub resolvers in the house are validating. > The

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote: > So, while technically the instruction (SHOULD NOT) applies to full .onion > names, > it is a SHOULD NOT, not a MUST NOT. Note also that the original request was that it be a MUST NOT, and some of us tried to explain that RFCs do

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Fri, Feb 10, 2017 at 12:57:25PM +1100, Mark Andrews wrote a message of 29 lines which said: > Even with everything working properly QNAME minimisation DOES NOT > STOP THE QUERIES. > > RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC > 4035) RFC

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Thu, Feb 09, 2017 at 04:40:23PM -0800, Brian Dickson wrote a message of 78 lines which said: > If you really care about privacy, IMHO, the place to instantiate the > private namespace, is under one of the heavily used AS112 zones. [...] > even if a leak >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Fri, Feb 10, 2017 at 11:48:01AM +1100, Mark Andrews wrote a message of 36 lines which said: > No, it will ask for foo.alt because: This is false (and Ted Lemon was correct in describing QNAME minimisation). Here, with a recent Unbound, when I ping foo.alt, I see only:

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Fri, Feb 10, 2017 at 09:48:51AM +1100, Mark Andrews wrote a message of 43 lines which said: > and has agressive negative caching (so the answer from the minimised > QNAME query get turned into a answer for *.alt). As I already said here, if by "agressive negative caching",

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Fri, Feb 10, 2017 at 06:57:22AM +1100, Mark Andrews wrote a message of 40 lines which said: > Only if you are willing to break lookups for names where there are > missing delegations in parent zone and the parent and child zones > share the same nameservers or the nameserver

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Could your concern be addressed with secure denial of existence plus the right text about how to configure recursive resolvers? On Feb 10, 2017 1:02 AM, "Mark Andrews" wrote: > > In message , Ted Lemon > writes > : > > > > On Feb

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Ted Lemon writes : > > On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote: > > I'm developing software that will be run on private internets with > > various degrees of compentence from the adminitrators as well as > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote: > I'm developing software that will be run on private internets with > various degrees of compentence from the adminitrators as well as > the public Internet. That private internet may have a ENT for ALT > that returns NXDOMAIN. The

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <20170210015725.bf777636c...@rock.dv.isc.org>, Mark Andrews writes: > > In message <653a3403-dfc8-491a-b083-7873d1886...@fugue.com>, Ted Lemon writes: > > > > On Feb 9, 2017, at 7:48 PM, Mark Andrews wrote: > > > 1) there is too much brokeness out there that returns

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Brian Dickson writes: > > On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews wrote: > > > > > In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon > > writes: > > > > > > On Feb 9,

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Ted Lemon writes: > How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver > is doing qname minimization? Because QNAME minimization does not stop on NXDOMAIN. Too much broken stuff out there

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews wrote: > > In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon > writes: > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > > At the moment we have Ted saying that if you want privacy you MUST

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon writes: > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > At the moment we have Ted saying that if you want privacy you MUST > > also turn on DNSSEC validation and implement QNAME minimisation and > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > At the moment we have Ted saying that if you want privacy you MUST > also turn on DNSSEC validation and implement QNAME minimisation and > implement agressive negative caching (still a I-D). No, I am _not_ saying that. I am

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Maybe DNS authority server software could auto-generate TXT records for what would otherwise be ENTs, or zone administrators could add them manually, E.g. ent.example.com TXT "This object intentionally left blank." This avoids the ENT issue. I can't think of any way that would break anything.

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <20170209163123.56hdbzaluekmv...@nic.fr>, Stephane Bortzmeyer writes : > On Wed, Feb 08, 2017 at 12:36:23PM -0800, > Brian Dickson wrote > a message of 258 lines which said: > > > - upon startup, do a query for "onion" (the non-existent TLD), with

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote a message of 258 lines which said: > - upon startup, do a query for "onion" (the non-existent TLD), with DO=1. > - cache the response, and as appropriate, re-query periodically. > - If a query for

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Thu, Feb 09, 2017 at 09:41:31AM +1100, Mark Andrews wrote a message of 38 lines which said: > And only because people are too scared to ask for changes to the > root zone to add a delegation. Being afraid to ask ICANN to do something is not cowardice, it is common sense :-)

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews wrote: > > In message , Ted Lemon writes: > > > > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > > > And if the service has the same privacy issues as .onion has? > > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews wrote: > > In message , Ted Lemon > writes: > > > > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > > > And if the service has the same privacy issues as .onion has? > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Ted Lemon writes: > > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > > And if the service has the same privacy issues as .onion has? > > > > So we leak names until every recursive server in the world is > > validating

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > And if the service has the same privacy issues as .onion has? > > So we leak names until every recursive server in the world is > validating (what % is that today?) and supports agressive negative > caching (still a I-D). I feel

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews wrote: > > In message , Ted Lemon > writes: > > > > On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote: > > > Which assumes agggressive negative caching. I'm going to make a

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <00767076-fa43-42c0-a4af-39f4e1087...@fugue.com>, Ted Lemon writes: > charset=us-ascii > > On Feb 8, 2017, at 2:42 PM, Mark Andrews wrote: > > 4. Caching DNS servers SHOULD recognize these names as special and > > SHOULD NOT, by default, attempt to look

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 8, 2017, at 2:42 PM, Mark Andrews wrote: > 4. Caching DNS servers SHOULD recognize these names as special and > SHOULD NOT, by default, attempt to look up NS records for them, > or otherwise query authoritative DNS servers in an attempt to > resolve

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Ted Lemon writes: > > On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote: > > Which assumes agggressive negative caching. I'm going to make a > > realistic assumption that it will take 10+ years for there to be > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 08, 2017 at 09:53:07AM -0500, Ted Lemon wrote a message of 37 lines which said: > > Why are they different, by the way? > > There is more than one way to handle a special-use name. Yes, but "serve it locally" is just one way, and it has its own registry, which

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote: > Which assumes agggressive negative caching. I'm going to make a > realistic assumption that it will take 10+ years for there to be > meaningful (>50%) deployment of aggressive negative caching. First of all, this probably isn't

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 8, 2017, at 3:43 AM, Stephane Bortzmeyer wrote: > Why are they different, by the way? There is more than one way to handle a special-use name. That's why we're debating which way to handle .alt, after all! :) ___ DNSOP

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 08, 2017 at 11:26:28AM +, Tony Finch wrote a message of 23 lines which said: > For RFC 8020 to suppress these .alt leaked queries properly, you > also need qname minimization. Yes, but anyone uses RFC 7816, anyway :-)

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Stephane Bortzmeyer wrote: > Mark Andrews wrote: > > Ted Lemon wrote: > > > > > > If it has proof of non-existence for .alt cached, it doesn't need > > > to ask any further questions to deny the existence of any > > > subdomain of .alt. > > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Mon, Feb 06, 2017 at 04:55:19PM +, Tony Finch wrote a message of 36 lines which said: > > Yes, that's right, with the caveat that all existing locally > > served zones are in the reverse space - there's no forward zones > > registered (yet). > > There are several :-)

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Mon, Feb 06, 2017 at 06:12:31PM +, Ray Bellis wrote a message of 28 lines which said: > The "locally served zones" and "special use domains" registries are > different. Why are they different, by the way? I really do not understand that. The "locally served zones"

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 08, 2017 at 05:02:08PM +1100, Mark Andrews wrote a message of 30 lines which said: > > If it has proof of non-existence for .alt cached, it doesn't need > > to ask any further questions to deny the existence of any > > subdomain of .alt. > > Which assumes

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Ted Lemon writes: > > On Feb 8, 2017, at 12:25 AM, Mark Andrews wrote: > > And how does the server get the proof of non-existence? It needs > > to leak a query. > > If it has proof of non-existence for .alt cached, it

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 8, 2017, at 12:25 AM, Mark Andrews wrote: > And how does the server get the proof of non-existence? It needs > to leak a query. If it has proof of non-existence for .alt cached, it doesn't need to ask any further questions to deny the existence of any subdomain of .alt.

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Ted Lemon writes: > > On Feb 7, 2017, at 4:48 PM, Mark Andrews wrote: > > Go add a empty zone (SOA and NS records only) for alt to your > > recursive server. This is what needs to be done to prevent > > privacy leaks. >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 7, 2017, at 4:48 PM, Mark Andrews wrote: > Go add a empty zone (SOA and NS records only) for alt to your > recursive server. This is what needs to be done to prevent > privacy leaks. No, the recursive server can just cache the proof of nonexistence. I didn't query the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews wrote: > > In message

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Brian Dickson writes: > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > > > > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon > > writes: > > > Hm. When I look for

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon > writes: > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > When I validate, I get a secure denial of existence. This is the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon > writes: > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > When I validate, I get a secure denial of existence. This is the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon writes: > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > When I validate, I get a secure denial of existence. This is the > correct behavior. Why do you think we would get a SERVFAIL? Because your

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. When I validate, I get a secure denial of existence. This is the correct behavior. Why do you think we would get a SERVFAIL? ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <5ca637ee-c0b6-4e5c-a446-a84431176...@fugue.com>, Ted Lemon writes: > > On Feb 7, 2017, at 11:45 AM, Warren Kumari wrote: > > I don't think I've seen a good argument for NOT doing the above -- why > > (other thabn the sunk time / effort) don't we do two? > > Right,

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 7, 2017, at 1:49 PM, John Levine wrote: > I really doubt that if we bless both .alt and .lcl (or whatever) that > the people building stuff will use the one we want them to use. Then it won't work for them. But fashionable though this sort of cynicism is, clear

Re: [DNSOP] ALT-TLD and (insecure) delgations.

>I don't think I've seen a good argument for NOT doing the above -- why >(other thabn the sunk time / effort) don't we do two? I checked with the protocol police who told me that even with their tasers set to maximum, they can't force people to use the right one. I really doubt that if we bless

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 7, 2017, at 11:45 AM, Warren Kumari wrote: > I don't think I've seen a good argument for NOT doing the above -- why > (other thabn the sunk time / effort) don't we do two? Right, this just seems obvious to me. If we do two, we can tailor each solution to the need it

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Yay! Centithread! On Tue, Feb 7, 2017 at 8:06 AM, Ted Lemon wrote: > On Feb 7, 2017, at 12:50 AM, Brian Dickson > wrote: > > I don't think the use cases for most of the sandbox involving alt, and/or > the homenet use case, requires support for

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson < brian.peter.dick...@gmail.com> wrote: > TL;DR: it is possible to have a signed DNAME in the root for alt (to > empty.as112.arpa), AND have a local signed alt. Things under this local alt > can be signed or unsigned. > > On Fri, Feb 3, 2017 at 1:09

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 7, 2017, at 12:50 AM, Brian Dickson wrote: > I don't think the use cases for most of the sandbox involving alt, and/or the > homenet use case, requires support for validating stubs. If .alt is being used for non-DNS names, you are correct, because non-DNS

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Brian Dickson wrote: > > Does the existence of query rewriting matter, as long as the end result > RDATA is the expected value? > I.e. If the query is "my-thing.foo.alt", returns a combo of "alt DNAME > empty.as112.arpa" plus "my-thing.foo.empty.as112.arpa ", > is

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews wrote: > > In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian > Dickson writes: > > The suggestion of DNAME to empty.as112.arpa involves some subtle details, > > which IMHO may in combination be the right mix here. > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian Dickson writes: > The suggestion of DNAME to empty.as112.arpa involves some subtle details, > which IMHO may in combination be the right mix here. > > The DNAME target is an insecure empty zone. > > This avoids the validation

Re: [DNSOP] ALT-TLD and (insecure) delgations.

The suggestion of DNAME to empty.as112.arpa involves some subtle details, which IMHO may in combination be the right mix here. The DNAME target is an insecure empty zone. This avoids the validation issue, and facilitates use of local "alt" namespaces. The default response to queries under alt

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <3581be55-b178-4298-8ee8-73fd16b42...@gmail.com>, Brian Dickson writes: > Mark, > > I don't think the use cases for most of the sandbox involving alt, and/or > the homenet use case, requires support for validating stubs. If stubs > aren't already validating, the incremental addition

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Mark, I don't think the use cases for most of the sandbox involving alt, and/or the homenet use case, requires support for validating stubs. If stubs aren't already validating, the incremental addition of a local alt, only requires distribution of the trust anchor to the resolvers. That is a

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message , Brian Dickson writes: > > TL;DR: it is possible to have a signed DNAME in the root for alt (to > empty.as112.arpa), AND have a local signed alt. Things under this local alt > can be signed or unsigned. So now

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On 06/02/2017 16:55, Tony Finch wrote: > > Ray Bellis wrote: > >> > >> Yes, that's right, with the caveat that all existing locally served > >> zones are in the reverse space - there's no forward zones registered (yet). > > > > There are several :-) RFC 6761 specifies

Re: [DNSOP] ALT-TLD and (insecure) delgations.

TL;DR: it is possible to have a signed DNAME in the root for alt (to empty.as112.arpa), AND have a local signed alt. Things under this local alt can be signed or unsigned. On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews wrote: > > In message

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <203e2636-1391-4100-9b1a-4f2dcc9a3...@gmail.com>, Ralph Droms writes: > > > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 16:55, Tony Finch wrote: > Ray Bellis wrote: >> >> Yes, that's right, with the caveat that all existing locally served >> zones are in the reverse space - there's no forward zones registered (yet). > > There are several :-) RFC 6761 specifies localhost,

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In article you write: >> Yes, that's right, with the caveat that all existing locally served >> zones are in the reverse space - there's no forward zones registered (yet). > >Could you clarify why that�s relevant? Perhaps because the management

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Ray Bellis wrote: > > Yes, that's right, with the caveat that all existing locally served > zones are in the reverse space - there's no forward zones registered (yet). There are several :-) RFC 6761 specifies localhost, invalid, test as locally served zones. RFC 6762 specifies

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 16:18, Suzanne Woolf wrote: >> Yes, that's right, with the caveat that all existing locally >> served zones are in the reverse space - there's no forward zones >> registered (yet). > > Could you clarify why that’s relevant? > > Does it just come down to the assumption that

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Feb 6, 2017, at 11:15 AM, Ray Bellis wrote: > >> For now, let’s keep it relevant to the decision this WG has to make, >> about what to do with .alt and whether it’s important to us to >> accommodate cases like .homenet. So far, it seems that the .homenet case >> is much

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Hi, Before this goes any further, I’m not sure an incomplete rehashing of the consensus in another WG is a good use of our time. For now, let’s keep it relevant to the decision this WG has to make, about what to do with .alt and whether it’s important to us to accommodate cases like .homenet.

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 16:12, Suzanne Woolf wrote: > Hi, > > Before this goes any further, I’m not sure an incomplete rehashing of > the consensus in another WG is a good use of our time. +1 :) > For now, let’s keep it relevant to the decision this WG has to make, > about what to do with .alt and

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 6, 2017, at 10:57 AM, Ólafur Gudmundsson wrote: > A WG can come to a consensus on a topic without all information available. > Now go back and see if reality changes consensus. I presented a detailed explanation of the tradeoffs, which the working group considered. If

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson wrote: > What RFC are you referring to? I wasn't referring to an RFC—I was referring to the homenet naming architecture document that we've been working on. > Why do you think .ARPA is for services? > It's for infrastructure and

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Ralph, A WG can come to a consensus on a topic without all information available. Now go back and see if reality changes consensus. Just my .02 cents. Ólafur On February 6, 2017 9:52:53 AM CST, Ralph Droms wrote: > > >> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 15:29, Ólafur Gudmundsson wrote: > Ted, > > What RFC are you referring to? > > Why do you think .ARPA is for services? > It's for infrastructure and homenet wants to join the infrastructure. > > It is waste of time arguing if name A or B is better take the one you > can get

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson wrote: > > Ted, > > What RFC are you referring to? > > Why do you think .ARPA is for services? > It's for infrastructure and homenet wants to join the infrastructure. > > It is waste of time arguing if name A or B is better

Re: [DNSOP] ALT-TLD and (insecure) delgations.

The working group has consensus to give it a try. We may change our minds of it takes too long, but it seems worth exploring from a process perspective anyway. On Feb 5, 2017 11:18 PM, "John R Levine" wrote: > I'm pretty sure I've explained it enough times on this mailing list

Re: [DNSOP] ALT-TLD and (insecure) delgations.

I'm pretty sure I've explained it enough times on this mailing list and in the relevant documents by now. If you don't agree, maybe we should just accept that. If you don't remember the explanation, it's in the homenet naming architecture doc I wrote. Well, OK, I took another look, and from

Re: [DNSOP] ALT-TLD and (insecure) delgations.

I'm pretty sure I've explained it enough times on this mailing list and in the relevant documents by now. If you don't agree, maybe we should just accept that. If you don't remember the explanation, it's in the homenet naming architecture doc I wrote. On Feb 5, 2017 11:05 PM, "John Levine"

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In article <6391b5bb-19bd-4717-b9bb-ecd145f7b...@fugue.com> you write: >On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson wrote: >> What is wrong with homenet.arpa ? > >homenet.arpa sounds like a service out there on the arpanet somewhere, not >something local. Why would that be

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson wrote: > What is wrong with homenet.arpa ? homenet.arpa sounds like a service out there on the arpanet somewhere, not something local. ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote: > > > > On 04/02/2017 02:13, Andrew Sullivan wrote: >> Right, that's always been the problem with using this _for the DNS_. >> Homenet has no choice in that, because the whole point of the homenet >> name is precisely to

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Sun, Feb 05, 2017 at 12:26:08AM +1100, Mark Andrews wrote: > > Given there are no rules for this type of namespace Which "type of namespace" do you mean? I think there are three possible namespaces you're talking about: 1. Domain names. There are rules for these, though they're

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Sun, Feb 05, 2017 at 10:16:20AM -0500, Warren Kumari wrote: > [0] > Reservation of .internal as a Special Use > Name. ... > > This document reserves the string "internal" for use as an internal > DNS > > [ Ed note: Text inside square brackets ([]) is additional

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Fri, Feb 3, 2017 at 9:40 PM, Ted Lemon wrote: > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote: > > 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

DNAME was considered early in the IDN evaluations, so it's not exactly unknown in the Icann community On Fri, Feb 3, 2017 at 15:33 Steve Crocker wrote: > We (ICANN) have no mechanism or process for inserting a DNAME record into > the root. We do have a process for

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote: > > > > On 04/02/2017 02:13, Andrew Sullivan wrote: >> Right, that's always been the problem with using this _for the DNS_. >> Homenet has no choice in that, because the whole point of the homenet >> name is precisely to

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <9920bdf2-e676-4262-9226-46652896e...@fugue.com>, Ted Lemon writes: > > On Feb 4, 2017, at 8:29 AM, Mark Andrews wrote: > > > > It's a problem for ALL special names. BOGUS / SERVFAIL isn't the > > response leaked names should get. Its bad engineering. > > What is the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 4, 2017, at 8:29 AM, Mark Andrews wrote: > > It's a problem for ALL special names. BOGUS / SERVFAIL isn't the > response leaked names should get. Its bad engineering. What is the response leaked names should get, and why is that the correct response? Why is SERVFAIL

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote: > If it turns out that we can't get the insecure delegation that we need > for .homenet, then I'd (personally) be reasonably happy with > .homenet.alt, except that the current proposals for the use of .alt > wouldn't seem to permit

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Feb 3, 2017, at 9:40 PM, Ted Lemon wrote: > > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan > wrote: >> My memory is that only after that >> did we start thinking of a sort of 1918-style part of the DNS as >> well.

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <20170204021353.gf67...@mx2.yitter.info>, Andrew Sullivan writes: > On Fri, Feb 03, 2017 at 08:54:59PM -0500, Ted Lemon wrote: > > On Feb 3, 2017, at 8:51 PM, Andrew Sullivan wrote: > > > If the resolver "has a local zone for alt" -- I think this means it is >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

In message <20170204020711.gd67...@mx2.yitter.info>, Andrew Sullivan writes: > Hi, > > On Sat, Feb 04, 2017 at 09:47:08AM +1100, Mark Andrews wrote: > > > > Also the ICANN's rule for signed TLD delegation for new gTLD is so > > that delegations from those zones can be signed. > > I don't think

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 04/02/2017 02:13, Andrew Sullivan wrote: > Right, that's always been the problem with using this _for the DNS_. > Homenet has no choice in that, because the whole point of the homenet > name is precisely to enable in-homenet DNS without reference to the > global DNS. I think you're quite

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 4 Feb 2017, at 2:57, Andrew Sullivan wrote: > On Fri, Feb 03, 2017 at 12:21:16PM -0800, Steve Crocker wrote: > >> And just to stir the pot a bit, what would you have ICANN do if someone >> applies for .alt as a top level domain? Is it ok if we say yes and delegate >> the name? If not, what

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote: > 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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Fri, Feb 03, 2017 at 08:58:43PM -0500, George Michaelson wrote: > sorry to be thick, but.. can we have both on a case-by-case basis somehow? Well, if the stub that is going to query in this namespace _knows_ that it's special, then it also knows not to validate it too. So that's not a

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Fri, Feb 03, 2017 at 08:54:59PM -0500, Ted Lemon wrote: > On Feb 3, 2017, at 8:51 PM, Andrew Sullivan wrote: > > If the resolver "has a local zone for alt" -- I think this means it is > > authoritative for that zone -- why would it ask the root about it at > > all? >

  1   2   >