Subject: 2052bis miscellany

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Nov 1998 22:51:45 -0000

I have a few questions about draft-ietf-dnsind-rfc2052bis-01.txt. My
apologies if these have been answered before.

1. Is there any way to specify more than one protocol that can be used
for a service?

For example, there are several competing protocols for injecting mail
into an ISP's outgoing mail queue. Right now the user has to manually
tell his MUA which protocol to use. Can a SRV client inspect the port
number and choose a protocol accordingly?

2. Is there any way to point a SRV record directly at an IP address?
This would save cache space, reduce traffic, and add convenience for
system administrators.

Experience shows that thousands of people put IP addresses into MX
records, even though MX records are supposed to be domain names. Is
there some reason that this is not expected to happen with SRV?

3. Is IETF taking over all DNS labels that start with underscores? If
so, what are the new rules for registering labels other than _tcp and
_udp? What happens if people are already using leading underscores in MX
records?

4. What exactly is the algorithm to use weights? ``Probability Weight''
is unclear. How is weight 0 interpreted if there are also nonzero
weights? Wouldn't weights be easier to implement if they were defined
somewhat differently?

I don't understand the comment about weight 0 being ``less noisy'' for
humans than, say, 65535. Is there some reason that the textual format
can't be defined so that there is a pleasant abbreviation for the most
common weight? Is there supposed to be some benefit in having every
client handle 0 specially?

The draft says that a client ``SHOULD'' use weight but ``MAY'' use other
means to choose hosts. What exactly does this mean? Is a SRV client
allowed to completely ignore weight in favor of its knowledge, or its
guesses, about network topology? What is a client supposed to do?

---Dan

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 22 Nov 1998 22:08:07 -0800

> apologies if these have been answered before.

no apology needed in this case -- these are relatively new questions.

> number and choose a protocol accordingly?

if someone were to write a draft specifying that MUA's should use SRV
RR's for this, it could certainly be done.  it was not the intent of
the SRV RR but what you're suggestion would work.  note that SRV's
specification is principally of its RDATA format and the uses one would
make of a SRV RRset if one had already chosen the application protocol.

> there some reason that this is not expected to happen with SRV?

there are no provisions for this, or plans.  while we could allow the
RDATA's "target" name to be a decimal-ascii IP address, this would be
the first RR whose RDATA was specified in that way and it would 
represent a significant departure from the historical practice of AAAA
and A RR's.  since the IPng people are now specifying something they're
calling A6 which is actually a compound value, i don't think we ought
to duplicate all of the compound logic of that inside SRV.  not even as
an option.  when there's more than one way to do something, interoperability
testing is just that much harder.

> _udp? What happens if people are already using leading underscores in MX

hostnames and mailnames already can't start with _.  while no general
strategy has been outlined for disrecommending leading _'s in domain names
overall, i think 2052bis could be used to in place of a more formal and
more specific discommendation of leading _'s in any non-SRV domain names.

> weights? Wouldn't weights be easier to implement if they were defined

this looks like an error in the specification.  since weight 0 is allowed,
the range should be specified as 0-65535 rather than 1-65535.  as written,
the specification implies that an RRset with both weight 0 and weight non-
zero would be both invalid and undefined.

> client handle 0 specially?

i agree with this analysis.  i don't know if this is grounds for another
revision in the document before PS.

> means to choose hosts. What exactly does this mean? 

it means that if a client knows the load average of the hosts and thinks
that this is a better way of choosing one vs. another, it would not be
a violation of the SRV specification to make the choice in that manner.
this was our somewhat oblique way to avoid overspecification.

>                                                      Is a SRV client

sure.

---

From: Robert Elz <[email-masked]>
Date: Mon, 23 Nov 1998 21:22:17 +1100

Date:        22 Nov 1998 22:51:45 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | 1. Is there any way to specify more than one protocol that can be used
  | for a service?

As I understand the intent from previous explanations, the intent is that
applications (almost, but not quite, protocols) that intend to use SRV should
indicate just how the SRV record is to be used.   I see no reason why that
might not in some cases include specifying the use of a different protocol
based upon the port number that the SRV contains.   I'm not sure that would be
a good idea, but I see nothing in 2052bis that would prohibit it.

Should there be text in the doc that makes this intent clear?

  | 2. Is there any way to point a SRV record directly at an IP address?

No.

That IP addresses work for MX records (and a few other bizarre places) is
a side effect of either (take your pick) a bug in a library routine used by
common applications that use MX records, or the use by those applications of
an inappropriate library routine.

In any case, you can't put an IP address in an MX record, what some do is
enter a domain name that has the form of a dotted quad representation of
an IP address.   Expecting that to work will break as soon as someone starts
defining top level domains with all digit values (and with values in the range
of 1-255).   I kind of think we ought create a few of those (say 1, 17, 67,
169) just on principle.

