[sf-lug] github DNS

[Michael Paoli]

[Bcc: off-list email sender]
> Subject: github DNS
> Date: Sun, 10 Apr 2016 19:58:49 -0700

> I can see how github churn would upset clients; in the last few days
> github.com resolves to a different address every damn time I push my
> changes.  Of course this by itself shouldn't cause clients to break if
> they do it *right*, but.

Well, yes, but that shouldn't cause resolve errors.
I'm presuming github.com is using some type of load balancing,
redundancy, and/or geolocation serving via DNS.  Not too uncommon these
days.

E.g. I notice:
$ (for ns in $(dig -t NS github.com. +short | sort); do echo $(dig \
> @"$ns" +noall +answer github.com. A github.com. AAAA) "[$ns]"; done)
github.com. 300 IN A 192.30.252.131 [ns1.p16.dynect.net.]
github.com. 300 IN A 192.30.252.120 [ns2.p16.dynect.net.]
github.com. 300 IN A 192.30.252.130 [ns3.p16.dynect.net.]
github.com. 300 IN A 192.30.252.130 [ns4.p16.dynect.net.]
$ (for ns in $(dig -t NS github.com. +short | sort); do for ip in $(
> dig +short "$ns" A "$ns" AAAA); do echo NS:"$ns" IP:"$ip":; dig \
> @"$ip" -t SOA github.com. +short; dig @"$ip" +noall +answer \
> github.com. A github.com. AAAA; done; done)
NS:ns1.p16.dynect.net. IP:208.78.70.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.130
NS:ns1.p16.dynect.net. IP:2001:500:90:1::16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.130
NS:ns2.p16.dynect.net. IP:204.13.250.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.128
NS:ns3.p16.dynect.net. IP:208.78.71.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.130
NS:ns3.p16.dynect.net. IP:2001:500:94:1::16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.121
NS:ns4.p16.dynect.net. IP:204.13.251.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.130
$ (for ns in $(dig -t NS github.com. +short | sort); do for ip in $(
> dig +short "$ns" A "$ns" AAAA); do echo NS:"$ns" IP:"$ip":; dig \
> @"$ip" -t SOA github.com. +short; dig @"$ip" +noall +answer \
> github.com. A github.com. AAAA; done; done)
NS:ns1.p16.dynect.net. IP:208.78.70.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.122
NS:ns1.p16.dynect.net. IP:2001:500:90:1::16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.129
NS:ns2.p16.dynect.net. IP:204.13.250.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.131
NS:ns3.p16.dynect.net. IP:208.78.71.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.120
NS:ns3.p16.dynect.net. IP:2001:500:94:1::16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.121
NS:ns4.p16.dynect.net. IP:204.13.251.16:
ns1.p16.dynect.net. hostmaster.github.com. 1460338784 3600 600 604800 60
github.com.             300     IN      A       192.30.252.122
$

Anyway, don't think that's a critical part of the resolver issues seen
(which as far as I'm aware are just on one particular installation that
would appear to have some issues, and not more generally).

But such slightly funky DNS setups do make troubleshooting a bit
trickier.  E.g. I notice in the above, one typically wouldn't expect the
same zone serial number to be giving different IPs from different
nameservers ... and then even the same nameservers, giving out different
IPs under the same SOA serial number.  Even if it may possibly not break
RFCs, it does tend to break the principle of least surprise.  Looks like
their serial numbers are also time(2) based.

Anyway, thanks for the thoughts/observations.  I think also original
poster on sf-lug list also noticed and mentioned how the IP addresses
for github.com. changes quite regularly.

references:
http://linuxmafia.com/pipermail/sf-lug/2016q2/011811.html
and much etc.:
http://linuxmafia.com/pipermail/sf-lug/2016q2/date.html