Subject: DNS usage in application protocols

From: Greg Hudson <[email-masked]>
Date: Wed, 23 Aug 2000 21:19:13 -0400

Hi.  The following text appears in section 5 of
draft-ietf-drums-smtpupd-12.txt, regarding MX hostnames with multiple
A records:

	The destination host (perhaps taken from the preferred MX
	record) may be multihomed, in which case the domain name
	resolver will return a list of alternative IP addresses.  It
	is the responsibility of the domain name resolver interface to
	have ordered this list by decreasing preference if necessary,
	and SMTP MUST try them in the order presented.

My DNS background suggests that this "MUST try them in the order
presented" requirement is misguided; order of DNS records is not
supposed to be important.  The text has been copied (with s/MX/SRV/)
by a draft relevant to the IMPP group, so I'm concerned about a faulty
meme propagating.

Can people in this group comment on whether I'm off my rocker?  I
can't imagine a client wanting to tamper with the order of records
returned by a resolver, but if for some odd reason it does want to
(say, it happens to have some network map information, or a cached
indication of which A record worked last time), I don't see why it
should be a violation the standard.

Thanks.

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 25 Aug 2000 01:16:06 +1000

Date:        Wed, 23 Aug 2000 21:19:13 -0400
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Can people in this group comment on whether I'm off my rocker?  I
  | can't imagine a client wanting to tamper with the order of records
  | returned by a resolver, but if for some odd reason it does want to
  | (say, it happens to have some network map information, or a cached
  | indication of which A record worked last time), I don't see why it
  | should be a violation the standard.

No, the MUST seems overboard.   It should probably say "unless other
information available suggests that a different order is to be preferred".

That is, by default, lacking any knowledge about the addresses, it should
be assuming that the resolver has been configured to return them in a rational
order, but if it knows that one is down, and another works, I think it
might be possible to skip the known down one (provided it gets tried again
from time to time).

I have used this kind of thing when the first address is a local one, that
is cheap to access, and the second is an alternate one, accessed via external
paths - I'd actually prefer the cheap one to be tried first every time, no
matter how often it was down before, before using the other (ie: agreeing
with the MUST) but there are other situations when that wouldn't be needed
(eg: someone from a remote site sending - to them either address looks just
the same, it makes no difference which they use).

kre

---

From: Terry Lambert <[email-masked]>
Date: Thu, 24 Aug 2000 09:39:12 -0700

Greg Hudson wrote:
> supposed to be important.

Do not confuse the resolver interface with the DNS itself.

The intent of this, from my reading, is to insure that
lower MX weights MUST be used in preference to higher
MX weights.

In sendmail, for example, the "resolver interface" that
does this is technically part of the code that comes with
sendmail.

Perhaps it is the intent of the authors to specify that,
rather than putting MX weight sorting in every application
implementing the SMTP protocol, that the code be implemented
once in the system resolver library.

I'd actually argue in favor of this, since I could see a
day when SMTP could switch from MX to SRV records by
trying SRV first, and only trying MX for backward
compatability with legacy DNS systems (i.e. I can see MX
being deprecated but not disallowed).  The switchover
would be accomplished by replacing the resolver out from
under the applciations.

As far as this being onerous on DNS, again, we need to
avoid confusing the resolver interface with the DNS.

I think that it is reasonable that, if the DNS group
perpetuates MX's that lookups on MX's be ordered, as
returned from the resolver interface.

What do SRV records do?  It's been a while since I've
looked (sorry, I should be more up on SRV records, but
I've got a lot vying for my attention right now).

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: Greg Hudson <[email-masked]>
Date: Thu, 24 Aug 2000 12:44:10 -0400

> Do not confuse the resolver interface with the DNS itself.

Understood, but the resolver has no information from the DNS with
which to order A records.

> The intent of this, from my reading, is to insure that lower MX
> weights MUST be used in preference to higher MX weights.

No, that would be the intent of the previous paragraph.  When I said
the paragraph was about MX hosts with multiple A records, I really
meant it.

---

From: Terry Lambert <[email-masked]>
Date: Thu, 24 Aug 2000 10:36:22 -0700

> the paragraph was about MX hosts with multiple A records, I really

Mea culpa.

I think I can defend that position even better, though.

I think the idea is that the resolver might have preferences
based on information not available to the MTA.

For example, the resolver may know the BGP hop distance
to each of these hosts, and order them in that order.

I think that we can restate this as saying that the SMTP
MTA MUST attempt them in the order presented by the
resolver.

Again, I think there's some leeway as to where the resolver
interface is located.

On the other hand, I would not object to some clarifying
language, such as:

  and SMTP MUST try them in the order presented [when attempting
  to make a conection].

Does this make more sense?

Alternately, one could predicate the "...and SMTP MUST..." on
the "...if necessary,...", but I don't see how that information
could be communicated across the interfaces without a lot of
work.

I agree that there's an ambiguity that could result in
people believing that this could prohibit connection
caching.

Maybe the intent was to provide for a resolver based
software version of a net rediretor -- if so, the idea
is ill-advised.

PS: I still believe the MX weight based sorting should take
place in the resolver, based on the duplication of code
argument, and that the resolver should be resonsible for
presenting the data this way for the MX/SRV migration
argument.

-- Terry Lambert