Any time you would rationally be willing to put an IP address in one of
those records (that is, when the actual IP address is under your control,
so you aren't subject to someone else's whim changing it) your server will
be returning the associated A record in the additional server section of an
answer, so the supposed traffic saving is negligible.   I also rather suspect
that any convenience saving is illusory - it seems easier when you do it
initially, but in the long term costs more than simply using the name.

  | 3. Is IETF taking over all DNS labels that start with underscores?

No, the underscores are just an attempt to minimise clashes with existing
names.   Aside from that, they are not magic.

  | 4. What exactly is the algorithm to use weights? ``Probability Weight''
  | is unclear.

Would you like to suggest some text to help clarify this?

  | The draft says that a client ``SHOULD'' use weight but ``MAY'' use other
  | means to choose hosts. What exactly does this mean?

That is fairly common IETF style - it suggests that in the absence of any
particular rationale, the weights should be used, but if there is some
particular reason not to, it is OK to use some other method.   Typically,
the particular reason will be explicit user configuration, though I suppose
that other possibilities exist.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Nov 1998 00:37:58 +1100

Date:        Sun, 22 Nov 1998 22:08:07 -0800
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | hostnames and mailnames already can't start with _.

The value (domain name in the RDATA) of an MX record can though.

  | i agree with this analysis.  i don't know if this is grounds for another
  | revision in the document before PS.

My guess is that we're going to need one more before an RFC is published.
However, since we're now in the I-D dead period, and as we're basically done,
I intend to request an IETF last call on the current doc.

Once that has completed (after the Orlando IETF) we will combine any more
last call comments, with those received now, and create a final version for
publication.   That's common practice.   None of the comments we have seen
so far calls for more than a clarification of the current text I believe, so
we would not need a new IETF last call (on the other hand, if there are any
defects of a more major nature, it would be nice to know of them now, so we
can avoid wasting time with unnecessary IETF last calls).

kre

---

From: [email-masked]
Date: Tue, 24 Nov 1998 08:22:36 +1100

> The value (domain name in the RDATA) of an MX record can though.

	Robert,
		you keep saying this but RFC 974 says that this is a host
	name. "Each MX matches a domain name with two pieces of data, a
	preference value (an unsigned 16-bit integer), and the name of a
	host." 

	Please quote where this restriction has been relaxed.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Nov 1998 04:25:34 -0000

Paul A Vixie writes:
> i don't think we ought to duplicate all of the compound logic of that
> inside SRV.  not even as an option.

There are ways to allow IP addresses without providing any special
support for them in the SRV spec.

For example, you could set up a new "a.int." domain with

   247.178.193.131.a.int. IN A 131.193.178.247

for every address. Improvement #1: Use a single binary label with bytes
131,193,178,247 instead of four ASCII labels. Improvement #2: Teach BIND
to handle a.int locally.

This would eliminate the need to provide additional records in the SRV
response. It could easily save 20 bytes per SRV.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Nov 1998 21:13:00 +1100

Date:        Tue, 24 Nov 1998 08:22:36 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	Please quote where this restriction has been relaxed.

It never existed.

You're reading too much into 974.   What 974 does is specify the way that
MX records are to be used.   It does not define them.   It uses "host"
rather loosely (meaning in this context the thing on which a mailer runs),
and certainly doesn't refer (even slightly) to 952 or anything else to
imply any naming syntax rules.

MX was defined in 973, the specification there was...

	The format of the MX RR
	is a 16 bit preference value followed by a domain name.

Note "domain name", not "host" name.    That is now in 1035 as ...

EXCHANGE        A <domain-name> which specifies a host willing to act as
                a mail exchange for the owner name.

1035 (as I think we have been through before, and 2181 re-iterated)
specifies no character set syntax on domain names (other than the upper case
ascii == lower case ascii bit).  No special rules are specified in 1035
(nor were then in 973) for the domain name which happens to be an MX exchange.

Further, there is absolutely no reason for there to be any required syntax
(beyond that required for domain names).   The MX EXCHANGE domain name
serves purely as an indirection mechanism inside the DNS - it allows the
MX record to indirectly refer to the address of the mail server, rather than
sticking addresses inside the MX record directly.   That's its only purpose.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Nov 1998 20:47:50 +1100

Date:        24 Nov 1998 04:25:34 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Improvement #1: Use a single binary label with bytes
  | 131,193,178,247 instead of four ASCII labels.

Which, of course, unless use of an address were to be the only option, would
require some extra indicator to determine whether numbers or names were being
represented.

This would, hoever, have gross negative operational impacts, especially
when it comes to issue like dynamic DNS, and automatic renumbering, etc.

