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