LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: UDP trouble with DNS setup.

To: Brett Johnson <mlipvs@xxxxxxx>
Subject: Re: UDP trouble with DNS setup.
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 14 Dec 2001 02:15:53 +0000 (GMT)
        Hello,

On Thu, 13 Dec 2001, Brett Johnson wrote:

> I've done a lot of DNS in the past and I always thought zone transfers were
> TCP.

        Yes, TCP but you said the UDP LVS rules block the UDP traffic
which is true with LVS but for setups that try to use bridging
to solve the problem with the direct connection from another
network segment (but from the same subnet) to the same real
server used before that for traffic through VIP.

> Apparently doing some sniffs, the following connection will occur:
> slaveDNS:53 -> masterDNS:53

        The usual problems with master-slave zone transfers are
that the slave does not like if the master uses unexpected IP to
notify for fresh zone. Also make sure there is access for the used
IP in the Slave when connection to the Master.

> I'm not sure what the UDP is for, but the actual zones are transferred by
> TCP.  I don't have any old DNS servers left laying around to check, but
> perhaps the UDP connections before the TCP connections are newer to BIND
> 9??? (who knows with them)
>
> This is what is killing me right now.
>
> I'm still a bit confused.
> Just for the sake of discussion, if the UDP transfers were:
> slaveDNS:HighPorts -> masterDNS:53
> Would LVS let the UDP packets pass???

        Yes, this is handled via NAT rules out of LVS control.
May be the problem is that master sees connection from unexpected
source IP after SNAT-ing the traffic from slave.

> I'm not really that worried about "untracked packets" as with my main setup
> I have iptables rules all around them.  Which leads up to another
> question...
>
> To use connection tracking, I can use "-m state" in iptables or the LVS
> commands, but not both?

        LVS has separate connection tracking and such commands don't
work for its connections. You can also try to remove temporary all
your firewall rules. Or to select good preferred source IP for your
route to the master IP. A tcpdump session can show where is the
problem.

> Thanks/B++

Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>