[ldns-users] drill and truncated packets

Teran McKinney sega01 at gmail.com
Wed Aug 20 13:52:41 UTC 2008

Thank you for replying to this; I did not understand drill's behavior
and assumed that it was a bug due to my tests with dig. I like option
3 as well, a warning would be useful. Dig's method (as you described
in Unbound's mailling list) seems a little deceptive to the user.
Perhaps an additional flag to automatically change behavior to get a
result would be useful? For example, --dowhateverisneeded (hopefully
not under that name, perhaps --automate/-a), could increase the buffer
or use TCP automatically if the result is too large.

Teran (sega01)

On Wed, Aug 20, 2008 at 13:19, Jelte Jansen <jelte at nlnetlabs.nl> wrote:
> Hi,
> on another list we've received a sort-of complaint that drill does not
> automatically fall back to TCP when it receives a truncated packet (in
> normal usage), while dig does.
> For normal resolvers, and in 'resolving mode' drill/ldns does fall back
> to tcp, but in 'single-query' mode it only prints the packet that is
> returned; ie. an empty answer with the tc flag set in this case.
> While this has been my own design choice (print what is returned, don't
> do magic) i understand the confusion this might bring, and there are a
> few options to handle this:
> 1. leave it as it is (just print the packet and hope people will look at
> the flags section as soon as they see something they didn't expect)
> 2. implement tcp fallback by default (and silently drop the truncated
> packet if verbosity level is not changed)
> 3. add a warning that the packet received was truncated, with a hint to
> use tcp or a larger buffer size
> For the moment i chose option 3 (subversion trunk rev. 2701). If people
> have a strong opinion to do either 1 or 2, please let me know.
> Jelte
> _______________________________________________
> ldns-users mailing list
> ldns-users at open.nlnetlabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users

More information about the ldns-users mailing list