Subject: draft-ietf-dnsext-apl-rr-01.txt

From: Randy Bush <[email-masked]>
Date: Fri, 01 Dec 2000 17:53:20 -0800

please remind me why we need to create yet another rr, in this case to store
address assignment data in the dns.

randy

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

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Dec 2000 10:34:11 -0800

s/cidr blocks/<a million things>/

but why do we care?  cidr is a thing about rirs etc. which have other
stores.

is it is the dns's job to store the universe?

randy

> there's no existing rr that can handle cidr blocks
> 
> > From: Randy Bush <[email-masked]>
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> > To: namedroppers <[email-masked]>
> > Subject: draft-ietf-dnsext-apl-rr-01.txt
> > Message-Id: <[email-masked]>
> > Date: Fri, 01 Dec 2000 17:53:20 -0800
> > Sender: [email-masked]
> > Precedence: bulk
> > X-DCC-MAPS-Metrics:  ib.rc.vix.com 666; IP=0/74 env_From=0/66 From=0/13
> > 	Subject=0/3 Message-ID=0/3 Received=0/3 Body=0/3 Fuz1=0/3
> >

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Dec 2000 12:19:04 -0800

> No, but no other storage exists with global reach but DNS.

actually, in this case, other global stores do exist, the rir routing
databases, aka the irr.

> Yes, this probably Apps Area should have solved long time ago

is there even a coherent work item on this?  a good wg name might be
universalgarbagecan.  :-)/2

randy

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 2 Dec 2000 14:13:36 -0600

If we had some other choice...well, then it would be easier to say no 
to the requests.

Yes, this probably Apps Area should have solved long time ago, but 
this is a different story, and talking about it need a bar within 
close range.

     paf

--

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 2 Dec 2000 14:25:46 -0600

> actually, in this case, other global stores do exist, the rir routing

Ok, true in _this_ specific case, but not in the general case.

>universalgarbagecan.  :-)/2

Nope, but the name is correct.

    paf

--

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 02 Dec 2000 14:35:24 -0800

> If we had some other choice...well, then it would be easier to say no

But there is, isn't there? LDAP, as in, for example, ldap.cisco.com.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 2 Dec 2000 21:08:28 -0800

>But there is, isn't there? LDAP, as in, for example, ldap.cisco.com.

Ok, I have to take one step further down this slippery path:

Question: You want to know the phone number of "Eva Fr=F6lich". What 
LDAP database do you search in?

Even if you want to know more about "[email-masked]", what LDAP 
database do you go to, what query do you issue, and what schema do 
you use? What base DN is the record in?

=46urther, even if you know "/C=3DSE/O=3DCisco/CN=3DPatrik Faltstrom", what 
LDAP server do you go to?

Answer:
LDAP doesn't work globally because of the lack of indexing (only 
strict hierarchies like DNS exists, and works) and noone have been 
able to create "the root" which should work as the root nameservers. 
If this root existed, you should still only be able to query for 
records if you knew the DN. Now, the DN is both the location and 
unique identity of a record which is what I call "overloading the DN 
with information". If a record moves from one server to another one, 
the DN changes. Because of this, I as a person can not have one DN 
for the rest of my life as a unique identifier for my record.

So, as LDAP only handle the same kind of lookups as DNS (hierarichal 
when you happen to know the global unique identifier), is slower and 
doesn't have root servers in the world, people look instead at DNS as 
it works.

But, as I said, this discussion need a bar.

     paf

--

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 02 Dec 2000 22:00:05 -0800

> LDAP database do you search in?

The same is true of DNS: which domain should you search? If you can't
find something in DNS then how do you find it in LDAP, and visa versa?
By pushing garbage from DNS to LDAP you at least have a hint of
directory and database (the DAP part). DNS, it seems to me, is more of
a locator service but people are trying to make it a database.

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Dec 2000 09:18:10 -0800

> DNS is a crap directory.

trains fly very poorly.  but they're the only vehicle we have.  so keep
welding on them wings.  :-)

randy

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 03 Dec 2000 09:12:47 -0800

> LDAP database do you search in?

This is a problem for every federated namespace. BUT just because the
problem is the same for all of them does not mean that you might as well
use DNS. DNS has many other problems in addition to this one which make it
even more unsuitable, not equally unsuitable.

> doesn't have root servers in the world, people look instead at DNS as

