[~]$ 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
[~]$ dig +short NS xip.io
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
[~]$ dig @ns6.gandi.net. SOA xip.io
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 3222
As in the parent comment, a CNAME is returned for arbitrary names;
% dig foo.192.0.2.1.xip.io
foo.192.0.2.1.xip.io. 600 IN CNAME foo.a2eo0.xip.io.
foo.a2eo0.xip.io. 600 IN A 192.0.2.1
Responding with no name would be bad on its own, but saying that no name exists is clearly wrong and can be used to poison caches (the NXDOMAIN is cacheable). Note that most browsers and clients will now perform an AAAA lookup prior to the A lookup - poisoning their own cache if they happen to have a copy of the SOA for xip.io in cache (the SOA record hints to the negative cache lifetime).
It's not clear that using an intermittent CNAME does anything useful - why not just return an A record, with a billion second TTL value. As-is, it merely adds a round-trip (the CNAME and A are not returned in one pass by ns-1.xip.io).
Additionally, ns-1.xip.io does not mark the "authoritative answer" bit in any responses - which will cause issues with some resolvers.
But, still a neat idea. Question for the developers;
It's clear that the intermediate CNAME represents an encoding of the IP address, e.g.;
foo.192.0.2.1.xip.io. 600 IN CNAME foo.a2eo0.xip.io.
foo.192.0.2.2.xip.io. 600 IN CNAME foo.k201s.xip.io.
PS. Everybody please use 192.0.2.0/24 for IP addresses in examples and documentation, and 2001:db8::/16 for IPv6. See RFC3330/5735 and RFC3849. It's good karma ;-)
Interestingly, it encodes 0.0.0.0.xip.io as 0.xip.io , but then refuses to answer for 0.xip.io. Why isn't obvious to me from reading the code, perhaps some kind of overflow condition is triggered by the right shift.
I can't see how it matters whether or not there are problems with this from the perspective of being a "correct" DNS server so long as it works for it's intended purpose (testing things on your local network from a bunch of different devices).
Otherwise it's easy to rat-hole for a long time trying to determine why your test isn't working, when it turns out it was a problem between your DNS resolver and an upstream domain.
Problems between DNS resolvers and DNS authoritative servers are classically intermittent; they usually depend on the ordering of a chain of steps to occur. For example, I might get a resolution failure for a xip.io record if one of the following sequences occurs;
Client asks resolver asks for AAAA - gets NXDOMAIN from ns-1.xip.io, caches it
Client asks resolver for A - responds with NXDOMAIN
or, another example;
Client asks an AD DNS server to perform resolution, server chokes on lack of the AA bit in authoritative answer.
But then in either case if a tester fires up nslookup or dig, everything works on the command line, and so they may spend quite a while trying to figure out why my library routine for connecting to my service isn't working.
I honestly don't understand what you've written above (although I re-read it a couple of times, I guess I'm just not knowledgeable enough about DNS for it to make sense) but can you see those issues impacting the ability of someone to load an application on their iPad in order to test it out?
I guess the problem might arise that people start to use this "not as originally intended" and get into all sorts of strife but for the particular scenario they were originally intending it for it seems perfectly adequate, no?
Many crufty resolvers - on things like wifi routers in particular - don't deal well with the lack of an AA bit, or a REFUSED answer. So a tester could easily end up with "works for me" and "not for me" reports that are really just down to the particulars of their network and resolver software, whether they have IPv6 enabled, and so on.
Edited to add: Again, I don't mean to rain on the developers parade. It's a great idea.
Writing DNS implementations is hard, and requires a certain kind of technical archeology to get to grips with the detail. DNS is a tricky protocol, chaotically and ambiguously documented. I've helped write 3 different ones - and I still get things wrong. And that said; anyone interested in writing hardcore DNS implementations that have to operate on the scale of microseconds per query should drop me a line.
The reason why it may not be serving NS records for itself is because looking at what is available on Github the server is started on port 5300, so I am assuming that there is some sort of DNS resolver/cache sitting in front of it that may be stripping them out. Same thing with it not responding with "Authoritative answer" bit set...
Although that is simply speculation, maybe they did put the node service directly on the internet.
But for a query like this, a server is allowed to return both a CNAME and its relevant target(s) ... as long as they are within-bailiwick. It can go right into the answer section, e.g.;
% dig example.allcosts.net @ns-22.awsdns-02.com.
;; ANSWER SECTION:
example.allcosts.net. 300 IN CNAME at.allcosts.net.
at.allcosts.net. 3613 IN A 220.127.116.11
It's more common to use the additional section to include details about the target(s) of MX, SRV and NS records. That's more of a "I know you asked for an MX record, but you're going to need this A / AAAA record too pretty soon, so here it is in the additional section" kind-of thing. The additional sections in the responses to the following queries should be illustrative;
dig NS ns_example.allcosts.net @ns-22.awsdns-02.com
dig MX mx_example.allcosts.net @ns-22.awsdns-02.com
dig SRV srv_example.allcosts.net @ns-22.awsdns-02.com
Although RFC1034 outlines that a server typically would do that, it also says that it shouldn't include data that it's not authoritative for.
So a conflict arises when you CNAME to a sub-delegated child zone. E.g.
foo.example.com IN CNAME baz.example.com
However baz.example.com may itself be delegated to other nameservers, and so is "really" out of bailiwick. But the response won't signal this to resolvers at this stage (though in theory could via the additional section).
The simplest reason why resolvers ignore it though is that there's no SOA in the response from which to derive the negative caching time - so it wouldn't know how long to cache that non-existence - and almost all resolvers are caches.
So recursors would have to account for possibly broken implementations and try the query anyway.
You can run it:
avahi_publish.py service1 service2
I genuinely and honestly cannot log into your Gandi account and fix your nameserver delegation, so that means I'm just here to shit on things? That's a logical leap for you? You are delegating xip.io to a nameserver that is refusing queries for your zone; that's seriously broken and can result in resolution failures, making your clever hack worthless.
I don't know why I bother providing feedback, since people from your school of thought (I'm looking at the 37signals community as a whole, here, which you're being a shining steward of) just get defensive and take your software being broken personally. You wrote a poor DNS server. Read the spec, study BIND's or NSD's source to understand the years of work that went into this before you, and understand the problems I've pointed out. I just get annoyed when people flagrantly misimplement DNS, because that starts trends, like Heroku suggesting for a long time that you use a CNAME for @ (don't do that).
I'm not making this up: http://i.imgur.com/zFNkV.png
Why? xip.io exists and works. If he had to read hundreds of pages of technical specs or thousands of lines of source to implement it, it wouldn't exist.
Feel free to make your own spec-compliant or better-working version though; Sam's done the same for RVM, and I'm sure he wouldn't have any problem with better software existing.