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

21–30 of 65 posts

Re: Faster, More Awesome GitHub Pages

#21

Post by nitinag »

sharth wrote: post #16
harryh wrote: post #12

What's an ALIAS record? I don't even see that here: https://en.wikipedia.org/wiki/List_of_DNS_record_types

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/st…

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)

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

Re: Faster, More Awesome GitHub Pages

#22

Post by tedivm »

philip1209 wrote: post #18
tedivm wrote: post #13

Earlier quoted context omitted.

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

Re: Faster, More Awesome GitHub Pages

#23

Post by namecast »

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

Re: Faster, More Awesome GitHub Pages

#25

Post by namecast »

nitinag wrote: post #21
sharth wrote: post #16

Earlier quoted context omitted.

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/st…

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 if one were available;

b) In any case, it looks like Fastly is using anycast from a quick telnet to route-views.routeviews.org.

Re: Faster, More Awesome GitHub Pages

#26

Post by saurik »

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…

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

Re: Faster, More Awesome GitHub Pages

#27

Post by brymaster »

namecast wrote: post #20
chc wrote: post #15

Earlier quoted context omitted.

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

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.

Re: Faster, More Awesome GitHub Pages

#28

Post by namecast »

brymaster wrote: post #27
namecast wrote: post #20

Earlier quoted context omitted.

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

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.

Re: Faster, More Awesome GitHub Pages

#29

Post by prezjordan »

sheetjs wrote: post #10
prezjordan wrote: post #8

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

Re: Faster, More Awesome GitHub Pages

#30

Post by sheetjs »

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.

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

Post reply on HN