Unbreaking the Internet and Converting Protocols

Hi,

Very good article. But I have to admit it's quite a challenge for me to figure out everything described. For example resolving first issue. My assumptions for setup involving BIG-IP are:

• Internet router is still configured with static route 1.1.1.1/32 gw 192.168.1.66 (probably 1.1.1.1 is configured on Linux loopback here?)
• You actually cheating a bit :-) as with above config you are really not able to send DNS request to 1.1.1.1 on the Internet, sure if 1.0.0.1 is as well DNS it's working but what if not? With such router setup it's not possible to really send traffic destined to 1.1.1.1 to the Internet - or I am missing something here?

DNS over TLS

Sorry for lame question but I am by far no DNS expert. As far as I understand DNS caches on BIG-IP for your setup two VS are required:

• VS (DNS_vs - my name here) to accept actual client DNS request (over UDP?) with DNS profile attached. Profile has DNS cache enabled with your resolver cache selected (CF)
• VS (dns_over_tls) doing TLS encryption (one configured in resolver cache Forwarding Zones tab)

Now how UDP is converted to TCP? dns_over_tls VS is TCP protocol, so it will not accept UDP packets. Will DNS_vs respond to clients requesting resending DNS queries over TCP? Some other way?

DNS over HTTPS

This is hard because I am not familiar with both RFC and JavaScript (iRuleLX - know the basic but never used).

I am not sure how previously configured (192.168.1.254) is used by iRuleLX - as proxy to send HTTPS request to cloudflare-dns.com?

So rule is just generating HTTP request with DNS binary (base64 encoded) inserted as HTTP payload and VS is just encrypting it and sending to cloudflare? Then response from cloudflare is decrypted by VS returned back to rule, HTTP payload extracted (being binary DNS response) and returned to iRule and then to requesting client - is that more or less how it works?

Is the same configuration as for DNS over TLS used by 192.168.1.254 VS or it has to be updated? What actually is in the VS Pool - list of DNS servers accepting TLS (or HTTPS) encrypted DNS requests?

Piotr

Piotr,

Great observations!

A. Unbreaking the Internet:

Re: do I use 1.1.1.1/32 on loopback on the server?

Yes. Not mentioned in the article I also use DSR on the BIG-IP to reduce one hop of traffic.

Traffic flow: 
client -> home router -> 
BIG-IP -> server -> 
client

Re: cheating

I am COMPLETELY cheating. In my home setup; once I changed my home router to point to the BIG-IP there's no way for the BIG-IP to connect back out (creates a routing loop). My only option was to point to 1.0.0.1. In an environment where the BIG-IP had a direct interface to the Internet you could route directly to 1.1.1.1.

Traffic flow: 
Client -> Internal Switch -> 
BIG-IP Internal Interface -> BIG-IP External Interface -> 
Internet

B. DNS over TLS

Re: How does UDP become TCP

The trick is that when you have a DNS profile that references a cache, you are turning the BIG-IP into another DNS client (initiates a completely new connection). So the flow is:

Client DNS Request (UDP request) -> [BIG-IP DNS] DNS_vs -> 
BIG-IP Cache DNS Request (TCP request) -> [BIG-IP DNS] dns_over_tls -> 
BIG-IP dns_over_tls (TCP/TLS request) -> [DNS over TLS (TCP port 853)]

C. DNS over HTTPS

This is bit convoluted, I did use the same IP address/port that adds to the confusion.

Your description is spot-on. There is a separate virtual server from the previous example. This is a case where you have:

192.168.1.254:53 TCP -> DNS over TLS (just performing TLS upgrade)
192.168.1.254:53 UDP -> DNS over HTTPS (performing conversion from UDP to HTTPS requests)

Somewhat like how Google uses UDP 443 for QUIC vs. TCP 443 for HTTPS; I am re-using the same port for two DIFFERENT services.

I meant for the article to be a progression of challenges. You did very well!

Eric

