Hi Wouter, sorry for the late answer. I have missed your reply in my pile of mails.
I like the new delay-close option very much. After a first test it solves an other problem I had also. It was described by Ilya Bakulin a couple of months ago. We have seen a bunch of ICMP-Port-Unreachable packets in some cases and we were using a workaround in our firewall to block them. Your solution is much better. Thanks for it! I think (not tested yet) the delay-close option can not solve the problem described in this thread. My problem here were not the ICMP packets. The problem is that unbound can't resolve if usually fast answering forwarders need a lot of time to do recursive resolution for a specific domain. With delay-close I can suppress the ICMP Packets to the forwarders but I still can't resolve the name. In that case the answers get dropped too early because of a small retransmit timeout. I'm running unbound with my patch for a couple of months now and it seems to work pretty good. I'm not sure how useful the patch is for the other users. Maybe a higher minimum retransmit timeout only for forwarder would be an option too and no special configuration would be required. On the other hand, with my patch everybody can fix such problems without recompiling unbound. Best regards, Florian On 01/28/14 15:44, W.C.A. Wijngaards wrote: > 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 > _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
