Registrars provide the nameservers you give them to the TLD itself. So, resolution doesn't depend on the registrar's infrastructure unless you're using the registrar's nameservers directly.
It works like this:
Root -> TLD -> NS -> NS -> ETC.
Thank you for the reply. Can you explain how "provide" works in your first sentence? How does the .com TLD server know who registered google.com ? Seems like TLD servers still have to know the list of possible registrars where one can register a domain for their TLD.
Yes, registrars have an agreement with the TLDs and have API access that allows them to submit requests for DNS delegation, transfers, registrations, creating glue records etc.
The registrar will send a request to the TLD to essentially ask that they delegate your domain to a specified nameserver which will add records to the TLDs zone for your domain
Opensource OpenTTD [1] (based on Transportation Tycoon Deluxe) is still around and in active development it seems. It was a great Simcity replacement in the past for me. Obviously graphics are dated, but gameplay was great.
No domain registrar should be taking the last four of your credit card number as proof of account identity or ownership. We certainly don't. Have you confirmed they reset the password based on just the last four of the credit card OR was your account's email address itself comprised, allowing them to reset the password via your email address?
Building on that:
The github blog post states that using an ALIAS record will allow you to take advantage of their CDN. I don't know if I believe that. Since the ip is being fetched by the ALIAS supporting nameserver, the CDN will use that as the end user location. Therefore, everyone is going to that location.
The only way around that would be:
1) CDN uses IP ANYCAST (in which case their CDN would work with just listing the IP as well and the ALIAS point is moot)
OR
2) ALIAS supporting nameserver uses the draft edns-client-subnet rfc (very low probability any current ALIAS provider uses it to resolve the ALIAS since support for the draft may be iffy and much heavier ns resolve logic for ALIAS provider).
Additional thoughts welcome.
Update: Github's external CDN provider is using ANYCAST, so that explains why that's working --- AND --- to explain why their CDN doesn't work on direct ip pointing is because they are giving you the ip to their own direct servers, which are non-cdn / non-anycast, which explains why in this case, the ALIAS record gives the benefit for their CDN, while the ip doesn't (because they're having you use a different non-cdn ip so they can change external cdn providers at will and not affect those that are pointing to the ip directly).
a) this is a common problem for CDNs, as you can never guarantee the DNS server that's asking for your CNAME is close to the cache servers that you want to deliver your end-user content; I'd be surprised if the first CDN cache server a client fetches github content from didn't inspect the end-user IP address from the HTTP session and redirect to a closer / "more optimal" point of presence if one were available;
b) In any case, it looks like Fastly is using anycast from a quick telnet to route-views.routeviews.org.
this is a common problem for CDNs, as you can never guarantee the DNS server that's asking for your CNAME is close to the cache servers that you want to deliver your end-user content;
This is the case, and it's a significant problem - especially for people who use Google's DNS server or OpenDNS
There is an experimental, but reasonably widely deployed[1] solution available though.
I'd be surprised if the first CDN cache server a client fetches github content from didn't inspect the end-user IP address from the HTTP session and redirect to a closer / "more optimal" point of presence if one were available;
That's pretty unlikely. The redirect is going to cost more than just serving the data (and of course there is no way to persist that redirect back to the DNS layer, so it will happen for every resource). "Media" CDNs (ie, CDNs optimised for delivery of large files like movies) sometimes work like this though.
HOWEVER, since Fastly/Github is doing Anycast, none of this should affect them.
I'll just put this here: Anycast doesn't _necessarily_ break CDNs in the way this thread has been implying. Ideally you've got some sort of loose unicast rpf in place for your DNS nodes, and have them receive DNS queries on the anycast address, and send outbound queries out of a local interface so that the NS you're querying knows where you're located... but this is getting a bit far afield of GitHub's new features in any case. PM me if you want to here me blather about DNS and CDNs more. And cross your fingers that edns0-subnet gets implemented sometime soon.
definitely not doing Anycast. As I wrote just a few days ago [1] github.map.fastly.net resolves to a different IP address based on the geographic location of the user. The exact server location might be approximated from the X-Served-By response header:
Redirecting the user to somewhere closer, for small content like you would have on Pages, would make a bad situation (talking to a suboptimal server) much much worse (due to having to setup a second connection and do another round trip with the new request).
You'll only have to confirm any underlying email changes in your example. However, the new ICANN contract also mandates a yet to be defined "Privacy and Proxy Accreditation Program", which will bring changes to the different whois privacy services that registrars currently offer.
Competitor registrar here. This is actually required by the new 2013 ICANN contract. Not all registrars are on the new contract yet, but those that have already signed are required to start following it as of January.
You can thank the law enforcement lobby and ICANN wanting to keep them happy. All of us registrars fought hard against it for a number of obvious reasons, but they went forward with it anyway.
Almost all registrars will be on the new contract soon if they already aren't because ICANN made it a requirement to be able to sell the new GTLDs. This is now going to be a normal part of owning a domain name.
Example 1: You are a large company, and registered 200 domain names for various products, spellings, local shops and such.
That is 200 verification emails, which now need to be pressed or whoops, no more working web shop, email!, and internal API will stop working and so on. Remember that broken DNS will cause emails to bounce rather than being resent later by the mail server.
Example 2: A company is changing name/owner, and in middle of all this need to register new domain name. Whoops, forgot to activate in all that?
Your first example isn't correct. As with the existing WDRP emails that people receive, registrars can batch the verifications. Also, verification doesn't need to be done on a domain-by-domain basis, but on a contact-by-contact basis, thus if all 200 domains use the same one contact in all roles, only one verification needs to be done.
Of course, if your registrar doesn't manage contacts as separate objects from domains (and some don't), they yeah, you'll end up getting a boatload of verification emails.
You'll also start finding a bunch of registrars doing email address checks to ensure deliverability before any registrations or contact updates are performed: this is for the customer's good and the registrar's good.
Registrars have to make a best effort to contact the customer by email. That means that if the email does bounce initially (due to DNS issues, full mailbox, &c.), it's up to the registrar to try again until the grace period expires.
Your second one isn't correct: if your contact has already been verified, there's no need to verified again. It's only if the contact is new or updated that verification needs to be done.
In the third case, you should be using roles, not individuals. Mail aliases were invented for a reason: no one person should be receiving these emails, so it's really your own tough luck if you're a business and you're not ensuring that there's somebody always able to receive and process the emails. Moreover, verification happens when a contact is created or updated, so it should be an address with somebody immediately able to process the verification request.
As far as my ability to write authoritatively on the subject goes, I'm the development lead for a registrar, and implemented most of our domain management system myself.
While I'm personally not a fan, it's not all that silly. If you've registered a domain in the past, your registrar likely invoices you by emailing you the invoice when your domain comes up for renewal (margins are so tight that it's the only cost-effective way). And if you're not checking your mail and you haven't authorised them to automatically charge your credit card, it's possible to miss your payment reminders, which could lead your domain to go into redemption and be deleted for non-payment.
Also, the verification checks only need to be done after you initially submit your contact details or after you attempt to change them, so it shouldn't be too much of an issue.
The big problem that registrars face is that law enforcement want us, the registrars, to verify phone numbers and addresses too, which is going to push up costs quite a bit, even if we find ways of doing so without having to actually phone people.
Verifying a phone number should be pretty easy - auto-call, force them to enter a code. Apart from calling cell phones and some countries, it shouldn't cost more than a few pennies.
Verifying addresses sounds like a real pain though. I imagine they'd want a scan of some ID or something else just as silly. Hopefully ICANN can push back on LE.
Less straightforward than you'd think. Ideally, it'd just be a matter of a text or call and having them input a code, but the costs lie in the failure state: we already deal with a large number of ccTLD registries, and many of those, including the IEDR (.ie) who we deal with regularly, require some form of documentation to allow domains to be registered, contacts to be updated, &c. Even with a 30% gross margin on .ie domains, the support costs with a highly automated application documentation submission process are high enough that we don't actually make much money on two-year registrations until the first renewal.
Thankfully, the new requirements for gTLDs aren't quite that onerous: we have to contact them to validate phone numbers and emails (which can mostly be automated), and we only have to ensure that the address provided is valid. That said, the costs involved in address verification aren't small, and we're hedging potential savings in avoiding fraudulent customers against the additional costs involved.
ICANN can't push back against the LEAs though: this stuff is now in the contract, so we're all stuck with it.
Some of us are waiting on ICANN to process waivers so that we can opt out of certain requirements of the 2013 RAA that are contrary to our local law, but ICANN are dragging their heels on processing the waiver requests. That's especially an issue for European registrars like ourselves, as we have stricter data privacy laws than the US does.
The verification and validation requirements the LEAs pushed down our throats are still crazy, even if they're not as bad now as what they were initially looking for.
> You can thank the law enforcement lobby and ICANN wanting to keep them happy.
Yeah, because there's absolutely no way to have an anonymous email address... /s But seriously, what does law enforcement think this will accomplish? I could see ICANN wanting to cut down on squatters or other domain delinquents, but for tracking down criminals this seems pointless. If anyone has theories or info on what they hope to accomplish I'd be interested.
If domains weren't obnoxious enough to deal with, a combination of contact verification and hundreds of new top level domains really is just icing on the cake. I just renewed my domains so that I don't have to bother with verification for a while, and somehow the amount of upselling is just astounding.
Registrar here (Misk.com). Wanted to share some information on the restore fees discussion. Yes, registries charge hefty restore fees. Using .com as an example (since it can be different for each extension), there is a renewal grace period that can last up to 45 days (we delete at 40 days). Once the name is deleted, the name goes into redemption for 30 days after that. This is where the high fees are hit due to the registry. The thing to note is that some registrars no longer delete names after the renewal grace period ends and pass the name into an auction system. Hence the name never goes into the real redemption period. In those cases the name is still in the renewal grace period and charging higher redemption fees is a business decision by that company. You can tell if this is the case if after a registrar's redemption period, anything happens to the name except becoming available to register by the public (after a 5 day pending delete at the registry). The real redemption period is 30 days and is reflected in the whois record. Domains should still be renewed before expiration since things could change at any level and there is no reason to risk it.
Here are the expiration policies I could find for GoDaddy, Namecheap, and Misk.com (us):
It works like this: Root -> TLD -> NS -> NS -> ETC.
Root Servers are fixed and everything drills down from there: https://www.iana.org/domains/root/servers
A visual example of how the nameserver hops work starting from the root using the nameserver delegation view feature of our dns lookup tool: https://www.misk.com/tools/#dns/news.ycombinator.com@i.root-...
(Disclosure: I work @ Misk.com, an ICANN accredited registrar, our link above)