Subject: [dnsext] DNSEXT progress and possible meeting at IETF-80

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 01 Feb 2011 14:39:42 -0500

At this point the chairs are not sure there is a reason to have a meeting.
We have a number of work items that can be discussed on the mailing list 
or wait on chair action.

There is one ttem that seems to have died, "Aliasing Requirements".
Unless there is movement on that document we can not adopt any new 
aliasing proposed changes.

The chairs will make a final call on meeting in about 10 days.

	Olafur & Andrew

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 10 Feb 2011 16:11:54 +0200

Dear Chairs,

We as the Registry of [.gr] domain names are still very much interested in
the Aliasing Requirements item and the development of a "xNAME" identical
tree solution.

We would be very happy to produce a comment of this document. If there is
anyone else interested in that please feel free to contact me.

Kind Regards,

Vaggelis Segredakis
Administrator of the .GR Top Level Domain
Institute of Computer Science
Foundation for Research and Technology - Hellas
Tel. +30-281-0391450
Fax +30-281-0391451
Email [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Olafur Gudmundsson
Sent: Tuesday, February 01, 2011 9:40 PM
To: [email-masked]
Subject: [dnsext] DNSEXT progress and possible meeting at IETF-80

	Olafur & Andrew

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 11 Feb 2011 02:01:25 +0000

> the Aliasing Requirements item and the development of a "xNAME" identical

This is good to know, as I am working on the -00 (WG item) of the
identical-resolution draft; it's behind schedule but definitely not
forgotten.

I expect to be in Prague and would work with you (or anyone
interested) there, as well as in email until then.

> anyone else interested in that please feel free to contact me.

This would be helpful.

thanks,
Suzanne

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Fri, 11 Feb 2011 18:17:16 +0200

Dear Suzanne,

Having read your analysis in the document
draft-yao-dnsext-identical-resolution-02.pdf I would like to raise some
points of discussion.

The analysis was thorough and it explains very well the issues at hand for
the registries with variant IDN registrations. Although we have been advised
to create bundles or variants of domain names, their behavior was never
explained as a mechanism.

As the Greek registry, offering registrations in Greek characters presented
the problem with the accent mark "tonos" which is used in the majority of
Greek words. In capital letters however, the same words are spelled without
the tonos. Their representation in the Punycode is unfortunately different
and we had to match these up (make similar) for the user, otherwise the user
experience of case-insensitivity would be lost. We used the DNAME mechanism
with not very satisfactory results.

The revision of the IDNA protocol to IDNA2008 brought forward two other
issues:
1. The mapping of the upper case letters to the lower case is no longer a
feature of the protocol but rather a task of the application. This way we
cannot have consistent mappings since we do not know what the programmer has
chosen to do with the upper case characters, especially in regards to tonos
and final sigma.
2. The final sigma letter which is a representation of the small case sigma
when at the end of the word and not a letter by itself is represented in the
new protocol as a standalone character. This is good in a sense, since
almost all male names and surnames and numerous other words end in a final
sigma which was misrepresented. However -maybe you guessed it- the same
words, when spelled in upper case letters do not have a final sigma but
instead the normal one.

Your document has also raised the issue of "confusing similar visuality"
[Page 12] (Homographs) which although present in the Greek to Latin alphabet
similarities was solved by regulation and was not really a problem of DNS.
Our solution can be found at the address
https://grweb.ics.forth.gr/homographs.jsp?lang=en. 

We are in favor of a solution of the BNAME type proposal. We do not intend
to SHADOW the .gr zone to another one but we would really like to "make
similar" a great number of IDN domain names that will have variants. This
way, while a SHADOW would be helpful only to our registrants wishing to
"make similar" the variants themselves we as a registry would like to
provide to our registrants the easiest solution of not having to deal
extensively with DNS. The registrant could just ask the registry to provide
the "sameness" for the variants in the BNAME form.

These are two completely different solutions and they have been asked by
different people for different cases. The word "similar" or "same" is
confusing but the needs presented are totally different. The SHADOW is a
request by registries that have multiple TLDs in different(?) character sets
and they want them to operate as one. The BNAME solution is suitable for a
TLD that wants to register variants and comply with the RFC3743 idea of
equivalence of labels and bundled names.

I would be very happy if your issue-analysis document turns into a solution
or even two, since these two are not even close, although BNAME would be a
solution even for shadow TLD zones as well, if it was to be used directly in
the root zone files.

I hope that Olafur in his email on the 1st of February was mistaken when he
declared the item "Aliasing Requirements" dead and a discussion will take
place in the next DNSSEC meeting to initiate the solution procedure.

Thank you for your document and I look forward to your next draft. I would
be glad to assist in any way possible.

Vaggelis Segredakis

P.S. The http://users.isc.org/~woolf web site mentioned in the draft is not
accessible.

-----Original Message-----
From: Suzanne Woolf [mailto:[email-masked]] 
Sent: Friday, February 11, 2011 4:01 AM
To: Vaggelis Segredakis
Cc: 'Olafur Gudmundsson'; [email-masked]
Subject: Re: [dnsext] DNSEXT progress and possible meeting at IETF-80

This would be helpful.

thanks,
Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 14 Feb 2011 07:10:47 +0000

> with not very satisfactory results.

The previous version of the document used your previous messages on
Greek as an example of the "bundling" requirement, however I can't
find any previous reference to specific problems you might have had
with DNAME. Could you elaborate?

> chosen to do with the upper case characters, especially in regards to tonos

This uncertainty about what the application will do with "bundled"
names as far as treating them "the same" seems to be the underlying
concern that motivates all the discussion we've had about adding
functionality to the DNS to support the "sameness" property.

However, it's also been strongly argued here that there's no way to
support "aliases" in the DNS without application support, particularly
without introducing inconsistencies in handling of certificates and
other objects that rely on domain names. So the tension that needs to
be explained in the next version of the document is between the need
for providing this kind of "help" to applications, and the challenge
of getting them to use it.

> the "sameness" for the variants in the BNAME form.

The thing that worries me about this is that the registry can provide
BNAMEs, but if applications don't make use of the "sameness"
semantics, we haven't really gained anything....

> I hope that Olafur in his email on the 1st of February was mistaken
> when he declared the item "Aliasing Requirements" dead and a
> discussion will take place in the next DNSSEC meeting to initiate
> the solution procedure.

The requirements document is a WG item under the recent charter, and
it remains my intent (as I believe Olafur knows) to make sure the
document is completed as an Informational RFC in the near future. The
work item isn't done until the WG has decided one way or another
whether to pursue additional work on the subject, so I'll respectfully
disagree with Olafur's assertion.

Whether there's a meeting of DNSEXT in Prague or not, the WG version
of this draft will ship soon so we can continue the discussion.

best,
Suzanne

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Mon, 14 Feb 2011 17:05:02 +0200

Dear Suzanne,

>with DNAME. Could you elaborate?

We have given the DNAME option to our registrants for less hassle in setting
up their DNS. Although it is OK if you just try to set
www.name1.gr=www.name2.gr, unfortunately you cannot use it to send
[email-masked] and expect it to arrive to [email-masked] because
name1.gr<>name2.gr. This way, our actual assistance to the registrant is
very limited and anyone choosing not to set up a zone for each name of the
bundle gets limited operation for the rest of the bundle names. 

As I explained before, since a user expects to type a domain name with tonos
or the same domain without the tonos and end up with the same result
(remember, in Greek words are spelled with tonos in small case letters but
without in Caps) the user experience is severely damaged when this is not
happening flawlessly, as expected if the domain was in Latin. We try to find
a solution to amend this issue and we came to the conclusion that a BNAME
sort of solution is necessary.

>of getting them to use it.

I can understand that a number of issues would need to be sorted before such
a solution could be used. However I believe that there is a need for it.
Furthermore, there is a logical gap between CNAME and DNAME if CNAME+DNAME
cannot co-exist and we do nothing to change this.

>semantics, we haven't really gained anything....

I expect it could take some time for the applications to adapt to such a
solution but I keep reminding to myself that DNAME as well took some time to
be deployed although it was a useful add-on to the DNS.

>of this draft will ship soon so we can continue the discussion.

This is very good to know :)

Best,

Vaggelis Segredakis

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Feb 2011 11:37:43 -0500

> a solution could be used. However I believe that there is a need for it.

Speaking only for myself, this is the crux of the issue.  What you're
saying is that the technology is needed, but the objection that some
have raised is that such a technology won't really work except in the
most trivial cases.  Since the trivial cases could just as easily be
solved with DNAME + other records at the apex, it's hard to justify
making a big change to the protocol.

Now, if the suggestion is that the parent _needs to_ enforce policies
in the tree underneath the parent, then we have a different argument,
because DNAME on the parent side won't really work for this purpose.

Speaking as co-chair but without having run this text past Olafur: in
respect of having a meeting, the issue is that we've already talked
about this topic a lot in meetings.  We discussed it at length in
Anaheim, had a special session about it in Maastricht, devoted meeting
time to in Beijing, and even had an interim teleconference.  But in
between those events very little discussion on the topic seems to have
happened.  Moreover, when we do have discussion it tends to focus on
existing proposals: "Do BNAME", for instance.  But the problem we have
is that we cannot tell whether BNAME (or any other proposal) actually
addresses the particular problems people have.  So either we get a
clear and broadly agreed-upon statement of the problem we are trying
to solve, or we don't solve the problem (because if we can't say what
it is, I think that means we don't know).

Best,

Andrew

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

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 14 Feb 2011 16:57:05 +0000

On Mon, Feb 14, 2011 at 11:37:43AM -0500, Andrew Sullivan wrote:
> But in

With all due respect, I'm not sure this is the most (or at least only)
useful razor for where we are at the moment.

I went back and looked at the problem statement draft after being
forced to put it aside for other things for some time. What I'm seeing
is that it has a couple of examples, and could benefit from more, and
needs to more clearly state the potential protocol issues around
application awareness, special processing, etc....

But the other thing we haven't talked about much is the actual
requirements for solutions. We did once (in Anaheim maybe?) but IIRC
only the once.

The main piece that the -00 will have that the previous individual
submission versions didn't, I think now, will be the list of what we
think a solution should look like....not in the protocol details of
behavior, I agree we won't know those without finer details of the
problems (probably plural) we're talking about....but in the sense of
things like:

* A solution must not break DNSSEC;
* A solution must not (should not?) require client changes to be useful;
* A solution must not change existing behavior of established RRtypes and
  protocol (which would make "fix CNAME" a non-starter);
* A solution should clearly either be less work than existing techniques, or
  solve some specific case (such as the canonicalization of email
  addresses that Vaggelis mentioned) that isn't otherwise solvable, so there's
  some incentive for deployment....
* A solution should not be specific to the root zone;

etc.

best,
S.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Feb 2011 12:40:58 -0500

No hat

> requirements for solutions. We did once (in Anaheim maybe?) but IIRC

Yes, I fully agree.  But what that amounts to are parameters for the
trade-offs we need to make, and that _again_ requires WG discussion
and so on.  When the WG doesn't discuss such issues, it makes me think
that it isn't that interested.  That's all I meant.

A

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

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Feb 2011 08:48:24 +0900

Vaggelis Segredakis wrote:

> the tonos.

The problem already occurs in ISO 8859/1 with 'y' with diaeresis,
upper case of which is plain 'Y' without diaeresis.

> Their representation in the Punycode is unfortunately different
> and we had to match these up (make similar) for the user,

Definitions, such as case correspondence, in Unicode are not definitions
useful in the real world, which means Unicode is
useless.

> We used the DNAME mechanism with not very satisfactory results.

Suppose you have a label:

	YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY.com

You can match it with:

	YyYYYyYYYYYYyYYYYyYYYYyYYYyYYyYYYyYYYYYyYYyYYyYyYY.com
easily because case correspondence is recognized by DNS protocol.

But, if you want to do the same thing with 'y' with diaeresis,
you can't do it with predefined BNAME/CNAME/DNAME, because of
exponentially many aliases.

However, dynamic generation of *NAME causes performance problem
with secure DNS.

So, you should give up localized DNS, secure DNS or have common
definition on extended case insensitivity (not really defined
in Unicode) between DNS servers and (security aware) clients.

My recommendation is to give up both.

> This way we cannot have consistent mappings since we do not know
> what the programmer has chosen to do with the upper case
> characters, especially in regards to tonos and final sigma.

For precise definitions of extended case insensitivity, we need
a formal language for extended case insensitivity description.

Locale dependent case insensitivity for localized domain names
requires locale information somehow supplied through DNS.

						Masataka Ohta

---

From: John Levine <[email-masked]>
Date: 16 Feb 2011 03:21:20 -0000

>* A solution must not (should not?) require client changes to be useful;

To me this is the key issue.

If you just want something that will return similar DNS records for all
of variants of a name, the technical issues are pretty straightforward.

But as has often been noted, many protocols such as HTTP and SMTP
depend on the actual domain name, so nothing the DNS does to make
stuff "the same" will make variants of a domain name work.
Considering the number of variants that a name can have, e.g., M^N for
any name with N characters that have M variants, any approach that
provisions the HTTP and SMTP servers manually is likely to fail in
practice, since the various lists of equivalent domains will always
get out of sync.

It would not be absurd to argue that the most reasonable way to solve
the provisioning issues is for the SMTP and HTTP servers to ask the
DNS what the canonical name for an otherwise unknown name is, so those
servers are just provisioned with the canonical name and an "allow
variants" flag.

I'm pretty tight with the SMTP crowd, and I have no idea how such a
proposal would be received, although once they understand the problem,
I suspect they'd eventually agree this was the least bad option.  No
idea what HTTP and any other protocols that use the domain name would
do, but I think it's the reasonable approach.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Jay Ashworth <[email-masked]>
Date: Tue, 15 Feb 2011 23:17:48 -0500 (EST)

----- Original Message -----
> From: "John Levine" <[email-masked]>

> practice, since the various lists of equivalent domains will always

And, as has been pointed out in some other venues, and which seems 
applicable here also, some approachs to certain things *depend on trying
a DNS lookup and having it break*.  I'm damned if I can remember what
the canonical example was, but it fell in the general category of 
"please don't make this change to try to 'help' 'the web', cause you'll
break *my* protocol which isn't http".

Cheers,
-- jra

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Feb 2011 14:20:01 +0900

> To me this is the key issue.

So true.

Clients should have remained as they were only allowing ASCII
domain names.

> DNS what the canonical name for an otherwise unknown name is,

Are you requesting DNS hold huge database on exponentially many
(millions or billions of) variations?

						Masataka Ohta

---

From: John Levine <[email-masked]>
Date: 16 Feb 2011 07:33:38 -0000

>(millions or billions of) variations?

Yes, but of course that does not mean it needs millions or billions
of records stored in servers.

A DNS wildcard matches a very large number of names, roughly
2^(8*(63-K)) where K is the length of the name after the star, but a
DNS server handles that with one pattern record and an algorithm that
tells the server how to match queries with the pattern.

The pattern language for encoding variant names would probably be more
complex than people would like, but if we are serious that all the
spellings of Greek words are equivalent, or traditional and simplified
Chinese are equivalent, I don't see how anything simpler could do the
job.

Regards,

---

From: Alex Bligh <[email-masked]>
Date: Wed, 16 Feb 2011 07:43:30 +0000

> Chinese are equivalent, I don't see how anything simpler could do the

The fact that 2 or more spellings (*) are equivalent does not necessarily
mean both always need to give the same DNS results; indeed as much
trailed previously, this may be undesirable. I still think this is the
wrong "job" to do, so the fact this is might be simplest way of doing
something undesirable is not really a positive. However, except in
the cases of combinatorial explosion, manual provisioning would seem
to be far simpler.

(*) I think it's really about orthographic representation rather than
spelling: we aren't really talking about jail.com and gaol.com, are
we?

-- 
Alex Bligh

---

From: "John R. Levine" <[email-masked]>
Date: 16 Feb 2011 00:02:15 -0800

> However, except in the cases of combinatorial explosion, manual 
> provisioning would seem to be far simpler.

I think you will find that combinatorial explosion is the norm, not the 
exception, in cases where you want multiple names to be equivalent. Or if 
it's not the rule, it is common enough that any attempted solution that 
doesn't handle large sets of equivalent names isn't good enough to be 
worth doing.

I also have a general dislike of any design that requires two things to be 
kept in sync manually, with random failures if they're not.  If a set of 
names really is all equivalent, wouldn't it be better in the long run for 
people to configure the set once rather than once per server?

Regards,

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Feb 2011 17:04:57 +0900

> Chinese are equivalent, I don't see how anything simpler could do the

I'm happy that you seems to have reached the same conclusion
as mine:

: For precise definitions of extended case insensitivity, we need
: a formal language for extended case insensitivity description.

But, then, the issue is purely about character encoding which
is better handled by clients outside of DNS.

Note that people working on secure DNS (I'm not) won't welcome
proposals to support yet another type of wild card.

Or, if you think pattern should be locale dependent, I agree
that its support must involve DNS protocol. Locale information
must be supplied from DNS, at least.

						Masataka Ohta

---

From: Alex Bligh <[email-masked]>
Date: Wed, 16 Feb 2011 08:35:23 +0000

--On 16 February 2011 00:02:15 -0800 "John R. Levine" <[email-masked]> 
wrote:

>  If a set of names really is all equivalent, wouldn't it be better in the
> long run for people to configure the set once rather than once per server?

I think we've been round this loop and determined that for most/many
applications there is /still/ manual configuration (see SSL cert DN
for example).

An alternative would be to do this at a higher presentation layer (e.g.
the search engine), and cope with the fact that despite there being >1
equivalent representation, there is a smaller number of canonical ones
(perhaps one) that work. I'm not convinced alex-bligh.com and alexbligh.com
are not equivalent - or for that matter alex.bligh.com; just because I
get one to work, it doesn't mean the others work automatically.

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Feb 2011 11:55:57 +0000

> servers are just provisioned with the canonical name and an "allow

It used to be the case that SMTP servers would rewrite domains in
addresses by replacing a CNAME owner with its target. See RFC 1123 section
5.2.2. This requirement no longer exists but there is still code out there
that supports it. I think it would be quite reasonable to add a feature
for optional cname-based canonicalization to an MTA. (You can probably do
it now using Exim's configuration language, though it'll probably be a bit
ugly.)

There is also some HTTP server code out there that hooks into the DNS for
server name canonicalization - see Apache's UseCanonicalName DNS option,
which is my fault. It uses reverse DNS lookups (it was designed for
IP-based virtual hosting) but I don't think it would be hard to do
something similar based on CNAME records.

Note that server features like this are nice to have but not absolutely
necessary.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Feb 2011 22:21:52 +0900

John R. Levine wrote:

> I also have a general dislike of any design that requires two things to 
> be kept in sync manually, with random failures if they're not. If a set 
> of names really is all equivalent, wouldn't it be better in the long run 
> for people to configure the set once rather than once per server?

Equivalence rule must run very long, maybe forever.

Or, if the rule is not stable, we shouldn't start registration
only to cause conflicts between registered names before and
after rule changes.

With the stable rule in hand, we can expect the rule configured
in factory on all clients.

The problem, of course, is how can we have the stable rule.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Feb 2011 23:05:19 +0900

Tony Finch wrote:

> I think it would be quite reasonable to add a feature
> for optional cname-based canonicalization to an MTA.

It does not address the exponential explosions.

Worse, it requires CNAME target canonicalized, which practically
means canonicalization by hand.

						Masataka Ohta

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Wed, 16 Feb 2011 16:37:13 +0200

John,

Please do not misunderstand the issue here. We did not ask for a wildcard in
DNS, we did not ask for millions of domain names to become one bundle.

We did however ask for the user's choice of registered domain names, the
names he thinks represent better the word he chose for registration to act
as a bundle.

The number of these domain names varies from two (or four if a final sigma
is present) to some tens of domains, not millions and certainly not
billions. The names are specific, not names with star-substituted
characters; just handpicked domain names by the user that should point to
the same services since one user will type them this way while the next user
will type them in an alternative form.

We did not say anything about a pattern to match domain names that look the
same in a language. We asked for a DNS rr that will allow two, three, four,
or tens of chosen domain names to act as if they were interchangeable in all
the branches of the domain name tree, starting from the top. They could be
perfectly normal Latin domain names that point to the same services and the
administrator decides to administer them as one.

Kind Regards,

Vaggelis Segredakis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Levine
Sent: Wednesday, February 16, 2011 9:34 AM
To: [email-masked]
Subject: Re: [dnsext] we need help to make names the same,was
draft-yao-dnsext-identical-resolution-02 comment

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for
Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Feb 2011 11:59:21 -0500

> names he thinks represent better the word he chose for registration to act

As a matter of _protocol_, however, what you asked for devolves to
"more than two".  Once we're at that point, the size of the set
doesn't really matter except for the question of where the trade-off
will be for performance reasons.

Moreover, you're not the only one asking.  This is certainly not a WG
devoted to solving the problem of how to make things easier for the
.gr registry.  Whatever we do has to be a significant improvement for
many different kinds of uses, or it's not worth changing the protocol,
even if that means you lose.  Sorry.

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Feb 2011 12:14:30 -0500

> spelling: we aren't really talking about jail.com and gaol.com, are

As co-chair but without having discussed with Olafur: We are talking
about whatever zone administrators want to be equivalent, I think.
This absolutely is not, no way, the DNS and Linguistic Harmony
Extenions Working Group.  We are not well enough versed in the
linguistic differences between two different spellings "in English"
and the two scripts that are used to write Chinese for us to begin to
make decisions on the basis of that sort of distinction.

No hat: One of the possibilities I think could come of the
requirements assessment is that something new is needed: the desires
that people have for locale-sensitive representations in the naming
system on the Internet perhaps simply cannot be accommodated in the
actual DNS as it is deployed and can realistically be modified.  This
amounts to saying, "We are at the end of incremental improvements of
this sort for the DNS, and if people want new features, they have to
go invent DNSng."  That is a legitimate possible answer if we look
very hard at the problems we are trying to solve, even if we don't
like it.

This is why I, at least, have been adamant that we need a problem
statement before we start trying to solve the problem.  It would be a
bad thing to add a bunch of complications that don't actually address
the real problems.  This is also why I have been so unhappy that we
have attracted little interest from the applications area crowd, who
will have to use anything we end up delivering.  If we can't tell
whether what we are talking about looks like a real problem to (say)
web browser writers, how will we know whether what we propose to do is
going to have any effect?

A

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

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 16 Feb 2011 17:23:33 +0000

> even if that means you lose.  Sorry.

To which I reply:
  In principle, universal solutions trump narrow solutions that cover fewer use cases.
BUT ...
  So far, this thread has touched on/drifted towards VERY difficult problems, with
alleged combinatorial explosions and other evils.

Vaggelis seemed to suggest that those allegations might not be important in practice.
Almost all registries will have rules on bundling and mapping. Thus one may not need
to "solve for infinity" to reach a solution that covers many or even most cases.
His comment appeared reasonable (to me :), in rebutting allegations of impossibility.

If I can count the number of "shadows" with my fingers, that seems to ME to be a tad
different from millions of potential domains.

The requirements capture is running apace. It seemed that some were starting to claim
that the (quantum superposed) kitchen sink needed to be in there as well.
We need to know what this is trying to solve, but I'd be surprised if DNSng (or some
LDAP-based oracle) is needed, just to meet the real registry issues already mentioned.

all the best,
  Lawrence

---

From: Alex Bligh <[email-masked]>
Date: Wed, 16 Feb 2011 17:29:46 +0000

> about whatever zone administrators want to be equivalent, I think.

Yes. You are quite correct. What I meant to say was treating this
as equivalencies in "spelling" misses the point; most of the use cases
now are about orthographic representation (I think). However *if*
we solve this, we need, as you say, to solve the general equivalence
problem, as ...

> We are not well enough versed in the

+1

> the real problems.

I'm not sure I follow that. If we don't understand the existing known
potential users (Chinese, Greek etc.), how can we pretend to understand
the requirements of users we don't know? Surely, the /only/ logical
thing to do is to solve "the general case", where an arbitrary number
of sets of labels each are equivalent inside that set.

> This is also why I have been so unhappy that we

+1

-- 
Alex Bligh

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 16 Feb 2011 09:39:33 -0800

> His comment appeared reasonable (to me :), in rebutting allegations of impossibility.

One stupid observation:  Combinatorial explosion, if the protocol is done right, should not be a problem even in the 'solve for near infinity' case:

The effect on resolvers/caches is effectively nonexistent: they only need to store the actual instances queried for.

The effect on authorities is harder, but still not that hard IF the authority can dynamically generate the needed translations on the fly.

Thus the CNAME+DNAME style of aliasing should one finally be settled on (x.y -> r.s AND *.x.y -> *.r.s) is a sufficient mechanism if the authorities who want the combinatorial explosion case can use code to synthesize (x'.y' -> r.s) plus the associated RRSIGs on the fly.

Thus I'll argue that any solution SHOULD support the 'solve for infinity' case.  There is no real reason not to.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Feb 2011 12:40:12 -0500

On Wed, Feb 16, 2011 at 05:23:33PM +0000, Lawrence Conroy wrote:

> Almost all registries will have rules on bundling and mapping.

I just want to be clear what you mean by "registries" there.  Remember
that, formally, every zone cut comes with a registry responsible for
it.

If what you mean is "big TLD registries", then I'll concede the point.
But we're not the DNS Extensions for TLDs WG.  We're responsible for
the protocol all the way down.

I fully agree that we're not required to solve _every_ case: we can't.
But we do have to solve enough of a problem to really make a
difference.

This is why the SMTP and web server issues are such a big deal.  If we
solve the problem that you only have to maintain one tree in the DNS,
and everything else "just works", that is a completely meaningless
victory if you nevertheless have to maintain all your SMTP and web
servers by hand and keep them up to date about the aliases.  The work
to keep the DNS in sync here is trivial compared to everything else.

> different from millions of potential domains.

So how many shadows is the right number?  The final sigma case is
trivial. But the tonos case is not; it requires a large number of
alternatives.  We heard "tens of alternatives".  But of course, that's
tens of alternatives _in every level_.  If you have four levels deep
and 10 each, then that's 40 possible alternatives for one FQDN.

A

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

---

From: "John R. Levine" <[email-masked]>
Date: 16 Feb 2011 09:44:16 -0800

> applications there is /still/ manual configuration (see SSL cert DN

If we're serious about names being equivalent, browsers should be able to 
take the name in an SSL cert, and check in the DNS to see if it's 
equivalent to the name it's using.  If we believe in DNSSEC this shouldn't 
be a security issue.

Yes, this is a lot more work than some DNS tweak that makes everything 
work, but if the DNS tweak existed, we would already have found it.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 16 Feb 2011 09:57:03 -0800

> billions.

Well, yes, but that's in one component.  If someone has a name A.B.C.gr, 
where each of A B C has ten variants, now there's a thousand equivalent 
names.  I would think that a design that handled the variants in C but not 
in A and B is not worth implementing.

If you only care about C, you can do that with bundling, have the registry 
assign all variants of a requested name to the registrant, and let the 
registrant deal with making them the same, by copies of the zone.  It's 
not particularly elegant, but it requires no changes to existing protocol 
and the software is not very complicated.

> We asked for a DNS rr that will allow two, three, four, or tens of 
> chosen domain names to act as if they were interchangeable in all the 
> branches of the domain name tree, starting from the top. They could be 
> perfectly normal Latin domain names that point to the same services and 
> the administrator decides to administer them as one.

Except that, as often noted, if the servers they point to don't have some 
way to discover that the names are intended to be equivalent, the services 
won't work.  The assumptions so far seem to be either that the services 
are something like telnet that doesn't care what its name is, or that 
they'll be manually provisioned, which seems unlikely to work except in 
the tiniest cases.

Regards,

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Feb 2011 06:02:11 +0900

Vaggelis Segredakis wrote:

> We did however ask for the user's choice of registered domain names,

How many names the user can choose? 10? 100? or 1000000?

> The number of these domain names varies from two

See examples of possible meaningful combinations of upper and
lower cases.

	my-domain.com
	my-Domain.com
	My-domain.com
	My-Domain.com
	MY-DOMAIN.com

or, some user may think even more meaningful

	my-DOMAIN.com
	My-DOMAIN.com
	MY-domain.com
	MY-Domain.com

> (or four if a final sigma is present)

How much will it be with the Greek equivalent of above examples?

> to some tens of domains, not millions and certainly not
> billions.

How can you forbid a user who purchased "my-domain.com" want to
have control over:

	mY-DoMaIn.com

?

> They could be
> perfectly normal Latin domain names that point to the same services

	mY-DoMaIn.com

is a perfectly normal Latin domain name.

> and the

Administrator of which? Registry or the user?

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 08:29:30 +1100

In message <[email-masked]>, Tony Fi
> Note that server features like this are nice to have but not absolutely

HTTP abuses CNAME.  If HTTP clients where following the design
principles behind CNAME then the HTTP request would be re-written
when a CNAME was seen.  Instead they ignored the CNAME and as a
result effectively treated it like a single MX record which is wrong
and has caused problems all along.

When we actually want to use CNAMEs for what they are designed to
be used for we find HTTP has hijacked them.

There still isn't a formal RFC for SRV with HTTP.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 13:36:45 +1100

> and 10 each, then that's 40 possible alternatives for one FQDN.

Does one have to support mixed tonos?   With and without rather than
on a per character basis?  I don't know as I don't write Greek.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 13:50:52 +1100

In message <[email-masked]>, "John R. Levine" wr
> they'll be manually provisioned, which seems unlikely to work except in 

This is where if CNAME's were being properly handled you wouldn't have a
issue.  Give the service the indirection support and aliasing support.
HTTP uses the alias record for indirection which is just wrong.

---

From: Doug Barton <[email-masked]>
Date: Wed, 16 Feb 2011 21:04:55 -0800

On 02/15/2011 20:17, Jay Ashworth wrote:
> break*my*  protocol which isn't http".

It would be really great if we could find a pointer to that discussion, 
since some of us are still working on trying to solve the problem and 
would prefer not to make things worse. :)

Meanwhile I'm concerned about what seems to be a thread of "We can't 
work to solve the DNS part of this problem because solving the DNS part 
won't solve the whole problem." *If* we can solve the DNS part of the 
problem now there are solutions available now for all the other problems 
that people have mentioned so far, even if they are potentially onerous 
(such as acquiring SSL certs for all variants, etc.). But without a 
solution for the DNS part of the problem it's going to be awfully hard 
to move forward in the other areas.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: John Levine <[email-masked]>
Date: 17 Feb 2011 06:01:05 -0000

>won't solve the whole problem."

I'm more concerned that whatever approach we adopt makes it possible
for applications to configure themselves automatically using the info
in the DNS.  Most likely people will configure manually until the pain
of doing so gets great enough that it's worth the hassle to implement
autoconfiguration for HTTP, SMTP et al., but we owe it to them to make
the autoconfig possible when they're ready to bite the bullet.

Mark is more or less right that CNAMEs do what you want, although they
don't deal with A.B.C where each of A, B, and C have variant forms.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 17:14:45 +1100

> would prefer not to make things worse. :)

The classic case is the email typo.  It fails immediately with
NXDOMAIN but has to wait for the MTA to timeout the connects with
"helpful" address records.

Mark

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 17 Feb 2011 09:36:13 +0200

Dear John,

>and the software is not very complicated.

I guess you know we are the Registry of [.gr] domain names. If we are asking
for a different solution than simple bundling and letting the registrant
deal with the issue this should mean something about bundling, right? When
an issue is so common that all your IDN registrants have to register bundles
and "deal with making them the same", it appears to be a good thing if the
registry can assist on such an issue.

The registrants have not asked for IDNA2003 or IDNA2008 to be implemented as
they were, protocols with shortcomings. However, since the IDNA protocols
are well in use by now, a BNAME type solution could make life easier for the
average user.

