Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

[Shane Kerr]

Warren,

I am still wondering about the:

   3 * (DNSKEY RRSIG Signature Validity) / 2

Term in the draft, which I see survived the update.

Why is this not just the DNSKEY RRSIG Signature Validity? In principle
once the signature has expired it cannot be used to replay the old
DNSKEY RRset right?

Cheers,

--
Shane

At 2017-02-03 21:14:03 -0500
Warren Kumari  wrote:

> Hi all,
> 
> Was and I have updated this document to make it clearer and more
> readable. Please take a read and let us know if any parts are unclear,
> if you have any other feedback, etc.
> 
> Is this close to done?
> W
> 
> On Fri, Feb 3, 2017 at 6:29 PM,   wrote:
> >
> > A new version of I-D, draft-hardaker-rfc5011-security-considerations-02.txt
> > has been successfully submitted by Warren Kumari and posted to the
> > IETF repository.
> >
> > Name:   draft-hardaker-rfc5011-security-considerations
> > Revision:   02
> > Title:  Security Considerations for RFC5011 Publishers
> > Document date:  2017-02-02
> > Group:  Individual Submission
> > Pages:  8
> > URL:
> > https://www.ietf.org/internet-drafts/draft-hardaker-rfc5011-security-considerations-02.txt
> > Status: 
> > https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/
> > Htmlized:   
> > https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-02
> > Diff:   
> > https://www.ietf.org/rfcdiff?url2=draft-hardaker-rfc5011-security-considerations-02
> >
> > Abstract:
> >This document describes the math behind the minimum time-length that
> >a DNS zone publisher must wait before using a new DNSKEY to sign
> >records when supporting the RFC5011 rollover strategies.
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat
> >  
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 


pgpLxXIWM7UDC.pgp
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

[Bob Harold]

On Fri, Feb 3, 2017 at 9:14 PM, Warren Kumari  wrote:

> Hi all,
>
> Was and I have updated this document to make it clearer and more
> readable. Please take a read and let us know if any parts are unclear,
> if you have any other feedback, etc.
>
> Is this close to done?
> W
>
> On Fri, Feb 3, 2017 at 6:29 PM,   wrote:
> >
> > A new version of I-D, draft-hardaker-rfc5011-
> security-considerations-02.txt
> > has been successfully submitted by Warren Kumari and posted to the
> > IETF repository.
> >
> > Name:   draft-hardaker-rfc5011-security-considerations
> > Revision:   02
> > Title:  Security Considerations for RFC5011 Publishers
> > Document date:  2017-02-02
> > Group:  Individual Submission
> > Pages:  8
> > URL:https://www.ietf.org/internet-
> drafts/draft-hardaker-rfc5011-security-considerations-02.txt
> > Status: https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-
> security-considerations/
> > Htmlized:   https://tools.ietf.org/html/draft-hardaker-rfc5011-
> security-considerations-02
> > Diff:   https://www.ietf.org/rfcdiff?
> url2=draft-hardaker-rfc5011-security-considerations-02
> >
> > Abstract:
> >This document describes the math behind the minimum time-length that
> >a DNS zone publisher must wait before using a new DNSKEY to sign
> >records when supporting the RFC5011 rollover strategies.
> 


Thanks for your work on this.  Some minor formatting issues:

Table of contents:
sections 5 and 5.1 have large blank space in middle
(as formatted at
https://www.ietf.org/id/draft-hardaker-rfc5011-security-considerations-02.txt
)
section 8 is wrapped unnecessarily

Section 3:
large space in first line

Section 5:
"poising" -> "poisoning"

Section 5.1.1
"(a new)" -> "(anew)"

Section 6
47 - 35 = 12 days (not 11)?

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Gudmundsson]

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 
faster.

Ólafur


On February 5, 2017 10:22:35 PM CST, Ted Lemon  wrote:
>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
>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 what I can see, it's a belief
>that
>> people will find toaster.homenet.arpa harder or more confusing to
>type than
>> toaster.homenet.
>>
>> Just out of curiosity, how long is it worth waiting to get .homenet
>rather
>> than .homenet.arpa?  If it took five more years, which at the current
>rate
>> seems optimistic, would homenet still be relevant?
>>
>> R's,
>> John
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 6 Feb 2017, at 15:29, Ólafur Gudmundsson  wrote:
> 
> It is waste of time arguing if name A or B is better take the one you can get 
> faster.

+100

Says he wishing the arguments over A or B (for some definition of both) would 
just go away and never return.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ralph Droms]

> 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 take the one you can get 
> faster.

The WG has considered the alternatives, and WG consensus is to specify 
".homenet"

