.io domains down?
Are all down for me.
$ host filepicker.io Host filepicker.io not found: 3(NXDOMAIN)
Are all down for me.
$ host filepicker.io Host filepicker.io not found: 3(NXDOMAIN)
Unfortunately for the 8% of resolvers that honour the TTL in the parent domain, you have less control. In this case for .io, the parent-zone NS ttls are just one hour;
;; AUTHORITY SECTION:
nic.io. 3600 IN NS ns1.communitydns.net.
nic.io. 3600 IN NS b.nic.ac.
nic.io. 3600 IN NS a.nic.io.
nic.io. 3600 IN NS b.nic.sh.
nic.io. 3600 IN NS ns4.nic.io.
nic.io. 3600 IN NS dns01.cdns.net.
nic.io. 3600 IN NS b.nic.io.
which I think is relatively short by TLD standards.Another important thing to consider is that the TLD you choose for your domain itself isn't the only TLD that your domain resolution may depend upon. Resolution also depends on all of the domains of your nameservers resolving too. Route 53 assigns every hosted zone 4 nameservers from 4 different TLDs, e.g.;
example.info. 172800 IN NS ns-1834.awsdns-37.co.uk.
example.info. 172800 IN NS ns-22.awsdns-02.com.
example.info. 172800 IN NS ns-912.awsdns-50.net.
example.info. 172800 IN NS ns-1233.awsdns-26.org.
So that if any one of those TLDs has a problem it does not cause a resolution failure for your zone. Some other providers do this too, and it's also something you could set up yourself.Full-disclosure: Route 53 engineer here.
Should I not have such a strict belief that thou shall not have glueless out of bailiwick entries?
I appreciate you indulging my curiosity/confusion.
"Bailiwick" is the term used for the namespace a nameserver is considered authoritative for. If example.com is delegated to ns1.example.com then all of the DNS names ending in example.com are in-bailiwick. foo.example.com, bar.example.com, foo.bar.example.com and so on. If example.org is also delegated to ns1.example.com, then names ending in example.org are also considered in-bailiwick for that name-server to return.
When example.com is delegated to ns1.example.com there's an obvious circular dependency; how can ns1.example.com be resolved without first resolving example.com? The way that this is solved is by using glue records. A glue record is when you tell the name-servers for the parent zone (.com in this case) what the IP address for ns1.example.com is. That way the com servers - when asked about www.example.com can say; "actually, you need to ask ns1.example.com, and by the way here's the IP address for ns1.example.com".
With an in-bailiwick delegation and glue record in place, a query can get all the way to the server it needs within 2 or 3 queries.
Now, if example.com is delegated to ns1.otherdomain.net, the delegation is out of bailiwick. Now when the resolver asks the com server for www.example.com it gets a response that says "you need to ask ns1.otherdomain.net". But the resolver doesn't know the IP address for ns1.otherdomain.net. So now it has to put the original query on-pause and go and resolve ns1.otherdomain.net. This is part of why resolvers are called "recursive resolvers" - they have to recursively resolve all dependencies.
Of course ns1.otherdomain.net could itself require out-of-bailiwick recursion, and the process could get quite lengthy. That's why some guides recommend against it - especially when managing you're own DNS; you may as well make everything in-bailiwick.
So how do we manage this? A few ways;
Firstly, there's no reason that managed DNS customers can't use in-bailiwick names anyway. Route 53 customers, for example, are free to create their own names that resolve to their Route 53 name-servers and to use those names. For a real world example, if you "dig amazonaws.com" you'll see that we have four names ; r[1234].amazonaws.com that actually point to regular Route 53 IP addresses.
Secondly, the nameserver names used by large providers are usually well cached. At Route 53 we host a lot of customers domains, and many many domains refer to each name like "ns-22.awsdns-02.com.", so for that reason the names are usually very well-cached, even if your own domain is low-traffic.
Thirdly, we chose TLDs that are large, popular and well-run. .com/.net are operated under a single contract by verisign, so if you do; "dig allcosts.net @g.gtld-servers.net" , you'll see that our .com and .net customers actually get the benefit of two in-bailiwick glue records (we have two nameservers that end in .com or .net). Customers with domains ending in .org or .co.uk get one each.
Fourthly, our nameserver domains are themselves exclusively delegated to in-bailiwick names, for example if you do; "dig awsdns-50.net. @g.gtld-servers.net", you'll see that all four of its nameservers are handled as glue-records. This limits the amount of recursion a resolver must do to just one level deep.
Our goal here is to be able provide a simple easy-to-use set of names that work well and are robust regardless of the customer's own domain of choice, without having to maintain hundreds of nameserver names in every single TLD.
This issue also affects .sh and .ac TLDs I believe since they are the same registry. If I find out anything new I'll post on Twitter in the @dnsimple account and here.
To explain why that's useful, we have three domains, draw.io (mutter), diagramly.com and diagram.ly that all map to the same thing. The actual site runs on a Google App Engine appspot domain. On GAE, you have to buy a Google Apps for Business account to map a domain to an GAE appspot domain.
We have three Apps accounts because of this. We're not happy to do the 301 on a physical server, that loses the scalability advantage of GAE. This has always needed to be done at the DNS level ( I know it's not truely a DNS feature, but I'm assuming the scaling of the redirects at someone who does it as a service is better than mine ). This is the first time I've seen this service. That's all...
Just because you're exposed to some reliability risk doesn't mean that you can't expose yourself to more by using a smaller TLD.
Going from dropbox.io to dropbox.com is ok, but I'd probably go for getdropbox.com in preference to dropbox.io.
Why exactly do you hate them?
2) ccTLD has a defined meaning -- it's the country. I don't hate ccTLDs; e.g. Amazon.co.uk makes a lot of sense for the UK site of Amazon. But when people
3) They expose you to additional risk. The US can largely shut down most things, but .ly means you're exposed to Libya (JFC! an internet business voluntarily deciding to be exposed to Libya?)
4) If you really want something other than .com, you could use another TLD. Generally they all tend to be scams (I'm not aware of many .info or .biz domain names which are anything but scams, although I guess a few single-purpose/serving sites are in .info)
In fairness, IO is actually the least objectionable of all the gccTLDs, since "IO" is a pretty bogus ISO code in terms of representing a country.
ccTLDs make sense when you want to "fly the flag" of that country, too -- wikileaks.is or wikileaks.ch makes sense. All the gccTLDs have policies which are strictly worse than .com though.
And 2-letter domains (which are mostly ccTLDs) do make sense for link shorteners, particularly temporary/transient ones.
I also do like .io for previously stated reasons by others... It's techie/geeky (I/O), and it's expensive enough that the squatters have mostly stayed away.
Working:
b.nic.io. ns1.communitydns.net.
Not working:
a.nic.io. a.ns13.net. b.nic.ac. b.ns13.net. ns3.icb.co.uk.
http://blorn.com/post/29851770158/beware-cutesy-two-letter-t...
I guess the title of the blog post pretty much says it all.
It doesn't seem to be the most professionally run domain...
Having a .com or .net as a backup domain, even if it isn't as sexy looking, doesn't hurt.
Send an email to one user asking for feedback and you will get a much better ROI than trying to plan for TLD failure.
$ host www.filepicker.io www.filepicker.io is an alias for anycast.filepicker.io. anycast.filepicker.io has address 174.129.254.207 Host anycast.filepicker.io not found: 3(NXDOMAIN) Host anycast.filepicker.io not found: 3(NXDOMAIN)
$ host filepicker.io Host filepicker.io not found: 3(NXDOMAIN)
Technical details of permanent delivery failure: DNS Error: Domain name not found
I will pour out some PBR for good ol' .io.
$ host algasm.io
algasm.io has address 176.58.123.62"Brandon Thomas is a triple major undergrad at Southern Polytechnic State University in the Computer Science, Biology, and Chemistry programs. Brand loves science, uses Linux and vim, and programs primarily in Python, Javascript, and C++. Computing interests include machine learning and computer graphics. After graduation Brand intends to study computational metabolomics or possibly found a startup company."
They recently switched their backend to a new platform (May 29th) maybe this issue is related…
Good thing it's just some crappy side project.