Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?

[Viktor Dukhovni]

On Thu, Sep 29, 2016 at 09:03:33AM -0400, Robert Edmonds wrote:

> > Very good question but, IMHO, it is thread-stealing (hence changing
> > the subject, and removing thread headers).
> 
> I think there was already a thread on this topic recently on this list
> ("Order of CNAME and A in Authoritative Reply" from August 2015). There
> was some discussion over "adding" versus "appending" and it was pointed
> out that a lot of existing code (e.g., the BSD stub resolver) was
> written using the "add at the end" meaning.

Right you are, and it seems I even participated in that discussion,
though it has entirely faded from memory.  All that said, it seems
to me that no conclusion was arrived at in that 2015 thread.

I'm inclined to conclude (as suggested off-list) that, while it
may be prudent to parse conservatively, and not make ordering
assumptions, in fact less tolerant stub resolvers are sufficiently
common and so one would likely get away with assuming natural
ordering.  So perhaps doing it right is not entirely overkill...

-- 
Viktor.

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Alain Durand]

On Sep 29, 2016, at 8:37 PM, Warren Kumari 
> wrote:

On Thursday, September 29, 2016, Ted Lemon 
> wrote:

So, if anyone is still wondering why we need a /good/ problem statement, this 
discussion is why.  You are both taking past reach other because you are 
looking at only the part of the problem you care about.


... and why we need a Special Use Names problem statement, and not just a 
RFC6761 problem statement. This problem is bigger than just 6761...

We will have to agree to disagree. RFC6761 is the document that created this 
issue. Focusing on what is wrong running its process should be, IMHO, the first 
step. It is like: first, admit we have a problem.

Alain, speaking solely on my own behalf.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[John R Levine]

Okay, John, if you can state the problem in one sentence and not have
it just be your particular view of the problem, let's hear that
sentence.   Otherwise, can you stop with the hyperbole?


I did, back on Sept 18th.  Here it is again, slightly tweaked.  I realize 
that you don't like either of these, but at this point, so what?  Neither 
your draft nor the other one is getting traction, so evidently neither of 
them describe the problem that the group thinks we should solve.



... we'd be better off with a one or two sentence description of
what we're trying to do, perhaps along these lines:

  * Describe how and when to recognize domain names that are handled
  in ways other than the DNS.  (That's mDNS and .onion)

or

  * Describe how and when to recognize domain names that should not
  be delegated in the DNS. (That's mDNS and .onion plus the toxic waste.)

or maybe something else, so long as it's short.

R's,
John

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[John R Levine]

So, if anyone is still wondering why we need a /good/ problem statement,
this discussion is why.  You are both taking past reach other because you
are looking at only the part of the problem you care about.


Agreed.  It's also why the problem statement has to be as short as 
possible, like one sentence, so people can't read it multiple ways.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Paul Wouters]

On Thu, 29 Sep 2016, Warren Kumari wrote:


On Thursday, September 29, 2016, Ted Lemon  wrote:

  So, if anyone is still wondering why we need a /good/ problem statement, 
this discussion is why.  You are
  both taking past reach other because you are looking at only the part of 
the problem you care about.

... and why we need a Special Use Names problem statement, and not just a 
RFC6761 problem statement. This problem is
bigger than just 6761...


I still do not see that. Without 6761, if anyone wants to ask for a TLD,
whether to delegate or never delegate, we (IETF) can say: That is
outside the area of our expertise - you must go to ICANN.

ICANN already has a blacklist of unsafe domains. IETF can advise them
on that list if needed.

I don't think at this point either ICANN or IETF would want to add TLDs
to the unsafe list. If at this point someone is still squatting domain
names, they get what they deserve. And all the known security risky
domains (as a result of decades of use of unqualified domain names)
are already known at ICANN, and they won't assign these. People creating
new ones are also going against the long standing don't squat advise,
and need no further protection from their own foot bullets.

So that brings the problem statement to:

IETF had the power to allocate or ban domain names based on the
Special Names RFC-6761. IETF no longer wants that power.

And the solution for that is a 6761bis document that confirms this.

Paul

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Warren Kumari]

On Thursday, September 29, 2016, Ted Lemon  wrote:

> So, if anyone is still wondering why we need a /good/ problem statement,
> this discussion is why.  You are both taking past reach other because you
> are looking at only the part of the problem you care about.
>


... and why we need a Special Use Names problem statement, and not just a
RFC6761 problem statement. This problem is bigger than just 6761...

W

>
> On Sep 29, 2016 6:03 PM, "George Michaelson"  > wrote:
>
> Thats precisely why its NOT a false analogy: the design model in the
> IETF is that the value doesn't matter, but in the DNS, the design
> model is "follow the money" and 6761 crosses the bars: it enables
> people in tech-space, to reserve labels in meat-space.
>
> We got it wrong. We should have encouraged s/w designers not to brand
> their DNS breakout string early, but provided a mechanism to give them
> a token under .arpa, or something else, pending a decision, and we
> should have made it clear the specific string wasn't their chosing. If
> they see inherent value in the string, then they immediately walked to
> being an applicant in ICANN gTLD space: the technical merit argument
> doesn't relate.
>
> Sorry John, but to me its not a "false analogy" its exactly what I
> meant. 6761 is a process fail.
>
>
> On Fri, Sep 30, 2016 at 10:41 AM, John R Levine  > wrote:
> >> The latter, is the decision-role of ICANN. Under advisement, yes.
> >> respecting IETF process yes. But the mechanism as written in 6761
> >> vests IETF with a process outcome which specifies where the label is,
> >> and what value. Thats just wrong.
> >
> >
> > For some version of wrong, I suppose, but it seems a false analogy to
> > me.  Nobody cares if their new RRTYPE is number 666 or numbr 273, or
> > what IP address range they get, but a lot of people care if their TLD
> > or pseudo-TLD is .lksjdk or .money.
> >
> >
> > R's,
> > John
> >
> > ___
> > 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
>
>
>

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Ted Lemon]