One more VS that I didn't mention, here's the complete list (separated for clarity):

      1.1.1.1:53 UDP -> To 1.0.0.1
      1.1.1.1:80 HTTP -> To server
192.168.1.113:53 UDP -> DNS Cache (DNS over TLS)
192.168.1.114:53 UDP -> DNS Cache (DNS over HTTPS)
192.168.1.254:53 TCP -> DNS over TLS (just performing TLS upgrade)
192.168.1.254:53 UDP -> DNS over HTTPS (performing conversion from UDP to HTTPS requests)
192.168.1.253:80 TCP -> HTTP to HTTPS (validate HTTPS server certificate, upgrade from HTTP to HTTPS)

In the article I only reference a single DNS cache, but the above example assumes that you use two separate caches (one configured for only clientside UDP and the other only for clientside TCP)

In my article the corresponding pools

      1.1.1.1:53 UDP -> pool: 1.0.0.1
      1.1.1.1:80 HTTP -> pool: 192.168.1.66
192.168.1.113:53 UDP -> DNS cache forward . -> 192.168.1.254:53 TCP
192.168.1.114:53 UDP -> DNS cache forward . -> 192.168.1.254:53 UDP
192.168.1.254:53 TCP -> 1.0.0.1:853 (w/ serverssl profile)
192.168.1.254:53 UDP -> iRule + iRuleLX that calls 192.168.1.253:80
192.168.1.253:80 TCP -> FQDN pool to cloudflare-dns.com

Hi,

Thanks a lot for explanations. I have to dig in to be sure if I got it now. Keep going with articles like that. Plenty of nice tricks I would never figure out by myself.

Piotr

After reading this very good article, I wanted to implement DNS over TLS using the BIG-IP in my lab environment. I decided to write this comment in case anyone is having the same trouble that I had and to make sure that I got everything correct. 

So, The idea is the following: 

• configure a simple virtual server listenning on port UDP 53 (dns_listener) . Assign to that virtual server a DNS Profile that in turn references a Cache Resolver profile
• configure the Cache Resolver profile to send DNS queries in TCP only
• configure a simple virtual server (kabe_vs_DNSoTLS) that listens on TCP port 853 and assign a Pool and SSL server profile to it. 
• configure the Cache Resolver profile to forward the zone "." (everything) to the IP address of the TCP virtual server (kabe_vs_DNSoTLS)

please find below my configuration. Feel free to ask question or to give me suggestions.

ltm dns cache resolver /Common/kabe_cache_resolver {
    forward-zones {
        . {
            nameservers {
                10.10.1.51:53 { }
            }
        }
    }
    route-domain /Common/0
    use-udp no
}
 
ltm profile dns /Common/kabe_dns_profile {
    app-service none
    cache /Common/kabe_cache_resolver
    defaults-from /Common/dns
    enable-cache yes
}
 
 
ltm virtual /Common/dns_listener {
    creation-time 2019-11-25:21:06:30
    destination /Common/10.10.1.50:53
    ip-protocol udp
    last-modified-time 2019-11-25:22:42:12
    mask 255.255.255.255
    profiles {
        /Common/kabe_dns_profile { }
        /Common/udp_gtm_dns { } /* this is a standard UDP layer 4 profile */
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
}
 
ltm pool /Common/kabe_DNSoTLS {
    members {
        /Common/1.1.1.1:853 {
            address 1.1.1.1
        }
    }
    monitor /Common/gateway_icmp
}
 
 
ltm virtual /Common/kabe_vs_DNSoTLS {
    creation-time 2019-11-25:21:14:12
    destination /Common/10.10.1.51:53
    ip-protocol tcp
    last-modified-time 2019-11-25:23:44:16
    mask 255.255.255.255
    pool /Common/kabe_DNSoTLS
    profiles {
        /Common/f5-tcp-lan {
            context clientside
        }
        /Common/f5-tcp-wan {
            context serverside
        }
        /Common/serverssl { /*I used the default Server SSL profile */
            context serverside
        }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
}

hope it helps,

Many thanks