Subject: Clarification Request (Truncation)

From: Kevin Darcy <[email-masked]>
Date: Tue, 29 Jan 2008 18:59:15 -0500

RFC 2181, Section 9 states: "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."

So, if an authoritative nameserver responds to a QTYPE=SOA query, with 
the SOA RR in the Answer Section, but cannot fit all of the apex NS 
records of the zone into the Authority Section, should it set TC or not?

Let's say that the answer to the above question is "do not set TC in 
that case", but a nameserver *improperly* sets TC in the response. What 
is the client to do with the response? The same section of RFC 2181 
states: "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.". But the client, being 
well versed in RFC 2181, Section 9, knows without a doubt that the TC 
was *improperly* set, and it has the answer it was seeking (the SOA RR). 
So why not, in the spirit of "be liberal in what you accept" (Robustness 
Principle, RFC 1123, Section 1.2.2) and "Avoid unnecessary 
transmissions" (RFC 1034, Section 5.3.3), accept the answer *as*is*? 
Since SOA is a "singleton" RR type, there is no possibility that the 
RRset in the Answer Section is a partial one. There seems to be no 
obvious downside in accepting such an answer.

                        - Kevin

--
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: Mark Andrews <[email-masked]>
Date: Wed, 30 Jan 2008 11:28:08 +1100

> records of the zone into the Authority Section, should it set TC or not?

	Yes.  NS records in the authority section from a authoritative
	server fill a gap in the DNS specifications.  They perform
	two functions.

	1. replaces glue with authoritative data in the cache, this
	   aids in the migration to a new set of nameservers.  This
	   is a double edged sword as caches can get locked onto old
	   servers if they are not configured to serve the new zone
	   content.  Cache work around the later by not updating the
	   ttl if the NS RRsets are otherwise equal.

	2. Allows caches to see the nameservers for a child zone where
	   a server for a parent zone also serves the child zone either
	   officially or as a stealth server.

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

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 29 Jan 2008 19:47:03 -0500

> 	   officially or as a stealth server.
This is "helpful" information, but is it *required* information? RFC 
2181 says "required".

Remember, this is an SOA query I'm talking about. If the client wanted 
to know the NS records for the zone, it could ask for them.

                              - Kevin

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Jan 2008 12:44:42 +1100

> to know the NS records for the zone, it could ask for them.

	The intermediate caching resolvers need it.  Not every
	client needs every bit of every response however some client
	needs some bits of a response and as we don't have a signaling
	mechanism to say exactly what parts of the response are
	needed by what clients the server has to assume that every
	client may need all parts of the response.

	Mark

---

From: Joe Abley <[email-masked]>
Date: Tue, 29 Jan 2008 21:22:49 -0500

On 29-Jan-2008, at 20:44, Mark Andrews wrote:

> 	The intermediate caching resolvers need it.

If it's a caching resolver that's sending the query in question,  
surely the caching resolver *is* the client.

Joe

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 29 Jan 2008 21:49:38 -0500

> 	client may need all parts of the response.
Is there any caching resolver implementation that isn't smart enough to 
follow up an SOA query with an NS query if it thinks it also needs the 
NS records and they're missing from the first response?

I'll note that there is a widely-used DNS implementation out there (not 
BIND) that doesn't appear to populate the Authority Section *at*all* in 
response to SOA queries. Is this implementation causing any problems 
with intermediate caching resolvers?

                                          - Kevin

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Jan 2008 14:32:49 +1100

> NS records and they're missing from the first response?

	Caching resolvers learn about NS RRsets as side effects of
	performing other queries.  The only times caching resolvers
	make explicit NS queries are to prime or when trying to find
	the correct servers to answer a DS query.

> with intermediate caching resolvers?

	Well if you care about correctly spreading load or quick
	movement when changing delegations it does.

	Mark

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 29 Jan 2008 23:12:53 -0500

> 	movement when changing delegations it does.
My point is: while it may be useful in the general case to put those NS 
records into the Authority Section, in my interpretation of RFC 2181, TC 
should *not* be set if it so happens that they don't fit. To do so risks 
triggering an unnecessary TCP retry. Since there is at least one 
implementation out there which does not provide this Authority Section 
information, without any noticeable ill effects, I think it's fair to 
say it's not *necessary*.

