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

[Patrik Fältström <paf@cisco.com>]

At 09.57 -0800 00-12-03, Dennis Glatting wrote:
>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.

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

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

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

Sure!

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

I hope so.

   paf



-- 


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.