Subject: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

From: [email-masked]
Date: Tue, 22 Feb 2011 16:15:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Problem Statement: DNS Resolution of Aliased Names
	Author(s)       : S. Woolf, X. Lee
	Filename        : draft-ietf-dnsext-aliasing-requirements-00.txt
	Pages           : 20
	Date            : 2011-02-22

This document attempts to describe a set of issues that arises from
the desire to treat a set or group of names as "aliases" of each
other, "bundled," "variants," or "the same," which is problematic in
terms of corresponding behavior for DNS labels and FQDNs.

With the emergence of internationalized domain names, among other
potential use cases, two or more names that users will regard as
having identical meaning may sometimes require corresponding behavior
in the underlying infrastructure, possibly in the DNS itself.  It's
not clear how to accommodate this required behavior of such names in
DNS resolution; in particular, it's not clear when they are best
accommodated in registry practices for generating names for lookup in
the DNS, existing DNS protocol elements and behavior, existing
application-layer mechanisms and practices, or some set of protocol
elements or behavior not yet defined.  This document attempts to
describe some of these cases and the behavior of some of the possible
solutions discussed to date.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aliasing-requirements-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 23 Feb 2011 11:47:20 +0000

Colleagues,

Per the announcement to the list last night, the -00 of the "aliases"
problem statement has been posted to the i-d repository.

Your comments are sought. It was pushed out this week to keep the
discussion here going.

It's a working draft and obviously needs a number of refinements on
terminology and details, but the most important thing to establish at
this point is whether it gets the overall landscape right.

I hope we will have a -01 ready before Prague, so we can have a strong
document by then and focus in the meeting on some decisions.

best,
Suzanne

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Feb 2011 09:45:06 -0800

Hi Suzanne, Xiaodong,

Thanks for producing the document; I think it's a good start toward
getting a common terminology around the problem space.  Reading
through the text for "variants", I think it might actually be useful,
though, to start  a little further back.  This might be particularly
useful for non-DNS geek readers.  What I'm thinking of is adding a
section that says, in big bold letters:

The DNS is a known-item lookup protocol.

If you start up from that in big, bold letters, it first clarifies
that any version of "sameness" or "variation" that is not about lookup
is work that has to be done at some other layer.  It also suggests
describing different variant  types in terms of the desired lookup
behavior.

CNAME is the "referral" version--it provides a pointer to another part
of the namespace at which subsequent lookups should occur.  Some
variants may desire "referral" lookup behavior of some type not yet
supported.

Your text makes clear that there is a desired lookup behavior of
"consistent result", where a query to

<query name1, type, class, server IP address>
and
<<query name2, type, class, server IP address>

will return (as much as possible) the same data.

I think there are two flavors of "consistent result".  For one, the
relationship between or among the names queried is exposed.  Much of
the current text seems to assume that it would advantageous to expose
that in order to reduce provisioning costs (especially for
higher-layer constructs like names in certificates).  A different
flavor synthesizes a response that are consistent, but does not
exposes the relationships among labels whose responses are "the same".
(The different cache characteristics is probably something worth
exploring as well).

This probably seems both obvious and pedantic, but given that the
likely audience will include folks more used to search-engine style
behavior, I think trying to describe things in terms of pure lookup
may help in the long run.

regards,

Ted Hardie

---

From: Doug Barton <[email-masked]>
Date: Thu, 24 Feb 2011 00:36:18 -0800

