DNS Proxy

In a typical hub/spoke deployment, its very common for the WAN interfaces to have some sort of dynamic interface such as DHCP, PPPoE, LTE, etc. The SSR can dynamically learn the DNS server address for these interfaces and can load balance DNS requests across the learned servers. The dns-proxy feature aims to provide a simple way to proxy all DNS requests originating on the LAN side to the learned server address(es) on the WAN side without having to re-configure or update client endpoints. This allows the network to better adapt to failures on the WAN interfaces while minimizing loss of connectivity from client side applications as clients can utilize the LAN address of the SSR to resolve DNS requests.

Overview

The common workflow for using this feature is as follows:

Configure a DNS server for the LAN network(s)
Configure a DNS proxy service to match the advertisement
Configure a service-route to indicate the WAN interface(s) to be used for proxying DNS requests

Advertise Interface Address as DNS Server

A key component for DNS proxy is the ability to configure a fixed address as the DNS address for the clients on the LAN. A typical choice is to use the LAN-facing SSR interface address as the DNS server address, though the feature is not limited to this choice. The selected address can either be statically configured on the clients or configured via DHCP server (either external or SSR acting as the DHCP server).

On a linux system representing a client, its /etc/resolv.conf file would contain similar contents:

; generated by /usr/sbin/dhclient-script
search openstacklocal
nameserver 10.10.10.1

Configuring a DNS proxy service

The special dns-proxy application-type is used for creating a DNS proxy service. All other service attributes such as access-policies, service-policies, etc., are also applicable to this service. The dns-proxy application-type indicates to the SSR to perform a destination NAT on the traffic when the session is created for the service.

admin@node1.conductor# show config running authority service lan-dns-proxy

config

    authority

        service  lan-dns-proxy
            name              lan-dns-proxy

            transport         udp
                protocol    udp

                port-range  53
                    start-port  53
                exit
            exit
            address           10.10.10.1

            access-policy     lan
                source      lan
                permission  allow
            exit

            access-policy     _internal_
                source      _internal_
                permission  allow
            exit
            application-type  dns-proxy
        exit
    exit
exit

admin@node1.conductor#

The example configuration captures all DNS traffic sent to address 10.10.10.1 interface as configured on the test client in the previous step.

How to proxy DNS requests originating from the linux host of the SSR

The _internal_ tenant has a special meaning on the SSRs as it represents the traffic originating from the host OS of the router. When the service allows the _internal_ tenant and a service-route is created for this service, the target router linux environment is automatically configured for use with the DNS proxy. The /etc/resolv.conf on the SSR is modified to point to a loopback address within the SSR.

; This file has been automatically updated by SSR - DO NOT EDIT
nameserver 169.254.127.126

This allows all DNS queries (for example, as a result of dnf lookups, etc.) to be intercepted by SSR and create sessions appropriately.

Additionally, this loopback address needs to be added to dns-proxy service.

config
    authority
        service  lan-dns-proxy
            name              lan-dns-proxy
            ...
            address           10.10.10.1
            address           169.254.127.126
            ...
            application-type  dns-proxy
        exit
    exit
exit

note

The /etc/resolv.conf file can also be configured to point to the LAN interface address to achieve the same results.

Configuring Service Route(s)

When the service route's next hop for the dns-proxy service points to a dynamic interface such as DHCP based interface, any learned DNS address(es) will be automatically used as destination nat target for sessions for that service. This is accomplished by populating the next-hop > target-address configuration internally upon address resolution. An example of the service-route configuration is as follows:

admin@node1.conductor# show config running authority router router1 node node1 device-interface inband-mgmt

config

    authority

        router  router1
            name  router1

            node  node1
                name              node1

                device-interface  inband-mgmt
                    name               inband-mgmt
                    pci-address        0000:00:03.0

                    network-interface  inband-mgmt-intf
                        name          inband-mgmt-intf
                        global-id     1
                        conductor     true
                        tenant        wan
                        source-nat    true

                        host-service  ssh
                            service-type  ssh
                        exit

                        host-service  web
                            service-type  web
                        exit

                        dhcp          v4
                    exit
                exit
            exit
        exit
    exit
exit

admin@node1.conductor# show config running authority router router1 service-route dns-proxy-route

config

    authority

        router  router1
            name           router1

            service-route  dns-proxy-route
                name          dns-proxy-route
                service-name  lan-dns-proxy

                next-hop      node1 inband-mgmt-intf
                    node-name  node1
                    interface  inband-mgmt-intf
                    target-address 8.8.8.8
                exit
            exit
        exit
    exit
exit

admin@node1.conductor#

A few key points about the service-route for a dns-proxy service type:

Multiple learned DNS addresses

If the dynamic interface learns multiple IP addresses, the SSR will apply a round-robin load-balancing strategy amongst these IP address. Here's how you can check the details on the learned DNS addresses.

admin@node1.conductor# show dhcp v4 router router1 name inband-mgmt-intf detail
Sat 2020-02-22 04:43:12 UTC

============================================================
 Router
============================================================
  Node:                            node1
    Device Interface:              inband-mgmt
      Network Interface:           inband-mgmt-intf
        Dhcp State:                Resolved
          State Machine State:     Bound
          Lease Start Time:        Sat Feb 22 00:28:30 2020
          Lease Renewal Time:      Sat Feb 22 12:28:30 2020
          Lease Rebinding Time:    Sat Feb 22 18:28:30 2020
          Lease Expiration Time:   Sun Feb 23 00:28:30 2020
          Learned MTU:             0 bytes
          Server Address:          192.168.1.2
          Dns Server Address:
            - 172.20.0.100
            - 172.20.0.101
          Addresses:
            Address:               192.168.1.10
            Prefix Length:         24
            Gateway:               192.168.1.1

Completed in 0.14 seconds
admin@node1.conductor#

The following example illustrates how the round-robin strategy gets applied for load-balancing the data across multiple learned addresses for two back-to-back queries.

admin@node1.conductor# show sessions router router1 | grep dns-proxy
✔ Piping output...
 745809ea-7ada-4225-a379-4159c1e226a2   fwd   lan-dns-proxy                                     lan          dpdk2            0   udp     10.10.10.11          52513   10.10.10.1               53   192.168.1.10         16398   false                     4   0 days  0:00:03
 745809ea-7ada-4225-a379-4159c1e226a2   rev   lan-dns-proxy                                     lan          inband-mgmt      0   udp     172.20.0.100            53   192.168.1.10          16398   0.0.0.0                  0   false                     4   0 days  0:00:03

admin@node1.conductor# show sessions router router1 | grep dns-proxy
✔ Piping output...
 801d9495-66a4-44cf-9eea-e22731389a95   fwd   lan-dns-proxy                                     lan          dpdk2            0   udp     10.10.10.11          44426   10.10.10.1               53   192.168.1.10         16399   false                     5   0 days  0:00:03
 801d9495-66a4-44cf-9eea-e22731389a95   rev   lan-dns-proxy                                     lan          inband-mgmt      0   udp     172.20.0.101            53   192.168.1.10          16399   0.0.0.0                  0   false                     5   0 days  0:00:03

Manually configured `target-address`

As seen in the example above the service-route > next-hop points to a DHCP interface and also specifies 8.8.8.8 as the target-address. When this configuration is present, the learned address are combined with the statically configured address(es). Based on the previous example, this means that there will be three DNS server targes (8.8.8.8, 172.20.0.100, 172.20.0.101). This configuration also allow the user to configure a failsafe DNS server address in case the DHCP server did not provide any valid DNS server addresses.

Overview​

Advertise Interface Address as DNS Server​

Configuring a DNS proxy service​

How to proxy DNS requests originating from the linux host of the SSR​

Configuring Service Route(s)​

Multiple learned DNS addresses​

Manually configured target-address​