[dnsext] Label space comparison (analysis)

[Brian Dickson <[e-mail]>]

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
/home.)
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
filesystems.
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/,
var/log/)
(This is what I previously tried to describe in the DNS world as
"exceptions".)

Benefits:
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
incompatibilities.
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
namespaces.
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
only.)

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.)

Brian