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.