Subject: RE: DNS SRV question (was Re: please post updated draft)

From: "Levon Esibov (Exchange)" <[email-masked]>
Date: Thu, 21 Oct 1999 15:10:39 -0700

> Or is this meant to refer to a *public* specification?  If so, then
> how does that jibe with the "locally defined" services mentioned
> earlier?
> 
You correction is taken. I'll remove the "Only locally defined services may
be named locally." from the text if there are no objections.
Thanks
Levon.

---

From: David Shaw <[email-masked]>
Date: Tue, 26 Oct 1999 11:16:29 -0400

> be named locally." from the text if there are no objections.

Oh boy, that wasn't my intent at all.  I think that locally defined
services should *stay* in the specification.

I was hoping to remove the statement "Service SRV records SHOULD NOT
be used in the absence of such specification."  It's completely
unenforceable, and anyone who wants to use SRV records for their own
use (presumably one that has no applicability to the Internet at
large) will have problems if they want to remain RFC compliant.

What is so wrong with just making it clear that IF you are using a
service type assigned via STD 2 you MUST use the protocol specified
for that service type?

If there is concern about people using a service type inappropriately
and/or colliding with a non-local service type, why not declare that
all local service types must start with a double underscore, rather
than the single underscore that STD 2 types do.
(i.e. "__mylocalservicetype").  They will then be protected against
DNS labels that occur in nature, as well as those that occur in STD 2.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Alan Barrett <[email-masked]>
Date: Wed, 27 Oct 1999 13:47:07 +0200 (SAST)

> large) will have problems if they want to remain RFC compliant.

I'd also prefer to see that statement removed, but I think it's less
damaging than you seem to believe.

"SHOULD" just means "think carefully before violating this
recommendation".  If, after careful thought, you decide to go ahead and
use SRV records in some locally defined way (e.g. for telnet), then you
can still be RFC compliant.

--apb (Alan Barrett)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 28 Oct 1999 00:40:59 +0200

>can still be RFC compliant.

one reason for the statement originally (I think) was that some protocols 
get badly broken, or have funny security risks, when you add the ability to 
redirect their ports by munging the DNS.

And protocols that carry state across commms sessions (NFS with lock 
daemons come to mind) can probably land you in serious deep trouble if your 
DNS resolver switches you to a diferent host in the middle of a transaction 
- it will work for the "simple redirect" case and in a lot of the 
load-sharing cases, and probably in 99.5% of cluster implementations, but 
anyone who knows the protocol at a deeper level will go "OOPS - will fail 
if your implementation does......"

It would be VERY nice to see someone attempt to push through an RFC saying 
"For the following 160 protocols, we have checked and found no issues that 
would make trouble with finding them using DNS SRV; the following 3 are not 
so simple, so don't do it for them".

I want this document to ship.....

                    Harald

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]