Netværksfirma: Facebook-nedbrud skyldtes problemer med DNS

Illustration: kenny001/Bigstock
Det var systemet Border Gateway Protocol (BGP), der lagde Facebook-tjenester ned. Øget DNS- og netværkstrafik fra brugere og apps belastede mange andre sites.

Det var protokollen Border Gateway Protocol (BGP), der i går lagde Facebook og en række andre firmaers tjenester ned omkring klokken 18 dansk tid. Det skriver netværksfirmaet Cloudflare i et blogindlæg.

Ifølge firmaet kunne opslag i Facebooks DNS-system, som er nettets telefonbog, der veksler domænenavne til IP-adresser, ikke længere udføres.

Det var mange flere tjenester end Facebook og Instagram, der blev ramt af gårsdagens nedbrud. Her er det tjenesten Downdetector.com omkring kl. 18.30, der viser brugerrapporterede problemer på en lang række sites. Illustration: Skærmdump/Version2

Den bagvedliggende årsag var ifølge Cloudflare, at Facebook stoppede med at annoncere firmaets ruter via BGP-protokollen, der styrer trafik mellem internettets store knudepunkter.

Cloudflare skriver i indlægget, at Facebook opdaterede sine ruter kl 16.40 dansk tid, og det var der, problemerne startede.

Udfaldet på Facebooks DNS-system betød, at apps gentagne gange forsøgte at slå firmaets adresser op, mens slutbrugere også genstarter apps og genindlæser websider. Det betød, at mængden af DNS-forespørgsler steg voldsomt.

På de DNS-systemer Cloudflare håndterer, steg antallet af forespørgsler 30 gange normalen, og skabte forsinkelser i svar og timeouts, som også påvirkede andre end Facebook.

De frustrerede Facebook-brugere vendte sig i nødens stund mod andre tjenester, og det øgede trafikken til Twitter, Signal og andre beskedplatforme, skriver Cloudflare.

Det betød, at der var mange flere tjenester end Facebook og Instagram, der blev ramt af nedbruddet. Det fremgik af tjenesten Downdetector.com, der opsamler brugerrapporterede problemer på en lang række sites. På illustrationen til højre ses situationen for en række sites omkring klokken 18.30 i går.

Læs også: Facebook og Instagram ramt af stort nedbrud

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Povl H. Pedersen

Overskriften "Netværksfirma: Facebook-nedbrud skyldtes problemer med DNS" er direkte forkert.

Problemet skyldtes en fejlkonfiguration af BGP, så Facebook reelt annoncerede at der ikke var nogen måde at tale med dem på. Det fremgår også af brødteksten.

Da Facebooks DNS servere ALLE lå på Facebooks eget netværk, som så ikke kunne nås, så kunne man ikke slå FB navne op noget sted, men det var et symptom og ikke en årsag. Men det resulterede så også i problemer for alt det crap der inkluderer FB content, tracking billieder etc.

Hvis FB have haft en enkelt sekundær DNS udenfor eget netværk, så ville DNS problemerne ikke være der, og man ville nok hurtigere have konstateret at BGP ruten var trukket tilbage.

  • 16
  • 2
#3 Henrik Kramselund Jereminsen Blogger

Når man nitpicker skal man passe på, spejlet kommer hurtigt frem

Først og fremmest har FB ikke lavet en root cause analysis rapport, som de har publiceret.

Det betyder at vi allesammen ser på symptomerne.

Der hvor vi er enige, formoder jeg, er at en browser ikke kunne se servere med facebook (og de andre services).

Det er en længere lavine, hvor BGP var skyld i at DNS ikke kunne nås, som gør at browsere, som spørger recursive DNS ikke fik svar.

Om FB servere er på samme prefixes, annonceret via BGP, eller andre er ligegyldigt. Grundet DNS fejlede det ved at hostnavne ikke kunne slåes op. DNS fejlede fordi man ikke kunne nå de servere, som formentlig stod og trillede fint i et datacenter, bagved routere. DET skyldes BGP fejlen.

Tilsvarende var alle FBs webservere, og dertilhørende load balancers m.v. formentlig også oppe og klar til at servicere, online, men ingen kunder ind til dem.

Jeg mener godt vi kan sige DNS er problemet, det var det specifikke step som gjorde at man ikke kunne nå FB servere fra en browser - som vil være det normale man som forbruger vil bedømme servicen på.

Kæden kan FB selv optrevle, og det skyldes formentlig nogle helt almindelige, men uheldige ændringer, som skubbet igennem pipelines af automatisering.

Dernæst kan vi begynde at snakke hvordan de kunne have undgået det.

og siden, og relevant, hvor mange danske firmaer har problemer med dårligere DNS, BGP og lignende.

  • 11
  • 2
#4 Baldur Norddahl

Jeg mener godt vi kan sige DNS er problemet, det var det specifikke step som gjorde at man ikke kunne nå FB servere fra en browser - som vil være det normale man som forbruger vil bedømme servicen på.

Det synes at være lidt søgt. DNS var faktisk irrelevant da du ikke kunne komme til sitet uanset da deres IP adresser ikke var routet. Der gik tilmed mere end en time efter at DNS var tilbage hvor sitet stadig var nede.

  • 5
  • 1
#6 Henrik Kramselund Jereminsen Blogger

Det synes at være lidt søgt. DNS var faktisk irrelevant da du ikke kunne komme til sitet uanset da deres IP adresser ikke var routet. Der gik tilmed mere end en time efter at DNS var tilbage hvor sitet stadig var nede.