I think this is a great draft, and it expresses both the parameters of 
the problem and the requirements for a solution in the way that I 
understand them (for whatever that's worth).

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: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Feb 2011 11:37:22 +0100

On Wed, Feb 23, 2011 at 11:47:20AM +0000,
 Suzanne Woolf <[email-masked]> wrote 
 a message of 69 lines which said:

> Per the announcement to the list last night, the -00 of the
> "aliases" problem statement has been posted to the i-d repository.

Well, thanks to the authors, it is a very necessary document and I
appreciate that two courageous persons decided to actually work on it.

This being said, I'm not terribly happy with the result. IMHO, such a
document should be used to help people understand the issues before
claiming "We need variants in the DNS" and I'm afraid it is too
complicated at this stage to fill this role. 

More specifically:

The document does not mention clearly that the starting point is a
difference of expectations between normal humans and IETF
members. Normal humans assume that some names are identical
(color.example == colour.example, café.fr == cafe.fr, wells-fargo.com
= wellsfargo.com, ibm.example = IBM.Example, etc) and the DNS does not
deliver what they want. IETF participants know that my last example
works and not the other three but, when you try to explain that to
normal humans, they don't understand and they are right. It should be
stated from the beginning that we simply cannot provide a DNS
behaviour that will be seen by normal users as "natural" and
"unsurprising" (because of the complexity of the rules and their
language-dependant character). So, we should warn users, not try to
create mechanisms that will *always* fall short of their expectations.

Second, the document seems to assume that the problem is mostly, if
not exclusively, an IDN thing. As the examples above (and the examples
of phishing sites) show, this is far from true. In registries which
are still discussing IDN registration (like .FR, see
<http://www.afnic.fr/actu/nouvelles/271/10-february-2011-idn-workshop-organised-by-afnic>),
some people keep telling that IDN are complicated and we should not
allow them because of this complication. But the examples above show
that IDN are not the only issue. It would be better if the document
clearly stated that. (Another french story: in .FR, the law - not the
registry policies - says that city names are reserved to the city
council, and this is done in a dash-independent way: saint-quentin.fr
and saintquentin.fr are therefore part of the same "bundle". Since the
law is only for cities, not for corporations, saint-gobain.fr and
saintgobain.fr are still distinct. Imagine the user confusion!)

The case (pun intended) of case-insensitivity is a complex one. It is
obviously impossible to change the rules now but the document says
several times that the case-insensitive rule is a good one, which is
not obvious. The case-insensitivity rule is not perfect (in French,
Poussin is a painter and poussin a bird) and users legitimally ask
"why case is not important but a stupid dash is?". The document's only
negative remark about case-insensitivity is about its use in
compression (section 2.3.1), which seems to me an useless detail
(because only implementers see it). I suggest to drop this sentence
about compression: the biggest lack of consistency is not in
compression, it is in the fact that DNS is fuzzy on some criteria
(case) and strict in others (dash, spelling).

The document mentions several times (for instance 3.1.1) the perceived
need to be able to distinguish if a name is a member of a bundle. This
need is not explicitely stated in the Proposed Requirments section (4)
and is questionable. What is the rationale for this unstated
requirment? After all, unless you use DNSSEC, I do not think there is
today a way to tell if a name was generated by a wildcard expansion
(if you want to test, tell me if real-name1.office--enregistrement.fr
is real or synthetic).

The section on Applications (3.3) apparently does not mention the fact
that many application protocols (HTTP and SMTP are two obvious
examples) need to be configured to recognize the bundle. (Which is a
strong argument against a new DNS solution, since it will be useless
anyway.)

Technical nit: I find no mention of RFC 3403 which seems a (corner)
case where even a purely DNS solution would be a problem if a rule
uses the original domain name for rewriting.

Editorial nit: the reference to the IDNA standard is now RFC 5890.

---

From: Doug Barton <[email-masked]>
Date: Thu, 24 Feb 2011 12:34:09 -0800

On 02/24/2011 02:37, Stephane Bortzmeyer wrote:
>   Suzanne Woolf<[email-masked]>  wrote

So it's too complicated, but you want to add to it? :)

> members.

I certainly don't think we need to draw the dichotomy quite that way. :)

> Normal humans assume that some names are identical

I agree that more examples would help improve the readability of the 
document for the non-tech folks, and there will be quite a few of them 
who will be reading/interested in this document. I disagree however that 
the logical conclusion of "the problem is a difficult one" is "therefore 
we should do nothing." I think this document makes a good start at 
laying out the problems, and should be expanded to make it more clear 
where solutions are possible in the DNS layer, and for which problems 
solutions will have to come from other layers.

> saintgobain.fr are still distinct. Imagine the user confusion!)

Registry policy could help with this user confusion. If only we knew 
someone in a position to help with that ...

> (case) and strict in others (dash, spelling).

That would have value for the non-technical audience of the document, yes.

> requirment?

My understanding is that it is to help application developers to be able 
to auto-configure things to handle multiple variants. I think this is a 
good idea, and you made a good catch in noting that it's not in Section 4.

> strong argument against a new DNS solution, since it will be useless

I believe that the common case will be that there are few enough 
variants that users who wish to use them all will simply configure them. 
This is already the case for "the same" domain in multiple TLDs, or 
non-IDN "variants" (of which your dash examples are a great case in 
point), and IS already the case for those who have chosen to provision 
the IDN variants they've been delegated. There is nothing about 
providing a DNS solution to the variant problem which makes _using_ the 
variants harder (or for the most part, different) and we have at least 
the chance to make life easier.

To that end, the security and/or application section(s) of the document 
could probably use a mention of name-based virtual hosting for http. It 
would also be nice to provide a discussion of the fact that HTML5 + 
DNSSEC + CERT has a chance to replace hostname-based SSL certs 
altogether, but given that I'm fuzzy on the details and don't have the 
time to do the research to provide text consider it only the whispiest 
of hints of a suggestion. :)

Doug

--

---

From: "George Barwood" <[email-masked]>
Date: Thu, 24 Feb 2011 22:30:03 -0000

The draft gets to the heart of the issue here

   One aspect of this is
   the notion or expectation that multiple sets of names may be similar
   to a human user, and expected to behave "the same" or as "aliases" of
   one another, across multiple services and interactions.

It seems to me that in fact the number of variations of a complete name will be quite small in practice.

There will be cultural conventions for the correct "spelling", in some cases there may be a few alternative conventions.

It's not hard to handle a moderate number of variations in DNS : it may impose some additional overhead, but sensible tools for administering domains and registrations should minimise this.

Again at the application level, proper tools for handling variations are quite straightforward - it should be straightforward to configure web, email and other servers to recognise standard variations.

Where the draft states:

   Howeverer, it is not
   clear how much of the user and operator requirements for "aliases"
   can be met by mechanisms for provisioning DNS zones, at acceptable cost.

