Re: dnscache and oversized answers

On 11 Oct 2008, John Levine wrote:

> >> Yes.  And even if I was, since I didn't send an EDNS0 question,
> >> that would be even more broken.
> >
> >Well, it wouldn't be broken in DNScache, if the authority server sent
> >a response.
> 
> Well, yes, it would.  Surely you have read section 5.2 of RFC 2671.

I do know of this RFC.  But your assertion is wrong. The responder is
the authority server.  If the authority server acts as though it has
seen an OPT RR even though it was not in the query (sending a large
response when it shouldn't), the error is in the authority server, not
in DNScache.

All DNSCache can do is truncate the response to its own internal limits,
setting the truncate flag accordingly.  There is no need to truncate
everything to 512.  There is no need to 'double check' the authority
server.  An internal limit of 4096 is fine. 8192 is better, but takes
more memory.

Also, I tried to fingerprint the XO servers but, fpdns 0.9.3 couldn't
find a match. I have some contacts at XO, and given John's lack of
cooperation with providing traces, I'll get together some traces of my
own and send XO a bug report.

> >Can you post the XO server IP addresses, query, and the packet you
> >got?
> 
> If you can't find the nameservers for xo.net and do an MX query on
> your own, I don't think we can help you.

You don't think "we" can help me???  I am not the one asking for help. I
am asking for complete information.  Things may have changed at XO by
the time someone actually looks into this problem, or revisits it later.
And of course, you may be confused, or you may have misinterpreted your
results, or just provided inaccurate information, as you have in the
past: see http://www.av8.net/IETF-watch/People/JohnLevine/index.html

Most people know that it is necessary to provide logs and traces when
they submit bug reports.  But I guess that perhaps some people don't
know that, or need to be reminded of why its important. So let me
explain:

There are very good reasons for the requirement to post packet traces
and logs with bug reports.  The original packets and queries are needed
so that people trying to fix or analyze the bugs can figure out what
happened to cause the report. The analysis of the problem may take place
long after the bug report was made.  Perhaps long after XO upgrades its
nameservers or alters the data.

It is not the analyst's task to figure out what someone meant when the
reporter doesn't send complete traces and logs. Perhaps 'task' isn't the
best word. By 'task', I don't mean that it's merely a question of
division of labor, but rather its a question of having complete
information to figure out what was happening at the time the reported
error was seen; as contrasted with what will be happening at the time an
analyst gets round to checking the bug reports, fixing bugs, and maybe
even creating regression tests.

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000