[ldns-users] drill and truncated packets

[Teran McKinney]

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.

Thanks,
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
>
>