Re: UDP trouble with DNS setup.

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: UDP trouble with DNS setup.
From: "Brett Johnson" <mlipvs@xxxxxxx>
Date: Thu, 13 Dec 2001 19:45:08 -0600
*********** REPLY SEPARATOR ***********

On 12/14/01, at 2:15 AM, Julian Anastasov wrote: 

>On Thu, 13 Dec 2001, Brett Johnson wrote:
>> I've done a lot of DNS in the past and I always thought zone transfers
>> 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.

I have observed that when I add the mentioned rule with ipvsadm that the
UDP DNS 53->53 traffic going out stops.  If I remove that rule in the
script I pasted in the first email, all UDP traffic works just fine.  Just
to clarify, the zone transfer process is using both UDP and TCP to do the
transfer.  Typically when I manually do name lookups, they are UDP
HighPort->53.  I don't know what the BIND people were thinking when they
originally wrote it. :-\  I would think by definition a slave DNS server
would not care about the IP of the master when trying to retrieve its zones
for the first time...but this is getting off topic...

>       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.

With my MASQUERADE rules, I'm not doing anything with the VIP, though.
Originally I was...and was having these problems, so I simplified it to
make everything go out the firewall's IP to make sure the master DNS server
didn't see 2 IP's trying to connect to it for the zone transfer.

It looks like I should try the 0.9.8 patch you mentioned and turn off the
unknown UDP block.  I've noticed that 0.9.8 is in the development side.
How stable is it for light production use?

>       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

Right now I set up my iptables rules by getting the connection to work
first then trying the blocks.  Needless to say that this is rather tedious.
 I really don't like having the OS exposed to open Internet (many others
are with me on that) this leads to another question (perhaps a feature

How hard would it be to tell LVS to just drop everything it doesn't have an
entry for in the ipvs table???
An example would be:  I alias an IP address for the intent of LVS usage.
Perhaps make it an option I can turn on to say that anything that doesn't
show up in the "ipvsadm -Ln" table gets dropped for that aliased IP only.
From a security stand point this would be really great as rules can be
easily written for the real IP that wont get any LVS entries anyway.


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