So, if anyone is still wondering why we need a /good/ problem statement,
this discussion is why.  You are both taking past reach other because you
are looking at only the part of the problem you care about.

On Sep 29, 2016 6:03 PM, "George Michaelson"  wrote:

Thats precisely why its NOT a false analogy: the design model in the
IETF is that the value doesn't matter, but in the DNS, the design
model is "follow the money" and 6761 crosses the bars: it enables
people in tech-space, to reserve labels in meat-space.

We got it wrong. We should have encouraged s/w designers not to brand
their DNS breakout string early, but provided a mechanism to give them
a token under .arpa, or something else, pending a decision, and we
should have made it clear the specific string wasn't their chosing. If
they see inherent value in the string, then they immediately walked to
being an applicant in ICANN gTLD space: the technical merit argument
doesn't relate.

Sorry John, but to me its not a "false analogy" its exactly what I
meant. 6761 is a process fail.


On Fri, Sep 30, 2016 at 10:41 AM, John R Levine  wrote:
>> The latter, is the decision-role of ICANN. Under advisement, yes.
>> respecting IETF process yes. But the mechanism as written in 6761
>> vests IETF with a process outcome which specifies where the label is,
>> and what value. Thats just wrong.
>
>
> For some version of wrong, I suppose, but it seems a false analogy to
> me.  Nobody cares if their new RRTYPE is number 666 or numbr 273, or
> what IP address range they get, but a lot of people care if their TLD
> or pseudo-TLD is .lksjdk or .money.
>
>
> R's,
> John
>
> ___
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[George Michaelson]

Thats precisely why its NOT a false analogy: the design model in the
IETF is that the value doesn't matter, but in the DNS, the design
model is "follow the money" and 6761 crosses the bars: it enables
people in tech-space, to reserve labels in meat-space.

We got it wrong. We should have encouraged s/w designers not to brand
their DNS breakout string early, but provided a mechanism to give them
a token under .arpa, or something else, pending a decision, and we
should have made it clear the specific string wasn't their chosing. If
they see inherent value in the string, then they immediately walked to
being an applicant in ICANN gTLD space: the technical merit argument
doesn't relate.

Sorry John, but to me its not a "false analogy" its exactly what I
meant. 6761 is a process fail.


On Fri, Sep 30, 2016 at 10:41 AM, John R Levine  wrote:
>> The latter, is the decision-role of ICANN. Under advisement, yes.
>> respecting IETF process yes. But the mechanism as written in 6761
>> vests IETF with a process outcome which specifies where the label is,
>> and what value. Thats just wrong.
>
>
> For some version of wrong, I suppose, but it seems a false analogy to
> me.  Nobody cares if their new RRTYPE is number 666 or numbr 273, or
> what IP address range they get, but a lot of people care if their TLD
> or pseudo-TLD is .lksjdk or .money.
>
>
> R's,
> John
>
> ___
> 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] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[John R Levine]

The latter, is the decision-role of ICANN. Under advisement, yes.
respecting IETF process yes. But the mechanism as written in 6761
vests IETF with a process outcome which specifies where the label is,
and what value. Thats just wrong.


For some version of wrong, I suppose, but it seems a false analogy to
me.  Nobody cares if their new RRTYPE is number 666 or numbr 273, or
what IP address range they get, but a lot of people care if their TLD
or pseudo-TLD is .lksjdk or .money.

R's,
John

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[william manning]

On Thu, Sep 29, 2016 at 3:28 PM, John R Levine  wrote:

> I suppose I could use jrl.alt, but I wouldn't want to use plain .alt for
>>> fear of, if you'll pardon the phrase, name collisions.
>>>
>>
> Name collisions may occur at any delegation point - why do you think the
>> root zone is special in this regard?
>>
>
> The point of .alt as I understand it is to provide a home for future stuff
> like .onion that is intended to be globally visible and usable but not
> resolved through the DNS.
>
> My .qy isn't globablly visible, so I don't care about other local uses of
> .qy.
>
> R's,
> John
>
>
Until it is globally visible...  and there is nothing we can do (ietf)
about that process.

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[George Michaelson]