I don't ask any of this from idle curiosity. We're dealing with a 
production issue and I'm trying to sort out how much of it is due to 
standards nonconformance and how much of it is due to discretionary 
design choices made by particular implementations.

                     - Kevin

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 30 Jan 2008 08:21:07 +0100

Hi Kevin,

Answer section and authority section must be complete, else, set the TC
bit. Additional section can be partial.

|>>>>>> RFC 2181, Section 9 states: "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."
|>>>>>>
|>>>>>> So, if an authoritative nameserver responds to a QTYPE=SOA query,
|>>>>>> with the SOA RR in the Answer Section, but cannot fit all of the
|>>>>>> apex NS records of the zone into the Authority Section, should it
|>>>>>> set TC or not?
|>>>>>>
|>>>>>     Yes.  NS records in the authority section from a authoritative
|>>>>>     server fill a gap in the DNS specifications.  They perform
|>>>>>     two functions.

Yes, too.

RFC 4035, 3.1.1 says very clearly that omission of RRs in the authority
section causes the TC bit to be set. I also interpret 2181 in the same
way. It means that the client can assume that an RRset, if present in
the authority section, is a complete RRset (and not 'truncated silently').

If you think that NS rrsets are not that critical, they should be put in
the additional section, which causes exactly the processing you are
alluding to. I do not agree with that position, the authority section
carries valuable information. As Mark says: for the spreading of load by
gossiping about other nameservers. In dnssec, contains NSECs.

Note that for NSEC3, the client *cannot* requery for missing NSEC3
records from the authority section. The latest nsec3 draft forbids
direct NSEC3 queries (in an attempt to de-complicate it).

Best regards,
~   Wouter

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 Jan 2008 15:18:11 +0700

Date:        Tue, 29 Jan 2008 18:59:15 -0500
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | RFC 2181, Section 9 states: "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."

That's correct.

  | So, if an authoritative nameserver responds to a QTYPE=SOA query, with 
  | the SOA RR in the Answer Section, but cannot fit all of the apex NS 
  | records of the zone into the Authority Section, should it set TC or not?

No, it should not, but also notice from section 9 ...

   In such cases
   the entire RRSet that will not fit in the response should be omitted,
   and the reply sent as is, with the TC bit clear.

That is, the correct behavior is to send the SOA answer, and leave the
authority section empty in the scenario that you posed (unless there's
some other RRSet that could go there, and fits, of course).

That avoids a server that really only ever wanted the SOA record, and did not
need the NS records from having to query again using TCP, when the SOA
record itself fitted just fine in the initial answer.

If the resolver needs the NS records, it must query again anyway, they
don't fit in the initial response.  It can perhaps do that with UDP,
without the SOA record they might fit (should fit if the admin has
planned things properly), or if they don't, that reply will be sent
with TC set, as it is not acceptable to just send back an empty answer
(see sect 5.1.)

  | Let's say that the answer to the above question is "do not set TC in 
  | that case", but a nameserver *improperly* sets TC in the response. What 
  | is the client to do with the response?

Treat it like any other response with TC set and query again.   That's
really all it can do (though I guess that it could notice that the
answer section was complete, and simply drop the auth section, as if
the server had never sent it, and continue).

  | The same section of RFC 2181 
  | states: "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.".

That's what was intended, yes.

  | But the client, being 
  | well versed in RFC 2181, Section 9, knows without a doubt that the TC 
  | was *improperly* set, and it has the answer it was seeking (the SOA RR). 
  | So why not, in the spirit of "be liberal in what you accept" (Robustness 
  | Principle, RFC 1123, Section 1.2.2) and "Avoid unnecessary 
  | transmissions" (RFC 1034, Section 5.3.3), accept the answer *as*is*?

As long as you mean just the answer, as in answer section, that should
do no real harm - of course, such a resolver would be behaving just as
improperly as the server that sent the response, though in neither case is
any actual harm (DNS harm, as distinct from workload hrm) being done.

  | Since SOA is a "singleton" RR type, there is no possibility that the 
  | RRset in the Answer Section is a partial one. There seems to be no 
  | obvious downside in accepting such an answer.

