Faster, More Awesome GitHub Pages

https://github.com/blog/1715-faster-more-awesome-github-pages

by bevacqua • 13 years ago

183 63 13 years ago

pbreit• 13 years ago

What CDN? CloudFlare?

dangrossman2• 13 years ago

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

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

toomuchtodo• 13 years ago

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

julien_c• 13 years ago

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.

bevacqua• 13 years ago

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

philip12092• 13 years ago

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.

dangrossman2• 13 years ago

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

tedivm2• 13 years ago

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.

prezjordan2• 13 years ago

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.

sheetjs2• 13 years ago

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

prezjordan2• 13 years ago

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.

namecast9• 13 years ago

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

giovannibajo1• 13 years ago

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.

zimbatm3• 13 years ago

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.

joaomsa• 13 years ago

No support for ALIAS on namecheap

namecast9• 13 years ago

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

zimbatm3• 13 years ago

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

nilved3• 13 years ago

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

namecast9• 13 years ago

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

harryh• 13 years ago

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

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

chc• 13 years ago

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.

namecast9• 13 years ago

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

sharth• 13 years ago

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

nitinag• 13 years ago

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

roozbeh18• 13 years ago

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.

abritishguy• 13 years ago

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

scottbruin• 13 years ago

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.

nodesocket• 13 years ago

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

Sir_Cmpwn3• 13 years ago

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

nilved3• 13 years ago

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.

krakensden• 13 years ago

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.

Spiritus• 13 years ago

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?

namecast9• 13 years ago

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

bgentry• 13 years ago

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.

tombrossman2• 13 years ago

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?

lmm• 13 years ago

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.

speleding• 13 years ago

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.

tombrossman2• 13 years ago

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.

seaghost• 13 years ago

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

slattery• 13 years ago

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

lectrick• 13 years ago

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

ksec• 13 years ago

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

Faster, More Awesome GitHub Pages

Related Stories