- Ralph

> 
> Ólafur
> 
> 
>> On February 5, 2017 10:22:35 PM CST, Ted Lemon  wrote:
>> 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 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 what I can see, it's a belief that 
>>> people will find toaster.homenet.arpa harder or more confusing to type than 
>>> toaster.homenet.
>>> 
>>> Just out of curiosity, how long is it worth waiting to get .homenet rather 
>>> than .homenet.arpa?  If it took five more years, which at the current rate 
>>> seems optimistic, would homenet still be relevant?
>>> 
>>> R's,
>>> John
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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] ALT-TLD and (insecure) delgations.

[Ray Bellis]

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 faster.

It really isn't.

If I type "arpa" into Google (without the leading dot) I don't get the
new "Address and Routing Parameter Area" definition.

I get a big side bar with the DARPA logo and mention of the US DoD
everywhere.

That might well be fine for us "in the know" techies, but as far as I'm
concerned it's not fine for the residential users that are the target
market for Homenet.

That's even more true now than it was before November.

Ray (no hat)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Gudmundsson]

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 
>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 faster.
>
>The WG has considered the alternatives, and WG consensus is to specify
>".homenet"
>
>- Ralph
>
>> 
>> Ólafur
>> 
>> 
>>> On February 5, 2017 10:22:35 PM CST, Ted Lemon 
>wrote:
>>> 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 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 what I can see, it's a
>belief that people will find toaster.homenet.arpa harder or more
>confusing to type than toaster.homenet.
 
 Just out of curiosity, how long is it worth waiting to get .homenet
>rather than .homenet.arpa?  If it took five more years, which at the
>current rate seems optimistic, would homenet still be relevant?
 
 R's,
 John
>> 
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 homenet wants to join the infrastructure.

What made you think I though that.   What I mean is that it sounds like it's 
something global, not something local, because of the .arpa subdomain.

> It is waste of time arguing if name A or B is better take the one you can get 
> faster.

This is your opinion.   I don't recall hearing you express it when I asked the 
working group which option they preferred.   We have a substantial amount of 
time to waste; the working group decided to waste it.   I don't see a problem 
with that.   If we need to revisit this later, when it becomes a pressing 
issue, I think we have a pretty clear expedient solution, as you say, so there 
is no harm in trying for the solution that we want, and that we thing produces 
the better result for end users.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 you think something has changed, you should first review the 
discussion, since it sounds like you never read that detailed explanation.  In 
that explanation, I made the precise point you are making: that homenet.arpa 
would be more expedient than .homenet.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

[Petr Špaček]

On 02/06/2017 01:11 PM, Shane Kerr wrote:
> Warren,
> 
> I am still wondering about the:
> 
>3 * (DNSKEY RRSIG Signature Validity) / 2
> 
> Term in the draft, which I see survived the update.
> 
> Why is this not just the DNSKEY RRSIG Signature Validity? In principle
> once the signature has expired it cannot be used to replay the old
> DNSKEY RRset right?

Shane was faster than me, I'm also wondering how 3/2 got here.

I expect that 3/2 = 2/2 to avoid replay attack + 1/2 from RFC 5011.

In any case, it would be awesome if each component in section 6 had own
explanation what role the particular component plays in the equation.

-- 
Petr Špaček  @  CZ.NIC

> 
> Cheers,
> 
> --
> Shane
> 
> At 2017-02-03 21:14:03 -0500
> Warren Kumari  wrote:
> 
>> Hi all,
>>
>> Was and I have updated this document to make it clearer and more
>> readable. Please take a read and let us know if any parts are unclear,
>> if you have any other feedback, etc.
>>
>> Is this close to done?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

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 whether it’s important to us to
> accommodate cases like .homenet. So far, it seems that the .homenet case
> is much like “locally-served zones”.

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).

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Suzanne Woolf]

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. So far, it seems that the .homenet case is much like “locally-served 
zones”.


thanks,
Suzanne

> On Feb 6, 2017, at 10:57 AM, Ólafur Gudmundsson  wrote:
> 
> 
> 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  > 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 faster.
> 
> The WG has considered the alternatives, and WG consensus is to specify 
> ".homenet"
> 
> - Ralph
> 
>> 
>> Ólafur
>> 
>> 
>> On February 5, 2017 10:22:35 PM CST, Ted Lemon > > wrote:
>> 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 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 what I can see, it's a belief that 
>> people will find toaster.homenet.arpa harder or more confusing to type than 
>> toaster.homenet.
>> 
>> Just out of curiosity, how long is it worth waiting to get .homenet rather 
>> than .homenet.arpa?  If it took five more years, which at the current rate 
>> seems optimistic, would homenet still be relevant?
>> 
>> R's,
>> John
>> 
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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] ALT-TLD and (insecure) delgations.

