Information Security
dns dns-domain enumeration
Updated Wed, 07 Sep 2022 02:48:38 GMT

DNS reverse lookup not finding domain name during enumeration


While enumerating a DNS server for a HTB machine, I've tried finding a domain name for 127.0.0.1:

(kalikali)-[~]
$ dig -x 127.0.0.1 @10.10.11.166 
; <<>> DiG 9.18.1-1-Debian <<>> -x 127.0.0.1 @10.10.11.166
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49357
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 04d096728a39f1fca35f95eb62c46e5c883360f8f1740712 (good)
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.                IN      PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 604800  IN      PTR     localhost.
;; AUTHORITY SECTION:
127.in-addr.arpa.       604800  IN      NS      localhost.
;; ADDITIONAL SECTION:
localhost.              604800  IN      A       127.0.0.1
localhost.              604800  IN      AAAA    ::1
;; Query time: 151 msec
;; SERVER: 10.10.11.166#53(10.10.11.166) (UDP)
;; WHEN: Tue Jul 05 13:01:16 EDT 2022
;; MSG SIZE  rcvd: 160

As you can see, all it returns is 'localhost'. However, I've found on google that HTB DNS servers usually have [name].htb domain names. In fact, I was able to check this:

(kalikali)-[~]
$ dig ANY trick.htb @10.10.11.166
; <<>> DiG 9.18.1-1-Debian <<>> ANY trick.htb @10.10.11.166
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42435
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 43e88bff29cff31f4725131762c46e64e7e7c676ae36449a (good)
;; QUESTION SECTION:
;trick.htb.                     IN      ANY
;; ANSWER SECTION:
trick.htb.              604800  IN      SOA     trick.htb. root.trick.htb. 5 604800 86400 2419200 604800
trick.htb.              604800  IN      NS      trick.htb.
trick.htb.              604800  IN      A       127.0.0.1
trick.htb.              604800  IN      AAAA    ::1
;; ADDITIONAL SECTION:
trick.htb.              604800  IN      A       127.0.0.1
trick.htb.              604800  IN      AAAA    ::1
;; Query time: 103 msec
;; SERVER: 10.10.11.166#53(10.10.11.166) (TCP)
;; WHEN: Tue Jul 05 13:01:25 EDT 2022
;; MSG SIZE  rcvd: 209

Why was I unable to retrieve trick.htb during the reverse lookup?




Solution

Why was I unable to retrieve trick.htb during the reverse lookup?

Because both trees (reverse and forward) are delegated through different paths, even if they theoretically land at the end to the same organization, which means that "in theory", bidirectional mapping can happen

except of course for some edge cases and specific addresses that can be used by multiple providers.

Standard recursive nameservers typically have configuration for 127.0.0.0/8, see for example this in bind documentation: "3.1.5. localhost Reverse-Mapped Zone File" at https://downloads.isc.org/isc/bind9/cur/9.19/doc/arm/html/chapter3.html#authoritative-name-servers

This zone file allows any query requesting the name associated with the loopback IP (127.0.0.1). This file is required to prevent unnecessary queries from reaching the public DNS hierarchy. The BIND 9 distribution file localhost.rev is shown for completeness:

$TTL 1D
@        IN        SOA  localhost. root.localhost. (
                    2007091701 ; serial
                    30800      ; refresh
                    7200       ; retry
                    604800     ; expire
                    300 )      ; minimum
         IN        NS    localhost.
1        IN        PTR   localhost.

But if you manage the server at 10.10.11.166 you are of course free to change that behavior. But if that IP is a remote server and not where you launch your dig commands, what should it reply for multiple clients? They would each want to see a different name.

You may also want to consult "6.3. Domain Name Reservation Considerations for "localhost."" of RFC 6761, that details why this name is special (and hence its resolution).

Do note also that at the OS level, for name resolution, it may or may not use the DNS, depending on /etc/nsswitch.conf or similar. They are often also other shortcuts, like systemd-resolved will always resolve localhost in a specific static way.





Comments (1)

  • +0 – Thank you for your answer. It is now obvious to me I still have a lot to study about this — Jul 05, 2022 at 19:30