Live data from Hacker News

Xip.io - a magic domain name that provides wildcard DNS for any IP address

xip.io

91–100 of 128 posts

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#92

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 b…

I find it interesting that we are required to do a second round-trip for the CNAME when it is available in the same bailiwick and could be sent as part of either the ADDITIONAL SECTION or as part of the ANSWER SECTION. Would you happen to know what the RFC has to say on this? I understand that CNAME's are not allowed to exist with other records, but returning it in the ADDITIONAL SECTION shouldn't be a cause for conc…

Once a CNAME exists for a name, no record of any other type may exist for that same name (it's an override for all types).

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       85.91.5.16
this is permitted because the original type of the query was "A", so we can include it as an answer, and it will avoid a round-trip on behalf of the recursor. That's all regular RFC1035 behaviour.

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
Something I forgot to mention; Being that DNS is the chaotically documented protocol that it is, I'm glad they launched early with a minimally viable product. It's the best way to get feedback like this for free! I think the real scope for real-world error is something like 1 in 100 users experiencing a problem as-is. Most resolvers are hyper tolerant of any amount of DNS crud, because they've been beaten on so much by poor implementations over the years. But the 1% of the time it breaks will cause you hours of pain in debugging.

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#93

Earlier quoted context omitted.

> For example, with XMPP servers, multi-user chat and any components must live on a subdomain. 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.

Interesting, this must be a shortcoming of OpenFire then. With OpenFire I haven't found a way around having the MUC and extension subdomains accessible via DNS, regardless of whether or not requests are coming from the same domain or not. Is this not necessary with other XMPP servers? Which ones are you using, if I may ask?

Not a problem with ejabberd.

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#94
post #70

I'm not exactly why it is so hard to connect to a local machine on your network. Either determine your local IP address or your network computer name.

If you're creating an application where connecting on the "root domain" matters it can be problematic. For example, imagine you were creating some URL rewrites using apache's mod_rewrite and they worked for http://some.domain.com/rewrite-goes-here/ you would have to do a bunch of extra work (or an extra set of rules even) to make that work also for 10.0.1.1/my_app_without_vhost/rewrite-goes-here/ When you're testing…

You really should develop your apps so that they are path agnostic. And the mod_rewrite rules can be fixed with a simple RewriteBase declaration (RewriteBase /subdirectory). I've never found this a major problem that requires a DNS server to fix.

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#95

I've also made use of lvh.me (local virtual host), a url who's dns points at 127.0.0.1. It's good for testing subdomains on localhost.

I like http://localtest.me because it's the only one I've seen with a valid wild card SSL...makes testing and switching between HTTP and HTTPS easy.

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#96

Earlier quoted context omitted.

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 respo…

Source code for encode/decode is found here: https://github.com/sstephenson/xipd/blob/master/src/index.co...

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.

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#97
post #14
post #11

What is the use case that requires http://test.10.0.0.3.xip.io/test-page rather than http://10.0.0.3/test-page ? I've been using the latter on iphones and ipads with no problem. Honest question.

You can't test multiple sites on the same host using just the IP.

Which is when you add them to /etc/hosts

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#98
post #63

Earlier quoted context omitted.

localhost.microsoft.com and localhost.yahoo.com also used to redirect to 127.0.0.1. And, of course, this wreaked utter havoc with cookies (since cookies are accessible across the entire domain). Zalewski discusses in TTW (The Tangled Web). DNS hackery is really dangerous.

I gather that Xip.io have the same issue with cookies.

Yes, but xip.io doesn't host any production services with which test cookies might interact.

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#99

Earlier quoted context omitted.

> For example, with XMPP servers, multi-user chat and any components must live on a subdomain. 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.

Interesting, this must be a shortcoming of OpenFire then. With OpenFire I haven't found a way around having the MUC and extension subdomains accessible via DNS, regardless of whether or not requests are coming from the same domain or not. Is this not necessary with other XMPP servers? Which ones are you using, if I may ask?

I've used jabberd2 and ejabberd, neither of which had that constraint. Can't remember from my experiments with OpenFire or Prosody.

Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address

#100

I think it really speaks to the impoverished startup environment in Chicago that this ends up as an un-monetized throwaway product. In Silicon Valley an idea like this could lead to a helluva exit with backing from incubators like YC.

That's funny. I would interpet it the other way around. It doesn't say much for SV if they have to make money off of redundant little .js hacks like this. They have nothing better? That's the problem with SV. Lots of stupid money, conniving VC and no standard for what constitutes an actual business. They can take anything and spin it into a "company" just to reach a "helluva exit". What a joke. It is all going to implode.
Post reply on HN