[Suzanne Woolf]

> 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 like “locally-served zones”.
> 
> 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 reverse zones are not supposed to 
have human-visible/human-friendly names? Or is there some other characteristic 
of how those names are used that’s important here?


thanks,
Suzanne

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

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 reverse zones are not
> supposed to have human-visible/human-friendly names? Or is there some
> other characteristic of how those names are used that’s important
> here?

In the back of my mind I was recalling some conversations I've heard
that perhaps some other "reserved" forward names should be treated like
locally served zones (e.g. ".invalid") but currently aren't.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] correction Re: virtual interim DNSOP WG meeting and current status, special use names

[Paul Hoffman]

On 2 Feb 2017, at 13:48, Suzanne Woolf wrote:

>> (Webex details will follow)

This Webex will be recorded for those of us who cannot attend, yes?

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 local. RFC 7686 specifies onion.

RFC 7534 says that the AS112 DNAME target zones should be locally served,
though they are not listed in the special use registry.

The example domains are special use but not locally served.

BIND currently has empty.as112.arpa as its only built-in locally-served
forward domain.

My servers have some awkwardness to sink .local mDNS queries without
making Avahi think there is a private non-multicast DNS .local domain.
This does not conform to the requirements of RFC 6762 but it is necessary
for interop :-/
zone local {
type master; file "/zm/null";
allow-query { !0.0.0.0/0; !::/0; };
};

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire, South Utsire, Forties, Cromarty: Southeasterly 7 to
severe gale 9, perhaps storm 10 later in Viking. Rough or very rough becoming
very rough or high. Rain or sleet. Moderate or good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

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 rules follow more or less mechanically
from the management rules for the corresponding IP space.

R's,
John

PS: I don't think that's hugely compelling.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

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, invalid, test as
> locally served zones. RFC 6762 specifies local. RFC 7686 specifies onion.
> 
> RFC 7534 says that the AS112 DNAME target zones should be locally served,
> though they are not listed in the special use registry.
> 
> The example domains are special use but not locally served.

The "locally served zones" and "special use domains" registries are
different.  There is potentially scope for overlap.

It's possible that some special use domains might benefit from special
treatment in the root zone, too (".localhost" ?)

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Russ Housley]

> This message opens a Working Group Last Call for:
> 
> "Special-Use Names Problem Statement"
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
> Proposed status: informational
> 
> Starts: 2 Feb. 2017
> Ends: 23 Feb. 2017 (3 weeks)
> 
> Discussion should go to the mailing list. 
> 
> Is this draft ready to advance for publication as an Informational RFC, and 
> as guidance for possible updates to RFC 6761? Does it describe the relevant 
> issues clearly, and cover all the relevant ones that should be taken into 
> account in future work in the IETF on the special use names registry or RFC 
> 6761?

I think the document should be published an Informational RFC once the comments 
are resolved.  I think it offers a good foundation for a future rfc6761bis 
document.

I have several comments…

I think the title should be Special-Use Domain Names Problem Statement.  The 
abstract talks about domain names, so the title should match.

Will I-D.lewis-domain-names be published as an Informational RFC as well?  If 
not, then the Introduction needs to extract highlights from that document.

These three bullets in Section 3 overlap:

   o  Both ICANN and the IETF have the authority and formal processes to
  assign names from the pool of unused names, but no formal
  coordination process exists.  The lack of coordination complicates
  the management of the root of the Domain Namespace and may lead to
  conflicts in name assignments [SDO-ICANN-SAC090].

   o  The IETF and ICANN each have administrative authority over the
  Domain Namespace.  Not all developers of protocols on the internet
  agree that this authority should reside with the IETF and ICANN.

   o  Although IETF and ICANN nominally have authority over this
  namespace, neither organization can enforce that authority over
  any third party who wants to just start using a subset of the
  namespace.

I think there is one main point and two observations.  The main point is that 
both ICANN and the IETF have the authority and formal processes to assign 
previously unused names.  The first observation is that ICANN and the IETF need 
to coordinate to avoid conflicts.  The second observation is that some think 
that the authority is misplaced.  The second observation needs to be expanded 
to state the consequence, which I assume is squatting.  If I guessed correctly, 
the text should explain that squatting leads to conflicts.  The third 
observation is that neither ICANN nor the IETF has any technical means to 
prevent squatting.