That's not the correct analysis, we don't want such things handled by
special casing some of the RR types that way.   Better, is that the
resolver can see that the answer section is correct, the header says
how many RRs are to be expected there (which should include any that
do not fit because of TC), the resolver can detect that the last expected
answer RR is within the data contained in the received packet, so it
knows that the answer section is complete, and hence any RRSets contained
in it are complete, which is what matters most.

However, I don't think we need to waste much time specifying just how a
resolver that is (clearly) acting in opposition to he spec should behave
so as to cause least damage - far better would be to find and fix whatever
server sent the dumb response in the first place.   Only a lazy implementation
would ever do that - there's no good reason for leaving the (partially 
complete) auth section RRSet in the response - leaving it there and setting
TC will just cause a (correct) resolver to retry with TCP, when it might
not really have needed to, which is a waste of everyone's resources, and
what's more, just makes the initial reply bigger, carrying data that cannot
be useful to the resolver - if the auth section is not complete, then nothing
in it can be used by the resolver (there's no way to tell which RRSet there
was incomplete, unless there is only one of course - either way, the entire
auth section is useless).   Leaving out the RRset that will not fit at least
makes the packet a few bytes smaller, avoids TC (and a TCP retry) and if
there are any other RRSets in the auth section that do fit, the resolver
gets them for free.

Lastly, some of the other answers either missed the point, or we just
wrong, there are no special cases here for some record types, other than
the ones (DNSSec RRs, if those ones still exist...) mentioned in 2181.

kre

ps: all this is usually more likely when considering the A (and AAAA) RRSets in
the additional section that accompany the NS records in the auth section.
There, there are several RRSets (one for each NS) - leaving out just the
(complete) RRSets that do not fit means that some others will fit, and be
useful, leaving the resolver with less other queries needed to fetch
the rest of the data.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Jan 2008 20:31:47 +1100

Or workout why there is a excessive number of NS records
	there and remove them.  If the delegation is being properly
	maintained the delegation itself will cause TC to be set
	as will any answer from a cache.  In neither of the last
	two cases in the NS RRset the least bit optional.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Wed, 30 Jan 2008 20:52:34 +0700

Date:        Wed, 30 Jan 2008 20:31:47 +1100
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Or workout why there is a excessive number of NS records
  | 	there and remove them.

Yes, of course, but that's a different issue.   That's just poor
configuration - but attempts to legislate against that are self-contradictory
so the best we can do is to make sure that things are handled sanely
when there is a poor config.

  |     If the delegation is being properly
  | 	maintained the delegation itself will cause TC to be set
  | 	as will any answer from a cache.

Not necessarily in the situation posed - it may be that it is only
when there is also something in the answer section that the NS RRSet
is too large (and more, the example cited was the relatively large
SOA record in the answer section).

  |    In neither of the last
  | 	two cases in the NS RRset the least bit optional.

Yes, for a referral, the auth section is required - in effect, it is
the answer (as much of an answer as this reply contains anyway), and there,
if the NS RRSet doesn't fit, TC is essential, just sending an empty answer
(without TC) isn't appropriate at all.

The same might be true (though less importantly) for the SOA in the
auth section when RCODE != 0, though it is fairly hard to imagine
that RRSet (that RR) ever being so big as to exceed the limits of
UDP (though it is theoretically possible).

kre

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 30 Jan 2008 22:04:37 -0500

W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Kevin,
>
I agree that if the TC bit is clear there should be no partial RRsets in 
the response. RFC 2181 states as much.

But should TC be set just because some helpful but not *necessary* 
information _might_ have been put in the Authority Section, but was too 
big to fit? Seems to me TC should be reserved for data that *must* go in 
the response but *cannot*. Not for mere "would be nice" scenarios.
> alluding to.
RFC 2181 says

  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. 

"includes" != "is limited to"

