Debugging DNS propagation
──────────────────────────────────────────────────────────────────────
I recently made a subdomain for phroxy(1), my http to gopher proxy [0].
In the process, I realised I had a resolution issue when accessing it
(even after ,72 hours). Sometimes I could access the domain, sometimes
I couldn't. At the time I used some random DNS, so I tried to resolve
them directly at the source (my own DNS servers), and it resolved as
expected... Weird issue.
I tried a bunch of DNS propagation maps on the web, and it showed that
barely 20% of worldwide servers could resolve this specific name, while
resolving another, old name on the same machine hit 100% resolution.
I first though about the sequence number, but it was correctly updated
(I even incremented it again, to be sure).
Then a collegue of mine gave me the key to this problem:
dig +trace phroxy.z3bra.org
That `+trace` here is the key. It show which servers are contacted to
resolved your name, kind of like what traceroute does for ICMP. And it
would never reach the servers pointed to by the NS records of my zone.
So my zone was fucked up somewhere, in a way that prevented the DNS
servers to be selected as authoritative on the zone.
After taking a closer look at the zone, I found the issue, in the very
first line:
$ORIGIN rg.
The full domain was cropped! It should have read « $ORIGIN z3bra.org.
». As I use short domain names in my zone, the $ORIGIN is there to
complete the FQDN, and it wasn't doing it with the correct domain !
I fixed that line, incremented the seqnum, and deployed the zone again.
Problem solved.
The real game-changer for me was `dig +trace`. I never used it before,
but it's definitely going to my debugging toolbelt !
--
~wgs
