Slack kampt met wereldwijde storing - update

Messagingdienst Slack kampte met een wereldwijde storing. Hierdoor was het voor sommige gebruikers niet mogelijk om berichten te sturen via de chatapp of gesprekken te voeren. De eerste problemen doken op vanaf 18u00 lokale Nederlandse tijd.

Zowel op de Amerikaanse versie van downdetector.com als op sociale media werd aangegeven dat sinds 18u00 lokale Nederlandse tijd Slack moeilijk of niet bereikbaar was. Op de statuspagina van Slack staat te lezen dit door een DNS-probleem was. "Om het probleem sneller te verhelpen, kan het helpen als jouw internetserviceprovider het DNS-record van Slack reset", klonk het bovendien op Twitter. Het bedrijf stelde dat de storing bij sommige gebruikers tot 24 uur kan aanhouden maar maakt zich ondertussen sterk dat maar een klein percentage van de gebruikers nog hinder zou ondervinden.

Update, 00u15: reactie Slack over storing toegevoegd.

Reacties (35)

[Keypunchie]

Mijn ervaring was dat een DNS switch hielp, maar toch meer aan de hand?

[ed.] Wel DNS, maar niet wat ik dacht:

We are aware of connectivity issues related to DNS that are impacting a small subset of users. This issue was caused by our own change and not related to any third-party DNS software and services. In order to resolve this faster, your ISP (Internet Service Provider) will need to flush their DNS record for slack.com. Please reach out to your networking team to provide them with this information.
We expect all customers’ connectivity issues to be resolved within the next 24 hours. We know how important it is for people to stay connected and we apologize for this disruption.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 02:23]

[Snow_King]

Het lijkt op een DNSSEC signing issue volgens deze post: https://lists.dns-oarc.ne...021-September/021340.html

Als mensen nu maar niet denken dat DNSSEC eng is….

[DDX]

Mooie oplossing ook :

https://status.slack.com/2021-09/06c1e17de93e7dc2

This issue was caused by our own change and not related to any third-party DNS software and services. In order to resolve this faster, your ISP (Internet Service Provider) will need to flush their DNS record for slack.com. Please reach out to your networking team to provide them with this information.
We expect all customers’ connectivity issues to be resolved within the next 24 hours.

Haha ff allemaal vragen of je provider dns wilt flushen.
Ok het is wel de oplossing, maar beetje lastig voor hoop mensen.

[Snow_King]

Maar zo zit het nu wel. Slack kan de caches van resolvers niet legen, dit is het enige wat ze kunnen.

[JackBol]

Rondom een change in DNS hoor je gewoon de TTL van de RR laag te zetten.

Als alles stabiel is, kan je de TTL weer verhogen. Dat ze gebruikers moeten vragen om de provider caches te flushen is gewoon slecht change management rondom DNS.

[LanTao]

Rondom een change in DNS hoor je gewoon de TTL van de RR laag te zetten.

Het RR in kwestie stond in de com. zone en heeft een standaard TTL van 24 uur. Slack kan dat niet beïnvloeden.

Als alles stabiel is, kan je de TTL weer verhogen. Dat ze gebruikers moeten vragen om de provider caches te flushen is gewoon slecht change management rondom DNS.

Grotere bedrijven gebruiken DNS ook voor availability en houden de TTL dus zo laag mogelijk (20 tot 60 seconden). Ik heb vanavond twee verschillende IP-adressen gezien voor slack.com zelf, eentje in eu-central-1 en eentje in eu-central-2 van Amazon AWS.

Het DS record in de com. zone was wat er onterecht gecached werd en daar kon Slack niks zelf meer aan doen. Wat Slack wel had kunnen doen was alle DNSKEY / NSEC3 records terugzetten in hun eigen zone. Dat ze het niet gedaan hebben betekent mogelijk dat ze die data niet meer hadden, of andere zwaarwegende redenen hadden om het weg te laten en effectief alle ISP's met validating recursors aan te schrijven met het verzoek de caches te legen. De RCA/RFO wordt interessant, vermoed ik, ook omdat ze in hun eigen status.slack.com lange tijd niet leken te begrijpen waar precies het probleem lag, tot iemand op de OARC mailing list ze erop wees (en The Register ze via Twitter de link stuurde).

[zalazar]

Inderdaad. Maar het is waarschijnlijk beter om de TTL permanent laag in te stellen, bijvoorbeeld 5 minuten.
Dan hoef je er ook niet meer aan te denken.

[eMiz0r]

Heel slecht idee. Wanneer je de TTL naar 5 minuten zet en je hebt een storing aan de DNS dan ligt je site er ook na 5 minuten uit. Met name de laatste tijd zijn DDoS (achtige) aanvallen op nameservers populair dus dan speelt dit probleem al snel op.

TransIP heeft nav de recente aanval op haar eigen nameservers alle TTLs naar 24u gepushed en ik denk dat dat zeer verstandig beleid is. Een TTL van 5 minuten zou alleen tijdelijk handig zijn in het geval van werkzaamheden.

[MoonWatcher]

Klopt,

Maar DNS is eigenlijk altijd redundant uitgevoerd met meerdere nameservers op fysiek andere locaties. Meestal zijn dit er 2. Bij ons bedrijf gebruiken we er zelfs 3 omdat we onderliggend MariaDB/galera replicatie gebruiken. Deze nameservers bevinden zich in 3 verschillende landen.

Hiermee verdwijnen in de praktijk de meeste bezwaren tegen een lage TTL.

Voor het opzetten van een verbinding kan een hogere TTL wel een positief effect hebben op de snelheid bij de eerste aanroep.

[kristofv]

Dit lijkt me inderdaad wel heel amateuristisch voor een bedrijf als Slack. TTL veranderen is nog het minste .. deze change hadden ze ook gewoon in het weekend moeten uitvoeren.

[thomas1907]

Is het niet zo dat, omdat de TTL 'nu' hoog is de nieuwe lagere TTL ook pas over een tijd gezien wordt?

[robvh99]

Daarom doe je dat ook enige tijd voordat je de wijzigingen gaat uitvoeren

[thomas1907]

In dit geval dus "haha we krijgen zometeen storing, eff die TTL alvast omzetten"?

[robvh99]

Nee, stel dat je normale ttl 1 dag is en je bent van plan zaken aan te passen, dan zorg je dat meer dan 1 dag van te voren de ttl omlaag gaat naar bv 5 minuten....
Voor storingen gaat dat niet op, maar ja dit was het gevolg van een wijziging die ze uitgevoerd hadden.

[DDX]

Wel grappig trouwens dat je bij google wel zelf de cache kan legen ;
https://developers.google.com/speed/public-dns/cache

[Pascal]

1.1.1.1 kan dit trouwens ook voor de geïnteresseerden
https://1.1.1.1/purge-cache/

[Accretion]

Slack kan toch ook aan z'n users vragen bij welke providers het nog mis gaat en dan die providers opbellen om een DNS flush aan te vragen voor slack.com

Of aangeven welke DNS servers wel werken en hoe je dat instelt?

[Jay-v]

Meeste bedrijven zullen zelf een DNS resolver hosten dus dat heeft weinig zin. Misschien in de toekomst een lagere TTL configureren?

[Blizz]

DNS probleempje. Oepsie.

[svane]

Relevante Haiku

It's not DNS
There's no way it's DNS
It was DNS

[Blizz]

Haha, prachtig!

[colinthart]

Hmm, started not long after IdenTrust’s “DST Root CA X3” certificate expired, as publicised by Let's Encrypt.

[sfranken]

Hier had ook start.fedoraproject.org last van gisteren (donderdag). De wordpress feed werd niet geladen, want die komt van een andere website die hier ook last van had. Was gelukkig vrij snel opgelost.

[nicolaasjan]

Ik had daar last van met de SponsorBlock-API in yt-dlp (fork van youtube-dl):
https://github.com/ajayyy/SponsorBlock/issues/979

https://letsencrypt.org/d...xpiration-september-2021/

Na toevoegen van het nieuwe ISRG Root X1 certificaat werkte het weer.

[ITsEZ]

Hier nergens last van, lijkt dus niet alle gebruikers te treffen?

[tucker88]

We are aware of connectivity issues related to DNS that are impacting a small subset of users.

Klopt dus. Als jouw DNS de nieuwe records opgepikt heeft heb jij nergens last van.

[Sn0wblind]

Volgens mij gaat er meer mis, Slack is iffy, Youtube doet nu zijn ding niet, Linkedin laad niet in.

[krakendmodem]

Gebruik je T-mobile thuis? Die hebben momenteel ook een storing.

[Sn0wblind]

Dat was inderdaad het geval.

[divvid]

hier nog steeds ellende.

[Maulwurfje]

Mijn T-Mobile thuis (DSL) verbinding is momenteel ook enorm traag. Het instellen van een andere DNS lijkt niet te helpen.

[Blizz]

Ja ik denk dat T-Mobile ook wat stuk heeft gemaakt in een poging om Slack te helpen.

[Annihlator]

Heb je naast het instellen van een andere dns ook gepoogd het dns-cache te flushen? Soms vergeten mensen dat; dan kunnen oude gecachede dns requests roet in het eten gooien.

[Blizz]

Dat loste het bij mij niet op, inmiddels heeft T-Mobile er ook een topic voor.

[HereIsTom]

T-Mobile Thuis Glasvezel duurt het ook heel lang voordat deze pagina geladen is, 0.5 Mbps download en 100 Mbps upload.