From jelte at NLnetLabs.nl  Wed Aug 20 13:19:59 2008
From: jelte at NLnetLabs.nl (Jelte Jansen)
Date: Wed, 20 Aug 2008 15:19:59 +0200
Subject: [ldns-users] drill and truncated packets
Message-ID: <48AC19FF.9070609@NLnetLabs.nl>


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20080820/edc4ef4b/attachment.bin>

From shane at ca.afilias.info  Wed Aug 20 13:30:21 2008
From: shane at ca.afilias.info (Shane Kerr)
Date: Wed, 20 Aug 2008 15:30:21 +0200
Subject: [ldns-users] drill and truncated packets
In-Reply-To: <48AC19FF.9070609@NLnetLabs.nl>
References: <48AC19FF.9070609@NLnetLabs.nl>
Message-ID: <1219239021.28309.41.camel@shane-macbook-pro>

Jelte,

On Wed, 2008-08-20 at 15:19 +0200, Jelte Jansen wrote:

> 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.

I think you did the Right Thing.

And maybe update the man page in case someone actually bothers to RTFM
(could be important if someone is using drill in a script for
instance). ;)

--
Shane



From ondrej at sury.org  Wed Aug 20 13:58:45 2008
From: ondrej at sury.org (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Wed, 20 Aug 2008 15:58:45 +0200
Subject: [ldns-users] drill and truncated packets
In-Reply-To: <48AC19FF.9070609@NLnetLabs.nl>
References: <48AC19FF.9070609@NLnetLabs.nl>
Message-ID: <3221680d0808200658n7dad3faewbd7c07c6a520991b@mail.gmail.com>

> 3. add a warning that the packet received was truncated, with a hint to
> use tcp or a larger buffer size

Option 3 suits me best as well.

Ondrej
-- 
?Ond?ej Sur? <ondrej at sury.org>

From sega01 at gmail.com  Wed Aug 20 13:52:41 2008
From: sega01 at gmail.com (Teran McKinney)
Date: Wed, 20 Aug 2008 13:52:41 +0000
Subject: [ldns-users] drill and truncated packets
In-Reply-To: <48AC19FF.9070609@NLnetLabs.nl>
References: <48AC19FF.9070609@NLnetLabs.nl>
Message-ID: <b245135e0808200652h469df4f4pc3b9dcb7fea39b6a@mail.gmail.com>

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