Tell me how you will index partial elements of a value in DNS? If I want
to find all of the email addresses which contain "ehsco.com" how do I
search for this? How do I setup the backend? This specific functionality
is not defined nor is it even feasible with DNS. It is well suited to LDAP
however.

Second: how do you define per-RR ACLs in DNS? If I want to publish my work
phone to all anonymous agents, my cell phone to fellow employees, and my
home/emergency info to my family, how do I do this in DNS? Once again, the
specs don't allow for it and no servers support it, and the protocol
probably could not handle it without being morphed into an entirely new
protocol.

DNS is a crap directory.

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 3 Dec 2000 09:02:32 -0800

>a locator service but people are trying to make it a database.

Exactly, LDAP and DNS have the same "semantics", but with the big 
difference that LDAP doesn't have a root server.

I.e. given that I know the DN (which is the owner in DNS) for a 
record in LDAP, there is no root server I can query to know what LDAP 
server to send the query to. Mapping from DN to domainname (which is 
needed) doesn't exist, given that you don't use the DC naming scheme 
that is, and people don't.

And, you don't get _better_ service with LDAP as you only can lookup 
records given the DN. Global searches doesn't work, so you will never 
be able to find information about "Eva Fr=F6lich", just like you can 
not do indexed searches in DNS.

So, I understand why people ask why one should use LDAP when it have 
worse performance than DNS.

Maybe we should have a "GC" class (garbage can) for these things in DNS?

     paf

--

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 3 Dec 2000 09:36:33 -0800

>even more unsuitable, not equally unsuitable.

I agree completely. I am not arguing _for_ DNS. I just explain why 
people want to use it.

>is not defined nor is it even feasible with DNS. It is well suited to LDAP

It is not well suited in LDAP either, as you might have referrals 
(like in DNS), but no server-server protocol which transfer the index 
which is needed.

>home/emergency info to my family, how do I do this in DNS?

This exists in LDAP, given that the bind operations succeedes, and 
you agree with the server on what bind mechanisms you want to use.

>DNS is a crap directory.

I have not claimed that DNS makes searches possible. What I claim is 
that lookup (which you do in DNS) work crap in LDAP because of lack 
of root server, LDAP doesn't give searches etc etc.

    paf

--

---

From: Dennis Glatting <[email-masked]>
Date: Sun, 03 Dec 2000 09:57:04 -0800

I forgot to add one item to my comments.

One problem I have with adding any new RR type to DNS is the core
software (server and client), and across all vendors, must be modified
to incorporate the new type whereas with LDAP you simply (YMMV) add a
new schema and plug in data. In the case of DNS, you are introducing
software complexity and error to a critical operating component of the
Internet, worsened if you are relying on DNSsec. With LDAP, you are
not.

As you point out, the problem of finding a given piece of information
whether you are using DNS or LDAP is pretty much the same. However, it
is common practice to include a quasi-URL in a DN, such as
ou=3Dwww.verisign.com/RPA often found in Verisign certificates (the
"ou=3D" makes no sense to me). With this information one knows the DN,
the server to talk to, and hopefully the question to ask. :) I am not
saying such an approach is wonderful or even real-world, however it at
least makes a plausible case to dump trash into LDAP rather than DNS.

Is "Eva Fr=F6lich" a real person?

---

From: Simon Josefsson <[email-masked]>
Date: 04 Dec 2000 01:55:51 +0100

Dennis Glatting <[email-masked]> writes:

> Patrik Fältström wrote:
> > Question: You want to know the phone number of "Eva Frölich". What

Now we're getting to the heart of the problem.  It all depend on what
you want to look up.  If you want to search for personal names, DNS is
not the right tool by any mean.  In fact, no global directory would be
the right tool, personal names are not unique enough to be useful as
an address on a global scale.  Department-wide, company-wide or
perhaps country-wide LDAP directories is probably better suited.

But if we consider things that got a natural hostname, such as
servers, zones, ip addresses, email addresses, it's very appealing to
use DNS to look up information attached to these addresses.  This is
because, DNS already support this infrastructure, and when it comes to
servers (hostnames) DNS _is_ this infrastructure.

My point is that some things are "natural" to store in the X.400
(L)DAP model, and other things are "natural" to store in the DNS
model.  Some things can be easily located in DNS and not in LDAP, and
vice versa.

> a locator service but people are trying to make it a database.

