[nsd-users] Wrong source IP for reply if 'ip-address' is not specified

[Stuart Henderson]

On 2017/12/14 00:56, Paul Wouters wrote:
> On Wed, 13 Dec 2017, Anand Buddhdev wrote:
> 
> > > We have a different opinion on what is "normal behaviour". I believe the
> > > normal behaviour is to reply using the IP address you received the
> > > packet from, eg using:
> > > 
> > > err = setsockopt(s, SOL_IP, IP_PKTINFO, &opt, sizeof(opt));
> > > 
> > > or
> > > 
> > > err = setsockopt(s, IPPROTO_IP, IP_RECVDSTADDR, &opt, sizeof(opt));
> > 
> > I don't know if these options are available in non-Linux socket
> > implementations, and is probably the reason that NSD doesn't use them.
> 
> Yes they are, but apparently for freebsd you use IP_RECVDSTADDR.
> 
> https://www.freebsd.org/cgi/man.cgi?query=ip&sektion=4&manpath=FreeBSD+9.0-RELEASE
> 
>      If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the
>      recvmsg(2) call will return the destination IP address for a UDP data-
>      gram.  The msg_control field in the msghdr structure points to a buffer
>      that contains a cmsghdr structure followed by the IP address.  The
>      cmsghdr fields have the following values:
> 
>      cmsg_len = sizeof(struct in_addr)
>      cmsg_level = IPPROTO_IP
>      cmsg_type = IP_RECVDSTADDR
> 
>      The source address to be used for outgoing UDP datagrams on a socket that
>      is not bound to a specific IP address can be specified as ancillary data
>      with a type code of IP_SENDSRCADDR.  The msg_control field in the msghdr
>      structure should point to a buffer that contains a cmsghdr structure fol-
>      lowed by the IP address.  The cmsghdr fields should have the following
>      values:
> 
>      [...]
> 
> 
> There is really no excuse to answer using the wrong IP :P

It is long-established and expected behaviour for UDP unless you
have a specific bind. IP_PKTINFO/IP_SENDSRCADDR are relatively new,
if they're supported at all (I have a feeling MacOS might still not
have IP_SENDSRCADDR).

> > I know the questions will come, so let me try to anticipate them and
> > answer them. Someone might ask why this isn't necessary with BIND. This
> > is because BIND attempts to detect the capability of the OS it's running
> > on, and compensate for the cases where these advanced options are not
> > present. This may make it easier for an operator, but at the expense of
> > more code complexity. I really do prefer NSD's simpler approach.
> 
> bind, powerdns, unbound and knot use these mechanisms. Someone should
> really just fix is for nsd as well.

You are correct about Unbound, PowerDNS and Knot. BIND doesn't
use these mechanisms at all, it looks up local addresses and binds to
all it finds unless instructed otherwise.