Subject: Re: [dane] Call for consensus for CNAME

From: Peter Koch <[email-masked]>
Date: Mon, 15 Aug 2011 10:45:27 +0200

On Tue, Aug 09, 2011 at 10:44:24PM +0200, Ond??ej Surý wrote:

> I am specifically asking you if you agree with current
> contents of DANE protocol draft, which says that TLSA
> queries and answers follows normal DNS resolution.

i am not convinced that the question is that easy.  Sure
the processing of CNAME RRs (and DNAME and what have you)
ought to be transparent to the application.

However, the problem is one of semantics of the namespace
and was actually initiated back when we started this funny
idea of extending the query type space by prefixing the QNAME.
The reason a CNAME RR cannot have siblings is that the owner
itself is only considered an alias and all data associated with
the node is to be found at the canonical name, i.e., at
the target of the CNAME RR. Now, since the prefixed data
is considered belonging to the (aliased) node, the same logic
should apply - but at the same time even though the protocol
does not allow CNAME siblings, it apparently allows CNAME
descendants.  So it isn't obvious to me why the only
interpretation, given a

	foo.example.org.	CNAME	bar.example.net.

should be that the _443_tcp (or _443._tcp) prefix has
to be applied to foo.example.org. rather than bar.example.net.

And this has nothing to do with wildcards, just plain
protocol semantics.

-Peter

---

From: Tony Finch <[email-masked]>
Date: Mon, 15 Aug 2011 10:46:28 +0100

Peter Koch <[email-masked]> wrote:
>
> The reason a CNAME RR cannot have siblings is that the owner itself is
> only considered an alias and all data associated with the node is to be
> found at the canonical name, i.e., at the target of the CNAME RR. Now,
> since the prefixed data is considered belonging to the (aliased) node,
> the same logic should apply - but at the same time even though the
> protocol does not allow CNAME siblings, it apparently allows CNAME
> descendants.

There is IDNA work which might result in the specification of a new RRtype
(possibly called BNAME) which aliases a name and its descendents, i.e. a
combination of both CNAME and DNAME.

I think it would be more consistent with the layering for DANE clients to
always apply the prefix to the original query name, and leave questions of
how aliasing is implemented (parallel CNAMEs or BNALE etc.) to the DNS
protocol.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, South Rockall: Southerly or southwesterly becoming cyclonic, 5 to 7,
decreasing 4 for a time. Moderate or rough. Showers then rain. Good, becoming
moderate or poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Aug 2011 11:23:30 +0100

> how aliasing is implemented (parallel CNAMEs or BNALE etc.) to the DNS

Clients never get to decide where the prefix is applied. Only the DNS admin
can do that.

All that clients can do is to decide on which places that they will look for
records. So what you are really arguing for is that the client should only
look for the prefix in one place and not two.

All I was proposing was that we respect the fact that the original DNS
architecture did not anticipate prefixed records and that the aliasing
mechanism does not by default provide the semantics that DNS admins are
likely to desire.

Instead people decided to demagogue the issue with claims about changing the
semantics of the DNS. Seems to me that someone got the idea that they
couldn't understand what I was up to and decided there must be a
conspiratorial explanation and decided to go out to block it.

Introducing BNAME might fix the problem, but that will take several years to
deploy and DANE will not have that long a trial. If there is no deployment
in the browsers within a couple of years then those of us who want to do
keying and security policy in the DNS are going to have to start again.

BNAME is not going to address the administration problems related to DNS and
Web site admin.

-- 
Website: http://hallambaker.com/

---

From: Scott Schmit <[email-masked]>
Date: Mon, 15 Aug 2011 10:16:46 -0400

> how aliasing is implemented (parallel CNAMEs or BNALE etc.) to the DNS

I agree that this is the best solution. However, the fate of BNAME is
considerably less clear than you imply. The IDNA/ICANN folks went to
dnsext about making names "the same". In the process of trying to solve
that issue, the dnsext WG came up with a number of different proposals,
of which BNAME was one. However, everything pretty much died when ICANN
was asked to clarify the requirements with their stakeholders (IIRC).

So, BNAME isn't just around the corner--the dnsext WG wants to solve the
"the same problem" (if there is one, and there's some question there)
once, so until they get clear requirements on "sameness", they aren't
going to extend DNS.

That said, I think it's the only way wildcards will work well, because
there's another use case for wildcards we haven't talked about: wildcard
address records. For those, there is nowhere to look for TLSA records
after the A other than the reverse DNS (for each and every address
returned). From my limited poking around, that seems to be at least as 
common as wildcard CNAMEs.

That said, this is probably something better examined through the SSL
observatory data, if the commonness matters.

If the wildcard CNAME usage makes up a high percentage of TLS usage (and
we think that they are likely to use DANE), then we need to prioritize
this use case and consider hacks like clients chasing CNAME chains. But
we'd still have no solution for the wildcard address records.

If not, then what we have is good enough, and will only get better when
BNAME (or one of the other suggestions for resolving the "the same
problem") is deployed.

Lacking data saying otherwise, I'm finding myself in the latter camp
now. So:

+1 to closing #24.

-- 
Scott Schmit

---

From: Tony Finch <[email-masked]>
Date: Mon, 15 Aug 2011 15:24:59 +0100

Scott Schmit <[email-masked]> wrote:

> returned).

Why not just have a parallel wildcard TLSA record? Does it matter that the
record will be returned in reply to more query names than you would
normally expect?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest FitzRoy: Southwesterly 4 or 5, but 6 or 7 at first in far northwest,
becoming variable 3 or 4 later. Rough at first in far northwest, otherwise
moderate. Rain at times. Moderate or good, occasionally poor.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Aug 2011 10:27:33 -0400

> does not allow CNAME siblings, it apparently allows CNAME

Those two sentences are inconsistent.  If CNAME allows subordinate
names lower in the tree than the CNAME, then it simply isn't true that
"the prefixed data is considered belonging to the (aliased) node."
The CNAME points into another tree at that node, but it does not
redirect the descendents.  That's just how the protocol works, and if
people want a different RRTYPE that redirects descendents too, then
they need to address the problems with the BNAME or CNAME+DNAME
proposals on the back burner in dnsext.

> And this has nothing to do with wildcards, just plain

We don't need semantics to solve this issue.  The protocol is clear:
CNAME redirects that node, and nothing else.

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Aug 2011 10:39:28 -0400

> mechanism does not by default provide the semantics that DNS admins are

It seems to me that if the original DNS design had intended that
CNAMEs be terminal (i.e. that things couldn't be lower than them in
the tree), that was a rule that was open to be specified.  It was not
so specified.

If DNS admins want such a feature, they can in fact provide it anyway,
by adding the relevant CNAME lower in the tree.  What exactly is
difficult here?

> semantics of the DNS.

People disagreeing with you are not "demagogues"; they just have a
different opinion.  There is absolutely no justification in any
protocol document I have been able to find for the suggestion that
CNAME redirects names beneath it.  You want it in effect to do so, and
you proposed language that caused clients to behave as though one
particular name beneath a CNAME _is_ redirected.  That does
effectively change the way the protocol works, and therefore I object.

> Seems to me that someone got the idea that they

I understand what you're up to, and I even have some sympathy with the
view that DNS administrators (and web site operators, and so on) might
want things to work this way.  But it's too bad: the protocol isn't
specified that way.  I think changing the way CNAME works for just
this case would be a very bad idea, because it means that one cannot
rely on the CNAME rules being consistent.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Aug 2011 10:43:52 -0400

> once, so until they get clear requirements on "sameness", they aren't

Speaking only for myself but as one of the co-chairs who made that
call, that isn't quite what the reasoning was.

The reasoning was that while there were people who wanted the
additional RRTYPE, there were also several voices against the
additional protocol complexity, partly on the grounds that it wasn't
clear what the problem was, it wasn't clear whether BNAME would
actually solve it, and it wasn't clear what trade-offs we were making.
None of that is any clearer lo these many months later, and therefore
the work hasn't been adopted.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2011 19:53:14 -0000

> If DNS admins want such a feature, they can in fact provide it
> anyway, by adding the relevant CNAME lower in the tree.  What
> exactly is difficult here?

Basically that it bundles different names together to mean one thing,
something the DNS has never done.  The whole point of having multiple
RRTYPEs is so that you can hang different kinds of information on the
same name.  Prefixes are a kludge to work around the lack of indexed
RRYPEs (for SRV) and the extreme pain involved in adding new RRTYPEs
to 50,000 badly written DNS provisioning systems (all the rest of
them.)

On further reflection, I note that this particular situation has been
broken for 15 years, since the invention of SRV, and arguably for over
30 years, since the invention of MX, and nobody's found it urgent
enough to fix.

If BNAME happens, it'll be a fairly effective band-aid for this
particular problem, which is pretty ironic since it's a complete
failure for the problem (making two TLDs equivalent) that it is
intended to solve.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Aug 2011 21:56:33 +0100

> 30 years, since the invention of MX, and nobody's found it urgent

In my view the use of prefixes is what 'broke the DNS model'. A prefix is a
different DNS name that is logically a substitute for a new RR but has
different semantics to a new RR because it is a separate name.

So in my view the 'last try' resolution approach is merely a mechanism that
fixes the breakage introduced by using prefixes to stand for new RRs.

> failure for the problem (making two TLDs equivalent) that it is

That's a bit generous. 'Not even a failure' is probably more accurate. For
BNAME to fail there would have to be a defined problem to be solved.

---

From: Peter Koch <[email-masked]>
Date: Tue, 16 Aug 2011 07:15:32 +0200

> "the prefixed data is considered belonging to the (aliased) node."

it might well look inconsistent, but it isn't, because we're dealing
with two different layers at the same time. Or it is - but that's
exactly the problem.
Prefixes are an attempt to extend the QTYPE space to mitigate the subtyping
problem and the lack of parametrized query types.  This is why both
the SRV specification and the protocol document in section 3 provide an
algorithm for deriving the QNAME from the name the data is associated with.
To that extent, "prefixed names" are inconsistent with regular types.
This brokenness isn't new since DANE, but it's a brokenness - or
irregularity if you'd prefer slightly milder language.

So, when the real name for foo.example.org is bar.example.net, it
would be quite logical to say that all derivatives of foo.example.org
would instead have to be derived from bar.example.net.  However,
we do not have a protocol intrinsic way to implement or even enforce that
since - in contrast to its CNAME logic - the protocol is "prefix agnostic".

> proposals on the back burner in dnsext.

This wouldn't help and BNAME can't fly for various reasons to start with.
And i do not believe theer is a solution because the prefix irregularity is
insoluable. All we can do is acknowledge it and document that while for
a connection to foo.example.org you really ought to connect to bar.example.net
but nonetheless the properties of that connection are still described based
on the alias name foo.example.org.

> CNAME redirects that node, and nothing else.

True, but already uncontested.

-Peter