#2 UDP Socket Pooling

UDP (1)

I've occasionally seen issues with UDP port exhaustion resulting from a high volume of DNS queries. I've been digging through the code an don't fully understand why this happens but netstat shows that the application exhausted all of the available UDP ports. I'm wondering if you would consider adding support for UDP Socket Pooling similar to what is supported by BIND and Microsoft DNS servers. This would allow DNSJNIO to re-use ports from the pool and would limit the number of actual UDP sockets that get allocated by the application.


  • alexd_nom

    alexd_nom - 2014-02-17

    Hi Allan -

    Actually, dnsjnio was originally written to perform all UDP and TCP queries over a single port (for each protocol). After the Kaminsky bug was discovered, source port randomisation was advised (RFC 5452), to prevent cache poisoning. At this point, I configured dnsjnio to use a new port for each query (thus reducing the performance, but increasing the security).

    If it was really desired to reverse this, then it is possible to rebuild dnsjnio with that configuration removed in NonBlockingResolver.java. Check the "useSinglePort" flag. Additionally, older versions of dnsjnio will be configured to use a single port (but they won't have any fixes applied to later versions).



  • Allan O'Driscoll

    Alex, thank you for your reply.

    Complete port randomization is definitely the most secure solution. However the side effect is the possibility of UDP port exhaustion.

    I've already implemented your suggested work around in order to avoid this issue. Right now I'm just exploring the possibility of creating a fix that could be part of the main code base. I don't really want to fork the project because my company requires legal approval for each and every change that we make to open source projects.

    UDP Socket Pooling would be somewhere in the middle security wise, between single port and port randomization. The system would still re-use ports (as in useSinglePort) but instead of a single port it would take them out of a variable sized pool at random. The response would still need to have the correct ID and would need to be received on the correct UDP socket. The advantage, at the cost of a little bit of additional security risk, would be better performance and management of system resources.

    This probably wouldn't be appropriate in all situations but maybe there could be an option to enable it if required.



    • alexd_nom

      alexd_nom - 2014-02-24

      Hi Allan -

      Sorry for the delayed response.

      Can I ask how many concurrent queries there are when you run out of ports?

      Is there a need to send all the queries at once, or could they be throttled to a sensible number to prevent port exhaustion?

      I'd be interested to see how strong the need is to add this feature. I'm uneasy about it, as it goes against the advice in RFC5452 - however, if there was a strong requirement, and a patch was contributed, I'd be happy to consider including it in the codebase.



  • alexd_nom

    alexd_nom - 2014-11-22
    • status: open --> closed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks