Faster, More Awesome GitHub Pages | Hacker News Reader

Faster, More Awesome GitHub Pages

github.com

183 pointsbevacqua63 comments

Interesting how ALIAS records are becoming a de-facto DNS protocol feature. Despite not having even an RFC draft proposing their existence, GitHub recommends using ALIAS records, and large players (e.g. AWS, Dyn, and DNSSimple IIRC, as well as us) now support adding ALIAS records to a domain.

I wonder why ALIAS took hold but DNAME and ANAME records were never widely supported despite actually making it into a few RFCs. Hrmm.

(Disclaimer: Namecast (http://www.namecast.net) supports ALIAS records as well, so I have an abnormal interest in what was otherwise a small part of the article.)

The worst part of ALIAS is that traditional hosted DNS servers don't support it, as far as I can see. Usually CDN providers do handle static IP addresses at the zone apex somehow, but in this case it seems they don't.

It's not a real record in the sense that it's never sent to the client so it doesn't really matter no ? It's just a convenient way to say "return an A record or that fqdn" on the configuration side.

Yeah, you should never see anything like "IN ALIAS" in the output of dig, for example, and getaddrinfo(3) wouldn't know what to do with that sort of record. It's all internal to the authoritative NS.

...which is a bummer, because doing this adds a weird sort of black box step in the DNS resolution chain between client and server. It makes troubleshooting DNS problems not so much fun.

Agreed and the option is often displayed along other real DNS records names adding to the confusion if you're not familiar with DNS systems.

No support for ALIAS on namecheap

DNSMadeEasy apparently supports ANAME records (according to their docs); ANAME's are essentially ALIAS records with a different qtype (though from what I remember, the RFC that proposed them is now deprecated.)

+1 for DNSMadeEasy. The interface is not the best but their pricing is really competitive and their product super stable.

Oh wow. I was doing a transfer of some sites and at the same time looking for a good + affordable DNS service and went with http://freedns.afraid.org/. Seeing that I can get even better service for under $2/month at DNSMadeEasy makes for a compelling proposition.

> (Disclaimer: Namecast (http://www.namecast.net) supports ALIAS records as well, so I have an abnormal interest in what was otherwise a small part of the article.)

Kudos, this is one of the most subtle advertising comments I've seen yet.

Sorry, it really wasn't meant to be. (And I think anyone "advertising" on HN in that way would be dealt with pretty quickly.)

Mine was originally one of the first comments on the article, and it turns out lots of people have had questions about ALIAS records since then, because "what's an ALIAS record?". (If you read the comments, I've actually been advertising for our "competitors" if anything - I think I got DNSMadeEasy a sale today ;).

What's an ALIAS record? I don't even see that here:

https://en.wikipedia.org/wiki/List_of_DNS_record_types

To my understanding, it's a new, nonstandard thing invented by DNSimple that lets you specify your base domain as a reference to another domain — basically, it's like a CNAME where an A record would normally be required.

Yep. ALIAS records exist basically to get around the CNAME restriction introduced in RFC 1034. Basically, with a CNAME, you can't have any other qtypes for the leaf that you're on. (I'll explain what that means...)

For example:

If you set up subdomain.yourdomain.com to be an A record to to 10.0.1.1, you can also set up additional A records, AAAA records for IPv6, and even MX and NS records for subdomain.yourdomain.com.

If you set up subdomain.yourdomain.com to be a CNAME, you can't have any other record types for subdomain.yourdomain.com.

ALIAS records exist because you can't CNAME your root record - the root of your domain has to have at the very least an SOA record, and NS records are going to be needed for the domain to actually resolve. Since those record types exist at the root of your domain, and since CNAME's can't coexist with other record types, you can't use CNAME's at the root of your domain.

Accordingly, the ALIAS record really is only useful to redirect the root apex of your domain somewhere else.

(Just my two cents.)

So is this blog incorrect in stating that you can simply change CNAME at your domain's registrar and still take advantage of github's CDN for "apex" domains? http://davidensinger.com/2013/03/setting-the-dns-for-github-...

Github stated that if you use an "apex" domain your only option is to set A records to their IP but that doesn't seem right.

Yeah, that blog isn't right, or at least it shouldn't be. (Just because a DNS registrar allows you to set up @ to point to a CNAME, or www to point to multiple CNAMEs on their authoritative servers, doesn't mean that your recursive nameserver will know what to do with that.)

It might be that Namecheap allows you to configure "CNAME's" but actually implements them as ALIAS records or HTTP redirects or something similar and obscures that from the user. Not having a Namecheap account I can't say for certain.

GitHub is correct, the @ record cannot be a CNAME.

Interesting and thanks for the clarification. I see they have (Alias) in parenthesis so it makes me wonder if they are implemented as ALIAS records. This will take some more digging.

Generally speaking, an ALIAS record points to a hostname. The DNS server software then fetches the IP address behind that hostname, and returns it as an A record to the user.

Normally, this is solved by using a CNAME record, but if you use a CNAME as the zone apex, then you cannot have any subdomains (because they will all be resolved through the CNAME record).

For some additional information: http://scripting.com/stories/2011/11/13/dnsimplesNewAliasFea... http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Cre...

That's absolutely correct.

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)

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).

I think that's right. But:

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.

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).

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.

[1] http://www.cdnplanet.com/blog/which-cdns-support-edns-client...

Google's public DNS (8.8.8.8) uses anycast as well.

https://developers.google.com/speed/public-dns/faq#anycast

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.

That article says that Fastly is not doing Anycast.

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:

  X-Served-By: cache-fra1225-FRA
  X-Served-By: cache-d46-DAL

[1] https://news.ycombinator.com/item?id=6975830

I have always wanted to be able to use routeviews for more than an easy way to bring about feelings of network inadequacy.

You can not have a CNAME at apex/root/naked domain such as example.com level. you can not point example.com CNAME username.github.io. The DNS spec only allows A records/Ip Addresses at this level. some companies have come up with Alias record which works like CNAME on apex domain, some old DNS Servers might not recognize this but most do these days.

I'm going to risk looking stupid here but what is the preferred DNS setup then, to make sure both example.com and www.example.com resolve to a GitHub Page at the custom URL www.example.com?

The way I read their documentation I set only a CNAME for www -> username.github.io. Does this mean I set no A record at all for the domain, to make sure I get the benefit of the CDN? If yes, how do I ensure requests for example.com resolve to www.example.com?

AIUI: If your provider supports ALIAS then you set an ALIAS for example.com in addition to the CNAME for www. If your provider doesn't then you'll have to set an A for example.com to point to their IP, and the CDN won't work for example.com.

The preferred way is to choose either www.example.com or example.com and let only one of them resolve, while the other should issue a 301 ("Moved permanently") back to the one that resolves.

The easier one to set up is to prefer the www version since it can be done with a simple CNAME and many DNS providers will offer a free automatic 301 forward for the non-www version. (But tastes differ on whether the non-www version looks better.)

Letting both versions resolve would give issues with Google indexing multiple versions of the same page, and reduces the ability to cache properly.

I'm looking to park a few low-traffic charity sites there and 'Set it and forget it' (like Ron Popeil). I think having both with and without the www working is a higher priority than SEO, so I'll have to compromise and set A records for example.com and CNAME for www.

If anyone figures out a better practice please leave a comment. My preference is no www (with www 301-ing) plus the CDN benefit, but this probably isn't possible.

"Same dos mitigation as GitHub.com" I should expect some downtime then

I'm not entirely sure why they say that since www.github.com is using Github's own BGP IP space whereas the CDN they're talking about is Fastly. In other words, github.com may not be on Fastly unless Fastly has built out separate infrastructure for them with Github's IP space.

Please GitHub add https (with SPDY) support. Willing to pay for this.

MediaCrush hosts our blog [1] on GitHub pages, and we proxy it [2] with nginx to add SSL.

[1] https://blog.mediacru.sh

[2] https://github.com/MediaCrush/MediaCrush/blob/master/config/...

And the pages: https://github.com/MediaCrush/mediacrush.github.io

Why not just host it yourself then? You can get precompiled gzip and sane caching. The only reason I can think of to use GitHub Pages is not wanting to pay for a proper host.

Two reasons:

Deployment. It's easy as pie to deploy GitHub pages.

Open-source. MediaCrush itself [1] is open-source, and we wanted the blog to be open and well tuned for pull requests and such.

[1] https://github.com/MediaCrush/MediaCrush

Having used GitHub Pages, S3 and my own VPS for hosting, a homebuilt host is by far the easiest. rsync is easier to use than git, which is a million times easier to use than S3.

I might go so far as to say that storing compiled HTML on git is an antipattern, but that isn't to say that you can't mirror the generator and posts on GitHub.

Well, I would use git anyway because I want it to be under version control. I'm intimately familiar with git and I consider it no harder than rsync. There are so many benefits offered by version control that I wouldn't dream of doing it with something like rsync alone.

Why? Given the restrictions of github pages, it doesn't seem like security could possibly be an issue, and it also seems like a not-particularly-compelling case for SPDY's muxing.

>Our plans start at $8/month. Register .com for $14, .me for $24, and .co.uk for $8

I don't get services like DNSimple. Why would I pay monthly just be able to pay to register domains? What am I missing?

Some users are fine with using their registrar's domain servers, others prefer a dedicated DNS provider to escape the constant barrage of upselling (looking at you Register.com and GoDaddy), or to get access to advanced features (read: native IPv6, anycast, geographic targeting, that sort of thing. DNSimple has a RESTful API and an iPhone app, for example), or - mostly - to get better support than registrars are typically known for providing. (Go ahead and try to find someone at Enom who wants to talk to you about updating glue records. I'll wait.)

^^This is sort of like saying, "I don't get services like Dropbox. Rsync works fine for me." If you don't think you need an UltraDNS/Dynect/DNSimple type of service, then you probably don't, and there's nothing wrong with that.

(P.S: I'm totally biased, I'm responsible for https://www.namecast.net, a GitHub + DNS mashup).

The monthly $8 plan is for DNS service. The other fees listed are for yearly domain registrations. The language could certainly be more clear around that.

What CDN? CloudFlare?

    c:\>ping dangrossman.github.io
    Pinging github.map.fastly.net [199.27.72.133]

Fastly (http://www.fastly.com/).

So I'm not the only one who went looking :) Not sure why they don't mention the specific CDN on their blog post. Possibly because they host at Rackspace but don't use Rackspace's CDN? (Which is white label Akamai last time I checked).

Apparently they don't yet have a great network of nodes in Europe though:

    ping dangrossman.github.io
    round-trip min/avg/max/stddev = 16.173/16.275/16.463/0.074 ms

(From Paris, France)

In comparison, Cloudfront is something like 2ms away.

They've been using fastly for a while now, makes sense that they're using fastly in this case as well.

Doesn't look like it:

    dig +short NS github.io
    ns2.p16.dynect.net.
    ns4.p16.dynect.net.
    ns1.p16.dynect.net.
    ns3.p16.dynect.net.

You need to hit a subdomain of github.io (any subdomain) to see the CDN; that's where user pages live.

All that shows is who they're hosting their DNS with, it has nothing to do with using a CDN. Dynect offers a CDN management tool that makes it easy to balance multiple CDNs across specific regions, so I'm not at all surprised they're using them for their DNS.

If they were using Cloudflare, as the other commenter had asked, they would be using Cloudflare nameservers

While it's true that they could be using the DNS servers, it's not true that they have to-

https://support.cloudflare.com/hc/en-us/articles/200168706-H...

Is there any way to point my github page (jdan.github.io) to a domain (let's say www.example.com) without losing all my projects' github pages (i.e. jdan.github.io/cleaver)?

Last time I tried it wasn't possible.

If you put a CNAME file in the repo, all of the project pages automagically route.

For example, sheetjs.github.io is configured to handle oss.sheetjs.com: https://github.com/SheetJS/SheetJS.github.io/blob/master/CNA...

The gh-pages branch for js-xls (https://github.com/SheetJS/js-xls/tree/gh-pages), accessible at http://sheetjs.github.io/js-xls, now redirects to http://oss.sheetjs.com/js-xls (and does the right thing so long as the main site repo doesn't have a conflicting directory)

As an example of a conflict, consider http://oss.sheetjs.com/test_files/ . The test_files repo (https://github.com/SheetJS/test_files/tree/gh-pages) is masked by the test_files subdirectory of the main repo (https://github.com/SheetJS/SheetJS.github.io/tree/master/tes...)

Hmm, so changing gh-pages on a project doesn't change anything, because it redirects anyway? That's sort of a bummer.

Thanks for your insight though, much appreciated.

I think "route" was the wrong word. If you set up CNAME in github.com/jdan/jdan.github.io to jordanscales.com, then accessing jdan.github.io/cleaver will result in a request to jordanscales.com/cleaver.

If your repo github.com/jdan/jdan.github.io has a cleaver subdirectory, then it will direct to the directory in the repo (masking the gh-pages branch). However, if you do not have a cleaver subdirectory (which is the case at the moment of writing), the gh-pages branch will be visible

What do you mean that changing gh-pages on a project doesn't change anything? The github pages for the project will continue to be available, but they will be available at www.example.com/project instead of username.github.io/project.

Why would I ever pay for CDN service, now that GitHub Pages provides CDN service for free? Am I missing something? We can all use Fastly for free now...

I am a little surprised that it took them this long to go to a CDN, actually

They used different CDN previously ( MaxCDN i believed it was ), now they changed to Fastly.

"Faster" is true, but "more awesome" is marketing.

Reply on news.ycombinator.com