Comment

Comment by jsprinkles

I've identified several technical problems with this domain, and this isn't an example of how to properly operate DNS. 37signals is setting an absurdly low TTL on these records (10 minutes; the answers never change, I absolutely do not understand the logic behind this TTL), which means every 10 minutes you're re-resolving a local address, through a CNAME (so two DNS round trips, and in my case this resolution took between 115ms and 230ms, not small change):

    [~]$ dig foo.169.254.84.1.xip.io
    foo.169.254.84.1.xip.io.	600	IN	CNAME	foo.daze1.xip.io.
    foo.daze1.xip.io.		600	IN	A	169.254.84.1
Concerningly, ns-1.xip.io is also broken; it does not serve NS records for its own zone, instead relying upon the SOA record and the upstream glue, which I'm shocked works:

    [~]$ dig +short NS xip.io
    [~]$ 
The nameserver delegation from nic.io is also broken:

    xip.io.			86400	IN	NS	ns-1.xip.io.
    xip.io.			86400	IN	NS	ns6.gandi.net.
    ;; Received 86 bytes from 2001:678:5::1#53(b.nic.io) in 60 ms
Oh, well that's interesting, Gandi is a backup for their custom daemon, eh? So did they implement AXFR, IXFR, and notify and such to Gandi? Well, let's ask Gandi:

    [~]$ dig @ns6.gandi.net. SOA xip.io
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 3222
Oh, guess not. The long and short of this is for DNS purposes, a custom daemon is almost never the answer. This could have been accomplished with BIND fairly easily, and the zone would be functional as well.
parent jsprinkles 14 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton