Comp 343/443-001 Week 6 notes


I ran this on Oct 4, 2021, at 11:30 am (1630 UTC):

pld> dig facebook.com

; <<>> DiG 9.16.1-Ubuntu <<>> facebook.com
;; global options: +cmd
;; connection timed out; no servers could be reached

pld> dig @8.8.8.8 facebook.com

; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 facebook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52651
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;facebook.com.            IN    A

;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct 04 11:31:52 CDT 2021
;; MSG SIZE  rcvd: 41

Let's use DNS to find the Facebook nameservers. There are a lot of them. We'll start with one top-level server for the .com domain: 192.12.94.30, run by Verisign.

pld> dig @192.12.94.30 facebook.com NS +norecurse

; <<>> DiG 9.16.1-Ubuntu <<>> @192.12.94.30 facebook.com NS +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20219
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;facebook.com.            IN    NS

;; AUTHORITY SECTION:
facebook.com.        172800    IN    NS    a.ns.facebook.com.
facebook.com.        172800    IN    NS    b.ns.facebook.com.
facebook.com.        172800    IN    NS    c.ns.facebook.com.
facebook.com.        172800    IN    NS    d.ns.facebook.com.

;; ADDITIONAL SECTION:
a.ns.facebook.com.    172800    IN    A    129.134.30.12
a.ns.facebook.com.    172800    IN    AAAA    2a03:2880:f0fc:c:face:b00c:0:35
b.ns.facebook.com.    172800    IN    A    129.134.31.12
b.ns.facebook.com.    172800    IN    AAAA    2a03:2880:f0fd:c:face:b00c:0:35
c.ns.facebook.com.    172800    IN    A    185.89.218.12
c.ns.facebook.com.    172800    IN    AAAA    2a03:2880:f1fc:c:face:b00c:0:35
d.ns.facebook.com.    172800    IN    A    185.89.219.12
d.ns.facebook.com.    172800    IN    AAAA    2a03:2880:f1fd:c:face:b00c:0:35

This is returning a list of the Facebook authoritative nameservers. There are four of them. These are what tell us what IP address corresponds to "facebook.com". Normally, when we look up "facebook.com" on campus, the query goes to Loyola's site-wide resolver, which if necessary will contact Facebook's authoritative nameserver but which almost always has "facebook.com" in its cache.

We can look up some of the IPv4 addresses using BGPview.io, to find some BGP-related information. If we enter 192.31.80.30, the .com nameserver, we find it is announced by quite a few BGP "autonomous systems" (19 as I write this). This is common, for large organizations: each here is being announced by a different VeriSign AS. No matter where you are in the world, you will connect to 192.31.80.30 through one of these 19 ASes, usually one that is close to you. The globe is in effect partitioned into 19 zones, each with its own server with IPv4 address 192.31.8.30.

The address for facebook.com, from dig today, is 157.240.18.35. That is announced only by the Facebook AS, 32934; they have their own internal CDN for their data. (This address is good in the Chicago area, but not everywhere. See dnschecker.org to resolve facebook.com from other locations.)

At some point Monday morning, Facebook stopped announcing routes to 129.134.0.0/17 and 185.89.128.0/17 via BGP. Eventually this cascaded to other BGP route withdrawals, but without DNS, it didn't matter if those routes were still active. For a large part of the outage, 157.240.18.35 was active and reachable, but nobody could find it without DNS.

Facebook's DNS timeout, by the way, is 300 seconds:

    dig @129.134.30.12 facebook.com

So 300 seconds after the authoritative nameservers disappeared, all the cached values also disappeared.

Here's the Cloudflare blog about the outage: blog.cloudflare.com/october-2021-facebook-outage.


Chapter 10:

DHCP
ICMP
DNS

Chapter 13: Routing

    Basics of distance-vector routing
    Slow convergence