I don't believe the costs are actually unacceptable at all.

Besides, users these days do not type domain names very often - when looking for an website we usually use search engines. One might give an email address over the phone, but this is not an everyday event.

So I think the current situation is not as bad as has been implied, and therefore it is only worthwhile pursuing technical changes to the DNS standard if the costs of such changes are low, which I doubt.

George

---

From: Alex Bligh <[email-masked]>
Date: Sat, 26 Feb 2011 13:07:54 +0000

Suzanne,

> Your comments are sought. It was pushed out this week to keep the

I think this is a very useful draft.

My main comment is that I had expected the draft to concentrate more
on what types of behaviour were requirements from a functionality point
of view (rather than a not breaking stuff point of view). We know how
to not break stuff (don't fix things). But we don't actually yet know
what the proposed required behaviour is. Some requirements conflict.
I'd sort of presumed we'd have a table of requirements (both sorts)
vs. potential solutions.

See below for detailed comments.

-- 
Alex Bligh

--- draft-ietf-dnsext-aliasing-requirements-00.txt	2011-02-23 
00:08:14.000000000 +0000
+++ draft-ietf-dnsext-aliasing-requirements-00-amb-comments.txt	2011-02-26 
13:01:45.000000000 +0000
@@ -22,6 +22,16 @@
    potential use cases, two or more names that users will regard as
    having identical meaning may sometimes require corresponding behavior
    in the underlying infrastructure, possibly in the DNS itself.  It's
+
+AB: Is the desired property really 'corresponding behaviour in the
+AB: underlying *infrastructure*' or 'corresponding behaviour in the
+AB: applications used by those users'. I suspect it is the latter and
+AB: this is a critical distinction. I don't think your average user
+AB: can see how the underlying infrastructure works. If the result at
+AB: the user experience level is the same, that should be good enough.
+AB: Indeed BNAME type approaches seek to replicate the behaviour at
+AB: user level using a different infrastructure.
+
    not clear how to accommodate this required behavior of such names in
    DNS resolution; in particular, it's not clear when they are best
    accommodated in registry practices for generating names for lookup in
@@ -177,13 +187,28 @@
    assumptions about how "names" or "words" work.  One aspect of this is
    the notion or expectation that multiple sets of names may be similar
    to a human user, and expected to behave "the same" or as "aliases" of
-   one another, across multiple services and interactions.  The DNS was
+   one another, across multiple services and interactions.  The DNS was 
originally
    designed with the implicit expectation that names would be based on
-   ASCII characters, and the "similarity" or "sameness" property doesn't
+   ASCII characters, and the "similarity" or "sameness" property did not
    seem to arise terribly often in the names people originally wanted to
    use in the DNS; thus the requirements of identical resolution of
    "aliased" or "bundled" names hasn't figured prominently as an
    attribute that needed to be accommodated in the generation or lookup
+
+AB: Perhaps add something like: "The DNS was originally designed from the
+AB: perspective of those using ASCII characters only, and (to a great
+AB: extent) labels consisting only of characters 0-9, A-Z, a-z and -.
+AB: An early decision was made to treat character case as insignificant
+AB: in lookups (one form of bundling), but to treat the presence of
+AB: hyphens as significant (another form of bundling). This currently
+AB: leads to situations where some names users might consider should
+AB: perform identically do not perform identically (e.g. a-b.example.com
+AB: and ab.example.com), whereas other pairs do perform identically
+AB: (e.g. AB.EXAMPLE.COM and ab.example.com). A user who does recognise
+AB: the significance of dots in names, or TLDs may have yet greater
+AB: expectations of DNS to resolve seemingly similar names, none of
+AB: which are ever likely to be met."
+
    of DNS names.  However, with the standardization of internationalized
    domain names protocols (ref: IDNA and IDNAbis), more and more
    internationalized domain name labels [RFC3490] are appearing in DNS
@@ -193,17 +218,27 @@
    users consider "the same" in some languages.  Accordingly, Internet
    users hope for such labels to behave in DNS contexts as they expect
    the corresponding human constructs to behave, regardless of the
-   specific service (smtp, http, etc.) involved..
+   specific service (smtp, http, etc.) involved.
+
+AB: Perhaps it is necessary to distinguish between these expectations
+AB: and the expectations of users we already fail to meet with
+AB: regards to case and hyphens, dots etc. as set out above.

    The general issues of what "the same" means, or of defining
    "variants" in human scripts as codified in Unicode (or anywhere else)
    are well outside the scope of the DNS or the expertise of most of the
    people who work on it.  They are matters for philosophers and
+
+AB: This is actually a key difference between the original design
+AB: decision re case insensitivity etc. and IDNA.
+
    applications developers, respectively.  However, to the extent that
    these issues can be specified as involving the resolution of names in
    the DNS, it's reasonable to describe those expectations and attempt
    to accommodate them.

+AB: Section break here on existing methods?
+
    There is some existing technology defined in the DNS for behavior
    that can be described as one name behaving "the same" as another.
    For a single node in the DNS tree, CNAME can be used to map one name
@@ -215,7 +250,7 @@
    that combines the characteristics of CNAME and DNAME is not currently
    defined in the DNS.

-   If existing protocol does not meet the zone administrator's need to
+   If the existing protocol does not meet the zone administrator's need to
    be able to treat one label, name, or zone as "the same" as another,

@@ -400,6 +435,30 @@
 2.2.  Identical DNS Resolution for Bundled DNS Names

    To some extent, the desired behavior can be described: "identical DNS
+
+AB: Are you trying to describe one particular form of desired behaviour
+AB: (i.e.  do you mean "this form of desired behaviour") or stating
+AB: that this is *the* desired behaviour. If the latter, I think this
+AB: is 'yet to be proven'. We have the example of SSL web sites
+AB: where it's (probably) precisely the opposite of the desired behaviour,
+AB: as currently, protocol developments aside, a different certificate is
+AB: needed for each variant, and each of those needs a different IP
+AB: address. Enforcing identical resolution (particularly at the TLD
+AB: level) between (say) TLDX and TLDY is likely to mean that the
+AB: operator of secure.example.TLDX has no choice but for
+AB: secure.example.TLDY to resolve to the same IP address, which will
+AB: inevitably lead to a security warning on the browser of the human
+AB: who thinks these two are identical - this is almost certainly
+AB: worse than (say) a redirect.
+AB:
+AB: [Later]: I see some of this is handled under 2.4 and 3.3, but reading
+AB: this in order doesn't make much sense. There is a bit of horse-before
+AB: cart here in that the draft seems to start by saying "identical
+AB: DNS resolution is useful" then quite a long while later (3.3)
+AB: say "actually, it may not be". Is the better approach not to say
+AB: "similar end user behaviour is the goal" and the question then
+AB: is "how can that be achieved?"
+
    resolution" means that the process of resolving two domain names will
    end with the same result, in most cases the same IP address.  In the
    history of DNS protocol development, there have been two attempts to
@@ -423,7 +482,7 @@
    variants, and in fact their characteristics differ widely, but it's
    possible to define some.  For example, the definition of variant
    characters in the JET Guidelines [RFC3743], intended for use with the
-   CJK language/script communities, is roughly this: One conceptual
+   CJK language/script communities, is roughly this: one conceptual
    character can be identified with several different Code Points in
    character sets for computer use.  In UNICODE definitions of some
    scripts, including Han (chinese), some characters can be identified
@@ -434,6 +493,14 @@
    (similarity in appearance is not required by the definition but often
    occurs).

+AB: it is probably worth stating that "It is inevitable that no character
+AB: variant rule is ever likely to encompass all characters of similar
+AB: appearance, as this may be undesirable (consider lower case l, upper
+AB: case I and number 1 in some fonts), and is likely to be too complex
+AB: in a unicode environment. No aliasing scheme will solve the problem
+AB: of protecting users and domain registrants from domain names that
+AB: are crafted to look the same as another, but are in fact different."
+
    With the introduction of IDNs in the DNS, perhaps most prominently in
    the root zone, decisions about how to deal with IDN variants is a
    significant challenge ahead of us.  We describe here a couple of
@@ -455,6 +522,17 @@
    (U+4E2D U+570B) are in the root today.  The first one (U+4E2D U+56FD)
    can be considered the "original" IDN TLD and the second one (U+4E2D
    U+570B) can be considered the IDN TLD "variant".  Ideally, it should
+
+AB: This is begging the question. Would it really be ideal? Assume
+AB: all the problems at the NS layer were solved and looking up
+AB: foo.bar.china1 gave the same result for foo.bar.china2, for
+AB: all values of foo.bar. This would then give the problem
+AB: with SSL certificates (and, no doubt other application layer
+AB: protocols). The problem is that applications using DNS
+AB: also need to recognise the fact that the two are variants.
+AB: So either you need to add this to the "However:" bit below,
+AB: or not assume that this is in fact idea.
+
    be possible to treat the original IDN TLD and its IDN TLD variant as
    "identical" for purposes of DNS resolution, in a way similar to the
    case mapping most DNS users take for granted, in which the uppercase
@@ -475,6 +553,22 @@
    share some operational experience around implementation of registry
    policy regarding managing multiple DNS trees as "the same"

+AB: I think the Chinese problem is actually more complex than you
+AB: make out. I believe you have described the 'chinese TLD'
+AB: prolem, rather than the general problem of 'Simplified and
+AB: Traditional Chinese' which is how the section is headed. The
+AB: section could thus be renamed - in which case one should note
+AB: that the TLD problem alone could be solved by registry policy
+AB: (as you mention with Greek, below). However, whilst I may have
+AB: misunderstood, I thought the 'simplified and traditional
+AB: chinese' problem was that variant ideograms could occur anywhere
+AB: within the domain name, and the mapping between them was not
+AB: done on a per (unicode) character basis, i.e. AB might be
+AB: equivalent to PQ, and CD to RS, but that doesn't necessarily
+AB: mean AD is equivalent to PS. Similar, EF might be equivalent
+AB: to U (one character) and GH to VWX (three characters). Saying that,
+AB: my limited understanding of this problem is second hand.
+
 2.3.2.  An example: Greek

    In Greek, almost every word has the "tonos" accent sign, but where it
@@ -494,8 +588,11 @@
    "the same word," in a sense very much like the case insensitivity
    that native users of Latin script take for granted in the DNS.

-
-
+AB: Perhaps mention that here or elsewhere it might be possible to
+AB: address these problems at the presentation layer, i.e. entirely
+AB: outside DNS (or arguably at nameprep stage). For instance, tonos
+AB: characters could be stripped and final sigmas rewritten as
+AB: normal sigmas. This is not ideal, but is one angle of attack.

@@ -519,7 +616,7 @@
    for zones maintained in parallel but for less work.  However, we
    later assert a proposed requirement that synthesizing the same record
    as a query would have obtained from an enumerated parallel tree isn't
-   enough-- that the property of association or "sameness" we're
+   enough; the property of association or "sameness" we're
    creating with specific mechanisms needs to be useful in some specific
    way to the consumer of the data.

@@ -572,6 +669,18 @@
        the use of DNS records or other mechanisms not really intended
        for the purpose, leads to confusion and inconsistency.

+AB: I wonder if it is worth mentioning that canonicalisation of a name
+AB: may be either a useful, or an undesirable process. Taking the
+AB: simplified Chinese example, or Arabic, some brands may wish to
+AB: appear (including in the browser bar, or in email addresses) written
+AB: one way, rather than another. On a web site this could be achieved
+AB: through a meta reload. On email by accepting all inbound email
+AB: variants but only using one outbound. Here, a variant solution
+AB: which canonicalised a single variant to a canonical version would
+AB: be useful (like a CNAME that doesn't actually get looked up except
+AB: by the application). In other circumstances, there has been
+AB: a desire expressed for all variants to be treated as equal
+AB: citizens.

 3.  Operational Considerations

@@ -601,7 +710,21 @@
    technology; it can be done, and is done today, entirely with
    provisioning logic and registry policy.

+AB: Note this isn't only a registry solution. It could be done by
+AB: users too (e.g. through a zonefile preprocessor that was
+AB: run prior to signing of the zone).
+
    However, it doubles the work and the number of records required.  If
+
+AB: I'm not sure it does double the work (presumably it's done
+AB: programmatically) but the effect on the number of records could
+AB: be far worse than doubling. Taking an example where 2 characters
+AB: are variants of eachother, the number of variants could be
+AB: as much as 2^((63-4)/(bytes per character)), i.e. huge. This
+AB: would therefore require limiting the number of supported
+AB: variants in the registry, either by policy or by economic
+AB: means
+
    provisioning isn't done carefully, errors can arise, leaving
    inconsistencies.  And provisioning multiple trees does nothing to
    link the resulting names directly; there is no property of
