We have a subnet running our legacy and primary DNS server where it remains as the last system on that subnet. Many things are pointing to that IP in resolv.conf, etc.,
We want to put the DNS server on the new subnet with all the other systems, to simply configuration on the new Fortinet firewall. It seemed a good solution would be to add a new IP to the legacy system so it would be on two subnets, and adjust named.conf so it was listening on both IPs. Later we could update the multiple external settings pointing to the legacy subnet and eventually take it down. After the second IP is brought up, we have something like this: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface XXX.YYY.2.0 * 255.255.255.0 U 0 0 0 eth0 XXX.YYY.200.0 * 255.255.248.0 U 0 0 0 eth1 link-local * 255.255.0.0 U 1002 0 0 eth0 link-local * 255.255.0.0 U 1003 0 0 eth1 default dyna2-1.mydom 0.0.0.0 UG 0 0 0 eth0 named is able to answer on either it's subnet 2 or subnet 200 address. However, systems on subnet 200 which have the XXX.YYY.2.ZZ address in the resolv.conf are timing out. If I try to ping the 2.ZZ address from a subnet 200 system, it fails. I think it is because the packet arrives at the 2.ZZ address, and it routes it through eth1 to get back to the subnet 200 destination. The remote subnet 200 system thinks the packet is spoofed since the answer came back from a IP different than it was sent to. Problems were restored simply by taking down eth1 for the time being. Is there an easy way to "make TCP/IP answer back on the same interface it was listening on when a packet is received"? I've seen articles mentioning multi-homing and balancing, but that doesn't seem to fit what we are looking for. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ca+akb6efwjkh9hpt7tlg5a-fqjdkrytc6wr1qgnla2+qpgp...@mail.gmail.com
