Subject: [DNSOP] Extended CNAME (ENAME)

From: Mark Andrews <[email-masked]>
Date: Sat, 17 May 2014 11:04:06 +1000

domain ENAME domain {0|1} [type list of included / excluded types]
		(0 == include, 1 == exclude)

	"domain ENAME domain 1" is equivalent to "domain CNAME domain"
		(exclude nothing)

	"domain ENAME domain 1 NS DNSKEY SOA" is CNAME at apex

	"domain ENAME domain 1 NS DNSKEY SOA DNAME"  +
	"domain DNAME domain" is full zone remapping.
	
	"domain ENAME domain 0 A AAAA" is address redirect

	This would require a dnssec algorithm bump.

	The server would synthesis CNAME in the response for plain
	and EDNS(0) queries with a TTL of 0 unless the type vector
	is zero in which case the TTL will match that of the ENAME.
	ENAME is not returned.

	The server would return ENAME in EDNS(>0) queries.

	A request for a ENAME record will return a ENAME records
	independent of EDNS versions.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: "Mark Delany" <[email-masked]>
Date: 17 May 2014 01:19:26 +0000

> 		(0 == include, 1 == exclude)

As I recall, the HTTP/2.0 folks have been intermittently talking about
supporting SRV. Would encouraging that group on that front be easier
than inventing CNAME support at the apex?

No reason to think either approach would get better or less
adoption-rates over time.

Or are there other uses for ENAME beyond what the HTTP/CDN crowd do
with CNAMEs today?

Mark.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 May 2014 19:25:08 -0700

> than inventing CNAME support at the apex?

yes. by far.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 17 May 2014 17:12:35 +1000

> Or are there other uses for ENAME beyond what the HTTP/CDN crowd do

I would encourage both.  ENAME is just service agnostic.
 
> Mark.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 May 2014 07:51:00 -0400

> I would encourage both.  ENAME is just service agnostic.

It might be worth actively pushing the CDN folks to go the SRV direction.   Even if ENAME were a good idea, which is not clear to me, it's an idea that would require significant infrastructure changes, whereas SRV records appear to be functional now, with no DNS software changes.

In any case, DNSOP certainly shouldn't be anticipating a future need that hasn't yet been clearly expressed to us and designing protocol changes to address it that haven't been requested.

---

From: Joe Abley <[email-masked]>
Date: Sat, 17 May 2014 09:23:01 -0400

On 17 May 2014, at 7:51, Ted Lemon <[email-masked]> wrote:

> It might be worth actively pushing the CDN folks to go the SRV direction.

It seems to me that the CDN people have a solution that works for them right now.

With respect to using SRV for HTTP (which I agree would be great) the gap is on the client side. It's an application issue, and I don't see a lot of work to be done in this working group.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 May 2014 09:28:04 -0400

> With respect to using SRV for HTTP (which I agree would be great) the gap is on the client side. It's an application issue, and I don't see a lot of work to be done in this working group.

How widespread is HTTP 2.0 support in browsers at the moment?   :)

---

From: Mark Andrews <[email-masked]>
Date: Sun, 18 May 2014 09:34:07 +1000

In message <[email-masked]>, Joe Abley writes
> It seems to me that the CDN people have a solution that works for them

But not all web hosters have a "solution" that doesn't require
custom nameservers to solve.  So yes we do need to push the CDN
people to get their customers to publish SRV records so that everyone
is using the same solution in the end.  Additionally the CDN hack
(and yes it is a hack not a solution) doesn't help when you want
to host some protocols locally and others at a CDN for the same
name.  This is very much "it works for what I want to do" not it
"works for everyone".

SRV will work all the time once the clients support it.

> With respect to using SRV for HTTP (which I agree would be great) the gap
> is on the client side. It's an application issue, and I don't see a lot
> of work to be done in this working group.
>
>
> Joe
>

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 18 May 2014 07:12:29 +0200

> It might be worth actively pushing the CDN folks to go the SRV direction.   Even if ENAME were a good idea, which is not clear to me, it's an idea that would require significant infrastructure chan…

++;

SRV is implemented (even by closed-source DNS servers/resolvers
that otherwise leave lots to desire), powerful and largely
unexploited. Inclusion in HTTP2.0 would be a major motivator.
 
> In any case, DNSOP certainly shouldn't be anticipating a future need that hasn't yet been clearly expressed to us and designing protocol changes to address it that haven't been requested.

One can lead sheep to the grass, but challenges remain. It is not clear
that inventing different grass will be worth the effort, compared to
offering the present, already grown, grass.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Yow!  I want my nose in lights!

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 18 May 2014 07:58:09 +0200

> It might be worth actively pushing the CDN folks to go the SRV direction.   Even if ENAME were a good idea, which is not clear to me, it's an idea that would require significant infrastructure chan…

As I have stated several times I disagree with any statement that claim "significant infrastructure changes".

This usage is the reason I did define the URI resource record, so that one could get a "redirect" already in DNS instead of escaping to HTTP.

example.com. IN URI 1 2 "https://foo.hosting.bar/example.com/startpage/en"

 Patrik

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 18 May 2014 09:57:24 -0400

> example.com. IN URI 1 2 "https://foo.hosting.bar/example.com/startpage/en"

As much as I would love for the HTTP2.0 folks to adopt SRV records, but 
Ted's comments on client adoption is still "wait and see".

I am finding ENAME a more palatable alternative.

tim

---

From: Andreas Schulze <[email-masked]>
Date: Sun, 18 May 2014 18:31:41 +0200

> 		(0 == include, 1 == exclude)

Mark,

I currently don't see, why ENAME will be usefull. Could you (or other)
clarify in which scenario ENAME would be helpfull?

Or what like to ask:
How has my problem to look like that this solution will help?

Andreas

---

From: Mark Andrews <[email-masked]>
Date: Mon, 19 May 2014 08:39:11 +1000

In message <[email-masked]>, Andreas Schulze wr
> How has my problem to look like that this solution will help?

The reason why CNAME is prohibited at a zone apex is described in RFC 1034:

