01 Mar

Encrypted DNS using DNSCrypt

Writing this post from my hotel room in Kathmandu. I found that many of the servers appear to be DNS resolvers which is unusual.



This seems unusual and is the result of basically port 53 DNS hijack. Let’s try to verify it using popular “whoami.akamai.net” query.

So clearly something in middle is hijacking DNS queries and no matter whichever DNS resolver I try to use, the queries actually hit authoritative DNS via This belongs to WorldLink Communications (ISP here in Nepal) and I am just 5 hops away from it.


So what can be done about these cases? Well, one way is VPN of course but with a setup where VPN server’s IP address is hardcoded in the client and not using DNS. It works and does the task but performance can vary greatly depending on how far is the tunnel server. A better and more modern way out of it is by using encryption in DNS by using a protocol named “DNSCrypt“. DNSCrypt offers to encrypt of DNS queries from clients to the DNS resolvers. (Beyond that resolver still, follow usual non-encrypted root chain to reach authoritative DNS servers).


So how does it work?

There’s no integrated support of DNSCrypt in OS’es at this time. There are number of projects like dnscrypt-osxclient available on GitHub which enable this support.  Once configured, the client changes system’s DNS resolver to a local IP which listens for port 53 (regular/non-encrypted) requests.

The client often offers support of various open resolvers like OpenDNS, Quad9 etc.



Here it shows that DNS resolver in my case happens to be Cisco’s OpenDNS. As soon as the client gets port 53 DNS queries, it encrypts it and sends via UDP port 443 (UDP or TCP depending on provider and client configuration). The encyption is based on trusted root CA’s and associated chain as popularly used in HTTPS. This is also one of reasons why DNSCrypt is also known as DNS over HTTPS.


Here’s an example of a DNS query to resolve A record of google.com while running tcpdumps in parallel:

This shows request went in clear text to which is configured on loopback. While in parallel if I watch for traffic towards OpenDNS public IPs, I get:

Thus all that appears here is just an encrypted packet to Cisco OpenDNS over UDP port 443.

I ran another query and saved it in pcap file. Here’s how it looks like in wireshark:




That’s all about it for now. I am going to keep encryption enabled especially when travelling from now onwards. Time to get some sleep. 🙂


Useful Links:

  1. dnscrypt-osxclient – https://github.com/alterstep/dnscrypt-osxclient
  2. DNSCrypt Wikipedia – https://en.wikipedia.org/wiki/DNSCrypt
  3. DNS Over HTTPS (Google Public DNS) – https://developers.google.com/speed/public-dns/docs/dns-over-https
  4. DNS over TLS (Quad9) – https://quad9.net/faq/#Does_Quad9_support_DNS_over_TLS
31 May

BGP Administrative Shutdown Communication

I recently came across an excellent draft at IETF by Job Snijders &  friends.  This is to address scenarios where a network might miss communication about a maintenance activity when BGP shutdown happens. Once implemented, this can potentially offer to send peer a message with up to 128 bytes with info about shutdown like “Ticket XXX: We are upgrading the router, will be back live in 1hr” etc. It depends by appending such data to the sys notification which is part of BGP protocol. This is one which sends a message just before the shutdown of the session. So it similar to the way you see session tearing down due to prefix limits etc. This has already been implemented in some of the open source routing implementations like OpenBGPd, GoBGP, PMacct, Exabgp etc.


Here’s the latest draft of this change: https://tools.ietf.org/html/draft-ietf-idr-shutdown-09. And here’s Job’s talk from NANOG conference at the start of this year.


Hopefully, we will see this implemented across large vendor routers!