Changing the subject line to keep up with the current topic.
At 12:34 AM 6/21/2005 +0000, John Levine wrote:
I don't see the point in making that restriction. You'll get all the SRV
records in one query anyway; all you have to do is deal with them if
more than one exists. That really isn't hard, and it's the expected
normal behaviour of DNS records. I see no reason to deviate from that.
But you have to loop through them to handle the A record that each can
point to. This changes the number of lookups from 2 to N+1, where N
is the number of SRV records. Since SRV records are pretty small, you
could fit 50 of them into a UDP DNS packet without any trouble, and I
think that a scheme that can require 50 lookups where people are
expecting 2 would be bad.
I agree. We have to think about the worst case, because that is exactly
what abusers will set up.
I'm not saying that the extra complexity of multiple SRV will break
this camel's back, but you'll notice that it already encouraged
someone to propose adding yet more cruft to describe IP ranges, to
which the answer is good lord, no. That's both for complexity reasons
and because the intention of CSV is to have a CSV record per client
machine in preference to an omnibus mess that covers hundreds or
thousands of them. I really think that it is to our advantage to
keep CSV as simple as possible, and I just don't see that multiple
SRV offers important utility that's worth the performance hit of
going from O(1) to O(N).
The complexity we should look at is not the number of IPs, but the number
of DNS queries. The ideal method would allow admins to list as many IPs as
they want, as long as the list fits in one DNS record.
Even an extremely large domain, like the example I gave, could arrange
their servers so as to list them all in one record. Am I right that the
caching of this record would save a lot of DNS queries?
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *