Subject: [dnsext] If you think "xNAME" doesn't work, what about SHADOW?

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Aug 2010 16:04:20 -0400

Dear colleagues,

We've spilled a lot of 1s and 0s over the question of whether xNAME
will solve enough of the aliasing issues to be worth the cost to the
protocol.  I still don't know where the community is heading on that,
but it appears there are people who feel quite strongly (and with good
arguments) that it is _not_ worth the cost.

This question is explicitly addressed to those participants.  If you
think that some xNAME strategy is too costly for its advantages, it
would be excellent if, in this thread, you stated your reasons for
thinking that the SHADOW approach is or is not worth adopting.  Just
as with the details of (say) BNAME vs. C+DNAME, the particular details
of SHADOW are not too important just now.  The main thrust is "some
provisioning metadata/hints in-protocol and in-zone". 

Thanks,

A (as co-chair, and still hoping to drive to some consensus on what
the charter will be.)

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Aug 2010 17:34:11 -0400

> thinking that the SHADOW approach is or is not worth adopting.  Just

Paul Hoffman helpfully nudged me to provide the reference.  Here we are:

http://tools.ietf.org/html/draft-vixie-dnsext-dnsshadow-00

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 17 Aug 2010 22:42:18 +0100

> provisioning metadata/hints in-protocol and in-zone".

I fall into this group. Without wishing to be irritating, I'm
not sufficiently certain what you mean by SHADOW  to
answer your question (perhaps Message-IDs would help). If by
"hints in protocol" you mean an RR that says "hey you should
be looking over here" that requires application support, I think
that will require too much application layer change.

My current view is that viable ways forward are:
* dumb provisioning hack (copy zones)
* automated provisioning hack (so for instance a zonefile
  format pre-signature a bit like a patch)
* XNAME+exceptions (I'm far from convinced this works, but
  it hasn't yet been run to ground). By this I mean a sort of
  "default value" for a zonefile.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Tue, 17 Aug 2010 22:49:27 +0100

> http://tools.ietf.org/html/draft-vixie-dnsext-dnsshadow-00

That would have been useful 10 seconds earlier :-)

I this approach is worth further investigation (hadn't seen it before)

-- 
Alex Bligh

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Aug 2010 14:52:11 -0700

> provisioning metadata/hints in-protocol and in-zone".
If the BNAME extension is not adopted, the SHADOW approach standardizes 
how IDN related issues might be solved at the registered domain, and 
impact a smaller number of servers.  It might be hard to arrive at a 
general consensus for either SHADOW or BNAME, with the IDN problem not 
being universally experienced.

With respect to BNAME, versus C+DNAME, BNAME provides a resource 
paradigm, which should offer less uncertainty in how cached data is to 
be handled.  It would be nice if neither alias scheme were needed, but 
without the full alias feature, IDN domain names will be less user 
friendly. Many domains already use aliases with CDN services, and this 
has not resulted in dire issues.

Warnings should be included in the BNAME draft regarding use of aliased 
targets in MX, SRV and PTR records.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 19:24:24 -0700

I have read the SHADOW/CLONE draft. I am not sure I like the specific semantics in this draft, but I suspect that adding replication directives in a zone file that show up on the wire is better than just comments in the zone file, and better than an informational BCP about how to write replication programs in Perl^WPython^Ruby^Wthe current scripting flavor of the month.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 11:19:42 +0100

On Tue, 17 Aug 2010, Andrew Sullivan wrote:
> thinking that the SHADOW approach is or is not worth adopting.

SHADOW is simpler from the protocol semantics point of view - CNAME and
DNAME have proven to be difficult in the past and BNAME and C+DNAME look
like they are as well, especially WRT DNSSEC.

SHADOW is easier to deploy since the only code changes necessary are at
the DNS hosting providers of the cloned domains.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
DOGGER FISHER GERMAN BIGHT HUMBER THAMES DOVER WIGHT PORTLAND CYCLONIC 6 TO
GALE 8 IN NORTH FISHER AT FIRST, OTHERWISE SOUTHWESTERLY BACKING SOUTHERLY, 4
OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.

---

From: John Levine <[email-masked]>
Date: 19 Aug 2010 18:10:05 -0000

I like the idea of SHADOW, although I hate the proposed implementation.

One good thing about it is that it's easy to roll out incrementally.  All
you need is a group of servers that share zone info and understand some
version of SHADOW.  It's easy to do experiments, since its effects should
be transparent outside that server group, and multiple incompatible
experiments are easy to do so long as server groups don't overlap.

Another good thing about it is that it admits that making two zones
"the same" is more than mechanically copying one subtree to another,
and could involve both modifications that SHADOW can describe and
modifications that have to be described some other way.

The proposed implementation is hopeless, since the assumption that
secondaries work from copies of a master's zone file is usually wrong.
I'd want the SHADOW info to be in the zone itself, so it gets copied
using AXFR or RSYNC or whatever the secondaries use.

Here's a sketch, no doubt with both syntactic and semantic bugs.

; Make the zone at S a copy of the zone at A
A  SHADOW COPY S

; When copying records at name N of type RR, copy names within
; the record literally.  Intended for MX, SRV, etc.
N  SHADOW LIT RR

; When copying records at name N of type RR, use local policy to
; modify the copy, fail if no local policy exists.  Intended for
; A records pointing to HTTPS servers, etc.  The local policy
; language is NOT specified, per Paul H's note about perl, ruby, etc.
N  SHADOW LOCAL RR

It would also be nice if there were some way to propagate shadow info
to subzones, but that breaks the useful characteristic that you know
what servers will be interpreting your SHADOW instructions.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 19 Aug 2010 18:35:26 +0000

> Date: 19 Aug 2010 18:10:05 -0000
> From: John Levine <[email-masked]>
> 

it depends on axfr.  the thing it isn't compatible with is the various
private multimaster implementations.  there's no call for zone file access.

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2010 15:00:26 -0400

> private multimaster implementations.  there's no call for zone file access.

I must be missing something.  If I get a copy of the zone by AXFR, how can 
I tell whether a name was fully or partially qualified in the master file 
so I know whether to copy it or shadow it?

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 19 Aug 2010 19:07:55 +0000

> Date: 19 Aug 2010 15:00:26 -0400
> From: "John R. Levine" <[email-masked]>
> 

this is an open issue.  see 4.1.

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2010 16:48:22 -0400

> this is an open issue.  see 4.1.

Right, hence my suggested hack to resolve it.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 19 Aug 2010 23:42:00 +0000

> Date: 19 Aug 2010 16:48:22 -0400

do you feel that the proposal is worthless without such a resolution?

from my point of view, a transformation that only works on owner names is
adequate, and a transformation that works on tail-replace of both owner
names and target names would also be acceptable.  i'm not in love with 
the idea of a knob for this kind of per-name rewrite capability on day 1.

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2010 19:59:18 -0400

> the idea of a knob for this kind of per-name rewrite capability on day 1.

It seems to me that if it doesn't offer some way to handle the exceptions 
we all know we need, it's basically the same as DNAME, where the name 
server generates an exact clone of a zone under a different name.  Fixing 
the names of mail servers actually isn't all that important since mail 
servers don't need to have unique names.  Adjusting A records for HTTPS 
servers is essential because people who run them aren't going to run out 
and get upgraded server software and buy combined multi-name certs just 
because we tell them to.  (The places where I buy my certs do not, as far 
as I can tell, even offer them.)

I'm certainly not arguing that my list of hacks is ideal, but for SHADOW 
to be useful, it needs some way to solve the problems that now can only be 
dealt with by local provisioning hacks.  All of the prior approaches seem 
to me to fail catastrophically in the sense that even if they do 95% of 
what you want them to do, you still can't use them because they don't 
provide any way to do the other 5%.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Aug 2010 01:20:21 +0100

On Fri, 19 Aug 2010, John R. Levine wrote:
>
> It seems to me that if it doesn't offer some way to handle the exceptions we
> all know we need, it's basically the same as DNAME, where the name server
> generates an exact clone of a zone under a different name.

No, because DNAME requires manual cloning of the zone apex, and extra
DNSSEC management, and it introduces synthetic CNAME RRs.

But I agree that IE6's lack of SNI support and lack of CA support for
useful x.509 features are problems.

> I'm certainly not arguing that my list of hacks is ideal, but for SHADOW to be
> useful, it needs some way to solve the problems that now can only be dealt
> with by local provisioning hacks.

Does it need to solve these problems? BNAME does not and SHADOW is still
simpler.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FITZROY: VARIABLE 4 IN SOUTHEAST, AND FOR A TIME IN FAR NORTHWEST, OTHERWISE
SOUTHWESTERLY 5 TO 7. MODERATE OR ROUGH. RAIN. GOOD, OCCASIONALLY POOR.

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2010 21:55:12 -0400

> Does it need to solve these problems? BNAME does not and SHADOW is still

I can only speak for myself, but I'm not going to use BNAME or XNAME or 
SHADOW if it can't generate the records I need in the shadow zone.  That 
can't be unusual.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Aug 2010 00:19:40 -0300

> SHADOW if it can't generate the records I need in the shadow zone.  That

It might be helpful to dissect what a typical set of zones would need to
look like, and/or what elements underneath a zone would need to exist and/or
differ based on the parent name.

I'll take a stab at it, and see if it's possible to accommodate those needs
while still benefiting from the strengths of BNAME/xNAME/SHADOW...

zone a.b.example.com
aka c.d.example.com
aka e.b.example.com
aka f.example.com
(the usual apex stuff - SOA bits, NS, plus DNSKEYs, perhaps MX records)
x   A  10.20.30.40 ; HTTP server for all names x.*
y  NS my.own.ip.address ; zone cuts for all names y.*

zone y.a.b.example.com
(standard apex stuff)
  A  10.20.30.41 ; HTTPS server for only this y

zone y.c.d.example.com
(standard apex stuff)
  A  10.20.30.42 ; HTTPS server for only this y

zone y.e.b.example.com
(standard apex stuff)
  A  10.20.30.43 ; HTTPS server for only this y

zone y.f.example.com
(standard apex stuff)
  A  10.20.30.44 ; HTTPS server for only this y

I think this scales reasonably well, and is easy enough to build tools for,
automate, document, and maintain.
Think of the first portion as kind of a template, and the remainders as
overlays to that template.

Does this example match what you believe the usual needs of folks?
Do you think this would be something you would/could/would want to use?

Thanks,
Brian

---

From: Paul Vixie <[email-masked]>
Date: Fri, 20 Aug 2010 03:40:54 +0000

> Date: 19 Aug 2010 21:55:12 -0400

ok, let's deal with open issue 4.1 if this approach is generally wanted.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 20 Aug 2010 07:32:02 +0000

* Paul Hoffman:

> I have read the SHADOW/CLONE draft. I am not sure I like the
> specific semantics in this draft, but I suspect that adding
> replication directives in a zone file that show up on the wire is
> better than just comments in the zone file,

As far as I understand it, shadowing a zone (that is, the rewriting
required on the master) has to work on the textual representation of
the zone, not the wire format ("Content of a Shadow zone will be
generated by parsing the Amber zone's master file using a different
default $ORIGIN.").  A good way around that does not seem to exist.
Perhaps you could use a magic TLD or SLD under ARPA, but that's
probably not "good", either.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Fri, 20 Aug 2010 07:40:01 +0000

> arguments) that it is _not_ worth the cost.

SHADOW actually works as advertized and creates truly equivalent names
(as far as I can tell).

But as I've tried to explain before, it is impossible to solve the
IDNA woes with DNS tweaks because IDNA-aware applications generally
lack access to DNS (think email submission), distinct IDNA versions
cannot be converted to each other, and an intermediate relay will not
always be able to translate a name to an IDNA version which is
expected by the recipient server.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 20 Aug 2010 14:21:40 +0000

> From: Florian Weimer <[email-masked]>
> Date: Fri, 20 Aug 2010 07:32:02 +0000
> 
> default $ORIGIN.").  

yeah, that's weak.  and it's noted in the open issues.

> A good way around that does not seem to exist.  Perhaps you could use a
> magic TLD or SLD under ARPA, but that's probably not "good", either.

i agree that there's no good way.  but paul hoffman's right in my opin:

> ... but I suspect that adding replication directives in a zone file that
> show up on the wire is better than just comments in the zone file, ...

in other words the transformation on the master server should probably be
done on FQDN's after all of the zone parsing ($ORIGIN etc) has been done,
and should therefore be a tail-replace (.amber -> .shadow) everywhere,
including both the owner and target names.  because we need to be able to
do this transformation even when the zone data source is a database rather
than a text file, the exceptions (like, i really want this target name to
be what is, and not get the tail-replace) would have to be expressed via
some metadata (which a database source could also have) rather than via
"zone file" directives (which only a zone file source would have.)  john
levine suggested:

	A  SHADOW COPY S
	...
	N  SHADOW LIT RR
	...
	N  SHADOW LOCAL RR

which is not my preferred approach (syntactically or semantically) but does
demonstrate the approach i'm describing (in-zone data, not file directives.)

in any case we can treat this as a work item if we adopt this approach.  at
the moment it's not worth our time or this mailing list's bandwidth to try
to fix this stuff, since the WG hasn't reached consensus on the basic SHADOW
approach.  if we do reach that consensus, nothing i've heard on this thread
would be a showstopper as far as fixing it before it reaches the RFC editor.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 20 Aug 2010 14:27:09 +0000

> Date: Fri, 20 Aug 2010 07:40:01 +0000
> 
> But as I've tried to explain before, it is impossible to solve the IDNA
> woes with DNS tweaks because IDNA-aware applications generally lack
> access to DNS (think email submission), distinct IDNA versions cannot be
> converted to each other, and an intermediate relay will not always be
> able to translate a name to an IDNA version which is expected by the
> recipient server.

if we need to solve IDNA woes with DNS tweaks, then it is possible, as long
as we're willing to require that IDN-aware applications be changed.  i'm
thinking we could add some more backpointers (similar to what PTR does, but
without some of PTR's limitations) and teach IDN-aware apps and servers how
to query for the new backpointers.  "tell me all the other ways this same
name can be reached in DNS" would be a new feature, which IDN-aware apps 
would use to solve their DNS-related woes.

i agree that it's impossible to solve these IDN-related woes transparently
and with only DNS-tweaks and no application changes.  we need to get the
whole WG to consensus on that point so that we can all move forward on that
shared basis.  and if the IDN community isn't then willing to use new DNS
features to solve their woes, then we should stop talking about adding new
DNS features for IDN.  but i don't think the IDN community will speak with
one voice on that matter.  and i don't think BNAME and SHADOW are limited to
IDN in their usefulness.  i'd like both, with or without IDN as a motivator.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Aug 2010 12:24:03 -0400

> ok, let's deal with open issue 4.1 if this approach is generally wanted.

Before tackling that, I'd really like to see the list of problems in
the problem statement document (that Suzanne is currently editing)
updated.  Please send text on what problems there are here.

W

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Aug 2010 10:22:22 -0700

>updated.  Please send text on what problems there are here.

Assuming that we are still talking about draft-yao-dnsext-identical-resolution, which is at -01, I am unsure what you are asking for. The document is a list of use cases (section 2) and proposals (section 3). The document itself seems to describe the problems that DNS users have well. Are you asking for a list of problems that zone owners would have? If so, are they the apex owners, the subdomain owners, or ...?

--Paul Hoffman, Director
--VPN Consortium

---

From: John Levine <[email-masked]>
Date: 20 Aug 2010 17:41:28 -0000

>updated.  Please send text on what problems there are here.

I see two somewhat different problems we might be trying to solve.
(Well, three if you accept "whatever xNAME does" as the problem.)

Small version) Automate as much of the process of making two domains
 "the same" in the DNS as we can, while not getting in the way of the
 scripts or manual process people use to do the rest of the work.

Large version) Small version plus sufficient hooks in the DNS that an
  application can auto-configure itself to handle the aliases and
  whatever involved in making names in other zones "the same" as a
  name it's already been set up to handle.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 20 Aug 2010 14:21:25 -0400

On Fri, Aug 20, 2010 at 10:22:22AM -0700, Paul Hoffman wrote:
> 
> Assuming that we are still talking about
> draft-yao-dnsext-identical-resolution, which is at -01, I am unsure
> what you are asking for. The document is a list of use cases

Yes, I was.

> (section 2) and proposals (section 3). The document itself seems to
> describe the problems that DNS users have well. Are you asking for a
> list of problems that zone owners would have? If so, are they the
> apex owners, the subdomain owners, or ...?

Well, presumably the problems of zone owners are in some other sense a
problem for DNS users, no?  But yeah, I think we probably need to
address issues for zone owners.  And while it's apex owners, it's
_every_ apex owner, I'd like to think.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Aug 2010 11:46:22 -0700

>_every_ apex owner, I'd like to think.

Yes, it is every apex owner. The case of <some-idn>.com is just as interesting as <some-idn>.<some-other-idn>.

I'll +1 John's proposals:

>  name it's already been set up to handle.

I am skeptical about whether the "large version" is even possible, but there are a lot of clever people and highly motivated DNS operators on this list.

--Paul Hoffman, Director
--VPN Consortium

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 20 Aug 2010 21:55:53 +0000

> apex owners, the subdomain owners, or ...?

As editor of the document I've come to the conclusion that the next
rev needs an explicit "requirements" section, to gather the ones so
far identified and help further with digging out the hidden
assumptions we seem to be excavating in recent discussion.

In fact....Broadly speaking, I think the next rev needs:

1. More detail on use cases, IDN-related an otherwise. We have basic
descriptions of two IDN-related cases. We need more. I have some
contributions on a couple, but more text is welcome. What we most need
is detailed descriptions of the desired behavior with regards to what
applications see, what caches see, and what users can reasonably
assume.

2. More detail on identified limitations on both problems and
solutions.

3. An expanded security considerations section, including not only
more discussion of DNSSEC but the SSL issues raised and psosibly
others as well.

4. An explicit "requirements" section, including those proposed in
Anaheim and the implicit ones that have been emerging in the list
discussion since Maastricht.

5. An overview of the complexity/tradeoffs analyses we've been doing
informally here, with an eye towards explaining to people who are not
DNS protocol experts what the side effects are to even apparently
simple changes to the DNS.

Text/suggestions welcome.

Best,
Suzanne

---

From: John Levine <[email-masked]>
Date: 20 Aug 2010 22:08:14 -0000

>I am skeptical about whether the "large version" is even possible, but
>there are a lot of clever people and highly motivated DNS operators on
>this list.

In case it wasn't clear, I wasn't anticipating any way to make
multiple names work transparently to applications.  The idea was that
an application configured for one name could query the DNS to find out
what other names are "the same" (shadowed or whatever) so it can then
look and see what DNS records the other names have and adjust its
configuration appropriately.

R's,
John

---

From: Ted Hardie <[email-masked]>
Date: Fri, 20 Aug 2010 15:51:12 -0700

On Fri, Aug 20, 2010 at 3:08 PM, John Levine <[email-masked]> wrot
> configuration appropriately.

I'm a bit concerned about "look and see what DNS records the other names
have".  CNAME works because it functions to identify the one name at which
the RRs reside.  I think anything we come up with should have that
same property--there
should be one entry where the data is,  whatever mechanisms are necessary
to point to that entry in a safe and sane manner.

The example I've used privately is a company that wants to support
both British and American spellings of its domain, humor/humour.example .
If one spelling is canonical, then solutions in this space work to
give something equivalent to
a domain-inclusive CNAME wildcard.  They're the moral equivalent of
 "for i in humor.example CNAME $i.humour.example" with humor.example
mapped to humour.example
as well.  This works, though APIs may need to pass up the equivalent of
"The DNS lead you to someplace new".

But if I want to allow subdomains to put the RRs either place, things
get tricky. To allow
RRs at british.humour.example (with a pointer from british.humor.example) but
RRs at american.humor.example (with a pointer from
american.humour.example), I think
I've ruled out an architecturally clean domain-level mechanism used at
the humor/humour.example level.
It gets particularly bad if I want to have the client check both
american.humour.example (where the
NS records might be configured) but also check american.humor.example
for other records (like MX) and
then act as if they both applied equally.

To put this another way, if the semantics of this are
"$variable.humor.example is a valid alternate to
$variable.humour.example, please check both for any RR you're
interested in", I think the apps
confusion will overwhelm any benefit.

So folks realize that this is not just a pure hypothetical, consider the case of
.中国 and .中國.  If one is canonical and the other a variant, we have the
CNAME-on-steroids case.  But if the domain administrators wish to allow
香港。中國 (Hong Kong, China, using the complex characters in use in Hong Kong)
to be primary but prefer 北京。中国 (Beijing, China, using the simplified
characters in use in Beijing),
to be primary, a domain-level solution at the .中国／中國 level may
actually be out of the question.
Which is an alias and which the target will vary below that point.

I fear that my own muddled thinking on these examples may hinder the
question, so I'll try to repeat it
succinctly:  "Can we agree that any solution can rely on there being a
single entry at which
all RRs other than pointers are found?"

regards,

Ted Hardie

---

From: "John R. Levine" <[email-masked]>
Date: 20 Aug 2010 19:18:03 -0400

> have".

I was thinking of something like this:

foo.example  A 12.34.56.78    ; normal record for web server or whatever
              THESAME  bar.example
              THESAME  baz.example

Nothing sees THESAME records unless they ask for them, so they're just for 
applications that know how to use them to autoconfigure.  There still has 
to be A records at bar.example and baz.example, whether from shadow or 
something else.

>  "Can we agree that any solution can rely on there being a
> single entry at which all RRs other than pointers are found?"

That was my assumption, but it's a good question.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sun, 22 Aug 2010 13:32:37 +0000

> Date: Fri, 20 Aug 2010 15:51:12 -0700
> From: Ted Hardie <[email-masked]>
> 
> have".  CNAME works because it functions to identify the one name at
> which the RRs reside.  I think anything we come up with should have that
> same property--there should be one entry where the data is, whatever
> mechanisms are necessary to point to that entry in a safe and sane
> manner.

disagreed.

we don't have that today, and we don't need it anyway.  gethostbyname() can
return many addresses and many aliases, and gethostbyaddr() can do likewise,
and someone who wants to know _all_ the names by which a host is reachable
has to call both (like getruserok() does.)

> $variable.humour.example, please check both for any RR you're interested
> in", I think the apps confusion will overwhelm any benefit.

agreed.

> So folks realize that this is not just a pure hypothetical, consider the
> case of .中国 and .中國.  If one is canonical and the other a variant, we
> have the CNAME-on-steroids case.  But if the domain administrators wish
> to allow香港。中國 (Hong Kong, China, using the complex characters in use
> in Hong Kong) to be primary but prefer 北京。中国 (Beijing, China, using
> the simplified characters in use in Beijing), to be primary, a
> domain-level solution at the .中国／中國 level may actually be out of the
> question.  Which is an alias and which the target will vary below that
> point.

yes.  but we're presuming a new RR or new placement of existing RR's as a
way for IDN-aware apps to do extra work to get some extra functionality.

> question, so I'll try to repeat it succinctly: "Can we agree that any
> solution can rely on there being a single entry at which all RRs other
> than pointers are found?"

i don't agree on this, since i know how A/AAAA/PTR clouds work today.

---

From: Ted Hardie <[email-masked]>
Date: Sun, 22 Aug 2010 14:38:05 -0700

> has to call both (like getruserok() does.)

The way the man page for gethostbyname and gethostbyaddr runs, though,
puts the structure this way:

 struct  hostent {
             char    *h_name;        /* official name of host */
             char    **h_aliases;    /* alias list */
             int     h_addrtype;     /* host address type */
             int     h_length;       /* length of address */
             char    **h_addr_list;  /* list of addresses from name server */
     };
     #define h_addr  h_addr_list[0]  /* address, for backward compatibility */

     The members of this structure are:

     h_name       Official name of the host.

     h_aliases    A NULL-terminated array of alternate names for the host.

     h_addrtype   The type of address being returned; usually AF_INET.

     h_length     The length, in bytes, of the address.

     h_addr_list  A NULL-terminated array of network addresses for the host.
                  Host addresses are returned in network byte order.
     h_addr       The first address in h_addr_list; this is for
backward compatibility.

This actually tends to reinforce the common view that there is one "real"
name and a list of aliases.  The number of addresses (and the address
families they fall in) is actually kind of a different question than
what I meant
to raise). To try to refocus this, would you expect anyone using gethostbyaddr()
to find the names of a host to look up further RRs at the h_name or one of
the names found in the h_aliases array?

> i don't agree on this, since i know how A/AAAA/PTR clouds work today.

I think cname+bname actually falls into the category I'm trying to lay
out, and the origin and shadow zones of the dnsshadow draft does as
well.  Do you see cases in either of these where humor.example and
humour.example
are related but the names below them have RRs in both?  That is where
a query to geek.humor.example must be repeated to geek.humour.example
in order to collect a full set of the relevant RRs?

regards,

Ted Hardie

---

From: John Levine <[email-masked]>
Date: 23 Aug 2010 02:57:47 -0000

>> than pointers are found?"

Nope.  (That is, I agree with Paul.)  Think of the well-worn HTTPS
example, where names that are "the same" nonetheless have different IP
addresses.*

The more I think about it, the more I think we need to separate the
declaration "A and B are the same" from whatever other RRs A and B
happen to have.  My goal is to provide enough hints in the DNS that an
application server that has been configured to handle some set of
names can find out all the other names that are "the same" and
automatically handle those, too.  I'm not too worried if there are
ways that people can screw up the hints; I'm more concerned that there
be some way to publish adequate hints if you, or more likely your DNS
maintenance scripts, know what they're doing.

I realize that there might be a combinational explosion if there are
aliases at multiple levels of naming, but if there are 10,000
different ways to spell some resource's name, I'd sure rather there be
some way for the servers to discover them and configure themselves.
If a web server has 10,000 different names for the same web page,
that's not necessarily a problem, so long as we don't have to type
them all into httpd.conf.

R's,
John

* - With sufficient upgrades to every web server and browser in the
world we can force this particular application to work with CNAMEs,
and a single A record, but it's an example.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 07:43:58 +0200

On 23 aug 2010, at 04.57, John Levine wrote:

> happen to have.

The question is not whether A and B are the same. It is "Resolving A and B leads to the same response".

But I agree with Ted that it would be very good if this problem is solved by having B be the canonical name, and A refer to it. And then have the referral from A to B in such a way that application layer do know that is what should happen. Applications then part from getting the same response when resolving A and B also get to know that B is the canonical name. And because of that B is what is to be used on the application layer. For example the HOST header of http.

I do not see any need though for "given B, let me know all A that refer to it as the canonical name". Specifically as this referral might happen on multiple times on each level in the name hierarchy which implies the number of A will explode exponentially.

   Patrik

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 23 Aug 2010 14:12:47 +0800

----- Original Message ----- 
From: "Patrik Fältström" <[email-masked]>
To: "John Levine" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 23, 2010 1:43 PM
Subject: Re: [dnsext] Re: Problem statement additions

>The question is not whether A and B are the same. It is "Resolving A and B leads to the same response".

+1.
excellent point.

Jiankang Yao

---

From: Alex Bligh <[email-masked]>
Date: Mon, 23 Aug 2010 09:01:06 +0100

> B leads to the same response".

Is it? I thought we already had examples where this is counterproductive
in making 2 names "act the same".

If the idea is to ensure at all times identical resolution, xNAME works
perfectly well. But I don't think that /is/ the problem (or at least
is not a useful problem to solve).

-- 
Alex Bligh

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 23 Aug 2010 11:13:17 +0000

On Mon, Aug 23, 2010 at 07:43:58AM +0200, Patrik F?ltstr?m wrote:
> 
> I do not see any need though for "given B, let me know all A that
> refer to it as the canonical name". Specifically as this referral
> might happen on multiple times on each level in the name hierarchy
> which implies the number of A will explode exponentially.

This raises the question of what scalability assumptions are being
made in this discussion.

Exponential explosions of anything are clearly to be avoided if at all
possible. At the same time, however, my sense so far for what people
will reasonably want to do in terms of counts or chains of things they
want to be "the same" will be in small numbers, either at a single
level or recursing down multiple subdomains. 

Does it follow that "unbounded scalability" should be an explicit
non-goal for this endeavor? What kind of limits sound sensible?

thx,
Suzanne

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Sat, 21 Aug 2010 00:04:48 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

On 20 aug 2010, at 19:25, Paul Hoffman <[email-masked]> wrote:

> The document is a list of use cases (section 2) and proposals (section 3). The document itself seems to describe the problems that DNS users have well

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Mon, 23 Aug 2010 08:20:11 +0200

>> The question is not whether A and B are the same. It is "Resolving A and B leads to the same response".

Let me change my own wording.

"leads to the same result" (so that applications can do "the right thing", regarding user experience). The responses (from DNS) might be different.

   Patrik

---

From: "John R. Levine" <[email-masked]>
Date: 23 Aug 2010 08:00:11 -0400

> "leads to the same result" (so that applications can do "the right 
> thing", regarding user experience). The responses (from DNS) might be 
> different.

Sure.  That's what I meant by "A and B are the same."  I gather that we 
agree that it does NOT mean that there is a simple mechanical relationship 
between the two sets of RRs.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 14:18:50 +0200

> non-goal for this endeavor? What kind of limits sound sensible?

I do not think we talk about "unbounded scalability", but if we have a delegation between two zones, and we have such "aliases" in both the parent and child zone, then we even at that point in time start to get problems keeping track of all permutations.

If we instead in the parent zone can have pointer(s) from all aliases to whatever the canonical name is, and then repeat that at each level in the namespace, then the number of permutations do not increase and we get a linear growth of "stuff" in the DNS. I think we already agreed to that (i.e. something that works similar to DNAME).

But, we still get the same explosion in the application layer, for example the HTTP HOST header, if not the application layer get some "hint" of which one of multiple possible domain names is the canonical one.

Yes, of course the application might have all combinations of characters enumerated, but...well...it would be "nice" if the application layer get to know which hostname is the canonical one.

   Patrik

---

From: "John R. Levine" <[email-masked]>
Date: 23 Aug 2010 09:18:04 -0400

> I do not see any need though for "given B, let me know all A that refer 
> to it as the canonical name".

We seem to have two different models of auto-configuration here, which 
I'll call predictive and reactive.

In the predictive model, a server knows that it's been configured for A, 
looks around to find all the aliases for A (call them B through Z), adds 
them to its configuration, then doesn't worry about aliases any more, at 
least not until the next time it checks to see if the list of aliases has 
changed.

In the reactive model, a server does nothing special until it sees a name 
show up for name Q, then in real time looks up Q, finds that it's an alias 
for A, and then proceeds more or less as though the request had been for 
A.

The reactive model certainly has nicer scaling properties, since the 
application doesn't have to preconfigure or even know all of the names it 
might have to handle.  Really, the only flaw I can see with it is that IT 
DOESN'T WORK.

Please consider, once again, the hoary HTTPS example with different names 
on different IPs.  The server doesn't know what IPs to listen to until it 
knows what names it has to handle.  Having a certain amount of experience 
with mail servers, I wouldn't want to run a server that needed to figure 
out on the fly whether each random incoming message is for a domain it's 
supposed to handle.

We could explicitly say that we're only going to handle situations that 
work with the reactive model, but if that were adequate, CNAMEs would have 
solved all our problems.

I'm not opposed to supporting the reactive model, but if you want to solve 
the actual problems that people have making multiple names "the same", you 
have to provide some way for an applications to enumerate the names they 
handle so they can configure themselves appropriately.  The enumeration 
doesn't have to be silly, we can probably figure out some way to encode 
wildcards so the DNS doesn't have to expand every cross-product, but you 
can't avoid it.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 15:40:08 +0200

On 23 aug 2010, at 15.18, John R. Levine wrote:

> We seem to have two different models of auto-configuration here, which I'll call predictive and reactive.

I am not talking about configuration at all.

> In the predictive model, a server knows that it's been configured for A, looks around to find all the aliases for A (call them B through Z), adds them to its configuration, then doesn't worry about aliases any more, at least not until the next time it checks to see if the list of aliases has changed.
> 
> In the reactive model, a server does nothing special until it sees a name show up for name Q, then in real time looks up Q, finds that it's an alias for A, and then proceeds more or less as though the request had been for A.

No, a client is to use B for a service, finds it is an alias for A and uses A when communicating with the server. The server only knows about A, not B. There is no configuration "on the fly" going on.

> We could explicitly say that we're only going to handle situations that work with the reactive model, but if that were adequate, CNAMEs would have solved all our problems.

CNAME would have worked for the HTTPS aliasing problem if we did not have the issue with "no other records should exist with the same owner", and I think maybe CNAME+DNAME could work.

> I'm not opposed to supporting the reactive model, but if you want to solve the actual problems that people have making multiple names "the same", you have to provide some way for an applications to enumerate the names they handle so they can configure themselves appropriately.

They only have to know about the canonical domain names clients will use when communicating with them. Not the other aliases.

> The enumeration doesn't have to be silly, we can probably figure out some way to encode wildcards so the DNS doesn't have to expand every cross-product, but you can't avoid it.

   Patrik

---

From: "John R. Levine" <[email-masked]>
Date: 23 Aug 2010 09:50:54 -0400

> No, a client is to use B for a service, finds it is an alias for A and 
> uses A when communicating with the server. The server only knows about 
> A, not B. There is no configuration "on the fly" going on.

Hmmn, so we upgrade billions of client programs rather than millions of 
servers.  I suppose.

I'm also thinking about the security model in which a client says "the 
user asked for B but I'm pretending he asked for A".  At the very least, 
the server better verify that's an alias it approves of.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 16:55:32 +0200

On 23 aug 2010, at 15.50, John R. Levine wrote:

> Hmmn, so we upgrade billions of client programs rather than millions of servers.  I suppose.

Billions?

Yes, I do talk about upgrading tons of stuff.

You and I have had this discussion before on where to upgrade things, and how to optimize. And we do have different idea on what is the best.

I am really trying to see a long term solution here. Where the number of "aliases" is large. And for a client to know what the canonical name is would really help many application layer situations. Just look at the number of HTTP redirect that is currently happening that instead could have been just DNS lookups.

Or the TLS situation that you mentions.

But, also, I wanted to list requirements. Wishes. X-mas presents I want to have. When we have a complete list of those we can compare the various proposals, and we pick the proposal that we think is the best. Maybe none of the proposals do implement what I am asking for? I do not know yet.

We need the list of requirements. And having a "this is the canonical name" that works also across delegation points, would be extremely helpful for applications.

> I'm also thinking about the security model in which a client says "the user asked for B but I'm pretending he asked for A".  At the very least, the server better verify that's an alias it approves of.

Yes, I call that DNSSEC.

   Patrik

---

From: Alex Bligh <[email-masked]>
Date: Mon, 23 Aug 2010 16:12:16 +0100

--On 23 August 2010 09:18:04 -0400 "John R. Levine" <[email-masked]> wrote:

> show up for name Q, then in real time looks up Q, finds that it's an
> alias for A, and then proceeds more or less as though the request had
> been for A.

Is that always possible? I presume not, given the https example, where
best case may demand adding a new alternative name to an existing cert
(which may require an offline private key to be typed), and worse
case involves registering a new cert.

-- 
Alex Bligh

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Aug 2010 08:33:27 -0700

At 11:13 AM +0000 8/23/10, Suzanne Woolf wrote:
>non-goal for this endeavor?

No, because...

>What kind of limits sound sensible?

...is impossible to define. Obviously, "unbounded scalability" is not desired, but making it an explicit non-goal means that everyone's definition of that, weighed against the value, must be the same. It will never be.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Aug 2010 09:57:58 -0700

> The question is not whether A and B are the same. It is "Resolving A and B leads to the same response".

This is a much better formulation than mine, thanks.  What I'm trying
to avoid in part is the situation
where you must query both A and B to get a full set of responses; this
implies that you must know
about both A and B to get one.  If we start from your formulation, a
client that queries either A or B
gets the same (full) result.  It doesn't need to know about the other.

I also think part of what should be returned is "X is the canonical
name", so that applications can use this
data to construct things like HOST strings in HTTP (and test for the
presence of the string in certs,
etc.).  This doesn't eliminate the problem entirely, but it provides
at least one clear path through the
thicket of permutations--it creates a normalization path, in other words.

regards,

Ted

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Aug 2010 13:20:45 -0400

No hat

> > I'm also thinking about the security model in which a client says "the user asked for B but I'm pretending he asked for A".  At the very least, the server better verify that's an alias it approve…

But without a record in A's zone to say, "Yep, B really does point to
me," you can't actually prove that A and B are "the same" as far as
A's operator is concerned, right?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 19:34:11 +0200

> A's operator is concerned, right?

No. Or I must misunderstand what you ask for.

We have tons of one-way-pointers already today. Like the A and PTR records. And CNAME. This is not worse.

What you want to know is that both A and B authoritatively resolve to the same data, so you must be able to trust each step in the resolution process:

A->data
B->A->data

For this to work, one sign "A->data".

And one sign "B->A".

Then resolution of A->data and B->A->data can be secured.

I do not feel A have to "approve" B is referring to A. It is the B->A pointer that should be secured. Just like PTRs, or A records or whatever. The world is full of one way pointers.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Aug 2010 13:40:44 -0400

No hat.

> We have tons of one-way-pointers already today. Like the A and PTR records. And CNAME. This is not worse.

Well, A and PTR are sort of different from this case.  But CNAME isn't, agreed.

> What you want to know is that both A and B authoritatively resolve to the same data, so you must be able to trust each step in the resolution process:

No, _one_ of the things you want to know is that both A and B
authoritatively resolve to the same data (waving madly away just what
"the same", "data", and so on means).  I think what John was arguing
was that knowing that much is perhaps enough in some cases, but not
others.  

I can create my.searchy.example.com today, with a CNAME to
www.google.com, and sign the CNAME record.  It'll validate.  But that
gives the user no assurance whatever that my name is an "authentic"
interface to Google.  I think it's cases like this that John was
worrying about.

> I do not feel A have to "approve" B is referring to A.

Why not?  (I'm not saying you're wrong, but I've heard arguments more
than once in this thread for having such a rule, and it doesn't strike
me as obviously wrong.)  Your argument here ("just like PTRs, CNAMEs,
&c.) isn't enough: that's just an appeal to tradition.  If we have
that avenue open to us, then we can dismiss all this aliasing work as
needless because we've never done it before.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 19:43:59 +0200

> needless because we've never done it before.

Because we do not do it for the domain name -> IP address mapping.

   Patrik

---

From: Alex Bligh <[email-masked]>
Date: Mon, 23 Aug 2010 18:58:07 +0100

--On 23 August 2010 19:34:11 +0200 Patrik Fältström <[email-masked]> wrote:

> What you want to know is that both A and B authoritatively resolve to the
> same data, so you must be able to trust each step in the resolution
> process:
>
> A->data
> B->A->data
>

At risk of misunderstanding it too (it appears from an off-list
conversation that I misunderstood John).

Let us suppose Alice owns A, and Malory owns B. Malory (without
Alice's consent) sets B to be equivalent to A and signs it. Alice's
(say) mail server now treats mail to B as local mail, because it
gets a signature on B saying it's equivalent to A. Is this a good idea?

I'm sort of nervous about applications considering a foreign domain
as equivalent to mine without any local confirmation. I know we have
existing one way pointers, but applications do not in general trust
them unconditionally, which is what you may need for a reactive
model (in John's terms), isn't it?

-- 
Alex Bligh

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Aug 2010 11:01:53 -0700

> interface to Google.  I think it's cases like this that John was

I think Patrik is saying that the information "The zone maintainer of
searchy.example.com has created a CNAME that points my.searchy.example.com
to www.google.com" has to be validated by "searchy.example.com"; no data
signed by google.com can validate that.

If you want to also have a record in which Google asserts "here are
CNAMES I am okay with pointing to me", Google would sign that record.
But, frankly, I'm not sure what use an application is going to make of
such an assertion.  I can picture app-specific meanings ("if you present
 a host header with any of the following, I'll do the same thing as I would
do when presented with www.google.com"), and a generic meaning
could be similar ("any of these strings will be accepted by services
running on this service and the results will be the same as the canonical
name string").  But I think Patrik and I are heading toward a slightly
different application/dns behavior--in which the DNS passes up the
canonical name and the app adjusts to use it.    With that behavior,
the second RR with Google's assertion is a no-op, because the app
will have learned to use www.google.com instead of my.searchy.example.com.
There's  nothing for anyone to approve there, as the app is intereacting
with the canonical name as expected by the time the app-layer interaction
starts.

Is there other behavior desired in defining something as "authentic"?  I'm
a little worried about hand waving there if we're already hand-waving
"the same" and "data"

regards,

Ted

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Aug 2010 14:03:33 -0400

No hat.

> Because we do not do it for the domain name -> IP address mapping.

Interesting you should argue that.  In a long-expired draft over in
dnsop, we made the following distinctions:

- existent and non-existent reverse mapping
- matching and non-matching reverse mapping

At least historically, we had a class of behaviour where people
insisted on matching reverse mapping: for a given name, you looked up
the IP address (A record), then did the PTR lookup for that and
checked to see if you got the hostname you expected.  If not, then the
host was "bad", for some definition of bad.

This use fell out of favour, partly because DNS without DNSSEC was not
hard to spoof (so the test added practically no security or other kind
of assurance).  It will be interesting to see whether it is
resurrected in the age of DNSSEC.

Moreover, your argument is basically that because we haven't had a
particular facility so far, then we don't need it.  But of course, we
have never had the sort of aliasing behaviour we're now talking about
_at all_.  I don't think it's an acceptable answer to say, "Well, we
never did that before," and expect that response to be treated as an
argument for why not to do this thing.  The same therefore goes for
the back-pointer idea.

There's something very attractive, I think, in having a mechanism for
the canonical name to list all the aliases by which it is known.
Moreover, with DNSSEC in all the zones, you could prove that they
really were related as they claim to be.  What's wrong with specifying
that as part of the work?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 20:06:57 +0200

> model (in John's terms), isn't it?

Ok, I got it now...

You are correct on the danger that the B->A pointer unconditionally on application layer say for example x@A and x@B are the same, so when wanting to send mail to x@B, the mail will be sent to x@A, and the mail server at A can not know that x@B was the intended recipient as the email address x@A is presented to it.

What I was (sloppy of me) thinking of is that in many cases each SMTP/HTTP/whatever server do have a default domain configured, and x@DEFAULTDOMAIN will work anyways.

Mumble...

I still think we should list requirements. And compile a list. Then we can discuss in a more constructive way.

I am nervous we have tons of requirements here and there, but not in one place.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 20:11:35 +0200

On 23 aug 2010, at 20.03, Andrew Sullivan wrote:

> particular facility so far, then we don't need it.

For the DNS I do think we have learned how to live without it, and we do argue about whether a domain name where A->PTR->A->PTR etc is stable compared to a case where it is not.

For the domain mapping on application layer, we do have a validation in the form of handshake, for example HOST header in HTTP.

So I get it now...

  Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Aug 2010 14:20:10 -0400

Hat still doffed.

> signed by google.com can validate that.

Right.

> CNAMES I am okay with pointing to me", Google would sign that record.

Also right.

> with the canonical name as expected by the time the app-layer interaction

Recall, however, that at least part of our goal amounts to solving a
user interface problem.  We have users who type things in one way, but
that is not the "canonical" way.  Nevertheless, it's the way that is
natural for them, given their input methods and so on.

I would be somewhat surprised if the communities who have that problem
would think it just fine and dandy if the canonical name ended up
being the only thing that users could actually use (i.e. that their
display would quickly convert to the canonical name once that link was
discovered in the DNS): this is more "second-class citizen" than I had
heretofore contemplated.  Since this isn't my itch, I can't tell how
to scratch it.  Is such a restriction really ok?

To be clear about what we're supposing: I was moderately surprised
just now at the results for the following names, for instance:

    bonjourquebec.com
    bonjourquebec.ca
    bonjourquébec.com
    bonjourquébec.ca

If you go to the website, the first three are the same (and they all
get you to the first of them; the last one doesn't work because .ca
doesn't have IDNA support).  None of this is done in the DNS.  What's
interesting is that the accent on the e gets dropped.  Is that what
we'd expect?  Is it ok?

> a little worried about hand waving there if we're already hand-waving

Me, too.  

I'm not sure that we need to overload the word "authentic" here,
however.  The point is to deliver behaviour that is predictable and
more or less intuitive, I think.  One of those intuitions might lead
one to say that nobody can make an alias of your name unless you say
so.  That's not the way we've historically done it, but it's not hard
to imagine.  After all, if you go making symlinks on a filesystem to
files you can't read, you still can't open them.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 23 Aug 2010 19:23:10 +0100

> that as part of the work?

You may well want to be able to confirm that an alias is an alias, but
perhaps a list of records are not the way to do it. It doesn't take a lot
of imagination to come up with a situation where the number of possible
equivalent forwards is beyond a million, and I'm not sure I fancy returning
a list of a million addresses in response to a query (whether that be
PTR or anything else).

Would it not be better to use some crypto solution to this: e.g.
(completely off the top of my head) for the (putative) alias zone to
hold some record signed with the same key as the canonical zone?

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Mon, 23 Aug 2010 19:24:05 +0100

On Mon, 23 Aug 2010, John R. Levine wrote:
>
> I'm also thinking about the security model in which a client says "the user
> asked for B but I'm pretending he asked for A".  At the very least, the server
> better verify that's an alias it approves of.

The client should treat it as a redirect. At the moment redirects are
unauthenticated in HTTP and SMTP at least.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER: WEST OR SOUTHWEST 7 TO SEVERE GALE 9, OCCASIONALLY STORM
10 AT FIRST IN HUMBER AND THAMES. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH.
SQUALLY SHOWERS. MODERATE OR GOOD.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 23 Aug 2010 15:28:21 -0300

> CNAMES I am okay with pointing to me", Google would sign that record.

Yes, and there are several similar things that I'd suggest are of some
value:
- something indicating, within an authority domain, what set of labels is
associated with what "canonical" label
- something else, indicating what labels and/or fqdn's, are authoritatively
"equivalent" from the authority owner's perspective

The former is a "goto" pointer.
The latter is a "come-from" pointer, which, when signed, gives strong
authentication of the pointer chain.

> such an assertion.

I don't think this is something which needs to be *exclusively* an app
thing.

I think that the model(s) we choose to support for "equivalent" and "dnssec"
at the same time,
need to enforce this, at the DNS level.

In other words, that the DNSSEC-aware validator would only give a "trusted"
response if B->A->rdata has A saying "I have signed my approval of B->A".

It's something missing from the current model, for sure - but I think it
needs to be there.

>  I can picture app-specific meanings ("if you present
That only works if the application is secure itself, e.g. https.

If the application is not secure, i.e. the server->client is in the open,
then the client
can pretty easily be spoofed with embedded my.searchy.example.com in a page
that also
contains evil.searchy.example.com. Both signed by searchy.example.com, both
valid and secure,
from a protocol perspective - but combined, creating a security nightmare
and phisher's dream.

You need to think like a bad guy first, before thinking like either a (big)
good guy or a little guy.

There's a reason for the DNSSEC model of chained authenticated delegations
from a trust anchor.
Deviations need to be thought out carefully, to ensure they don't create
vectors for compromising that trust relationship.

Brian

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 20:28:40 +0200

> interesting is that the accent on the e gets dropped.  Is that what

That is an application layer issue, and unfortunately (I think) due to the way many CMS systems work (like Wordpress). You can only have one canonical domain name for a host, and the rest are aliases that result in redirects.

For example http://xn--bonjourqubec-jeb.com/ result in a redirect to http://www.bonjourquebec.com/

That is not always needed. See http://www.ledåsa.se/idn/.

   Patrik

---

From: Tony Finch <[email-masked]>
Date: Mon, 23 Aug 2010 19:32:24 +0100

> interesting is that the accent on the e gets dropped.  Is that what

It's good from the point of view of http cache behaviour.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOLE LUNDY FASTNET IRISH SEA SHANNON ROCKALL MALIN WEST OR NORTHWEST, 5 TO 7,
OCCASIONALLY GALE 8 IN IRISH SEA, ROCKALL AND MALIN, DECREASING 3 OR 4 LATER
IN SOLE, FASTNET, SHANNON AND ROCKALL. MODERATE OR ROUGH, OCCASIONALLY VERY
ROUGH IN ROCKALL AND MALIN. SQUALLY SHOWERS, RAIN IN ROCKALL AND MALIN.
MODERATE OR GOOD.

---

From: "John R. Levine" <[email-masked]>
Date: 23 Aug 2010 14:44:44 -0400

> unauthenticated in HTTP and SMTP at least.

Right.  This isn't something DNSSEC addresses at all.  In this model, the 
set of alias names is entirely under control of the operators of the 
aliases, not the resource they redirect to.  With HTTP redirects, they may 
not be authenticated but at least they're under control of the server.

I haven't worked out all the various threat models, but the idea that 
random bad guys can invent new names for my web servers or my mail system 
and I wouldn't even know about them does not give me a warm feeling.

Also, although I certainly don't think we should try to define user 
interfaces, we should at least have reasonable answers for questions like 
if the user asked for B, and his client asked the server for A instead, 
what name should appear in feedback like a browser's address bar?

Oh, and one more data point: the mail RFCs consistently say that mail 
clients should resolve CNAMEs and use the resolved name, and mail clients 
consistently don't do that (and not just because the authors haven't read 
the RFCs.)  There's a lesson there.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 20:53:15 +0200

On 23 aug 2010, at 20.44, John R. Levine wrote:

> I haven't worked out all the various threat models, but the idea that random bad guys can invent new names for my web servers or my mail system and I wouldn't even know about them does not give me a warm feeling.

Today if I put up an HTTP server, I can either do a forward-proxy or a redirect to your server. In the first case, the client does not notice, and in the second you do not notice.

But as Andrew says, just because we already have this problem already (CNAME, A record, on application layer etc), should we make the problem worse? Will the problem get worse?

I do not know.

But it is one issue to look at when evaluating possible solutions.

   Patrik

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Aug 2010 12:01:26 -0700

> from a protocol perspective - but combined, creating a security nightmare

When I try to work this out in venn diagrams in my head, I'm afraid I fail.
If the reference is to my.searchy.example.com, the pointer is to www.google.com,
but the signature is searchy.example.com's.  There's no trust being given
here other than "searchy.example.com asserts my.searchy.example.com is
a pointer to www.google.com".  How would it increase the trust in
evil.searchy.example.com?
There are, of course, existing attacks that allow you to embed trusted
content from
a different host in an untrusted context (early frame attacks, etc.),
but this doesn't seem
to actual touch on those in any way I can see.

> vectors for compromising that trust relationship.

But this isn't a deviation.  DNSSEC is a mechanism for ensuring what you got
was what the zone maintainer entered.  It has no protection for an evil zone,
and never did.  What Patrik pointed out was that you need to separate the
data asserted by one zone (the CNAME-ing zone) from that which must
be asserted by the other (the target one).  I don't think I understand how
the existence of a different label under the CNAME-ing zone  relates
to this at all.

More explanation gratefully received....

Ted

---

From: Brian Dickson <[email-masked]>
Date: Mon, 23 Aug 2010 16:15:40 -0300

> to actual touch on those in any way I can see.

It was in fact what I was thinking of - the embedded content (early frame
attacks), under
the new method of securing things (DNSSEC).

Normally, if you combine insecure and secure content, the browser
application will generate a warning
(which the user can ignore, or even select to suppress all such warnings).

In the analogous set-up, having a DNSSEC-aware browser present analogous
emblems for the security
level of the DNS names present in the content, having signed CNAMEs for
my.searchy, and signed other-RRs
for evil.searchy, would suggest that all the content was DNSSEC-"safe".

I'm suggesting that the overall usefulness of DNSSEC is diminished without
having the target also validate
the pointer - or rather, that we miss the opportunity to provide a means to
increase the usefulness of DNSSEC,
if we don't provide such a means.

> More explanation gratefully received....

It would be a label under the target zone, not under the CNAME-ing zone,
which gives protection
against unilateral signed pointing at a target label in a target zone.

It's kind of like the difference between single-entry (cash) accounting,
versus double-entry accounting,
where debits and credits need to match up. In accounting, it makes it
possible to audit the books.
In DNS, it provides ways for domain owners (registrants) to exert much more
control over their domain.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 23 Aug 2010 18:38:56 -0300

> Text/suggestions welcome.

I've been giving some thought to a variety of aspects to the problem space
and some of the possible solutions (both those in ID form already, and those
not yet fully fleshed out).

I think, in some use cases, we should think about the deployment timeline,
not just generally, but collectively (as in set-wise) across multiple actors
in the respective spaces.

And, to do so from the perspective of several categories of actor:
- domain owner (i.e. registrant who either intrinsically receives, or
explicitly requests, multiple domains, IDN or otherwise)
- delegation-only zone owner
- registry owner - generic, sponsored, cctld
- registrar
- software vendor for registrar (EPP client)
- software vendor for registry (EPP server0
- software vendor for DNS authority server
- software vendor for DNS resolver
- software vendor for DNS stub resolver
- operator of DNS resolver (included with ISP service)
- operator of DNS resolver (open resolver)
- any others?

And to complicate things further, let us consider that not all such actors
are going to be what is considered a "rational actor", i.e. looking at the
big picture, acting logically, or even acting in their own self interest.

We sometimes forget that even when a large proportion of actors in a given
space act rationally, not all do, and not always on the same time scale. (Or
maybe we don't, but it just hasn't surfaced in the present discussion.)

I think we need to consider, for each proposed solution, in addition to the
benefits and costs, how universally it needs to be implemented and deployed,
in what segments in the list of actors, before the solution can be
considered useful enough to warrant use by its target use case group.

Here are some examples of the deployment issues, as I see them:

- If a new RR type is needed for equivalence, *above* the apex of the domain
owner (e.g. in any of the delegation zones), it matters a great deal:
-- which parent zones support that RR type
-- whether, given the owner's desire to have N equivalent names, all parents
of the N names support the RR type
-- or whether N-1 parents support the RR type
-- and if the number is N-1, whether the N'th parent supports other
necessary elements (from the perspective of the owner), such as DNSSEC
-- which registrars support the new RR type, and how
-- which vendors support serving the new RR type (if such type is not
generically supported)
-- which operators have deployed support for the new RR type

- If more than one means for achieving equivalence is available:
-- that they are sufficiently compatible so as to co-exist for the same
"target" name for a given owner
-- that there be incremental incentives for all parties involved, to deploy
anything "new"
-- that there be a progression between methods, which always involves a
positive benefit to the party making the needed change
-- Having one minimal cost early-deployment mechanism makes a lot of sense,
pragmatically
-- Having a maximum-benefit mechanism available with the fewest "moving
parts" which need to be changed makes a lot of sense
-- The long tail needs to be considered not only in each component, but on a
collective basis
---- This suggests that unless universal deployment in at least one
dimension (all TLDs, all validators, all recursive resolvers, or all stub
resolvers), the diminishing returns from individual domain owners being
members of the non-deployed overlap zones leads away from solutions
involving larger number of required component changes

- If possible, isolate the changes to elements which are involved in DNSSEC,
so as to minimize the need to change non-DNSSEC components, for maximum
backwards compatibility
-- Most of the scaling issues have to do with either duplication of data, or
the performance penalty of DNSSEC signing of duplicated data (with different
signers)

- If possible, isolate the changes needed to local components, so as to not
require coordinated changes to the participants in multiple segments of the
food chain
-- Otherwise, there is a non-zero probability that some subset of the domain
owners will be unable to benefit from the changes, as the providers they
must use or choose among, don't support the needed functionality
-- This comes from thinking of things from the perspective of a domain
owner, and "not blaming the victim" - the domain owner does not get to
choose his situation, i.e. which TLDs he needs to register domains in

- If possible, ensure that there is no need to choose between multiple
domain support (IDN et al) and DNSSEC support
-- Further, ensure that there is no performance penalty for using both, as
this would present a barrier to deployment
-- Again, this points towards isolated elements rather than interconnected
functionality (above the apex) changes, since multiple domains are by
definition involved

- There is a non-obvious benefit to focusing on the zone apex, for where to
implement solutions(s):
-- Every zone _has_ an apex
-- Every zone, no matter how large or small, has _one_ apex
-- Large zones benefit from apex-specific solutions in that the least number
of changes are required, and the greatest benefit is seen by large zones, if
there is a performance benefit to be seen
-- Small zones benefit by having the changes being local to within their own
sphere of operations (zone of control as it were)
-- Coordination is not required, either operationally (between registrants,
registrars, registries, and DNS authority delegation-only servers) or
developmentally (multi-vendor, multi-function coordination being the
worst-case scenario from a software perspective)
-- Additional elements fit semantically quite nicely there: canonical zone
identity, permitted zone aliases (AKA), any others?
-- The apex is in some respects "label-free" (at least relative to the zone
owner name)

(Um, sorry for another long analytical post...)

Here's where I see this analysis pointing:
- SHADOW has operational benefit to domain owners, but still has performance
penalties (each name needs to be signed by every owner combination)
- Changes to validation (and *only* validation), by either:
-- simply changing the rules to allow apex KSK-only signing of DNSKEY sets,
as a means of signaling zone equivalence (implicitly)
-- adding new RR types to the apex, to explicitly signal allowed signers
(canonical) plus zone names to which this applies (AKA names)
- C+D might work (but take a long time and have signaling issues)
- bname might work (but take a very long time for similar reasons)
- provisioned zones with DNAMES (Andrew's suggestion) might be feasible
- The above are increasing time to deploy, and decreased incentive to deploy
- The TLDs and ICANN are likely to play a large roll in deployment
- Finding ways to play nice with the TLDs, and *not* *require* any changes
by them to achieve most of the benefits, should be a large consideration to
the choices of solution
- No single solution can be considered adequate.

Brian

---

From: [email-masked]
Date: Mon, 23 Aug 2010 21:46:45 +0000

> Hmmn, so we upgrade billions of client programs rather than millions of 

	stub resolvers seem to gets swapped out more frequently than
	servers.  the focus on stubs also reduces the attack surface,
	if that is of interest.

	(noting that 15+years of empericial survey data suggest that
	the spread of code varients in servers is widening instead of
	shrinking)

	just saying.

> the server better verify that's an alias it approves of.

	oh well - yet another vector for tortuous interference by	
	random third parties - eh?

--bill

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Aug 2010 15:16:04 -0700

> to scratch it.  Is such a restriction really ok?

And the answer is awful: it depends.  In some of these contexts, the idea
that something is moved to a normalized version will no doubt be okay;
the user will treat this as a handy fix-up of their entry.  In others, I suspect
that there will be real political pressure to retain multiple "real" domains.
My off-the-cuff guess is that in the latter cases xName, shadow, et al. won't
work in practice because the situation requires the complexity to allow

british.humour.example to be the "real domain"
american.humor.example to be the "real domain"
and geek.humor.example and geek.humour.example to be on equal fotting.

You can do any of the above using a canonical name, but you need something
acting as a presentation layer to get the user view right (and it is
likely to be
an app-specific presentation layer in our current world).

> interesting is that the accent on the e gets dropped.  Is that what

I would personally suspect that once the 4th is live, all the others will
point to it and the result would no longer be a surprise.  But that's the
view of an anglophone non-Canadian, and I'm not a good test.

> so.

I think trying to match intuitions which aren't going to be consistent
is a very hard task indeed.  I also suspect that your last statement
isn't true in the state Patrik originally envisioned--in which you get
back a pointer to the real name passed up the stack.  It doesn't
leave the app dealing with a symlink--it acts closer to a redirect.

(And analogies here are going to bite us in the long run, but I
don't see a way around it right now).

> That's not the way we've historically done it, but it's not hard

The broken behavior here would be allow the app to be presented
the CNAME and use it to talk to google.com without ever passing the
forward pointer
up the stack.  If the google search engine accepted any host string,
that might be an issue.

---

From: Tony Finch <[email-masked]>
Date: Mon, 23 Aug 2010 23:38:35 +0100

On Mon, 23 Aug 2010, John R. Levine wrote:
>
> Right.  This isn't something DNSSEC addresses at all.  In this model, the set
> of alias names is entirely under control of the operators of the aliases, not
> the resource they redirect to.

Yes.

> With HTTP redirects, they may not be authenticated but at least they're
> under control of the server.

Under control of the server referred to by the alias but not the target
server.

> I haven't worked out all the various threat models, but the idea that random
> bad guys can invent new names for my web servers or my mail system and I
> wouldn't even know about them does not give me a warm feeling.
>
> interfaces, we should at least have reasonable answers for questions like if
> the user asked for B, and his client asked the server for A instead, what name
> should appear in feedback like a browser's address bar?

At least HTTP redirects replace the contents of the URL bar. SMTP doesn't
have a sensible way of providing that kind of feedback. Other protocols
don't have any kind of redirect support.

> Oh, and one more data point: the mail RFCs consistently say that mail clients
> should resolve CNAMEs and use the resolved name, and mail clients consistently
> don't do that (and not just because the authors haven't read the RFCs.)
> There's a lesson there.

That was true in RFC 821 + RFC 1123, but it was dropped by DRUMS and is no
longer required by RFC 2821 / RFC 5321.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT: CYCLONIC SEVERE GALE 9 TO VIOLENT STORM 11, BECOMING WEST 6 TO
GALE 8. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR.

---

From: "John R. Levine" <[email-masked]>
Date: 23 Aug 2010 18:56:06 -0400

> 	servers.  the focus on stubs also reduces the attack surface,

That's different from my experience, but in any event, it ain't just stub 
resolvers.

It seems to me that if the world were going to handle aliases in the 
clients, they'd be doing it now.  If we imagine an HTTP extension in which 
the client can send both the original name and the canonical name, you'd 
publish the alias via CNAME, clients would do a normal lookup for an A 
record, and if the name of the A record returned didn't match the name it 
looked up via a CNAME chain, now it's got the original name and the alias. 
Web clients don't do that and show no likelihood of doing that.  Why not? 
Blaming it on gethostbyname() seems pretty feeble, and in the meantime, 
we're using our scripts to generate shadow zones for servers.

> 	the spread of code varients in servers is widening instead of

I believe it, but there's literally a billion, maybe two billion web 
browsers in use, quite a lot of which won't be upgraded until the device 
on which they're running is discarded.  People who run servers have the 
incentive to make this stuff work so their clients can get to them. 
Clients who find web sites or whatever inaccessible are much more likely 
to blame the remote site (well, other sites work so it can't be my 
problem) and will just look elsewhere.

> 	random third parties - eh?

tortious, too.

R's,
John

---

From: John Levine <[email-masked]>
Date: 24 Aug 2010 02:02:41 -0000

Man, I go away for a few hours to take my daughter to the dentist,
and look how much I missed.

>I still think we should list requirements. And compile a list. Then
>we can discuss in a more constructive way.

Yes indeed.  Let me see if I can clarify what my thinking a little.

I hope we agree that a design where there are two parallel sets of
info that have to be kept in sync by hand for a system to work is, at
least, something we'd like to avoid.  As a concrete example, if a web
site has a bunch of equivalent names, both the DNS and the web server
have to be configured to handle them all.

So what could we add to the DNS so that the list of equivalent names
is only stored in one place?  My thought was that the application is
manually configured with the canonical name, and it pulls the rest of
the names from the DNS.  As far as users can tell, all the names can
be equivalent; picking one as canonical is just to give the
application a place to start.  That's the point of the backward
pointers in the DNS, so that the application can tell what names it's
supposed to handle, as opposed to which ones are just pointed by
random possibly hostile parties.

R's,
John

---

From: Florian Weimer <[email-masked]>
Date: Tue, 24 Aug 2010 07:57:40 +0000

* Patrik Fältström:

> refer to it as the canonical name".

Initialization of the Cw macro in Sendmail (which contains the list of
domains for which mail is to be delivered locally).  This was not
needed for CNAME because resolving CNAMEs was the responsibility of
the sender.

However, these days, few senders resolver CNAMEs (and I don't think
Sendmail got it right, either), so you need to explicitly configure
the local domain list anyway, and the reverse lookup capability seems
less important.