Alternative DNS Techniques
“What’s in a name? That which we call a rose By any other name would smell as sweet.”
— William Shakespeare’s Romeo and Juliet, Act II Scene 1
Since humans aren’t good at memorizing IP addresses (22.214.171.124 is a bit much to remember), we need a way to convert between www.whitehouse.gov and that IP address. DNS – the Domain Name System – is the general term for this conversion between Internet names and IPs. We also have Netbios names which are most commonly used on networks of Windows machines but are also supported on Linux and other operating systems.
In this reference, we’ll look at the different ways of looking up DNS and Netbios names, with a focus on how the different approaches can be identified on your network.
DNS Format Requests and Replies
DNS (“Domain Name System”) objects are names that end in one of the common top level domains (“.com.”, “.org.”, “.jp.”, “.internal.”, etc.). The tools that allow you to both publish these records (DNS name servers) and look them up (resolvers, which convert them to IP addresses) are available for all platforms.
DNS can carry many more traffic types than just hostname lookups, but for this article we’ll focus just on those.
Not a traffic type, but a standard file location for a static list of IPs with their hostname(s). Can be used to override DNS lookups.
On MacOS, Linux, and the other Unixes this is stored at /etc/hosts . On windows systems it’s found in c:\Windows\System32\drivers\etc\hosts .
ip.address name optionalsecondname optionalthirdname #Comment
DNS requests are sent as UDP packets to a server listening on port 53. Replies (with the original request, any answers, and any errors) are sent back to the original client.
These requests are unencrypted.
To see what name servers a system is using look at the “nameserver ….” lines in /etc/resolv.conf on Macs and Linux systems, or see the DNS settings under “Network Properties/Advanced” in Windows settings.
Similar to UDP DNS, these TCP connections are sent to port 53 at the server. Replies come back in the same connection. TCP DNS is primarily used for Zone transfers (sending an entire zone from the master DNS server to the slave). It was also used for large answers, though these can usually be handled in UDP DNS now. These may not be used at all if TCP port 53 traffic is blocked at the firewall.
Like UDP DNS, these are unencrypted.
Multicast DNS uses (almost) the same packet format as UDP DNS requests and replies. Unlike UDP DNS, mDNS is sent and received on the local network only.
All hostnames in mDNS should end in “.local.” instead of one of the normal top level domains like “.com.” or “.us.”.
Traffic sent to one of two multicast addresses: 126.96.36.199 (mac: 01:00:5E:00:00:FB) or ff02::fb (mac: 33:33:00:00:00:FB), udp port 5353
mDNS traffic is unencrypted.
Link-Local Multicast Name Resolution/LLMNR
LLMNR is very similar to mDNS; they both use (mostly) multicast and are both intended for clients and servers on the same network.
Where mDNS has all objects under the “.local.” top level domain, LLMNR can be used to publish real DNS objects, and therefore could conflict with real DNS requests (though it’s supposed to be queried after a real DNS lookup has failed).
Server listens on 188.8.131.52 (mac: 01:00:5E:00:00:FC) and/or FF02::1:3 (mac: 33:33:00:01:00:03), UDP port 5355 and/or TCP port 5355
LLMNR was originally designed for Windows, though a Linux implementation exists as well. There does not appear to be an OS/X implementation. Since Windows 10 supports mDNS and LLMNR was not accepted by the IETF, mDNS is the more likely interoperable tool.
LLMNR is unencrypted.
DNS over TLS (DoT)
This approach takes standard DNS requests and places them inside a TLS outer shell. These encrypted packets are sent to a DoT server on TCP port 853.
DNS over HTTPS (DoH)
Similar to DNS over TLS, except that the requests are placed inside of an encrypted HTTPS connection to TCP port 443 instead of a raw TLS connection.
Known DoH server lists:
Additional DOH servers:
Quad9 dns.quad9.net, dns9.quad9.net, dns10.quad9.net 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199 2620:fe::fe, 2620:fe::fe:9, 2620:fe::9, 2620:fe::fe:9, 2620:fe::10, 2620:fe::fe:10
Google dns.google, dns.google.com 188.8.131.52, 184.108.40.206 2001:4860:4860::8888, 2001:4860:4860::8844
Cloudflare cloudflare-dns.com, mozilla.cloudflaredns.com 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199 2606:4700:4700::1111, 2606:4700:4700::1001, 2606:4700::6810:f9f9, 2606:4700::6810:f8f9
Oblivious DNS over HTTPS (ODoH)
Like DoH, but requests are routed through a proxy first so the HTTPS DNS server cannot correlate the request with its original source IP and the proxy cannot see the actual queries and responses. In design.
Like DNS over HTTPS, this traffic is encrypted.
DNS over QUIC (DoQ)
Similar to DNS over HTTPS, but instead of using HTTPS as a carrier, this uses QUIC (a lower latency form of TCP+TLS).
This traffic is encrypted.
Netbios and DNS are two totally different ways of associating names to computers. Netbios got its start in Windows and is still used there to identify hosts, but DNS is a more global tool.
This file is similar to /etc/hosts used in DNS in that both associate an IP address with a hostname, one per line. Note that this is only used for Netbios names, not for DNS lookups.
ip.address name #Comment
Netbios Name Resolution
The first routable netbios name lookup approach was the Netbios Name Service. These requests and replies are carried over UDP port 137 (though technically TCP port 137 is also supported). It is only supported on IPv4 – there’s no support on IPv6.
This traffic is unencrypted.
This has been deprecated; it’s replacement is SMB over TCP/IP.
SMB over TCP/IP
The original approach of carrying Netbios over udp and tcp ports 137-139 was later replaced with a lightweight and faster approach of carrying Netbios over TCP (or UDP) port 445.
This traffic is encrypted.
Both Netbios and SMB over TCP/IP depend on hosts either broadcasting their names or broadcasting queries. A WINS server is a central place to hold netbios name data on a network.
Peer Name Resolution Protocol
Microsoft released a naming system for IPv6-enabled systems called PNRP. The published names can be either unsigned or signed.
PNRP appears to be only used in Windows.
To look up a DNS name, you can simply “ping” it:
ping -c 3 www.whitehouse.gov. PING e4036.dscb.akamaiedge.net (188.8.131.52): 56 data bytes 64 bytes from 184.108.40.206: icmp_seq=0 ttl=59 time=20.068 ms 64 bytes from 220.127.116.11: icmp_seq=1 ttl=59 time=19.897 ms 64 bytes from 18.104.22.168: icmp_seq=2 ttl=59 time=19.989 ms --- e4036.dscb.akamaiedge.net ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 19.897/19.985/20.068/0.070 ms
Unlike the above, which asks one of the nameservers listed in /etc/resolv.conf to look up the address, you can place a specific request to a specific nameserver with “dig”. This tool, part of the “bind9” or “bind-utils” package, is a good way to do name server troubleshooting.
Let’s say we thought that nameserver 22.214.171.124 might be returning an incorrect IP address for www.whitehouse.gov. We can ask this specific nameserver for the Whitehouse’s IP addess:
dig @126.96.36.199 www.whitehouse.gov. A ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @188.8.131.52 www.whitehouse.gov. A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8758 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.whitehouse.gov. IN A ;; ANSWER SECTION: www.whitehouse.gov. 103 IN CNAME wildcard.whitehouse.gov.edgekey.net. wildcard.whitehouse.gov.edgekey.net. 480 IN CNAME e4036.dscb.akamaiedge.net. e4036.dscb.akamaiedge.net. 19 IN A 184.108.40.206 ;; Query time: 13 msec ;; SERVER: 220.127.116.11#53(18.104.22.168) ;; WHEN: Wed Jan 27 16:31:39 UTC 2021 ;; MSG SIZE rcvd: 148
The important parts are the question and answer section. Dig reports on what it asked – “What’s the A (ipv4 address) record for www.whitehouse.gov.?”, and what that specific server (22.214.171.124) answered: “www.whitehouse.gov. can be found at 126.96.36.199.”
If you only want the answer(s) and not all the extra verbiage, try:
dig +short @188.8.131.52 www.whitehouse.gov. A wildcard.whitehouse.gov.edgekey.net. e4036.dscb.akamaiedge.net. 184.108.40.206
If dig is not available on a old system you may be able to use the older, and deprecated, nslookup: nslookup www.whitehouse.gov. 220.127.116.11 Server: 18.104.22.168 Address: 22.214.171.124#53 Non-authoritative answer: www.whitehouse.gov canonical name = wildcard.whitehouse.gov.edgekey.net. wildcard.whitehouse.gov.edgekey.net canonical name = e4036.dscb.akamaiedge.net. Name: e4036.dscb.akamaiedge.net Address: 126.96.36.199
To scan a network for netbios hosts, try the nbtscan program (in the nbtscan package). It may need to run as root, so we’re running it under sudo in this example:
sudo nbtscan 10.0.0.0/24 Doing NBT name scan for addresses from 10.0.0.0/24 IP address NetBIOS Name Server User MAC address ------------------------------------------------------------------------------ 10.0.0.87 DROBO5N <server> DROBO5N 00:00:00:00:00:00 10.0.0.88 DROBO5N <server> DROBO5N 00:00:00:00:00:00 10.0.0.235 SECONDARY <server> SECONDARY 00:00:00:00:00:00 10.0.0.234 SECONDARY <server> SECONDARY 00:00:00:00:00:00 10.0.0.179 BRWF8DA0C339CE8 <server> <unknown> ff:ff:ff:33:9c:e8
nbtscan web site: http://unixwiz.net/tools/nbtscan.html
To look up a particular netbios name, use nmblookup (part of the samba-client, samba4, or samba4-client package):
nmblookup SECONDARY 10.0.0.234 SECONDARY<00>
Here’s an example of running tcpdump with a BPF filter that will return most name lookups and replies. You’ll want to update this with the specific nameserver IPs used by your systems. Note that this may capture traffic other than name lookups too.
sudo tcpdump -i en4 -qtnp '(port 53) or (udp port 5353 and (host 188.8.131.52 or host ff02::fb)) or (port 5355 and (host 184.108.40.206 or host ff02::1:3)) or (port 137) or (tcp port 445) or (tcp port 853) or (tcp port 443 and (host 220.127.116.11 or host 18.104.22.168 or host 22.214.171.124 or host 126.96.36.199 or host 188.8.131.52 or host 2620:fe::fe or host 2620:fe::fe:9 or host 2620:fe::9 or host 2620:fe::fe:9 or host 2620:fe::10 or host 2620:fe::fe:10))'
o simply see the dns query and response, use tcpdump without the “-q” flag:
sudo tcpdump -i en4 -tnp 'port 53 and host 184.108.40.206' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en4, link-type EN10MB (Ethernet), capture size 262144 bytes IP 10.0.0.41.52847 > 220.127.116.11.53: 56183+ [1au] A? www.whitehouse.gov. (59) IP 18.104.22.168.53 > 10.0.0.41.52847: 56183 3/0/1 CNAME wildcard.whitehouse.gov.edgekey.net., CNAME e4036.dscb.akamaiedge.net., A 22.214.171.124 (148)
, and you get to see the outgoing request and incoming reply to
dig +short @126.96.36.199 www.whitehouse.gov. A
Passer, a passive network sniffer, is also able to extract hostname/IP pairs from network traffic. DNS records show up on lines starting with “DN,”, while Netbios records start with “NA,”:
DN,188.8.131.52,A,a104-104-102-64.deploy.static.akamaitechnologies.com., DN,2600:1401:c000:0193:0000:0000:0000:0fc4,PTR,g2600-1401-c000-0193-0000-0000-0000-0fc4.deploy.static.akamaitechnologies.com., DN,2600:1401:c000:01b7:0000:0000:0000:0fc4,PTR,g2600-1401-c000-01b7-0000-0000-0000-0fc4.deploy.static.akamaitechnologies.com., NA,10.0.0.235,PTR,SECONDARY,netbios-dgm NA,169.254.5.153,PTR,SECONDARY,netbios-dgm
Wireshark (and its command line version “tshark”) can display these different types of queries and responses with a high level of detail.
This has specific references to using Zeek and using RITA to detect DoH.
Tools, browsers, setup details, and servers
Interested in threat hunting tools? Check out AC-Hunter
Active Countermeasures is passionate about providing quality, educational content for the Infosec and Threat Hunting community. We appreciate your feedback so we can keep providing the type of content the community wants to see. Please feel free to Email Us with your ideas!
Bill has authored numerous articles and tools for client use. He also serves as a content author and faculty member at the SANS Institute, teaching the Linux System Administration, Perimeter Protection, Securing Linux and Unix, and Intrusion Detection tracks. Bill’s background is in network and operating system security; he was the chief architect of one commercial and two open source firewalls and is an active contributor to multiple projects in the Linux development effort. Bill’s articles and tools can be found in online journals and at http://github.com/activecm/ and http://www.stearns.org.