BIND and listening on interfaces
Sam Wilson
Sam.Wilson at ed.ac.uk
Fri Aug 1 16:13:06 UTC 2014
In article <mailman.722.1406907165.26362.bind-users at lists.isc.org>,
Reindl Harald <h.reindl at thelounge.net> wrote:
> Am 01.08.2014 um 17:16 schrieb Barry Margolin:
> > In article <mailman.720.1406904401.26362.bind-users at lists.isc.org>,
> > Reindl Harald <h.reindl at thelounge.net> wrote:
> >
> >> the thread yesterday reminded me on my Fedora bugrpeort
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c3
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c8
> >>
> >> i don't buy "Note that destination IP address must be
> >> known and set correctly in reply, otherwise clients
> >> will be confused" because how does it survive NAT
> >
> > What's meant is that the source address of the reply must match the
> > destination address of the request. This is the how TCP behaves
> > automatically, since it involves connections, but all UDP packets are
> > independent. When BIND sends a reply message, the stack doesn't know
> > that it's related to a particular incoming message whose IPs should be
> > flipped.
> >
> > It survives NAT because the router remembers how it translated the
> > incoming packet. When it sees an outgoing packet with the translated IP
> > and port, it undoes the translation
>
> yes and no
>
> iptables knows the concept of " -p udp -m conntrack --ctstate NEW"
> so the stack somehow knows, not the same way as TCP but it knows
>
> other UDP services like OpenVPN, dhcpd, avahi or mediathomb just
> listening on UDP 0.0.0.0:port and just working
Works fine on single-homed hosts, can break on multi-homed hosts.
Sam
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the bind-users
mailing list