"The domain system provides such a feature using the canonical name
(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR.  If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types."

Named probibits CNAME and other data when loading zones because of
this and because we had too many "bug" reports where people only
wanted CNAME to only be followed when there wasn't a type already
there.  Making it fail at load time rather than run time got rid
of the later compliants replacing them with "why can't we have a
CNAME at the apex", but then it was just a matter of referring them
to RFC 1034.

ENAME lets a resolver know whether a particular type is covered by
its alias functionality or not.  This avoids the issues cause by
having CNAME and other data as described above .

Mark

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 19 May 2014 16:38:41 +0200

> example.com. IN URI 1 2 "https://foo.hosting.bar/example.com/startpage/en"

So can that be used instead of specifying something where the initial
proposal casually mentions "This would require a dnssec algorithm bump"?

Not saying this to move it from dnsop to any other list or group, but
that line alone implies there's a significant protocol change.

Jelte

---

From: "John Levine" <[email-masked]>
Date: 19 May 2014 16:12:41 -0000

>>> It might be worth actively pushing the CDN folks to go the SRV direction.   Even if ENAME were a good idea, which is
>not clear to me, it's an idea that would require significant infrastructure changes, whereas SRV records appear to be
>functional now, with no DNS software changes.

As I understand it, this is proposing a large DNS change as an
alternative to a modest HTTP change.  Doesn't strike me as a great
tradeoff.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 May 2014 14:11:51 -0700

> than inventing CNAME support at the apex?

Yes they have, and yes it would. However, they are not focused on SRV (nor URI) at the current time.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 May 2014 07:45:21 +1000

In message <[email-masked]>, "John Levine" writes:
> >>> It might be worth actively pushing the CDN folks to go the SRV
> >>> direction.   Even if ENAME were a good idea, which is
> >>>not clear to me, it's an idea that would require significant
> >>> infrastructure changes, whereas SRV records appear to be

It's trading off a in nameserver redirection which works with
wildcards to a in client redirection that doesn't work with
wildcards.

Everytime I have mentioned SRV records to HTTP folks they
say it won't work as the extra lookup takes too long.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 May 2014 14:56:37 -0700

Mark Andrews wrote:
> ... Everytime I have mentioned SRV records to HTTP folks they say it
> won't work as the extra lookup takes too long.

this sounds strange to me. TTL=0 SRV RR's strike me as precisely what
the CDN industry needs, since they can include an AAAA (or for
back-compatibility, an A) RR in the same response as additional data.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 May 2014 18:40:51 -0400

> Yes they have, and yes it would. However, they are not focused on SRV (nor URI) at the current time.

What _are_ they focused on?

---

From: Bob Halley <[email-masked]>
Date: Mon, 19 May 2014 23:07:17 +0000

I too think the SRV route is far better.

I've always thought it was an architectural mistake to be looking up
hostnames when what you wanted was a service.  SRV records have
priority, weighting, and the ability to specify a port, all of which
are useful.  Since the owner name for a service whose URL would be at
a zone origin is *not* at the zone origin, ordinary CNAME is still
possible if you want to have the SRV in the control of the CDN.

ENAME does not have a good transition mechanism for DNSSEC. If you do
not know the new algorithm(s), you will not be able to validate, and a
zone signed with an earlier algorithm will not work either as the
synthesized CNAME will not validate.  ENAME can thus not be used with
DNSSEC until there is sufficient adoption of the new algorithms by
the installed base of resolvers.

Anything which requires DNSSEC validator changes is a transition
disaster that will become totally untenable if DNSSEC is ever widely
deployed (in the "millions of zones signed" sense).  That level of
deployment has not yet occurred, but nevertheless I think that DNSSEC
validation process changes should be held to the very strictest
standards and only be contemplated for dire problems.  This is *not* a
dire problem!

I think we should encourage the use of SRV in HTTP 2.0.  We can also
recommend that if people are contemplating ever needing to use a CDN,
then they shouldn't publish URLs with names at zone cuts.

/Bob

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 May 2014 09:43:42 +1000

> the installed base of resolvers.

No.  Your analysis is faulty.

ENAME could be used immediately once the authoritative servers for
the zone support it.  It would just be insecure until validators
catch up.  ENAME + old algorithm would be illegal and would be
enforced by signing code and authoritative servers.

> standards and only be contemplated for dire problems.  This is *not* a

We have already managed two DNSSEC validator change,  NSEC -> NSEC
+ NSEC3 (algorithm bump), and adding DNAME awareness to DNSSEC (type
code roll, though we could have done it using a algorithm bump) and
the world did not end.  If we wanted to do it we could deploy this
on multiple implementations before the end of the year.  It just
requires the will to do it.  There is nothing in the proposal that
is technically harder than what we are already doing when validating
or have already done in terms of transition management.

> then they shouldn't publish URLs with names at zone cuts.

Nobody is saying don't get SRV support in HTTP 2.0.  I would love
SRV or even a HTTP record to be support in HTTP 2.0.

There is however a need to be able to fully redirect a zone.  CNAME
cannot be used along side DNAME.  There is also a needed for aliasing
by type.

These needs will come up again.  We can deal with them now or deal
with them later.

---

From: Bob Halley <[email-masked]>
Date: Tue, 20 May 2014 00:26:58 +0000

>enforced by signing code and authoritative servers.

I didn't say ENAME wouldn't work if you didn't validate.  What I'm saying
is that proposals which are incompatible with existing DNSSEC should be
subject to the most rigorous scrutiny and cost-benefit analysis, and that
I don't think ENAME's benefits are worth its costs.  Others may have
differing valuations.  That's all I'll say on this matter.

/Bob

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 May 2014 17:44:59 -0700

<off-topic>

> What _are_ they focused on?

Transport and layering of messages within the protocol and, to a lesser extent, interaction with TLS.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 May 2014 21:27:44 -0400

> These needs will come up again.  We can deal with them now or deal

Let's deal with them later.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 19 May 2014 21:50:51 -0400

> differing valuations.  That's all I'll say on this matter.

+1
Anything that requires logic changes in resolvers takes a long time to roll
out. We can not afford having one more change that negatively affects DNSSEC validation. 
SRV use by HTTPv2 is mostly a client change, we will not need to wait for the 5+ year developmental 
+ deployment cycle of upgraded resolver in certain OS distributions. 

As a matter of fact I recall that Mark wrote this document many years back: 
 http://tools.ietf.org/html/draft-andrews-http-srv-00
If that draft had got traction then,  the world would be a much better place today. 

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 May 2014 22:23:49 -0400

Hi,

First, let me say that I like Mark's sketch of ENAME that I read on
this list.  (To disclose my bias, I had a much inferior, faintly
similar idea a couple years ago, but it was not complete, and not as
compact or elegant.  The customer I offered it to therefore told me
not to pursue it.)  I think the ENAME suggestion is a promising idea
(though it needs fleshing out and deeper evaluation).  I think it is a
vast improvement over the last suggestion in this direction (BNAME).
Nevertheless,

On Tue, May 20, 2014 at 09:43:42AM +1000, Mark Andrews wrote:

> catch up.  

…I think that may be a little too glib.  Given the DNSSEC environment
these days, I'm not sure we can just shrug our shoulders at the idea
of breaking DNSSEC validators.  Replacing validators on a large scale
takes perhaps 18-24 months (it's a new feature, and a lot of "stable"
server systems are now committed to no feature change in that time
scale), and likely longer for really complete penetration.  End point
validation uptake is worse; but on the other hand that continues to be
an enthusiast market, so it might be ok.  _But_, there might be a
slightly better argument.

The driving use cases for ENAME are for zones that today are almost
certainly not signing and, perhaps more importantly, have a whole
bunch of challenges in signing.  "Stupid DNS tricks" in the presence
of DNSSEC are awful hard.  Given the still-low utility in end point
validation, an administrator of such a candidate zone might not be
ready to adopt DNSSEC anyway.  So, if we quickly added ENAME and got
the algorithm change in place, then validators might be ready in time.

I can't say I'm optimistic about this.  ENAME would require special
server-side processing, so it's full standards action.  If we as a
community are actually convinced this is worth doing, however, then we
ought to be able to crank this out in 3-5 months.

I have heard people claim that we shut down DNSEXT too fast.  It took
years to do that, which I took to be evidence that we did it too
slowly.  Perhaps this is an opportunity for those who think I was too
keen to prove what a jerk I am.  That oughta be incentive ;-)  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 May 2014 15:45:34 +0900

