It's a cool idea, but there are some other problems too; which I just want to list to help the developers and am not trying to rain on a parade.
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
but only if the request is of type A. Requests of other types return invalid NXDOMAIN responses - invalid because they contain no SOA in the authoritative section. CNAMEs are supposed to be returned for all records of any type for a given name, not doing so is dangerous as it can poison caches. Not returning the CNAME even for a query of type "CNAME" is particularly harmful.
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.
here "a2eo0" is an encoding of 192.0.2.1 , but then;
foo.192.0.2.2.xip.io. 600 IN CNAME foo.k201s.xip.io.
are you using some kind of cipher?
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 ;-)
Thanks! it reads like a 36-ary encoding of an IP address in host byte order, rather than network byte order, which is why it seems to jump around so much.
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.
As in the parent comment, a CNAME is returned for arbitrary names;
but only if the request is of type A. Requests of other types return invalid NXDOMAIN responses - invalid because they contain no SOA in the authoritative section. CNAMEs are supposed to be returned for all records of any type for a given name, not doing so is dangerous as it can poison caches. Not returning the CNAME even for a query of type "CNAME" is particularly harmful.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.;
here "a2eo0" is an encoding of 192.0.2.1 , but then; are you using some kind of cipher?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 ;-)