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

 

Intro

Since humans aren’t good at memorizing IP addresses (104.104.102.64 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.

/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

Reference:
https://en.wikipedia.org/wiki/Hosts_(file)

UDP DNS

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.

References:
https://www.rfc-editor.org/rfc/rfc1035.txt
https://en.wikipedia.org/wiki/Domain_Name_System

TCP DNS

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.

References:
https://www.rfc-editor.org/rfc/rfc1035.txt
https://en.wikipedia.org/wiki/Domain_Name_System

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: 224.0.0.251 (mac: 01:00:5E:00:00:FB) or ff02::fb (mac: 33:33:00:00:00:FB), udp port 5353

mDNS traffic is unencrypted.

References:
https://en.wikipedia.org/wiki/Multicast_DNS
https://www.eiman.tv/blog/posts/lannames/

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 224.0.0.252 (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.

References:
https://en.wikipedia.org/wiki/Link-Local_Multicast_Name_Resolution
https://www.eiman.tv/blog/posts/lannames/

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.

Servers:
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers
https://www.privacytools.io/providers/dns/
https://en.wikipedia.org/wiki/Public_recursive_name_server

References:
https://tools.ietf.org/html/rfc7858
https://en.wikipedia.org/wiki/DNS_over_TLS

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:

https://github.com/curl/curl/wiki/DNS-over-HTTPS

https://github.com/dnscrypt/dnscrypt-resolvers

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers

https://www.privacytools.io/providers/dns/

https://support.opendns.com/hc/en-us/articles/360038086532-Using-DNS-over-HTTPS-DoH-with-OpenDNS

https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md

https://en.wikipedia.org/wiki/Public_recursive_name_server

Additional DOH servers:

Quad9 dns.quad9.net, dns9.quad9.net, dns10.quad9.net 9.9.9.9, 9.9.9.10, 149.112.112.112, 149.112.112.9, 149.112.112.10 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 8.8.8.8, 8.8.4.4 2001:4860:4860::8888, 2001:4860:4860::8844

Cloudflare cloudflare-dns.com, mozilla.cloudflaredns.com 1.1.1.1, 1.0.0.1, 104.16.249.249, 104.16.248.249 2606:4700:4700::1111, 2606:4700:4700::1001, 2606:4700::6810:f9f9, 2606:4700::6810:f8f9

References:
https://tools.ietf.org/html/rfc8484
https://en.wikipedia.org/wiki/DNS_over_HTTPS

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.

References:
https://blog.cloudflare.com/oblivious-dns/
https://en.wikipedia.org/wiki/DNS_over_HTTPS#Oblivious_DNS-over-HTTPS

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.

References:
https://www.zdnet.com/article/ad-blocker-adguard-deploys-worlds-first-dns-over-quic-resolver/
https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07

 

Netbios

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.

LMHOSTS file

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

Reference:
https://en.wikipedia.org/wiki/LMHOSTS

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.

References:
https://en.wikipedia.org/wiki/NetBIOS
https://en.wikipedia.org/wiki/NetBIOS_over_TCP/IP
https://tools.ietf.org/html/rfc1001
https://tools.ietf.org/html/rfc1002

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.

References:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/direct-hosting-of-smb-over-tcpip
https://en.wikipedia.org/wiki/Server_Message_Block

 

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.

References:
https://en.wikipedia.org/wiki/Windows_Internet_Name_Service

 

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.

Reference:
https://en.wikipedia.org/wiki/Peer_Name_Resolution_Protocol

 

Generation

DNS

ping

To look up a DNS name, you can simply “ping” it:

ping -c 3 www.whitehouse.gov.
PING e4036.dscb.akamaiedge.net (104.104.102.64): 56 data bytes
64 bytes from 104.104.102.64: icmp_seq=0 ttl=59 time=20.068 ms
64 bytes from 104.104.102.64: icmp_seq=1 ttl=59 time=19.897 ms
64 bytes from 104.104.102.64: 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

dig

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

dig @8.8.8.8 www.whitehouse.gov. A

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

;; Query time: 13 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; 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 (8.8.8.8) answered: “www.whitehouse.gov. can be found at 23.64.102.183.”
If you only want the answer(s) and not all the extra verbiage, try:

dig +short @8.8.8.8 www.whitehouse.gov. A

wildcard.whitehouse.gov.edgekey.net.
e4036.dscb.akamaiedge.net.
23.64.102.183

nslookup

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

nslookup www.whitehouse.gov. 8.8.8.8

Server: 8.8.8.8
Address: 8.8.8.8#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: 23.64.102.183

Netbios Names

nbtscan

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

nmblookup

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>

 

BPF/Capture

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 224.0.0.251 or host ff02::fb)) or (port 5355 and (host 224.0.0.252 or host ff02::1:3)) or (port 137) or (tcp port 445) or (tcp port 853) or (tcp port 443 and (host 9.9.9.9 or host 9.9.9.10 or host 149.112.112.112 or host 149.112.112.9 or host 149.112.112.10 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))'

Analysis

o simply see the dns query and response, use tcpdump without the “-q” flag:

sudo tcpdump -i en4 -tnp 'port 53 and host 8.8.8.8'

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 > 8.8.8.8.53: 56183+ [1au] A? www.whitehouse.gov. (59)
IP 8.8.8.8.53 > 10.0.0.41.52847: 56183 3/0/1 CNAME wildcard.whitehouse.gov.edgekey.net., CNAME e4036.dscb.akamaiedge.net., A 104.104.102.64 (148)

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

dig +short @8.8.8.8 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,104.104.102.64,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.

Reference:
https://github.com/activecm/passer/
https://github.com/jbaggs/anomalous-dns

 

References

https://www.cloudflare.com/learning/dns/dns-over-tls/

https://corelight.blog/2020/06/18/dns-over-tls-and-dns-over-https/

https://developers.google.com/speed/public-dns/docs/dns-over-tls

https://kb.adguard.com/en/general/dns-providers

https://www.dns.cam.ac.uk/servers/doth.html

https://wiki.ipfire.org/dns/public-servers

https://wiki.archlinux.org/index.php/DNS_over_HTTPS_servers

https://www.sans.org/reading-room/whitepapers/dns/needle-haystack-detecting-dns-https-usage-39160

This has specific references to using Zeek and using RITA to detect DoH.

https://superuser.com/questions/1532975/how-to-query-for-dns-over-https-dns-over-tls-using-command-line

https://github.com/curl/curl/wiki/DNS-over-HTTPS

Tools, browsers, setup details, and servers