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

[0]: git://z3bra.org/phroxy.git

20200919.1520