On Fri, Oct 17, 2003 at 03:33:22AM -0400, Eric S. Raymond wrote:
|
| THE BIG ONE...the hack of using specially named subdomains and TXT has got to
| go. I can't support that. It's unclean in a way that I feel certain
| will get us in deep doo-doo someday. There are at least two bad
| effects:
|
| 1. It muddles together host-namespace information (which is the only thing
| that ought to be to the left of IN) with attribute information (which is
| the only thing that ought to be over on the right).
This is absolutely true.
| 2. It hijacks TXT. TXT is intended to be a comment attribute.
http://www.faqs.org/rfcs/rfc1035.html
3.3.14. TXT RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TXT-DATA One or more <character-string>s.
TXT RRs are used to hold descriptive text. The semantics of the text
depends on the domain where it is found.
| I strongly urge that the proposal be modified to use the obsolete RR
| types MD and MF from RFC1035.
But I concede the point. It bothers me also; we are not using DNS as it
was designed.
Let's take a closer look at SRV records before we fall back on MD / MF.
The weird thing is that we're not looking up a service, in the sense
that http is a service provided by a web server on a port. The "service"
we're looking for is entirely in DNS. So a number of the fields in the
SRV records won't make sense.
http://www.faqs.org/rfcs/rfc2782.html: DNS SRV
Abstract
This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.
Overview and rationale
Currently, one must either know the exact address of a server to
contact it, or broadcast a question.
The SRV RR allows administrators to use several servers for a single
domain, to move services from host to host with little fuss, and to
designate some hosts as primary servers for a service and others as
backups.
Clients ask for a specific service/protocol for a specific domain
(the word domain is used here in the strict RFC 1034 sense), and get
back the names of any available servers.
The same people who say "TXT is for comments!" will now say "SRV is for
servers and services!"
What we really need is our own RR type, and I would love to have one,
but getting a new RRtype published runs counter to our goal of fast
widespread adoption. I would like to get some input from a DNS WG about
how long it will take to get a new RRtype approved, and whether domains
will need to upgrade their nameservers to work with the new RRtype. I
know tinydns lets you specify any RRtype you want using a ":" line.
All this trouble with RRtypes strikes me as the static-IP -> DHCP ->
Rendezvous pattern all over again, but we're still at the static-IP
stage.
One could argue that TXT is tempting simply because DNS failed to leave
in any other easy-to-specify free-form field, and so the failing is on
the DNS end of things, not ours.
How about we use TXT for now and publish a new RRtype in the future?
Pollution of the DNS is a Very Bad Thing, but so is spam, and we have to
make tradeoffs.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