>they'll be manually provisioned, which seems unlikely to work except in 

My guess is that when the solution is available, many services will benefit
from it and use it.

Kind Regards,

Vaggelis Segredakis

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 17 Feb 2011 10:21:58 +0200

Dear Andrew,

>will be for performance reasons.

That is OK, as long as it provides a solution. However, what you say above
does not imply necessarily the use of "wildcards", right? It is a different
thing to use wildcards in the DNS protocol and completely different to ask
for a group of FQDNs to be the "same".

>even if that means you lose.  Sorry.

Andrew, you have been crystal-clear in many occasions that we shouldn't
expect a solution just for .gr domain names and we are not expecting
something like that. However, if we do not bring our experience along with
others in this discussion then we discuss solutions that are not applicable
to the real problem. 

You do not need to be sorry; you are the chair of the group and somedays
somebody loses; the chair will have the task to announce it. However, up to
that specific point of time please be impartial because I have the feeling
you would prefer this discussion to end as soon as possible and that is not
just.

Kind Regards,

Vaggelis Segredakis

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 17 Feb 2011 10:34:10 +0200

Dear Mark,

>on a per character basis?  I don't know as I don't write Greek.

Most users will never ask for all possible positions of a tonos in a word to
be registered as domain names, since there is usually a cost related to the
registration. 

As a registry we provide them with the domain with tonos in their chosen
position and the domain without it without extra cost. So, for every IDN
registration they get two domain names. For every domain containing a final
sigma they might get four domains per registration. Sometimes they decide to
register a few more for the usual mistypings. Nobody to this date has ever
requested all the possible domains of the bundle to be registered, since
although domain names are not words the users usually like them to have a
meaning. If they are meaningless variations of the original domain they are
not too interesting as a product.

If on the other hand you would like to register ancient Greek words then
different accent styles would come into the game. A good xNAME solution
however is not dependant in the PUNYCODE form, this is beyond the scope of
this discussion. The xNAME solution should be one to make Latin domain trees
equal. The xn-- part is no more significant than any other letter.

Kind Regards,

Vaggelis Segredakis

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 17 Feb 2011 10:47:41 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Masataka Ohta
Sent: Wednesday, February 16, 2011 11:02 PM
To: [email-masked]
Subject: Re: [dnsext] we need help to make names the same, was
draft-yao-dnsext-identical-resolution-02 comment

>How many names the user can choose? 10? 100? or 1000000?

Usually they get two to four names. There is no real limit though. Not all
domain names create huge bundles and even if they do, how many would a user
choose to pay for and for what benefit?

	my-domain.com
	my-Domain.com
	My-domain.com
	My-Domain.com
	MY-DOMAIN.com

	my-DOMAIN.com
	My-DOMAIN.com
	MY-domain.com
	MY-Domain.com

Your examples are not valid, they are the same domain name. The upper case
to lower case conversion does not produce different domain names, even in
IDN. However, if you have a letter with tonos there, the user would type
this word in capital letters without tonos and this would be a different
name in PUNYCODE.

>How much will it be with the Greek equivalent of above examples?

Usually there is only one position for the tonos in each word. Different
position is different word or mistyping. So, you get one domain name with
the tonos, one without. If the domain name had a final sigma, one domain
with tonos+normal sigma, one without tonos+normal sigma, one with
tonos+final sigma, one without tonos+final sigma (total four). If you have a
two word domain or more, you have to multiply these combinations.

>	mY-DoMaIn.com

As mentioned before, they are the same.

>is a perfectly normal Latin domain name.

I agree :-)

>Administrator of which? Registry or the user?

The administrator/user of the domain name, not the registry.

Kind Regards,

Vaggelis Segredakis

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 Feb 2011 10:52:18 +0000

> HTTP uses the alias record for indirection which is just wrong.

It's worth noting that email moved away from doing client-side CNAME-based
redirection.

But you are right that it is better to have protocol support.

SMTP has vestigial client redirects (251 and 551 server responses), though
no-one ever implemented them. Many sites like to rewrite message headers
to canonicalize email addresses based on some idea of friendliness e.g.
[email-masked] -> [email-masked]. I generally think this is
pointless since (in the absence of 251 and 551 support) it doesn't have
any useful effect on the address books of people who are using the
non-canonical aliases. However since email is mostly open-loop, the
complexity of a site's aliases don't need to be exposed to their
correspondents.

XMPP presence handling is a more awkward example: last time I looked the
protocol doesn't have a way to redirect a presence subscription request
from one JID to another (e.g. from an alias to the JID where you actually
advertise your presence). The only way to handle aliases is on the client
side as a multiplicity of separate accounts. It matters much more to your
IM buddies that they know the JID(s) you currently use.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Easterly or
southeasterly 5 to 7, decreasing 4 at times in North Utsire and Viking. Rough
or very rough, but moderate in North Utsire. Rain or snow. Moderate or poor.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Feb 2011 21:16:26 +0900

Vaggelis Segredakis wrote:

> As a registry we provide them with the domain with tonos in
> their chosen position and the domain without it without
> extra cost. So, for every IDN registration they get two domain
> names.

Then, from the beginning, there is no problem of you at all,
even though you thought there were.

Let your clients synchronize their domains.

> For every domain containing a final
> sigma they might get four domains per registration.

If your clients will pay for the additional four domains, there
is no problem.

The problem, however, is that its not fair.

> If they are meaningless variations of the original domain they are

Just say "iPod".

						Masataka Ohta

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 17 Feb 2011 12:36:05 +0000

> choose to pay for and for what benefit?

	Is that to say that the typicl registrant gets 2-4 names from
	the .GR registry, and may then add further multiplicity further
	down the hierarchy, depending on requirements and resources?

	Thanks for confirming and/or clarifying.

	VBR
	Niall O'Reilly

---

From: Danny Mayer <[email-masked]>
Date: Thu, 17 Feb 2011 08:38:59 -0500

> There still isn't a formal RFC for SRV with HTTP.

Even if there were I'm not convinced that it would be useful since there
is no way on the RHS to specify the path. It can give you a name, a
port, a weight and a priority but no path. There was a proposal for a
URL RR but I cannot find it right now and I don't think the wg is
considering it, at least it's not on the document list.

Danny

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 17 Feb 2011 15:56:45 +0200

In the present time the registrant gets two IDN domain names, one with tonos
and the same without. The IDNA2008 protocol is not yet implemented in the
registry and the final sigma is not a different character.

It will soon be and we have to discuss with our registrars and registrants
what the fee scheme will be then, since the domains with final sigma will
need four variants to cover the most usual typing types.

To these domain bundles, they can add variants (different tonos positions of
the original name) and homographs (names in Latin that look exactly like or
very similar to the Greek character domain name).

This should be considered the top level of the bundle-tree. Down below, many
similar things can happen but they do not happen in our zone file.

If you provide the registrant the possibility to set up just a "main" zone
and xNAME the rest, the administration will be much easier and cheaper.

Best,

Vaggelis Segredakis

-----Original Message-----
From: Niall O'Reilly [mailto:[email-masked]] 
Sent: Thursday, February 17, 2011 2:36 PM
To: Vaggelis Segredakis
Cc: [email-masked]
Subject: Re: [dnsext] we need help to make names the same, was

	VBR
	Niall O'Reilly

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 17 Feb 2011 16:06:53 +0200

>Let your clients synchronize their domains.

That would be the easiest thing to do. However, we want to support the users
to have a good experience when using their IDN domain names and not condemn
the ones that choose an IDN over a Latin name to setup everything
two-three-four times.

Then there is the extra cost for these setups.

I believe you are familiar with the term Local Internet Community. We
respect our users need to use IDNs for the Greek characters and we want to
support in the best possible way this IDN community to expand in equal terms
to the Latin domain names. For this, we try to remove this handicap that is
present in the IDNA protocol for the non-latin users.

Best,

Vaggelis Segredakis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Masataka Ohta
Sent: Thursday, February 17, 2011 2:16 PM
To: [email-masked]
Subject: Re: [dnsext] we need help to make names the same, was
draft-yao-dnsext-identical-resolution-02 comment

Just say "iPod".

						Masataka Ohta

---

From: Jay Ashworth <[email-masked]>
Date: Thu, 17 Feb 2011 01:17:02 -0500 (EST)

----- Original Message -----
> From: "Doug Barton" <[email-masked]>

> Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment
> > applicable here also, some approachs to certain things *depend on
> > trying a DNS lookup and having it break*. I'm damned if I can remember what
> > "please don't make this change to try to 'help' 'the web', cause
> > you'll break*my* protocol which isn't http".
> 

Well, clearly it was some thread I was involved in, and it was either 
on namedroppers (which this is the child of, right?) or NANOG, and it was
in the context, I think, of Unicode more generally than I18N names (which 
is the present context, right? I wandered in late).

And I'm pretty sure I Told You So.  :-)

I'll see if I can either locate it in someone's archives or remember
what it was; the argument -- that whatever machination someone was trying 
to apply to DNS that would make DNS work better would break lots of 
other protocols -- was not mine; I was merely kibitzing, as I so often do.

Cheers,
-- jra

---

From: Jay Ashworth <[email-masked]>
Date: Thu, 17 Feb 2011 01:43:08 -0500 (EST)

----- Original Message -----
> From: "Mark Andrews" <[email-masked]>

Yeah, but I don't think that was it.

I wanna say I think it might have been 3LD wildcards to the webserver name,
actually, but I'm gonna have to hunt.  I can characterize it pretty cleanly,
though, as "DNS being configured to lie to querents to make one popular 
thing work at the expense of making other less common but important things
*impossible* (not just slow)".

On reflection, it might have been on the Linux Gazette mailing list, too;
another place I can check.

Cheers,
-- jra

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Feb 2011 13:19:03 -0500

No hat.

> for a group of FQDNs to be the "same".

Well, yes, except that we actually already have wildcards.  We don't
have these other mechanisms.

> However, if we do not bring our experience along with

We fully agree here.

> you would prefer this discussion to end as soon as possible and that is not

I do want the discussion to end as soon as possible, but only in the
following sense: I want us to drive towards a conclusion and, if we're
going to do something, to do it.  We have been in the phase of talking
about maybe doing something for a year (or depending on how you count,
more), now, and we need to nail down exactly what the problems are,
figure out whether we have something useful we can do about them, and
then move ahead with doing those things if so.  We are supposed to be
a working group, after all, not a talk shop.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Feb 2011 10:17:20 +1100

> considering it, at least it's not on the document list.

Which can be dealt with entirely at the HTTP/S layer.

People are using CNAME for 

	site -> hosting server

this include "www.example.net CNAME example.net".
 
We need to support 

	site alias -> site { -> hosting server }

		 CNAME    NEW-TYPE

Additionally people are too lazy to add records for each virtual
service in the DNS so they use "* CNAME server" which makes using
SRV hard as it requires prepended labels.

To prevent breaking existing clients that use CNAME like NEW-TYPE
client would look for NEW-TYPE and only re-write the URL there is
a CNAME and a NEW-TYPE returned.

The CNAME would be replace by NEW-TYPE + addresses records to
help with the transition.

This is very much like the introduction of MX records.  At
some point you stop putting in address records.

Mark

---

From: Danny Mayer <[email-masked]>
Date: Thu, 17 Feb 2011 22:19:40 -0500

> Which can be dealt with entirely at the HTTP/S layer.

Not for the purpose I'm looking to use it. For the particular purpose
the SOAP Servlet path needs to be different from the regular login URL
and there is no way to express that. It needs to be like an SRV record
so that the particular SOAP service can be located.

> some point you stop putting in address records.

Maybe you can give an example of how to get to the following URL for a
SOAP Service and a regular login otherwise for the same host and port
number.

http://ws.example.net:5678/Ws/SOAPServlet for SOAP Service and continue
to allow regular http access to the URL http://ws.example.net/Ws/Servlet
for people who need to just login. This is a real example BTW and the
current implementation stores the SOAP service URL locally. If I could
figure out a way of using SRV records I would.

Danny

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Feb 2011 14:47:37 +1100

> figure out a way of using SRV records I would.

It helps to use the right scheme (RFC3288).  It should be
"soap.beep://ws.example.net:5678/Ws/SOAPServlet" not
"http://ws.example.net:5678/Ws/SOAPServlet".

The client can then make appropriate DNS lookups. 

	_soap_beep._tcp.ws.example.net SRV ....

---

From: Danny Mayer <[email-masked]>
Date: Thu, 17 Feb 2011 23:06:24 -0500

> 	_soap_beep._tcp.ws.example.net SRV ....

I don't care about the transport piece since that's on the LHS. It's the
path that cannot be specified here. Where do I go to get the
/Ws/SOAPServlet part? The path is going to be different for each site.
I'd love to use SRV records particularly as Brian W implemented a Java
DNS library (dnsjava from xbill) that supports SRV records.

Danny

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Feb 2011 15:32:00 +1100

> DNS library (dnsjava from xbill) that supports SRV records.

That's the job of NAPTR records.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 17 Feb 2011 21:49:00 -0800

I think there definitely needs to be a new combination of things:
RRTYPE, semantics, and API.

Overloading CNAME, while attractive, is likely to cause problems. It
is also limited by what CNAME permits for RDATA.

Consider a generic example, where there may be multiple equivalences
at multiple locations of a FQDN A.B.C.example.gr (say).

Say we have A1,A2,A3, and A4 that are all meant to be "the same", and
we want the "official" (canonical) name used to be A1.
Similarly, B1 for B2/B3/B4, C1 for C2/C3/C4.

It would be both cumbersome, and bloated, to have to put all
combinations into DNS as CNAMEs.
It would also be limiting to put other requirements onto how the zone
structure was built (such as requiring delegations/zone cuts).

Lets consider two aspects of the naming issue.
First, is the "same resolution" problem - having all combinations
An.Bn.Cn.example.gr resolve identically (such as with A records). (We
can leave that for another day, to discuss how to do that.)
Second, is having all such combinations advise the client what the
"canonical" name should be, i.e. A1.B1.C1.example.gr.

Having these two handled orthogonally, means there are two distinct
problems. It also means that the second problem is effectively
"opt-in"; it doesn't break anything that doesn't explicitly query for
it or understand it. It doesn't change the semantics of existing DNS
stuff.

Adding a new API, call it "dns_canonicalize()", lets things that care,
look up FQDNs, and get back "canonical FQDNs".
Ideally, the results of "gethostbyname(FQDN)" and
"gethostbyname(dns_canonicalize(FQDN))" would return the same values,
but I don't think it should be a strict requirement, rather a
"principal of least surprise" recommendation to zone operators.

The new RRTYPE could be, for example, CLABEL. A CLABEL's RDATA would
be either a "label", i.e. relative domain name, or an FQDN (ending
with a "." to anchor it at the root.)

So, in our example, A3.B2.C3.example.gr could be a CLABEL of "A1",
meaning only the left-most label has a "canonical" preferred label.
And B2.C3.example.gr could have a CLABEL of "B1", and C3.example.gr
could have a CLABEL of "C1".

The resolver implementing "dns_canonicalize" would start with the
FQDN, and work right-to-left (top down), looking for CLABELs at each
node. Any time a CLABEL is found, rewriting is done, either relative
(current label), or absolute (everything to the right).

So, "dns_canonicalize("A3.B2.C3.example.gr")" would proceed as:
A3.B2.C3.example.gr (no CLABEL at gr)
A3.B2.C3.example.gr (no CLABEL at example.gr)
A3.B2.C1.example.gr (CLABEL at C3 -> C1)
A3.B1.C1.example.gr (CLABEL at B2 -> B1)
A1.B1.C1.example.gr (CLABEL at A3 -> A1).

The extra code in a web browser would be taking what the user typed in
the address bar, apply (dns_canonicalize), and use the resulting name
as the correct name to open the http (or whatever) connection to the
server found at the corresponding A (or AAAA) record (or whatever else
gets used in figuring out where to go and what to do).

I think this has good scaling properties, doesn't break anything, and
is likely to be useful to those who need it. It doesn't matter if 97%
of the DNS namespace doesn't have any CLABELs, IMHO, as long as the
mechanism has adequate support at both the DNS protocol and the
application layers.

Brian

P.S. Perhaps CLABELs could be included in the additional section, if
QTYPE != CLABEL, to reduce delays, server load, etc. (?)

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 18 Feb 2011 14:51:32 +0900

> this include "www.example.net CNAME example.net".

That's a problem. But...

> SRV hard as it requires prepended labels.

Doesn't it mean:

	*.example.com    CNAME srv.example.com
	srv.example.com  SRV   Priority Weight Port Target

works as:

	_http._tcp.www.example.com SRV  Priority Weight Port Target

?
						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 18 Feb 2011 07:32:36 +0100

> 	site alias -> site { -> hosting server }

I just saw an acceptance of the by me suggested URI RR-Type, and this is one of the usages I was thinking of, although it was not a "main goal".

For example:

_http._tcp.example.com.  URI 1 1 http://example.hostingcompany.com/
_https._tcp.example.com. URI 1 1 https://example.hostingcompany.com:444/

Etc...

   Patrik

---

From: "John R. Levine" <[email-masked]>
Date: 18 Feb 2011 01:46:46 -0500

> structure was built (such as requiring delegations/zone cuts).

I went back and reviewed the BNAME proposal on the plane this afternoon. 
Somewhat to my surprise, it looks to me like it's a plausible technical 
approach to "the same" if (and this is a big IF) we can get buy-in from 
the relevant application groups that BNAMEs mean variant spellings of the 
same web site/mail domain/whatever, rather than whatever CNAME means in 
practice now.

If you do a BNAME resolution, the result should come back with a 
synthesized CNAME along with all the BNAME records the client can use to 
see that it was BNAMEs that did it.

Regards,

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 18 Feb 2011 15:51:48 +0900

wrote:

> I just saw an acceptance of the by me suggested URI RR-Type, and
> this is one of the usages I was thinking of, although it was
> not a "main goal".
> 
> For example:
> 

Isn't an original request "http://example.com/filename" converted
to "http://example.hostingcompany.com/" by URIs?

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 18 Feb 2011 08:18:54 +0100

> to "http://example.hostingcompany.com/" by URIs?

Or maybe to http://example.hostingcompany.com/filename?

And then the next question is of course what DN to compare with in the SSL cert?

And then the question is whether SRV RR should be used for example.hostingcompany.com?

I.e. what I see this discussion is boiling down to is that what I think we need is a document that clearly describe one as "simple" thing as "how to resolve a HTTP URI".

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 18 Feb 2011 16:55:24 +0900

> Or maybe to http://example.hostingcompany.com/filename?

"Or"??? Which is specified in your draft?

 > example.hostingcompany.com?

The original request "http://example.com/filename" will cause
SRV look up of "_http._tcp.example.com" and port numbers
and targets are obtained.

As RFC2782 says:

    Priority
         The priority of this target host.  A client MUST attempt to
         contact the target host with the lowest-numbered priority
	it can reach;

"target host"s are "contacted", which means no recursive SRV
look up will occur.

SRV is for hostname in URL just as MX is for domain name
in e-mail address.

						Masataka Ohta

---

From: Danny Mayer <[email-masked]>
Date: Thu, 17 Feb 2011 22:29:43 -0500

> so that the particular SOAP service can be located.

Looks like the URI proposal from Patrik Falstrom fits the bill. Of
course it will be years before it is implemented and deployed. I just
saw the review message from Frederico right after yours.

Danny

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 18 Feb 2011 14:36:53 +0000

> to keep the DNS in sync here is trivial compared to everything else.

Re-reading almost all of the history all at once, this strikes me as
the emerging key point: we started with registry issues, where
scalability of provisioning was the driver for opening the discussion.

But it's not clear that we can help registry operators with benefit
also to applciations writers, or to network operators (Alex's comment
about protocol perversions that rely on DNS lookups to fail in order
to frame a query that wlil succeed, which are always with us but which
we should hardly be encouraging).

I'm comfortable with the assertion that making life easier for
registry operators isn't worth doing if it makes life harder for
applications writers, at least for purposes of argument in the draft.

But: might helping registry operators (i.e., people who run
authority-side servers) without helping anyone else be worth the
effort? I haven't reviewed the draft lately but clones, IIRC, are
based on server-side synthesis of "the same RR you would have gotten
if the aliased zones were fully enumerated". Useful enough?

I *think* Andrew's text above says no, we can't reasonably help
registry operators if we leave applications with the same problem they
have now (knowing for themselves that string $x needs to map to string
$y). But rather than argue with something he may not have actually
said, I'm looking for further comments on this point.

thanks,
Suzanne

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Feb 2011 10:12:09 -0500

no hat

> said, I'm looking for further comments on this point.

That wasn't really what I was trying to say, so I guess I better clarify.

I'm trying to keep in mind two things at once.

On the one hand, we have a narrow issue about the DNS and
provisioning.  And the idea is that we need to make it easier to say
"When you encounter alias {A[1], A[2]. . .A[n]} for some value of n,
then that is mostly functionally equivalent to encountering FQDN F."
This isn't really that big a deal, and we have at least two
complimentary proposals on how to do it.  There are some tricks in
stating exactly what "mostly" and "functionally equivalent" mean, but
I think this isn't that hard.

But if we think about this in the larger sense, we have to confront
the reason why people want the above.  It is surely not just that
people want to have more ways to write the same name.  It is rather
that naive users on the Internet will try to use such "alternative
spelling" names, and we want to help the operators of sites that are
the target of such attempted use to make their lives easier.

Therefore, if we deliver an answer that makes it trivial to add all
these additional ways of referring to "the same host" or "the same
resource" or something like that, we cannot simply ignore the
potential issues for how the addressed services are going to manage
this plethora of names.  This is in fact exactly why I am so concerned
that we have not attracted broad-based attention from the applications
community: we need to hear from them, if we mess up, "Hey, DNS
weenies!  You just made my life impossible."  For if we do that, we
will have failed in the real goal of this work.

Consider that the mail admins and the web admins could be completely
different parts of the organization in a large enterprise (they were
in a university where I worked).  BNAME could have an effect on the
mail admin even if it were just added to help the web admin.  These
are practical consequences of a big change in the DNS protocol, and we
have to think about them in the case of adding new aliasing features.
(This is not the same as what happens when you do it with
provisioning: those admins already have to understand their
provisioning and the deployed applications already have rules for
those cases.)

This is why I think just solving the provisioning case, without at
least some way for the applications to know what to do, is not enough.

I have been very intrigued by the idea of having two-way pointers, so
that if you are a mail server and you're coming up, you can look up
your name and learn how else you might be called.  But nobody has
offered a proposal for how to do that nicely, and we haven't heard
from actual application people about whether that's useful or totally
silly.

(Note I'm not bashing "application people" and I appreciate, very
much, the active involvement of those who have relevant experience and
have been expressing opinions.  But those people are here extremely
notable for their rarity.)

A

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Feb 2011 16:27:13 +0000

> Date: Fri, 18 Feb 2011 14:36:53 +0000
> From: Suzanne Woolf <[email-masked]>
> ...

registry operators (and those who govern) asked about name sameness and
it's fair to answer them with a cost-benefit analysis, such as:

"1. dns provides aliases but these are application-visible and many
   protocols forbid their use, for example MX -> alias -> {A|AAAA}
   so these may not be suitable for your proposed use.

"2. services are name-aware, so any dns sameness whether based on
   existing alias technology or on some imaginable new technology
   would still require service config changes, for example to postfix
   and apache configs on all servers which were going to become
   multinamed.  even if we add new dns technology to support some
   kind of automation in that area, it will still require a global
   upgrade of server side technology, and the failure mode for clients
   contacting non-upgraded servers could be unpredictable/unsettling.
   so, adding new sameness will have a high cost and a long tail.

"3. some existing dns data elements are harmonized around the idea of
   a "canonical name" (for example, {A|AAAA} and PTR) and applications
   often enforce this.  the dns and all applications would have to be
   changed to either remove assumptions about canonical names, or to
   change the definition of a canonical name from a scalar to a vector.
   this has the same high costs and long tail as described for #2 above.

"please choose a tradeoff and give us appropriate marching orders.  thanks."

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Feb 2011 14:09:13 -0800

> That wasn't really what I was trying to say, so I guess I better clarify.

I think what you have here is very clear, at least it helped me 
understand your concern quite a bit better.

> will have failed in the real goal of this work.

Agreed up to here.

> provisioning and the deployed applications already have rules for

Two comments ... First, just because we provide one or more solutions 
doesn't mean that the registrants of the preferred names will chose to 
use them. What generally happens with variants now is that either the 
registry assigns them to the registrant by default, or they are given 
the option to register them at an additional cost. At that point (for 
the most part) they also have the option of whether to delegate the 
variants or not. So IDN registrants are already dealing with these 
questions, we're just giving them a different set of tools with which to 
deal with them.

> from actual application people about whether that's useful or totally

Personally I think that's a really interesting idea, and I will try to 
work it into my CLONE draft (which I am aiming to have complete before 
the -00 deadline on March 7). For CLONE the design is that if a 
CLONE-aware resolver sends a query for a name that is actually a CLONE 
it gets the fact that it's a CLONE back in the ADDITIONAL section, so 
it's not impossible to believe that application developers could use 
that information.

What it sounds like may be useful is an additional RR (maybe CLONES) 
that asks the authority the question you posed above, "What other names 
are related to this one?" I can think of a couple of complications with 
that, not the least of which is that if the qname is one of the CLONEs, 
how do you represent the preferred label in the response (always list it 
first maybe)? The other problem that comes immediately to mind is what 
to do when you have multiple labels in a hostname and more than one of 
them has CLONEs. (Return all the possible variants is likely the correct 
answer, but depending on user creativity that could get unwieldy.)

But back to your original concern, I agree that we don't want to solve 
one part of the problem in a way that makes other parts of the problem 
harder (or impossible) to solve. But I think that we have to be careful 
not to throw our hands up too early, particularly before we've even 
tried to engage the people who are already dealing with these same 
issues we're discussing in theory.

The common case (at least as far as the IDN issues go) is likely to be a 
small enough number of variants that the registrants will be perfectly 
capable of manually configuring the relevant software for all of them. 
And for those that don't wish to do that they can simply choose to not 
provision the variants at the registry, just like they do now.

hth,

Doug

--

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Feb 2011 17:29:50 -0500

> questions, we're just giving them a different set of tools with which to  

Well, yes and no.  Consider one of the favoured strategies in this
area: BNAME.

The reason some people are unhappy with DNAME is because a DNAME at
the parent side causes problems for (for instance) using email at the
DNAMEd domain.  The natural use of BNAME, then, would be on the parent
side (never mind whether it will work for email anyway, for now).

Now, today, people tend not to put DNAME on the parent side because it
doesn't redirect the name itself.  But if we create this tool, it
allows the parent side of the delegation effectively to _require_ that
two names both be active; or at least, to force the child side of the
delegation to handle the traffic from both "spellings". 

So if you want to run your mailserver at example.com, and your parent
decides that you ought also to handle otherexample.com, you're going
to get that traffic even if you don't want it.  And this, of course,
carries up the tree.

That's a tool with potentially significant changes to the operational
environment in which we have lived so far, and I don't want us to
forget it.

> issues we're discussing in theory.

Yes.  I would keep at least a studied silence if I were throwing up my
hands.  I'm not trying to be argumentative for its own sake.  I just
want us to expose as many things as early as possible, while we're
still working out what the problems are.  I'd hate to learn all of
this in another year.

A

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

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Feb 2011 14:48:44 -0800

> delegation to handle the traffic from both "spellings".

Sure, that's possible. But I think it's very, very unlikely. As I said 
in my previous post registries today are giving registrants the option 
of whether to delegate the variants, I don't see this changing if we 
give them a new tool to use.

> to get that traffic even if you don't want it.  And this, of course,

Ok, but even if this happens (which I think is unlikely), so what? If 
the mail server is not configured to handle otherexample the person 
sending mail there will get a bounce. That's only slightly more 
aggravating than having it not resolve at all.

Doug

--

---

From: Mark Andrews <[email-masked]>
Date: Sat, 19 Feb 2011 10:04:55 +1100

> to get that traffic even if you don't want it.  And this, of course,

This is where SMTP is now stupid. 822 (821?) required the sender
to rewrite in CNAME.  If you want multiple mail domains use a MX
record.  I suspect that a lot of this was driven because HTTP does
have the equivalent of MX and rather than fix the real problem SMTP
was stuffed up.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Feb 2011 18:09:06 -0500

> give them a new tool to use.

I've asked before, and I'll ask again now: what do you mean by
"registries"?  Remember that we are _not_ talking only about the top
level.

It is certainly true that the commercial environment today
concentrates most of the commercial relationships and delegations at
the top level, and it is also true that most delegations below the top
level are friendly and co-operative.

But I'm simply not willing to say, glibly, "The future will resemble
the past," in this area.  For instance, we are today in a commercial
environment where the scope for expansion of the top level is very
large, and there is little reason to believe that all of those new
operators are going to do exactly the same thing as everyone else
already has been doing.  We need to design this protocol change for
cases we can plausibly imagine, not just what we happen to have seen.

A

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

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Feb 2011 15:46:29 -0800

> "registries"?  Remember that we are _not_ talking only about the top

Define "top." :)  If you're talking about organizations registering new 
Top Level Domains with ICANN then the behavior regarding variants will 
be defined by mutual agreement so we don't have to worry there. If 
you're talking about how the TLD registries handle this issue with their 
registrants this behavior will also be defined in advance so the 
registrant will know what they are getting themselves into.

> cases we can plausibly imagine, not just what we happen to have seen.

The key word there being "plausibly." I don't foresee a scenario where 
TLD registries will "force" activating variants (whether by delegation, 
or some other solution we provide) on their registrants without warning.

Doug

--

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 18 Feb 2011 21:12:31 -0500

> level are friendly and co-operative.

agree. a CNOBI (com/net/org/biz/info) "feature" is fine, if, like GMO 
corn and soy, appropriately labeled. it is not a general (generic is a 
word that leads too often back to CNOBI) property of the hierarchical 
system.

> environment...

i wish the word "commercial" was paired with "and non-commercial" to 
somehow suggest that the mercantilism at ICANN is not universally 
embraced or of infinite duration.

> ... where the scope for expansion of the top level is very
> already has been doing.

+1, though there is a dot-bomb equivalent accumulation of ambition to 
replicate the failed competition policy experiment of 2000 and capture 
more than a cosmetic (and trademark subsidized) fragment of the .com 
market, and an accumulation of ambition to replicate the successful 
communitarian policy experiment of 2004, without trademark subsidy, 
pioneered by Fundacio PuntCat.

what we really don't know (to paraphrase a man who really should be a 
guest of the government) is what will happen outside of the copy-.com 
and copy-.cat trajectories.

> ... We need to design this protocol change for

err, well, yes in principle, and no in practice. that is, a series of 
pick-according-to-taste-or-belief{blunders, errors, accidents, acts of 
genius} has lead to some specific use cases. han sc/tc. greek tonos. 
failing to solve leads to unintended consequences.

-e

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 17:18:17 -0800

It does indeed. And worse, it works for

_null._random.example.com  SRV...

And other non existent protocols.

There is a way to fix the issue. Instead of resolving in a single step, a
two step resolution is performed. The first step being for an unprefixed
name. This will result in either 'not found' or a canonical name being
returned. The prefix is applied to the canonical name in the second phase.

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

---

From: Jay Ashworth <[email-masked]>
Date: Sun, 20 Feb 2011 11:15:24 -0500 (EST)

----- Original Message -----

> harder (or impossible) to solve.

Or, even worse, "which causes new heretofore unexperienced problems for
completely unrelated items and services."

Remember always that important principle:

"The Internet is the only human endeavour in which a single character
typographical error in a file on a server *on the other side of the 
planet* can cause your entire network to come crashing to the ground."

