DNS Redirection

[Sunny2]

Hi,

I have a PBR issue which I can't get my head around.

We have several thousand user currently using DNS severs say for example 10.xx.xx.10 and 10.xx.xx.11. These are supplied by a 3rd party and we are now looking to use our own servers and need to redirect trafficking over the next year and eventually replace the 3rd party ones with ours 192.xx.xx.10 and 192.xx.xx.11. So I guess I am looking DNAT and DNS redirection. I haven't touched PBR for a long time and wonder if anyone can help? Many thanksDNS Redirection, Other Routers

[Deepak Kumar]

Hi,

Your question is not clear. Do you want to change the routing path?

As you said that your current servers IPs are 10.x.x.10 and 10.x.x.11 and you are implementing new servers in 192.x.x.10 and 192.x.x.11. So you want to place the DNS server. This you can do it from the DHCP server. I don't think it will require any Routing (PBR) involved. 

As this is in the testing phase so you can change Secondary DNS server IP address to the 192.x.x.10. If your new DNS server (192.x.x.10) will goes not due to some issue then client's will not face any issue because the primary DNS server is working fine.

If you want that your client will send DNS queries on the 10.x.x.10 and on behalf of this your newly DNS server will resolve the queries with IP 192.x.x.10. then we need your network topology. It will involve NATing, Routing, and PBR.

Regards,

Deepak Kumar

[Sunny2]

Thank you for the replies guys.

We can't change DNS servers being used which belong to a 3rd party to ours at once as there are hundreds of hard coded machines across the estate. We need a gradual approach so that a year down the line our servers would have learnt all the routes and then we can switch over. So, ideally we need to NAT the traffic from the current servers to  the new ones that we will switch over to completely in a year's time.

[paul driver]

Hello

---

@Sunny2 wrote:

We need a gradual approach so that a year down the line our servers would have learnt all the routes and then we can switch over. So, ideally we need to NAT the traffic from the current servers to  the new ones that we will switch over to completely in a year's time.

---

You could introduce Internal DNS servers to be forwarders so any queries that need to cross the NAT boundary can.

what you cannot do is have these internal dns servers to become secondary dns to these 3rd party servers as zone transfer will fail because the information in that zone file will not be translated over the nat boundary.

[Deepak Kumar]

Hi,

I am not sure about your Setup but this is a solution from my side. 

Here is my LAB:

Special Note:

1. I am using GRE Tunnel for redirect traffic on fake IP address. This Fake IP is configured on R1 under the Loopback interface (10.10.10.10).

2. New DNS server IP address is 192.168.10.10

3. Old DNS Server IP address is 10.10.10.10

R1 Configuration (New DNS is installed on the R1)

!
interface Loopback0
ip address 10.10.10.10 255.255.255.255
ip nat enable
!
interface Tunnel1
ip address 192.168.200.1 255.255.255.0
no ip redirects
tunnel source 1.1.1.1
tunnel mode gre multipoint
!
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255.0
duplex half
!
interface FastEthernet1/0
ip address 192.168.10.1 255.255.255.0
ip nat enable
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 172.16.1.1 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 1.1.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255

network 192.168.10.0 0.0.0.255
!
ip nat inside source static 192.168.10.10 10.10.10.10
!
!

R2 Configuration

!

interface Tunnel1
ip address 192.168.200.2 255.255.255.0
tunnel source 1.1.1.2
tunnel destination 1.1.1.1
!
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.0
duplex half
!
interface FastEthernet1/0
ip address 2.2.2.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 172.16.2.1 255.255.255.0
ip policy route-map DNS-192.168.10.10
duplex auto
speed auto
!
!
router eigrp 1
network 1.1.1.0 0.0.0.255
network 2.2.2.0 0.0.0.255
network 172.16.2.0 0.0.0.255
!
ip access-list extended DNS-192.168.10.10
permit ip any host 10.10.10.10
!
!
route-map DNS-192.168.10.10 permit 10
match ip address DNS-192.168.10.10
set ip next-hop 192.168.200.1
!
!

R3 Configuration:

!
interface Tunnel1
ip address 192.168.200.3 255.255.255.0
tunnel source 2.2.2.2
tunnel destination 1.1.1.1
!
interface FastEthernet0/0
ip address 172.16.3.1 255.255.255.0
ip policy route-map DNS
duplex half
!
interface FastEthernet1/0
ip address 3.3.3.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 2.2.2.2 255.255.255.0
duplex auto
speed auto
!
!
router eigrp 1
network 2.2.2.0 0.0.0.255
network 3.3.3.0 0.0.0.255
network 172.16.3.0 0.0.0.255
!
access-list 100 permit ip any host 10.10.10.10
no cdp log mismatch duplex
!
route-map DNS permit 10
match ip address 100
set ip next-hop 192.168.200.1
!
!

