I was just reading yesterday about one way this can be done. If you are using DNSSEC, the server, in order to sign a negative result, will use an NSEC record type which will contain some similar record to the missing record since it can’t sign an empty record. see below where I dig for MacBook.mylocal which doesn’t exist on my home domain and it returns a couple of NSEC records with appletv-livingroom.mylocall, jj-soundbar.mylocal., and macbookpro-20.mylocal. The solution to this is NSEC3 where the host names are hashed (https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#nsec3). Not sure if that answers how others are doing it, but was something I read about yesterday that has been exploited in the past to learn details about a zone.
$ dig macbook.mylocal IN A @192.168.40.42 +dnssec ; <<>> DiG 9.16.33-Debian <<>> macbook.mylocal IN A @192.168.40.42 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18808 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 498ba75e90a524ad0100000063a44d72b4b9adb0b61ef5de (good) ;; QUESTION SECTION: ;macbook.mylocal. IN A ;; AUTHORITY SECTION: mylocal. 7200 IN SOA ns1.mylocal. hostmaster.mylocal. 64133 43200 900 1814400 7200 mylocal. 7200 IN RRSIG SOA 13 1 86399 20230105095806 20221222085806 2295 mylocal. 0AaPYQf2zVZuTshZ/yaVoQfgtQdwp2WigXypDEXp/NVdz6jH8pQKDB8j 3NDB7Xw1lr/o2OeJeK9NjuVIr3dZiA== mylocal. 7200 IN RRSIG NSEC 13 1 7200 20221228002743 20221213235040 2295 mylocal. SLA3LiYg8s80GlEFIgK0thf83k7z927lJJvGGUTF6mBzbrpC2kkDFfvw hx3cwjHU+zMlKoy1MdyDUJajBfn7hg== mylocal. 7200 IN NSEC appletv-livingroom.mylocal. NS SOA RRSIG NSEC DNSKEY CDS CDNSKEY TYPE65534 jj-soundbar.mylocal. 7200 IN RRSIG NSEC 13 2 7200 20221228203849 20221221200203 2295 mylocal. bczZ0RfYzVaoLoJC6qV8RJHaXJhyxVtkExQ/S1NB0iPQeb26jZghZfMK umFNNcsMlGo4o5eiryxJGeC+yMfReA== jj-soundbar.mylocal. 7200 IN NSEC macbookpro-20.mylocal. A RRSIG NSEC DHCID ;; Query time: 0 msec ;; SERVER: 192.168.40.42#53(192.168.40.42) ;; WHEN: Thu Dec 22 07:28:34 EST 2022 ;; MSG SIZE rcvd: 576 > On Dec 22, 2022, at 12:19 AM, Michael De Roover <i...@nixmagic.com> wrote: > > Hello, > > I have been running BIND 9 on my external and internal networks for a > few years now -- as such I have a basic understanding of the most > common RR types and activities such as zone transfers. However, I have > been seeing something that's been baffling me for quite a while now. > Somehow there are services like c99.nl [1] and Criminal IP [2], which > can enumerate various subdomains on a given target domain. I am > confused as to how they can enumerate this information. > > As far as I know, a NS record returns the name servers authoritative > for a domain. Alright, now you've got authoritative information when > querying these domains. No useful information about the zone data they > are responsible for though. > > Then there is an A record, which returns an IPv4 address of a server > responsible for a domain. Alright, now you can talk to a server. Maybe > that would be a webserver, and now you may perform a HTTP exchange to > that server (GET /whatever, with a given Host header). You still have > to guess what the Host: header would have to be. > > Maybe it would be an MX record. Brilliant, now you could talk to a mail > server. Its EHLO message (sometimes called a "banner" in security > circles) would contain a domain, alright. It would also only be one of > them -- AFAICT only one domain that the organization wants to actually > primarily send from. > > Another interesting record would be the CNAME record. As far as I know, > this is used to redirect to another domain from within the DNS, with > its own bespoke entries (bringing us back to A records). Getting from a > CNAME to an A record seems easy enough, but what about getting these > CNAME records in the first place? > > This is what I am thinking of so far, but it may well be that I've been > talking crap in all of the above and know nothing about the DNS. That's > fine, and in that case please correct me where necessary. Either way, > I'm very confused on how these services can actually enumerate these > subdomains, and find most -- if not all -- reliably. This seems a bit > concerning to me with regards to unwanted information disclosure, hence > my curiosity. If it is at all possible to mitigate, I would of course > also appreciate discourse on this matter. Thank you! > > [1] https://subdomainfinder.c99.nl > [2] https://criminalip.io/domain > > Best regards, > Michael > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