I think I've got that right.  :-)

Can't remember who said it though.  Some BGP-speaker, almost certainly.

Cheers,
-- jra

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 20 Feb 2011 10:05:02 -0800

> That's the job of NAPTR records.

No, the purpose of NAPTR records was to provide a scheme for 'resolving'
URNs.

Using NAPTR for any other purpose is a terrible idea. They have regular
expressions and that is tantamount to being a Turing complete scheme. Why
not put javascript in the DNS while we are at it?

Trying to use NAPTR here results in records whose effects cannot be
predicted by machines and thus prevent automation of administrative
processes.

---

From: Tony Finch <[email-masked]>
Date: Sun, 20 Feb 2011 19:08:51 +0000

On 18 Feb 2011, at 23:04, Mark Andrews <[email-masked]> wrote:
> to rewrite in CNAME.

I think the reason for removing this feature is that it allows third parties to play silly games, inventing new aliases that will deliver mail to people without their consent.

Tony.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Feb 2011 09:51:14 +0900

> And other non existent protocols.

Non existent protocols are not a problem, because they just do
not work, which is fine.

The problem is that protocols used share a port.

However, as the only protocol which may be used by *LAZY* users,
other than http, is https, it may share the same port as http,
if servers are implemented to distinguish them by the first
byte of the request.

Maybe, some of you are thinking that SRV can't differentiate
server names of name based virtual hosting.

But,

       *.example.com  CNAME com.example.net

       *.example.org  CNAME org.example.net

	com.example.net SRV  0 1 P com.server.example.net
	org.example.net SRV  0 1 P org.server.example.net
	com.server.example.net CNAME shared.server.example.net
	org.server.example.net CNAME shared.server.example.net

should work, even though it violates SRV specification requiring
"name MUST NOT be an alias".

> returned. The prefix is applied to the canonical name in the second phase.

Why do we have to fix a non existent issue?

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 12:17:31 +1100

> if servers are implemented to distinguish them by the first

It breaks *all* protocols that use SRV.  Wildcarding a SRV record
is a bad idea.

> "name MUST NOT be an alias".

The you have a client that tries to use the "foo" protocol which is
SRV aware.  The client asks for _foo._tcp.bar.example.com SRV and
sends up being sent to the http server.

Wildcards match multiple labels.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Feb 2011 10:48:14 +0900

Mark Andrews wrote:

> It breaks *all* protocols that use SRV.

When the protocols used at the domain are http and https only,
nothing break.

Otherwise, users can not be very lazy.

> Wildcarding a SRV record is a bad idea.

If you say so, you should also say:

	Wildcarding a CNAME record is a bad idea

to deny *YOUR* example.

> sends up being sent to the http server.

If users are less lazy, they can set up:

	_http._tcp.www.example.com SRV 0 1 P com.server.example.net

	_http._tcp.www.example.org SRV 0 1 P org.server.example.net

and a server operator set up:

for name based virtual hosting, which is not more difficult for
users than users set up:

	www.example.com CNAME shared.server.example.net

	www.example.org CNAME shared.server.example.net

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 13:29:50 +1100

> When the protocols used at the domain are http and https only,

It breaks all protocols and I'm sorry that you can't see how but
it does.  

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Feb 2011 11:44:36 +0900

> It breaks all protocols and I'm sorry that you can't see how but

I'm afraid you are wasting bandwidth of the mailing list.

						Masataka Ohta

---

From: Larry Brower <[email-masked]>
Date: Sun, 20 Feb 2011 20:52:00 -0600

> I'm afraid you are wasting bandwidth of the mailing list.

I disagree, I say you are wasting it. Mark told you why it was a bad
idea and you just want to argue the point. Sending a message saying "I'm
afraid you are wasting bandwidth of the mailing list" is what is wasting
bandwidth.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Feb 2011 12:56:34 +0900

Larry Brower wrote:

> idea and you just want to argue the point.

> When the protocols used at the domain are http and https only,

Protocols not used at a domain can not break at the domain,
because they are not used.

But Mark *REPEATED* his unfounded statement, which is
the waste of bandwidth.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 20 Feb 2011 20:23:26 -0800

> But Mark *REPEATED* his unfounded statement, which is

Mark is quite correct here.

I have been looking at this problem for five years now and I can assure you
that if Mark was wrong, I would know it.

The fundamental limitation here is that prefix records can only be applied
to canonical names. They do not give the desired results if either wildcards
or aliases are used.

Consider the following:

*.example.com   SRV 1 1 80 host1.example.com

Any attempt to resolve any service in example.com  will succeed whether or
not the service is provided. In other words the domain is advertising
services it does not support, this is a failure for a discovery mechanism.

The following attempt to create an alias for example.net to example.com also
fails:

example.net  CNAME example.com
_http._tcp.example.com SRV 1 1 80 host1.example.com

These are problematic because wildcards and aliases are features we want in
the DNS and they should be supported by advanced discovery.

The mechanism that I hope to have ready for an ID next week adopts the
following approach

Phase 1: Domain Resolution

The query is made for an unprefixed record. This query will return one of
the following results:

1) Domain not found - game over
2) CNAME alias - maps to canonical name
3) Record returned saying 'use SRV, use URI, use TBD'

In the case of a wildcard, there is a need to specify the address at which a
prefix record is to be applied.

Phase 2: Service Resolution

If indicated by domain resolution, SRV or URI resolution is employed to
resolve the service to a host.

It is possible to save the principle of prefix resolution and make aliases
and wildcard work. But not by pretending that there is no issue to be
solved.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Feb 2011 15:25:36 +1100

> But Mark *REPEATED* his unfounded statement, which is

When the discovery phase of the protocol returns a answer when it
shouldn't have you have broken the protocol regardless of whether
it would ultimately succeed or not.  Additionally no one has the
ability to foresee future needs.

I re-iterate.  Wildcards SRV records are a bad idea.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Feb 2011 13:46:08 +0900

> Mark is quite correct here.

Neither your example "_null._random.example.com" nor Mark's
example "_foo._tcp.bar.example.com" is applicable to the case
of "protocols used at the domain are http and https only",
because you are assuming protocols "null" or "foo" is used
at the domain.

> In other words the domain is advertising

That's fine.

Lazy users do not mind if they advertise non existent services.

Moreover, your statement has nothing to do with Mark's unfounded
statement:

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Feb 2011 13:51:49 +0900

Mark Andrews wrote:

> it would ultimately succeed or not.

You can't force lazy users strictly follow your idea on how
protocols should not break.

They are fine if their http domains work.

> Additionally no one has the ability to foresee future needs.

Just say, TTL.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Feb 2011 05:32:09 -0800

2011/2/20 Masataka Ohta <[email-masked]>

> Lazy users do not mind if they advertise non existent services.

But competent people mind a very great deal. If the client is attempting to
discover which GPS protocols are supported at a site and choose the best,
the wildcard scheme fails because it will advertise everything as being on
offer.

Now I do have some experience in Web Services that is rather relevant here.

Like many protocol design issues, these are very easy if you only deal with
some of the use cases. They become much harder when you actually take into
account all the constraints.

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Tue, 22 Feb 2011 15:40:33 +0200

Hi Eric,

>failing to solve leads to unintended consequences.

I couldn't agree more with your last sentence above. Before landing in this
WG with this issue I tried to explain the situation back when the first
protocol of IDNs was designed. The belief then that a protocol should not
take into consideration specific issues but rather stick to the "domains are
not words" motto brought us all ten years later to the point of discussing
adding rr types in DNS, rather than designing correctly a translating
application-layer protocol right from the beginning, with formatting data
etc to solve all problems.

Best,

Vaggelis Segredakis

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 09:35:18 -0500

I think the big problem here is the failure to accept the fact that the
problem as stated is ambiguous and interpreted literally is nonsense.

If we have two trees, x.y.z.a, x.y.z.b what does it mean for them both to be
'the same'?

Do we mean the same from an application point of view or from a DNS layer
point of view?

Solving the problem from the application point of view is easy. We just
invent a new pointer that aware applications can interpret. Non-aware
applications will not.

Making the two trees 'the same' at a DNS level appears to me to be nonsense.
It is only possible for the DNSSEC signature to be for one of them. So they
are not going to be exactly the same, one must inevitably be the canonical
form.

This particular issue seems to arise from certain political objectives, the
futility of which has been amply demonstrated in the past few weeks.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 22 Feb 2011 11:55:34 -0500

> etc to solve all problems.

It is peculiar that we have both the uninterpreted 8 bits semantics, 
however unfashionable binary labels are presently, and the xn-- prefix 
to signal an encoding within a larger repertoire of characters, and 
the per-character associated property of directionality, and probably 
some other stuff that escapes me writing this will on a concall, yet 
we have nothing (I can think of) that provides a description of 
(sub)string (sequence of character) semantics (other than the charming 
property of "." as construed by the UTC, of directionality, which it 
happily associates with proximal characters, effecting directional 
leakage across label boundaries in bidi scripts).

A source of requirements has been primarily concerned with the visual 
similarity of some characters in larger repertoire in a single name 
space. While this appears to be a "sub-word" concern, as the problem 
to be solved is significantly less common absent outside of that 
single name space, it is confusing that this is not viewed as an 
instance of the "domain is a word" frame of reference.

I mention this to point out that the sources of requirements have 
addressed issues other than those identified in this thread.

Eric

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Feb 2011 05:33:58 +0900

Vaggelis Segredakis wrote:

> protocol of IDNs was designed.

It was about 14 or 15 years ago, when I, and some others, argued
against localized domain names exactly the same reasons as today:
sameness including case correspondence of accented characters and
improper (prohibitively complex) support for bidirectionality.

So, you have been warned.

> The belief then that a protocol should not take into
> consideration specific issues but rather stick to the "domains
> are not words" motto brought us all ten years later to the point
> of discussing adding rr types in DNS, rather than designing
> correctly a translating application-layer protocol right from
> the beginning, with formatting data etc to solve all problems.

Some of the problems can be solved only by fundamental redesign
of character encoding (effectively abandoning Unicode).

Avoiding to do so, more than 10 years have wasted already.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Feb 2011 15:56:17 -0500

Moderator hat on.

> Avoiding to do so, more than 10 years have wasted already.

Ok, you've made this claim repeatedly.  We've heard it.

Like it or not, the actual computer world we actually have is using
Unicode, and IDNA is using it too.

Repeating over and over again that it won't work isn't helpful.  If
you have specific criticisms of a specific proposal, that is helpful,
and I'll be happy to read it.  Otherwise, I hereby ask you not to post
again the claim that Unicode needs to be abandoned.  There are lots of
things that would be different if we'd made different decisions in the
past, but we didn't and here we are.

A

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

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Feb 2011 08:36:59 +0900

> Moderator hat on.

You shouldn't.

> and I'll be happy to read it.

Specific proposals on the sameness problem I made this time are:

	to give up to have localized domain name

or

	develop extended case insensitivity description language

and

	to give up DNSSEC or run extended case insensitivity
	database on clients

which you failed to read.

> Chinese are equivalent, I don't see how anything simpler could do the

Remember possible case insensitivity issues related to Greek or
Chinese equivalent of

	yyyyyyyyYyyyyyYyyyYyyyyyYyyyyyyyyyyyYyyyy

or

	iPod

That you want to have IDN politically does not mean IDN
exist and even localized domain names are so hard to have,
which is the technical reality.

However, you are saying you can't accept the technical
consequences only to waste yet another 10 years.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Feb 2011 09:01:34 +0900

As Andrew requests a specific proposal, I give it also
for bi-directionality.

Hope Andrew not change his mind to say I shouldn't make
a specific proposal because it was already made 15 years
ago.

Eric Brunner-Williams wrote:

> yet we have 
> nothing (I can think of) that provides a description of (sub)string 
> (sequence of character) semantics (other than the charming property of 
> "." as construed by the UTC, of directionality, which it happily 
> associates with proximal characters, effecting directional leakage 
> across label boundaries in bidi scripts).

The problem is that bi-directionality of Unicode (and ISO 2022
extension) is not finite state but requires PDA (push down
automaton).

While PDA is fine with structured text, having PDA with plain
text is overkill.

For example, search pattern with PDA have time complexity of
O(L^3) where L is the length of text to be searched.

As I wrote recently (2/18) on IETF main ML;

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55532
Subject: Re: MHonArc mail archive line wrapping
> The assumption on line length is necessary to have multilevel
> quotation ("> ", ">> ", etc., see above) with plain text.
> We know that we can use directives of structured text such as:
>.in +3
>...
>.in -3
>when necessary.
>But, when plain text is good enough, we use plain text.

which is seemingly agreed by most, we (and DNS, especially)
shouldn't be bothered by PDA unless it is necessary.

It is not difficult to support bi-directionality with finite
state if line length is known (or known to be infinite,which
should be the case for DNS) in advance. Just spell words
backward if directionality of the words are different from
directionality of lines containing the words.

So, a specific proposal is to stick to finite state, even
though it might mean abandoning Unicode.

					Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 22 Feb 2011 18:02:05 -0800

> 	to give up DNSSEC or run extended case insensitivity

OR use DNSSEC but sign data dynamically.

10 years ago, online signatures may have been questionable computationally.  Today, online signatures are near-trivial computationally.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Feb 2011 11:47:45 +0900

Nicholas Weaver wrote:

> 10 years ago, online signatures may have been questionable
> computationally.  Today, online signatures are near-trivial
> computationally.

Any reference?

Note that "near-trivial computationally" means more lengthy
signatures are required than 10 years ago.

						Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 22 Feb 2011 19:36:20 -0800

>> computationally.  Today, online signatures are near-trivial

Not for DNSSEC, but computationally DNSSEC signature generation is no harder than SSL connection setup.  Google was able to make Gmail SSL only with a trivially small increase in computation.