R4 Configuration

!

interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
duplex half
!
interface FastEthernet1/0
ip address 3.3.3.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 172.16.4.1 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 3.3.3.0 0.0.0.255
network 10.10.10.0 0.0.0.255
network 172.16.4.0 0.0.0.255
!

LAB Result

PC-2> tracer 10.10.10.10
trace to 10.10.10.10, 8 hops max, press Ctrl+C to stop
1 172.16.2.1 7.612 ms 9.232 ms 9.131 ms
2 *192.168.200.1 30.496 ms 

!

PC-3> tracer 10.10.10.10
trace to 10.10.10.10, 8 hops max, press Ctrl+C to stop
1 172.16.3.1 2.063 ms 9.459 ms 10.667 ms
2 *192.168.200.1 29.783 ms 

PC-3> ping 10.10.10.10
84 bytes from 10.10.10.10 icmp_seq=1 ttl=253 time=50.648 ms
84 bytes from 10.10.10.10 icmp_seq=2 ttl=253 time=32.737 ms
^C

I hope it will help you to resolve your issues. Let me know if you any other question.

Regards,

Deepak Kumar

[Sunny2]

Thanks Deepak,

But I think what I'm looking seems more closer to this: I think it needs some modification but might work. Sadly, I don't have a lab to try it in and modify.

ip access-list extended transparent_dns
permit udp any any eq 53

route-map redirect_dns permit 10
match ip address transparent_dns
set ip next-hop ip.of.your.server
route-map redirect_dns permit 20

interface fax/x
ip address xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
ip policy route-map redirect_dns

[Deepak Kumar]

Hi,

ip access-list extended transparent_dns
permit udp any any eq 53

This will not work because as you have checked my lab, we have to make a fake duplicate IP address which will respond in absence of the original IP. So We had to work on original DNS server IP (10.10.10.x) but

what if the client will try with 8.8.8.8 as DNS server? It will fail and create routing loops for DNS packets. 

Regards,

Deepak Kumar

[Deepak Kumar]

Hi,

Are you using any Dynamic routing protocol?

Regards,

Deepak Kumar

[paul driver]

Hello

@Deepak Kumar
The clients will be obtaining their dns listing from dhcp ( assumption)
This listing can be changed per sa so each internal network could re pointed as /when to their own internal DNS

For testing purposes selected clients can be individually selected to point to their new internal dns server.

The internal dns server(s)can be made to forward any quires they cannot resolve to a upstream server (public)  so no need for any PBR as far as I can see, however something is saying this is not as simple as the above, Email is one thing that comes to mind!

[Deepak Kumar]

Hi @paul driver 

I asked the same question and  he replied

We can't change DNS servers being used which belong to a 3rd party to ours at once as there are hundreds of hard coded machines across the estate.

So, I created a lab and shared a possible solution for him. I never implemented this solution in production but got an idea from Google's Unicast DNS (8.8.8.8) IP advertisement in BGP. 

Regards,

Deepak Kumar 

[Jon Marshall]

I agree with Deepak here, I am not sure why you need to use NAT and/or PBR for this. 

Can you not just update the DNS servers for the clients as you migrate across, would be a lot simpler. 

Jon

[marce1000]

 - It would be more desirable to use standard DNS architecture and protocols  such as  slave-master configurations and the setup of revolvers. Migrate these components and settings according to your needs.

M.

[Sunny2]

The DNS servers we use are 3rd party servers which are also used by thousands of their clients. We have been using these for many years. 

---

@marce1000 wrote:

 - It would be more desirable to use standard DNS architecture and protocols  such as  slave-master configurations and the setup of revolvers. Migrate these components and settings according to your needs.

M.

---

[marce1000]

 - Don't defy your own project and secondly , DNS and especially DNS should not operate in an inter-mixed setup with other layers of the network-stack.

 M.

[paul driver]

Hello

---

@Sunny2 wrote:

---

@marce1000 wrote:

 - It would be more desirable to use standard DNS architecture and protocols  such as  slave-master configurations and the setup of revolvers. Migrate these components and settings according to your needs.

M.

---

---

My understanding that's not possible over nat, Because as I said the zone transfer between the NAT boundary will fail

You should however be able to create new internal dns server and have them forward unresolved quires to your external dns server