Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

From: Dan Massey <[email-masked]>
Date: Tue, 3 Apr 2001 12:54:14 -0400

On Friday, March 30, 2001 at 12:35PM, Ted Lindgreen wrote:
| 
| But, perhaps you refer to registry testbeds?  I know of two
| implementations: one at CAIRN and one over here at NLnet Labs.
| 
| The former uses the KEY+parentalSIG @child scheme. From private
| communication during the last IETF (50th) with the
| authors/zoneadministrators I know that most, of not all, of their
| test child zones are currently BAD.  They told me that they consider
| their setup as very difficult, if not impossible, to maintain, and
| that they are considering to adopt the parental-SIG@parent scheme.
| 

First, I'd like to follow up on the above comment.  In CAIRN, we have 
found that the SIG at child approach makes changing parent keys 
operationally difficult and we are testing the NLnet Labs approach.  
Currently we have some people working out the operation guidelines
and revising our key registration and rollover procedures appropriately.  
The switch should be complete soon.  

With respect to the latest sig@parent draft, I think this a good idea
but I have some questions/comments.

Section 2.1 describes the TTL at the parent but it does not specify 
anything about the lifetime of the SIG at the parent.  Note that an
attacker can continue replaying an expired or compromised key until the
parent's SIG expires. You want to avoid scenarios where the child plans 
to change keys once a month, but the parent creates SIGs with a lifetime 
of one year.  Perhaps you need something like the following: 

The parent and child should agree upon an expiration date for the child's 
key.  Any SIGs generated by the parent must not exceed this expiration date. 

In CAIRN, our current plan is that the child will send a self-signed key 
and the expiration date on that (self-signed) SIG is taken as the key's 
expiration date.  

Section 4 describes a scheduled key rollover.  Should there be a transition
period where both keys are valid?  The old cairn.net plan had a short 
transition period where both the old and new key were active. After the 
transition, the zone moved to only the new key.  The current draft seems
to disallow this.  

Section 8 seems to push a lot of complexity into the resolver.  To lookup
the non-zone (ipsec/ssh/whatever) key for host bar.foo.com, the resolver
just requests the keyset for bar.foo.com, verifies the set signed by the 
foo.com zone key, and returns the result.  But to lookup a non-zone key 
for foo.com, the resolver requests the keyset for foo.com and gets only the
zone keys.  At this point, the resolver must be smart enough to know that
the requestor wants something besides zone keys and the resovler must be 
smart enough to send a query for the keyset of f.i.keys.foo.com.  

Shouldn't the query just say keyset for foo.com, not this particular type of 
KEY record?  Will this work for recursive queries?  If the foo.com zone 
chooses a name other f.i.keys.foo.com, how will the resolver know what to
ask for?  

Dan

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Miek Gieben <[email-masked]>
Date: Thu, 5 Apr 2001 15:49:08 +0200

> and the expiration date on that (self-signed) SIG is taken as the key's 
we've added:

2.2. SIG expiration considerations
   The expiration lifetime of the parental SIG over the 
child's zone KEY MUST be kept as short as possible. A good
value is one day. If there is a child KEY compromise, the 
SIGs for that zone are only valid for as long as the
parental SIG is valid. The selfsigned zone KEY stored in the
child's zone can have a much longer expiration lifetime.
The SIG at the child does not serve any purpose, a lifetime
measured in years is not uncommon.

-----------
I don't (yet) know if it matters if a child has a shorter
lifetime on the sig than the parent.

> transition, the zone moved to only the new key.  The current draft seems
We are not sure how or why you come to this conclusion from section
4. The idea was, and still is, to have a short  transition period
where both the old and new key are active.
The actions are:
   Child               Parent              Comments
   add new key                             Old key is still valid.
                       get, check, and
                         sign new set.     Both old and new key are valid.
   use new key and
     remove old key.
                       get, check, and
                         sign new set.     Only the new key is valid.

Perhaps confusing is that from the parent point of view, both
actions look (and are) identical. This is done on purpose to help
automating the parent's actions.

> foo.com zone key, and returns the result.  But to lookup a non-zone key 

Not sure whether this is really true.

In this example, if I were to look (without any knowledge) for an
ipsec/ssh/whatever key for the host "bar.foo.com" I'd look for a
key-set with the name "bar.foo.com" and not for the key-set
"foo.com" (which contains the zone-key for the domain where
"bar.foo.com" resides).

With proper knowledge about what I want from "bar.foo.com"
(ipsec/ssh/whatever) I would very likely also know the name
of the key.

For host with an A RR that points to the zone-name (instead of
a hostname under the zone-name) and without any knowledge, this
clash could happen, but then two unlikely things are happening
(a system administrator putting his "ipsec/ssh" host at the
top of his zone and a user whois aware of ipsec/ssh but unaware
of where to look for the ipsec/ssh key-RR).

So, we don't think this is a resolver problem, its a user problem,
and should not by adding complexity to the resolver.

Regards,
Ted & Miek

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Apr 2001 20:17:14 -0700

> of where to look for the ipsec/ssh key-RR).

There's nothing wrong with putting an IPSEC KEY record at the top
of a zone, along with the zone keys.  That's why the keys have flags
and protocol fields in them, to differentiate the various sorts that
a domain name or host might have.

The parent that signs the KEY records at a zone top should be prepared
to sign any number of KEY records in the RRset, with any flags desired
by the zone owner.  The signature is defined to be on the entire
RRset, there is no way for the parent to "just sign the zone key".

My zone, toad.com, will one day have both a zone key and an IPSEC key.
That RRset will be signed by the parent zone, assuming it isn't VeriSign.
(VeriSign will probably try to charge big bucks for signing your zone,
since they currently charge big bucks for signing your SSL key, and
signed DNS keys could easily obsolete SSL certificates.  I think they 
bought NSI to be able to make money either way.)

Many SLDs have a web server at the SLD (e.g. slashdot.org as well
as www.slashdot.org).  If it supports IPSEC, its key will be there;
if it supports SSL, its key could be there in the DNS, etc.

There is no reason for TLD DNSSEC automation to refuse to sign RRsets
that contain keys like this.  And many reasons, generality and
non-discrimination being the most obvious, to sign whatever keys the
lower zone wants to put at its top label.  It does own its zone, and
should be able to control its contents...

	John Gilmore

PS: The last few releases of the FreeS/WAN software (www.freeswan.org)
contain support for fetching keys out of the DNS, and the current
snapshot contains prototype code for attempting opportunistic
encryption using such keys.  (Opportunistic encryptors see if an IPSEC
key is published for any destination IP address, and if so, attempt to
negotiate a tunnel before sending any packets to it.)

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Apr 2001 05:40:31 -0700

in general, we discourage storing non-dns data in the dns.

also, it would be inadvisable to equate dns trust with trust for other
things, such as sessions with hosts/services you happened to find through
the dns.

but i think we discussed all these things before.

randy

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 06 Apr 2001 15:04:16 +0200

Hi Miek, Ted, Dan and others.

 * 2.2. SIG expiration considerations
 *    The expiration lifetime of the parental SIG over the 
 * child's zone KEY MUST be kept as short as possible. A good
 * value is one day. 

Detail: Since this not only applies to TLDs, where the terminology may
be a little stronger, I think above line should read be 'SHOULD be
kept as'.

 * If there is a child KEY compromise, the 
 * SIGs for that zone are only valid for as long as the
 * parental SIG is valid. The selfsigned zone KEY stored in the
 * child's zone can have a much longer expiration lifetime.
 * The SIG at the child does not serve any purpose, a lifetime
 * measured in years is not uncommon.
 * 
 * -----------
 * I don't (yet) know if it matters if a child has a shorter
 * lifetime on the sig than the parent.

Except for key compromise I can't see a reason for very short
signature validity. If there is a reason other than key compromise
then the child can put a short validity period on the SIGs in its zone
and sign it's zone more often. 

The validity period of a parental SIG is bound to a minimum set by
operational parameters. That is SLA material, hence the suggested
SHOULD above.

 * We are not sure how or why you come to this conclusion from section
 * 4. The idea was, and still is, to have a short  transition period
 * where both the old and new key are active.
 * The actions are:
 *    Child               Parent              Comments
 *    add new key                             Old key is still valid.
 *                        get, check, and
 *                          sign new set.     Both old and new key are valid.
 *    use new key and
 *      remove old key.
 *                        get, check, and
 *                          sign new set.     Only the new key is valid.
 * 
 * Perhaps confusing is that from the parent point of view, both
 * actions look (and are) identical. This is done on purpose to help
 * automating the parent's actions.

This confusion got me to the following thought. Since the idea is more
relevant to dnsops. I will post it there starting a new thread with
subject "One Interaction KEY exchange", please continue the discussion
on this part of the mail there.

Using the ideas from draft-ietf-dnsext-parent-stores-zone-keys-00.txt
this is an alternative to the key exchange mechanism described in
section 4 of that draft (which is the same as in
draft-ietf-dnsop-parent-sig-00.txt)

I think one can restrict the parent-child interaction even more. I get
to only 1 child parent interaction and an optional parent child
interaction. During the rollover the parent only needs to sign keys
once instead of twice.

Consider the following

1. To initiate a key rollover the child replaces the KEYold by the
KEYnew, signs KEYnew and the rest of the zone using the old and new KEY.

Then the child signals the parent to initiate the rollover.

2. The parent fetches the new key with the double signature and verifies
the SIG made with the old KEY with the old child KEY that the parent
is authoritative for. If the SIG is correct the Parent publishes the
new KEY with parental signature.

Since all child zone data is already signed with the new key that
data is also validated against the now signed KEYnew.

3. Once the child notices (or receives the optional signal by the parent)
that KEYnew has been signed the child can remove the SIG made with
KEYold. This is not a resigning exercise. A simple 'grep -v' will do.

To put this in a hopefully readable table:     
__________________________________________________
KEYold is  the child's old key RR
KEYnew is  the child's new key RR
SIGparent(RR) is the parental signature over RR
SIGkeyold(RR) is the child  signature over RR using keyold
SIGkeyold(RR) is the child  signature over RR using keynew
(At all times the child has signed the complete zone with the same keys 
as it signed the KEY record with.)
_______________________________________________________________________________
Time               Parent state              Child state         Comment
_______________________________________________________________________________

0                  KEYold                 KEYold            Before key rollover
                   SIGparent(KEYold)      SIGkeyold(KEYold)
            
1                  KEYold                 KEYnew             Shortly before 
                   SIGparent(KEYold)      SIGkeyold(KEYnew)  rollover
                                          SIGkeynew(KEYnew)  This works 
                                                             because parent 
                                                             is authoritative.

2a   SIGNAL to parent parent fetches KEYnew with the two sigs. It can verify
     SIGkeyold(KEYnew) against the data it holds itself. then replaces KEYold 
     by KEYnew and signs
  
2b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeyold(KEYnew)
                                           SIGkeynew(KEYnew)

3a  SIGNAL from parent to child. Child checks signature over KEYnew and 
    knows it can dispose of SIGkeyold(KEYnew)

3b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeynew(KEYnew)

_______________________________________________________________________________

In the mentioned draft the child always publishes one KEY RR in its
KEY RRset that is signed by the parent. This is not the case in this
model still all arguments in paragraph 7 apply.

Paragraph 7:

"  There are two reasons to have of the child's zone KEY not only at the
   parent but also in the child's own zonefile: 
	1. to facilitate a key rollover  
	2. to prevent local lookups for local information to suffer 
           from possible loss of access to its outside parent

   To cope with 1, secure aware resolvers MUST be aware that during a
   key-rollover there may be a conflict, and that in that case the
   parent always holds the active KEY set.  To cope with 2, the local
   resolver/caching forwarder should be pre-configured with the zone-KEY
   and thus looks at its own zone as were it a secure entry-point.  For
   both things to work, the zone-KEY set must be selfsigned in the child
   zonefile.
"

As far as I can tell this scheme is still immune for fake signals
since the Parent will only update if it finds another key at the child
then the key in it's own zone. Besides, a spoofed new keyset will not
validate since it is not signed with the verifiable SIG made with the
old key.

To cope with point 2 from par 7 the zone administrator should configure
the local resolvers and forwarding caches with the KEYnew somewhere
between step 1. and step 2a. in the table

I welcome your merciless responses :-)

--Olaf

-----------------------------------------------------
  Olaf M. Kolkman      |  RIPE NCC 
     -----------       |      ---------------	   
  RIPE NCC             |  Phone:   +31 20 535 4444
  Singel 258           |  Fax:     +31 20 535 4445
  1016 AB Amsterdam    |  http://www.ripe.net
  The Netherlands      |  [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Fri, 6 Apr 2001 19:38:29 +0200 (CEST)

> a domain name or host might have.

There is nothing wrong with putting IPSEC KEY's in a zone. Just not at the
apex. I rather want the zone to be responsible for the SIG(IPSEC KEY) than
the Parent zone, which is out of my control. Next to that, a ZONE key is
responsible for the whole zone, while IPSEC KEY's are associated with
individual hostnames or numbers. 

I agree with Randy's statement that "in general, we discourage storing
non-dns data in the dns.", but thats in my view unrelated to this matter.
The DNS is an excellent place to store IPSEC Keys. I strongly encourage
using DNS as a PKI (which DNSSEC is), when it comes to these DNS related
matters. If one uses DNSSEC to authenticate data which is responsible for
mapping hostnames to numbers, why not authenticate data which is
responsible for mapping hostkeys to numbers (or vice versa). If I think
about it a little further, I can see those as strongly related: DNSSEC for
authentication, IPSEC for encryption. Where is IPSEC without DNSSEC. And
what else is there to use for IPSEC key distribution ? Where is the
redundant, globally distributed and widely used X-509 PKI scheme for that
matter ?

Regards,

Roy Arends
Nominum.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 06 Apr 2001 16:13:27 -0400

> in general, we discourage storing non-dns data in the dns.

What is the definition of "DNS data", actually? In a strict definition, even
MX records and PTRs are "non-DNS data", i.e. they are not necessary to hold
the DNS infrastructure together. By such a strict definition, all of
DNSSEC is "non-DNS data". Does that mean it should be deprecated?

Or, is "DNS data" to be defined loosely as "whatever one can legally store
in the DNS"? In that case, the principle enunciated by Randy above is
totally circular.

A reasonable definition should lay somewhere between those two extremes. It
should delineate *why* it is acceptable to e.g. store in DNS data about how
an SMTP client should deliver a piece of email, whereas it is, _arguendo_,
*not* acceptable to store in DNS data about how an IPSec client should
encrypt and/or sign/verify packets.

I wish someone would clarify this, so that whenever a new record type is
shot down because it supposedly puts "non-DNS data" into the DNS, or a new
use for an existing record type -- like storing IPSec keys in DNS -- is shot
down for essentially the same reason, it doesn't look so much like a
capricious exercise of power.

- Kevin

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 06 Apr 2001 15:07:45 -0700

> What is the definition of "DNS data", actually?

Actually, it's probably a good idea to develop a concept consensus.

My definition is that the DNS is a lookup service similar to ARP. It just
happens to be distributed across a collection of interconnected partitions
in a hierarchical structure -- and there's a bunch of referral stuff to
make sure queries are sent to the right place -- but in the end devices
just issue targetted lookups for named resources and they expect an
unambiguous and consistent answer.

In that model, www.ehsco.com., mail.daimlerchrysler.com and ops.ietf.org
are all peer entries in a massive *FLAT* database (they happen to be
stored in separate partitions represented by a namespace but the global
database itself is flat).

Stuff that belongs in DNS is stuff that benefits from being used in a
non-authenticated, unambiguous, lightweight lookup service which is backed
by a global hierarchy of independent partitions. Stuff that doesn't belong
is anything that requires authentication, is ambiguous, can be served by a
standalone lookup, or consumes more valuable resources than it provides.

MX RRs work okay in that model. SRV RRs work okay (if they are picked up
and used to refer to richer or low-commodity-value services). Application
configuration does not belong (local only). User data does not belong
(requires authentication).

or was your question rhetorical

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Robert Elz <[email-masked]>
Date: Sat, 07 Apr 2001 13:33:24 +1000

Date:        Fri, 06 Apr 2001 16:13:27 -0400
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | What is the definition of "DNS data", actually?

When I saw Randy's message, I was going to send almost an identical
reply.

Personally, I have no problem with storing almost any kind of data in the
DNS, provided that it makes technical sense to put it there (that is, given
the limited available space for RDATA, so for example, storing images in the
DNS wouldn't be rational) and provided that the DNS is the sane mechanism
for the data and the way it is to be retrieved (so anything that you want
to be able to find based upon an imprecise query, or a query that isn't
easily mapped into a domain name, should go someplace else).  Also the
data needs to be of unrestricted access (DNS data is available to the
universe, despite the misguided efforts of some to provide implementation
defined access restrictions).

But where it makes sense to use a domain name to fetch a small amount of
public data, then I don't mind defining an RR code for the thing.   About
all that is left is to decide whether the definition of the object is precise
enough that we know what is really being fetched and how to use it, and
whether it is realistically going to be used enough to make it worth the
bother of doing the assignment (there have been cases proposed where I
though the thing being defined so useless that it just wasn't worth the
effort).

kre

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 06 Apr 2001 21:40:41 -0400

> standalone lookup, or consumes more valuable resources than it provides.

This is possibly too narrow a definition. With DNSSEC, authentication of
queries is possible and perhaps even desirable. As for "ambiguous", what
exactly do you mean by that term? It is perfectly normal and acceptable for
different clients to get different answers to the same DNS question
(depending on their source address and/or which DNS server they ask, when
they ask it, etc.). Does that constitute "ambiguity"? As for "consumes more
valuable resources than it provides", we'll wait to see how efficient DNSSEC
proves to be :-)

> or was your question rhetorical

Would I ask a rhetorical question? :-)

No, actually, it wasn't rhetorical. I'm looking for a *principled* standard
by which to judge what kinds of data should go into DNS and what kinds of
data shouldn't. Seems to me the determinations have been pretty much
_ad_hoc_ thusfar.

I should perhaps point out that I have no vested interest here. I have no
proposals in mind for new resource-record types, or new uses for existing
types, that could reasonably be considered "non-DNS data". I just don't like
arbitrariness or even the appearance of same.

Question: wasn't it the whole *point* of DNSSEC to offer a secure key
repository to applications? It's hard to believe that so much time and effort
would be expended just to secure DNS *itself*...

- Kevin

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 06 Apr 2001 23:12:09 -0700

>> Stuff that doesn't belong is anything that requires authentication,
>> is ambiguous, can be served by a standalone lookup, or consumes more
>> valuable resources than it provides.

> As for "ambiguous", what exactly do you mean by that term?

I mean multiple things but essentially I mean that DNS shouldn't be viewed
as a cheap distributed database (eg, "lets make an Internet filesystem of
MIME objects, stored in DNS!").

The usage of a specific RR should be unambiguous. The usage of A RRs is
pretty much unambiguous. The usage of WKS tends to be somewhat ambiguous
due to system-specific implementation issues (some have used it as a
supplement for /etc/services). The multiple usages of TXT makes it
extremely ambiguous.

The datatypes should also be unambiguous. Free text is ambiguous;
typed-data (like IPv4 Addresses) is unambiguous. Some free text usages are
okay as long as the usage is unambiguous ("display only" as a rule is
unambiguous).

There should never be a general purpose "8-bit-binary" RR or data-type
defined as that would be ambiguous, which is counter purpose to a lookup
protocol. The EDNS kitchen-sink datatype is a good example.

In essence, the data returned from a lookup should be used for automated
processes like fetching an IP address or the list of mail servers for a
host, and not for reading the of MP3 song titles and artists that are
stored in a specified path on a specified host (no this is not a proposal
for the My-MP3-Files RR).

> It is perfectly normal and acceptable for different clients to get
> different answers to the same DNS question (depending on their source
> address and/or which DNS server they ask, when they ask it, etc.).
> Does that constitute "ambiguity"?

Not by my definition. But since you brought it up, clients should expect
to get the same answer set from the same server, within reason.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 07 Apr 2001 19:03:43 -0700

Robert Elz wrote:

> Personally, I have no problem with storing almost any kind of data in
> the DNS

I'm sure you didn't mean the example I'm about to give but I am taking the
bait anyway. :)

The problem with being too liberal wrt DNS data is that it dillutes the
effectiveness of the lookup service.

If for example under the "anything goes" principle somebody defines the
dreaded My-MP3-Files RR which returns records for every MP3 cataloged on a
specific server, it is possible for thousands of RRs to be returned.
However, those answers will also get returned whenever the associated
domain name is queried with a qtype=*

Ergo, everytime sendmail tries to enumerate the RRs for a destination
domain name, it would get overloaded with My-MP3-Files RRs, which would
either dillute or completely destroy the usability of DNS for simple
lookup functions.

That's maybe an exaggeration, but maybe it isn't, and really it will all
depend on how liberal the line is drawn. I advocate hard-liner positioning
in this matter. Heck it might even be worth a policy thing, no RRs get
approved without passing through DNSEXT first.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 07 Apr 2001 08:37:26 +0200

--On 01-04-07 13.33 +1000 Robert Elz <[email-masked]> wrote:

> DNS, provided that it makes technical sense to put it there (that is,
> given the limited available space for RDATA, so for example, storing
> images in the DNS wouldn't be rational) and provided that the DNS is the
> sane mechanism for the data and the way it is to be retrieved (so
> anything that you want to be able to find based upon an imprecise query,
> or a query that isn't easily mapped into a domain name, should go
> someplace else).  Also the data needs to be of unrestricted access (DNS
> data is available to the universe, despite the misguided efforts of some
> to provide implementation defined access restrictions).
>
> all that is left is to decide whether the definition of the object is
> precise enough that we know what is really being fetched and how to use
> it, and whether it is realistically going to be used enough to make it
> worth the bother of doing the assignment (there have been cases proposed
> where I though the thing being defined so useless that it just wasn't
> worth the effort).

I agree completely.

I just want to let you DNS people know that I try to tell the wg's in my 
(Applications) area that it is ok to store references to data in the DNS if 
the references are to be looked up given the unique name of the owner. 
Searches is a nono, and storing actual data is also a nono.

That kre above accepts some small amount of data which is tied to the zone 
in DNS is something which I also think is ok, but I don't tell people in 
the beginning of the "negotiation" :-)

     paf

---

From: Robert Elz <[email-masked]>
Date: Sun, 08 Apr 2001 22:54:36 +1000

Date:        Sat, 07 Apr 2001 19:03:43 -0700
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm sure you didn't mean the example I'm about to give but I am taking the
  | bait anyway. :)

It is actually not a bad example to analyse.

  | The problem with being too liberal wrt DNS data is that it dillutes the
  | effectiveness of the lookup service.