@@ -626,6 +749,12 @@
    maintained in parallel and possibly available for audit by the
    authority over example.com, depending on its delegation policy.

+AB: That may be a desirable feature as opposed to a limitation. For
+AB: the reasons given above (SSL example) it may well be that the
+AB: need for ensuring sameness is only in the zones managed by the
+AB: registry and not for the child zones for which it is not
+AB: authoritative.
+
 3.1.2.  Impact of special mechanisms

    Once we begin to consider mechanisms for maintaining parallel zones
@@ -695,6 +824,10 @@
    An example used more than once in discussion is provided by SSL, as a
    protocol that uses domain names without necessarily using the DNS
    protocol per se.  SSL certificates are tied to one domain name.  It
+
+AB: my understanding (and I am not an expert) is that this is changing,
+AB: but certificates supporting more than one are not widely supported.
+
    would be helpful to applications to have a non-protocol-specific way
    to identify securely cases where multiple domain names can be
    canonicalized to the domain name used for an SSL certificate.
@@ -749,17 +882,67 @@
        as they may be, it's not clear where the incentives would lie to
        deploy it.  This is particularly a concern for implementors and
        application developers.
+
+AB: I am not sure this is a reasonable requirement. After all, IDN
+AB: itself would have failed this test, as it is 'more overhead'
+AB: than LDH zones. The 'incentive to deploy' is presumably that
+AB: customers want it. May be add the word "disproportionate' before
+AB: 'overhead' within the first line.
+
    4.  Any mechanism proposed MAY require new RRtypes and special
        processing for them.
    5.  Any mechanism proposed MUST NOT only reduce costs of generating
        and providing authoritative service for DNS zones.  It would be
        too easy to reduce costs on the authority server provider while
        adding costs elsewhere, particularly in terms of complexity.
