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

[Patrik Fältström]

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 is the basis for us to say no?
>
> If alt ends up in the 6761 special-use names registry, that seems a
> reason for ICANN not to delegate the name.  For adding something to
> the 6761 special-use names registry removes it from the possible pool
> of names that can be in the root zone.

This would be my suggestion.

What worries me is not names in 6761 special-use names registry but other names 
ICANN "should not" add to the root zone.

   paf


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

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

[Ray Bellis]

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 correct that we need to decide
> whether alt is to be used for those purposes.  I'm not convinced
> that's so useful.

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

Ray

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

[DNSOP] DNS BoF at FOSDEM, Sunday

[Peter van Dijk]

Hello DNS people!

For those of you attending FOSDEM, we have reserved room H.3227 for 
Sunday(!) 13:00-14:00, to hold a DNS BoF. There is no agenda yet; please 
suggest items by private reply.


If you are at FOSDEM, or if you know anyone who is, please make sure 
they know! If you think I missed a mailing list, please forward this 
message.


If you need to reach me, please use +31-6-10908570.

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

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

[Mark Andrews]

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 that it is up to this WG or even the IETF to make any
> determinations about why the names community decides the policies it
> does for the root zone.  But in any case, there are two relevant
> policy issues here:
> 
> 1.  We are not the authority for delegations -- signed, unsigned,
> emtpy or otherwise -- from the root zone, and if we are going to
> seek any kind of entry in the actual DNS root zone then we are
> talking about that in entirely the wrong forum.  We maybe should
> complete the alt draft saying what we want from it, and then
> insert that into the correctly-shaped receptical at ICANN. 
> 
> 2.  Unfortunately for us, right now, there _is_ no such receptical
> at ICANN.  For there does not appear to be an ICANN policy for
> delegations from the root for special uses.  There is a policy for
> ccTLD additions, but we are not a country.  There is no current
> policy for new gTLDs -- the previous round closed, and there has
> been no determination of whether a new round will happen nor what
> that round might entail if it happens.  If you want to shape those
> rules, I believe there are some discussions going on within some
> constituencies at ICANN.
> 
> > signed.  There is no reason for ICANN to object other than religious
> > arguments.  Technically they don't have a leg to stand on.
>  
> I'm sorry, but it's not religious.  Other communities have rules for
> establishing their IANA functions.  If we want them to respect our
> rules for the IANA registries for which we set the policy, then we
> need to respect theirs for the registries for which they set the
> policy.

Given there are no rules for this type of namespace we need to
respect the reasons for the other rules which I did but you choose
to completely cut out of the reply.  This isn't a registry.  It's
a non-registry.  It is different.

Mark

> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> 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.

[Mark Andrews]

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
> > > authoritative for that zone -- why would it ask the root about it at
> > > all?
> > 
> > As long as the stub resolver isn't validating, it's no problem. If it is 
> > validating, t
> hen the recursive resolver can't fool the stub resolver if there's a secure 
> denial of ex
> istence.
> > 
> 
> 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 correct that we need to decide
> whether alt is to be used for those purposes.  I'm not convinced
> that's so useful.

It's a problem for ALL special names.  BOGUS / SERVFAIL isn't the
response leaked names should get.  Its bad engineering.
 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> 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.

[Suzanne Woolf]

> 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.  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.
> 
> I think that we've seen a number of questions go by that lead to the 
> conclusion that it makes sense to have two hierarchies: one for experimental 
> non-DNS queries, and one for locally served zones.   I don't know if we 
> _need_ the .LSZ (or whatever) SUTLDN, but if we need to be able to have a 
> special-use top-level domain name that has an un-signed delegation, it 
> probably ought to be different than the SUTLDN that is used for non-DNS 
> stuff, so that both names can have the appropriate configuration in the root 
> zone.

We may be making this harder than it has to be.

It’s worth noting at this point that the "1918-style part of the DNS” (DNSSEC 
compatibility for names intended to be locally resolved with the DNS protocol) 
is a solved problem, if you mean it literally: they’re under .arpa.

This was an obvious solution for address blocks, since in-addr.arpa was already 
established by the protocol for PTR records and .arpa was already administered 
under IETF rules.

However, in terms of the desired behavior all the parts are there: .arpa is a 
signed zone, can have signed or unsigned delegations for names intended to be 
resolvable in the DNS (locally or globally), and is administered under IETF 
rules that include *not* delegating special use names under it that shouldn’t 
be in the DNS (I don’t see the IAB having a problem with making a commitment 
that a specific string won’t be delegated).

The objections to .home.arpa were to the specific string “.arpa” and that it 
wasn’t a single-label name, which seemed to be strong preferences but I’m not 
sure were ever documented as hard (“it won’t work otherwise”) requirements. For 
other special use names, they might very well not be constraints.

Having already decided that “single label” is a tough constraint to maintain if 
you want an unsigned delegation from a signed zone (i.e. an unsigned TLD in the 
root), I’m not sure I see a major difference between mystring.alt and 
mystring.arpa.


Suzanne


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

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

[Ted Lemon]

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

.alt doesn't allow for reserved allocations, so I don't think this would fly.   
Also, there won't be a .alt zone (correct me if I am wrong), so it doesn't 
actually solve the problem.

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

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

[Ted Lemon]

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 not the correct response?

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

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

[Mark Andrews]

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 response leaked names should get, and why is that the correct
> response?   Why is SERVFAIL not the correct response?

SERVFAIL indicates something went wrong.  Clients try alternative
servers on SERVFAIL.  It isn't a property of the name.  It the
property of a server when looking up the name.

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

[Suzanne Woolf]

> 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 enable in-homenet DNS without reference to the
>> global DNS.  I think you're quite correct that we need to decide
>> whether alt is to be used for those purposes.  I'm not convinced
>> that's so useful.
> 
> 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 that.

The other question to keep in mind, perhaps particularly for HOMENET, is how 
long are you/we willing to wait?

The IETF has no process for requesting a change to the root zone (it’s not one 
of the protocol parameter registries under the change control of the IETF) and 
ICANN has no process for evaluating such a request..

Generallly when iCANN is asked to do something for which they have no process, 
their answer is Yes; No; or “We have to think about that,” and it often takes 
years, particularly in the last case.

(no hats, just lots of experience.)


Suzanne

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

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

[Warren Kumari]

On Fri, Feb 3, 2017 at 10:34 AM, Jeremy Rand  wrote:
> Suzanne Woolf:
>> 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?
>>
>> If not, can you suggest changes that would get your support for advancing 
>> it? (“Send text” if possible!)
>>
>>
>> thanks,
>> Suzanne & Tim
>
> Trivial spelling nit: Sec. 4.2.2 says "unilateral use by the TOR
> project".  The correct spelling is "Tor" (only the "T" in "Tor" should
> be capitalized.)  Also, according to
> https://www.torproject.org/docs/trademark-faq.html.en, "The Tor Project"
> is the correct spelling of the phrase (all 3 words should have the
> initial letter capitalized).


Thank you very much -- Ralph added this (and Suzanne's below) to the
issue tracker. I did the easier part of addressing the nits and
closing the nitty issues. We've published a version to GitHub with
some of the nits addressed, and we will work on addressing more of the
substantive comments.

W


>
> Cheers,
> -Jeremy
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



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