Subject: the KEY debate

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Aug 2002 13:17:36 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Loomis," == Loomis, Rip <[email-masked]> writes:
    Loomis> First, I agree with Matt's recommendation to take the
    Loomis> discussion to namedroppers...but as another way to state what
    Loomis> Matt already stated quite well above, it's not that having
    Loomis> lots of non-DNSSEC info in KEY records "breaks DNSSEC".  It's
    Loomis> that having to sort through all the possible cruft at the top
    Loomis> of a zone and look for the "right" key causes the DNSSEC
    Loomis> signature verification process to take too long.  There's not
    Loomis> much IMHO that can realistically be done to engineer either
    Loomis> the software or the protocol to fix this...other than limiting
    Loomis> the KEY record as that I-D discusses, and using APPKEY or
    Loomis> something similar to store the non-DNS application keys.

    Loomis> If anyone sees any holes in my summary above...ask me on
    Loomis> namedroppers.

  Let's be clear.

  Some people who are not application developers, and who have no deployed
code, want to obsolete KEY EVERYWHERE for non-DNS use because they think that
it might cause problems if put at the apex of a zone.

  Who wants to put non-DNS KEY records at the apex of a zone?

  What application needs it there?

  1) IPsec.	   nope, needed with host records or reverse records.

  2) SSH/telnet.   nope, same requirements as IPsec.

  3) HTTPS.	   maybe for supporting "example.com" as an alias for
		   www.example.com, but due to HTTPS limitations, would
		   require a seperate IP address from www.example.com
		   (so that the server could use the proper certificate)
		   A major hassle, and it is unlikely that this is going
		   to matter as long as we do web certificates with X.509
		   CAs.

  4) SMTP.	   Put an MX record there. Use the KEY record attached to
		   the MX record, and authenticate the server. You might
		   think that you want to authenticate the zone's key, not
		   the server's key. Well, that doesn't work, because you
		   don't know which of potentially many MX servers you will
		   talk to. You could give them all the same private key,
		   but that would be a mistake, given that for best
		   reliability, you want the MXs in different places, run
		   by different people.

  So, we are left with someone who wants to do:
      "ssh example.com"

  rather than 
      "ssh host1.example.com"

  Of course, they might put 100 A records at "example.com". Will DNSSEC deal
with this? Will it be cause the signature verification process to take too long?

Massey/Rose write:

>differences in more detail.  Combining these very different types
>of keys into a single sub-typed resource record adds unnecessary
>complexity and increases the potential for implementation and deployment
>errors.  Limited experimental deployment has shown that application
>keys stored in KEY records are problematic.

Also, they write:

>The following table summarizes some of the differences between DNSSEC
>keys and Application keys:
>
> 1. They serve different purposes.
>
> 2. They are managed by different administrators.
>
> 3. They are authenticated according to different rules.
>
> 4. Nameservers use different rules when including them in responses.
>
> 5. Resolvers process them in different ways.
>
> 6. Faults/key compromises have different consequences.

#1 is confused about the purpose of DNS. DNS serves to map names into things
that the network layer can use to connect with. 

DNS is to permit people to type "telnet host1.example.com" and have it
work. In an age of SECURITY, that means that we all of the network blobs
required to make that connection. 

These are *not* APPLICATION keys because "telnet" is not an application, it
is a session layer protocol. Emacs is an application. Word is an application.

#2 is also confused when it comes to IPsec and SSH keys.
IP addresses are FREQUENTLY managed by the same people who manage the hosts
that they are assigned to. Even when protocols like DHCP is used to assign IP
addresses, we have demonstrated that making the link to the public key can be
done at the same time. There are two WGs that want to leverage this kind of
thing.

They further list #3 - that keys would be exchanged with the parent zone.
DS gets rid of that, so this comment is moot.

#4 is a concern - but, you MAY NOT deprecate a facility without having
provided a replacement facility. The SRV and NAPTR suggestions are
unacceptable, as they introduce yet another round trip. There are only two
methods which will work:
      1) special names. "ipsec.example.com" - might as well use	KEY.
      2) a RR for each application.