I think that the Section 3 bullet on .local should explain that the amount of 
time involved was excessive, but part of the reason was that the process for 
special-use assignments was being invented.  As a result, .onion took much less 
time.

I think that theSection 3  bullet that references 
https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html should be 
reworded.  The information in the Ed Note probably does not belong in the 
Informational RFC.

I think that Section 4.2.5 should include a reference to the SSAC document.  I 
know it is also referenced elsewhere.


And a few Nits…

The “SUDN” and “SUTLDN” acronyms are defined, but they are not used very often. 
 I wonder is spelling it out in every case would be more clear.

In Section 3, there is bad formatting and duplicate informations in the bullet 
about ICANN Reserved Names.  I suggest:
s/(see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )/(seeSection 
2.2.1.2.1of [SDO-ICANN-DAG])

In Section 4.1.1:
s/TOR browser/Tor Browser [TP]/
s/connecting over TOR/connecting over the Tor network/

[TP] = https://www.torproject.org

In Section 4.1.3:
s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding [RFC2860]/

Russ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] IPR Disclosure VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis

[IETF Secretariat]

Dear Olaf M. Kolkman, Matthijs Mekking, R. (Miek) Gieben:


An IPR disclosure that pertains to your RFC entitled "DNSSEC Operational
Practices, Version 2" (RFC6781) was submitted to the IETF Secretariat on 
and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/2877/). The title of the IPR
disclosure is "VeriSign, Inc.'s Statement about IPR related to
draft-ietf-dnsop-rfc4641bis"


Thank you

IETF Secretariat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Ralph Droms]

Thanks for your review and comments, Russ.  I've extracted the issues from your 
review and entered them in the GitHub issue tracker for the document.

- Ralph

> On Feb 6, 2017, at 2:21 PM, Russ Housley  wrote:
> 
>> 
>> This message opens a Working Group Last Call for:
>> 
>> "Special-Use Names Problem Statement"
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ 
>> 
>> Proposed status: informational
>> 
>> Starts: 2 Feb. 2017
>> Ends: 23 Feb. 2017 (3 weeks)
>> 
>> Discussion should go to the mailing list. 
>> 
>> Is this draft ready to advance for publication as an Informational RFC, and 
>> as guidance for possible updates to RFC 6761? Does it describe the relevant 
>> issues clearly, and cover all the relevant ones that should be taken into 
>> account in future work in the IETF on the special use names registry or RFC 
>> 6761?
> 
> I think the document should be published an Informational RFC once the 
> comments are resolved.  I think it offers a good foundation for a future 
> rfc6761bis document.
> 
> I have several comments…
> 
> I think the title should be Special-Use Domain Names Problem Statement.  The 
> abstract talks about domain names, so the title should match.
> 
> Will I-D.lewis-domain-names be published as an Informational RFC as well?  If 
> not, then the Introduction needs to extract highlights from that document.
> 
> These three bullets in Section 3 overlap:
> 
>o  Both ICANN and the IETF have the authority and formal processes to
>   assign names from the pool of unused names, but no formal
>   coordination process exists.  The lack of coordination complicates
>   the management of the root of the Domain Namespace and may lead to
>   conflicts in name assignments [SDO-ICANN-SAC090].
> 
>o  The IETF and ICANN each have administrative authority over the
>   Domain Namespace.  Not all developers of protocols on the internet
>   agree that this authority should reside with the IETF and ICANN.
> 
>o  Although IETF and ICANN nominally have authority over this
>   namespace, neither organization can enforce that authority over
>   any third party who wants to just start using a subset of the
>   namespace.
> 
> I think there is one main point and two observations.  The main point is that 
> both ICANN and the IETF have the authority and formal processes to assign 
> previously unused names.  The first observation is that ICANN and the IETF 
> need to coordinate to avoid conflicts.  The second observation is that some 
> think that the authority is misplaced.  The second observation needs to be 
> expanded to state the consequence, which I assume is squatting.  If I guessed 
> correctly, the text should explain that squatting leads to conflicts.  The 
> third observation is that neither ICANN nor the IETF has any technical means 
> to prevent squatting.
> 
> I think that the Section 3 bullet on .local should explain that the amount of 
> time involved was excessive, but part of the reason was that the process for 
> special-use assignments was being invented.  As a result, .onion took much 
> less time.
> 
> I think that theSection 3  bullet that references 
> https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html 
>  should be 
> reworded.  The information in the Ed Note probably does not belong in the 
> Informational RFC.
> 
> I think that Section 4.2.5 should include a reference to the SSAC document.  
> I know it is also referenced elsewhere.
> 
> 
> And a few Nits…
> 
> The “SUDN” and “SUTLDN” acronyms are defined, but they are not used very 
> often.  I wonder is spelling it out in every case would be more clear.
> 
> In Section 3, there is bad formatting and duplicate informations in the 
> bullet about ICANN Reserved Names.  I suggest:
> s/(see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )/(seeSection 
> 2.2.1.2.1of [SDO-ICANN-DAG])
> 
> In Section 4.1.1:
> s/TOR browser/Tor Browser [TP]/
> s/connecting over TOR/connecting over the Tor network/
> 
> [TP] = https://www.torproject.org 
> 
> In Section 4.1.3:
> s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding [RFC2860]/
> 
> Russ
> ___
> 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] ALT-TLD and (insecure) delgations.

