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

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Oct 1999 13:49:06 -0400

> Can you please describe one scenario where performing a DNS SRV lookup
> for an entry that does not exist may lead to operational problems?

Why are my DNS servers being pounded with queries for non-existant
names (e.g., http servers)?

Thomas

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 27 Oct 99 13:32:46 EDT

> Also, think about this a bit. For existing deployed services, having
> some random client decide it wants to do SRV lookups for a name can
> lead to operational problems at sites that aren't using them (e.g., if
> clients at one site get upgraded but those clients make use of servers
> elsewhere not administered by the same authority as those
> clients). And why should they? No standard says they should support
> SRVs for their particular service, and their deployed infrastrucure
> may not even support them. The point of documenting this is so some
> thought goes into how to deal with transition issues between non-SRV
> usage and SRV usage and that any application-specific issues get dealt
> with appropriately.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 27 Oct 1999 14:08:43 -0700

> names (e.g., http servers)?

because RFC 2308 has not been widely enough deployed. that's not a SRV problem.
in fact it's a problem we already have, without SRV.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Oct 1999 17:17:49 -0400

> because RFC 2308 has not been widely enough deployed. that's not a SRV
> problem.  in fact it's a problem we already have, without SRV.

But SRV could make this even worse. Much worse, in fact, if http was
the example. Is that not a concern?

Thomas

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 27 Oct 1999 16:00:37 -0500

> names (e.g., http servers)?

Umm, negative caching to the rescue?

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 27 Oct 1999 18:37:59 -0400

> names (e.g., http servers)?

that's what negative caching is for.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Oct 1999 17:11:48 -0400

> Umm, negative caching to the rescue?

One would hope so. But how widely is it deployed today? Can we rule
this out as an issue at this time? I don't know.

It seems like we are just starting to get experience with deploying
SRV. We want to continue moving in that direction. But that doesn't
mean we want to give a green light to allowing implementations to just
start using SRV for everything. That seems premature. In another
couple of years, we'll have more experience and everything is up for
reevaluation.

An earlier poster I think said it well in pointing out that SHOULD NOT
means think carefully before doing, but is not an outright ban. Do
folks really think that text is too strong?

Thomas

---

From: Jerry Scharf <[email-masked]>
Date: Wed, 27 Oct 1999 15:35:43 -0700 (PDT)

> names (e.g., http servers)?

And how is this any different than a sendmail server looking for MX
records that users have chosen not to include? People will look it up,
find out it's a record type they haven't put in and go on with their
lives.

jerry

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 27 Oct 1999 14:31:33 -0700

> the example.

not so.  the primary http client in use on the internet today has NO dns cache
at all, or if it has one it has no negative caching support and does not listen
to the dns TTL's.  this platform depends on a local caching dns proxy, which
must in turn implement RFC 2308 or at least the subset of negative dns caching
described in RFC 1034 or else all hell already breaks loose, with or without
SRV.

> Is that not a concern?

compared to DNAME, A6, KEY, and SIG: no.

also: i want to explain a comment i made earlier.  i said "there are some
things the IETF just can't do."  i do not mean this as a slam against thomas
or the current IESG -- these are all good people doing the best work they can.
however, the primary purpose of the IETF is to filter out bad ideas while
trying to stimulate the progress of good ones.  unfortunately for all of us,
anything representing farsighted vision will almost precisely match the profile
of a bad idea.  there is no way the IETF could permit SRV as it was originally
designed without losing its capability for killing off things like IPv8.  i
regret that i didn't realize that a lot earlier, since i yelled at folks who
were just doing their jobs.  my recommendation is: do "the vision thing"
outside the IETF, and plan on writing a BCP whenever a successful vision needs
interoperability and/or publication for its resulting network protocols.

---

From: Rob Austein <[email-masked]>
Date: Wed, 27 Oct 1999 20:31:34 -0400

Date: Wed, 27 Oct 1999 17:11:48 -0400
   From: Thomas Narten <[email-masked]>

Either:

(a) Negative caching, which has already started being deployed,
    will be in place before increased load from SRV becomes a serious
    issue, or

(b) Demand for SRV is so significant that deployment will outstrip
    demand for negative caching, in which case a clause saying "any
    implementation that includes SRV must also implement negative
    caching" might be appropriate, but delaying SRV would not be.

Either way, I see no argument for holding up the document here.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 27 Oct 1999 23:54:37 -0400

> the example. Is that not a concern?

There's at most a doubling in query rate.  you look for SRV, miss,
look for A, miss again, instead of the current look for A, miss. 

How is this "much worse"?

Are DNS misses that big of a load on nameservers?

I don't see why this is so terrible to require text in teh document
effectively scaring people away from experimenting with what appears
to be a valuable extension.

						- Bill