Subject: SRV records for SIP?

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Mar 2000 10:55:28 -0800 (PST)

draft-ietf-sip-dhcp-00.txt defines some new DHCP options.
One of them carry the FQDN to use when asking for SRV records
(which seems a little bit odd - I'd expect a fixed prefix like
_sip._tcp.<something> ??).

The other DHCP option tries to capture all of the content of 
the reply to a query for an SRV record.
The DHCP option doesn't contain anything like a DNS TTL for this info.
Thus I'd appreciate if somebody could give this document a careful read
from the DNS perspective.

   Erik

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Gautam Nair <[email-masked]>
Date: Mon, 20 Mar 2000 14:59:02 -0500

In the first option we defined, we send a DNS string to the client. This
DNS string could either be an SRV name such as sip.udp.cs.columbia.edu *or*
it could be an A record string such as marta.cs.columbia.edu. It is
obviously more desireable to use the SRV record. The local DHCP
administrator can configure the DHCP server to send either the SRV or the A
record string according to the DNS capabilities of the DNS server and the
SIP client. The client should however first attempt to use the string in an
SRV query if it is SRV cognizant. I do not think there is any harm in
sending an A record string in an SRV query other than the fact that it will
fail and a second attempt (making the A record query) will have to be made.

The second option that we defined is an attempt to replicate the reply to
an SRV query. This is done with some embedded systems, that do not
implement DNS, in mind. Since all the IP addresses and priority/weightage
information is available, a DNS query is not required.
For the DNS TTL type of info: In this case, it is expected that the DHCP
administrator would make sure that the IP addresses are up to date, so TTL
is not too important here.

Regards,
Gautam.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Mar 2000 12:28:03 -0800 (PST)

[Resent with correct address.]

   Erik

---

From: Robert Elz <[email-masked]>
Date: Tue, 21 Mar 2000 12:55:36 +1100

Date:        Mon, 20 Mar 2000 12:28:03 -0800 (PST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <Roam.SIMC.2.0.6.953584083.22389.nordmark@jurassic>

  | One of them carry the FQDN to use when asking for SRV records
  | (which seems a little bit odd - I'd expect a fixed prefix like
  | _sip._tcp.<something> ??).

I don't mind that .. if anything building the magic knowledge into
less places is probably an advantage, the extra few octets that appear
in the DHCP reply (even given that DHCP packets are, like the DNS, one
of those places where space is at a premium) shouldn't matter.

However, just like every new place where DNS names are embedded in
binary protocols, I don't believe that using the ascii form of the
DNS name benefits anyone - embed the thing using DNS binary form.
If that's done, then it is certain that a max length of 255 octets
is sufficient (so the one byte length code works) - in textual form
that is no longer going to cover all the cases, some sequences need
extra bytes to act as escapes.   With the (possible) forthcoming use of
more international domain names, this is likely to become much
more important (as perhaps will names that come closer to needing
the full 255 octets than those we typically see today).

For the kind of application that is being suggested here, one which
may not even have a DNS client, this is likely to be an even bigger
win, as it allows DNS support to be added without the need to have
a hostname parser - the string returned from the DHCP option could
be copied literally into the question section of a DNS packet, making
the DNS support that much cheaper to add.

  | The other DHCP option tries to capture all of the content of 
  | the reply to a query for an SRV record.

That part is totally brain dead.   Anything that can cope with DHCP
ought to be able to cope with DNS as well, the two are very similar
in their requirements - both use UDP, so both need internal retransmit
timers and backoffs, both use a binary packet format, ...

  | The DHCP option doesn't contain anything like a DNS TTL for this info.

While that would be trivial to add, and absolutely must be added anywhere
that addresses are being passed around.  With DHCP the server could
perhaps mitigate this to some extent by arranging for the lease on the
client's IP address to be no longer than the minimum TTL of all the
addresses in the reply - most other addresses in DHCP replies have no
TTLs either - but this ought to be stated somewhere, and further, someone
needs to work out how all of this functions with DHCPINFORM requests,
where no leasing info is supplied.

But just assuming that an address is valid when it is returned, and
that that obviates the need for a TTL totally misses the point of the
TTL, which is as a guarantee (promise) of how long into the future the
address will remain valid.   If no TTL were to be included, then the
doc would need to say "for immediate consumption, another DHCP query
must be performed if the address is to be reused more than a second later
than when the first DHCP reply is received".

However, I don't believe this is a good match to the DHCP protocol, or
DHCP servers - where DNS servers expect to be asked the same questions
over and over, DHCP servers typiclaly don't - the protocol generally
expects the clients to go away for hours after a query has been answered.
This manifests itself in many ways - not the least being the habbit of
DHCP servers to log every query received, and every answer sent.

However, perhaps even worse than that is that this option is so IPv4
centric.  I know that DHCPv6 is a different protocol, but it seems to
me that defining new options now, that can't simply be used in both,
is a grave mistake - anything new ought be compatible with both the v4
and v6 versions of DHCP.    Here, as for some obscure reason the address
(uniquely I belive amongst all DHCP options) is being returned as a
dotted quad (ie: in ascii instead of binary), supporting IPv6 would
be fairly easy - just allow it's ascii form to be returned as well.
However the doc explicitly states that the address is a dotted quad.
That means IPv4 only.

More trivially...

        wt: This field is used by the load balancing mechanism.  When
             selecting a target host among those that have the same
             priority, the chance of trying this one first SHOULD be
             proportional to its weight. The range of this number is 1-
             65535. Domain administrators are urged to use Weight 0 when
             there isn't any load balancing to do, to make the option
             easier to read for humans (less noisy).

which just duplicates the language from an old SRV draft - language
which was one of the overhauls before the doc was finished,
not least because it is hard to see how to specify "Weight 0" (as
directed) in a field which has a range of 1-65535.

I would simply drop this option - require use of the DNS, and don't
attempt to pervert the DHCP protocol into becoming an el-cheapo DNS
protocol in disguise.   DHCP will already tell the client the address
of the DNS server to use, sending an extra DNS query cannot realistically
be enough overhead (in code size, or in execution time) to really
matter (and as far as time goes, especially once it is realised that
the DHCP server is often going to have to do the DNS query to get the
information anyway - ie: you cannot assume that the delay won't exist).

Just return the name to be used in the DNS SRV request, and return that
in DNS encoded binary form (ie: an overall length - 1..255 followed
by a series of one or more <length><label> pairs, where each length is
1-63 except the last, which is length 0, with no following label).

It probably wouodn't hurt to include explicit advice as to whether or
not a SRV query is to be attempted, rather than expecting the client
to just do the SRV, and if that fails, do an A (or any address type) query.
Otherise I'd expect that clients will be tempte dto try the A query
first, on the assumption that that is what most users will actually
use, and so avoid the RTT that the SRV query would add.

Of course, the other option would be to mandate the SRV query, and
prohibit doing an address query on the results of this option - actually
require people to use SRV records for this purpose.

kre

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Mar 2000 21:51:45 -0500

Thanks for your valuable comments.

> of those places where space is at a premium) shouldn't matter.

Besides the space, there's one reason not to include the protocol
(tcp/udp), in that clients may only speak one, but servers generally
speak both TCP and UDP. This would mean that all advertisements have to
include two strings, but the client really knows which one it needs.
This is probably a minor advantage, so I don't much care one way or the
other.

> the full 255 octets than those we typically see today).

I have one concern with the DNS format, namely that it won't allow use
of existing DHCP servers, which only allow strings (or list of IPv4
addresses) as values. We'd have to wait until all the servers support
this format.

My current inclination is to keep things simple by only having something
like

A some.host.domain or 
SRV some.host.domain

(or the equivalent binary version) and drop the SRV replication.
Comments?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs