There are some things you can do to protect yourself against these kinds of problem. About 92% of DNS resolvers honour the TTL setting for the NS records from the leaf-node child-zones (e.g. the NS records you control as the owner of a domain). If your domain is reasonably popular, then that caching can help you outlast a problem with your TLDs name-servers. 2 days is a pretty common number for a cache lifetime.
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.
I apologize for bothering you with this but I was nerding out on DNS recently and I have learned just enough to get very confused. It seems that you (the royal you) are benefiting from glueless out of bailiwick entries?
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.
I'd say that the advice is outdated, but I'll try my best to explain and you can decide.
"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.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.
Anthony from DNSimple here. I'll pass along what I know so far: some of nic.io's name servers appear to be no longer delegating .io domains out to authoritative name servers. Some of their name servers are still delegating properly, but some are not.
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.
ooo, you do 301 redirects, I'll be over shortly...
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...
We're back online at http://candid.io. Someone on twitter posted "VCs should think twice before investing in startups without a .com" -> I think that's patently absurd. Azure, AWS, and the other 'core infrastructure' services suffer similar outages form time to time.
I hate genericized ccTLDs, but I don't think the VCs are the ones who should be avoiding them. People creating services should stick to .com, get the .net, and if they have to do something like "getdropbox.com" until they can buy dropbox.com, so be it.
Going from dropbox.io to dropbox.com is ok, but I'd probably go for getdropbox.com in preference to dropbox.io.
Well as a person hosting a service under a .io domain I must say that it's next to impossible to find a decent domain under .com these days. They are all taken by domain sharks hoarding away and running link-farms. The .io landscape is a refreshing one, it's well recognized by it's typical audience (tech people), expensive enough so that it's not attractive for the domain-sharks, and there's plenty available.
1) Once you're successful you have to get the .com/.net/etc anyway. There's a lot of ambiguouty when you say "go to my site, de.lici.o.us" (which was probably the dumbest one ever), but even saying "referly" makes me think "referly.com" more than "refer.ly". If you're going to get the gccTLD, you absolutely must have sitenameio.com too. So, it doesn't really save you from "decent domain not available" -- prefixing with "get" or "my" in .com isn't any worse.
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.
Yes, you're taking on a bit more risk in the short-term... but everything's a trade-off, you're getting much back for a slightly elevated risk in having a short, concise, very meaningful (in our case) name that influences adoption. There's no other alternative -> .COM is a limited resource, only reasonable assumption is that reliability of other TLDs must improve in the long run.
On April 29 I received a notice from firstname.lastname@example.org concerning user-generated content that I was to remove from an IO domain "by April 2" (ie a month earlier) - otherwise they would advise the complaintant to contact law enforcement and would suspend the domain "upon receipt of a formal request to do so".
When I attempted to reply, the email address was out of order ("Write error: Broken pipe") and remained so for several days.
It doesn't seem to be the most professionally run domain...
This may work for API endpoints but there's little re-course for your primary domain. It makes more sense to have .COM/.NET as your primary domain and have the .IO as a convenient alternative than the other way around. But my opinion is still that this is a short-term issue: the reliability of other TLDs will improve.
$ host www.filepicker.io
www.filepicker.io is an alias for anycast.filepicker.io.
anycast.filepicker.io has address 18.104.22.168
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)
Thanks Steve, agreed - just unfortunate that I only found your service earlier today, and when I went back the site was down :( Would having a custom domain have got around the problem, or is that a CNAME to your .io domain?
Yeah, I was deploying to Heroku when this roots error occurred. This screwed up the deploy (as it crashed in the middle) and just 500'ed on every page load. And meant every DNS request in my deploy chain that relied on *.notable.ac resolving ended up caching negative results. Luckily it's back up now :)
It is not possible to move away from them. nic.io is the registry for .io domains, so you can't move to anyone else. They also act as a registrar for their own TLD, so you could move to another registrar, but ultimately they're responsible for .io delegation.
I thought it was as I transferred fine.io over to someone else because I found out nic.io were storing passwords in plain text. Sadly, it seems not. It's quite frustrating to know your business is essentially at the mercy of people that don't know what they are doing.