[Ralph Droms]

> 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 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 resolution 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

> 
> 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

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

[Mark Andrews]

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 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

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

[Brian Dickson]

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  mail.gmail.com>
> , Brian Dickson writes:
> >
> >- I am in favor of AS112 for ALT
> >- For AS112, I prefer the AS112++ method (DNAME)
> >- I do not see why the DNAME would/should not be DNSSEC signed
> >- Any local use of ALT can be served locally and signed using an
> >alternative trust anchor
>
> You need a insecure delegation for ALT for the purposes we want to
> use ALT for.
>
> Go setup a test rig where you have a signed root with ALT as you
> described.  A validiting recursive server which also serves foo.alt.
> A second validating recursive server which forwards all queries to
> the first recursive server.  All servers are configured with a trust
> anchor for the test root zone and are validating responses.  Try
> to perform a lookup on foo.alt.
>

I spent some time mocking up a variety of configurations.

My original assertion stands; the particulars on making it work are perhaps
not interesting to everyone.
However, it falls in the "pics or it didn't happen" category, so here's
what I did to make it work.

1 - set up a general resolver with the standard ICANN root trust anchor.
Call it "X".
2 - set up a local "fake root server" which delegates to a "local alt
server". Call this fake root server "F"
3 - set up a local "alt server" which serves the local "alt" domain
(including any delegations, etc). Cal this "A".
3 - set up a second resolver, with appropriate trust anchor(s), that uses a
"fake root server" instead of the real root. Call this "Y".
4 - set up a forwarder, which is configured to always forward to "X",
except for the zone "alt", where it forwards to "Y". Make sure the
necessary trust anchors are configured. Call this "Z".

Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
anchors)
Z->X otherwise (and validates using the ICANN root trust anchor).

When I do this, I get real answers for everything but "alt". For anything
at or under "alt", I get my own local copy.

Everything validates (or is from below an insecure delegation point).


>
> The second recursive server is the validating client that needs to
> be able to get a answer other than BOGUS.  As we want to allow
> foo.alt to be unsigned there can't be any other trust anchors,
> including negative, configured.
>

In the above scenario, you CAN have an unsigned foo.alt, and it will not
get BOGUS.

If you want me to send you configs, just drop me a line.

>
> Only solutions which allow content from the foo.alt zone to be
> successfully resolved are acceptable.
>
> The following will not work with the above rig:
> * No delegation for ALT.
> * A secure delegation for ALT.
> * A DNAME for ALT in the root zone.
>
> Mark


The problem is with your set-up, not the ability to have a working
local-alt set-up.

You need to put "foo.alt" somewhere OTHER than on the validating recursive
server (which knows how to find the local "alt" stuff.)

TIL you can't mix authority and recursive on the same server, when you are
the target of a forwarder.

If the two are separated, it works correctly, including using an alternate
trust anchor for "alt".

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Woodworth, John R]

> 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, invalid, test as
> > locally served zones. RFC 6762 specifies local. RFC 7686 specifies onion.
> >
> > RFC 7534 says that the AS112 DNAME target zones should be locally
> > served, though they are not listed in the special use registry.
> >
> > The example domains are special use but not locally served.
>
> The "locally served zones" and "special use domains" registries are different.
> There is potentially scope for overlap.
>
> It's possible that some special use domains might benefit from special
> treatment in the root zone, too (".localhost" ?)


I know I am late to the game but as I understand the issue (still catching up)
the .alt is intended for both non-DNS and special-use DNS (expected to be
resolved locally).

Just spitballing but what about a new RR type to actively flag the owner as
officially not-existing (e.g. NXD).  These RRs could be used in *any* zone
including root and combined with the special use registry (for policy)
could flag the namespace as both reserved and non-existent.

I tend to agree with Mark on this, SERVFAIL feels wrong.


/John