Not necessarily.

  | If for example under the "anything goes" principle somebody defines the
  | dreaded My-MP3-Files RR which returns records for every MP3 cataloged on a
  | specific server, it is possible for thousands of RRs to be returned.

Yes, and for that reason (the RRset would not be expected to fit in any
rational packet), that wouldn't be a sane thing to store, technically.

  | However, those answers will also get returned whenever the associated
  | domain name is queried with a qtype=*

Yes, though qtype=* (ANY) as a reason for dropping something doesn't
concern me greatly - if there was no better reason not to do it, I'd
hesitate to refuse on those grounds alone.

  | Ergo, everytime sendmail tries to enumerate the RRs for a destination
  | domain name, it would get overloaded with My-MP3-Files RRs, which would
  | either dillute or completely destroy the usability of DNS for simple
  | lookup functions.

I won't debate whether the way sendmail chooses its lookups is sane or not,
it certainly isn't required that it operate that way.   But anyone who chose
to load up thousands of RR's at the kind of domain label that would be used
for other purposes (like mail) would deserve to have all kinds of things
start failing.   Inventing a new name for such things (say mp3.my.dom.ain)
is not difficult to achieve (assuming it was rational to use the DNS for
a purpose like this - which it isn't).

  | That's maybe an exaggeration, but maybe it isn't, and really it will all
  | depend on how liberal the line is drawn. I advocate hard-liner positioning
  | in this matter. Heck it might even be worth a policy thing, no RRs get
  | approved without passing through DNSEXT first.

I think we already have that policy - the philosphical question being asked
is when and why should new RR records get approved by DNSEXT, and when should
they be rejected.

Eg: if you were to take music (mp3s or anything else), it (just might possibly
be reasonable to encode the aritsi/title (or just title) (of is music
has anything equivalent to an ISBN, perhaps that identifier) as a domain name,
and then define a few RR's to allow a server for that particular music to be
located (then again, perhaps SRV is already that).

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 08 Apr 2001 12:48:03 -0700

> | If for example under the "anything goes" principle somebody defines
> | the dreaded My-MP3-Files RR which returns records for every MP3
> | cataloged on a specific server, it is possible for thousands of RRs
> | to be returned.
> 

Of all the reasons to limit, message size probably isn't one of them.
There are lots of valid reasons to have very large answer sets. I think it
is better to define filters which are based on content/context.

> anyone who chose to load up thousands of RR's at the kind of domain
> label that would be used for other purposes (like mail) would deserve
> to have all kinds of things start failing. Inventing a new name for
> such things (say mp3.my.dom.ain) is not difficult to achieve
> (assuming it was rational to use the DNS for a purpose like this -
> which it isn't).

But then somebody publishes their email address (user@mp3...) and mail is
broken again. Or a user puts their MP3 collection on their rent-a-domain
redirector box, the same box/domain that they use for mail, the same box
they use for web pages, etc.

The use of qtype=* is probably going to become more common over time, what
with there being A, A6 and AAAA RRs in the field now. Since DNS doesn't
provide a way to enumerate the RRs that it wants, it has to use qtype=* if
it will pick and choose.

The key point in my argument is that data in the DNS should only be used
for lookups. It should provide a critical piece of information which is
necessary for some other application process to complete, and nothing
more. It should not provide any application data whatsoever.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Apr 2001 19:55:48 -0400

>in general, we discourage storing non-dns data in the dns.

"We?"

I disagee that we should be trying to limit the data held in DNS.  I
believe that volume is not an issue and should not be artificially limited.

OTOH, I feel that we should limit the impact on DNS by the data held in
DNS.  (E.g., the A6 record impacts the DNS more so than the A record.  Not
that this makes the A6 evil, but it is less desirable than an A.)

...the ensuing arguement is off the topic at hand though...

>but i think we discussed all these things before.

If we did, we did so with less operational input.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Apr 2001 20:05:42 -0400

>measured in years is not uncommon.

"MUST be kept as short as possible" is poorly worded.  The use of the
subjective "as possible" makes the use of MUST incorrect, a SHOULD would be
more appropriate.

I don't know if a hard requirement can be placed here.  Ultimately, it's up
to the registry to decide how often they will resign the keys.
Technically, it is good to limit the lifetime of a SIG, but this incurs a
staffing cost.

(Ya' know, this discussion borders on dnsop quite frequently.)

The meanings of the SIG by the parent and the SIG by the child are almost
unrelated.  The parent says "this key is good" and the child says "I have
the private key for this."  Because of this, I can't justify tying the two
SIG durations in a specification.

>where both the old and new key are active.

One of the smokdering debates is why there is the need for roll over.  On
the one hand, old SIGs might still be fine if the old key is around.  On
the other hand, isn't the fact that a new key is available mean you should
forget the old data?

Now, the desire to use the old key to sign the new key set is the first
requirement I have heard that justifies the continued use of the old key
once the new key is present.

Dilbert is an optimist.

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 09 Apr 2001 17:07:39 +0200

Edward Lewis <[email-masked]> responding to Miek:

 * >We are not sure how or why you come to this conclusion from section
 * >4. The idea was, and still is, to have a short  transition period
 * >where both the old and new key are active.
 * 
 * One of the smokdering debates is why there is the need for roll over.  On
 * the one hand, old SIGs might still be fine if the old key is around.  On
 * the other hand, isn't the fact that a new key is available mean you should
 * forget the old data?
 * 
 * Now, the desire to use the old key to sign the new key set is the first
 * requirement I have heard that justifies the continued use of the old key
 * once the new key is present.
 * 

FYI:

The scheme I posted on Friday drops the requirement to have the old
KEY around. Actually it requires the old key NOT to be around. (If you
would keep the key in the keyset, and the parent would not keep state,
you might be able to trigger keyrollovers by spoofed notifies.)

"Isn't the fact that a new key is available mean you should forget the
old data?" seems to be an important question to answer...

--Olaf

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Apr 2001 10:51:22 -0400

> is when and why should new RR records get approved by DNSEXT, and when should

Personally, I think defining DNS RRs should be encourgaged where it
makes sense. I.e, the DNS does the things it is designed for quite
well. New RRs that fit within the existing model should be encouraged.
Criteria could include:

- Would use of the new RR cause operational problems?

- Would it cause problems for existing implementations, or would
  existing resolvers/servers handle them just fine (i.e., don't forget
  about caching servers that could just cache the RR without
  undestanding its semantics)?

- Is the usage of the RR consistent with the basic service the DNS
  provides well?

  - E.g,. lookup based on a heirarchical name (the DNS name).

  - Small number of RRs at a given name, as opposed to tens or
    hundreds

  - Relatively infrequent updates to the data (i.e., non-realtime)

  - Can use reasonable TTLs (i.e., other than zero)

Surely there are more (does it duplicate existing RRs, is it specified
clearly enough for implementors, etc.), and enumerating/documenting
the issues that should be considered when evaluating a proposed RR
would be a useful exercise, especially for folks that are thinking
about whether they should define a new RR.

> more. It should not provide any application data whatsoever.

I think this distinction is too absolute. As long as the application
data can easily be put into the DNS without causing contortions, why
shouldn't that be allowed? And isn't the info in an MX record
"application data"?

Thomas

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 11 Apr 2001 09:59:15 -0700

> well. New RRs that fit within the existing model should be encouraged.

Agreed. The tricky part is defining what that is exactly.

>   undestanding its semantics)?

Does it provide unambiguous data.

>   - Can use reasonable TTLs (i.e., other than zero)

Agree

> about whether they should define a new RR.

Is it a lookup and not data. Does it provide information about Internet
resources and not local data (lookups that only have relevance within an
administrative domain should not be stored in the global DNS).

> > It should provide a critical piece of information which is
> > necessary for some other application process to complete, and
> > nothing more. It should not provide any application data whatsoever.
> 
> shouldn't that be allowed?

Because too many RRs will trigger UDP overflow which impacts the
performance of lookups. Way-too-many RRs will also trigger TCP overflow
whichi will prevent lookups from working at all.

This is my primary concern: the main function of the DNS is for lookups,
it should not be hampered or blocked with excessive RRs which are better
served by other processes.

> And isn't the info in an MX record "application data"?

Yes, but I'm not advocating its removal.

A lot of the filtering effort comes from trying to keep things like MX out
of DNS. Putting MX into the DNS in the first place could be considered a
mistake by my defintion. However, I certainly recognize the value and
stickiness of MX and also recognize that there was no other alternative at
the time, and so I certainly have no desire or goal of pulling it out of
DNS. But that doesn't mean new MX-like RRs should go into the DNS either.

---

From: Robert Elz <[email-masked]>
Date: Thu, 12 Apr 2001 16:54:59 +0700

Date:        Wed, 11 Apr 2001 09:59:15 -0700
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Agreed. The tricky part is defining what that is exactly.

It doesn't need to be defined, no-one is looking at creating an
automated RR registration service.  As long as we can make the
distinction when required, that will be fine.

  | Is it a lookup and not data.

I have no idea what that means.   If it is in the DNS, it is going to
be used in a lookup, or having it would certainly be a wast of time.
If it is going to be represented in the DNS, it is certainly going
to be data.   Hence, I would have thought everything in the DNS is
used in a lookup and is data...

  | Does it provide information about Internet
  | resources and not local data (lookups that only have relevance within an
  | administrative domain should not be stored in the global DNS).

I'm not sure I would go quite that far.  If the data is going to be
useful all over the place, and it is data that can be made publicly
available (isn't intended to be private) then I don't think it matters
in the slightest whether the majority of the uses will be local.

Certainly the vast majority of the A records are only used locally, are
you suggesting that they shouldn't be in the DNS but should be
someplace else instead?

  | Because too many RRs will trigger UDP overflow which impacts the
  | performance of lookups.

Only if there are large numbers of RRs for the same RR type (that
should certainly be discouraged) - or for used of ANY type lookups,
which I don't consider all that important.

  | Way-too-many RRs will also trigger TCP overflow
  | whichi will prevent lookups from working at all.

There's no way a FOO RR type can prevent my A lookups from working,
regardless of how many RRs are there.   Nor can 2 or 3 hundred other
RR types defined at the same node.

  | This is my primary concern: the main function of the DNS is for lookups,

The only function of the DNS was for lookups - before DynDNS, that (and the
odd zone transfer) were all it could do.   But you seem to have "lookups"
defined somewhere with a particular kind of data being returned, whereas
I can see no justification for that.

  | A lot of the filtering effort comes from trying to keep things like MX out
  | of DNS.

Then that is wasted effort, as that would not be a sane result.

  | Putting MX into the DNS in the first place could be considered a
  | mistake by my defintion.

It could be considered to be that way, but without any rational
justification.   If MX is on the "wrong side", then I don't think
there's any data in the DNS that would justify staying, certainly I
don't see A or PTR as being any different than MX.  Certainly not HINFO
or MB.   I guess you'd just be left with the RRs that build the tree
(NS and SOA), without which there would be no DNS at all.   But at that
stage, there wouldn't be a lot of use delegating domains.

  | However, I certainly recognize the value and
  | stickiness of MX and also recognize that there was no other alternative at
  | the time, and so I certainly have no desire or goal of pulling it out of
  | DNS. But that doesn't mean new MX-like RRs should go into the DNS either.

RRs like MX (eg; SRV) are just fine in the DNS - that's exactly the kind
of thing it ought be used for.   I wouldn't even look very closely at that
kind of RR (other than the definition of its data format - SRV certainly
had a bunch of that in its time).

The ones that are more problematic are stuff like the (proposed) apl RR,
which just doesn't seen to be able to drum up sufficient interest (and
hence most likely wouldn't really ever be used), and the (still? proposed)
kitchen sink rr, which overloaded an RR type so that people could add
random data without needing to get their own RR type.   This isn't to say
that those ones are automatically no good - just that those are the types
of requests that demand greater scrutiny, not anything which smells like MX.

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 12 Apr 2001 08:54:27 -0700

> used in a lookup and is data...

I consider "lookup" to be a piece of required data which is necessary for
a distributed (eg, Internet-wide) application process to complete.

I consider "data" to be (poorly termed) information which is not required
for the distributed portion of the application process to complete.

MX is a lookup for a remote domain's mail servers and is necessary for
SMTP delivery over the Internet to complete. MB is data which is not
required for the Internet portion of the process. Local mailertable RRs
would also not meet this requirement, but reusing MX for this is not
necessarily bad.

> Certainly the vast majority of the A records are only used locally,
> are you suggesting that they shouldn't be in the DNS but should be
> someplace else instead?

As a class of data, A RRs are necessary for distributed network processes
to complete. Something that provided MAC addresses would be local-only. RT
RRs are probably local-only.

> don't see A or PTR as being any different than MX.

[I may be wrong on MX, I'm trying to define the line too.]

My feeling is that MX is wrong when it is compared to SRV because SRV uses
protocol-specific labels which are not likely to cause overload. If SRV
were used with DNs without the service-specific labels (similar to the MX
method) then we could end up with dozens of service-specific RRs
associated with a DN, such that requests for qtype=* qname=oz.au. would be
overloaded.

> I guess you'd just be left with the RRs that build the tree (NS and
> SOA), without which there would be no DNS at all.

Well, that's certainly not my goal. :p

---

From: Randy Bush <[email-masked]>
Date: Sun, 15 Apr 2001 18:17:51 -0700

> I.e, the DNS does the things it is designed for quite well.

opinions on this seem to vary.  and the trend seems to be more
dissatisfaction.  responses are perceived to be slower, though
hardware is faster and bandwidth wider.  it would be helpful
to have actual data.

randy

---

From: John Gilmore <[email-masked]>
Date: Sun, 15 Apr 2001 20:50:09 -0700

> hardware is faster and bandwidth wider.

The DNS is really the only game in town for what it does.  Who else
has a locally published, globally accessible, hierarchical,
distributed, replicated, cached, high availability, dynamic database?
With hundreds of thousands of publishers and hundreds of millions of
hourly users?  With end-to-end cryptographic authentication coming soon?
Oracle?  Don't make me laugh.

The fact that this 1983 bear is still dancing under 2001's load is
quite admirable, even if a small sheen of sweat appears on her upper
lip occasionally.  The amazing thing is that the protocol and
implementation scaled right up through nine orders of magnitude with
minor tuning, despite bungled administrative policy that resulted in a
large fraction the nodes being hung off a single node of the tree
(.com).  The occasionally announced political initiatives to
"stabilize the DNS infrastructure" have all been hooey; the technical
infrastructure was and is solid, even in the hands of largely
incompetent self-serving bribeocrats.  Mostly the initiatives were to
get the infrastructure under somebody's political thumb, rather than
being managed by sane people exercising judgement.

If the DNS is slow, it can be sped up by implementation, without
protocol changes.  Find the pinch points, and replicate the servers
for those zones on a more globally equidistant basis from the queries.

If a speed problem is due to needing better retransmission algorithms
than UDP offers, let's resurrect a protocol for three-packet TCP for
short connections (similar to T/TCP) that automatically scales up to
an arbitrary number of packets and bytes if you don't terminate the
connection (as TCP does now).  This would let us gradually switch to
defaulting to TCP queries, even for short queries and answers.

As for what data belongs in the only global distributed database, I
say whatever data fits the query method.  Any information that ties
directly to domain names or IP addresses on the Internet is a
legitimate candidate to be there.  Crypto keys.  Physical locations.
Mail handlers.  Other service handlers.  Text.  Names.  Addresses for
lower or higher level protocols (X.25, Frame, IPv6, email, IPSEC,
Mobile IP, routing, whatever).

For data that doesn't tie to domain names or IP addresses, even it can
be accessed via the DNS, by delegating it a chunk of the label space.
You could put baseball scores there, as records under .baseball./ or
.baseball.org, giving them a record type or two if they needed one.
(This is how lookups by IP addresses were handily slid in, using
.in-addr.arpa and PTR.)  There is no reason to limit this capability
to just IP addresses; such sub-delegations produce almost zero load
on the pre-existing DNS, even if widely used, and have no effect on
publishers elsewhere in the hierarchy below the root, nor on queriers
who never ask for those records.

There is similarly no reason for the DNS to limit the number of
records of a given type, or the number of record types that could
exist at a given label.  There are efficiency issues if large numbers
of users are expected to make queries that resulted in large volumes
of data being served to them -- but those are design decisions best
made in the individual context of a DNS RR design and of the
application that uses it.  There should be no hard-and-fast rule that
says "no RRset will ever have more than 16 entries or consume more
than 64K bytes" or "No label will ever have more than 42 record types".

There is little technical reason for limiting sizes or the creation of
new types.  I for one am a bit tired of people deciding that
administrative control over the evolution of the technology should be
used to squelch applications that particular people in positions of
control don't happen to like.  We get far too much of this from the
music monopolies and from the anti-spammers already.  They are trying
to design-out the ability to copy information -- and the ability to
send the first communication in a protocol exchange.  Both of these
are basic foundations of how the Internet works.  We really don't need
this kind of arbitrary control imposed on what kinds or types of info
can go into the big global database in the sky.  ANY kind or type of
info should be able to be put into the DNS.  Indeed anything can today
be encoded into TXT records in labels delegated to the folks who wish
to publish it.  This capability should remain available, should never
be administratively outlawed, and applications that expect to see
broad use should be able to get new RRtypes, for higher efficiency or
convenience of widespread administration.

Programs dumb enough to make queries for "all records at label X" will
someday soon want to change to request only the records they really
want.  That was one of those penny-wise, pound-foolish optimizations
that only improves efficiency for a brief time.  If it turns out that
many applications would like to ask for more than one RRtype at once,
and kludges like special rules for MX or IPv6 QTYPEs keep
proliferating, then we should revise the protocol to clearly and
cleanly define a way to query for multiple RRtypes and unambiguously
interpret the answer.  (Today's protocol puts too much reliance on
minor differences of response, like NODATA versus NXDOMAIN versus
more-than-0-records-returned.  It doesn't cleanly scale to answering
more than one question, and has ended up more complicated than it
needs to be.)  If multiple-query is a real need, fixing it isn't
complicated, just a little tedious.

If today's arbitrary limits on the size of DNS labels, records,
sections, queries, or responses are pinching us a little, such that we
couldn't retrieve a megabyte or two of ".baseball.org" SCORE records
if we wanted to, then we should revise the protocol in minor ways to
allow these length fields to be expanded.  It would be better to do
this now rather than when serious applications are feeling the pinch,
since deployment always takes a few years.

I do think that a complete replacement for DNS should be researched,
designed, and prototyped.  It should use what we have learned about
building distributed databases over the last twenty years, and what we
have learned about how NOT to administer globally vital resources.
(Thus it should probably not be hierarchical, since that provides a
pinch-point where administrative control can -- and therefore
inevitably will -- be exerted.)  But that's a ten year plus project,
which should run in parallel with evolving the current DNS to support
whatever applications people can find for it.  If the research
produces something better, people will switch over to it naturally; if
not, the current DNS has to keep working.

	John Gilmore

---

From: [email-masked]
Date: Mon, 16 Apr 2001 15:46:36 +1000

> hardware is faster and bandwidth wider.  it would be helpful

	Given that DNS queries and answers are small compared to most other
	uses of the internet.  Increasing bandwidth has little effect compared
	with the effect of increasing bandwidth with other protocols.  The
	dominant factor in the rtt calculation is signal transmission speed
	not the time it takes to spit all the bits into the link.
	
	As everything else speeds up the DNS *seems* slower.

	Mark

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Apr 2001 22:35:15 -0700 (PDT)

> than UDP offers, 
I'm not even sure that we've got the best retransmission algorithm
possible with UDP. 

I do find it curious that the transport behavior of resolvers has never
been standardized. Some may take RTT into account in their
algorithms; others do not. I have observed some resolvers failing over
to secondary DNS servers at time intervals that would barely even permit 
a response from the primary to be returned. My suspicion is that better
behaving resolvers could cut down on query volume. Perhaps a "DNS resolver
implementation problem" draft is appropriate?

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Apr 2001 23:21:57 -0700 (PDT)

> defaulting to TCP queries...

Use of TCP would address congestion between the host and local DNS
server. However, it would *not* necessarily address overall congestion. 

Since hosts implement "stub" resolvers, local DNS servers act as
proxies. Thus you'd really have two TCP connections, one from the host to
the local DNS server, and another between the local DNS server and its
correspondent. Assuming the two connections operate independently without
coupling, self-clocking will not necessarily occur. For example, where the
bottleneck exists between the local DNS server and its correspondent, 
the overall conversation will not self-clock. This is because the host
will happily dispatch packets to the local DNS server oblivious of the
overall bottleneck, which it cannot see, since there is no e2e transport
connection. In this case the overall transport behavior will be influenced
by the size of the queue on the local DNS server and the details of the
implementation (e.g. whether backpressure is used, and if so, when). 

In the case of DNS, the effect is moderated by caching. The local DNS
server will thus typically have the answer and thus will not have to
originate its own query. Thus the typical query will only involve a single
connection.

---

From: Rob Austein <[email-masked]>
Date: Mon, 16 Apr 2001 04:10:46 -0400

Date: Sun, 15 Apr 2001 22:35:15 -0700 (PDT)
   From: Bernard Aboba <[email-masked]>

I have long suspected that something like TCP's variance-based
retransmission algorithm would help UDP-based applications like DNS.
Perhaps there are other algorithms better suited to this, but the
variance-based algorithm is easy to implement (core algorithm is seven
lines of code), conceptually straightforward (in retrospect :), and is
almost certainly a better retransmission algorithm than is likely to
occur to anybody who has not been immersed head down in a transport
protocol implementation for several years.

As far as I know nothing like this has never been tried with DNS.  I'd
be interested to hear otherwise.

Reference: Appendix A of Van Jacobson's and Mike Karels's 1988 SIGCOMM
paper "Congestion Avoidance and Control", which was still available from 
ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z last time I checked.

---

From: John Gilmore <[email-masked]>
Date: Sun, 15 Apr 2001 20:50:09 -0700

John Gilmore

---

From: Rob Austein <[email-masked]>
Date: Mon, 16 Apr 2001 04:10:46 -0400

---

From: [email-masked]
Date: Mon, 16 Apr 2001 15:46:36 +1000

Mark

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Apr 2001 23:21:57 -0700 (PDT)

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Apr 2001 22:35:15 -0700 (PDT)

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 16 Apr 2001 09:34:39 -0500

> Perhaps there are other algorithms better suited to this, ...

And the more you concentrate your wide-area DNS queries through a
small set of intermediaries, the more bang you can get out of better
server, address & retransmission decisions ... up to the point at
which you lose due to common points of failure.

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 16 Apr 2001 14:43:08 +0200

> hardware is faster and bandwidth wider.  it would be helpful

I have a suspicion that is a little more than vague that the root
cause to this problem is probably misconfiguration of the DNS, in
particular inconsistencies at zone cuts / delegation points and the
resulting lame delegations.

Since this is perhaps primarily a "people problem" at this point,
throwing more hardware or bandwidth at it isn't going to make it go
away.

As one of my friends say in one of his plays with words: what the
DNS needs the most is more CLUE records...

Regards,

- H=E5vard

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Apr 2001 15:30:44 -0000

John Gilmore writes:
> Programs dumb enough to make queries for "all records at label X"

Unfortunately, mail transfer agents have been forced to do that for
interoperability. Here's what happened:

   * RFC 821 prohibited ``nicknames or aliases'' in domain names in SMTP
     requests. RFC 1123 specifically prohibited DNS aliases: domain
     names with CNAME records. (Why? Because the IETF is incompetent.)

   * Sendmail's SMTP client checked for CNAME records by doing a *
     query. When it found a CNAME record, it replaced the alias with the
     contents of the CNAME record.

   * Many sites started relying on Sendmail's alias replacement. Users
     would type aliases and expect their mail to be delivered.

   * Meanwhile, when BIND found syntax errors in a zone, it wouldn't
     revert to the previous version of the zone, nor would it produce a
     consistent SERVFAIL answer. It replaced _negative answers_ with
     SERVFAIL. It didn't replace positive answers with SERVFAIL. (This
     was fixed recently.)

   * System administrators often made syntax errors in BIND zone files,
     and didn't realize that anything was wrong. There are still a huge
     number of domains for which CNAME requests produce SERVFAIL but *
     requests succeed.

   * New MTAs were forced to check for CNAME, because users relied on
     that behavior, but couldn't do it with CNAME queries, because that
     wouldn't interoperate with all those BIND sites. The only solution
     was to do * queries, just like Sendmail.

The prohibition on CNAME records was abruptly yanked in 821bis, without
regard for interoperability. I'm going to stop checking for CNAME
records sometime in the next few years. In the meantime, however, I'm
not going to accept any blame for my use of * queries in qmail.

---Dan

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Apr 2001 09:35:18 -0700 (PDT)

> retransmission algorithm would help UDP-based applications like DNS.

In practice, we see resolvers failing over to the secondary before an RTO
timer would have expired. Emission of dual packets often continues even
after the primary has not responded for quite a while. So in addition to
the RTT/RTO logic, we also need to think about failover/failback behavior. 

> be interested to hear otherwise.

I'm told that some implementations have incorporated RTT estimates, though
probably not in the same manner. Looking into this in a systematic way
would seem worthwhile (any grad students interested in a thesis topic?)
It would be likely to have a particularly big impact on the root servers.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 16 Apr 2001 12:13:43 -0700

John Gilmore wrote:

> hourly users?  With end-to-end cryptographic authentication coming
> soon? Oracle?  Don't make me laugh.

Let's look at this position up close for a moment.

In order for DNS to serve as a general-purpose database, it would need
several new features. For example:

 o DNS would need record-locking mechanisms so that a user could
   modify data without another user modifying the same record
   simultaneously. DNS as a lookup service for Internet resources
   does not need this capabilty. Please submit your draft on
   record-locking. :) By the way, you should also plan ahead for
   byte-range locking so that two users can modify different
   parts of the same "database record," since feature creep is
   hard to stop once it gets started.

 o Databases need user-specific ACLs, lookups do not. This also
   requires user-specific authentication which is verifiable and
   not subject to replay attacks. It also means implementing a
   key-exchange structure, and a management architecture that
   allows for adding/editing/deleting keys from the structure.
   The user auth part would actually be pretty easy to implement
   in the protocol if it weren't for the 512 byte limit and the
   datagram centric approach to lookup operations. Implementing
   a management architecture such that non-replay user-specific
   keys are verifiable in a datagram exchange within this size
   constraint is not easy.

 o What good is a database table that can't be joined with
   other tables?  Conversely, DNS does not need joins since
   lookups are one dimensional. Although DNS has an effective
   db architecure for lookups, the architecture is effective
   because it is optimized for lookups. It has NO existing
   constructs for building joins. There aren't even any
   conceptual hooks for this. You'd literally have to add an
   entire new framework, along with a collection of verbs and
   protocol mechanisms to DNS in order for this to work. Don't
   forget the locking and authentication requirements.

 o Databases need tools and hooks for the tools. Surely you
   don't expect users to edit zone files directly? But GUI
   gizmos that let users lock a record and edit the contents,
   set permissions, and perform triggered updates, they require
   protocol hooks which leverage authentication, etc.

In short, DNS is not capable of serving as a general-purpose database
without totally overhauling the protocol and service. Unfortunately, DNS
does not have the structure to allow these changes. It doesn't even have a
version field!

Morover, overloading the DNS service with these features would MAKE IT
USELESS FOR LOOKUPS. If DNS were converted into a general purpose lookup
archicture that resulted in a magnitude more queries, all kinds of
problems would happen. Do you think the root could handle a magnitude more
queries? We already know that responses overflow, but what happens when
DNS caches start to overflow? How useful is the distributed lookup 
service when none of the distributed lookup points have the data?

Furthermore, calling DNS a database and comparing it to Oracle is a false
premise. It is not a general purpose database along the lines of any
existing database product. Seriously, you would have an easier time
turning IMAP into a distributed database than you would with DNS.

DNS is a _distributed lookup_ service. There is no way that DNS can serve
the kinds of functions that people expect from general purpose database
and still be useful for lookups. Advocating its usage for such or
representing that it is capable of performing as such would be
irresponsible of this group and the Internet community in general.

But since this comes up so very often, my position is to advocacate
restraint so that we keep DNS from being loved to death by people who
think it can be a general purpose database or a directory. And since we
know that if all of the necessary cruft were added to DNS in order to
support those functions IT WOULD BECOME USELESS FOR LOOKUPS, lets define
where the line is, and let's not be arbitrary about it.

As for your baseball score application, there are a lot of issues with
that. Putting all of the systems in a single .baseball domain doesn't give
you access to all of the systems unless you use zone transfers. At that
point, why do you need DNS, since you aren't doing lookups? Couldn't you
just be replicating static lists with TFTP? Couldn't you use FTP or HTTP
and gain authentication? Or use CGI and XML and get update capabilities
with locking and more? Again, you would be further ahead if you started
with something like a shared IMAP message store; as inappropriate as that
would be, it would be much more usable than DNS. Use DNS to find the
server(s) for your application, you don't need to use DNS for the
application data, and doing so would be a bad idea anyway.

> have learned about how NOT to administer globally vital resources.

DNS works pretty damn well as a lookup service. We don't need another
lookup service.

What we need are better tools for managing distributed data, of which DNS
data is a subset. LDAP is advancing nicely and there is now a locator
protocol in place so things like user-specific authentication and
application-specific transactions are certainly now possible. For
large-scale database services, I agree that the IETF needs to develop a
vendor-neutral database transport protocol (similar to the way that
SMTP/POP/IMAP provide vendor-neutral email transports, we need a
vendor-neutral database access protcol).

DNS is not it.

> not, the current DNS has to keep working.

The current DNS will only keep working if it is restrained to lookups, the
very function that it was designed to serve. It will not keep working if
the protocol, service, tables and caches are overloaded with excessive
amounts of data which doesn't benefit from the lookup architecture.

---

From: John Gilmore <[email-masked]>
Date: Tue, 17 Apr 2001 00:16:31 -0700

> > ... a locally published, globally accessible, hierarchical,
> > distributed, replicated, cached, high availability, dynamic database ...

Just as I said, Oracle doesn't offer this.  Nor does the DNS offer
what Oracle has.  DNS is the only game in town for what it does.
There's no point in beating up the strawman of "DNS as generic database".

The point is that it is the ONLY database of any sort that has the above
characteristics.  There's only one in the known universe.  Everybody
who ever needed something like this (e.g. the Web) ended up using DNS
as a sub-component, because it already existed and worked, and tens of
thousands of people already maintain the information in it.

Randy's point seemed to be that we should limit access to this singular
wonder (I assume on the grounds that we would thereby be protecting it).

I argue instead that rather than reserve DNS for only holding information for
some sort of privileged applications, that we let it be used as it has
been used for decades.  For publishing and obtaining information
useful to whatever applications need its facilities.

If we did withhold access to it, new significant applications would
have to provide similar facilities -- and then there would be TWO
global distributed replicated blah blah blah databases.  In the long
run that might be a good thing, having a backup or two.  It's more
likely that the next world-shaking system like Email or the Web will
merely fail, because it lacked a global database and couldn't use
ours.

I suggest that if we want to protect the DNS, it would be better to
design a backup system -- as IPv6 is for IPv4.  The One That Fixes The
Structural Problems We Know Will Bite Us Someday.  Let's get it ready
as a research project, and deploy it as we need it or find it fun,
rather than forcing some poor application to invent it because we
won't give them a DNS record type.

And meanwhile, to protect the DNS, we should fix the minor limits in
the DNS protocol, whether they be performance, implementation,
fixed-size fields, or whatever.  So it can keep evolving in case the
research doesn't pan out.

When I was a DNS registrar (of no TLDs, due to NSI) I was surprised
that no registrars built tools for automatically telling their
customers when the customer's DNS was misconfigured, and suggesting
what to do about it.  If there's a performance problem due to
misconfigured servers or zones, a few relatively simple tools could
perhaps diagnose the problems, letting humans focus their attention on
the hot spots.

	John

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 17 Apr 2001 10:50:17 -0700

John Gilmore wrote:

> I argue instead that rather than reserve DNS for only holding
> information for some sort of privileged applications,

Nobody is advocating that we should restrict it to specific apps. What I
am advocating is that we restrict it to pure lookups of Internet specific
resources rather than succumbing to the constant push to extend it into
general-purpose database and directory services.

For example, some of the things you listed in your prior message are not
connection-critical lookups, do not require the use of DNS (life would
just be easier if you could use DNS), and would actually be better served
by something like LDAP:

>>> Crypto keys.  Physical locations. Mail handlers.  Other service
>>> handlers.  Text.  Names.  Addresses for lower or higher level
>>> protocols.

All of those would be better served through local authenticated queries
(aka LDAP). None of them are optimally served with DNS.

> that we let it be used as it has been used for decades. For publishing
> and obtaining information useful to whatever applications need its
> facilities.

The Internet of the last 10 years is a lot smaller than the Internet of
the next 10 years. There are better alternatives for data that won't
require polluting DNS' lookup functionality or rewriting the protocols,
and which will just work better.

> have to provide similar facilities

Or they could use any of the existing data-publishing and gathering
technologies already out there.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 17 Apr 2001 17:09:22 -0700

> So, define "lookups of Internet specific resources".  If you propose
> to limit the availability of DNS, you have the burden to define
> exactly who will and who won't be allowed to use it.

I have:

 | Date: Thu, 12 Apr 2001 08:54:27 -0700
 | From: "Eric A. Hall" <[email-masked]>
 |   To: Robert Elz <[email-masked]>
 |   CC: Thomas Narten <[email-masked]>,
 |       [email-masked]

 | I consider "lookup" to be a piece of required data which is
 | necessary for a distributed (eg, Internet-wide) application
 | process to complete.

There are other quals which I am incorporating into a personal draft on
the general subject of ~"Considerations for new DNS RRs".

> An earlier post by you suggested that you thought "MX" was a mistake,
> that email server info should never have gone into the DNS. That
> statement seemed to me to be a bit of a gauntlet thrown down.  If
> email, which is the long-term killer application of the Internet and
> its predecessors, doesn't qualify as an "Internet specific resource",
> then what would?

To be precise, I said that RRs for service- or application-specific data
should not go into DNS (with MX being cited as an example), and that
keeping app-specific RRs *like* MX out of DNS has been an ongoing effort
(which eventually resulted in SRV, a single RR for general service-layer
connection config).

> I didn't mean to start an LDAP flame war.  I wasn't even talking about
> LDAP.  I'm sorry that LDAP is threatened by the DNS.  I'm sorry that
> you're sensitive about it.  I wish LDAP could be just as popular as
> you want it to be.  Forget I ever mentioned it, even though I didn't.

This isn't about LDAP vs DNS, it is about your insistance that DNS is
always the appropriate technology for all data of any kind on any network
anywhere. For the application-specific authenticated queries required by
your own examples, LDAP is a more-suitable technology than DNS. I don't
know how you got LDAP-vs-DNS from that, nor do I really care.

What I *do* care about is the globally-distributed lookup service which
everybody depends on, and that it doesn't get broken by excessive
extensions which do not serve the purpose of the protocol and which do not
even benefit from the nature of the protocol. To wit, you have yet to
provide an example which absolutely requires DNS and which could not be
better served by some other technology. You have only provided examples
which overload the hierarchy and protocol, which require significant
amounts of protocol redevelopment to optimize for, and which don't even
BENEFIT from being in DNS in the first place. In all of your examples,
faster deployment and better access to the localized data would be
achieved by using something other than DNS. Your demand that DNS be
prostituted to accomodate this cruft is simply untenable.

> Just don't tell us that new applications CAN'T use DNS, and MUST use
> something else.  Without a very good justification, which so far I
> haven't seen.

This group reject extensions fairly often.

---

From: John Gilmore <[email-masked]>
Date: Tue, 17 Apr 2001 16:25:36 -0700

An earlier post by you suggested that you thought "MX" was a mistake,
that email server info should never have gone into the DNS.  That
statement seemed to me to be a bit of a gauntlet thrown down.  If
email, which is the long-term killer application of the Internet and its
predecessors, doesn't qualify as an "Internet specific resource", then
what would?

Let's let a thousand flowers bloom.  YOU can serve your information your
way, I will serve mine with DNS.  We can live and let live.

	John

---

From: Randy Bush <[email-masked]>
Date: Wed, 18 Apr 2001 08:45:19 -0400

> exactly who will and who won't be allowed to use it.

or, conversely, if you plan to add gnurr to it, you need to justify that.
design conservatives may prefer the latter.

randy

---

From: John Gilmore <[email-masked]>
Date: Tue, 17 Apr 2001 23:56:01 -0700

> anywhere. 

This isn't about that strawman, either, since I didn't insist on that.
Maybe you and I should give it a rest, and see what a few other people
think.

	John

---

From: Robert Elz <[email-masked]>
Date: Wed, 18 Apr 2001 11:27:53 +0700

Date:        Tue, 17 Apr 2001 17:09:22 -0700
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  |  | I consider "lookup" to be a piece of required data which is
  |  | necessary for a distributed (eg, Internet-wide) application
  |  | process to complete.

That restricts absolutely nothing that anyone is going to care about.
Anything that uses the internet is distributed by definition (as opposed
to things that simply run on computers attached to the internet - eg:
my computer runs a compiler, but that is local, not distributed, and
fortunately, has no need for anything at all in the DNS).   But all
e-mail, web, irc, ... all count as distributed.   So, your definition
just says that anything that is needed by any such application can go
in the DNS.   That's fine, I don't have a problem with that, though I
would probably restrict it a bit more, so it better fits the current
DNS protocols (unless/until they are ever extended, and then that is
deployed widely enough to make a difference).

  | There are other quals which I am incorporating into a personal draft on
  | the general subject of ~"Considerations for new DNS RRs".

Then those we are going to have to see before the rest of us will
have any idea whether we agree or not.

kre