> Transport and layering of messages within the protocol and, to a lesser extent, interaction with TLS.

I'm afraid exchanges of the messages within the protocol need
extra time, which can be too long.

Though Mark wrote:

: Everytime I have mentioned SRV records to HTTP folks they
: say it won't work as the extra lookup takes too long.

one can lookup A, AAAA and SRV in parallel and positive answer
to SRV, as Paul mentioned, can have additional A and AAAA RRs.

						Masataka Ohta

PS

Even without SRV, extra lookup for DNSSEC takes tooooooooooooo
looooooooooong, even though the root zone operated by ISOC/ICANN,
both of which are under US legislation, is not very trustworthy.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 20 May 2014 22:51:01 +0200

> say it won't work as the extra lookup takes too long.

So query A/AAAA/SRV in parallel and be done with it. Smart resolves will provide additional data just for fun and everyone will be happy.

Given how much pre-caching and magic modern web browsers do, the extra lookup argument is just moot IMHO.

	jakob

---

From: "Mark Delany" <[email-masked]>
Date: 20 May 2014 20:57:20 +0000

> to SRV, as Paul mentioned, can have additional A and AAAA RRs.

A downside is that clients has to wait for the SRV query to complete
so they can be sure of the presence or not of an SRV. First-win
approaches like happy eyeballs don't work here so most clients are
going to perform at the rate of negative cache lookups for the
foreseeable future. In aggregate I would expect this will slow clients
a bit.

You're also ensuring that the global query rate will substantially
increase on the assumption that HTTP/2.0 becomes as popular as
HTTP/1.0.

Generally speaking, the challenge is that SRV is likely acceptable to
commercial CDN providers that have thus far relied on CNAME - with
it's intrinsic level of indirection - but will be less welcome by
those who are using every trick to squeeze latency out of HTTP.

The latter - who are well represented in http-wg - will probably not
welcome a parallel SRV even if the latency impact is mostly zero.

If you want to make everyone happy, you need to invent a single
round-trip resolution that supports indirection...

These are just observations - not judgments.

Mark.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 May 2014 14:17:23 -0700

Mark Delany wrote:
> so they can be sure of the presence or not of an SRV. ...

in a blast protocol where all N queries are sent to the same
destination, one can reset the blast timeout upon first response, to
1.2x that response time. or even 1.1x. the total time cost delta of a
blast protocol is thus ~10%. since this is only happening on a cache
miss, i don't see it as decisive.

> ...

not so. 97% of the queries reaching the root name servers (as an example
of an important subset of global DNS traffic) are unanswerable due to an
initator-side screwup of some kind (rfc1918 source; firewall doesn't
permit response; etc). if we doubled the traffic that is not that 97%,
it would still be mouse nuts compared to that 97%.

> ...

disagreeing for a third time, SRV is an opportunity to squeeze even more
latency out of HTTP.

> ...

content-centric networking would do this. lixia and van have been
talking about it for a few years. alas it's a totally non-IP model and
not likely to replace the internet during the time it will take us to
decide what to do about SRV (and also do whatever it is we decided.)

vixie

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 11:55:48 +0900

> The reason why CNAME is prohibited at a zone apex is described in RFC 1034:

If we must change something, isn't it easier to allow CNAME at
a zone apex than introducing ENAME?

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 May 2014 19:59:47 -0700

> a zone apex than introducing ENAME?

the reasons for prohibiting it, as given in RFC 1034, still apply.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 May 2014 13:11:02 +1000

> a zone apex than introducing ENAME?

No.  They are roughly equally difficult and allowing CNAME at the
apex still won't solve CNAME + MX or CNAME + DNAME or CNAME + TXT
or CNAME + just about any other type.  The zone apex has lots of
data stored at it.

You have to update validators.  You have to do a DNSSEC algorithm
bump.  You need to update signers and authoritative servers to
enforce the algorithm bump.  You have to update recursive servers
to know about the new CNAME semantics.  You have to have a transition
strategy.

If you do allow CNAME at the apex one will then just end up with
two zones to manage instead of one just the second one is on the
CDN's nameservers for all the apex data.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 13:00:58 +0900

Mark Andrews wrote:

> apex still won't solve

See below.

> CNAME + MX or CNAME + DNAME or CNAME + TXT
> or CNAME + just about any other type.

What's wrong with allowing a zone apex have SOA, NS, CNAME but
nothing else?

> The zone apex has lots of
> data stored at it.

Nodes, not necessarily zone apex, having lots of their own
data can not have CNAME. So?

> You have to do a DNSSEC algorithm bump.

No, I don't, because I think DNSSEC must be obsoleted.

Anyway, special treatment for CNAME in DNSSEC is no
different regardless of whether a node is a zone apex
or not.

> You have to update recursive servers
> to know about the new CNAME semantics.

The update is never rely on cached CNAME for SOA or NS query.

Thus, even without the update, most people won't notice lack
of the update.

> You have to have a transition
> strategy.

First, change name server implementations. Then, declare
that people can use CNAME at zone apex. That's all.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 May 2014 14:28:27 +1000

> data can not have CNAME. So?

I'm saying just allowing CNAME + SOA + NS + DNSKEY doesn't help in
the grand scheme of things.  It just moves the problem rather than
fixing the problem which is two organisations wanting to change
data at the same node.

The data stored at www.example.net is usually very different to the
data stored at example.net.  For www.example.net you often don't
care about anything other than A and AAAA.  The same can not be
said for example.net even after you remove SOA, NS and DNSKEY from
the evaluation.

> Thus, even without the update, most people won't notice lack

Most != all.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 13:44:08 +0900

> said for example.net even after you remove SOA, NS and DNSKEY from

Are you saying to have:

www.example.net. SOA ...
                 NS ...
                 CNAME example.net.

?

What's wrong with:

	_http._tcp.example.net. SRV ... www.example.net.

?

>> Thus, even without the update, most people won't notice lack

Those who notice are those who can update their servers if
they think it necessary (I think it is not).

					Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 May 2014 07:02:46 +0200

On 20 maj 2014, at 22:57, Mark Delany <[email-masked]> wrote:

> so they can be sure of the presence or not of an SRV.

You have to look and count on A/AAAA + HTTP with redirect when comparing with SRV+A/AAAA or URI+A/AAAA.

I.e. some of the losses in even parallell URI/A/AAAA are compensated by loosing roundtrips in HTTP.

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 May 2014 16:09:42 +1000

> > said for example.net even after you remove SOA, NS and DNSKEY from

I am saying that many zones have more than A/AAAA/SOA/NS/DNSKEY/RRSIG at
the apex and adding allowing CNAME/SOA/NS/DNSKEY/RRSIG to all co-exist
doesn't help much as you end up with

	example.net SOA
	example.net NS
	example.net CNAME example.net.hoster.net

	example.net.hoster.net A
	example.net.hoster.net AAAA
	example.net.hoster.net TXT
	example.net.hoster.net MX
	...

	Which kind of forces them to deploy GLB technology even if they
	don't need to do for availability reasons to isolate the address
	changes from the other changes.

	When what is really wanted by the hoster is

	example.net.hoster.net CNAME serverX.hoster.net
	serverX.hoster.net A
	serverX.hoster.net AAAA

	which allows for the server's address to change and
	the hosting machine to be able to be changed with minimal
	DNS changes and is what they do for www.example.net.

	www.example.net doesn't have the other baggage associated
	with it.

> 	_http._tcp.example.net. SRV ... www.example.net.
 
Nothing.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 15:30:17 +0900

>> 	_http._tcp.example.net. SRV ... www.example.net.

So, without (C/E)NAME changes, the possibility of the following
configuration:

 	_http._tcp.example.net. SRV ... example.net.hoster.net.
	example.net.hoster.net CNAME serverX.hoster.net
	serverX.hoster.net A
	serverX.hoster.net AAAA

will motivate the hoster deploy SRV. Right?

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 May 2014 17:54:23 +1000

> will motivate the hoster deploy SRV. Right?

Yes, but the hoster doesn't have a say in it.  If they did it would
already be done because that is a lot simpler and cleaner than all
the other hacks being done.  You need to get the browser and proxy
vendors to update their code.  Giving them a spec to work to is the
first step.

Mark

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 21 May 2014 10:50:42 +0200

Hi,

please take into account that a CNAME + DNAME, the previously discussed BNAME or 
the now discussed ENAME solution is still interesting for domain name registries 
that have to deal with (maybe lots of) IDN variants. I don't think that SRV 
records are a viable solution for their use case.

Regards,

Klaus

---

From: Ralf Weber <[email-masked]>
Date: Wed, 21 May 2014 11:52:24 +0200

Moin!

On 21 May 2014, at 10:50, Klaus Malorny <[email-masked]> wrote:
> please take into account that a CNAME + DNAME, the previously discussed BNAME or the now discussed ENAME solution is still interesting for domain name registries that have to deal with (maybe lots of) IDN variants. I don't think that SRV records are a viable solution for their use case.
A combination of DNAME (which exists) and SRV should work or? But am not sure if it is a good thing.

