At 12:10 PM -0500 2005-07-29, wayne wrote:
Are/were the packets really being truncated, with the TC bit being set
and all?
Yes. TC was being set on the servers I checked.
No, you can see that the "received messsage size" is 492 bytes, which
is right up at the edge.
Right. Take a look at the "dig" examples I posted earlier.
Almost all of them had sizes well in excess of 500 bytes.
In the additional section, only 4 of the 5
name servers have A records provided. It is my understanding that the
additional records are optional and it is OK for name servers to not
put them in when they don't fit.
According to the spec, yes. They aren't required to set the TC
bit unless the truncation occurs in the ANSWER section, as opposed to
the ADDITIONAL section. However, many somewhat older nameservers
would set TC in either event.
Moreover, there are all sorts of bizarre behaviour regardless of
whether or not you get the TC bit set or not.
I don't see any mention of the TC bit being set, nor a warning about
falling back to TCP.
If the remote server supports EDNS0, and your caching/recursive
server supports EDNS0, and your resolver supports EDNS0, and the
query was in excess of 512 bytes length in the reply, you may never
have had to fall back to TCP. But there are many sites out there
where one or more parts of the system don't support TCP.
--
Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