Random reported SSL setups per second are ~1500/s for a commodity 64B processor with 1024B keys.  (People don't benchmark this kind of thing as much as they used to...)

AND this parallelizes obscenely well: because of the stateless nature of DNS, a simple salted hash function dispatch to compute nodes will easily handle a cluster to however many requests per second you need to case-sensitive-normalize.  

AND such compute nodes could cache the signatures for common conventions, which means you can't computationally DOS the common cases and the COMMON cases no longer require dynamically executed DNSSEC...

> signatures are required than 10 years ago.

2048B signatures are only ~4x harder than 1024B signatures computationally to GENERATE, but vastly harder to crack using brute force.  Thats the wonder of cryptography and the exponentials involved.  Its quadratic increase in complexity to add bits to your RSA keysize, but far far far greater impact on the cost of cryptanalysis.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Feb 2011 22:48:29 -0500

If you are going to do that, you might as well do a key exchange inline as
well as we do in TLS.

One key exchange can then be leveraged across multiple connections using
kerberos style tickets (see DPLS for an example).

DNS does not require non-repudiation so this would be the appropriate
technology.

On Tue, Feb 22, 2011 at 9:02 PM, Nicholas Weaver
<[email-masked]>wrote:

> 10 years ago, online signatures may have been questionable computationally.
>  Today, online signatures are near-trivial computationally.
>

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Feb 2011 14:32:59 +0900

Nicholas Weaver wrote:

> Random reported SSL setups per second are ~1500/s for a commodity
> 64B processor with 1024B keys.

I think you are saying 1024b keys.

That's a lot slower than typical number on TCP connections per
second, which means computation load dominates.

Considering the following statement in RFC5507 (April 2009):

   DNS queries over TCP are not subject
   to this length limitation, but TCP imposes significantly higher per-
   query overhead on name servers than UDP.

dynamic generation is not feasible at all.

> AND such compute nodes could cache the signatures for
> common conventions, which means you can't computationally
> DOS the common cases

DOS will clear the cache. Worse, multiple layers of labels
increase the number of common cases exponentially, unless
you introduce redirection by BNAME.

> 2048B signatures are only ~4x harder than 1024B signatures
> computationally to GENERATE,

As 2048 is not very large that Karatsuba Multiplication is
not very effective.

> but vastly harder to crack using brute force.

If it were vastly harder we should be using 520b key, if 512b
key was good enough 15 years ago.

						Masataka Ohta

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Feb 2011 10:30:43 +0000

On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> If you are going to do [online signing], you might as well do a key
> exchange inline as well as we do in TLS. One key exchange can then be
> leveraged across multiple connections using kerberos style tickets (see
> DPLS for an example).

That gives you channel security whereas DNSSEC gives you data origin
authentication. They are not the same things.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Southeasterly 7 to
severe gale 9, occasionally storm 10 in Viking. Rough or very rough, becoming
high in north Viking. Rain or snow. Moderate or good, occasionally poor, light
icing in north and South Utsire.

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Feb 2011 10:35:06 +0000

> > computationally.  Today, online signatures are near-trivial

PowerDNSSEC is designed for online signing, though its author doesn't
recommend this mode for heavily loaded servers:

http://doc.powerdns.com/powerdnssec.html
http://doc.powerdns.com/dnssec-performance.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes, South-east Iceland: Southeasterly veering southwesterly 6 to gale 8,
occasionally severe gale 9 in east Faeroes. Rough or very rough, becoming
high. Occasional rain. Moderate, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Feb 2011 10:38:09 +0000

> http://doc.powerdns.com/dnssec-performance.html

And Dan Kaminsky's Phreebird DNSSEC reverse proxy does too:
http://dankaminsky.com/phreebird/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: Southeasterly 5 to 7, occasionally gale 8 in Fisher.
Moderate or rough. Rain or snow. Moderate, occasionally poor, light icing.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 23 Feb 2011 06:46:22 -0800

> dynamic generation is not feasible at all.

That is a statement in the RFC I find a bit of a red herring:  I personally find that the DNS community's fear of computation made sense 15 years ago, but we are in the days where 1U servers are massively powerful (8+ core 1U servers are reasonable) and, more importantly, we understand how to make huge cluster servers that can RELIABLY scale to entire data centers.

Remember, a cluster solution is ONLY needed for those heavily loaded authorities (TLDs, cc-TLDs) which require case insensitivity in non ASCII text, which is not all that many anyway.

An authority that has more like a few hundred base names can just run on a single system, cache all the common cases, and call it good.

> you introduce redirection by BNAME.

I disagree:

a)  The cache can be VERY large: a few GB or more of ram per NODE is trivial (after all, its hard to buy nodes with LESS than 8 GB of RAM these days).  That can hold a lot of entries.

b)  You don't evict old but active entries, so the DOS attack can't evict the common cases that you've learned.

As long as the DOS doesn't start up when you start for the first time, you can learn the common cases and make sure they remain cached in the face of a computational DOS.

Yes, DOS is a problem, but you can structure it so a COMPUTE DOS can only affect new queries which is a far smaller problem: The problem space may be near eXpoNenTIAl, but people don't type that way.

> key was good enough 15 years ago.

No, we should have ALWAYS been using 2048B RSA keys and 256B symmetric keys and 512B hashes.  

"If your crypto is in danger of brute forcing by anything short of a cubic earth of sci-fi nanotech, use a longer key."  

We failed that earlier on, but there really IS no excuse for that now.  And 2048B keys should still be on the order of ~300 ops/s/node.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 23 Feb 2011 11:44:09 -0500

>> dynamic generation is not feasible at all.

first, there are zones who's editors generate updates with on the 
order of 1 time/day, and zones who's editors generate updates with an 
order of 100 times/day.

requirements for the CNOBI business model is not a general requirement.

restated, for a large number of zones, including a plurality of zones 
who's editors have a contractual relation with a technical 
coordinating body, dynamic generation is simply not present or in plan.

> Remember, a cluster solution is ONLY needed for those heavily loaded authorities (TLDs, cc-TLDs) which require case insensitivity in non ASCII text, which is not all that many anyway.

second, overlooking the persistent error of using case to reason about 
caseless character repertoires, there is very limited experience with 
this use case at present.

it is possible that one or more arabic script registries, of arbitrary 
contractual or memorandum or other documented policy stripe, will 
elect to map arabic script labels and latin script labels (see "chat 
arabic").

i don't want to itemize the possible pairings (or poly pairings) that 
operators may choose to attempt, whether uniform or conditional in 
their zones, though i'm trying to write a candidate policy document 
for a technical coordinating body.

i simply want to suggest that "heavily loaded" may have a bi-modal 
distribution, and correlate to operators which map labels as a 
default, e.g., the .cn and similar operators for labels containing 
characters from the sc and tc repertories, and operators which do not 
map labels as a default, e.g., operators pursuing the CNOBI business 
model and monitizing each nominally distinct label.

> An authority that has more like a few hundred base names can just run on a single system, cache all the common cases, and call it good.

i hope this is several orders of magnitude lower than obtains for 
authorities offering a zone or zones in or between which label mapping 
for script and identifier support is offered.

hope springes eternal, etc.

-e

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Feb 2011 15:00:27 -0500

> authentication. They are not the same things.

True, but data origin authentication is probably the wrong model for a DNS
security scheme.

If we are going to consider changing the model of DNSSEC, which is what
moving to online signatures would entail, then the whole architecture is
back on the table.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 23 Feb 2011 13:49:02 -0800

On Feb 23, 2011, at 12:00 PM, Phillip Hallam-Baker wrote:

> True, but data origin authentication is probably the wrong model for a DNS security scheme.
> 
> If we are going to consider changing the model of DNSSEC, which is what moving to online signatures would entail, then the whole architecture is back on the table. 

Online signatures work within the existing DNSSEC model, you just need to be willing to pay the computational cost in the cases where it is necessary (eg, mixed-casing non-ascii)

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 23 Feb 2011 14:25:41 -0800

Hi,

> True, but data origin authentication is probably the wrong model for a DNS

Why? Is your goal to make it easy for some entity not the authority
for a zone to forge data in that zone?

> moving to online signatures would entail, then the whole architecture is

Total nonsense. The on or off line signing question is pretty minor
and completely orthogonal to the channel versus origin authentication
question. As soon as you have a zone with dynamic update, your are
shoved in the direction of on-line signing, it doesn't take mixed case
non-ascii.

Donald

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Feb 2011 08:35:59 +0900

> That is a statement in the RFC I find a bit of a red herring:
> I personally find that the DNS community's fear of
> computation made sense 15 years ago,

I gave you a reference.

> but we are in
> the days where 1U servers are massively powerful (8+
> core 1U servers are reasonable) and, more importantly,
> we understand how to make huge cluster servers that can
> RELIABLY scale to entire data centers.

We know how RSA-768 was attacked.

> symmetric keys and 512B hashes.

The reality is that they changed, even though there was no progress
on integer factorization algorithm since 1996.

						Masataka Ohta

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Feb 2011 10:07:08 +0000

> > True, but data origin authentication is probably the wrong model for a

If you want to argue that, please get in your time machine and go back to
1993.

> > If we are going to consider changing the model of DNSSEC, which is
> > what moving to online signatures would entail, then the whole
> > architecture is back on the table.
>
> Online signatures work within the existing DNSSEC model, you just need
> to be willing to pay the computational cost in the cases where it is
> necessary (eg, mixed-casing non-ascii)

You can predict in advance the maximum size of the signature cache you
will need (since it's the same size as a pre-signed zone) and once the
cache is populated the work you need to do is exactly the same as for
re-signing a static zone. There are some cases where the maximum cache is
unfeasibly huge, for example pool.ntp.org, in which case you might be able
to get away with a smaller cache (which implies more computational work)
or a more restricted data model.

See also
http://www.ietf.org/mail-archive/web/dnsext/current/msg08593.html
and Colm's follow-up.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Rockall, Malin, Hebrides: Southwest 6 to gale 8, occasionally severe
gale 9 in Rockall, perhaps severe gale 9 later in Hebrides. Very rough or
high, occasionally very high in northwest Rockall and northwest Hebrides.
Occasional rain. Moderate or poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Feb 2011 07:44:55 -0500

> If you want to argue that, please get in your time machine and go back to

Why would I need a time machine? You still don't have anyone actually using
DNSSEC for production?

That snark might be justified if this was a system that was being deployed
and used, but the original premise of the question was that it was necessary
to revisit the design of DNSSEC in major ways to solve the 'same resolution'
problem.

> or a more restricted data model.

That would be a totally bizarre response to a requirement that is nonsense.

If we had a time machine and could go back to 1983, making the DNS support
this particular requirement might make sense.

But unlike DNSSEC, the DNS is deployed and used.

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Feb 2011 12:52:04 +0000

> Why would I need a time machine? You still don't have anyone actually using

Speak for yourself. We're using it in cam.ac.uk and so are our friends at
ic.ac.uk. Large amounts of cz is signed.

> That would be a totally bizarre response to a requirement that is nonsense.

Why is data origin authentication of dynamic replies nonsense?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Southeasterly 7 to severe gale 9,
occasionally storm 10 in north Viking at first. Rough or very rough,
occasionally high in north Viking. Rain or snow. Moderate or poor. Light icing
except Viking.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Feb 2011 08:08:37 -0500

> for a zone to forge data in that zone?

Data origin authentication is very expensive. If the use cases only require
channel authentication, that is going to be more practical.

> shoved in the direction of on-line signing, it doesn't take mixed case

The original poster was being imprecise. DNSSEC already has an 'online'
signature model in that the only practical way to sign a zone is to have the
signing keys connected to the Internet.

What is being proposed here is really an inline signature scheme in which
the signatures are generated within the DNS request-response loop. It would
require every DNS server to have signature capability, not just the zone
master. It would require the signatures to be generated on demand in
response to attacker generated queries.

It would be a total change of the security model.

I think that it would be unwise to make such a change to the DNS
infrastructure in order to support a requirement that is probably nonsense.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Feb 2011 08:17:49 -0500

> ic.ac.uk. Large amounts of cz is signed.

Generating signatures is one thing.

You don't have a deployment until you have people verifying the signatures
and the results affect their behavior.

> Why is data origin authentication of dynamic replies nonsense?

I was referring to the original requirement driving this proposal, making
'names resolve the same'.

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Feb 2011 13:32:31 +0000

> and the results affect their behavior.

Like our central DNS resolvers and my mail relays' resolvers?

The .gov DNSSEC mandate is broken in the way you describe. I have no idea
if they plan to fix it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Variable 3 or 4. Moderate or rough. Fair. Moderate or good.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 24 Feb 2011 05:37:02 -0800

On Feb 24, 2011, at 5:17 AM, Phillip Hallam-Baker wrote:

> You don't have a deployment until you have people verifying the signatures and the results affect their behavior.

All Comcast customers who've opted out of the NXDOMAIN wildcarding are behind resolvers that validate DNSSEC.

nweaver% dig www.dnssec-failed.org

; <<>> DiG 9.6.0-APPLE-P2 <<>> www.dnssec-failed.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36205
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; Query time: 47 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Feb 24 05:35:42 2011
;; MSG SIZE  rcvd: 39

nweaver% dig +cd www.dnssec-failed.org

; <<>> DiG 9.6.0-APPLE-P2 <<>> +cd www.dnssec-failed.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1844
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; ANSWER SECTION:
www.dnssec-failed.org.  7200    IN      A       68.87.64.48

;; Query time: 15 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Feb 24 05:35:48 2011
;; MSG SIZE  rcvd: 55

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Feb 2011 08:44:54 -0500

So you are saying that it is TOO LATE to make a change that would have major
impact on the practice of domain management?

It really has to be one or the other. Either it is too late to make major
change or its all on the table.

Or alternatively, the proposed use case may not justify a major change.

On Thu, Feb 24, 2011 at 8:37 AM, Nicholas Weaver
<[email-masked]>wrote:

> > You don't have a deployment until you have people verifying the
> signatures and the results affect their behavior.
>

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 24 Feb 2011 05:52:46 -0800

On Feb 24, 2011, at 5:44 AM, Phillip Hallam-Baker wrote:

> So you are saying that it is TOO LATE to make a change that would have major impact on the practice of domain management?

I'm stating that your "nobody validates DNSSEC" claim is demonstrably false.

> It really has to be one or the other. Either it is too late to make major change or its all on the table. 
> 

OR the notion of online signature generation is not a change at all, but is something already supported in the protocol [1] and supported by at least two implementations.

[1] Where does the protocol require that signature generation is off-line?  

The key feature for data integrity is that the validating party is NOT necessarily the party contacting the authority.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 24 Feb 2011 09:34:02 -0500

> I'm stating that your "nobody validates DNSSEC" claim is demonstrably false.

have you both agreed what "nobody" means?

does it mean zero validation, not even by superman in his fortress of 
solitude, somewhere in the antarctic, or does it mean that no 
competition authority is likely to consider a claim based upon current 
market share data?

yogi bera used to say things like "nobody goes there". to interpret 
that as having no human visitiation, like mars, would be ... creative.

-e

---

From: Alex Nicoll <[email-masked]>
Date: Thu, 24 Feb 2011 09:56:12 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Finch
Sent: Thursday, February 24, 2011 8:33 AM
To: Phillip Hallam-Baker
Cc: [email-masked]
Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment

[Alex Nicoll] >The .gov DNSSEC mandate is broken in the way you describe. I have no idea if they plan to fix it.

Completely unofficial answer to Tony's statement:

Yes, several different folks are working on it.  As with all things .gov, there's a political and technical angle, and both are being worked.

-Alex

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Feb 2011 15:06:14 +0000

On Thu, 24 Feb 2011, Alex Nicoll wrote:
>
> Yes, several different folks are working on [.gov DNSSEC validation].

Good news :-)

> As with all things .gov, there's a political and technical angle, and
> both are being worked.

Good luck!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay, Southeast FitzRoy: Variable 4. Moderate or rough. Fair. Moderate
or good, occasionally poor.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 24 Feb 2011 09:00:37 -0800

> I'm stating that your "nobody validates DNSSEC" claim is demonstrably false.

More precisely, there is a large ISP, Comcast, where ALL users who've opted out of NXDOMAIN wildcarding are behind DNSSEC validating resolvers.  I would call this a significant operational deployment of DNSSEC validation.

However, back to the original topic: why does case insensitivity for non-ASCII NEED protocol changes?  Can't it be done with just authority changes for only those authorities needing case insensitive non-ASCII names (rather than a protocol change which needs universal changes to the resolvers)

The authority has a standard mapping for case insensitivity in the language in question.  

a: If its the terminal authority for a name, it just runs the mapping and returns the value (if necessary, generating a DNSSEC signature on the fly if its an uncached mapping).

b:  If the authority is not a terminal, and it knows that the authority directly beneath it for a name support case insensitivity, it just runs the mapping and returns the appropriate value (if necessary, generating a DNSSEC signature on the fly if its an uncached mapping).

c:  If the authority is not a terminal, and it does NOT know that the authority directly beneath it supports case insensitivity, it runs the mapping to generate a canonicalized DNAME or CNAME (as appropriate) with TTL=0 and, if necessary, generates the appropriate signature.

Cases A and B Just Work (tm).  

Case C will work as well because you don't have the CNAME + DNAME problem because the TTL is 0.  Case C may reduce caching and also increase latency, but that is ONLY network load on the authority not computation load (because the DNSSEC signature is cached), and creates an incentive for the authority directly beneath to support case-insensitive names.

NO DNS protocol changes are required, everything is provisioning and authority side changes.

By maintaining a cache of signed data, the reality is although it supports effectively exponential case-recasing, the ones which are actually used get in the cache.  If the cache is well structured and sticky, a computational DOS won't be able to evict valid entries (limiting its effect to only new BizArrE caSeS of TyPogRaphy)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Feb 2011 12:17:10 -0500

The problem here comes in that the downstream server needs to be prepared to
support the scheme. And there can be multiple levels of ambiguity so the
cache requirement grows exponentially with each level.

I am starting to get a really bad feeling about the resolve the same
requirement. Is the objective here really to make things work better or did
the authorities that raised this in ICANN have a rather different agenda?

On Thu, Feb 24, 2011 at 12:00 PM, Nicholas Weaver <[email-masked]

> >> So you are saying that it is TOO LATE to make a change that would have
> major impact on the practice of domain management?
> >
> More precisely, there is a large ISP, Comcast, where ALL users who've opted
> out of NXDOMAIN wildcarding are behind DNSSEC validating resolvers.  I would
> call this a significant operational deployment of DNSSEC validation.
>
>
>
> However, back to the original topic: why does case insensitivity for
> non-ASCII NEED protocol changes?  Can't it be done with just authority
> changes for only those authorities needing case insensitive non-ASCII names
> (rather than a protocol change which needs universal changes to the
> resolvers)
>
>
> a: If its the terminal authority for a name, it just runs the mapping and
> returns the value (if necessary, generating a DNSSEC signature on the fly if
> its an uncached mapping).
>
> b:  If the authority is not a terminal, and it knows that the authority
> directly beneath it for a name support case insensitivity, it just runs the
> mapping and returns the appropriate value (if necessary, generating a DNSSEC
> signature on the fly if its an uncached mapping).
>
> c:  If the authority is not a terminal, and it does NOT know that the
> authority directly beneath it supports case insensitivity, it runs the
> mapping to generate a canonicalized DNAME or CNAME (as appropriate) with
> TTL=0 and, if necessary, generates the appropriate signature.
>
>
> Case C will work as well because you don't have the CNAME + DNAME problem
> because the TTL is 0.  Case C may reduce caching and also increase latency,
> but that is ONLY network load on the authority not computation load (because
> the DNSSEC signature is cached), and creates an incentive for the authority
> directly beneath to support case-insensitive names.
>
>
> By maintaining a cache of signed data, the reality is although it supports
> effectively exponential case-recasing, the ones which are actually used get
> in the cache.  If the cache is well structured and sticky, a computational
> DOS won't be able to evict valid entries (limiting its effect to only new
> BizArrE caSeS of TyPogRaphy)
>
>

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 24 Feb 2011 12:32:33 -0800

