Subject: SRV and TC flag

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Feb 2001 10:33:43 -0800

I see a potential problem with the wording in RFC 2782 regarding truncated
answer sets, and am wondering if the wording needs to be changed. I don't
know if this is a significant enough change to cause procedural problems
with the document, but it seems like a minor change albeit one that is
necessary for proper functionality.

Page 7 of RFC 2728 says:

   - If a truncated response comes back from an SRV query, the rules
     described in [RFC 2181] shall apply.

Item 9 on page 11 of 2181 says:

   Where TC is set, the partial RRSet that would not completely fit may
   be left in the response.  When a DNS client receives a reply with TC
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies.

By a strict reading, the use of "should" in 2181 allows an SRV client
application to use an incomplete SRV RRset. This is bad IMO. I believe
that SRV clients which receive truncated SRV RRsets MUST discard the
incomplete list and reissue the query over TCP.

The reasoning for this is the same as the reasoning for the same
requirement for MX RRsets, as stated in section 6.1.3.2 of RFC 1123:

   A mailer must not use a truncated MX response, since this could
   lead to mail loops.

The same kind of problems can occur with any use of SRV which results in a
prioritized list. Although the current application-specific uses of SRV
are not fatally wounded by an incomplete priority list, future uses of SRV
may be. EG, if SMTP were a (unlikely) future use, SRV would be less
functional than MX under the current rules. Any application which requires
a prioritized answer list for message routing would also suffer.

IMO, any RR which provides weighted answers MUST discard truncated RRset
responses in order for the weighting to have any value.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

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

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 7 Feb 2001 12:19:38 -0800 (PST)

Eric A. Hall writes:
> application to use an incomplete SRV RRset.

I would interpret that "should" as a MUST rather than a SHOULD 
because of RFC2181 section 3:

  3. Terminology

     This memo does not use the oft used expressions MUST, SHOULD, MAY, or
     their negative forms.  In some sections it may seem that a
     specification is worded mildly, and hence some may infer that the
     specification is optional.  That is not correct.  Anywhere that this
     memo suggests that some action should be carried out, or must be
     carried out, or that some behaviour is acceptable, or not, that is to
     be considered as a fundamental aspect of this specification,
     regardless of the specific words used.  If some behaviour or action
     is truly optional, that will be clearly specified by the text.

-- 
Andreas Gustafsson, [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Feb 2001 17:49:25 -0800

> because of RFC2181 section 3:

I have gone through it three times now, but whenever I read 2181 I still
come away with a wishy washy mandate: "hey you know you really ought to
discard these incomplete answers but if it's too much trouble, that's cool
too man."

What I'm saying is that I would really feel more comfortable about the
integrity of various SRV client implementations if the wording in 2728 was
adament to the point of military precision: "you MUST discard SRV RRset
responses with TC enabled."

Either that or a clarification to 2181 stating something along the lines
of: "any RRs which require sorting by the client (MX, SRV, future), must
be complete, so any responses with TC enabled must be discarded."

I know it's a hassle to change stuff in-process but I really think this
needs to be clearly stated one way or the other.

My complaint has been made, the synaptic pressure has been relieved.

---

From: Robert Elz <[email-masked]>
Date: Thu, 08 Feb 2001 14:33:02 +0700

Date:        Wed, 07 Feb 2001 10:33:43 -0800
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | By a strict reading, the use of "should" in 2181 allows

What Andreas said...

  | IMO, any RR which provides weighted answers MUST discard truncated RRset
  | responses in order for the weighting to have any value.

Any RR, regardless of weighted answers.

kre

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 08 Feb 2001 05:22:22 -0800

> discard these incomplete answers but if it's too much trouble, that's cool

Such an implementation would not be standards compliant.  RFC2136 goes
into some detail about the atomicity of rrsets.  RFC1034/35 is less clear
but equally insistent.  If 2181 seems wishy-washy then let's upgrade the
wording.  RRsets are atomic.

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Feb 2001 07:45:02 -0800

> If 2181 seems wishy-washy then let's upgrade the wording.  RRsets are
> atomic.

gladly.  send text.

randy

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 08 Feb 2001 09:02:00 -0800

> > If 2181 seems wishy-washy then let's upgrade the wording.  RRsets are

Only change requires is replacing 'should' with 'must' in paragraph 2 of
section 9.

Original text:

New text:

   ...
   set, it must ignore that response, and query again, using a
   ...

That one-word change unambiguates this particular issue.

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 08 Feb 2001 18:22:30 +0100

> Only change requires is replacing 'should' with 'must' in
> paragraph 2 of section 9.

Is this still necessary in view of section 3 of the same document
which in essence says "in the rest of this document should == MUST".

- Håvard