Claim #5 is totally confused. They keep saying how application keys must not
be used to authenticate data. They then go on to explain how writing
application is "hard" because we might have to do DNSSEC ourselves. Not only
do want to do that, but we *insist* on doing it.

Claim #6 is again totally confused. Where does it say that application keys
are used to authenticate DNS data?

In general, we regard this draft as a denial of service attack on the effort
to secure the Internet. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

		   

--
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/>

---

From: Rob Austein <[email-masked]>
Date: Sat, 03 Aug 2002 14:50:39 -0400

I know I'm going to regret this, but....

There is a specific problem with using the KEY RR type for things
other than DNSSEC's own internal keying.   It's called the "sub-typing
problem" and has been discussed namedroppers many times before, please
check the archives if you don't already understand the problem.

This is a totally separate discussion from whether putting keys for
things other than DNSSEC itself into the DNS is a good or bad idea.
If we stipulate that such keys should use a different RR type, I'm
relatively agnostic on the subject.

Confusing the two issues does not help anybody.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 03 Aug 2002 21:43:39 +0200

> Confusing the two issues does not help anybody.

Agreed.  But removing functionality does not help anybody either,
that's why I suggested shipping restrict-key draft together with a
migration path in the form of APPKEY, an updated CERT RR
specification, or a specification stating that applications should
define their own RR for keying material, or whatever approach is
preferred by the DNS illuminati.  Then the restrict-key people are
happy, and the application keys in DNS community is happy.  Why is
that solution unreasonable?

---

From: Rob Austein <[email-masked]>
Date: Sat, 03 Aug 2002 18:21:13 -0400

> that solution unreasonable?

If the two halves of this proposal were at equal stages of readiness,
this would be a reasonable way forward.  Unfortunately, they're not:

- The reasons for updating the DNSSEC protocol spec to restrict use of
  the KEY RR type to DNSSEC internal use have been well understood for
  years, the DNSEXT WG is actively trying to get the updated DNSSEC
  spec done and the protocol deployed, and from the DNSSEC core
  protocol persepctive, there's no reason to delay updating the spec.

- The APPKEY/CERT/whatever stuff isn't as far along.  No doubt you
  recall the SIKED BOF this year in Minneapolis, at which several
  people asked some pretty fundamental questions about the problem
  spaces people were trying to solve and what the underlying trust
  models were.  No good answers at that time.  Not saying there
  -aren't- good answers, but at that BOF there didn't appear to be any
  kind of consensus on the subject.  So proponants of this idea have
  some work cut out that either has not yet been done at all yet or
  has been done but has not yet been walked through the IETF process.

Finally, given the above, I have to wonder who would really benefit
from delaying the cleanup action on the core DNSSEC spec until the
other stuff is done.

---

From: [email-masked]
Date: Sun, 04 Aug 2002 09:19:08 +1000

> that solution unreasonable?

	We have basically already made a decision about whether we
	should have different type or not for application keys.
	DNSSEC is one application and the decision was made to
	give it its own type by removing the other uses.

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

---

From: Dan Massey <[email-masked]>
Date: Sun, 04 Aug 2002 14:15:09 -0400

Hi,

I started a more detailed in-line response to the various claims
about key restrict but  the main points of this discussion remain
the same as the last couple times....

  - key restrict does not prohibit storing application keys in the DNS
    and key restrict explicitly states that in a couple places.

  - key restrict does say the KEY record should not be used to
    store application keys and it does eliminate KEY record subtypes.

  - subtypes are a bad way to overload a DNS record and there is
    consensus that a subtyped KEY record is not the right way to
     store applications keys in the DNS.

There is an orthogonal problem of  what is the best way to store
application keys in the DNS.  Key restrict does not identify one
approach as "the solution" for storing application keys, but note
that key restrict is 100% compatible with all the approaches being
discussed.  There are legitimate open issues and trade-offs being
considered and there are places to discuss those issues.

Dan

---

From: Rob Austein <[email-masked]>
Date: Sun, 04 Aug 2002 20:13:44 -0400

