Xip.io - a magic domain name that provides wildcard DNS for any IP address
91–100 of 128 posts
Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address
#92I'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…
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
#93Earlier 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?
Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address
#94I'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…
Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address
#95I'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.
Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address
#96Earlier 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...
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
#97What 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.
Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address
#98Earlier 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.
Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address
#99Earlier 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?
Re: Xip.io - a magic domain name that provides wildcard DNS for any IP address
#100I 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.