I'm not getting what the problem is. Isn't this what ports are for? Or even just running the websites on different folders?
This is just one situation where I can see this come in really handy during development.
This is only necessary if you want users outside your domain to access your component. While you probably want to do so for MUC, you might not necessarily want to bother for your user directory or gateways. I've run many servers over the years and long since stopped creating a host/subdomain for each component.
As far as the XMPP protocol is concerned, the concept of sub-domains doesn't matter. It's useful for human users when configuring servers though.
Prosody for example allows running a multi-user chat service on example.com. And there's an undocumented feature which let's you have email@example.com be a user, and firstname.lastname@example.org be a chatroom.
126.96.36.199 site1.com site2.com
Then you have to edit /etc/hosts to try two more sites.
The idea that the user cannot access /etc/hosts on the iPhone is reason enough to jailbreak it. Denying access to /etc/hosts means the iPhone cannot connect to the any website that requires a hostname, even when the iPhone can connect to the internet, unless the iPhone can access some DNS server (which of course Apple probably wants to control). That is a ridiculous limitation. The internet nor the web requires DNS to work, but the iPhone requires DNS to access the web.
1. assuming the website is using virtual hosts or otherwise requires a hostname
Some things are harder to do without a hostname - cookies, for instance, can be tricky.
Other than that, ports will do.
(Update) Problem solved by myself. The DNSmasq config has stop-dns-rebind option enabled, which filters out DNS results in private IP ranges from upstream servers for security reasons. DNSmasq doc has the following part:
In case you run into this issue, just comment out this option in dnsmasq.conf and restart dnsmasq.
When you're testing on your LAN using a PC/mac or whatever you can do a local DNS modification on the machine (eg. /etc/hosts) but when you're testing from an iPad or some other device this is either impossible or prohibitively difficult.
The other option is to setup a DNS server on your LAN which is a headache all it's own - this is a very simple and elegant way of circumventing these issues. Awesome stuff.
powerdns is a solid dns server and very extensible!
$ host whatever.188.8.131.52.ip.ipq.co
whatever.184.108.40.206.ip.ipq.co is an alias for 1h9u9ze.ip.ipq.co.
1h9u9ze.ip.ipq.co has address 220.127.116.11
Filed an issue: https://github.com/37signals/pow/issues/293
Edit: a) I should RTF man page for ipfw, b) nevertheless my OS X behaved strangely. I rebooted and now everything works.
Anyway, great project, have been a happy user of pow master for quite a while.
DNS hackery is really dangerous.
With this you could serve as many different sites as you want based on the first part of the domain name.
By the way, a neat trick is to assign an alias to your network interface in order to avoid the trouble of DHCP giving you a different IP address each time you connect. For example, on Mac OS X:
$ sudo ifconfig en1 alias 10.99.99.99 netmask 255.0.0.0
(Obviously you want to be sure you're using a vacant address.)
(And of course, when you have control over the DHCP server there are more elegant ways of achieving this, such as binding your MAC to a static IP address.)
Edited for clarity.
And most routers try to minimize IP variations, but it's not perfect. Mine doesn't persist IP<->MAC associations when I reboot it.
Not sure what you mean. If you're referring to the bit about binding MAC to an address, I should probably have said "fixed IP" rather than "static IP", sorry about that.
Also don't most routers attempt to give IPs back to the MAC that last had them?
I'm hopping between different networks (with different DHCP servers) quite a lot, maybe it's less useful when you're always on the same network.
They all resolve to the same IP Address (10.0.0.1), but now the web application at that address knows which tenancy is being targeted.
And I wrote a Ruby DSL to easily integrate with a real dns server (powerdns). Makes it trivially easy to write things like xip.io
Of course reverse dns doesn't work :-) I suppose it kinda sorta could if you tracked where a request came from and what IP you sent it and if you got a reverse lookup you could undo that, but still it is clever!
When you reverse map an IP you look up b4.b3.b2.b1.in-addr.arpa. where b1 - b4 are bytes 1 through 4 (in reverse order) of the IP address. So 10.1.2.3 becomes 18.104.22.168.in-addr.arpa. The interesting bit is you send this to some dns resolver, typically in the 'generic' world your machine got the address of a resolver (and maybe a backup) from the DHCP server that gave it the IP address. When that dns server sees this request what it is supposed to do is to either tell you to 'go fish' and here is the IP of a server than can help, or 'recursively resolve' by forwarding on your request. Now if you run a vanilla BIND or djbdns setup you will get short circuited by it recognizing a 'private' address and not resolving it, if it did try the root servers tell you to go away as well. But if you recognized it as a private address and sent it back to xip.io DNS servers on a lark, they could "pretend" to be authorative for the domain and return you a cname record that pointed back to your fake name.
I admit it is a hack on top of another hack but as long as we're writing custom DNS servers why not go all in? :-)
 If you ever wondered how openDNS or your ISP sends you spammy web pages when you try to resolve something that doesn't exist, or how the hotel hijacks your browser into giving you a login page, this is it. You look for google.com it notes you haven't logged in and returns the address for its paywall as the answer.
Oh except if you are running dnssec in which case it is a lot harder to lie about what you are authoritative for. But on my dns servers at home they all think they are authoritative for 10.in-addr.arpa. so that they will answer queries for that network.
Edit: Proxy settings can't be global, but are assigned individually for each WiFi connection.
In fact doesn't the whole idea of binding multiple sub-domains to the same IP address (on the same port) kind of go by the wayside when it's free/cheap/not-going-to-blow-up-the-internet to get another IP?
External ip addresses of requestees.
Internal ip addresses of requestees.
To some, this is very useful...
That said, I do trust them :)
[~]$ 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 22.214.171.124
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.
Running a local DNS server on these devices is also not possible?
Can a user access ifconfig and change interface settings, e.g. adding an alias?
In terms of networking, these devices appear to be crippled. Yet they do not have to be if they're built using code from BSD's.
In Silicon Valley an idea like this could lead to a helluva exit with backing from incubators like YC.