While reading this HN comment, I learnt of a CLI tool named
delv's history paints it as the spiritual successor to
dig, plus its name pays homage to a popular nursey rhyme. Interesting.
delv is a DNS lookup and validation utility. Apple shipped the
delv binary with my machine running macOS Monterey (v12.3.1) but I had trouble getting it to work.
When I ran the first command in that HN comment:
delv MX ycombinator.com @184.108.40.206 I got an inscrutable output:
delv MX ycombinator.com @220.127.116.11 ;; none:29: no crypto support delv: No trusted keys were loaded
Some Attempts to fix the Problem
I did a search on the error message and came across a mailing list discussion from 3 years ago which mentioned the
-a anchor-file option from the man page.
Based on the explanation in that man entry, the default behavior of
delv is to look for key information in a default location
/etc/bind.keys, if no
-a anchor-file option is specified, so I decided to create that file since it was non-existent on my machine.
Just to be sure, I first check to see what version of
delv I have installed:
delv -v delv 9.10.6
So, I use the term "
/etc/bind.keys" to search for a valid copy of that file online and landed on the homepage of the ISC (Internet Systems Consortium). It is hosted on their FTP site and I was able to download a valid copy (v9.11) with the following commands:
cd /tmp curl -LO https://downloads.isc.org/isc/bind9/keys/9.11/bind.keys.v9_11 sudo mv /tmp/bind.keys.v9_11 /etc/bind.keys
With a valid
/etc/bind.keys in place, I ran the
delv command again and the error message was slightly different:
delv MX ycombinator.com @18.104.22.168 ;; /private/etc/bind.keys:29: no crypto support delv: No trusted keys were loaded
Based on additional searches, the real issue is the "no crypto support" part of the error message. This ServerFault answer suggests that the Apple-provided version of the
delv binary was not set to support SSL when it was compiled.
Apple's inclusion of OSS network utilities can sometimes be half-hearted, so rather than play whack-a-mole trying to fix it, I decided to use Homebrew.
Fixing the Problem
bind is an OSS collection of network utilities (sometimes called
bind-tools) from the ISC that includes CLI tools like
nslookup and of course
So, I search for "homebrew bind" and the first result gave me a simple way to install it on macOS in only 2 steps.
Step 1: Install
bind by executing
brew install bind:
brew install bind ... ==> Caveats ==> bind To restart bind after an upgrade: sudo brew services restart bind Or, if you don't want/need a background service you can just run: /Users/mac/homebrew/opt/bind/sbin/named -f -L /Users/mac/homebrew/var/log/named/named.log
Step 2: Next, open a new terminal window, and check the version of
delv that was installed is newer than the Apple-provided version of
delv -v delv 9.18.4
delv binary can be found at this path:
/Users/mac/homebrew/Cellar/bind/9.18.4/bin/delv on my Mac and because my Homebrew installation was setup to put Homebrew binaries ahead of Apple-provided binaries in my
PATH, the shell found it before it found the older version provided by Apple.
You can read more about how I set this up towards the end of my article on using a newer version of rsync on macOS.
Using the new version of delv
Re-running the original command in the HN comment earlier–
delv MX ycombinator.com @22.214.171.124 now works correctly:
delv MX ycombinator.com @126.96.36.199 ; unsigned answer ycombinator.com. 300 IN MX 10 aspmx.l.google.com. ycombinator.com. 300 IN MX 20 alt1.aspmx.l.google.com. ycombinator.com. 300 IN MX 20 alt2.aspmx.l.google.com. ycombinator.com. 300 IN MX 30 aspmx4.googlemail.com.
The second command in the HN comment–
delv NS ycombinator.com @188.8.131.52 also worked:
delv NS ycombinator.com @184.108.40.206 ; unsigned answer ycombinator.com. 10267 IN NS ns-225.awsdns-28.com. ycombinator.com. 10267 IN NS ns-556.awsdns-05.net. ycombinator.com. 10267 IN NS ns-1411.awsdns-48.org. ycombinator.com. 10267 IN NS ns-1914.awsdns-47.co.uk.