Subject: some thoughts on name prefixes and new types

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 17:06:20 -0400

One of the most sacred tenets of DNS is that a query has three 
degrees of freedom - the qname, the qclass, and the qtype.  One way 
to look at this is to melt all three into one field and call this the 
address of the desired information.

In this perspective, using a new type code is functionally equivalent 
to requiring a prefix to the object name.  (Where the object name 
refers to the name of what the application seeks data about, the 
qname remains the prefix.object name.)  The difference between 
approaches relying on name prefixes and type codes lays in the 
mechanics of the system, by that I mean DNS and the surrounding 
software (shims).

My hypothesis is that if adding new type codes is made the path of 
least resistance (including bureaucratically), then there is no need 
for name prefix approaches and hence no need for non-terminal wild 
cards.  Breaking this down:

  1) Getting a new and stable type code allotment ("leased" or "tenured") in
     the early stages of software development is a must.

  2) Shim software is always type agnostic until the last moment of the code
     path.

  3) DNS software is type agnostic except for the DNS special types, e.g., NS
     and others.

  4) Fixing the terminology about "object names" - the "name" in the SRV record
     definition is not the same as the qname when a lookup is done.

  5) Patience with the limited abilities of the record synthesis capability
     (known as wildcards), recalling that the mission of DNS is for lookups
     and not a directory or search mechanism.

I think that #1 may be the only item in the list that needs original energy
to be expended.  By that I mean I think the fundamental definition of the
how IANA is supposed to run the DNS type code registry needs to be overhauled.
(Not the fault of IANA, not the fault of the editors of RFC 2929, this is
a statement that we have learned lessons in the last 4+ years.

Items 2-5 are statements of what should already be true.  I concede 
that they may not be, that is why I referred to "original" energy in 
the previous paragraph.

Item 1

After I sent a message that concluded from the lack of new non-DNSEXT 
type codes since RFC 2929 that the bureaucracy was the broken 
component, I realized it was possible that there had been no requests 
for new numbers.  (I.e., going 0-for-0 is not an indication of a 
problem.)  A post from <[email-masked]> says he was denied 
on the basis of not having an RFC.  That's one instance, true.  But 
it means that we are at least 0-for-1.  Okay, still not a crime wave.

If I were to begin an effort now and needed to put something in DNS, 
I would need access to a type code number that would be permanent. 
We are all aware of how code "goes operational" without anyone 
noticing - it's happened to all of us, so we shouldn't expect that it 
won't happen to the next generation of developers.

I think that we need to lower the barrier to getting a number.  This 
may leak numbers, so we also need to have a recall mechanism.  This 
will work against careful planning, so I think we need to also let go 
of the idea that we should be allocating numbers in a nice orderly 
sequence.  (Yeah, the NSEC record will suffer.)

Item 2

Shim software has to be encouraged to be type-agnostic up until the 
shim is providing some application-data specific service.  Especially 
if we expect to lease type codes to developers during development - 
kind of a rent-to-own program.  (You own it when you have a referred 
document describing the type.)  As long as the shim software is 
agnostic, it won't be in the way of changing definitions of type 
codes.

Item 3

DNS has to peek into the RDATA of some types, but for other types 
there is no need.  SOA, NS, address, are needed for lookups, CNAME 
and DNAME for processing lookups, and security records are needed 
too.  MX isn't - as well as a bunch of other now defunct types. 
(Unless MX requires additional processing - adding the A records, for 
instance.)  There is no reason that these have to be dumped in a XFR 
file in anything other than ugly hex notation.  See a note later 
about viewing the hex as pretty-print.

Item 4

Applications can think of entities as objects.  Putting my SSH 
information for host singsing.prison.ny at 
"_ssh._tcp.singsing.prison.ny, qtype=TXT" or at "singsing.prison.ny, 
qtype=SSHDATA" is the same (functionally) to the application.  I 
forget exactly what my point here is, I guess it is that the clinging 
to prefixes as a solution is a red herring.  And I think that an 
update to the SRV definition document ought to fix the terminology 
bug.

Item 5

One of the most forgotten but important tenets of my DNS religion is 
that the DNS is a meager beast and it needs to remain so.  DNS is a 
lookup - you give it a query and it gives you the answer - and not 
much more.  With the exception of some acid-trip ideas like CNAME, 
DNAME, and wild cards, it's a strictly what you put in is what you 
get out system.

DNS is also the epicenter of the upper layers of the Internet.  Using 
the old OSI reference model, layers 5-7 all need the DNS.  It's even 
seeping downward, into things like VOIP and secure routing.  Cutting 
to the chase, the simpler the DNS is, the simpler it's code is, and 
the more likely it won't suffer software bugs.  Let's make it so that 
only bad disks, power outages, etc., are the reason servers go off 
line.

Given it's simplicity and the need to make is as robust as possible, 
there is a need to build up management tools around it to make 
administration possible.  The important thing to keep in mind is that 
these tools can be layered upon lowest common aspects - like hex 
dumps of records.

When the A6 was designated an experimental record, "knocked down" 
from standards track, one of the concerns was that this meant DNS 
wasn't as agile for network renumbering.  Someone pointed out that it 
would be trivial to write a PERL-like script to substitute the old 
network prefix with the new in all of the AAAA records, or to submit 
a series of dynamic updates to change them.  Moral of the story is - 
move the management of the network up out of the DNS.

CNAME, DNAME, and wildcards are three overly complicated yet 
underpowered features that have crept into the DNS.  Okay, I'm being 
harsh on CNAME, but I think the three give a taste of a vastly more 
functional system and deliver on a part of the promise.  The "holes" 
they don't fill trip up many folks, so much so that I wouldn't 
recommend the use of them in general.

The five items may not be as simple as I have described, maybe there 
is a reason that name prefixes with generic data types will remain a 
desirable goal.  If that happens, I think it's an accident of history 
and the times we live in and not something in the fundamental design 
and architecture of a name lookup system.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>