[Unbound-users] Resolve failures when using forwarders that do recursion

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Florian,

On 01/07/2014 08:52 AM, Florian Riehm wrote:
>> 
>> Hi,
>> 
>> Please have a look to the attached patch. It adds a new config
>> option 'infra-cache-min-rtt' which makes the former constant
>> value of RTT_MIN_TIMEOUT adjustable. This gives the user the 
>> opportunity to choose a reasonable retransmit timeout value.
>> 
> 
> Hi Wouter,
> 
> I'm still thinking about the problem with the infra cache timeouts
> with forwarders. I would like to ask you about your opinion of a
> 'right' solution for the problem. I guess adding a config option
> (see my patch) is kinda hack, but I don't see any other solution at
> the moment.
> 
> Actually I was thinking about this idea: After a timeout unbound
> could reuse port and query id in the second query. Then we could
> accept the first reply still after the second query was sent. Reuse
> port and query id will avoid security problems with the kaminsky
> attack. But this solution works only if the second query gets send
> to the same server as the first. In most cases people use >1 global
> forwarders, so it won't work. So I guess it's to much work to
> implement this behavior if it doesn't fix the problem in all
> cases.
> 
> Have you any other suggestions how we could fix this problem? Have
> you any considerations about my patch with the infra-cache-min-rtt
> option?

So, the same fix as the min-rtt option, but then conditional on the
recursiveness of the target.  So, if unbound sends a packet to a
destination that is recursive, it uses the timeout of 1000 msec for
it.  This gives the recursive destionation the time to perform the
recursion before a retry.

However this conflicts with the desire for unbound to poll a second
recursive server, just to see if this query is in cache for that
server.  And come back to the first one later (on a later reprobe),
(this is the current behaviour).

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSy7XgAAoJEJ9vHC1+BF+N9QgP/38I6ExL9IHBHWTlw5hoeIRb
jeOTfmaFXziMhXsUy6yITg9no1M4Z97uLtLgI8WVcvD3cSZcX0jJFZ491DGTacrm
0tvW3YnR3FSDdJcZ3VQbzAgoHAR6lh7GME77eJLZ6JJW0/r83kW2LPANk6ilnXk2
UGFRzmKumpU2v4jcZDd/PuNcOKAiPnHNF+ccKq2mudArjF//ZOVj7YCDjtf2SS2f
LEHvggP5YMyY7tLj2a4vAQ1WfBHPHnatkS3/odRjZfLUTtbaPF1PB51D+7CbX4UX
qg5EQCApdkRl2YzZO4JVQXJsp2l1BnzQ9Zm1HL5MVffQE5v/8KZjwWWeamKMFw61
8Xufg7ylAvq03AV2yEvx+AtPWoGcRvj1E/7ori676QvKzlBTvsnkTKKyUipdLv04
1robSYOnhcPJRunSRadQiY4qJdqnKFPuL00YCc4x6h2+ldhgf23fpIkcI4sJRbSk
aasWJrkV6EAwapYnHLUA07zxr0AvtiLOOUy9lfssnNqSD2ntDwL72TYlSLzWIhRf
/MNYLbsoUJ4AAhmq2m2UaT0qOhSgS+kvDSEsKu1rNfEEYkfOeCIeEbJiwSChUFBM
YCge72bcFFVZDhDzUJM/q+9TuULNVtwACaOqzitskfjk+7ZAPTrhHv99ZDvUgp8X
R2E2NcSxYgxCpm3HQ/l3
=MN5H
-----END PGP SIGNATURE-----