At Sun, 04 Aug 2002 12:53:03 -0400, Michael Richardson wrote:
> 
>     Rob> There is a specific problem with using the KEY RR type for things
>     Rob> other than DNSSEC's own internal keying.   It's called the "sub-typing
>     Rob> problem"
> 
>   Yes, and obsoleting KEY does nothing to solve this problem.

Sorry, wrong.  (a) it removes the need for DNSSEC-aware resolvers to
sift through RRsets picking out individual keys by subtype codes, and
(b) it reduces the chances that KEY RRsets will be large enough to
trigger DNS message truncation and fallback to TCP.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 Aug 2002 08:51:18 -0400

>that solution unreasonable?

This is a philosophical answer.  So, if you have code to compile, 
take care of that and leave this for when you want to counter the 
effects of all that coffee and cola you've had today.

There is a good reason to restrict the use of the KEY RR.  The reason 
is that in doing so we can achieve a tighter definition of DNS 
security.  Having a tighter definition makes the security model 
clearer and more verifiable (in that it works, not in the sense that 
I can verify data).  Additionally, due to the implementation of DNS 
(I mean the protocol, not the software), if the KEY RR is 
unrestricted we can run into performance glitches (TC bit getting 
turned on).  That and the desire to put the KEY RR set in the 
authority sections when possible drive a desire to limit the size of 
the set.  Then, of course, there is the "fear" (as in FUD) that 
poorly implemented resolvers may not check whether the KEY RR flags 
and protocol field are properly set and misuse a key.  (Yes, FUD.)

Rob has already mentioned the "sub-typing" problem, and referred 
further discussion to the archives.

None of this addresses the application-keys-in-DNS issue.  Yes, 
currently the KEY RR can accommodate them (RFC 2535) and the 
KEY-restrict draft would stop this.  The reasons for the stopping are 
above, and should be clear in the draft.  (I've made comments to that 
effect already.)

In a perfect world (we wouldn't need DNSSEC, but) it would be good to 
be able to achieve both the restriction on KEY and provide an 
alternative for the application keys in one fell swoop.  In my 
opinion, this just can't happen.

First, one of my goof-ball ideas was that we should just completely 
ditch the KEY RR for DNSSEC altogether, replacing it with the DNSKEY 
RR and restrict DNSSEC processing to just that record type.  I really 
am leery of restricting an existing definition because there will 
always be code out there that implemented the unrestricted version of 
the definition.  Moving to a new RR type would eliminate the problem, 
but was shot down because the KEY restrict draft was already written.

Second, give that restrict key is on the threshold, it can be put in 
place to alleviate the burden placed on the DNSSEC definition now. 
Waiting for a solution to application-keys-in-DNS would be a delay I 
think we could do with out.  Partly because of my third point.

Third, there's no clear consensus on how to proceed with application 
keys in DNS.  I don't mean DNS* consensus, I mean any sort of a 
community consensus.  (How close are IPsec OE and SSH in agreement on 
how to approach this?)  For my part, I really think that it is a 
mistake to expect a generic application key solution to come from 
DNS, rather solutions should come to DNS.  (E.g., from the SSH WG or 
the IPSEC WG.)  Yes, solutions in DNS should get some DNS review, but 
the applications know better their needs and goals.  The solutions 
should also get some Security Area review, as the DNS community is 
not geared towards security issues (if we were, perhaps DNSSEC would 
be done by now).

Third and a half, I'm hesitant to support any application key 
approach that relies on the DNSSEC protections to cover delivery of 
the key material from end to end (e.g., server to client).  DNSSEC 
may be part of the solution (the DNS authoritative server to 
resolver) but is not the whole (e.g., requiring a client to allow a 
human user to inspect the fingerprint before blindly accepting is a 
good idea).

Fourth, this is the philosophical comment.  Waiting until there is a 
completely worked out design before going forward is a good way to 
design a bridge over a river, and is generally a sound engineering 
approach.  A converse example is the OSI protocol suite, especially 
the session layer protocol, which addressed every conceivable 
situation in theory and wound up with an unworkable implementation. 
Another example, much more philosophical, is a human society and the 
body of law applied to it.  No set of lawyers could ever think up 
every situation ahead of time, so it is sometimes best to partly 
define the law and let cases set precedents.

My point here is that there is sometimes value in partial 
definitions, especially when the next step to a complete definition 
is still unsettled.  Restricting the KEY RR (or defining my pipe 
dream of DNSKEY RR) accomplished a known, needed step.  Losing the 
application-key-in-DNS feature (or any feature) isn't a good thing, 
but there isn't a clearly good alternative.  I'd say let's not wait 
and hold the KEY RR restriction up while testing the best way to 
accomplish the needs of applications wanting to distribute their 
keys, possibly via DNS.

If you've made it this far, try counting sheep.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Aug 2002 12:53:03 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Rob" == Rob Austein <[email-masked]> writes:
    Rob> There is a specific problem with using the KEY RR type for things
    Rob> other than DNSSEC's own internal keying.   It's called the "sub-typing
    Rob> problem" and has been discussed namedroppers many times before, please
    Rob> check the archives if you don't already understand the problem.

  We know that it can be solved by one of two means:
     1) well known naming scheme that lets me ask for just what I want.
     2) creating a RR for each use.

  There are various schemes for making the name of #1 be looked up