> Ray
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

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 there is the problem of distributing trust anchors for the
locally signed .alt zone just to be able to generate a NXDOMAIN
response locally so that you don't leak names to the root servers.

Note: we have no automatic solution to this problem and there is
no possible solution.

A DNAME at the root is not the right solution to this.

Mark

> On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews  wrote:
> 
> >
> > In message  > mail.gmail.com>
> > , Brian Dickson writes:
> > >
> > >- I am in favor of AS112 for ALT
> > >- For AS112, I prefer the AS112++ method (DNAME)
> > >- I do not see why the DNAME would/should not be DNSSEC signed
> > >- Any local use of ALT can be served locally and signed using an
> > >alternative trust anchor
> >
> > You need a insecure delegation for ALT for the purposes we want to
> > use ALT for.
> >
> > Go setup a test rig where you have a signed root with ALT as you
> > described.  A validiting recursive server which also serves foo.alt.
> > A second validating recursive server which forwards all queries to
> > the first recursive server.  All servers are configured with a trust
> > anchor for the test root zone and are validating responses.  Try
> > to perform a lookup on foo.alt.
> >
> 
> I spent some time mocking up a variety of configurations.
> 
> My original assertion stands; the particulars on making it work are perhaps
> not interesting to everyone.
> However, it falls in the "pics or it didn't happen" category, so here's
> what I did to make it work.
> 
> 1 - set up a general resolver with the standard ICANN root trust anchor.
> Call it "X".
> 2 - set up a local "fake root server" which delegates to a "local alt
> server". Call this fake root server "F"
> 3 - set up a local "alt server" which serves the local "alt" domain
> (including any delegations, etc). Cal this "A".
> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a
> "fake root server" instead of the real root. Call this "Y".
> 4 - set up a forwarder, which is configured to always forward to "X",
> except for the zone "alt", where it forwards to "Y". Make sure the
> necessary trust anchors are configured. Call this "Z".
> 
> Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
> anchors)
> Z->X otherwise (and validates using the ICANN root trust anchor).
> 
> When I do this, I get real answers for everything but "alt". For anything
> at or under "alt", I get my own local copy.
> 
> Everything validates (or is from below an insecure delegation point).
> 
> 
> >
> > The second recursive server is the validating client that needs to
> > be able to get a answer other than BOGUS.  As we want to allow
> > foo.alt to be unsigned there can't be any other trust anchors,
> > including negative, configured.
> >
> 
> In the above scenario, you CAN have an unsigned foo.alt, and it will not
> get BOGUS.
> 
> If you want me to send you configs, just drop me a line.
> 
> >
> > Only solutions which allow content from the foo.alt zone to be
> > successfully resolved are acceptable.
> >
> > The following will not work with the above rig:
> > * No delegation for ALT.
> > * A secure delegation for ALT.
> > * A DNAME for ALT in the root zone.
> >
> > Mark
> 
> 
> The problem is with your set-up, not the ability to have a working
> local-alt set-up.
> 
> You need to put "foo.alt" somewhere OTHER than on the validating recursive
> server (which knows how to find the local "alt" stuff.)
> 
> TIL you can't mix authority and recursive on the same server, when you are
> the target of a forwarder.
> 
> If the two are separated, it works correctly, including using an alternate
> trust anchor for "alt".
> 
> Brian
> 
> --001a113fece272cf3b0547e877d3
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> TL;DR: it is possible to have a signed DNAME in the root f=
> or alt (to empty.as112.arpa), AND have a local signed alt. Things under thi=
> s local alt can be signed or unsigned. iv class=3D"gmail_quote">On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews   dir=3D"ltr">marka@i=
> sc.org> wrote: margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
> t:1ex">
> In message  sxom13...@mail.gmail.com">CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSX=
> oM13DTg@mail.gmail.com>
> , Brian Dickson writes:
> >
> >=C2=A0 =C2=A0 - I am in favor of AS112 for ALT
> >=C2=A0 =C2=A0 - For AS112, I prefer the AS112++ method (DNAME)
> >=C2=A0 =C2=A0 - I do not see why the DNAME would/should not be DNSSEC s=
> igned
> >=C2=A0 =C2=A0 - Any local use of ALT can be served locally and signed u=
> sing an
> >=C2=A0 =C2=A0 alternative trust anchor
> 
> 

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

[Brian Dickson]

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 solvable problem 
for most values of "local".

If use cases for non-local or validating stubs exits, IMHO that rises to the 
level of requiring something real, not an alt name.

If you think that is something that there is a demand for, I don't know if it 
might belong in a separate domain.

An insecure delegation from the root may be seen as an invitation for 
exploitation by squatters.

Sent from my iPhone