The initiation problem is the belief IETF needs a mechanism to
identify non-use of the DNS or special use of the DNS demanding a
break-out from normal gethostbyname() and related processing.

The second order problem is that people come to the table with
proscriptive ideas about the specific label: where it is in the DNS
hierarchy, and what string value the label bears.

The latter, is the decision-role of ICANN. Under advisement, yes.
respecting IETF process yes. But the mechanism as written in 6761
vests IETF with a process outcome which specifies where the label is,
and what value. Thats just wrong.

Consider IANA codepoints. You don't tell IANA "I want 42" -You ask
IANA to reserve one and in draft status, you use a $nonce and in
publication its assigned BY IANA AT THAT TIME or, if pre-reserved, we
understand how and why.

The current 6761 breaks this model. It breaches process badly inside
ICANN and the worlds vesting of 'value' in DNS labels, (rightly or
wrongly)

Thats why I wrote the shut it down draft. The problem is not the
desire to reserve labels, its the way we've specified it, promoting
(a) top level and (b) specific strings into ICANN driven decision
logic.

-G

On Fri, Sep 30, 2016 at 3:08 AM, John R. Levine  wrote:
>> If the process was a success, we would have had the other candidates go
>> through as well. The process was a failure because it has been rather
>> arbitrary - which is why it needed to close down as it did.
>
>
> Some of us think that the process worked OK, and the other candidates
> don't meet the requirements that .onion did.
>
> This isn't to argue that 6761 is perfect, but that we have little
> agreement on if or how it's broken.
>
> R's,
> John
>
>
> ___
> 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] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[John R Levine]

I suppose I could use jrl.alt, but I wouldn't want to use plain .alt for
fear of, if you'll pardon the phrase, name collisions.



Name collisions may occur at any delegation point - why do you think the
root zone is special in this regard?


The point of .alt as I understand it is to provide a home for future stuff 
like .onion that is intended to be globally visible and usable but not 
resolved through the DNS.


My .qy isn't globablly visible, so I don't care about other local uses of .qy.

R's,
John

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[william manning]

On Thursday, 29 September 2016, John R Levine  wrote:

> I've been telling people that if they need a fake private TLD for their
 local network they should use one of those since it is exceedingly unlikely
 ever to collide with a real DNS name.  Am I right?

>>>
> C: why not just use .alt for this? It is clear that these should not
>> hit the global DNS, and should fail (get NXD) if they do. It is
>> clearly different to a ccTLD (at least some users have learnt that
>> things of the form .xx are "countries" - lets not confuse them
>> further).
>>
>
> I suppose I could use jrl.alt, but I wouldn't want to use plain .alt for
> fear of, if you'll pardon the phrase, name collisions.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnso
> 
>


Name collisions may occur at any delegation point - why do you think the
root zone is special in this regard?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[John R Levine]

I've been telling people that if they need a fake private TLD for their local 
network they should use one of those since it is exceedingly unlikely ever to 
collide with a real DNS name.  Am I right?



C: why not just use .alt for this? It is clear that these should not
hit the global DNS, and should fail (get NXD) if they do. It is
clearly different to a ccTLD (at least some users have learnt that
things of the form .xx are "countries" - lets not confuse them
further).


I suppose I could use jrl.alt, but I wouldn't want to use plain .alt for 
fear of, if you'll pardon the phrase, name collisions.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[Michael StJohns]

Hi -

A couple of items of history.  Back about 1987, Jon Postel and I talked 
about the original registration of .INT - he was the IANA, I was 
managing the NIC contract which would be responsible for dealing with 
registrations under .INT.  ( .INT ended up being managed by ISI under an 
DARPA contract when the DDN PMO wouldn't cover the costs).  The topic of 
the cc TLDs came up then and strangely a bit later when I was at 
(D)ARPA.  The first time was a discussion about .UK vs .GB, the last was 
about Native American tribes/nations.


Jon was adamant (and I think rightly so) about keeping the IANA out of 
determinations of "what is a country"  and to use the 3166 process for 
allocation of 2 character TLDs (note I didn't say ccTLDs) and I think 
that still makes a lot of sense.  Given that, I would suggest we say 
that all of the possible two letter TLDs not yet delegated have been 
reserved by the IANA on behalf of ISO3166 pending a request to delegate 
them to an entity identified by ISO3166.  I might suggest that 
ICANN/IANA update RFC1591 to discuss how to deal with "transitionally 
reserved" TLDs/ISO3166-2 codes (e.g. .SU from the soviet union for 
example) if they haven't already.


And to answer John's original question - it's probably a bad idea, but, 
like smoking,  it probably won't kill you immediately.  I might actually 
suggest using .EZ which looks like it will never be stood up as a DNS 
domain given that its registration is for " European OTC 
 
derivatives within International securities identification numbering 
system 
 
(ISIN)"


And to go back to Ed's comment.  I *wouldn't* move forward with his 
draft.  It's not space that's currently owned by the IETF/IANA/ICANN.


So a big +1 to Mark's comment about using namespaces not delegated to you.

Mike



On 9/29/2016 11:44 AM, David Conrad wrote:

Mark,

On September 28, 2016 at 10:35:40 PM, Mark Andrews (ma...@isc.org 
) wrote:



Things can change. It is ALWAYS a bad idea to use namespace not
delegated to you.


Unless, of course, Ed's draft progresses and the user assigned ISO 
codes are turned into private use TLDs (similar to RFC 1918 turning 
10/8, etc., into private use address space).


The only way the user assigned codes could be delegated would be if:

a) ISO reverses their policy for those codes and assigns them to countries

