Subject: Re: Clarification Request (Truncation)

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 01 Feb 2008 09:05:00 +0100

Kevin Darcy wrote:
| Danny Mayer wrote:
|> There are many solutions to improving the design of the architected or
|> mis-architected configuration, but the protocol needs to work for all
|> situations including this one. So setting the TC bit is the correct
|> answer.

I agree with Danny.

| Non sequitur. The protocol "works" whether TC is clear or not: if it's
| clear, the client takes the answer as it finds it and queries the
| "missing" NS records as necessary; if TC is set, then the client
| (typically) will retry the query using TCP, thus obtaining the answer
| and all of the NS records that wouldn't fit in the initial response.

Well, your use of the protocol works without the NS records. The DNS is
robust. The DNS protocol as widely used, needs those NS records to help
resolvers find nameservers more efficiently. So what is querying for the
SOA record that cannot retry with  TCP? (This is your local subnet, so
speed is not that much of a problem?)

Can you deploy EDNS? That is the other obvious solution.

| The main question is whether an implementation which sets TC under these
| circumstances conforms to RFC 2181. A follow-on question would be
| whether RFC 2181 needs to be amended for situations such as this one.

What is the problem with a TC bit on a SOA answer?

I am guessing 140 records may fit in an EDNS answer even (if the names
compress well, name your domain controllers a.domaincontroller.local to
zz.domaincontroller.local).

Best regards,
~   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Feb 2008 19:51:24 +0700

Date:        Thu, 31 Jan 2008 21:43:40 -0500
    From:        Danny Mayer <[email-masked]>
    Message-ID:  <[email-masked]>

  | There are many solutions to improving the design of the architected or 
  | mis-architected configuration, but the protocol needs to work for all 
  | situations including this one.

Yes, that is exactly what I think I said in the message you quoted.

  | So setting the TC bit is the correct answer.

No, it isn't - I suspect you're making the same mistake as
Stephane Bortzmeyer made, and not really considering the
viable choices - see the reply I just sent to him.

  | If DNS performance is poor as a result, that a matter of fixing 
  | the configuration rather than messing with the protocol.

Absolutely.   That I agree with.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 01 Feb 2008 16:09:06 -0500

Wouter Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevin Darcy wrote:
> | Danny Mayer wrote:
Already deployed. The advertised buffer size is 2048 which is still not 
big enough to fit all of the NS records.
> What is the problem with a TC bit on a SOA answer?
Besides the wastefulness of an unnecessary TCP retry, it causes 
execution of a code branch that has an unfortunate end result.

But, I don't want to whine about the coding of a particular 
implementation. My focus here is on the question of standards 
conformance. Apparently we still don't have a consensus answer on that.

                     - Kevin

---

From: Danny Mayer <[email-masked]>
Date: Fri, 01 Feb 2008 21:58:07 -0500

Kevin Darcy wrote:
> Danny Mayer wrote:
>> Robert Elz wrote:
>>>     Date:        Wed, 30 Jan 2008 22:15:14 -0500
>>>     From:        Kevin Darcy <[email-masked]>
>>>     Message-ID:  <[email-masked]>
>>>
>>>   | Actually, I wouldn't say "poor configuration". It's the *default* 
>>>   | configuration of the particular DNS implementation in question to 
>>> add an   | NS record at the apex of the zone for every "peer" server.
>>>
>>> That is OK, and even sounds correct, but ...
>>>
>>>   | We're up to 142 NS records at the apex of this particular zone.
>>>
>>> That's insane.   What benefit can anyone possibly achieve by having
>>> that many peer servers?   You'd be better to use anycast, and have just
>>> one server name for a whole subset of those 142 - that way at least the
>>> routing system can help clients (resolvers) select a rational one of
>>> those servers to query.
>>>
>>> And yes, that is very poor configuration (not in the server adding the
>>> NS records, but in having that many peers in the first place - how 
>>> frequently
>>> do you verify that they're all working correctly???)
>>>
>>>   | That's what gives rise to the TC bit being set,
>>>
>>> Yes, it would - and you get the option of either setting TC, and forcing
>>> a retry (using TCP) for the SOA to be fetched, or of simply putting none
>>> of the NS records in the reply - the server faced with this absurd zone
>>> zone config has no other choice.
>>>
>>>   | not the size of the SOA RR itself (as you   | 
>>> theorized/hypothesized later in your message).
>>>
>>> For that I was just suggesting that in some cases the NS list (of a
>>> sanely configured NS list) may be carefully chosen to fit in a UDP
>>> reply when an NS query (or referral) is performed, but just fail to fit
>>> in the presence of a larg(ish) answer section - like perhaps a SOA
>>> record - I was not intending any specific comment on your particular
>>> situation.
>>>
>>>   | It's more like "bad design" than "poor configuration".
>>>
>>> You mean bad design that it is possible to have so many peers?   How 
>>> would
>>> you possibly prevent it?   Or bad design that having the peers causes 
>>> them
>>> to be listed in NS records (I suppose maybe).
>>>
>>>   | But I'm trying   | hard not to point fingers at specific 
>>> implementations,
>>>
>>> No, nor was I (though perhaps at whoever decided so many peers was
>>> sane) - and ..
>>>
>>>   | since I'm   | attempting to raise a protocol-conformance issue, 
>>> not just criticize   | particular implementations for their 
>>> discretionary choices.
>>>
>>> I agree, which is what I said last time (and you quoted from my previous
>>> message) ...
>>>
>>>> so the best we can do is to make sure that things are handled sanely
>>>> when there is a poor config.
>>>
>>> That is, the protocol has to cope with the stupid, no matter whose
>>> stupidity it is, and making sure that it does is a perfectly reasonable
>>> thing to do.
>>>
>>> kre
>>
>> There are many solutions to improving the design of the architected or 
>> mis-architected configuration, but the protocol needs to work for all 
>> situations including this one. So setting the TC bit is the correct 
>> answer. 
> Non sequitur. The protocol "works" whether TC is clear or not: if it's 
> clear, the client takes the answer as it finds it and queries the 
> "missing" NS records as necessary; if TC is set, then the client 
> (typically) will retry the query using TCP, thus obtaining the answer 
> and all of the NS records that wouldn't fit in the initial response.
> 
> The main question is whether an implementation which sets TC under these 
> circumstances conforms to RFC 2181. A follow-on question would be 
> whether RFC 2181 needs to be amended for situations such as this one.
> 

Why would you change an RFC for a poor infrastructure. Fix the
infrastructure not the protocol which is working just fine.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sat, 02 Feb 2008 15:21:19 -0500

> conformance. Apparently we still don't have a consensus answer on that.

I think we *do* have consensus on it. You just don't want to accept it. 
I have seen no response indicating that the RFC should be changed.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 01 Feb 2008 20:13:43 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Danny

---

From: Robert Elz <[email-masked]>
Date: Tue, 05 Feb 2008 12:00:22 +0700

Date:        Mon, 04 Feb 2008 22:59:05 -0500
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | My interpretation is that, since the NS RRset is not "required" in this 
  | response, then TC shouldn't be set.

You're right, provided that you make it clear that none of the NS RRSet
is actually included in the message in this case.

I think you're seeing an argument against that which doesn't really
exist, and was all based upon a misunderstanding of the situation.

  | As a fanciful analogy, setting TC=1 and triggering a TCP retry in this 
  | case strikes me as similar to one's significant-other saying: "Thanks, 
  | honey, for making the emergency run to the drug store to get my 
  | life-saving prescription pills, but since you didn't also bring the 
  | chocolate bar that you usually buy when you shop at that store, I'm 
  | going to have to send you back on another trip. See you in another 15 
  | minutes".

Actually, that's a very poor analogy.   The right one along the same
lines would be: "honey" arrives at the pharmacy to get the pills, and
discovers that (s)he doesn't have enough space in his/her pockets/purse
(or perhaps insufficient finances) for both the pills and the chocolate bar
that always comes home too (though there would have been space/money for
either one alone).

So, "honey" returns home with nothing, changes to clothes with more
pockets (or a larger purse, or more cash) returns to the pharmacy, obtains
both pills and chocolate, then returns home to be told "thanks honey, but
I didn't really need that chocolate today, just the pills".  (And then
if you want to over-dramatise, "pity I died waiting for those pills while
you were running around backwards and forwards...")

  | If "non-conformant" is the consensus of the WG, while at the same time 
  | folks want to condone the behavior of the particular implementation in 
  | question,

There is no need to condone it, but we do need to recognise that it
exists (broken implementations in the DNS world have mostly been the
norm rather than the exception) and live with it.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 04 Feb 2008 22:59:05 -0500

Danny Mayer wrote:
>> Already deployed. The advertised buffer size is 2048 which is still 
>> not big enough to fit all of the NS records.
>>>
> I think we *do* have consensus on it. You just don't want to accept 
> it. I have seen no response indicating that the RFC should be changed.
>
True, we don't have anyone suggesting, so far, that RFC 2181 be changed.

But, there have been diverse opinions on whether the behavior I 
described conforms to the RFC or not. We don't, as I see it, have a 
consensus on that question.

Again, I quote the language (Section 9):

    The TC bit should be set in responses only when an RRSet is required
    as a part of the response, but could not be included in its
    entirety. The TC bit should not be set merely because some extra
    information could have been included, but there was insufficient
    room. This includes the results of additional section processing.

and ask:

    Does a nameserver implementation which can fit an answering RRset in
    the Answer Section of a response, given the EDNS0 buffer size in
    effect, and is configured to normally also provide the apex NS RRset
    of the zone in the Authority Section, but cannot, for this specific
    response, due to the fact that the RRset is too large to fit, have
    license to set TC=1, with the answering RRset in the Answer Section
    and an empty Authority Section?

My interpretation is that, since the NS RRset is not "required" in this 
response, then TC shouldn't be set. The "extra information" referred to 
by the RFC 2181 verbiage is stated to "include[] the results of 
additional section processing", but I don't see it as *limited* to that. 
So presumably it also applies to "extra information" that might normally 
be provided in the Authority Section. To my knowledge, the only 
information in an Authority Section which is ever *required* is
o  an NS RRset in a referral response
o  one or more DNSSEC-related records (? again, showing my DNSSEC ignorance)
neither of which apply in the case in question.

As a fanciful analogy, setting TC=1 and triggering a TCP retry in this 
case strikes me as similar to one's significant-other saying: "Thanks, 
honey, for making the emergency run to the drug store to get my 
life-saving prescription pills, but since you didn't also bring the 
chocolate bar that you usually buy when you shop at that store, I'm 
going to have to send you back on another trip. See you in another 15 
minutes".

If "non-conformant" is the consensus of the WG, while at the same time 
folks want to condone the behavior of the particular implementation in 
question, then RFC 2181 would need to be amended to allow it. (Generally 
speaking, I have a dim view of amending standards-track RFCs in order to 
accommodate the quirks of individual implementations; code should 
conform to standards, not the other way around).

                     - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 05 Feb 2008 22:34:43 -0500

> you were running around backwards and forwards...")
I don't agree with that change to the analogy. The response wasn't 
*empty*. An answer *was* given (honey came home with the pills), but it 
was considered suspect because TC=1 (oh, I don't know, maybe honey is a 
chronic prescription drug abuser and there's a palpable suspicion he/she 
may have diverted some of the pills to his/her own use).

If there is ever a RFC2181bis, I'd probably argue that an exception 
should probably be made for TC=1 responses that are still usable. This 
is possible when, for instance, the QTYPE is a "singleton" type 
--QTYPE=SOA in my original example -- so there is no fear that there 
might be missing RRs from the Answer Section (instead of pills, maybe 
the prescription is for a single vial of injectable liquid).

(Have we beaten this silly analogy of mine to death yet? :-)
> norm rather than the exception) and live with it.
Again, I'm not out to skewer anyone or anything, I'm just trying to 
clarify which parts of the behavior with which I've been confronted are 
standards-conformance issues and which parts are questionable/debatable 
design choices or mere coding quirks.

- Kevin