first. They are a total waste of time since they just add a needless layer of
indirection (I can't ask for just the NAPTR that I need, can I? I have to
sort through them), and they likely cost another round trip.

  Further, if we decide to designate a well known name for a particular key
usage, then there is little reason we can't use "KEY" RR as the format. 
  
    Rob> This is a totally separate discussion from whether putting keys for
    Rob> things other than DNSSEC itself into the DNS is a good or bad idea.
    Rob> If we stipulate that such keys should use a different RR type, I'm
    Rob> relatively agnostic on the subject.

  It is not for DNSSEC people to decide if DNSSEC provides the right trust
model for another protocol. It is for the designers of that protocol.

  That means that DNSSEC may not even provide the right trust model for
mapping of names to IP addresses for certain end-users!

  Any proposal that removes functionality without offering an immediate
alternative is a complete and total non-starter.  You later write:

  Rob> If the two halves of this proposal were at equal stages of readiness,
  Rob> this would be a reasonable way forward.  Unfortunately, they're not:

  Until such time as -restrict-key-for-dnssec is massively overhauled to 
remove the baseless FUD which occupies 90%, then I do not agree that removing
KEY has any documented justification.

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 Aug 2002 08:53:29 -0400

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "Rob Austein" <[email-masked]>
Sent: Sunday, August 04, 2002 12:53 PM
Subject: Re: [Design] Re: the KEY debate

>      2) creating a RR for each use.

Restricting KEY to DNSSEC only does solve the sub-typing problem - for
DNSSEC.  For everything else that wishes to use the DNS to store keys (IPSec
and SSH are the only 2 that come to mind).  APPKEY faced the same problem -
it just pushed the subtyping problem off to all the other protocols and left
DNSSEC as the lucky one.

Esoteric naming schemes (like SRV) bring an increased chance of admin error
(entering RR) and user error (queries).  A new RR for each application
wishing to use sounds better.  If it is good to restrict KEY to DNSSEC, then
having a separate RR type for any other public key is a good idea too.
Again - we get to avoid the sub-typing problem without resorting to other
tricks like naming schemes.

> model for another protocol. It is for the designers of that protocol.

I think Rob is referring to the ever-ongoing debate every time someone
suggests a new RR type be added to the DNS.  It's not a security debate,
more like a philosophy.  Some argue the DNS is fine to use to support other
protocols in this way, some consider it a bad thing.

I was in camp B.  Now I'm leaning towards camp A.  If some other protocol
thinks that using the DNS is the best way to distribute keys, or other
information, then a new RR might be in order.  I realize that we aren't the
best group to argue what the format of those new RR should be, and that
someone experienced with the protocol in question (IPSec, SSH, whatever)
needs to be included, but someone with DNS knowledge should be included as
well - to make sure it meshes with the agreed DNS spec.

> KEY has any documented justification.

Just because this draft restricts KEY to DNSSEC does not mean that there
will never be a way of storing other keys in the DNS.  Just that the DNS WGs
alone aren't the best people to do it.  There needs to be some input from
the designers of other protocols.  First question:  what special information
(besides the key itself) should be in a IPSec DNS RR RDATA?

