[dnsext] Some thoughts on the updated aliasing draft

Ted Hardie <ted.ietf@gmail.com> Sat, 26 March 2011 17:50 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 16E1B3A6955 for <dnsext@core3.amsl.com>; Sat, 26 Mar 2011 10:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.541
X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 04S49vdzmOf8 for <dnsext@core3.amsl.com>; Sat, 26 Mar 2011 10:50:22 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id 2F9D63A67EC for <dnsext@ietf.org>; Sat, 26 Mar 2011 10:50:15 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1872318iwn.31 for <dnsext@ietf.org>; Sat, 26 Mar 2011 10:51:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=DVJlOCqugNQEtpGN4hFqDdYjTm2P4zFGF+qGZfnH9wk=; b=map8/EhFHfQBbsM5bmcCNaVtuVP75fp1AeVE6meGCsxLv2oWk3AVHVydf1dacvKp3q eWOxv1mfPkrBOiofGZyBTyzZnYckZmjvHSXB3IFSL8S9B93qk4ezRTRoUlJqOvmcF8No rOxQAz+t0bIxRSgRZH+YM4hO1PdY2PEoroPJs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h1MWFfx6jw+05jb/bkaRo/iwjV/kkOMfBISQGeCg7TAKnG8ETGEp3CZ0Cc1xnR5k/3 K6TkMLYtqBFGEfXeCLS191dItVc4EXkA6kBgje66E/mQgJCO0rD9nS4w/fFjSj8o8UYd YiaC6E8RMdkQ7rXvFH6o6ELlyqO7EHt8+67Zk=
MIME-Version: 1.0
Received: by with SMTP id bj1mr2079205ibb.145.1301161911251; Sat, 26 Mar 2011 10:51:51 -0700 (PDT)
Received: by with HTTP; Sat, 26 Mar 2011 10:51:51 -0700 (PDT)
Date: Sat, 26 Mar 2011 10:51:51 -0700
Message-ID: <AANLkTimOKdFt9PyRD_hEdQstyak9Z-eCOAHm3FYooMjL@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: dnsext@ietf.org
Content-Type: multipart/alternative; boundary="001636e0b90b83f466049f665d09"
Subject: [dnsext] Some thoughts on the updated aliasing draft
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Mar 2011 17:50:24 -0000

The draft under discussion  was updated just before the meeting, and it has
some useful updates.  I think, however, it is anxious to scope the problem
in ways that leave out what I believe is a well-recognized aspect of the
basic desire of those who brought the work forward.  The draft says:

  To some extent, the desired behavior can be described: "identical DNS
  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
  specify such "identical resolution" behavior:CNAME[RFC1034] which
  maps or redirects itself, and DNAME[RFC2672] which maps or redirects
  its descendants.  In the case of bundles or groups of names, however,
  some operators have asserted they need identical DNS resolution at
  all levels' domain names, including the domain name itself and its

But the reality is that the operators actually want the applications to
treat two domain names as the same.  That's a lot harder than simply having
the same IP returned when looking up an A record at each one.  Especially in
the case of secured zones, it involves issuing multiple certificates or
certs that cover both, and otherwise ensuring that whatever services are
present at that IP can effectively handle either name.  It's moderately
obvious that this is a tougher job than putting in a CNAME or DNAME.

It is possible to store additional data in the DNS that asserts X=Y for some
values of X, Y, and equals, and we could, theoretically, mint records that
had appropriately scoped forward knowledge about other equivalent domains.
Where apparent administrative domains are crossed, it may take additional
work to check that all parties concur.  It gets ugly fast, but it may be
better than the alternate of brute-force registration.

The real trouble, though, is getting applications to check for the existence
of such records.  The DNS is a known-item lookup protocol, and it basically
has to return the information that corresponds to the question that was
asked.  It can return additional data, but if it does so, there is a fairly
serious risk that only the answer to the question asked will be stored and
forwarded to the consuming application.

The only way around that that I can see at the moment is to either declare
one record to be canonical (forcing applications to "correct" any names they
are currently using to the canonical name) or use an additional layer of
indirection so that all of the records that are the same point to some
meta-target.  That might work--it's the same basic use of pointers that's
already present in CNAME, but it requires a pointer from all the "same"
domain names to some target that's not in the set.  The structure of that
record might be the same as the normal targets, using something like prefix
addressing to signal its use; it might also have a different structure.

But the problem remains daunting.  Even if DNSEXT creates the perfect record
for sameness, we still have to get apps to check it--and that suggests to me
designing the system for that goal should be a primary consideration in the
design space.