Going back a few weeks, we discussed how DNS over HTTPS (DoH) works (https://isc.sans.edu/forums/diary/Fun+with+NMAP+NSE+Scripts+and+DOH+DNS+over+HTTPS/27026/)  - very much as an unauthenticated API over HTTPS.  But DNS over TLS (DoT) has been with us for a fair bit longer (May 2016), why haven't we heard about it so much?

After wrestling with it for a bit, I can tell you why!

DoH is easy to work with, since we have so many HTTPS tools at our disposal.  Plus DoH was first implemented in browsers, and the browser developers *live* in HTTPS, so DoH is a cake-walk for them.  DNSSEC is basically plain old unencrypted DNS, but with signature records.

DoT on the other hand is a whole 'nother beast.  It's still basic DNS, but encapsulated in TLS.  So to make DoT calls we need a toolset to create TLS packets, then send and validate them using the certificate at the server side.  So the first tool that came to my mind of course was scapy, but read on, I used an easier method ..

To allow all of the mentioned DNS protocols to live on one server, DoT lives on tcp/853.  This makes for an easy NMAP scan if you're looking for this service.  NMAP tags the port correctly, but an NMAP version scan (-sV) won't identify  the DoT service.  It will however find some critical strings in the fingerprint, things like "DNSVersionBindReqTCP" and "DNSStatusRequestTCP" - so a version scan will validate the service enough for your eyes to see it, without calling it out definitively.  You can also of course validate the certificate on port tcp/853 using NMAP's ssl-cert.nse script or openssl:

Me, I took the easy way out for DoT queries and installed the knot-dnsutils (sudo apt-get install knot-dnsutils), which installs kdig to do all the heavy lifting for me.  As the name implies, kdig does just about everything that dig does, but for this task gives you parameters to make DoT queries.

So an A record query over DoT from kdig looks just very much like DOS query outpuyt from dig:

Note all the TLS session info at the top, and the port number in the last line.

As you'd expect, if you're just after answers you can use the +short parameter:

.. yup, I host my website on github, handiest github feature ever (ok, maybe not the handiest, but still pretty darned handy)

Other handy parameters in kdig?

• Just as in dig, you can always tack on the "-d" parameter for debug output
• +tls-hostname can be used to over-ride the server name during TLS negotiation.  This means you can even use the server's IP address when you use this parameter.
• Related to tls-hostname, +tls-sni adds the Server Name Indication field to the request

Without constructing the TLS packet, how can I use DoT in an NMAP script?  I again took the easy way out and used kdig, in combination with the lua command os.execute.  Yup, in the time honoured tradition of coding laziness I shelled out and executed the matching OS command!  In the DoH script I wrote I did a quick check to make sure that the host was running HTTP services on port 443 with "shortport.http".  In the DoT script I changed this, to ensure that TLS is running on the scanned port, using the "shortport.ssl" check.  An example scan is shown below:

You can find the DoT script here: https://github.com/robvandenbrink/dns-dot . Because is calls kdig, you'll need the knot-dnsutils package installed before this script will run.  If you're interested in combining NMAP scans with different OS commands you're welcome to review the source code and use whatever you need!

Do you have a handy nmap script that uses os.execute to do the "behind the scenes" work?  Please, share a link in our comment form!

References:
DoT RFD: https://tools.ietf.org/html/rfc7858

Usage Profiles for DNS over TLS and DNS over DTLS: https://tools.ietf.org/html/rfc8310

knot-dnsutils: https://www.knot-dns.cz/

===============
Rob VandenBrink
rob<at>coherentsecurity.com