]> git.kaiwu.me - haproxy.git/commit
BUG/MINOR: dns: always validate the source address in responses
authorWilly Tarreau <w@1wt.eu>
Mon, 4 May 2026 14:10:20 +0000 (16:10 +0200)
committerWilly Tarreau <w@1wt.eu>
Mon, 4 May 2026 14:27:26 +0000 (16:27 +0200)
commit4ef31cb5c2ddef6e240b70e15591e575beaca58c
tree9030b53e23b4842c708080e0306829309a816a63
parent4153aae9325d5450f90a03a5bad451b9b5ef21cd
BUG/MINOR: dns: always validate the source address in responses

When we removed the use of connect() to reach DNS servers in 3.3 with
commit 2c7e05f80e ("MEDIUM: dns: don't call connect to dest socket for
AF_INET*"), we accidentally lost a check on the server's address in
responses, opening the possibility of spoofed DNS responses for someone
who knows both haproxy's IP:port and the transaction ID.

In practice, the impact is very low, because:
  - DNS servers IP addresses are almost always known, and often even among
    the widely used ones (1.1.1.1, 8.8.8.8 etc), and their port is 53.
  - all DNS "security" relies on the ignorance of the transaction ID and
    is possible source port, so if either the attacker is on-path and sees
    them, or it's off-path and has to guess them, but in any case it's
    trivial to spoof the known server in responses, with or without the
    check.

Regardless, let's not further weaken the protocol and do the check.

Thanks to Omkhar Arasaratnam for reporting this issue.

An interesting observation while testing this fix was that the code does
support UNIX dgram sockets (via connect()) but that since we don't bind
to a local UNIX socket to send requests, the server's recvfrom() doesn't
get any address and has nowhere to respond to. So in practice while the
code is designed to deal with UNIX sockets, these cannot work by design.

This fix must be backported to 3.2 where the commit above was backported.
src/dns.c