+
+AB: The first sentence here is ambiguous and says something different
+AB: from the second. A solution which increased costs for everyone
+AB: satisfy this criteria on one reading. Proposed text for
+AB: first sentence:
+AB: "Any mechanism proposed MUST NOT, in order to reduce cost for
+AB: generating and providing authoritative service for DNS zones,
+AB: disproportionately increase costs elsewhere, particularly
+AB: in terms of complexity"
+
        Given the central importance of DNS service to Internet
        operations, any change undertaken to lower the cost to providers
        may be useful, but should not simply shift costs to DNS users,
        whether applications or end users.

+AB: These are all, I think, impact requirements, i.e. "don't break
+AB: things". I think we also need to set out requirements in terms
+AB: of positive functionality.
+AB:
+AB: Here are some things that have been suggested are requirements.
+AB: I don't know whether they actually are requirements.
+AB:
+AB: * Ability for any variant name to resolve to the same records
+AB:
+AB: * Ability to do the above automatedly (i.e. without manually
+AB:   duplicating all records for variant names)
+AB:
+AB: * Ability to have exceptions to the above
+AB:
+AB: * Ability to work at TLD, registry and end registrant level
+AB:
+AB: * Ability to enforce sameness on child zones as well as parents
+AB:   (recursive sameness), i.e. more than that the child zones
+AB:   just have the same NS records
+AB:
+AB: * Ability for RRs within children of two "same" zones to differ
+AB:   (non-recursive sameness) - that's exactly the opposite to the
+AB:   above and is driven by the SSL/application layer point
+AB:
+AB: * Ability to support an arbitrarily large number of DNs per
+AB:   bundle
+AB:
+AB: * Ability for an application to be able to canonicalize a name
+AB:   i.e. for the application to be able to determine the canonical
+AB:   name not just get an IP address back.
+AB:
+AB: * Ability for all variant names to be treated as 'equal citizens'
+AB:   (no one canonical variant)

 5.  Possible Solutions

@@ -773,6 +956,20 @@
    other, or in preventing the use of such variants as might be
    considered confusing or dangerous.

+AB: At the risk of generating more work, I think it might be useful
+AB: to list some mechanisms which result in no protocol work
+AB: here, so that we have a proper taxonomy of all requirements.
+AB: I am sure there will be some need to produce a matrix of solutions
+AB: versus conformity with requirements, and for that we need to
+AB: have a common language of what potential solutions mean. The
+AB: ones not listed here that I can immediately think of are:
+AB: - online synthesis
+AB: - the "I think you mean" record, allowing a canonicalizing pointer
+AB:   at the application level, and returning NXDOMAIN to anyone
+AB:   not supporting it (I think someone else had a better name)
+AB: - manual provisioning / zonefile preprocessing
+AB: - rewrite DN at application / nameprep stage
+
    In addition, there are new proposals for DNS protocol to support
    "aliases" in the DNS as part of the desired behavior of "variant"
    names: Names direction[BNAME], and "Zone clone".
@@ -867,6 +1064,9 @@
    compatibility to avoid harm to implementations that expect, and use,
    the old behavior.

+AB: I think it would be fair to make CNAME+DNAME a separate proposal
+AB: as they have different characteristics (subtle breakage vs. new RRs)
+
 5.2.  Zone Clone

    The proposal of "zone clone" or "dns shadow", is an alternative

---

From: John Levine <[email-masked]>
Date: 27 Feb 2011 19:15:42 -0000

>My understanding is that it is to help application developers to be
>able to auto-configure things to handle multiple variants. I think
>this is a good idea, and you made a good catch in noting that it's
>not in Section 4.

Yes, I was going to point out the same thing.

In the security section, I'd suggest adding something about who can
make one domain an alias of another.  Currently, anyone can point a
CNAME or DNAME at anything, but since few applications currently
autoconfigure based on CNAMEs, it's not a big deal.  If
autoconfiguration becomes common, the security issues are a lot more
complex.

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: Patrik Fältström <[email-masked]>
Date: Sun, 27 Feb 2011 21:08:30 +0100

There are a few things I think makes this discussion hard...and that is that the overall usability is a requirement in the usability, manageability etc while what we talk about is "only" what we do in DNS. What we should (and can) do in DNS must then match whatever application layer/protocol behaviour, which in turn depends on how the protocol works.

What I *think* could be interesting is one of these things as very high level issues to look at, that btw I think sort of is written in the draft, but using DNS terminology ;-)

1. Aliases

1.1. If we today have two delegations, we do have a risk that one of the delegations changes holder while the other does not. Can one of the two be an alias to the other, and the two then bundled by policy in the registry so we absolutely know one and only one holder controls the data for the names (plural)?

1.2. If we today have two delegations, synchronization of the two delegations imply provisioning systems must place the same records in two zones. Can we solve the problem in different ways?

2. Support of more application layer aliases

2.1. In HTTP and a few other protocols, we have the ability to do a redirect inside the application layer protocol itself. We do not have that in all protocols. In other we have things like the MX records. Do we with IDN etc need more of these, and do we need a mechanism in DNS that "help" such redirect in a "lower" layer in the resolution algorithm?

2.2. When using HTTP HOST header, and SSL where the DN of the cert is matched with the domain name used, it is kind of problematic to match the application layer with what originally was entered by the user. Is there some need for DNS layer aliases that changes what later is matched in the application layer comparisons?

3. Comparison algorithm

3.1. We can not change the matching algorithm in DNS

3.2. Given we can not change the matching algorithm in DNS, do we need something in DNS that matches some new(?) matching algorithm in the application layer so that the two together produce the result we are after?

4. How do we ensure skilled apps people manage to work with skilled DNS people so that the end result is optimal? (something IETF is not always very good at...)

Now beat me up!

   Patrik

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 28 Feb 2011 09:48:59 +0100

On Sat, Feb 26, 2011 at 01:07:54PM +0000,
 Alex Bligh <[email-masked]> wrote 

> +AB: run prior to signing of the zone).

A registry can be at any level. See the IDN RFCs which use the word
"registry" for "anything that manage a zone, whether the zone is .com
or foobar.momandpop.example".

---

From: Alex Bligh <[email-masked]>
Date: Mon, 28 Feb 2011 09:26:36 +0000

> or foobar.momandpop.example".

I'm not sure that's the natural meaning of the term, nor that
that's how the draft uses it, e.g. from Section 5 in the I-D

>    In
>    addition, as described briefly above, registry operators have a great
>    many techniques for applying policy to what names can be registered,

but if we going to use "registry" to mean "zone manager", we should
say so. Otherwise, we should just say "zone manager" where it's
applicable to more than registries (meaning ones allowing third
party registrations).

-- 
Alex Bligh

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Feb 2011 07:02:13 -0800

> applicable to more than registries (meaning ones allowing third

There may be a difference between registries and zone managers, but it 
is not in the protocol. A registry has some interface with (normally) 
humans to receive information about the creation of new zones and the 
DNS-applicable data for existing zones; registries are also expected to 
do authorization and authentication of those (normally) humans. Zone 
managers only deal with zone data, (normally) given to them by the 
registry for the zones being administered.

Normally, there isn't a distinction between the two entities, but in the 
case of this document, there is. It is the registry that would be 
responsible for determining the aliases for a zone and enumerating them 
to the zone administrator. The zone administrator simply does the right 
technical bits to make all the aliases work. In many cases, the two 
roles will be the same for aliasing, but for many cases, they will be 
completely different organizations.

--Paul Hoffman

---

From: Dan Schlitt <[email-masked]>
Date: Mon, 28 Feb 2011 12:40:55 -0500

Back when this discussion started a long time ago I thinkit was perhaps 
the first message that listed a number of possible approaches. One of 
them was a presentation layer in the DNS. The statement with this was 
that it had been rejected earlier and so need not be considered.

As this long discussion has gone on with more problems than solutions I 
have often thought "now wouldn't that problem be better avoided with a 
presentation layer."

Isn't the problem what domain name the user asks for and getting the 
right behaviour from the DNS. Isn't this a presentation problem and not 
a problem of the basic DNS?

Weren't we told that we weren't dealing with "words" even though some 
things might look like words. This means that we don't have to deal with 
things like the difference between american english and british english.

If this is actually an application layer problem isn't it reasonable to 
look for a way to fix it generally instead of expecting each application 
to do it for itself. This suggests placing something between the 
application and the DNS.

Is there some way that the WG can get out of this pattern of going round 
and round over the same old territory?

/dan

-- 

Dan Schlitt
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Feb 2011 18:26:10 +0000

> Date: Mon, 28 Feb 2011 12:40:55 -0500
> From: Dan Schlitt <[email-masked]>
> ...

yes.  declare defeat.  see Message-ID: <[email-masked]>.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 28 Feb 2011 18:46:32 +0000

> have often thought "now wouldn't that problem be better avoided with a

I believe every possibility (including doing nothing) has been
rejected at least once, so on that basis +1 to this being (re)considered
at least to the extent of being included in the draft as a possibility.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Mon, 28 Feb 2011 18:47:15 +0000

> yes.  declare defeat.  see Message-ID: <[email-masked]>.

I think defeat has been rejected too :-)

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Feb 2011 13:54:43 -0500

> at least to the extent of being included in the draft as a possibility.

I can't speak for others, but I have not rejected every possibility at
least once; I have rather attempted to encourage some exploration of
possiblities in the interests of getting the problem statement
correct.

The editors of the problem statement are in earnest request of text,
so if you have observations that you think could be turned into useful
parts of that document, I urge you to send it.

I am told by the editors that there will be a -01 before IETF 80.

Consistent with what we said when raising the possibility of not
requesting a session at the Prague meeting, your chairs are eager to
wind up discussion on the problem analysis.  The only reason we
requested the session in Prague was the renewed discussion of this
topic.  

So we are quite keen to finish laying out the issues, ideally after
the Prague session.  At that point, we can ask properly whether we
have proposals that will solve the problem as we understand it.

Best,

A

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

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 01 Mar 2011 00:37:39 +0000

On 27/02/11 20:08, Patrik Fältström wrote:
> There are a few things I think makes this discussion hard...and that
> is that the overall usability is a requirement in the usability,
> manageability etc while what we talk about is "only" what we do in
> DNS. What we should (and can) do in DNS must then match whatever
> application layer/protocol behaviour, which in turn depends on how
> the protocol works.

	Or, should we look at the use cases at a higher level,
	and identify which components, including (but not limited to)
	the DNS, need to be adjusted to achieve the desired result?

	In this case, the question becomes no longer one of matching
	the DNS to how the other components actually work, but to
	how they will work in the future to support a coherent, rather
	than a fragmented, "aliasing" concept.

	I'm pretty sure that solving "the aliasing problem", whatever
	it is, cannot be done by adjusting only the DNS.

