

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.
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.
- EU vil skabe egen DNS-tjeneste med indbyggede filtre
- Facebooks nedbrud kostede 1 mio. kr. i minuttet
- Facebooks BGP-maveplasker skabte ringe i hele verdens internet
- Denne artikel
- Facebook og Instagram ramt af stort nedbrud
- Globalt internet-nedbrud skyldtes programfejl, siger Fastly
- Edge-nedbrud lagde mange danske og globale sites ned
- emailE-mail
- linkKopier link

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Hvis man sad og doomscrollede på fjæsbogen mens nedbruddet skete, ville man så ikke allerede have de relevante DNS entries cached? Men være forhindret i videre brug af sitet, på grund af routing fuckuppet?Hvis vi snakker brugeroplevelsen, klient vinkel så er det DNS de ser som problemet, først.
</p>
<p>Men vi har fået ekstraordinært mange henvendelser fra kunder om problemer med internetforbindelsen i går aftes, hvilket kan betyde flere ting:</p>
<p>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.
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 ;-)
Få styr på jeres betegnelser!
Ruter er flertal af rute. Hvis der mentes flertal af router, havde der nok stået routere.
Få styr på jeres betegnelser!
Sjovt nok benytter Instagram.com AWS Route 53 og ikke Facebooks egen DNS.Engang imellem giver det mening at bruge andres, selvom man godt selv kan...
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: https://www.registrarsafe.comUpdated 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.
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:
- 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)
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.
DNS er da bestemt ikke irrelevant. Det er det step der fejlede, stopklodsen om du vil.
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.
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.
Hvordan kan dette forhindre at man kan udføre et whois-opslag på facebook.com? Jeg forsøgte, og kunne ikke.
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.
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.
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.
Cloudflares blog-indlæg er meget pædagogisk og beskriver både hvad DNS er og hvad BGP er.
Derfor er det trist at I kalder BGP for et DNS-system.
Det må og skal I gøre bedre, hvis I vil være et medie for IT-folk.