71–80 of 128 posts
This would be great for testing multi-tenanted cloud applications. For example: tenant1.10.0.0.1.xip.com tenant2.10.0.0.1.xip.com tenant3.10.0.0.1.xip.com 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.
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…
Hold on - who cares? This isn't meant for use in production right? Or am I missing something... from what I can tell the purpose here is that I can setup a domain that will resolve to an address on my LAN without having to modify, say, /etc/hosts on my android device (which I wouldn't even know how to do) or setup a DNS server on my LAN (which is of course possible but a lot more long winded than the solution propose…
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.
Earlier quoted context omitted.
[deleted]
(The author of the software wrote a comment here: "So you're just here to shit on things?", which he has since deleted.) 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 r…
Earlier quoted context omitted.
Yeah but then you're into jailbreak-warranty-invalidation territory. Great for personal devices, not so great on corporate.
Why would adding a proxy server invalidate your warranty? Adding a proxy is built in to iOS.
Earlier quoted context omitted.
Hold on - who cares? This isn't meant for use in production right? Or am I missing something... from what I can tell the purpose here is that I can setup a domain that will resolve to an address on my LAN without having to modify, say, /etc/hosts on my android device (which I wouldn't even know how to do) or setup a DNS server on my LAN (which is of course possible but a lot more long winded than the solution propose…
Edge cases and niggling "works ok for me" problems really do matter for something that's intended to be used with testing. 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 t…
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?
Why is this better than adding an entry to my hosts file?
How are you going to add an entry to the hosts file on an iPhone?
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…
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.
Earlier quoted context omitted.
Edge cases and niggling "works ok for me" problems really do matter for something that's intended to be used with testing. 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 t…
What I took away from this, though, is that they just want to be able to load a web application they're developing on their iPad/iPhone or otherwise "restrictive" device that doesn't allow you to easily make local DNS modifications (such as /etc/hosts files). 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 ma…
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.
Earlier quoted context omitted.
(The author of the software wrote a comment here: "So you're just here to shit on things?", which he has since deleted.) 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 r…
Bravo. I sometimes wish HN had an option to filter out 37 Signals items...