> I do not agree with that position, the authority section
> gossiping about other nameservers.
Valuable but not *necessary*. That's my point. I think avoiding 
unnecessary TCP retries is also a valuable goal, and not just because of 
incompetent firewall admins who block TCP/53. I understand it's a 
tradeoff, X amount of "cache enrichment" for the price of Y amount of 
unnecessary TCP retries, but it seems to me the tradeoff has already 
been decided by RFC 2181 and now the only questions are whether 
implementations are conformant and/or whether RFC 2181 should be amended.
> direct NSEC3 queries (in an attempt to de-complicate it).
Pardon my DNSSEC ignorance, but if the client cared about the NS RRset, 
along with the associated signatures, etc. couldn't it just query NS 
directly? Wouldn't the response to that query carry with it the 
necessary elements for DNSSEC validation?

               - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 30 Jan 2008 22:15:14 -0500

> when there is a poor config.
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. We're up to 
142 NS records at the apex of this particular zone. That's what gives 
rise to the TC bit being set, not the size of the SOA RR itself (as you 
theorized/hypothesized later in your message).

It's more like "bad design" than "poor configuration". But I'm trying 
hard not to point fingers at specific implementations, since I'm 
attempting to raise a protocol-conformance issue, not just criticize 
particular implementations for their discretionary choices.

- Kevin

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 Jan 2008 14:58:11 +0700

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) ...

> 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

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 31 Jan 2008 09:43:00 +0100

Kevin Darcy wrote:
| I agree that if the TC bit is clear there should be no partial RRsets in
| the response. RFC 2181 states as much.

OK, we agree

| But should TC be set just because some helpful but not *necessary*
| information _might_ have been put in the Authority Section, but was too
| big to fit? Seems to me TC should be reserved for data that *must* go in
| the response but *cannot*. Not for mere "would be nice" scenarios.

I do not think it is merely 'would be nice', even though you can omit it
from one single query, not for all of them, you miss the gossip quality
and the load spreading goes amok. I do not think that one misconfigured
zone (that works, sort of, with EDNS or TCP fallback) is a reason to
change the protocol.

| Pardon my DNSSEC ignorance, but if the client cared about the NS RRset,
| along with the associated signatures, etc. couldn't it just query NS
| directly? Wouldn't the response to that query carry with it the
| necessary elements for DNSSEC validation?

For the NS yes. For NSEC3 no. NSEC3 records are not 'would be nice',
they are absolutely necessary in the authority section. Without them (or
NSEC records) the answer is useless.

Best regards,
~   Wouter

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 31 Jan 2008 21:04:53 -0500

> do you verify that they're all working correctly???)
OK, time to name names. It's Microsoft DNS and an "Active Directory 
Integrated" zone. By default, every Domain Controller gets an NS added 
to the apex of the zone.

Not the design choice I'd make, but I didn't get a say in the matter.

Apparently there _is_ a way within the software to control what NS 
records are added to the apex, but I'm no Microsoft expert and it is 
non-obvious enough that our resident admins haven't been able to figure 
it out yet. Which suggests that large numbers of NS records at the apex 
may be a *common* situation for anyone using AD-integrated DNS zones. 
This is why I think it's important to clarify how authoritative 
nameservers -- who may be slaving those zones -- should handle their 
inability to fit all of the NS records for such zones into their 
responses' Authority Sections.

For the record, the primary master (the Microsoft DNS server) answers 
SOA queries for the zone with an empty Authority Section and TC clear. 
But another DNS implementation sets TC under the same circumstances, 
which has, in our particular environment, led to other problems.

- Kevin

---

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

> stupidity it is, and making sure that it does is a perfectly reasonable

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. If DNS performance is poor as a result, that a matter of fixing 
the configuration rather than messing with the protocol.

Danny

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 31 Jan 2008 22:18:45 -0500

Danny Mayer wrote:
>>   | configuration of the particular DNS implementation in question to 
>> add an   | NS record at the apex of the zone for every "peer" server.
>>
>>   | not the size of the SOA RR itself (as you   | 
>>   | But I'm trying   | hard not to point fingers at specific 
>> implementations,
>>
>>   | since I'm   | attempting to raise a protocol-conformance issue, 
>> not just criticize   | particular implementations for their 
>> discretionary choices.
>>
> 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.

                              - Kevin