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

W.C.A. Wijngaards wouter at nlnetlabs.nl
Tue Jan 28 14:44:52 UTC 2014


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

Hi Florian,

I have implemented a completely different option, does that meet your
needs?  It is called delay-close: msec.  If you set eg. delay-close:
1500, then when a UDP socket timeouts that port is kept open for 1500
msec afterwards.  Meanwhile unbound continues (but a socket is still
in use) as normal.

Only the right ID, IPaddr is accepted on that port; bad packets are
added to the unwanted_replies counter.  The right ID,IP also closes
the port.

This keeps ports open for a little while longer, without impacting the
rest of unbound.

Do you like this option, or do you (also-) want me to accept your patch?

Best regards,
   Wouter

On 01/07/2014 09:08 AM, W.C.A. Wijngaards wrote:
> 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
> 
> _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

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

iQIcBAEBAgAGBQJS58JkAAoJEJ9vHC1+BF+NvO8P/Ra1I0VBv/VLS1EdU+uSuWk6
RViQgXxrMbd0uap1oLe1WVnrTWi8SSCErushKt90qcAG6HY8kL5HQNaXPpH3EOYR
QRnUTLHK7CgrfU8QuMTtuCmlmVFlIetXyK/OILKOwag0zyXOJDJS4FTAW4uYzCv9
nbEqDoIubbX+PPkpSM4HTaIfERTylhF3vDEdz9ZwFiBcbawVoKoGFz0coRTat10p
dFOXTt3mm2A/NazV8EwTgDxoVvWlIHype7Hk3wJnKPLSUfZAV4TLBVegN7msLRjz
pmAU6rGouONQhJBCK/Sy59U/JCWAA9QinS7/cOKLN9peIUZ5h3L9xdmjsq5i1FbH
atrbCKvGkvAwznjEysCRFHGHsLmIqofNvQqdgEn3HrCbC6CQRnoUnDUhrJTXwPH2
FDabFPHgErZEhZ91dx60/ZKySSa9tBAESYNbrO6qtxzOqVu0AtMEMYhleCspVer0
Mq8U36USRH5KbjLvirGeqWGeHD1fraCzeqBJ/tfHlLKAeeomZTwJOIhJ2j64KgI1
7TFZQB/zPtAJSbn/ud0DYsBRZMeKmVC1yZYltiksgff4fLgbJ2yASLOHfmI6rBt/
ofZPAiHesqo6Vb3EkyZtXMfgxREoIHUyW66SMfyc50DT1jR65o6rkL358H9RUCsm
nvJ7znaCkmCEdnB4IrSn
=Hv6R
-----END PGP SIGNATURE-----



More information about the Unbound-users mailing list