I agree!  But I still want to see garbage (like certificates) stored
in DNS because they are vital when "locating" someone.  In a secure
world, knowing the address of someone isn't enough to contact someone.
The certificate is similar to addresses, in that it's required to
contact the remote entity.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 3 Dec 2000 20:41:30 -0800

>model.  Some things can be easily located in DNS and not in LDAP, and

But, as indexing doesn't work in LDAP globally, searching in LDAP 
(which you need for looking up names) doesn't work. This means that 
searching for information doesn't work regardless of whether you use 
LDAP or DNS.

So I don't agree that some things that doesn't work in DNS work in 
LDAP. Some thing (like finding information given the name of a 
person) doesn't work in either of the protocols.

That is my point.

    paf

--

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 3 Dec 2000 20:24:36 -0800

>Internet, worsened if you are relying on DNSsec. With LDAP, you are

Well, basically I am of course agreeing with you and all others on 
this list. Yes, I am an apps person, but I have been working with DNS 
long enough (since 87 or so) that I use exactly the arguments you do.

I just tried to in the beginning to this discussion explain why 
people which do _not_ understand how important stability of DNS is 
want to put more and more RR types into DNS.

To continue that discussion, I basically don't understand why you 
have to add code to generic DNS software just because you add an RR. 
I.e. adding a new RR type and a new schema in LDAP is basically the 
same thing. res_send etc handle the records just fine, and only the 
software which really need the information in the RR have to be able 
to change it.

Yes, of course you need to be able to enter the data in the primary 
DNS server, but that is something you have to do with LDAP and a new 
schema aswell.

It's all length-prefixed blocks of bits.

>However, it
>"ou=3D" makes no sense to me).

One should instead use the DC naming scheme (see RFC 2247).

>I am not

Sure!

>Is "Eva Fr=F6lich" a real person?

I hope so.

   paf

--

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Dec 2000 06:57:03 +0100

At 20:24 03/12/2000 -0800, Patrik F=E4ltstr=F6m wrote:
> >Is "Eva Fr=3DF6lich" a real person?
>
>I hope so.

while Eva Fr=3DF6lich is (AFAIK) an artifact of failed MIME decoding, Eva
Fr=F6lich would probably have a much better retort to this comment :-)

to put back some content:

LDAP searches at the moment make the server-to-ask part of the search
criteria, and one that is largely orthogonal to what you know about the
info you seek. Added to the rest of LDAP's problems, the result is not good.

DNS does not have search.

I suggest we move the directory discussion to the [email-masked]
list. It's nice and quiet and not LDAP specific.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Sun, 03 Dec 2000 22:28:15 -0800

Patrik Fältström said:
> ...

Because of domain name compression.  An RR containing compressed names
will be silently corrupted if it is transmitted as a mere block of
bits.  There is also a couple of other issues like the downcasing of
embedded domain names currently required for DNSSEC canonicalization.

draft-ietf-dnsext-unknown-rrs-00.txt is an attempt to address this.
-- 
Andreas Gustafsson, [email-masked]

---

From: Dennis Glatting <[email-masked]>
Date: Sun, 03 Dec 2000 23:24:42 -0800

Patrik F=E4ltstr=F6m wrote:
> =

> >software (server and client), and across all vendors, must be modified=

> >software complexity and error to a critical operating component of the=

> =

> =

> =

> =

Interesting  point. I was thinking existing implementation.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 04 Dec 2000 00:18:39 -0800

> searching for information doesn't work regardless of whether you use

It's not supposed to work. Federated namespaces are not easily searched.
Instead, you localize a search to a specific realm and hope for the best
from that. If you want global searching, write a catalog server to index
all of the data and search that. There is room for an ldap equivalent of
google, there are lots of first-run efforts out already (bigfoot, four11
and others were ldap searchable once).

Somebody could do the same thing with DNS even, BUT the important
distinction is that the DNS protocol doesn't provide for incomplete
searches. The inverse query allows you to search by value and type, but it
does not allow for incomplete value. Good luck finding a resolver which
can wring out an iquery as well. From this perspective searching in DNS
will not work using existing tools, while LDAP can be made to work.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Dec 2000 08:10:56 -0000

I have a web page on this issue: http://cr.yp.to/djbdns/newtypes.html

In short: There is no need for a protocol change. The standards already
make perfectly clear that DNS caches (and AXFR secondaries) must handle
unknown record types. The only problem is that one widespread DNS
implementation is ignoring the standards.

Andreas Gustafsson writes:
> An RR containing compressed names will be silently corrupted if it is
> transmitted as a mere block of bits.

The protocol does not allow that situation to occur in the first place.
Compression is forbidden in new record types. BIND used to screw this up
too, but it hasn't had a problem since version 8.1.2, right?

I strongly object to your draft-ietf-dnsext-unknown-rrs-00. We don't
need more disasters like http://www.cert.org/advisories/CA-2000-20.html.
Handling the compression allowed by the protocol---owner names, NS data,
CNAME data, PTR data, MX data, and SOA data---already takes way too much
code; adding more code to decompress bogus records is a really bad idea.

---Dan

---

From: [email-masked]
Date: Tue, 05 Dec 2000 01:40:37 +1100

> implementation is ignoring the standards.

	RFC 1034 and RFC 1035 are incomplete and badly worded w.r.t.
	treating new RR types as opaque data.  Even after correcting
	the wording to say that new RR types should be treated as
	opaque data they are still incomplete.

> Compression is forbidden in new record types.

	Not according to RFC 1034 and RFC 1035.  They actually allow
	compression in new types.  Not that I agree that it should be
	allowed just that it was.

> BIND used to screw this up

	Actually the server was only doing *less* than what RFC 1034 and
	RFC 1035 allowed it to do.  It was not compressing SRV rdata.  If
	it was still compressing (as earlier versions did) the bug would
	not have been triggered.  In fact it was treating the RDATA as
	opaque data, the only additional thing it did was to add the
	servers to the list of potential additional data to be added.

	draft-ietf-dnsext-unknown-rrs-00 doesn't want to add compression
	to new RRs.  It also doesn't want the server to have to know where
	domain names are in rdata hence the changes to DNSSEC in there.  

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

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 4 Dec 2000 11:15:09 -0800 (PST)

> unknown record types.

I don't think the following text in RFC1035 is particularly clear:

   Pointers can only be used for occurances of a domain name where the
   format is not class specific.  If this were not the case, a name server
   or resolver would be required to know the format of all RRs it handled.
   As yet, there are no such cases, but they may occur in future RDATA
   formats.

To me this seems to imply that domain names in future non-class-specific
types can safely compressed, which of course is incorrect.

> I strongly object to your draft-ietf-dnsext-unknown-rrs-00. [...]

draft-ietf-dnsext-unknown-rrs-00 does not require you to decompress
post-RFC1035 record types - it's a SHOULD, not a MUST.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Dec 2000 21:24:35 -0000

[email-masked] writes:
> compression in new types. 

You're not looking at the complete protocol specification. RFC 1123,
section 6.1.3.5, says ``compression must only be used for the contents
of WELL-KNOWN, class-independent RRs.'' (Emphasis added.)

The reason for such restrictions was already made clear in RFC 1035,
section 4.1.4: ``Pointers can only be used for ... If this were not the
case, a name server or [cache] would be required to know the format of
all RRs it handled.'' I agree that the ``...'' isn't broad enough, but
the rationale makes clear what to do.

The fundamental point is that the protocol is extensible. RFC 1035 says
that ``new data types ... should always be expected.'' RFC 1123 makes
this even more clear:

   A name server may acquire, via zone transfer, RRs that the server
   doesn't know how to convert to printable format. A [cache] can
   receive similar information as the result of queries. For proper
   operation, this data must be preserved ...

I realize that this isn't a capitalized MUST, but there's only one
reasonable interpretation of the protocol. BIND's behavior of destroying
unrecognized record types is not ``proper operation.'' BIND's behavior
of compressing new types (now fixed, right?) is indirectly prohibited,
because it doesn't interoperate with caches that do what RFC 1123 says.

> Not that I agree that it should be allowed just that it was.

No. The only compression allowed by the protocol is in owner names, NS
data, CNAME data, PTR data, MX data, and SOA data. My cache and AXFR
client do not decompress anything else. I object to your company's
attempts to portray this as a bad thing.

I'm not saying that decompression of other types should be prohibited by
the protocol. It doesn't affect legitimate packets; I understand that it
simplifies your code. But decompression of other types shouldn't be
_encouraged_. There's no reason that my cache should know about RP
packets and RT packets and AFSDB packets and so on.

---Dan