b) The IETF revises name assignment policy and demands they be delegated

c) The ICANN community revises name assignment policy and allows them 
to be delegated


I'm quite confident that (c) will never occur -- too many parts of the 
ICANN community would reject the idea instantaneously and given the 
new gTLD program, there is simply no reason for the question to even 
come up.  Similarly, I'm reasonably confident the IETF won't demand 
those labels be delegated -- I can't see a reason why a different 
solution would be sufficient. Where I don't have as much confidence is 
in ISO-3166/MA's actions, but that's mostly because I don't know how 
they work.


Regards,

-drc



___
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] register and unregister, was Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[John Levine]

>> prompts another question: if a name enters the Special-Use Name
>> Registry, is it parked (for an indefinite amount of time), or is it
>> engraved in stone (and won't move from that registry again)?  And can
>> the SUNR hold both types of names (parked and final)?
>
>Good question, not (as far as I know) explicitly addressed in RFC 6761.

It isn't.  Given what's in 6761, I doubt the question ever came up.

>The question might actually apply to many IANA registries.  Do the 
>"Registration Procedures" apply to "unregistration" as well?  I don't know
>if there is any precedent here.

Well, the list of names in the root is nominally an IANA registry, and
they're removed lots of names such as .NATO and countries that no
longer exist such as .CS and .YU.  But somehow I'm guessing that's not
what you're thinking of.

It is my vague recollection that we have removed some old cruft from parameter
registries, but after some googlage I can't find any details.

R's,
John

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[David Conrad]

Mark,

On September 28, 2016 at 5:08:05 PM, Mark Andrews (ma...@isc.org) wrote:
> I've been telling people that if they need a fake private TLD for their local 
> network they should use one of those since it is exceedingly unlikely 
> ever to collide with a real DNS name. Am I right? 

No. Just because countries don't get assigned these values it 
doesn't mean that they can't be assigned by ICANN or the IETF in 
consultation with ICANN. 
I believe from both the IETF's and ICANN's perspective, 2-letter labels at the 
root are reserved to be associated with ISO-3166 2-letter codes. I cannot 
imagine a plausible scenario in which this policy would change.

And who *needs* a fake tld? As far as I can tell almost no one. 
Can we PLEASE not repeat the arguments made against RFC 1918 space in the 
domain name world?

Regards,

-drc




signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Where in a CNAME chain is the QNAME?

[Paul Hoffman]

On 29 Sep 2016, at 8:01, Robert Edmonds wrote:

> Paul Hoffman wrote:
>> Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which
>> describes the format of resource records:
>
> Compare that section to the nearly identical §4.1.3, which replaces this
> sentence:
>
> All RRs have the same top level format shown below:
>
> with:
>
> The answer, authority, and additional sections all share the same
> format: a variable number of resource records, where the number of
> records is specified in the corresponding count field in the header.
> Each resource record has the following format:
>
> But, the "All RRs" part of §3.2.1 is still accurate, because an entry in
> the question section is not a RR.
>
> There are some other differences between §3.2.1 and §4.1.3, for instance
> §3 uses "owner name" while §4 uses "domain name" to describe the NAME
> field, and the infamous signed vs. unsigned definition of the TTL field.

Yes, I see that now. N'r mind...

--Paul Hoffman

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

Re: [DNSOP] Where in a CNAME chain is the QNAME?

[Robert Edmonds]

Paul Hoffman wrote:
> Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which
> describes the format of resource records:

Compare that section to the nearly identical §4.1.3, which replaces this
sentence:

All RRs have the same top level format shown below:

with:

The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the header.
Each resource record has the following format:

But, the "All RRs" part of §3.2.1 is still accurate, because an entry in
the question section is not a RR.

There are some other differences between §3.2.1 and §4.1.3, for instance
§3 uses "owner name" while §4 uses "domain name" to describe the NAME
field, and the infamous signed vs. unsigned definition of the TTL field.

-- 
Robert Edmonds

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Ted Lemon]

Carrot and stick. The current IESG can certainly abstain new proposals to
death, and individual ADs can refuse to publish. But in doing so they are
trying to lead the consensus on a new direction. They cannot unilaterally
change it.