Scott

---

From: Derek Atkins <[email-masked]>
Date: 06 Aug 2002 09:42:12 -0400

Michael,

Remember that the IETF is based on rough consensus, and there has been
rough consensus within the DNSEXT working group to restrict "KEY" to
only DNSSEC infrastructure.  Yes, you object.  We know that.  We
acknowledge that.  One objection does not invalidate a rough
concensus.

May I make a suggestion: instead of using your energy to write long
missives about how restrict-key sucks, may I suggest that instead you
refocus that time and energy to write a draft that defines a new FSKEY
record that defines how to store FreeS/WAN keys in DNS?  Feel free to
copy-and-paste the text out of 2535 that defines the KEY record, if
you feel that is sufficient (I would not actually recommend that -- I
don't think you need or want the subtyping in the 2535 KEY record).

My recollection of reading the OE draft was that you needed additional
information above and beyond what was provided by the KEY record.  In
particular, IIRC, you needed a pointer to the gateway and the network
size to use.  This would be the perfect opportunity to combine this
all into a single record!

I am very sure that if you write such a draft it can progress
extremely quickly through the process.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Aug 2002 22:29:17 +0200

> don't think you need or want the subtyping in the 2535 KEY record).

Is this the WG blessed answer to storing application keying material
in DNS?  Defining new RRs, that is.  If it isn't the WG blessed
solution, why should he follow this suggestion instead of continuing
to use what is already implemented and described in a draft?  It seems
like someone else could suggest FreeS/WAN to sub-type CERT instead, or
sub-type KEY (which actually was designed for this purpose once upon a
time), or encode the key into AAAA records, and these recommendations
would be equally valid and equally useful to someone that has already
implemented and documented another solution.

Having a blessed (as in reviewed and designed by DNS people) answer to
this problem was all that SIKED was about, at least that's my
interpretation of it.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 16:59:11 -0400

At 10:29 PM +0200 8/6/02, Simon Josefsson wrote:
>in DNS?  Defining new RRs, that is.

Seems like the best current approach to me, but there's no "blessed" 
label to apply to it.

>this problem was all that SIKED was about, at least that's my

Oh my lord no!  SIKED was accidently about DNS folks defining how to 
put application keys into DNS - only 'cause we started it.  SIKED 
wasn't supposed to be so - which is why it was forked off from 
DNSEXT.  But we kept coming back to DNS and that's why there's no 
SIKED II BoF.  Had SIKED went anywhere, we would have been in the 
Security Area, not in the areas currently doing DNS (Internet and 
O&M).

Look back at the keydist archives.  I tried floating discussion 
topics, at first trying to define the problem and then later "Let's 
assume DNS is involved."

http://www.cafax.se/keydist/maillist/2001-12/msg00009.html
and
http://www.cafax.se/keydist/maillist/2002-03/msg00005.html
and
http://www.cafax.se/keydist/maillist/2002-03/msg00048.html

---

From: Derek Atkins <[email-masked]>
Date: 06 Aug 2002 17:24:57 -0400

> implemented and documented another solution.

No, it is not the WG blessed answer.  It is a suggestion, and was
framed as such.  You are correct that subtyping CERT is another
reasonable approach.  I do not believe that subtyping KEY is a
reasonable approach (although a copy-and-paste of the text defining
KEY into a new draft that defines fooKEY would be reasonable, IMHO).

At this point I am just tired of the running around the issue.  I give
up.  I want to see progress.  As I was a vocal proponent of
sub-typing, I give up and buy into the type-per-application and have
encouranged Mr. Richardson to work towards that goal.

If this means I need to host a DNSKEY BOF in Atlanta, so be it.

> this problem was all that SIKED was about, at least that's my

No, SIKED was trying to be more.  I want to see a specific niche
carved out: a framework for how to store application keys in DNS for
those applications that completely understand all the issues involved.
My hope would be that we could create a template that applications
could follow to define their own key-type.  Most of the work would be
writing the security considerations to appease people like Mr. Moore
who clearly believes that nobody should trust application keys from
DNS, whereas there is clearly a community who believes that
DNSSEC-based security is "good enough."

So please, Mr. Richardson, write that draft.  I look forward to
reading it.  Perhaps it can be the basis of this "template" (if said
pipe-dream of mine ever happens).

-derek

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 6 Aug 2002 23:40:06 +0200 (CEST)

On Tue, 6 Aug 2002, Simon Josefsson wrote:

> Is this the WG blessed answer to storing application keying material in
> DNS?  Defining new RRs, that is.

I suggest that the people who believe they have a protocol that would
benefit from storing keying material in the DNS define an RRs, write some
code and deploy it - then we'll evaluate and see what does work and what
does not. the alternative might of course be to discuss this forever and
while we're discussing people will go off using TXT records instead.

	jakob

ps. I know OE currently uses TXT records and there is a reason for it
    since there currently isn't anything better - let's build that better
    thing.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 7 Aug 2002 09:20:59 -0400

----- Original Message -----
From: "Derek Atkins" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Michael Richardson" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Rob Austein"
<[email-masked]>
Sent: Tuesday, August 06, 2002 5:24 PM
Subject: Re: [Design] Re: the KEY debate

> DNSSEC-based security is "good enough."

I've been thinking the same thing - a BOF about using DNS to support other
applications and set up a general framework/process for getting any type of
network information in the DNS.  Not just keys.  The hard part would be to
stress that the DNS isn't an end all solution, but a possible option for
things like certificates and key distribution, now that DNSSEC has added
integrity and source authentication.

I always thought SIKED was more of a general purpose "Interent Key
Distribution methods" BOF.  The fact that "DNS people" started it was
supposed to be irrelavent, but I think that may have been one of the caused
it didn't catch on:   Other people thought it was strickly a DNS group when
it was hoped to be more.  Correct me if I'm wrong.

<joke>
As for the BOF, why don't we all call it PDNS, for "Pimping DNS for other
applications"?
Depends on how you view it I guess.
</joke>

Scott

---

From: bert hubert <[email-masked]>
Date: Wed, 7 Aug 2002 15:52:52 +0200

> Depends on how you view it I guess.

Well, our daemon is already called 'pdns' so please don't :-)

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 14:07:13 -0500

on 8/7/2002 8:20 AM Scott Rose wrote:

> I've been thinking the same thing - a BOF about using DNS to support
> other applications and set up a general framework/process for getting
> any type of network information in the DNS.

Ugh. The more crap we put into DNS the less useful it will be for
lightweight lookups. We'll need another DNS if we pimp this one.

Might I suggest that it would be more fruitful to work on ways to support
applications in one or more external services, and solving the problems
with those services such that they would be usable. I am working on the
LDAP-WHOIS stuff just for this purpose (give every delegated domain and
netblock LDAP referral hooks at the time of delegation). There are lots of
other options out there that also deserve attention.

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

---

From: David Conrad <[email-masked]>
Date: Wed, 07 Aug 2002 12:56:35 -0700

> lightweight lookups. We'll need another DNS if we pimp this one.

Can we _PLEASE_ stop with this FUD?

Explain exactly why adding a new RR type, one that does not change the
underlying DNS algorithms, will have any significant impact on the DNS, much
less make it "less useful".  On the contrary, it would make the DNS more
useful, pretty much by definition.

Rgds,
-drc

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 7 Aug 2002 22:00:47 +0200 (CEST)

> lightweight lookups. We'll need another DNS if we pimp this one.

why would more data (aka crap) in the dns render it less useful for
lightweight lookups?

> Might I suggest that it would be more fruitful to work on ways to
> support applications in one or more external services, and solving the
> problems with those services such that they would be usable. I am
> working on the LDAP-WHOIS stuff just for this purpose (give every
> delegated domain and netblock LDAP referral hooks at the time of
> delegation). There are lots of other options out there that also deserve
> attention.

and when you've added redundancy, security and a couple of other nice
properties you've suddenly almost built that other DNS and called it LDAP
instead.

	jakob

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 16:31:15 -0400

> lightweight lookups. We'll need another DNS if we pimp this one.

HUH?  I don't see where this leap in logic comes from.  Just
because I can make a query for:

        myserver.host.example. IN SSHKEY

does not imply that lookups for

        myserver.host.example. IN A

are any "heavier".  So, either you have a specific example in mind
which you did not state, or you are just spreading FUD on the topic.
I don't know which, but I'd appreciate it if you actually stated facts
instead of unsubstantiated non-problems.

-derek

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 16:31:31 -0500

on 8/7/2002 3:31 PM Derek Atkins wrote:

> HUH?  I don't see where this leap in logic comes from.  Just because I
> can make a query for:
>
> are any "heavier".

Of course they aren't. It is the queries for myserver.host.example. with
qtype=ALL that are heavier.

And to answer your next question, sendmail and qmail both use qtype=all
out of the box.

And to give you an example:

  Z:\>dig @ns1.hotmail.com. hotmail.com. any

  ; <<>> DiG 8.3 <<>> @ns1.hotmail.com. hotmail.com. any
  ; (1 server found)
  ;; res options: init recurs defnam dnsrch
  ;; got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 24, AUTHORITY: 4, ADDITIONAL: 18
  ;; QUERY SECTION:
  ;;      hotmail.com, type = ANY, class = IN

  ;; ANSWER SECTION:
  hotmail.com.            1H IN A         64.4.52.7
  hotmail.com.            1H IN A         64.4.53.7
  hotmail.com.            1H IN A         64.4.43.7
  hotmail.com.            1H IN A         64.4.44.7
  hotmail.com.            1H IN A         64.4.45.7
  hotmail.com.            1H IN MX        5 mx01.hotmail.com.
  hotmail.com.            1H IN MX        5 mx02.hotmail.com.
  hotmail.com.            1H IN MX        5 mx04.hotmail.com.
  hotmail.com.            1H IN MX        5 mx05.hotmail.com.
  hotmail.com.            1H IN MX        5 mx06.hotmail.com.
  hotmail.com.            1H IN MX        5 mx07.hotmail.com.
  hotmail.com.            1H IN MX        5 mx08.hotmail.com.
  hotmail.com.            1H IN MX        5 mx09.hotmail.com.
  hotmail.com.            1H IN MX        5 mx10.hotmail.com.
  hotmail.com.            1H IN MX        5 mx11.hotmail.com.
  hotmail.com.            1H IN MX        5 mx12.hotmail.com.
  hotmail.com.            1H IN MX        5 mx13.hotmail.com.
  hotmail.com.            1H IN MX        5 mx14.hotmail.com.
  hotmail.com.            1H IN MX        5 mx15.hotmail.com.
  hotmail.com.            1H IN NS        ns1.hotmail.com.
  hotmail.com.            1H IN NS        ns2.hotmail.com.
  hotmail.com.            1H IN NS        ns3.hotmail.com.
  hotmail.com.            1H IN NS        ns4.hotmail.com.
  hotmail.com.            1H IN SOA       ns1.jsnet.com. dns.hotmail.com.
  (
                                        2002080603      ; serial
                                        8H              ; refresh
                                        1H              ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

  ;; AUTHORITY SECTION:
  hotmail.com.            1H IN NS        ns1.hotmail.com.
  hotmail.com.            1H IN NS        ns2.hotmail.com.
  hotmail.com.            1H IN NS        ns3.hotmail.com.
  hotmail.com.            1H IN NS        ns4.hotmail.com.

  ;; ADDITIONAL SECTION:
  mx01.hotmail.com.       1H IN A         65.54.254.145
  mx02.hotmail.com.       1H IN A         65.54.254.145
  mx04.hotmail.com.       1H IN A         65.54.254.145
  mx05.hotmail.com.       1H IN A         65.54.254.129
  mx06.hotmail.com.       1H IN A         65.54.254.129
  mx07.hotmail.com.       1H IN A         65.54.254.129
  mx08.hotmail.com.       1H IN A         64.4.49.7
  mx09.hotmail.com.       1H IN A         64.4.49.71
  mx10.hotmail.com.       1H IN A         64.4.49.135
  mx11.hotmail.com.       1H IN A         64.4.49.199
  mx12.hotmail.com.       1H IN A         64.4.50.7
  mx13.hotmail.com.       1H IN A         64.4.50.71
  mx14.hotmail.com.       1H IN A         65.54.232.7
  mx15.hotmail.com.       1H IN A         65.54.232.71
  ns1.hotmail.com.        1H IN A         216.200.206.140
  ns2.hotmail.com.        1H IN A         216.200.206.139
  ns3.hotmail.com.        1H IN A         209.185.130.68
  ns4.hotmail.com.        1H IN A         64.4.29.24

  ;; Total query time: 1000 msec
  ;; FROM: ferret to SERVER: ns1.hotmail.com.  216.200.206.140
  ;; WHEN: Wed Aug 07 16:24:19 2002
  ;; MSG SIZE  sent: 29  rcvd: 869
                               ^^^

Just using A, MX, NS and SOA. All sendmail/qmail queries to hotmail.com
get restarted.

Sure, hotmail could improve this by publishing fewer A and MX RRs and
using some kind of load balancer. However, at that point they would have
left DNS for some other technology.

What is so hostile about my approach that warrants calling it FUD versus
the other abandonments (eg, load balancing) that are more common?

> So, either you have a specific example in mind which you did not state,
> or you are just spreading FUD on the topic. I don't know which, but I'd
> appreciate it if you actually stated facts instead of unsubstantiated
> non-problems.

I will gladly expound on my theories and ideas in detail if you wish.
Frankly, I didn't think that it would be necessary.

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 17:43:01 -0400

> And to answer your next question, sendmail and qmail both use qtype=all

This sounds like a bug in those applications, not a bug in DNS.
I presume they are doing this to try to save a round trip?

> And to give you an example:
[snip]
>   ;; MSG SIZE  sent: 29  rcvd: 869

Yes, this is bigger than the 512 limit, but would still fit in a UDP
response.  EDNS0 solves this problem.  Turn on EDNS0 and you wont
restart your query.

> the other abandonments (eg, load balancing) that are more common?

It's not the abandonment proposal that is FUD, it's your statement
that "adding new record types breaks DNS".

-derek

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 17:16:55 -0500

> that "adding new record types breaks DNS".

What I said is that adding more crap to DNS makes it less useful. I didn't
say it would break DNS. That would be stupid.

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 18:21:13 -0400

> say it would break DNS. That would be stupid.

My appologies for mis-paraphrasing you.

However I think many people here would disagree that it would be less
useful, and I believe that your stating so is still FUD.  First, I
don't think keys are crap.  Second, the only real issue are
applications that make T_ANY queries, and I maintain those
applications are broken (or mainly for debugging purposes, like dig).

So unless you are saying that DNS should not be used because sendmail
is broken, I think the statement that more data is less useful is FUD.

-derek

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Aug 2002 18:48:15 -0400

> And to answer your next question, sendmail and qmail both use qtype=all

This was a bad idea in 1985, and has not improved with age.  It can
return the wrong answer under certain conditions, and the defence
against that failure mode involves at least as many queries as one
would have made if one just queried first for the MX then falling back
to querying for the A.

This is not hypothetical.  We tracked a series of whacky mail failures
at MIT-LCS in the early 1990s to another implementation of this same
bad idea (in a then-current version of MMDF).  We replaced the QTYPE=*
query with the obvious MX and A queries and the problems went away.

MMAILR never did this.  Postfix doesn't do this.  It's a misfeature.
Plow it under and sow its burial site with salt.  Don't defend it.

We now return you to your regularly scheduled interminable debate
about the true purpose of DNS.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 18:03:02 -0500

on 8/7/2002 5:21 PM Derek Atkins wrote:

> First, I don't think keys are crap.

Nor do I. I just wish there was somewhere else to put them.

> Second, the only real issue are 

That would be pretty dumb, too.

On the other hand, my bet is that more applications are likely to START
doing it once we have IPv6 applications that query for qtype=any instead
of doing AAAA before A.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 18:05:34 -0500

> Nor do I. I just wish there was somewhere else to put them.

[...] along with the "other information" that "some other protocol
thinks that using the DNS is the best way to distribute" that Scott
mentioned in his message which spawned my retort.