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

2017-02-07 Thread Mark Andrews
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.

2017-02-07 Thread Ted Lemon
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.

2017-02-07 Thread Mark Andrews
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.

2017-02-07 Thread Ted Lemon
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.

2017-02-07 Thread Mark Andrews
In message

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

2017-02-07 Thread Brian Dickson
On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews wrote: > > In message

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

2017-02-07 Thread Mark Andrews
In message

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

2017-02-07 Thread Mark Andrews
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.

2017-02-07 Thread Brian Dickson
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.

2017-02-07 Thread Brian Dickson
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.

2017-02-07 Thread Mark Andrews
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.

2017-02-07 Thread Ted Lemon
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.

2017-02-07 Thread Mark Andrews
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.

2017-02-07 Thread Ted Lemon
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.

2017-02-07 Thread John Levine
>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.

2017-02-07 Thread Ted Lemon
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.

2017-02-07 Thread Warren Kumari
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.

2017-02-07 Thread Bob Harold
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.

2017-02-07 Thread Ted Lemon
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.

2017-02-07 Thread Tony Finch
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