Viktor Dukhovni:
>
> > On May 5, 2017, at 11:31 AM, Wietse Venema <wie...@porcupine.org> wrote:
> >
> > I would not exclude the possibility that the OP is using a greedy
> > resolver that tries to look up A records when asked for MX, and
> > then reports an MX lookup problem when it was actually the A query
> > that failed because of the large response to that query.
>
> Perhaps, but I would not have expected this. The additional records
> in this case are not "in bailiwick", and would be ignored by any
> downstream recursive resolver in a chain of resolvers, so including
> such additional records would be often pointless.
>
> Also, while there are many A records, there are not so many that I
> would expect UDP issues. The entire A RRset fits in 505 bytes, with
> EDNS0:
I was seeing ';; Truncated, retrying in TCP mode' with the host(1)
and dig(1) command-line utilities on my aging server.
Still wondering, though, whether some resolver isn't returning
failure because some unsolicited lookup didn't work out.
There is some prior art for this. Some SunOS versions used to have
a gethostbyaddr() implementation that would return failure if the
forward lookup result did not match, as a defense against spoofing.
Wietse