On Sep 29, 2016 10:27, "Paul Wouters"  wrote:

> On Sep 29, 2016, at 10:21, Ted Lemon  wrote:
> >
> > To be clear, while the IESG may have said something about their
> > willingness to entertain further uses of the 6761 process, the 6761
> > process represents current IETF consensus.   If we don't update it, it
> > stands.
>
> That does contract earlier statements  from dnsop that stated no new 6761
> based special names would be considered until we had a new solution.
>
> Paul
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Where in a CNAME chain is the QNAME?

[Shumon Huque]

On Thu, Sep 29, 2016 at 10:36 AM, Paul Hoffman 
wrote:

> On 28 Sep 2016, at 22:50, Robert Edmonds wrote:
>
> Stephane Bortzmeyer wrote:
>>
>>> On Mon, Sep 26, 2016 at 09:04:54AM -0400,
>>>  Matt Larson  wrote
>>>  a message of 41 lines which said:
>>>
>>> I'd venture that more people familiar with the subject matter would
 define QNAME as the name in the question section of a DNS message.
 (That's my sense of the definition, FWIW.)

>>>
>>> What about adding this text to the Terminology section of the draft?
>>>
>>>"QNAME": it is defined in  and
>>>in , section 4.1.2, but, because >>target="RFC2308"/> provides a different definition, we repeat the
>>>original one here: the QNAME is the owner name of the record in the
>>>Question section.
>>>
>>
>> The QNAME is a domain name, but is it an owner name? There is no owned
>> record data in the question section (and the entries in the question
>> section are not RRs).
>>
>
> Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which
> describes the format of resource records:
>
> All RRs have the same top level format shown below:
>
> 1  1  1  1  1  1
>   0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> |   |
> /   /
> /  NAME /
> |   |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> |  TYPE |
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> . . .
>
> where:
>
> NAMEan owner name, i.e., the name of the node to which this
> resource record pertains.
>

Yes, Owner name is defined in terms of a resource record, i.e. the domain
name that owns a resource record.

But the question section has no resource record. It has 3 components of a
potential resource record.

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Paul Wouters]

On Sep 29, 2016, at 10:21, Ted Lemon  wrote:
> 
> To be clear, while the IESG may have said something about their
> willingness to entertain further uses of the 6761 process, the 6761
> process represents current IETF consensus.   If we don't update it, it
> stands.  

That does contract earlier statements  from dnsop that stated no new 6761 based 
special names would be considered until we had a new solution.

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

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Paul Wouters]

> On Sep 28, 2016, at 17:24, Stephane Bortzmeyer  wrote:
> 
> On Sun, Sep 25, 2016 at 12:35:00PM -0400,
> Paul Wouters  wrote 
> a message of 16 lines which said:
> 
>>> it works (two TLD were registered through it).
>> 
>> Are you referring to the two registrations as successes or failures,
> 
> In the absence of criteria for defining success or failure of a
> special-use TLD, it will be hard to tell. But the _process_ was a
> success: applications were written, examined, and the registry was
> updated.

If the process was a success, we would have had the other candidates go through 
as well. The process was a failure because it has been rather arbitrary - which 
is why it needed to close down as it did.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?

[Robert Edmonds]

Stephane Bortzmeyer wrote:
> On Thu, Sep 29, 2016 at 08:17:28AM +,
>  Viktor Dukhovni  wrote 
>  a message of 57 lines which said:
> 
> > By the way, is it the case that CNAMEs in the answer section MUST
> > appear in their natural chaining order:
> 
> Very good question but, IMHO, it is thread-stealing (hence changing
> the subject, and removing thread headers).

I think there was already a thread on this topic recently on this list
("Order of CNAME and A in Authoritative Reply" from August 2015). There
was some discussion over "adding" versus "appending" and it was pointed
out that a lot of existing code (e.g., the BSD stub resolver) was
written using the "add at the end" meaning.

-- 
Robert Edmonds

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[Jim Reid]

> On 29 Sep 2016, at 13:24, Stephane Bortzmeyer  wrote:
> 
>> 
>> Where’s the demand from experimenters
> 
> The demand? You see it in the use of non-ICANN TLDs like .onion or
> .bit.
> 
>> and why do they need a dedicated TLD for their alterate resolution
>> systems?
> 
> You may think they don't NEED it but how will you convince them? (The
> IETF has no police force, so our only course of action would be to
> convince people.)
> 
>> FWIW I’m sceptical about creating .alt as a playpen for experiments
>> since it might undermine efforts to answer the question ICANN asked
>> us,
> 
> ICANN asked us what? When and where (URL, please)?

Stephane, please stop this rat-holing and whatabootery. [Raising non-sequiturs: 
what about...] It is not helping the production of a problem statement. I hope 
you can focus your efforts on that.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[Stephane Bortzmeyer]

On Thu, Sep 29, 2016 at 09:50:13AM +0200,
 Jaap Akkerhuis  wrote 
 a message of 15 lines which said:

> There is no such thing as a language attribute to doamain names.

Tell that to ICANN, which continues to use "languages" when they mean
"scripts" :-(

But if you want precision, let's go:

A domain name is written from left to right if it is composed entirely
of characters from LTR scripts (for instance the latin script, used to
write english). If the domain name is composed of characters from RTL
scripts, it is written from right to left (the TLD will be the
leftmost label).

[Of course, this is only the text representation, the wire one is
unaffected.]

The case of Bidi FQDN (RTL and LTR characters) is left as an
exercice...

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

[DNSOP] Mandated order of CNAME records in a CNAME chain?

[Stephane Bortzmeyer]

On Thu, Sep 29, 2016 at 08:17:28AM +,
 Viktor Dukhovni  wrote 
 a message of 57 lines which said:

> By the way, is it the case that CNAMEs in the answer section MUST
> appear in their natural chaining order:

Very good question but, IMHO, it is thread-stealing (hence changing
the subject, and removing thread headers).

> irrelevant CNAME responses that are even part of the chain, ...

You mean _not_ even part of the chain?

> Or put another way, does step "3 a" of Section 4.3.2 of RFC 1034
> imply

This algorithm seems to be for a resolver querying authoritative
servers, and therefore does not address your issue (which is for a
final client).

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[Stephane Bortzmeyer]

On Tue, Sep 27, 2016 at 07:38:52PM +0100,
 Jim Reid  wrote 
 a message of 35 lines which said:

> Where’s the demand from experimenters

The demand? You see it in the use of non-ICANN TLDs like .onion or
.bit.

> and why do they need a dedicated TLD for their alterate resolution
> systems?

You may think they don't NEED it but how will you convince them? (The
IETF has no police force, so our only course of action would be to
convince people.)

> FWIW I’m sceptical about creating .alt as a playpen for experiments
> since it might undermine efforts to answer the question ICANN asked
> us,

ICANN asked us what? When and where (URL, please)?

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Wed, Sep 28, 2016 at 06:44:27PM +0200,
 Ralf Weber  wrote 
 a message of 26 lines which said:

> I consider anything in the cache where the TTL is still valid to be
> valid data that can be send to clients even if below the nxdomain
> cut. My understanding is that this is how the current draft is
> written.

Yes (with "MAY" instead of "can").

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Tue, Sep 27, 2016 at 07:28:57PM +,
 White, Andrew  wrote 
 a message of 284 lines which said:

> True. When a resolver gets an NXDOMAIN for, say x.example.com, would
> it better to say the resolver SHOULD drop from cache all descendents
> of x.example.com, or MAY?

The current state of the draft is "approved by IESG". Which means
that, unless a serious bug is discovered, it will be published as a
RFC with only editorial changes (by the RFC editor). I don't think it
is a good idea to reopen a discussion which triggered aleady many
emails.

> It may be computationally expensive to search cache to remove cached
> NXDOMAIN responses below x.example.com, and I see no harm in letting
> those cached entries expire as their TTL runs out.

Which is exactly what the draft is saying:

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply (until the TTL of this cached data
   expires), since this may avoid additional processing when a query is
   received.  Section 6 provides more information about this.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Tue, Sep 27, 2016 at 03:46:16PM -0700,
 Matthew Pounsett  wrote 
 a message of 137 lines which said:

> My rationale is that if foo.bar.example.org were still a valid name

By "valid name", do you mean "something which existed less than $TTL
seconds ago"?

> at the time that the bar.example.org NXDOMAIN response was issued,
> then NXDOMAIN was not the correct response.  It would be
> inappropriate to answer for foo.bar.example.org out of the cache in
> that case.

The DNS is full of these (minor) inconsistencies. As Mark Andrews
said, temporal issues are not new.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Wed, Sep 28, 2016 at 01:42:19PM +,
 Edward Lewis  wrote 
 a message of 84 lines which said:

> As far as DNSSEC, this only works with DNSSEC in place, right?  You
> need the missing span proofs or you are NXDOMAIN'ing entire zones,
> not just entire domains (within a zone).

This is covered in section 8 of the draft (and also in 9, about
Unbound). If people want to spend time on an already-approved draft,
could they at least read it?

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

Re: [DNSOP] Where in a CNAME chain is the QNAME?

[Stephane Bortzmeyer]

On Thu, Sep 29, 2016 at 01:50:05AM -0400,
 Robert Edmonds  wrote 
 a message of 28 lines which said:

> The QNAME is a domain name, but is it an owner name? There is no owned
> record data in the question section (and the entries in the question
> section are not RRs).

You're rigt, of course. Here is the new version:


"QNAME": it is defined in  and
   in , section 4.1.2, but, because  provides a different definition, we repeat the
   original one here: the QNAME is the domain name in the
Question section.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque]

On Wed, Sep 28, 2016 at 2:37 PM, Matthew Pounsett 
wrote:

>
>
> On 28 September 2016 at 10:29, Shumon Huque  wrote:
>
>> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett 
>> wrote:
>>
>>>
>>>
>>> On 28 September 2016 at 06:42, Edward Lewis 
>>> wrote:
>>>
 On 9/27/16, 18:46, "Matthew Pounsett"  wrote:
 >Would it be better then to leave early expiry as an implementation
 choice


 Ultimately, the goal of the draft is to tell a recursive server that if
 it can conclusively deduce existence of a name from what it has cached, it
 is allowed to do so.  Today if the conclusion is positive, that's how it
 is.  The draft proposes to add negative conclusions as well.  Perhaps
 getting into the details of managing what's in the cache, which is not
 covered beyond TTL expiry "rules" is causing the wrapping around the axle.
 (We are talking about the fairly odd example of there being conflicting
 data.)


>>> Taking the view that this is only about interoperability, then I would
>>> say the implementor MAY treat names below the NXDOMAIN response as
>>> nonexistent, and MAY choose to expire those names early... perhaps with a
>>> suggestion that this might be the better choice for data coherence, but
>>> still leave it up to the implementor if they've got a better reason to do
>>> it otherwise.
>>>
>>
>> The draft (by working group consensus) is written as "SHOULD treat names
>> below as non-existent", but "MAY continue to answer existing positive
>> cached entries". I think this managed to cover or at least placate all
>> positions expressed by working group participants leading up to the last
>> call.
>>
>> I'm not sure we'll get new agreement on your proposed revision.
>>
>> I phrased that badly.  Since we were on the subject of cached entries
> already, I assumed that context in my wording.   I should have said "MAY
> treat positively cached names below the NXDOMAIN response as nonexistent,
> and MAY choose to expire those cached names early."  I think that's in
> keeping with the intent of the current text.
>
> There's probably some value in rewording that text though, if it's going
> to cause confusion for implementors.  Maybe invert the text?
>
> # When an interative caching DNS resolver receives a response NXDOMAIN, it
> # SHOULD store it in its negative cache.  It MAY choose to immediately
> remove
> # from its positive cache any previously cached names at or below the
> NXDOMAIN
> # response.  If the cached entries below the NXDOMAIN response are not
> # removed, it MAY choose to continue to answer positively for those names
> # until the cached entries expire.
>
> # The resolver SHOULD treat all other names at or below NXDOMAIN response
> as
> # nonexistant and SHOULD respond negatively to queries for such names.
>
>
I'll wait first for others to weigh in on your proposed rewrite.

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

Re: [DNSOP] ENT and NXDOMAIN: the case of RFC 4035

[Stephane Bortzmeyer]

On Mon, Sep 26, 2016 at 09:31:32AM +0100,
 Ray Bellis  wrote 
 a message of 29 lines which said:

> Roy Arend's response was that the intent was that an ENT response
> requires the same NSEC records as an NXDOMAIN response, but not the same
> RCODE.

Sure, but the title of the section is very misleading.

I tried to write an errata to RFC 4035 but it is complicated because
it requires to find new terminology for the two cases named "No data"
and "Name error".

May be just adding in 3.1.3.2:

   This section only deals with NSEC records to return. Its title does
   not imply that the proper RCODE is
   always "Name error" (NXDOMAIN). For instance, in the case of an
   ENT, the correct RCODE is "No error".
   

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

Re: [DNSOP] Where in a CNAME chain is the QNAME?

[Shumon Huque]

On Thu, Sep 29, 2016 at 1:50 AM, Robert Edmonds  wrote:

> Stephane Bortzmeyer wrote:
> > On Mon, Sep 26, 2016 at 09:04:54AM -0400,
> >  Matt Larson  wrote
> >  a message of 41 lines which said:
> >
> > > I'd venture that more people familiar with the subject matter would
> > > define QNAME as the name in the question section of a DNS message.
> > > (That's my sense of the definition, FWIW.)
> >
> > What about adding this text to the Terminology section of the draft?
> >
> >"QNAME": it is defined in  and
> >in , section 4.1.2, but, because  >target="RFC2308"/> provides a different definition, we repeat the
> >original one here: the QNAME is the owner name of the record in the
> >Question section.
>
> The QNAME is a domain name, but is it an owner name? There is no owned
> record data in the question section (and the entries in the question
> section are not RRs).
>

Yes, I agree. I suggest "the QNAME is the domain name that appears in the
Question section of a DNS message".

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[Ralph Droms]

> On Sep 29, 2016, at 2:56 AM, hellekin  wrote:
> 
>> On 09/29/2016 05:42 AM, Edward Lewis wrote:
>> 
>> The one option you have is ".example", unfortunately (and in sympathy)
>> I don't have a better suggestion.
>> 
> 
> .example is for documentation.  You can use .invalid for "fake private
> TLD", which makes it very clear that it's not a valid TLD. (Sorry for
> the tautology.)
> 
> This list of two-letter TLDs sounds like a good candidate for
> Special-Use Domain Names.  But then, it prompts another question: if,
> e.g., XA-XZ are reserved for future use, how to handle their *removal*
> from the Special-Use Name Registry once they're assigned again?  Which
> prompts another question: if a name enters the Special-Use Name
> Registry, is it parked (for an indefinite amount of time), or is it
> engraved in stone (and won't move from that registry again)?  And can
> the SUNR hold both types of names (parked and final)?

Good question, not (as far as I know) explicitly addressed in RFC 6761.

Because there is no explicit prohibition on removal of a name from the SUNR, 
publication of an appropriate RFC directing IANA to take such an action would 
be the appropriate action, at least. In my opinion.

The question might actually apply to many IANA registries.  Do the 
"Registration Procedures" apply to "unregistration" as well?  I don't know if 
there is any precedent here.

- Ralph

> 
> ==
> hk
> 
> ___
> 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] Where in a CNAME chain is the QNAME?

[Viktor Dukhovni]

On Wed, Sep 28, 2016 at 09:26:38PM +, Stephane Bortzmeyer wrote:

> On Mon, Sep 26, 2016 at 12:33:39PM +0100,
>  Ólafur Guðmundsson  wrote 
>  a message of 148 lines which said:
> 
> > The RCODE applies to the RRSET pointed to by the last CNAME in answer
> > section (or the missing one).
> 
> This specific case was settled in RFC 6604 and I did not intend to
> reopen it. My problem was with the definition of QNAME, not with the
> proper rcode for a chain of CNAME.

By the way, is it the case that CNAMEs in the answer section MUST
appear in their natural chaining order:

A. IN CNAME B.
B. IN CNAME C.
C. IN CNAME D.
D. IN CNAME E.

Which is to say can stub resolvers assume that this is always the
case, or would it prudent to reassemble the list by finding the
CNAME whose owner is the qname, and using the target alias to find
the name CNAME, ... recursively without making assumptions about
the order in which the records appear?

I am writing some code in Haskell that process DNS responses, and
made no assumptions about CNAME ordering in the response, because
Haskell is recursive anyway and finding the starting point rather
than using the first remaining response is easy enough.  So this
code is more robust in the face of unexpected CNAME ordering,
irrelevant CNAME responses that are even part of the chain, ...

What I'm wondering about is whether this is just quaint pedantry,
encouraged by a language that makes it all too easy, or sensibly
defensive programming... :-)

Or put another way, does step "3 a" of Section 4.3.2 of RFC 1034
imply that responses MUST contain any CNAMEs in the typically
expected order?  And, if so, is it then the case that clients
(wether stub or iterative) need make no effort to deal with responses
that are not so ordered?  Should clients take care to deal with
CNAMEs in the answer section that don't form a linear chain (out
of order, or not even possible to re-order as a linear chain).

-- 
Viktor.

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[Viktor Dukhovni]

On Wed, Sep 28, 2016 at 11:27:20PM -, John Levine wrote:

> The codes AA, QM-QZ, XA-XZ, and ZZ are "user assigned" and will never
> be used for countries.  Last year Ed Lewis wrote an I-D proposing that
> XA-XZ be made private use and the rest future use, but as far as I can
> tell it never went anywhere.
> 
> I've been telling people that if they need a fake private TLD for their local
> network they should use one of those since it is exceedingly unlikely
> ever to collide with a real DNS name.  Am I right?

The the ".invalid" TLD is reserved, and has been used for private
naming of domains that are sure to not be real domains either
internally or on the public Internet.  I use:

  address.invalid - added to bare mailbox names in inbound external email.
  bcc.invalid - rewrite domain for (env recipient data) lossless Bcc copies of 
email
  discard.invalid - rewrite domain for addresses whose email gets dropped.
  local.invalid - rewrite domain for local delivery when no real domain is 
"local"
  ...

This is of course different from squatting on a TLD for naming
"real" private domains, and I see little justification for the
latter.  Real 2LDs, 3LDs, ... are cheap, and why not use those
instead?

And for documentation we of course have ".example", "example.net",
...

-- 
Viktor.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[Jaap Akkerhuis]

 Stephane Bortzmeyer writes:

 > 
 > As you can imagine, I disagree.
 > 
 > > Domain names are written left to right.
 > 
 > In english, yes, not in general. They are always written from the
 > beginning to the end (obviously) and the final label can be at the
 > left in a RTL script.

There is no such thing as a language attribute to doamain names.
They are just strings.

jaap

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[Jaap Akkerhuis]

 David Conrad writes:

 > 
 > I'd really like to say yes, but ISO-3166/MA appears to have removed 
 > references
 > to "User Assigned" in their official ISO-3166 two letter code w=
 > webpage.

Only the the standard is normative.

 > I'm trying to understand if they've changed their mind, but no answer yet.

The standard hasn't changed in that reqpect for the last twenty five year of so.

jaap

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