While a host (or its dhcp server or equivalent) might reasonably expect to
know its host name(s) and hence be able to trivially find any A, AAAA, or A6
records that it owns, and so be able (assuming the necessary authority) to
update those whenever its address is altered, I think it is a bit much for
it to expect to know all of the SRV (and by implication, MX) records that
might just happen to reference its old address and update those as well (for
which it is much less likely to have the authority).

The extra indirection certainly has costs, the benefits suffice.

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 24 Nov 1998 09:02:43 -0600

> [...]

Perhaps so, but there are many DNS fronts on which we may expect
to bump into the current length limits soon.  It would be far
better to solve the length limit directly than to attack each
instance piecemeal.
					Matt

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Nov 1998 20:26:10 -0000

Robert Elz writes:
> I think it is a bit much for it to expect to know all of the SRV (and by
> implication, MX) records that might just happen to reference its old
> address

My question was whether people are _allowed_ to use IP addresses.  Our
experience with MX indicates that many people want to do this.

You're talking about the administrative benefits of _allowing_ people to
use names. Did someone propose eliminating that option?

(It is, in fact, possible to achieve the same benefits even if everyone
uses numbers. You put names into your zone files as usual; the _server_
then figures out the addresses and automatically keeps them up to date.)

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 25 Nov 1998 15:12:01 +1100

Date:        24 Nov 1998 20:26:10 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | My question was whether people are _allowed_ to use IP addresses.  Our
  | experience with MX indicates that many people want to do this.

What I've seen is that many people do it by accident.   Personally I
have not seen a case where anyone has ever given a convincing reason
for actually wanting to use a number (anone who has actually done it I mean)
other than "I didn't know that wasn't right").

If mailers actually refused to deliver to such nonsense, instead of
(accidentally) accepting it, no-one would be using IP addresses (that
is, domain names that have the appearance of a dotted quad).

  | You're talking about the administrative benefits of _allowing_ people to
  | use names.

Partly.

But not exclusively.  If there might be anyone, anywhere, legitimately
using my IP address in an MX record, and I need to renumber my mail
server, then there's a real problem.   If the only place my address is
going to appear is in my A record, then I can change that with much more
confidence that the world (or that part of it which obeys the rules
anyway) is not going to break.

I need to *know* that the address is not in use elsewhere.

  | (It is, in fact, possible to achieve the same benefits even if everyone
  | uses numbers. You put names into your zone files as usual; the _server_
  | then figures out the addresses and automatically keeps them up to date.)

Yes, things could be done that way, and there are tradeoffs, but that would
be a fundamental change to the way the DNS works now (both MX and SRV records
are actually implemented and in use), and we're not even considering making
such a fundamental change - nor could we rationally if we wanted to.

In an earlier message, you described some ambiguity (lack or clarity, or
precision, or something) with one part in particular of 2052bis.   Rather
than wasting everyone's efforts in debating this point, do you think you
could assist the WG in getting 2052bis finished, and in the best possible
form, by actually sending some suggested wording for improving that
section (the one related to interpreting the weights, and "probabilistic")?

kre

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 24 Nov 1998 23:43:57 -0500

I think this is going way too far.  I urge simplicity.  A few extra
bytes in cases where additional complexity in servers could have
permitted optimization is not worth it.

Donald

From:  "D. J. Bernstein" <[email-masked]>
Date:  24 Nov 1998 20:26:10 -0000
Message-ID:  <[email-masked]>
To:  [email-masked]
References:  <[email-masked]> <[email-masked]>

---

From: [email-masked] (Pyda Srisuresh)
Date: Fri, 27 Nov 1998 15:30:03 -0800 (PST)

Folks,

I havent been following all the arguments on the subject of using IP 
addresses for MX records. But, I just wanted to add my few cents here.

DNS MX record is extensively used by NAT private domains, that have
a private domain mail server. Using a host-name in RDATA is a requirement
to support  mail server facility within the private domains. DNS name 
provides the necessary glue for NAT private enterprises to operate
between different routing realms (i.e., private and external domains).

I agree with the observation by Robert that any use of IP address in an
MX record must be by accident and cannot imagine any design benefits.

cheers,
suresh

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 1998 21:16:21 -0000

> Would you like to suggest some text to help clarify this?

I imagine that the intent is to handle weights w[1], w[2], ..., w[n]
as follows:

   (1) Compute s = w[1] + w[2] + ... + w[n]. Abort unless s > 0.
   (2) Generate a random number r from 1 through s.
   (3) Find the smallest i for which r <= w[1] + w[2] + ... + w[i].
   (4) Use record i.
   (5) Copy record n to record i. Decrease n and repeat.

This algorithm naturally accepts, and ignores, records with weight 0. I
don't see any reason for a more complicated procedure.

Some people will (deliberately or accidentally) use 16-bit arithmetic
for s, so I suggest requiring that weights add up to at most 32767.

---Dan