On Feb 24, 2011, at 9:17 AM, Phillip Hallam-Baker wrote:

> The problem here comes in that the downstream server needs to be prepared to support the scheme. And there can be multiple levels of ambiguity so the cache requirement grows exponentially with each level.

Why?  That would be case C:  A 0 TTL CNAME or DNAME is synthesized, so there is no support needed down the chain.

And again, caching and similar requirements do not grow exponentially IN PRACTICE:

How much bigger would your ASCII DNS cache be if you included every capitalization variant as a separate cache entry?  People don't TyPE liKE THis, but DNS supports people TyPEiNG lIKe thIS for ASCII.  

You'd end up with WWW.google.com, www.Google.COM, and the like, but you won't end up with wWw.goOgLe.cOM in the cache.

The problem only occurs if the downstream resolver has a different set of normalization rules, but developing and specifying such a standard is outside the purvue of DNS: we aren't the language experts.  But given a standard normalization, no resolver or protocol changes are needed, and only authorities which support such normalizations need to change.  Additionally, since the upsteam authorities do need to know the state of the downstream authorities, they can ensure that the normalization is agreed to.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 25 Feb 2011 12:48:15 +0000

--On 24 February 2011 12:17:10 -0500 Phillip Hallam-Baker 
<[email-masked]> wrote:

> requirement. Is the objective here really to make things work better or
> did the authorities that raised this in ICANN have a rather different
> agenda?

We asked (effectively) that, and reply there came none.

I think there may have been a little naivety involved, and someone rather
hopefully thought a simple "fix in DNS" could make domain names in n
different TLDs (which they thought of as 1 TLD with n different
representations) "work the same". Several hundred messages here plus a
non-trivial I-D just to set out the requirements, suggests that at the very
least, the problem is not as simple as first thought.

I understand what ICANN is wanting to do (particularly since the "one ccTLD
per nation" requirement is long standing), and suggest the answer is "give
up the aliasing requirement or enforce it by contract with your TLDs".

I also think I understand what the registries are trying to do, and suggest
the answer is "enforce this within your business processes" (i.e. make
registration of any of a bundle of identical names block out all further
registrations other than by the same registrant, and let the same
registrant insert NS records etc. for any other domain in the same bundle,
perhaps up to some local policy limit). I can understand why synthesis
might be useful here, but I can also understand why registries don't like
it.

I also think I understand what the rest of the world might want to do, and
my answer is "use CNAME/DNAME", plus possibly synthesis.

However, what we don't yet have is a coherent statement of the problem
(save for the I-D just out which I have yet to read), which means we don't
have coherent explanation of why it is so difficult to solve (and, IMHO, a
bad idea if it requires protocol changes). This is why I should go and read
the I-D.

-- 
Alex Bligh

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 25 Feb 2011 13:33:03 +0000

> We asked (effectively) that, and reply there came none.

ICANN has announced a proposed study project that stands some chance
of allowing it to arrive at its own position on what's entailed around
"variants" or "sameness". It appears that they are admitting they
don't know what they want, or whether it's got anything to do with the
DNS, so they're starting from the policy perspective and working
(perhaps) towards the technical.

See:
http://www.icann.org/en/public-comment/public-comment-201104-en.htm#idn-varianttld

(NB: I serve as a non-voting liaison to the ICANN Board of Directors
from one of its technical Advisory Committees, the Root Server System
Advisory Committee. However, I don't speak for ICANN, particularly not
on this issue; took on the aliases draft with no support or prompting
from ICANN and with the support of my employer, ISC; and have been
trying for quite some time now to get ICANN to speak for itself.)

> least, the problem is not as simple as first thought.

Can't comment on what ICANN thought (see above). But I'll note that
part of how we got where we are was that the WG found itself with
several proposals for technology to solve a simple, obvious problem
that no one could state here, either.

In other words, there may have been plenty of naivety to go around :-)
(including my own, I claim no special wisdom)

> I also think I understand what the rest of the world might want to
> do, and my answer is "use CNAME/DNAME", plus possibly synthesis.

This is a very fair and important point-- that we're actually talking
about two different perspectives here, what registries want and what
application writers want. One of the things we have to settle is how
much they're talking about "the same thing"(!) -- i.e. how much their
concepts of what needs to be done overlap.

If all we're looking at is what registries need, we have to separate
the policy requirement to have a way to determine that a set of
objects should be treated as "the same" (not our business) from the
operational or technical requirements for a mechanism by which to
instantiate what that means (maybe our business).

To the first (registry) question, I'm hoping for more text on
variant-related use cases, which is why I'm hopeful about ICANN's new
project. But when you read the draft, you'll see a proposed
requirement that for any action the WG takes, it's necessary but not
sufficient to address the registry consideration, per some comments on
the list about a week ago. It's extremely important to get reactions
to that requirement from the full range of WG participants.

I've talked to some people (some of whom have posted here) who seem to
be saying that parallel provisioning by the domain registry is not
enough for their purposes, because the fact that the objects so
created are only related inside the registry and to some assumed set
of users is not enough-- that it would be useful to them to have a
service-independent, application-accessible way to create a property
or attribute of a set of names that we could call "sameness" or
"aliases-of".

If true, it provides a motivation for looking hard at a requirement
that parallel provisioning doesn't meet (your second prong). However,
it's been extremely difficult to get clarity on this, and it's one of
the things most important to get right for the draft.

Either way, we also need to settle exactly how CNAME/DNAME fall short,
if they do. The current draft takes a stab at that but it may need
more development.

> bad idea if it requires protocol changes). This is why I should go and read

Please do, looking forward to your comments.

best,
Suzanne

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Feb 2011 09:30:43 -0500

No hat, I think.

> up the aliasing requirement or enforce it by contract with your TLDs".

Two things:

1.  The issue before us is not merely a TLD or near-TLD one.  If we
work as though it is, then we're not doing our jobs.

2.  Notwithstanding the above, there are some delegation relationships
that are less fraught than others.  There are all sorts of prickly
layer-9+ issues implicit in talking about a contract between a private
US corporation and the sovereign power of foreign nations, and I think
we maybe want to avoid exploring that warren.

A

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Feb 2011 11:49:35 -0500

I suspect that the point of these requirements is precisely the fact that
they cannot be met within the current architecture.

I am seeing people rushing to change the security model of DNSSEC to support
this requirement, but I doubt that is going to be sufficient.

Let me be clear here, I do not believe that any contributor to this
discussion is acting improperly or following a hidden agenda. But I do
strongly suspect that the problem is intentionally put in such a manner as
to collectively yank our chain.

This is the bring me a rock school (no wrong one) school of management. And
the rock will continue to be the wrong one until such time as we propose
creating a hole in the infrastructure that serves the underlying agenda.

It seems rather surreal to be having a dialogue about how to make locating
Web sites easier when the parties behind the proposal are devoting vast
resources to make access to the 'wrong' sites as hard as possible.

The anual market for censorship equipment and technology is in the billions
of dollars and most of that technology is being made by companies whose
names are really well known in IETF.

Oddly enough, the companies that are involved in that particular market do
not attract a tenth of the scrutiny that CAs attract. I am not aware of any
CA having mis-issued except unintentionally or as a result of coercion. Yet
the sales of equipment designed for the purpose of enabling censorship are
made with full knowledge of their purpose.

Here is an idea, let us table this whole discussion until after we solve the
problem of how to make the Internet accessible without let or hindrance from
any point on the planet with minimal communications connectivity.

The proposal that I made at the start of this discussion for a 'Did you
Mean' record is easily sufficient to address legitimate usability concerns
in this respect. If we wanted to go further we could define a record that
specifies transliteration mappings within a domain.

But at the moment I am rather more interested in the prospects for running
NNTP over USB key and wifi enabled mobile devices as transport.

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 Feb 2011 17:09:49 +0000

> they cannot be met within the current architecture.

A lot of the argument is because we aren't sure that that is true. Can the
requirements be met with improved provisioning technology and no protocol
changes?

> this requirement, but I doubt that is going to be sufficient.

Online signing is not a change to the DNSSEC security model.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth: Southwest 5 to 7 veering northwest 4 or 5. Moderate
or rough. Occasional rain. Moderate or good, occasionally poor.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 25 Feb 2011 17:10:33 +0000

--On 25 February 2011 11:49:35 -0500 Phillip Hallam-Baker 
<[email-masked]> wrote:

> Here is an idea, let us table this whole discussion until after we solve
> the problem of how to make the Internet accessible without let or
> hindrance from any point on the planet with minimal communications
> connectivity.

Perhaps I am being thick here, but I don't see anything but the most
tenuous connection between internet censorship and IDN variant support
in DNS.

I'm in general in favour the solution to this problem being "not to fix
it", but I think we owe people a better rationale for this than "some IDN
users censor internet traffic" which I suspect might be the link you
are making.

-- 
Alex Bligh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Feb 2011 12:43:29 -0500

Requiring slaves to be signers is a major change to the security model.

In the current architecture it is sufficient to have online keys at a hidden
master. The hidden master can be placed behind a firewall that rejects
inbound requests.

In the proposed architecture every DNS server has to have signing
capability. It is not possible to prep the zone at the hidden master and
then push the data out. The keys are not only online, they are reacting to
queries prepared by potential attackers.

>From a risk analysis point of view these changes are very significant
indeed.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Feb 2011 12:46:23 -0500

> Requiring slaves to be signers is a major change to the security model.

Depending on how you implement this, it might be.  But anyway, this is
why we are doing a requirements analysis _before_ we start planning
how to solve these problems, since it isn't obvious at least to me
that what you describe above is a requirement in any case.

A

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Feb 2011 12:58:04 -0500

> that what you describe above is a requirement in any case.

True, but what I was originally complaining about was the rush to put this
on the table in the first place and then I was reacting to the statements to
the effect that this is no big deal.

As a provider of DNS services I think that we have to have a very clear
requirement that any proposed solution not impact the deployments of DNSSEC
currently taking place. Requiring servers be capable of signing inline would
represent a major architectural change. It would have a major impact on the
cost of deployment.

At the moment I can put a DNS slave pretty much anywhere. If I need more
capacity I can simply rent it as required at commodity rates.

If every slave has to be a signer then I either have to engage in some very
expensive engineering effort or I have to locate every slave in a Tier 6
secure facility.

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 Feb 2011 18:06:29 +0000

On Fri, 25 Feb 2011, Andrew Sullivan wrote:
> Depending on how you implement this, it might be.

I don't think any of the proposals actually require online signing, so
Phill is arguing against a straw man.

So far as I can tell the main question is, what is the question and is
BNAME the answer?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover, Wight, Portland, Plymouth, North Biscay: Southwesterly veering
westerly, 4 or 5 increasing 5 to 7, perhaps gale 8 later. Moderate or rough,
occasionally very rough in Plymouth and Biscay. Occasional rain, fog patches.
Moderate, occasionally very poor.

---

From: Michael Graff <[email-masked]>
Date: Fri, 25 Feb 2011 12:12:52 -0600

> So far as I can tell the main question is, what is the question and is

I'd ask this differently.  "Is BNAME the only answer?" or perhaps "the
BEST answer?"

No matter how I travel down the path, from reading all the email to
date, I still maintain in my own thoughts that BNAME is one possible
solution, but that the cost of pushing a protocol change down to the
clients is painful in light of DNSSEC deployment and the breakage that
BNAME will create there.

The solution I've heard is that we roll the DNSSEC algorithm numbers.
This is a non-scalable solution and means we have other, bigger issues
to contend with.  We can't continue to use DNSSEC algorithm numbers as a
DNS version number like we did to some extent for NSEC3.

No matter how I approach this problem, I see the solution in my mind.
This solution is that no protocol changes are needed for this, and that
it all comes down to an improvement in the configuration and publication
of delegation points, and zone file contents.

- --Michael

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 25 Feb 2011 10:34:22 -0800

> Requiring slaves to be signers is a major change to the security model.

There is NOTHING which prevents such slaves from forwarding the dynamically signed requests to the master and caching the results and forwarding it on.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Feb 2011 13:48:39 -0500

No hat

> There is NOTHING which prevents such slaves from forwarding the dynamically signed requests to the master and caching the results and forwarding it on.

Except, of course, that it would be insane, since that would turn the
master into a potential single point of failure for any lookup in the
zone.  A significant reason for the success of the DNS is its loose
consistency and resulting resilience to failure.  Any scheme which
replaces that with a single server is doomed to failure.

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 25 Feb 2011 10:51:48 -0800

> replaces that with a single server is doomed to failure.

It is ONLY a point of failure for NeW MiXED CasINGs which appear.  Old ones remain cached.

And unlike other schemes, does NOT require any changes to resolvers.  Any proposal which requires changes to resolvers rather than just authorities which want to support non-ascii mixed case is IMO, a non-starter.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 25 Feb 2011 15:02:14 -0400

> And unlike other schemes, does NOT require any changes to resolvers.  Any proposal which requires changes to resolvers rather than just authorities which want to support non-ascii mixed case is IMO…

I think it is useful to be precise in scoping exactly what changes
we're talking about.

Specifically, when it comes to DNSSEC and signatures, there are
several individual cases, whose deployed implementation may or may not
require changes, depending on the specific proposal(s):
- validating iterative resolvers
- non-validating, DNSSEC-aware iterative resolvers (is there such a thing?)
- DNSSEC-unaware iterative resolvers
- validating stub resolvers
- non-validating, DNSSEC-aware stub resolvers (CD=1) (who talk to
validating iterative resolvers)
- DNSSEC-unaware resolvers (who may be talking to any of the above
sorts of iterative resolvers)

The tails on each of these is of (drastically, IMHO) different lengths.

And, the behavior in the cases of unmodified instances of the above,
in the face of modified authority server answers (new RRtypes, new
DNSSEC RRTYPEs, new DNSSEC validation logic), may differ too.
(Bogus vs Insecure is a huge difference.)

Let's hold off on passing judgement until:
- the requirements doc is cleaned up and accepted (or not)
- proposals are available for evaluation, and/or have been read and
commented on.

(ObContent - my somewhat stale DS2 draft is on-topic, I hope, and
could use some reviewers and feedback, even if it is not yet time to
propose adopting it for WG consideration. Applies only to validating
resolvers (of both kinds) and authority servers who want to use it,
and is benign/fail-safe-ish, with "insecure" rather than "bogus" when
the validator does not understand it.)

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Feb 2011 14:20:59 -0500

No hat.

> It is ONLY a point of failure for NeW MiXED CasINGs which appear.  Old ones remain cached.

I'm not exactly sure how you decided that mixed case was a problem we
were going to solve anyway, but let me disabuse you of this.  In the
interests of allowing people to think about the issues, I haven't shut
down the case discussion, but maybe I should have.  It's not something
we actually need to solve.

First, remember that we're actually trying to solve problems in the
DNS generally, and not to solve particular linguistic issues, since we
don't have the expertise for that.  (Indeed, that we're wasting time
exploring this rathole is evidence of it, since a large number of the
"variant" cases for which we might need a solution don't have anything
to do with case.  Chinese, to pick the obvious example, isn't even
alphabetic.)

Now, there simply is no problem in English: mixed case already
matches.

The rest of the possible target cases occur under IDNA.  And in IDNA,
there is no problem of case.  IDNA2003 maps all upper case to lower
case, and does the lookup.  Under IDNA2008, upper case is simply
DISALLOWED, so it never gets looked up.  It is presumed (but not
actually part of the protocol) that applications will do
locale-appropriate case conversion prior to lookup.  (Note that there
are important subtleties involved here that I am quickly waving away
as detail, but which matter up in the application layer.  For
instance, downcasing, upcasing, and normalization for comparison might
yield different and, to anglophones, surprising results.)

There are problems which happen to have their expression in the
results of case conversion.  

In Greek, there is one GREEK CAPITAL LETTER SIGMA, but GREEK SMALL
LETTER FINAL SIGMA and GREEK SMALL LETTER SIGMA.  In upper case a
sigma in the final position will be the identical Unicode code point
to an upper case medial form sigma; but when they are downcased, one
of those should become one code point and the other should become
another code point.  This _is_ a problem.  People might try to look up
a label, [GREEKLETTERS][GREEK CAPITAL LETTER SIGMA].  Now you need to
have [greekletters][GREEK SMALL LETTER FINAL SIGMA] and
[greekletters][GREEK SMALL LETTER SIGMA] mapped to one another
transparently, because it is unpredictable what will actually be the
U-label that gets converted to the A-label before it gets looked up
when the application maps [GREEKLETTERS][GREEK CAPITAL LETTER SIGMA].
(Or rather, it might be.  The applications might actually all do this
correctly, for all anyone knows.)

But as you can see, we can discuss all of that without recourse to the
specifics of the language, since the actual issue is that a zone
administrator knows a label to label mapping of the items.

Clearer now?

A

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Feb 2011 13:07:51 -0800

> administrator knows a label to label mapping of the items.

Dearly as I would love to agree with you, I fear I cannot.  The actual
issue is that humans interpolate well and canonicalize badly. We're
exploring how to mesh the untidy reality that colour/color, 中國／中国， and
a host of other examples are "the same" to those humans but not to an
exact much look-up protocol.

There are several classes of solutions we can envision.  On is a
referral from variants to canonical forms (like DNAME/CNAME and its
synthetic friends).  That works fine from a protocol perspective, but
it requires there to be a single "real" label and variants which only
point to it.  Some zones don't want that result, for both political
and practical reasons.

Another is one in which there is no DNS change at all, but zone
synchronization methods that ensure that the records at one label and
those at another are in sync.  This avoids declaring one to be "real",
but has a very large potential cost in terms of applications which
will not match them as the DNS is, in essence, declaring them to be
distinct.

Another is to create a "canonical + supported variants" approach.
That would involve both mapping variants to a single label and storing
at that label some information about what the zone maintainer
considered variants, so that applications and local caches could treat
them the same.  The security properties of this approach are, to put
it mildly, interesting, but for variants all within a single
administrative domain, it is possibly workable.  The operational
consequences are also pretty daunting unless the record stores a
pointer to some well-known representation of the normalization rules
rather the variants themselves.

This is a case where people want to treat DNS labels as human-friendly
strings.  They are asking us how far down that road we can go without
breaking fundamental bits of the DNS's design and deployment.  So far,
I hear "we can give you referrals to canonical forms, you can give
yourself synchronized zones, and we may be able to achieve a method
that stores variant information with a canonical form".  The label to
label mapping problem is pretty clearly solved somewhere in that set,
but it is not at all sure that the "humans interpolate well, but
canonicalize badly" problem is or can be.

Just my two cents,

Ted Hardie

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 05:05:00 -0000

>Requiring slaves to be signers is a major change to the security model.

Maybe, but this isn't the only place it's an issue.

IPv6 rDNS is a can of worms that I'd prefer not to open here, but
making forward and reverse DNS match on consumer IPv6 is another
problem that has no straightforward solution.  One of the possiblities
that keeps coming up is stunt servers that synthesize the records as
needed, which obviously means that if they do DNSSEC they need to have
the signing keys.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 27 Feb 2011 07:46:46 -0500

Two questions come to mind

1) How is key publication going to be effected for rDNS-SEC?

Have we actually got a plan for deployment?

2) If we have a viable plan for deployment of rDNS-SEC, why would we not
plan to use that as the PKI for BGPSEC?

It may make sense to employ a hybrid PKI since DNSSEC responses are
transitory and there is a bootstrap issue. But this makes more sense to me
than experimenting with novel X.509 features.

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 15:18:56 -0000

>Have we actually got a plan for deployment?

As far as I can tell, we don't have a plan for deployment of rDNS on
IPv6, with or without DNSSEC.  But like I said, I'd rather leave those
worms in the can other than to note that dynamic generation and
presumably signing of AAAA and PTR records may turn out to be one of
the least bad options.

We don't have a plan for IPv6 DNSBLs and DNSWLs either, but if it
ends up being anything like what people do for IPv4 (an open question,
due to DNS cache explosion problems) rbldnsd is going to have to sign
on the fly, too.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 27 Feb 2011 12:07:31 -0500

> presumably signing of AAAA and PTR records may turn out to be one of

That is my suspicion.

The technology is the easy part. Its the administrative model that
concerns me. Or rather it is technology proposals that seem to assume
that the administrative details are unimportant and can be filled in
later.

> due to DNS cache explosion problems) rbldnsd is going to have to sign

This is the sort of issue that I would hope that the IAB spent time
thinking about.

One answer to this question could well be that the people who use
blacklists have to develop their own technology designed for the
purpose.

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 18:27:20 -0000

>So far as I can tell the main question is, what is the question and is

Looking back into the mists of history (that would be the 1980s for
you old timers), for about the first decade of the DNS, servers didn't
care what their names were.  If you want to add a new name to a TELNET
or FTP or SMTP or POP or IMAP server, just add an A or CNAME record
and you're done.  Even web servers didn't care about their names until
HTTP 1.1 and HTTPS in the mid 1990s.  Mail servers always knew what
domains they could handle mail for, but the CNAME rule pushed alias
resolution into mail clients.  For most purposes, the client handed
the name to the DNS, the DNS gave back an answer that let the client
connect to the server, and that was it.

But life now is not so simple.  We have several major protocols, mail,
http, and https, that pass domain names as part of the data stream
that are not (currently at least) resolved by DNS queries.

When I read a lot of the arguments here, particularly the ones about
what TLD operators want, it's like being in a time warp.  If it were
still 1987, and the only problem were locating the server, then
something like BNAME would probably do it.  But it's not, if we don't
also have a plan for the protocols with domain names in the data
stream, it's a cruel joke on the users.

If the question is how can we make one subtree an alias that resolves
to the same DNS results as a canonical subtree AND allows the
application servers to tell what names are aliases to a canonical
name, BTREE is pretty close.  The primary shortcoming I see is a
security issue: anyone can set a BNAME to make a random name
equivalent to one of mine.  It's possible to handle this outside the
DNS, by manually configuring the server to know what names it can
handle, or hackery, e.g., only accept BNAMEs served from specific name
servers that we trust.  But that's not great for users, since they
will see baffling error messages like "mail relay refused".

So I'd also want some way for the canonical domain to state in the DNS
what aliases it accepts.

Regards,

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 18:32:49 -0000

>blacklists have to develop their own technology designed for the

Over in the ASRG we're working on it.  I have an alternate version of
DNSBL/WLs organized like a b-tree that seems to have pretty good cache
behavior, but it's surprisingly hard to get people to wrap their heads
around the fact that there is a problem.

R's,
John

---

From: Alex Bligh <[email-masked]>
Date: Sun, 27 Feb 2011 18:33:02 +0000

--On 27 February 2011 18:27:20 +0000 John Levine <[email-masked]> wrote:

> The primary shortcoming I see is a
> equivalent to one of mine.

How does this differ from DNAME?

-- 
Alex Bligh

---

From: "John R. Levine" <[email-masked]>
Date: 27 Feb 2011 13:37:17 -0500

>> The primary shortcoming I see is a security issue: anyone can set a 
>> BNAME to make a random name equivalent to one of mine.

> How does this differ from DNAME?

Not in any important way I can see.  But I'm not aware of any application 
servers that autoconfigure based on DNAME, either.

Regards,

---

From: Alex Bligh <[email-masked]>
Date: Sun, 27 Feb 2011 19:56:09 +0000

> servers that autoconfigure based on DNAME, either.

I think I'm being thick here. Doesn't the BNAME reference go the
wrong way to autoconfigure a server based on it in a manner where
there can be a security problem as a result? IE Mallory's BNAME
record tells you which zone Mallory's zone is equivalent to.
Mallory's BNAME record does not tell you which other zones
(incl. Mallory's) are equivalent to yours. What would make
your server query Mallory's BNAME record at config time anyway?

-- 
Alex Bligh

---

From: "John R. Levine" <[email-masked]>
Date: 27 Feb 2011 15:00:10 -0500

> there can be a security problem as a result?

You're quite right.  SHADOW goes the right way, but requires a zone cut 
everywhere that there's aliases.

I'm not seeing any particularly pretty ways to fix BNAME to tell which 
ones are approved.  It's not unlike the rDNS problem.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 28 Feb 2011 10:07:26 -0500

John is completely right here and it really demonstrates the need to
have application level input into this discussion.

Modern application protocols bind to DNS names and NOT to IP
addresses. As far as we are concerned a DNS name is the only essential
part of the Internet architecture.

Applications do not and should not care about IP addresses. The few
protocols that do rely on IP addresses break on modern NAT-ed networks
as a result unless there is specific protocol level fixup.

So attempting to make two names resolve alike without change at either
the application client or the application server is a fools errand. It
is not going to work because that is simply not how the applications
see the world.

If someone wants a2.com to work in exactly the same way as a1.com,
then either the application client has to know to substitute a1 for a2
when it makes the request or the application server has to know to
redirect a2 to a1.

The security model of Web applications is complex and convoluted
enough as it is. We have had almost 20 years now of protocol
extensions being thrown in by people whose idea of a security
consideration is 'tell me why it might be bad, too late its deployed'.
And this proposal seems to be more of the same.

I know that there are some people who will have just written in their
response to the above something along the lines 'well thats their
issue' or 'well they should fix it'. And that is exactly the type of
thinking that got us into this problem. Security is real easy when you
decide the hard part is someone else's problem.

If we are going to change the security model we have to change the
application client or things are going to break.

If we decide we can change the application client, this whole problem
becomes pretty straightforward. Either adopt the 'did you mean'
pointer style approach or allow domains to nominate mappings of one
charset to another.

On Sun, Feb 27, 2011 at 3:00 PM, John R. Levine <[email-masked]> wrote:
> I'm not seeing any particularly pretty ways to fix BNAME to tell which ones
> are approved.  It's not unlike the rDNS problem.
>
> Regards,

---

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Feb 2011 09:38:56 -0800

On Mon, Feb 28, 2011 at 7:07 AM, Phillip Hallam-Baker <[email-masked]> wrote:
<snip>

> the application client or the application server is a fools errand.

I'm not sure how you see this split based on the text above.  My
personal take is that if you want two names be "treated the same" by
an application, you can do one of three things:

1) Make one name refer to the other, transforming the problem of
"treating the same" into "pointing to the canonical name".

2) Provide for all the names equally, so that the same resources are
available at each name (this means not just things like
name-to-address mappings but also certificates with the names used on
them etc.).  This is expensive and difficult, but there may be some
methods to reduce the pain (subjectAltName, provisioning-based
mirroring of resources, new protocol methods).  I think a lot of the
discussion so far has been of the "are there useful DNS mechanisms
that could reduce this pain"?

3) Create a method that allows applications to know which names should
be treated as equivalent.  The difficulty here is primarily that any
names which are not within the same administrative boundary cannot be
treated as equivalent without the records related to both/N
administrative boundaries confirming the equivalence. So the
application would have to understand how to determine the
administrative boundaries, check for the confirmation of equivalence,
and then correctly apply whatever behaviors result from the two names
being the same.  This is far from trivial, as the
applications/protocols may have no defined behavior for "treat these
as the same".  Knowing they are to be treated as equivalent doesn't
help a lot for applications with no sense of what behavior should
result.

><snip>
Please do not use "mappings of one charset to another" to represent
this problem.   At this point, we are all mostly talking about the
Unicode character set and how to map labels derived from sequences of
Unicode characters.

regards,

Ted Hardie

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 28 Feb 2011 13:09:26 -0500

<snip>
> Unicode character set and how to map labels derived from sequences of

well ... it is the case that we have distinct ranges of values, 
subsetting within the Unicode character repertoire, and have, or have 
considered, rules concerning labels composed of values from distinct 
regions.

the latin vs arabic vs indic digit discussion is one example with 
three very modest subsets of that repertoire. should "mixing digits" 
be allowed, pro and con claims followed, invoking directionality or 
similarity, depending upon the choices of subsets to be . there are 
other examples.

so it isn't incorrect to reference, though perhaps charset is 
misleading, mappings from one subset of values to another, in the same 
repertoire. the subsets may, or may not, be contiguous and disjoint, 
or consist of a common set, and two or more point-wise disjoint 
subsets of a single additional set (sc/tc).

-e

---

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Feb 2011 11:42:52 -0800

On Mon, Feb 28, 2011 at 10:09 AM, Eric Brunner-Williams
<[email-masked]> wrote:
>perhaps charset is misleading,

I think at this point casting the "sameness" problem in terms of
charset mapping is more than misleading.  In IETF terms, a charset is
a character repertoire in a particular encoding.  The IDN effort can
be seen as changing the character repertoire in a way that re-used the
previous codepoints in a new encoding.  That was hard enough for
people to get their heads around.

At the label level, .xn--fiqz9s and xn--fiqs8s being equivalent is no
different from colour.example and color.example being "the same".

Let's not confuse our terminology further, please.

regards,

Ted Hardie

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 28 Feb 2011 14:50:56 -0500

do you seriously think phillip was contemplating playing shuttlecock 
with a pair of labels, one GB, one Big5?

i didn't.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Feb 2011 15:11:17 -0500

> with a pair of labels, one GB, one Big5?

Speaking as one who is going to have the happy task of determining
consensus on this topic, but with no particular official role, I
appreciate Ted's insistence on terminological precision.

For instance, I foolishly failed to cut off a debate about mixed case
lookup, which led to speculation about problems that nobody actually
has.  I was wrong to have let it go on, and I'd like to learn from
that mistake by not making it again.  Allowing discussions of more
than one character set is actually going to be worse, because some
people will forget that we're talking always about DNS labels, which
either have no character set at all or else are US-ASCII (and likely
LDH, at that).

A

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 28 Feb 2011 12:12:16 -0800

On Mon, Feb 28, 2011 at 11:50 AM, Eric Brunner-Williams
<[email-masked]> wrote:
> do you seriously think phillip was contemplating playing shuttlecock with a
> pair of labels, one GB, one Big5?
>
> i didn't.
>

Keeping the language consistent helps.  That's all my request was intended for.

regards,

Ted Hardie