Just let me give you an operational subjective observation from dealing with certain kinds of *NAME based redirection over 20 years running DNS servers. They caused mostly grief and problems since they been around. This of course is caused by the different semantics (a CNAME redirects every record type, and thus their can't be another record type at that node) compared to other resource records, that even the authors of some software did not understood (some versions of bind could load CNAME and other data at the same node). Once people understood this DNSSEC came around and changed that assumption again as even a CNAME needs signatures.

Oh and then came DNAME for redirecting whole domain trees and that might have been a nice idea if I have a couple of domains and want them all to have the same data. But I do not know of Registries/Registrars that picked that up. Or is there widespread deployment?

Now having an ENAME that initially will break all existing DNSSEC resolvers (Who can't validate any longer, because they don't support the algorithm yet) is IMHO not the right message when we want people to deploy DNSSEC and especially do validation.

SRV has been defined for some time, there are applications using it and the application we are most interested in the Browser has a much shorter update cycle than the typical DNS Infrastructure, so why not use it, as they fallback/backwards compatibility mechanism also is there and understood (publish an A/AAAA record).

So lets go for it.

SO long
-Ralf

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 19:08:55 +0900

Klaus Malorny wrote:

> please take into account that a CNAME + DNAME, the previously discussed 
> BNAME or the now discussed ENAME solution is still interesting for 
> domain name registries that have to deal with (maybe lots of) IDN 
> variants.

Scalability of IDN labels of equivalent characters is exponential.

Thus, the only solution against it is to give it up.

						Masataka Ohta\

---

From: Saku Ytti <[email-masked]>
Date: Wed, 21 May 2014 13:15:41 +0300

Any opinions on SVCINFO[0]. I was really big fan of SRV until I read the
draft, it made really compelling arguments to me.

I'm not sure I agree on how the information is encoded, coworker sent some of
his thought to the author explaining how to encode in a way which makes
machine-parsing easier. But this is minor detail.

Goal should be that 1 query returns all the information client needs to decide
how it wants to connect to service, SVCINFO delivers this.
If we had had SVINFO (or even SRV) for years, we'd likely have less BGP bloat,
as now you need to rely on really low-level stuff to deliver services reliably
due to naivety of A/AAAA.

[0] http://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr-01
-- 
  ++ytti

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 21 May 2014 12:37:26 +0200

> Moin!

Hi Ralf,

>
> Oh and then came DNAME for redirecting whole domain trees and that might have
> been a nice idea if I have a couple of domains and want them all to have the
> same data. But I do not know of Registries/Registrars that picked that up. Or
> is there widespread deployment?

To my knowledge, the .gr TLD registry uses DNAME besides puntCAT (.cat), in 
whose operation I am involved. From a technical perspective, we have not 
encountered problems with DNAMEs so far, but, of course, the registrants would 
prefer to be able to use the variant name without a subdomain prefix as well.

With the new gTLDs, those customers of us who intend to offer variants preferred 
not to use DNAME variants, not only because of the risk of getting special 
attention from ICANN ("extended validation"), but also because of the 
redirection problem of the variant name itself. As the alternatives also have 
operational deficits as well, I do not regard it as impossible that future gTLDs 
would use a fully working DNS redirection or that even existing gTLDs/ccTLDs 
would move to that once available. But this is, of course, my humble opinion, 
not based on any inquiry.

>
> Now having an ENAME that initially will break all existing DNSSEC resolvers
> (Who can't validate any longer, because they don't support the algorithm yet)
> is IMHO not the right message when we want people to deploy DNSSEC and
> especially do validation.
>

Well, I do not regard myself as an expert in DNS matters and cannot really 
estimate the impact of protocol changes, since I lack the "global view" to some 
extend (so I would have introduced IDNs as UTF-8 labels instead of the tricky, 
but still inconvenient Punycode, but that's another story). So my point of view 
is more that of a DNS user than of a protocol guru.

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 21 May 2014 12:43:44 +0200

> Scalability of IDN labels of equivalent characters is exponential.

Sure, but I am talking of about 5-20 variants per name, not all that are 
combinatorially possible.

> Thus, the only solution against it is to give it up.

Not yet ;-)

Regards,

Klaus

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 May 2014 12:23:08 +0100

> What's wrong with allowing a zone apex have SOA, NS, CNAME but

One problem is that CNAME pointing at MX is an interop disaster area,
since different MTAs disagree about whether this implies an email address
rewrite.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest Shannon, Rockall, Malin, Hebrides: Cyclonic 4 or 5 in southeast
Malin, otherwise northeasterly 6 to gale 8. Moderate or rough in southeast
Malin, otherwise rough or very rough. Rain or showers. Good, occasionally
poor.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 20:30:14 +0900

> combinatorially possible.

I'm afraid you don't distinguish "name" and "label".

Anyway, what if you encounter a label with 21 variants?

Are you saying registries MUST reject registrations requests for
domain names, if the numbeer of variants exceed 20?

Note that a single Chinese character frequently used in Japan
have, at least as I quickly checked, 6 variants, which means
your limit can easily and naturally be exceeded.

Or, how many variants, do you think, a '-' character, which
is a legal ASCII character for hostnames, have?

>> Thus, the only solution against it is to give it up.

Even before the beginning, yes, it has been.

						Masataka Ohta

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 May 2014 12:38:44 +0100

Saku Ytti <[email-masked]> wrote:

> Any opinions on SVCINFO. I was really big fan of SRV until I read the

It doesn't provide indirection, and it piles potentially-unrelated SVCINFO
records on to the same QNAME. It would be better to prefix the QNAME with
_service (e.g. _http) and provide target hostname, protocol, and port
information in the RDATA.

> how it wants to connect to service, SVCINFO delivers this.

SVCINFO still requires concurrent A and AAAA queries.

> If we had had SVINFO (or even SRV) for years, we'd likely have less BGP bloat,

I don't see how it does anything to reduce the need for anycast.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: South or southeast, backing east for a time, 4 or 5,
occasionally 6. Slight or moderate. Thundery showers, fog patches. Moderate or
poor, occasionally very poor.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 20:48:15 +0900

> since different MTAs disagree about whether this implies an email address

What? A CNAME, redirection purely within DNS, rewrites an email
address?

Can you provide some specific examples, because a possible use
of SRV:

	_smtp._tcp.example.com. SRV ... mx.example.com.

can cause a similar problem.

						Masataka Ohta

PS

Does someone support:

	example.com NS ns.example.com
	_domain._udp.ns.example.com SRV ... ns.example.net

?

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 May 2014 12:53:44 +0100

> What? A CNAME, redirection purely within DNS, rewrites an email

See RFC 1123 section 5.2.2. This requirement was dropped in RFC 2821 and
successors.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Shannon: Northerly 6 to gale 8. Rough or very rough. Showers. Good.

---

From: Saku Ytti <[email-masked]>
Date: Wed, 21 May 2014 15:33:24 +0300

On (2014-05-21 12:38 +0100), Tony Finch wrote:

Hi,

> SVCINFO still requires concurrent A and AAAA queries.

Until newer versions of current protocols replace current protocols and
mandate SVCINFO (or requivalent) at which case client has no need to query for
anything else.
Some services mandate SRV, but even then they must query A/AAAA as well, with
SVINFO they wouldn't need to.

---- 2.3 ----
   In all cases when an SVCINFO record is returned, all A and AAAA record for
   the domain SHOULD be returned in the additional information section.  This
   eliminates excess queries without adding additional risk of cache
   poisoning.
-------------

> I don't see how it does anything to reduce the need for anycast.

It would not reduce need for anycasting, but that is not the common
application for BGP. Most typically you have no geographical diversity or
deliver-to-closest-exit strategy, you have single location, but vou need
global BGP visibility to offer your service to clients even in absense of
single connection.
If DNS could (like SRV could) tell alternative options, then client could mask
the outage of single connection, not requiring server to be have redundant
connection with single IP.

-- 
  ++ytti

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 21 May 2014 15:01:36 +0200

> is a legal ASCII character for hostnames, have?

The idea is that the registrant simply decides which of the variants he wants to 
have included with his original name. Those would be added to the zone via 
redirection resource records, whatever available. When he reaches a registry 
given limit, he has to make a trade-off, which of the possible variants he 
regards as most valuable for his purpose. From my perspective, this is an 
acceptable compromise. Otherwise, the only solution to cope with the exponential 
number of variants would be to add logic about human languages and scripts 
directly into the name servers that serve the respective TLD. They would have to 
identify the base name, and synthesize and sign respective answers on the fly. 
Besides the technical challenge, I am sure ICANN would not be pleased about this 
(thinking of zone file access, escrow and the explicit ban of redirecting 
unregistered names as Verisign once did, which resembles this approach).

Regards,

Klaus

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 May 2014 00:16:06 +1000

In message <[email-masked]>, Ralf Weber writes:
> > please take into account that a CNAME + DNAME, the previously discussed BNA
> ME or the now discussed ENAME solution is still interesting for domain name r
> egistries that have to deal with (maybe lots of) IDN variants. I don't think 
> that SRV records are a viable solution for their use case.
> Just let me give you an operational subjective observation from dealing with 
> certain kinds of *NAME based redirection over 20 years running DNS servers. T
> hey caused mostly grief and problems since they been around. This of course i
> s caused by the different semantics (a CNAME redirects every record type, and
>  thus their can't be another record type at that node) compared to other reso
> urce records, that even the authors of some software did not understood (some
>  versions of bind could load CNAME and other data at the same node). Once peo
> ple understood this DNSSEC came around and changed that assumption again as e
> ven a CNAME needs signatures.

More that it was assumed that people would read the rfc and enforce
the prohibition themselves.  When that wasn't happening it was first
made into a warning '97 and fatal in '99.

>  same data. But I do not know of Registries/Registrars that picked that up. O
> r is there widespread deployment?
> 
> Now having an ENAME that initially will break all existing DNSSEC resolvers (
> Who can't validate any longer, because they don't support the algorithm yet) 
> is IMHO not the right message when we want people to deploy DNSSEC and especi
> ally do validation.

No, it will not break DNSSEC resolvers.  If you were to need to
use ENAME and you are signing then only validators that were aware
of ENAME would mark you as secure.  The existing validators would
treat you as insecure.  If you don't need the ENAME functionality
you would continue to use the existing algorithms when signing.

Introducing NSEC3 did not break existing validators.  Introducing
ENAME will not break existing validators.

> SRV has been defined for some time, there are applications using it and the a
> pplication we are most interested in the Browser has a much shorter update cy
> cle than the typical DNS Infrastructure, so why not use it, as they fallback/
> backwards compatibility mechanism also is there and understood (publish an A/
> AAAA record).
> 
> So lets go for it.
> 
> SO long
> -Ralf
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 May 2014 10:39:58 -0400

On Wed, May 21, 2014 at 10:50:42AM +0200, Klaus Malorny wrote:
> interesting for domain name registries that have to deal with (maybe
> lots of) IDN variants. I don't think that SRV records are a viable
> solution for their use case.

While this is true, xNAME remains a crummy way to handle variants.  We
discussed DNAME at length in the "Variant Issues Project Integrated
Issues Report", which is still available from ICANN last I checked.

The problem is not just that DNAME doesn't redirect the owner name
itself, because you could get around that with a little bit of
automation (at least at the registry).  The problem is that there's no
way to find out the total set.  If the claim of "variants" is that the
different variants of "the same label" are really completely
interchangable, then it is incoherent to assume that naïve
administrators will be able to configure their machines competently.
Therefore, every server offering service at a name that has variants
will need to be able to figure out all its names (http servers and
mail servers and so on all need to know the names by which they are
known).

ENAME doesn't solve this, because it's still a one-way pointer.  

One of the ideas I originally had for the SOPA record I proposed is
that you'd be able to extend it to include this sort of variant-policy
mechanism, and it's designed to be a two-way link.  So far, however,
I've had pretty negative reaction to that proposal.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dan York <[email-masked]>
Date: Wed, 21 May 2014 14:59:57 +0000

Commenting on deployment...

On May 20, 2014, at 11:11 PM, Mark Andrews <[email-masked]<mailto:[email-masked]>>
 wrote:

In message <[email-masked]<http://hpcl.titech.ac.jp>>, Masataka Ohta writes:
Mark Andrews wrote:

... which means it may take many years for it to happen (IF it happens).

I actually like the idea of the ENAME record, mostly because I find it simpler to configure, but I do wonder how we would ever get it deployed.

Over the past couple of years as we've been looking at what we can do to accelerate DNSSEC deployment, one of the barriers has been that many registrars and DNS hosting providers have simply not provided the ability for customers to enter in DNSSEC-related records through the GUIs that the customers use.  For instance, they can't enter in a DS record. There is no way for them to do this. I still have this problem with one of the registrars I use for several of my domains.  And when I've contacted registrars about why they haven't offered it there are the usual litany of excuses about how customers aren't asking for it, there's no business case, they don't want to add a field that might cause support issues, etc., etc.  This is changing now... but a major reason is probably that ICANN mandated that registrars had to support accepting these records (DS/DNSKEY) as part of the 2013 Registrar Accreditation Agreement (RAA).

Similarly, a few years back I had issues with several DNS hosting providers that were providing no way to enter AAAA records.  So if you wanted IPv6 you had to use a different DNS provider.  I haven't really looked... but I wonder how many DNS hosting providers do allow the entry of DNAME records.  (I just checked... and mine *does*, which is good.)

Many of us here on this list have no problem whatsoever running our own DNS servers, editing zone files (by hand, even), and other normal sysadmin things... this stuff is trivial for most/many of us.

But for "regular" users out there, they don't care about any of that.  All they want to do is have a website and email that works.  They just registered "toms.plumbing" and want to point that to their website... and ideally they'd like to do that WITHOUT the "www." on the front.  They want to go to their DNS hosting provider and enter the appropriate info in the GUI and just have it work.

If we are suggesting adding a new ENAME record, I think we need to think about how it will get out there to all the DNS hosting vendors - and also *why* they might be motivated to do so.

Similarly, with SRV records, I think part of the challenge is just helping people to understand what they have to do to configure them.  A CNAME record is super easy and simple to enter.  A SRV record is a lot more complicated:

_sip._tcp.example.com<http://tcp.example.com> 86400 IN SRV 10 10 5060 sipsvr.example.com<http://sipsvr.example.com>.

I don't even remember the format without looking it up... and while I understand the value of the priority and weighting fields, I don't think most people will care.  And yes, this is something that DNS hosting providers could conceivably hide behind a menu choice about redirecting your domain to another website or something like that.  But the DNS hosting provider has to do that... or more precisely the software they use has to do it.  The SRV records, at least, do seem to be supported by DNS hosting providers.  We'd just need applications and services to actually *use* them.

Personally, I wish we *could* just add a simple CNAME record at the zone apex... but I do understand why we can't in terms of the need to also support other services like email.

Whatever we come up with needs to be simple enough that DNS hosting providers can make it easily available to customers without having to make significant changes or incurring support issues.

My 2 cents,
Dan

P.S. I think the larger challenge for ENAME will be to get validators updated.  We're having a big enough challenge right now getting DNS resolvers updated to do DNSSEC validation - largely because DNS resolvers are installed on a ton of boxes like "home routers" that almost never get updated.  The path to getting those updated may involve replacement lifecycles on the level of years.

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 May 2014 01:07:57 +1000

Getting validators updated will just happen once the code is written.
Try to find a validator that doesn't accept NSEC3 records today.  It
is actually hard to do.  RFC 5155 is just over 6 years old at this
point.

Mark

---

From: "John Levine" <[email-masked]>
Date: 21 May 2014 17:43:21 -0000

>What? A CNAME, redirection purely within DNS, rewrites an email

Yes, of course.

See RFC 1123, section 5.2.2.

R's,
John

---

From: Ralf Weber <[email-masked]>
Date: Wed, 21 May 2014 23:23:36 +0200

Moin!

> made into a warning '97 and fatal in '99.
IMHO a software should not allow me to make incorrect entries. I think having the assumption that everybody editing a zone file would have read the RFCs is a bit far fetched.

> you would continue to use the existing algorithms when signing.
We have different definition of breaking. To me when a validator gives me an insecure on something that has DNSSEC signatures and proper secure delegation I consider that broken as it probably allows neat downgrade attacks.

> ENAME will not break existing validators.
NSEC3 was defined before the root was signed, so there was no real deployment. Now we have granted limited, but deployment on the authoritative as well as resolver/validator side. So we have to be much more careful on the impact of what we do to people who do the right thing (validating) now.

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 May 2014 08:25:21 +1000

In message <[email-masked]>, Ralf Weber writes:
> IMHO a software should not allow me to make incorrect entries. I think
> having the assumption that everybody editing a zone file would have read
> the RFCs is a bit far fetched.

Well if you want to complain about software that was fixed 15 years ago.

Additionally sometimes the software can't determine if something
is wrong or not.

	foo_bar.example.net CNAME foo-bar.example.com
	foo-bar.example.com A 1.2.3.4
	foo-bar.example.com TXT some text

does not make foo_bar.example.net a legal host name.  Some things do
need to be left to the zone adminstrators to do the correct thing.
 
> We have different definition of breaking. To me when a validator gives me
> an insecure on something that has DNSSEC signatures and proper secure
> delegation I consider that broken as it probably allows neat downgrade
> attacks.

DNSSEC has *never* been "has signatures, will be treated as secure".
You needed a chain of trust and common sets of algorithms for every
zone in that chain.

> NSEC3 was defined before the root was signed, so there was no real
> deployment. Now we have granted limited, but deployment on the
> authoritative as well as resolver/validator side. So we have to be much
> more careful on the impact of what we do to people who do the right thing
> (validating) now.

When the root was signed there were still lots of NSEC only validators
in use.

And given almost all infrastructure zones don't allow anything other
than delegations this will have no impact on them.  Nobody will be
forcing them to use the new algorithms to sign their zones until
they add a ENAME record.  That is the forcing operation on the
signer.

Today you can't tell a signer to generate NSEC3 chains if there are
any non-NSEC3 capable DNSKEYs in the zone.  You won't be able to add
ENAME records to a zone without all ENAME capable DNSKEYs.

Use of ENAME in infrastructure zones.

5 years after the publication of this rfc (<Month> <Year>) it will
be assumed that validators support ENAME.  Prior to this date
it is NOT RECOMMENDED that infrastructure zones be signed using
ENAME aware algorithms or use ENAME if they were signed using non
ENAME aware algorithms at the time of publication.  Additionally
after this date unless you intend to add ENAME records it is NOT
RECOMMENDED that ENAME aware algorithms be used in infrastructure
zones without further advice to the contrary.

This is intended to minimise the number of zones that will be go
from being treated as secure to insecure due to the use of ENAME
in a infrastructure zone.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 May 2014 08:49:04 +1000

> SVINFO they wouldn't need to.

Hog wash.  Both SRV and SVINFO supply addresses via additional section
processing.  Additional records like these are always optional.

Additionally SVINFO doesn't support indirection to different machines
which is one of the primary features of SRV.  The reason why CNAME like
functionality is wanted at the apex of a zone.  SVINFO doesn't come
close to being a alternative to ENAME or CNAME or SRV.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 May 2014 10:18:40 +0900

> The idea is that the registrant simply decides which of the variants he 
> wants to have included with his original name. Those would be added to 
> the zone via redirection resource records, whatever available. When he 
> reaches a registry given limit, he has to make a trade-off, which of the 
> possible variants he regards as most valuable for his purpose. From my 
> perspective, this is an acceptable compromise.

OK. If it is acceptable for you, allow 1 variant per name and we
are done.

That people around you are happy with at most 5 or 20 variants
does not mean other people needing more variants may suffer
from the trade-off.

A better solution is never use IDN. That, even within European
(French) context, capital form of 'y' with diaeresis can be 'Y'
or 'Y' with diaeresis is already bad enough for case insensitive
DNS.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 May 2014 11:02:29 +0900

> See RFC 1123 section 5.2.2. This requirement was dropped in RFC 2821 and

Perhaps, it is a misunderstanding of a suggestion of rfc974:

   Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
   a alias and the alias is listed in the MX records for REMOTE.  (E.g.
   REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
   can be avoided if aliases are never used in the data section of MX
   RRs.

and is just wrong from the beginning. Then, we don't have to
think about it any more.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 May 2014 12:58:54 +0900

> Goal should be that 1 query returns all the information client

The problem of URI and SVCINFO RRs is that they return too much
information.

With SVCINFO, browsers don't know how to interprete "InstanceId".

Note that port number returned from SRV is already too much.

Though SVCINFO draft says:

   There are two concerns with SRV.  First, one
   must indicate the transport protocol as part of the QNAME.  This
   means that discovery of multiple transport protocols requires
   multiple queries.

for browsers,

	_proto.example.com. SRV ...

should be better. The second problem in the draft merely
means that, with SRVINFO, when there are a lot of
SRVINFO RRs at "example.com", "example.com" will be a zone.

					Masataka Ohta

---

From: S Moonesamy <[email-masked]>
Date: Wed, 21 May 2014 22:00:26 -0700

Hi John,
>See RFC 1123, section 5.2.2.

Tony Finch already commented about RFC 1123.  That section has been 
replaced (see RFC 5321).  Section 8.7 of RFC 6409 is applicable for 
mail submission and CNAME.

Regards,
S. Moonesamy

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 May 2014 15:46:31 +0900

(2014/05/22 14:00), S Moonesamy wrote:
> replaced (see RFC 5321).  Section 8.7 of RFC 6409 is applicable for mail 
> submission and CNAME.

What rfc1123 prohibit with no good reason is using
"[email-masked]" as a mail address in MAIL and RCPT, when:

	bar.example.com CNAME mail.example.com
	mail.example.com MX ...

even though it is a valid configuration explicitly admitted in rfc974,
whereas rfc974 mentions (and rfc5321 forbids):

	cname.example.com CNAME mx.example.com
	mail.example.com MX 0 cname.example.com
                         MX 1 other.example.com
	                 MX 2 mx.example.com

may cause a mail loop, if mx.example.com receives mail to

	mail.example.com MX 0 cname.example.com

misunderstanding that they are to

	                 MX 2 mx.example.com

It is not a problem if mail software properly recognize host
identity including aliases.

					Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 May 2014 17:08:34 +1000

> 	bar.example.com CNAME mail.example.com

Why are you complaining about this?  Do you have a time machine to
correct it?  The prohibition has been removed but we still need
to be aware that it existed, that there are MUA that still re-write
based on the CNAME and it impacts on the solution space.

Just use CNAME has negative consequences.

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 May 2014 10:34:09 +0100

>    can be avoided if aliases are never used in the data section of MX

No, that's about MX pointing at CNAME, which is frowned on but generally
works. The fix for the problem mentioned in the quote above is to resolve
MX targets all the way to IP addresses before discarding ones after the
current host, instead of relying on host names only.

CNAME pointing at MX is a different problem, which does not work
consistently in practice. The requirement in RFC 1123 is a restatement of
RFC 821 section 3.7 (last paragraph) and page 30 (penultimte paragraph).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: Northerly 6 to gale 8, but 5 at first in east. Moderate at first in
southeast, otherwise rough or very rough. Rain or showers. Good, occasionally
poor.

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 22 May 2014 11:37:44 +0200

> or 'Y' with diaeresis is already bad enough for case insensitive

What's the purpose of this comment? Are you saying that you don't care about 
real world problems? Get rid of IDNs? Learn English or die? Internet back to its 
roots as an academic, non-commerical network? This all would be fine to me, but 
unfortunately not to many people out there.

Regards,

Klaus

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 May 2014 11:51:09 +0100

S Moonesamy <[email-masked]> wrote:
>
> Section 8.7 of RFC 6409 is applicable for mail submission and CNAME.

Whoops, the second paragraph of that section is completely incorrect.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger, Fisher, German Bight, Humber: Cyclonic 5 to 7, occasionally gale
8 at first in Dogger and Humber, becoming variable mainly northeast 4 or 5.
Slight or moderate, occasionally rough at first. Rain or thundery showers, fog
patches. Moderate, occasionally very poor.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 23 May 2014 14:25:23 +0900

Tony Finch wrote:

> No, that's about MX pointing at CNAME,

> CNAME pointing at MX is a different problem,

There is an interesting history of confusion. See below.

> The requirement in RFC 1123 is a restatement of

At that time, there was no MX-like mechanism in domain names
and rfc819 discusess domain->address mapping only. A mail
to a domain is delivered to domain's address.

As such, rfc974 specifies:

   It is possible that the list of MXs in the response to the query will
   be empty.  This is a special case.  If the list is empty, mailers
   should treat it as if it contained one RR, an MX RR with a preference
   value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
   MX).

Thus, what rfc821 prohibits is alias->address, CNAME pointing to
A, with an obvious reason to prevent mail loops, if mail software
is not robust enough not to be able to recognize its identity
involving aliases.

With introduction of MX, what should have been prohibited is
still CNAME pointing to A, that is, MX pointing to CNAME then
to A (as rfc974 mentions), not CNAME pointing to MX (rfc1123).

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 23 May 2014 14:37:08 +0900

> What's the purpose of this comment? Are you saying that you don't care 
> about real world problems?

I'm saying you should accept the real world problems of:

	other people needing more variants may suffer
	from the trade-off.

and

	That, even within European
	(French) context, capital form of 'y' with diaeresis can be
	'Y' or 'Y' with diaeresis is already bad enough for case
	insensitive DNS.

> Get rid of IDNs?

Yes.

As it is obvious from the beginning that IDN is not practical,
I have been saying so.

> Learn English or die? 

No, as can be seen names on passport, internationally, every
country have a scripting system to represent their language
in ASCII.

Though some European country may insist that their passport
may include Latin-1, it is not fair for the rest of the
people who can't use their traditional script.

> Internet back to its roots as an academic, non-commerical network? This 
> all would be fine to me, but unfortunately not to many people out there.

A commercial network can not support something operationally
impossible or, at least, impractical.

						Masataka Ohta

PS

As I repeatedly state, so called IDN is not internationalized at
all and actually is localized DN, whereas ASCII DN is, like
ASCII names in passports, fully internationalized.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 23 May 2014 08:30:46 +0000

> draft, it made really compelling arguments to me.

It looks interesting.

I had a long conversation last night with Martin Thomson, editor of the HTTP/2.0 draft and now employed at Mozilla.

I've made him aware of the update to Mark's HTTP SRV draft, but there appears to be a problem that SVCINFO addresses that SRV doesn't, namely declaration (or discovery) of which version of the protocol is supported by the endpoint.

Given that the CNAME at the Apex problem appears to be mostly (entirely?) an HTTP-related problem, it seems to me we ought to be engaging more with HTTPbis to help them come up with a solution that's mutually acceptable and doesn't involve breaking DNSSEC.

Ray

---

From: Saku Ytti <[email-masked]>
Date: Fri, 23 May 2014 11:51:19 +0300

> I've made him aware of the update to Mark's HTTP SRV draft, but there appears to be a problem that SVCINFO addresses that SRV doesn't, namely declaration (or discovery) of which version of the prot…

ACK. We have great window of opportunity with HTTP2 to mandate use of some RR
which delivers all information client needs to make informed decision how to
redundantly access web service.
Then we can reduce client query to 1 and gain new services and reduce need for
having single redundantly routed address for web server.

-- 
  ++ytti

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 May 2014 11:47:17 -0400

> Given that the CNAME at the Apex problem appears to be mostly (entirely?) an HTTP-related problem, it seems to me we ought to be engaging more with HTTPbis to help them come up with a solution that…

I've been talking privately with some knowledgable httpbis folks about having a special joint session at IETF 90 where we can focus on this topic and hopefully come to a mutual understanding of the problems and opportunities.   Would people be interested in attending such a meeting?

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 May 2014 11:54:52 -0400

> I've been talking privately with some knowledgable httpbis folks about having a special joint session at IETF 90 where we can focus on this topic and hopefully come to a mutual understanding of the…

I would.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 May 2014 13:06:13 -0400

> I've been talking privately with some knowledgable httpbis folks about having a special joint session at IETF 90 where we can focus on this topic and hopefully come to a mutual understanding of the…

I'd certainly show.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 23 May 2014 13:28:39 -0400

> I've been talking privately with some knowledgable httpbis folks about having a special joint session at IETF 90 where we can focus on this topic and hopefully come to a mutual understanding of the…

That's great. I wrote a note to myself to reach out to mnot and Martin 
when I returned from the weekend.

tim

---

From: "John Levine" <[email-masked]>
Date: 23 May 2014 18:03:25 -0000

>> I've been talking privately with some knowledgable httpbis folks about having a special joint
>session at IETF 90 where we can focus on this topic and hopefully come to a mutual understanding of
>the problems and opportunities.   Would people be interested in attending such a meeting?
>> 
>
>I'd certainly show.

Me too.  It's also an SMTP issue but I expect that anything that works for http is likely
to be adaptable to SMTP as well.

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Sat, 24 May 2014 09:13:31 +0000

Absolutely!

Ray

Sent from my iPhone

> On 23 May 2014, at 16:47, "Ted Lemon" <[email-masked]> wrote:
>

---

From: Florian Weimer <[email-masked]>
Date: Sat, 24 May 2014 23:58:25 +0200

> the zone support it.  It would just be insecure until validators

Uhm.  Why insecure and not bogus?

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 24 May 2014 18:43:59 -0400

> Uhm.  Why insecure and not bogus?

Mark's plan includes an algorithm number change.  If you're a
validator and the signing algo is one you don't know, then it's an
insecure delegation, not a bogus one.

I note that this means that DANE type approaches won't work reliably
with ENAME until everyone has upgraded validators.

A

-- 
Andrew Sullivan
[email-masked]