trickest/resolvers

The most exhaustive list of reliable DNS resolvers.

Resolvers

The most exhaustive list of reliable DNS resolvers

• resolvers.txt: A simple list of resolver IP addresses, which you can pass directly to your DNS enumeration tool.

• resolvers-extended.txt: All of the resolvers in resolvers.txt with additional information about each server, including the organization it belongs to, its country, and how many times it has been detected as valid. If a resolver is valid enough times, it may earn its place in the next file.

• resolvers-trusted.txt: A list of trusted resolvers from organizations like Cloudflare, Google, etc. We recommend you use this list to re-validate the results you get with the main resolvers.

How it Works

A Trickest workflow creates an initial dataset of resolvers from various sources and then uses multiple instances of dnsvalidator to validate and re-validate this dataset and make it as reliable as possible.

TB; DZ (Too big; didn't zoom)

• We collect the initial dataset from ten sources:
  • The Public DNS Server List
  • A list of provider DNS servers collected from bass (Thanks, Abss0x7tbh).
  • janmasarik/resolvers (Thanks, janmasarik).
  • A list of DNS servers contributed by our community in resolvers-community.txt (Thanks, Trickest community!).
  • proabiral/Fresh-Resolvers (Thanks, proabiral).
  • geraldino2/jart (Thanks, geraldino2).
  • cxosmo/dns-resolvers (Thanks, cxosmo).
  • Massdns's resolvers list (Thanks, blechschmidt).
  • zeroc00I/test_github_action (Thanks, zeroc00I).
  • Auto_Wordlists's resolvers list (Thanks, carlospolop).
• This mega list of resolvers is then sort -ud and split up into smaller chunks.
• Multiple instances of dnsvalidator are created to validate the resolver lists in parallel (Huge thanks to vortexau and codingo).
• Then we run another round of dnsvalidator to weed out any false positives that survived the previous step.
• The final resolvers list is passed to a whois script (which uses APNIC's API) to find out the organization and country to which each resolver belong.
• In the end, the workflow counts the number of times it found each resolver to be valid throughout all the previous runs and writes the frequency data to resolvers-extended.txt.
• This workflow is scheduled to run constantly.

Contribution

All contributions are welcome! You can create a pull request editing resolvers-community.txt to contribute new DNS servers to the project. For any other suggestions/questions, feel free to create a new ticket via GitHub issues, tweet at us @trick3st, or join the conversation on Discord.

Build your own workflows!

We believe in the value of tinkering. Sign up for a demo on trickest.com to customize this workflow to your use case, get access to many more workflows, or build your own from scratch!

resolvers's Issues

Trusted resolvers misbehaving

There's a couple of trusted resolvers which are always returning invalid DNS records. There should probably be checks to ensure misbehaving resolvers are removed from the trusted resolvers file if they can no longer be trusted.

dig @76.76.19.19 thisdoesnotexist2023.trickest.com

; <<>> DiG 9.10.6 <<>> @76.76.19.19 thisdoesnotexist2023.trickest.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7023
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;thisdoesnotexist2023.trickest.com. IN	A

;; ANSWER SECTION:
thISDoesnotexist2023.trickest.com. 300 IN A	54.144.128.85

;; Query time: 245 msec
;; SERVER: 76.76.19.19#53(76.76.19.19)
;; WHEN: Fri Oct 20 01:12:08 +04 2023
;; MSG SIZE  rcvd: 99

dig @76.223.122.150 thisdoesnotexist2023.trickest.com

; <<>> DiG 9.10.6 <<>> @76.223.122.150 thisdoesnotexist2023.trickest.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8931
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;thisdoesnotexist2023.trickest.com. IN	A

;; ANSWER SECTION:
thISDoesnotexist2023.trickest.com. 300 IN A	54.144.128.85

;; Query time: 2075 msec
;; SERVER: 76.223.122.150#53(76.223.122.150)
;; WHEN: Fri Oct 20 01:13:18 +04 2023
;; MSG SIZE  rcvd: 99

Resolvers not updated since over 1 week

Just to notify you that the resolvers are not updated since 12 of august

Resolvers not updated for 5 days

As per title.

A decent portion of resolvers are unreliable

These are the results I'm getting when resolving the A records of the Alexa top 5k domains using the resolvers from this repository:

root@vps:~/dns-test# cat output-base.txt | sort -n -r
   4834 status: NOERROR
    733 status: REFUSED
     68 status: SERVFAIL
     24 status: NXDOMAIN

Further filtering on resolvers.txt using custom dnsvalidator options results in more stable output:

root@vps:~/dns-test# cat output-new.txt | sort -n -r
   4910 status: NOERROR
     89 status: SERVFAIL
     22 status: NXDOMAIN
      2 status: REFUSED

Note that these do include retries on timeouts, which explains why the total responses might exceed the 5k number.

I've done some investigating and it seems like some DNS servers will refuse to serve records for certain domains. For example:

• 162.159.11.139 will refuse example.com, youtube.com, facebook.com, but not slack.com or lesser-known domains.
• 162.159.34.74 will refuse example.com, youtube.com, facebook.com, but not slack.com or lesser-known domains.

dnsvalidator relies on bet365.com, which works, but provides little guarantee that it will work on random domains as well. I think it's best to not make use of the default configuration to improve the quality of the resulting resolver list. Additionally, dnsvalidator has some minor issues that may affect results: vortexau/dnsvalidator#40

Remove previous runs' results from the final output file

To get the frequency data, the workflow collects the results of all previous runs. This currently leads to the results of all previous workflow runs being merged with the current run's results leading to some false positives.

Only the results of the latest run should be pushed to the final output file.

Horizontal Scaling - Many to One Issue

I am using this wordlist (9m) https://wordlists-cdn.assetnote.io/data/manual/best-dns-wordlist.txt with puredns (Horizontal Scaling - Many to One). on 100 instances. The wordlist is splitted 9m/100 instance = 95k for each instance this 95k takes 20 sec with puredns on my digitalocean VPS but when I run it using axiom the execution time is +10m I expected the execution time to be -1m since axiom executes all puredns instances in same time is this intended?

[{
    "command":"/home/op/go/bin/puredns bruteforce input  --resolvers /home/op/resolvers.txt | tee output",
    "ext":"txt",
}]

Resolvers not updated for 3 days

The bot might be broken, no update for 3 days

Thank you for your repos !

Resolvers not updated since 8 days

Hi !
The bot might be broken. No update since 8 days from now.

Have a great day :)