DNS er da bestemt ikke irrelevant. Det er det step der fejlede, stopklodsen om du vil. Gav det andre problemer at BGP fejlede, helt sikkert. En af de twitter tråde jeg så havde var det 110 vs normalt 133 routes/prefixes, så ja der er sikkert flere problemer, som man så støder på når DNS er "fixet".

DNS er jo heller ikke bare eeeeen A record, men typisk et antal hostnavne, til diverse ressourcer. Hver af kan så have problemer med NS, records, caching osv. En time til at DNS stabiliserer sig virker ikke unormalt.

  • 3
  • 4
#8 Rasmus Larsen

Problemet var routning, hvilket naturligt tager dns med i faldet, med det setup de har. Det er helt sikkert en design fejl af facebook at deres dns effektivt er afhængigt af et enkelt AS, men dns er stadig en detalje i det her udfald.

Hvis jeg hiver kablet ud af min maskine (og trækker kill-switchen til wifi'et), så vil jeg også få en ton dns fejl, hvor den virkelige fejl er mangel på en default gateway. At påstå at dns vil være andet end en detalje i det problem, er ihvertfald ikke noget der hjælper os videre med en løsning.

Der hvor jeg kan give dig ret er at Facebook nok bør kigge på deres eget dns design.

Engang imellem giver det mening at bruge andres, selvom man godt selv kan...

➜ dig +short amazon.com -t ns

pdns6.ultradns.co.uk.

ns1.p31.dynect.net.

pdns1.ultradns.net.

ns3.p31.dynect.net.

ns4.p31.dynect.net.

ns2.p31.dynect.net.

  • 6
  • 0
#9 Yoel Caspersen Blogger

Det var BGP der fejlede og som følge af det fejlede alle tjenester, herunder også DNS.

Men det store spørgsmål er: Kunne Facebooks manglende svar på DNS-forespørgsler give problemer for DNS recursors, som også skulle håndtere forespørgsler til andre sites?

Vores trafikgrafer siger umiddelbart nej - vi så normale trafikmængder på vores caches, peering- og transitlinks.

Men vi har fået ekstraordinært mange henvendelser fra kunder om problemer med internetforbindelsen i går aftes, hvilket kan betyde flere ting:

  1. Folk mener at Facebook = Internettet
  2. Browsing-oplevelser har været elendige på grund af alle de Facebook spy pixels rundt omkring, som browseren forgæves har forsøgt at loade (med deraf følgende renderingsproblemer og "hængende" TCP-forbindelser)
  3. DNS-recursors har skaleringsproblemer, hvis en stor andel af forespørgslerne tager længere tid (timer ud pga. manglende routes til Facebooks autoritative DNS-servere)
  • 12
  • 0
#10 Baldur Norddahl

Engang imellem giver det mening at bruge andres, selvom man godt selv kan...

Facebook har taget det skridtet videre og er også deres egen registrar.

Følgende er sakset fra mailinglisten NANOG:

On 10/4/21 4:47 PM, Jean St-Laurent via NANOG wrote:

dig @c.gtld-servers.net. facebook.com. NS ;; 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. What happens if the NS aren’t back within 48 hours?

Facebook can just update it at the registrar.

$ whois facebook.com Domain Name: FACEBOOK.COM Registry Domain ID: 2320948_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.registrarsafe.com Registrar URL: http://www.registrarsafe.com Updated Date: 2021-09-22T19:33:41Z Creation Date: 1997-03-29T05:00:00Z Registry Expiry Date: 2030-03-30T04:00:00Z Registrar: RegistrarSafe, LLC

$ dig @c.gtld-servers.net. registrarsafe.com. NS ;; registrarsafe.com. 172800 IN NS a.ns.facebook.com. registrarsafe.com. 172800 IN NS b.ns.facebook.com. registrarsafe.com. 172800 IN NS c.ns.facebook.com. registrarsafe.com. 172800 IN NS d.ns.facebook.com.

crap....

Vertical integration is a hell of a thing.

  • 4
  • 1
#14 Henrik Kramselund Jereminsen Blogger

Det forstår jeg ikke hvordan du kan sige. Det var BGP der fejlede og som følge af det fejlede alle tjenester, herunder også DNS.

Hvis vi snakker root cause, så er det BGP - eller faktisk før i kæden, og den del som FB ikke har fortalt ret meget om, deres FB engineering post er jo næsten tom for teknik.

Hvis vi snakker brugeroplevelsen, klient vinkel så er det DNS de ser som problemet, først.

Jeg kan sige DNS hele dagen ;-)

  • 3
  • 4
#15 Morten Birkelund

Men vi har fået ekstraordinært mange henvendelser fra kunder om problemer med internetforbindelsen i går aftes, hvilket kan betyde flere ting:

Folk mener at Facebook = Internettet Browsing-oplevelser har været elendige på grund af alle de Facebook spy pixels rundt omkring, som browseren forgæves har forsøgt at loade (med deraf følgende renderingsproblemer og "hængende" TCP-forbindelser) DNS-recursors har skaleringsproblemer, hvis en stor andel af forespørgslerne tager længere tid (timer ud pga. manglende routes til Facebooks autoritative DNS-servere)

Jeres internet fungerede perfekt i går aftes, jeg sad og spillede online på min Kviknet forbindelse hele aftenen.. :)

Facebook har egne navneservere alle under samme AS nummer, så hvis de laver en BGP fejl og ikke annoncere deres adresser vil ingen kunne tilgå deres DNS servere (ligesom alle deres andre services)

Så det er faktisk relativt sårbart overfor fejl med AS nummer eller i BGP.

Men DNS serverne har nok haft det ganske fint der har bare ikke været nogen som har kendt en route til dem.

  • 7
  • 0
Log ind eller Opret konto for at kommentere