> On Feb 6, 2017, at 8:05 PM, Mark Andrews  wrote:
> 
> 
> 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 there is the problem of distributing trust anchors for the
> locally signed .alt zone just to be able to generate a NXDOMAIN
> response locally so that you don't leak names to the root servers.
> 
> Note: we have no automatic solution to this problem and there is
> no possible solution.
> 
> A DNAME at the root is not the right solution to this.
> 
> Mark
> 
>>> On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews  wrote:
>>> 
>>> 
>>> In message >> mail.gmail.com>
>>> , Brian Dickson writes:
 
   - I am in favor of AS112 for ALT
   - For AS112, I prefer the AS112++ method (DNAME)
   - I do not see why the DNAME would/should not be DNSSEC signed
   - Any local use of ALT can be served locally and signed using an
   alternative trust anchor
>>> 
>>> You need a insecure delegation for ALT for the purposes we want to
>>> use ALT for.
>>> 
>>> Go setup a test rig where you have a signed root with ALT as you
>>> described.  A validiting recursive server which also serves foo.alt.
>>> A second validating recursive server which forwards all queries to
>>> the first recursive server.  All servers are configured with a trust
>>> anchor for the test root zone and are validating responses.  Try
>>> to perform a lookup on foo.alt.
>>> 
>> 
>> I spent some time mocking up a variety of configurations.
>> 
>> My original assertion stands; the particulars on making it work are perhaps
>> not interesting to everyone.
>> However, it falls in the "pics or it didn't happen" category, so here's
>> what I did to make it work.
>> 
>> 1 - set up a general resolver with the standard ICANN root trust anchor.
>> Call it "X".
>> 2 - set up a local "fake root server" which delegates to a "local alt
>> server". Call this fake root server "F"
>> 3 - set up a local "alt server" which serves the local "alt" domain
>> (including any delegations, etc). Cal this "A".
>> 3 - set up a second resolver, with appropriate trust anchor(s), that uses a
>> "fake root server" instead of the real root. Call this "Y".
>> 4 - set up a forwarder, which is configured to always forward to "X",
>> except for the zone "alt", where it forwards to "Y". Make sure the
>> necessary trust anchors are configured. Call this "Z".
>> 
>> Z->Y if QNAME matches "alt" or "*.alt" (and validates with local trust
>> anchors)
>> Z->X otherwise (and validates using the ICANN root trust anchor).
>> 
>> When I do this, I get real answers for everything but "alt". For anything
>> at or under "alt", I get my own local copy.
>> 
>> Everything validates (or is from below an insecure delegation point).
>> 
>> 
>>> 
>>> The second recursive server is the validating client that needs to
>>> be able to get a answer other than BOGUS.  As we want to allow
>>> foo.alt to be unsigned there can't be any other trust anchors,
>>> including negative, configured.
>>> 
>> 
>> In the above scenario, you CAN have an unsigned foo.alt, and it will not
>> get BOGUS.
>> 
>> If you want me to send you configs, just drop me a line.
>> 
>>> 
>>> Only solutions which allow content from the foo.alt zone to be
>>> successfully resolved are acceptable.
>>> 
>>> The following will not work with the above rig:
>>> * No delegation for ALT.
>>> * A secure delegation for ALT.
>>> * A DNAME for ALT in the root zone.
>>> 
>>> Mark
>> 
>> 
>> The problem is with your set-up, not the ability to have a working
>> local-alt set-up.
>> 
>> You need to put "foo.alt" somewhere OTHER than on the validating recursive
>> server (which knows how to find the local "alt" stuff.)
>> 
>> TIL you can't mix authority and recursive on the same server, when you are
>> the target of a forwarder.
>> 
>> If the two are separated, it works correctly, including using an alternate
>> trust anchor for "alt".
>> 
>> Brian
>> 
>> --001a113fece272cf3b0547e877d3
>> Content-Type: text/html; charset=UTF-8
>> Content-Transfer-Encoding: quoted-printable
>> 
>> TL;DR: it is possible to have a signed DNAME in the root f=
>> or alt (to empty.as112.a

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

[Mark Andrews]

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 of a local alt, only
> requires distribution of the trust anchor to the resolvers. That is a
> solvable problem for most values of "local".

It's not just stubs.

> If use cases for non-local or validating stubs exits, IMHO that rises to
> the level of requiring something real, not an alt name.
>
> If you think that is something that there is a demand for, I don't know
> if it might belong in a separate domain.
>
> An insecure delegation from the root may be seen as an invitation for
> exploitation by squatters.

And if they could find a way to squat here (which requires intercepting
queries) what would be the problem?  We are expecting the namespace
to be squatted.  Thats the whole point of the namespace.  In fact
we are going to tell nameserver vendors to squat on .alt by default*
to generate the NXDOMAIN responses.

There is absolutely no need for a secure NXDOMAIN here.  Just as
there is zero need for secure NXDOMAINs in COM, ORG, NET or any
other gTLD.  The gTLDs prevent secure delegations being spoofed
away.  The don't prevent names being spoofed into existence between
the secure delegations.

There is absolutely no need for a secure delegation here.

I have not seen anyone demonstrate a technical need for a secure
delegation for alt.  There are no formal delegation in alt so there
can be no secure delegations from alt.

Mark

> Sent from my iPhone
-- 
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] ALT-TLD and (insecure) delgations.

