[dnsext] Label space comparison (analysis)

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 02 October 2010 03:05 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 348B83A6CC4; Fri, 1 Oct 2010 20:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.02
X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=1.578, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id R0ljX-oknxC4; Fri, 1 Oct 2010 20:05:15 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6D823A6CBA; Fri, 1 Oct 2010 20:05:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1P1sKO-0003DX-7C for namedroppers-data0@psg.com; Sat, 02 Oct 2010 03:00:00 +0000
Received: from mail-fx0-f52.google.com ([]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <brian.peter.dickson@gmail.com>) id 1P1sKJ-0003DB-A9 for namedroppers@ops.ietf.org; Sat, 02 Oct 2010 02:59:55 +0000
Received: by fxm17 with SMTP id 17so3320951fxm.11 for <namedroppers@ops.ietf.org>; Fri, 01 Oct 2010 19:59:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=GUAfGVgfPfqGVlrcbzxl4NVdN6uAoxTLIiOrd7y0EFM=; b=xSTvsVu5d4+PbARP15HHXIChhy24ggYAvrSZ/0v44qG//RBOYActAAYqt/6jLhFk9E xh7wO9ygNHkWrBxOH/CjOSYL6uyBX+FChP76nXtV07WV2Ka5unlOjLIjLQqVl4iY3V5f DPHCgJ6jUYIcNuImQ5AkPbrZ6PyL6cCF4t/iI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iYPL1N2IT0fNeebetvYgkASXr/48Y6gtYdO/Ue68B12wT1igolOwt8qD032A1dN53Z 2LftZhov2HgG/Gja+Fj0omhOXhkEmjolek0cvUdNQ31MLcrR/J9Mc5GBtmPNtIj+cius +5+mD36tmOOuV6nFm5HMgDxfqyIu4edOmYekw=
MIME-Version: 1.0
Received: by with SMTP id x6mr6104278far.85.1285988393869; Fri, 01 Oct 2010 19:59:53 -0700 (PDT)
Received: by with HTTP; Fri, 1 Oct 2010 19:59:53 -0700 (PDT)
Date: Fri, 1 Oct 2010 23:59:53 -0300
Message-ID: <AANLkTimNimGHnQinPZ7GG3YKs6LOY-6uqsFBiBY8vJRy@mail.gmail.com>
Subject: [dnsext] Label space comparison (analysis)
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: namedroppers@ops.ietf.org
Content-Type: multipart/alternative; boundary=0016e68e871966e28504919981ec
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

The following is, I hope, useful in understanding some of the issues and
behaviors, which relate to aliasing.

If we consider the two namespaces DNS and *nix file naming, there are
interesting analogies between them. (It's where I got some of my ideas...)

DNS labels correspond to either directories (non-leaf labels) or files.
DNS allows the same label to both be a non-leaf and have data, while *nix
does not.

A DNS zone contains objects whose owner names are subordinate to the zone
owner name.
In that respect, owner names of objects in the zone can be considered
*relative* to the zone owner name.

A *nix filesystem has a hierarchy of directories. Those path names are all
*relative* to the filesystem root.

The main point is: there is a direct correspondence, at the path/label level
at least, between *nix filesystems and DNS zones.

The absolute file path in a *nix filesystem only exists in the context of
the filesystem being mounted.
The first filesystem mounted must be the "root" of the namespace, "/".
Thereafter, the "mount point" must already exist in the namespace, normally
as a plain directory.
Thus, the user's home directory filesystem, containing directories user1,
user2, etc., could be mounted on the mount point /usr/home (or /Users, or
The choice of where to mount it gives it its name, and is orthogonal to the
filesystems' contents (which use relative naming).

The absolute DNS names are similarly "built" by zone delegations. The
delegation establishes the place in the name hierarchy where the zone sits,
and the zone owner plus the zone-relative name becomes the FQDN.
(This is from the comparative standpoint; I realize traditionally the owner
name of anything in DNS is an FQDN, and is so particularly "on the wire".)

A CNAME is very much like a symlink (anchored or absolute) to a file (i.e. a
leaf node).
A DNAME is very much like a symlink (anchored or absolute) to a directory
(i.e. impacts the path and anything below it.)

The comparison gets interesting when one considers some of the possibilities
that emerge from the *nix use cases which exist or are supported, and seeing
how those might be translated into DNS equivalents.

For example, the same filesystem can be mounted in more than one location.
One could simultaneously mount the user directory partition on /Users *and*
on /home.
The same data is accessed, including file and directory creation and
attribute modification, regardless of which of several paths is used.

Another example supposes the use of lots of filesystems; for this, the .iso
file/filesystem is often used.
Small "stock" packages related to specific use, such as are needed on an FTP
server (i.e. bin/ etc/ man/ pub/ var/), can be put in such small
Then, the same "stock" filesystem can be mounted under *each* user's home
directory: (/Users/user1/stock, /Users/user2/stock, etc.)
This permits the use of "chroot" "jail" (qv): chroot $HOME.
By having a common filesystem used and re-used, management of many
directories is nearly trivial.
And, by then mounting on a per user basis, another (non-reused) filesystem
*below* the stock filesystem, per-user elements can be maintained (pub/,
(This is what I previously tried to describe in the DNS world as

This hierarchy of filesystems needs only be set up once.
There is no ongoing maintenance of the relationship or special utilities or
tasks that are needed.
After the set-up is done, everything maintenance-wise can be done within the
filesystem space, i.e. plain directories and files.
And most importantly, maintaining, duplicating, backing up, and restoring,
is all done without needing special tools.
A simple "cp -R" (for recursive copy) is sufficient for most tasks.
Filesystems that are mounted multiply don't even need to know that fact, or
receive special treatment.
This simply saves space and effort.

DNS comparisions:
Anything that adds hard links *within* a zone, introduces AXFR/IXFR
Anything that adds non-hard links which behave "kind of" like hard links,
opens the inconsistency can of worms.
(Needing to fsck your zone is bad news.)
Delegations are similar to mount points.
Aside from managing the set-up, re-used zone files with relative naming can
be a very attractive way to manage scaling of aliases.
The main issue is DNSSEC; however, that is good, since it means non-DNSSEC
backwards compatibility is assured.

The named.conf file (or nsd.conf file, or other similar conf file), and the
fstab, are both places that need to be set up for their respective
They are also not the places where frequent changes get made; those tend to
be the zone files or filesystems themselves.
Separating the maintenance of those, and adding provisioning tools, is
presumed and recommended. (E.g. zone files with $ORIGIN @ and relative names

However, with that assumption, it becomes a matter of documenting those
tools, and the conventions used.

(I have an idea on the DNSSEC issue this creates or relies upon, and I'll
write that up as an ID.)