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 ( is a bit much to remember), we need a way to convert between 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.

/etc/hosts file

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 .

Line format:

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/mDNS

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: (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 (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,,,,,, 2620:fe::fe, 2620:fe::fe:9, 2620:fe::9, 2620:fe::fe:9, 2620:fe::10, 2620:fe::fe:10

Google,, 2001:4860:4860::8888, 2001:4860:4860::8844

Cloudflare,,,, 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.

file: c:\Windows\System32\drivers\etc\lmhosts

Line format:

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.



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.



WINS Server

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
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=59 time=20.068 ms
64 bytes from icmp_seq=1 ttl=59 time=19.897 ms
64 bytes from icmp_seq=2 ttl=59 time=19.989 ms

--- 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 might be returning an incorrect IP address for We can ask this specific nameserver for the Whitehouse’s IP addess:

dig @ A

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @ 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

; EDNS: version: 0, flags:; udp: 512
; IN A


;; Query time: 13 msec
;; 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”, and what that specific server ( answered: “ can be found at”
If you only want the answer(s) and not all the extra verbiage, try:

dig +short @ A
If dig is not available on a old system you may be able to use the older, and deprecated, nslookup:



Non-authoritative answer: canonical name = canonical name =

Netbios Names


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

Doing NBT name scan for addresses from

IP address NetBIOS Name Server User MAC address 
------------------------------------------------------------------------------ DROBO5N <server> DROBO5N 00:00:00:00:00:00 DROBO5N <server> DROBO5N 00:00:00:00:00:00 SECONDARY <server> SECONDARY 00:00:00:00:00:00 SECONDARY <server> SECONDARY 00:00:00:00:00:00 BRWF8DA0C339CE8 <server> <unknown> ff:ff:ff:33:9c:e8

nbtscan web site:


To look up a particular netbios name, use nmblookup (part of the samba-client, samba4, or samba4-client package):




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 or host ff02::fb)) or (port 5355 and (host or host ff02::1:3)) or (port 137) or (tcp port 445) or (tcp port 853) or (tcp port 443 and (host or host or host or host or host 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'

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en4, link-type EN10MB (Ethernet), capture size 262144 bytes
IP > 56183+ [1au] A? (59)
IP > 56183 3/0/1 CNAME, CNAME, A (148)

, and you get to see the outgoing request and incoming reply to

dig +short @ 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,”:






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!

Share this:
AC-Hunter Datasheet
AC-Hunter Personal Demo
What We’re up To