[Brian Dickson]

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 would be unsigned NXDOMAINs.

I am not seeing a problem with this.

Am I missing anything?

Brian

Sent from my iPhone

> On Feb 6, 2017, at 10:31 PM, Mark Andrews  wrote:
> 
> 
> 
> 
> 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 of a local alt, only
>> requires distribution of the trust anchor to the resolvers. That is a
>> solvable problem for most values of "local".
> 
> It's not just stubs.
> 
>> If use cases for non-local or validating stubs exits, IMHO that rises to
>> the level of requiring something real, not an alt name.
>> 
>> If you think that is something that there is a demand for, I don't know
>> if it might belong in a separate domain.
>> 
>> An insecure delegation from the root may be seen as an invitation for
>> exploitation by squatters.
> 
> And if they could find a way to squat here (which requires intercepting
> queries) what would be the problem?  We are expecting the namespace
> to be squatted.  Thats the whole point of the namespace.  In fact
> we are going to tell nameserver vendors to squat on .alt by default*
> to generate the NXDOMAIN responses.
> 
> There is absolutely no need for a secure NXDOMAIN here.  Just as
> there is zero need for secure NXDOMAINs in COM, ORG, NET or any
> other gTLD.  The gTLDs prevent secure delegations being spoofed
> away.  The don't prevent names being spoofed into existence between
> the secure delegations.
> 
> There is absolutely no need for a secure delegation here.
> 
> I have not seen anyone demonstrate a technical need for a secure
> delegation for alt.  There are no formal delegation in alt so there
> can be no secure delegations from alt.
> 
> Mark
> 
>> Sent from my iPhone
> -- 
> 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] ALT-TLD and (insecure) delgations.

[Mark Andrews]

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 issue, and facilitates use of local "alt"
> namespaces.

No it doesn't. 

> The default response to queries under alt would be unsigned NXDOMAINs.

No, it would be a secure response saying that foo.alt is covered
by a DNAME.  The names under empty.as112.arpa are unsigned NXDOMAINs.

The difference between the two descriptions is critical to why a
DNAME in the root zone will not work.  You *have* to leak names to
the root to get a DNAME returned by ordinary processing because the
DNAME is signed.

> I am not seeing a problem with this.
>
> Am I missing anything?

Yes.  A solution that *works*.

> Brian
>
> Sent from my iPhone
-- 
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] ALT-TLD and (insecure) delgations.

[Brian Dickson]

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.
> >
> > The DNAME target is an insecure empty zone.
> >
> > This avoids the validation issue, and facilitates use of local "alt"
> > namespaces.
>
> No it doesn't.
>
> > The default response to queries under alt would be unsigned NXDOMAINs.
>
> No, it would be a secure response saying that foo.alt is covered
> by a DNAME.  The names under empty.as112.arpa are unsigned NXDOMAINs.
>
> The difference between the two descriptions is critical to why a
> DNAME in the root zone will not work.  You *have* to leak names to
> the root to get a DNAME returned by ordinary processing because the
> DNAME is signed.
>
> > I am not seeing a problem with this.
> >
> > Am I missing anything?
>
> Yes.  A solution that *works*.
>
>
What are the specific requirements for the solution?

I am inferring that the following are needed:

The ability to have a local authority server for *.alt, where responses to
queries with DO=1 do not include any DNSSEC RRs, i.e. unsigned responses.

The ability to have validating forwarders configured to point to one or
more resolvers, where the resolvers are configured to use these alt
server(s) (directly or indirectly)

The ability of validating stub resolvers to accept the answers received
(not BOGUS).

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 that acceptable, as long as there is no validation failure?

Whatever initiated the DNS call, via the stub, would get back , and
presumably be unaware of the presence of the DNAME.

I just want to be sure what is or is not acceptable, and what is explicitly
within the requirements for a working solution.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop