Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster, More Awesome GitHub Pages

github.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Faster, More Awesome GitHub Pages

#31

Post by cstejerean »

prezjordan wrote: post #29
sheetjs wrote: post #10

Earlier quoted context omitted.

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 th…

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.

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.

Re: Faster, More Awesome GitHub Pages

#33

Post by brymaster »

namecast wrote: post #28
brymaster wrote: post #27

Earlier quoted context omitted.

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 simila…

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.

Re: Faster, More Awesome GitHub Pages

#36

Post by namecast »

Spiritus wrote: post #35

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

Re: Faster, More Awesome GitHub Pages

#37

Post by scottbruin »

abritishguy wrote: post #32

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

Re: Faster, More Awesome GitHub Pages

#38

Post by nl »

namecast wrote: post #25
nitinag wrote: post #21

Earlier quoted context omitted.

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 C…

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 i…

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

Re: Faster, More Awesome GitHub Pages

#39

Post by zimbatm »

giovannibajo1 wrote: post #14
namecast wrote: post #11

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 RFC…

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.

Re: Faster, More Awesome GitHub Pages

#40

Post by zimbatm »

namecast wrote: post #23
namecast wrote: post #11

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 RFC…

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.
Post reply on HN