> What I *think* could be interesting is one of these things as very
> high level issues to look at, that btw I think sort of is written in the
> draft, but using DNS terminology ;-)

	I'm not sure quite what you're saying.

	Expressing higher-level issues in DNS terminology can either
	help us to visualize those issues, or blind us to the non-DNS
	aspects;  perhaps both of these effects occur at the same time.

> 1. Aliases
> 
> 1.1. If we today have two delegations, we do have a risk that one of
> the delegations changes holder while the other does not. Can one of the
> two be an alias to the other, and the two then bundled by policy in the
> registry so we absolutely know one and only one holder controls the data
> for the names (plural)?
> 
> 1.2. If we today have two delegations, synchronization of the two
> delegations imply provisioning systems must place the same records in
> two zones. Can we solve the problem in different ways?

	I believe that this is one strong attraction of the BNAME
	concept.  Performing pseudo-delegation in parallel with
	traditional delegation in the parent zone leaves the
	registrant/deleg[at]ee with just a canonical instance of
	the child zone to look after.  But this only applies when
	there is a common (bundle of) parent zone(s).  So, it would
	work for example[+/-final_sigma+/-tonos].gr, but not for the
	vixie.sf.ca.us/vix.com bundle mentioned in Paul's slides of
	almost a year ago.  That this is so is not intrinsically
	problematic, as the motivations are different in each case.
	In the .gr (also .cn, IIUC) case, the motivation appears (to
	me) to arise from a desire on the part of the TLD registry to
	provide a coherent offering to customers (registrants) in
	support of what might be called "naturally arising" bundles.
	Paul's example is rather "bottom-up" than "top-down", and
	is driven by the customer rather than by the provider (or the
	provider's politico-regulatory circumstances).

> 2. Support of more application layer aliases

	More in terms of quantity, or just "more coherent"?

> 2.1. In HTTP and a few other protocols, we have the ability to do a
> redirect inside the application layer protocol itself. We do not have
> that in all protocols. In other we have things like the MX records. Do
> we with IDN etc need more of these, and do we need a mechanism in DNS
> that "help" such redirect in a "lower" layer in the resolution algorithm?

	SMTP has MX; others have SRV; HTTP is an outlier in that it
	avoids this kind of assistance from the DNS.  It's a significant
	and pathological outlier because of the way HTTPS works.

> 2.2. When using HTTP HOST header, and SSL where the DN of the cert
> is matched with the domain name used, it is kind of problematic to match
> the application layer with what originally was entered by the user. Is
> there some need for DNS layer aliases that changes what later is matched
> in the application layer comparisons?

	2.3 (?)
	It may be worth examining the semantics of distinct, but
	seductively similar, elements in different URL schemes.

	For example, in the "mailto:" URL scheme, there is a "domain
	part" which is essentially a reference to a naming authority.
	In contrast, the "http:" scheme uses a superficially similar
	component strictly as a reference to a host.  This is arguably
	an incoherence at the semantic level between the different URL
	schemes which, if resolved, could eliminate the difficulty
	which arises today from matching the DN of the cert to the
	"host" component of a URL whose scheme is "http:".

	I'm suggesting that this incoherence should be resolved by
	having the application exploit already available DNS
	mechanisms.  New DNS-layer aliasing seems to be un-necessary.

	Re-writing the definition of the "http" URL scheme so that
	not only

		'http' ':' '//' host [: port] '/' ...

	but also

		'http' ':' '//' domain-part '/' ...

	would be allowed, might lead to a resolution based on SRV
	records.

	I suggest that this approach is worth following, and will be
	no more painful than transitions we have already chosen (or been
	forced) to face, as between A and MX, or between A and AAAA
	records.  If we want the omelette, we can't insist on not
	breaking the eggs.

	With this approach the DN of the SSL cert would match the
	target host of each SRV record.

> 3.2. Given we can not change the matching algorithm in DNS, do we
> need something in DNS that matches some new(?) matching algorithm in the
> application layer so that the two together produce the result we are after?

	For example, in the case where the HTTP HOST header refers
	to a domain-part for which the server is not configured, the
	server might query the DNS for a matching [BCD]NAME record,
	and use the URL corresponding to the corresponding canonical
	name (which it could cache) as the key to its document store.

	Alternatively, in the same circumstances, the server could
	send the browser a "please canonicalize" error response.

	Either of these approaches, if feasible, would appear to
	eliminate the need to pre-configure an application server
	for all of the potential "equivalent keys" which might
	appear in an incoming request.

> 4. How do we ensure skilled apps people manage to work with skilled
> DNS people so that the end result is optimal? (something IETF is not
> always very good at...)

	Pass ... 8-)

	IHTH, but I'm not at all sure.  I think we're still in a
	brainstorming phase, so "off-the-wall" is (so I hope) not
	necessarily "bad".

	Niall