Hos Kviknet har vi de sidste dage modtaget mange klager over manglende adgang til borger.dk, jobnet.dk og en række andre offentlige websites, så vi satte os for at undersøge, hvad der var galt.
Vi har for nylig aktiveret DNSSEC på vores DNS recursors, og vi ser i vores logs, at en lang række DNS-opslag fejler, bl.a. til følgende domæner:
og ironisk nok:
Hvad er fællesnævneren for alle disse domæner?
whois ufm.dk whois udbud.dk whois borger.dk
De anvender samme DNS-servere:
Registrant Handle: N/A Name: Statens It Address: Lautruphøj 2 Postalcode: 2750 City: Ballerup Country: DK Nameservers Hostname: ns2.sitnet.dk Hostname: ns3.sitnet.dk
Aha.
I loggen på vores DNS recursor ser vi de fejlede opslag:
Dec 3 10:45:00 dns1 pdns_recursor[10177]: Answer to jobnet.dk|A for <client IP:source port> validates as Bogus
Et opslag mod vores DNS recursor viser ganske rigtigt, at klienten ikke får svar:
$ dig @185.107.12.83 jobnet.dk ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> @185.107.12.83 jobnet.dk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, <strong>status: SERVFAIL</strong>, id: 62051 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;jobnet.dk. IN A ;; Query time: 3018 msec ;; SERVER: 185.107.12.83#53(185.107.12.83) ;; WHEN: Thu Dec 03 10:45:00 CET 2020 ;; MSG SIZE rcvd: 38
Vi anvender PowerDNS som recursor, og i konfigurationen har vi valgt den sikreste DNSSEC-opsætning:
################################# # dnssec DNSSEC mode: off/process-no-validate (default)/process/log-fail/validate # # dnssec=process-no-validate dnssec=validate ################################# # dnssec-log-bogus Log DNSSEC bogus validations # # dnssec-log-bogus=no dnssec-log-bogus=yes
Vi prøver for sjovs skyld at slå DNSSEC fra for at se, om det gør en forskel. Det gør det:
$ dig @185.107.12.83 jobnet.dk ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> @185.107.12.83 jobnet.dk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53735 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;jobnet.dk. IN A ;; ANSWER SECTION: jobnet.dk. 3600 IN A 131.165.97.177 ;; Query time: 12 msec ;; SERVER: 185.107.12.83#53(185.107.12.83) ;; WHEN: Thu Dec 03 10:55:42 CET 2020 ;; MSG SIZE rcvd: 54
Godt så. Er det hos os eller hos Statens IT, den er gal?
Vi starter med at spørge sikkerpånettet.dk:
Glem advarslerne om IPv6 og HTTPS - lige nu er det DNSSEC, vi interesserer os for, og her ser alt ud til at være i skønneste orden:
Et statsligt website siger, at en anden statslig service fungerer helt OK. Vi må hellere få en second opinion, så vi spørger Verisign Labs:
Av - det var ikke godt. Kan det virkelig passe, at ns2.sitnet.dk og ns3.sitnet.dk ikke svarer, når der bliver spurgt på en DNS key? Måske kan vi få lidt mere information fra dnsviz.net:
Holder vi musen hen over udråbstegnene, får vi endelig forklaringen:
No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size.
Aha! Så her har vi forklaringen: Når man spørger på en DNS key for jobnet.dk, kommer der ikke noget svar, medmindre klienten specifikt beder om at få små UDP-pakker.
Vi kan teste dette direkte fra en Linux-maskine:
$ dig DNSKEY @188.64.157.26 jobnet.dk +dnssec ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> DNSKEY @188.64.157.26 jobnet.dk +dnssec ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
Hvis vi kigger på DNS-forespørgslen i Wireshark, kan vi se, at dig-klienten by default foreslår 4096 som UDP payload size:
Hvis vi beder om at få pakker på 1500 bytes, får vi et svar fra ns2.sitnet.dk:
$ dig DNSKEY @188.64.157.26 jobnet.dk +dnssec +bufsize=1500 ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> DNSKEY @188.64.157.26 jobnet.dk +dnssec +bufsize=1500 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7180 ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;jobnet.dk. IN DNSKEY ;; ANSWER SECTION: jobnet.dk. 172800 IN DNSKEY 256 3 5 AwEAAdUErdhvUJu+iFZnBwkmVHEGiVWQM59ciHzfW2CR1rYD+MZFWJtQ t/bcLhNP9l4B3046wEyROZKHRTcscDCQ8O5eJywwlkhq5D5tfaqDjMMA /oO+k+wvazKC904of4xjR6cIizJ93jhK4bgtikTq0QwaBH6A+g7iOVy3 5PuJQWyt jobnet.dk. 172800 IN DNSKEY 257 3 5 AwEAAdZjPvQwEgLkqHHi09p2g7L84Al1KXWGLD9ITr63NNMbAyT2bK2Y ZEoJwMX/qmNMmOPMjuiZfATS3WPPGkd+/2vYOkJ2VZJMu17MHVwQStt9 F/gcwzmsnEfypeihS3zzQTHW8Tkw/hb7dWE2r/L8pp+w94lovPcbQfhy Jcd507Xbu/Y3EIeo6Vq5us/LJz4MR1BKpukx4SDz77y11Ep+Tjwkp2T3 +ghilB7YMegdXdu1DOl2Vb+OZbiKDfw+I3EJjuHZF5kxe5fgE7X5rAfg 2fXHmYYam7UxGFEPfyhh8B5LOqzKZR+QzsTvC+N7SgyYewJsLY4h2/cW W1vbI95MzwU= jobnet.dk. 172800 IN DNSKEY 257 3 5 AwEAAb4oCH9CT4do1QnpaKHTxHBxkpTwb01uEV1mpiKhj+x2wcS1SqLD YqT3g0JIQcHGj9N9Fq1ZBcAuVP8BKdRF/AHhcX6QW9hBm4brnEnxPqkB yASBtkY0cZYgMiFsnSGwxc2+m5KJ1zz1UA+wz3cw8q4ayWDXgki0KYdF caf3sb0piIEwqJYmP96YdDMkctJxcQ9jOxZm57E5UPbjTBQGdV362WNt XWNzuWsbXiZfFEx6UDHP4VQL+tzQwPIybsSn+QMQ1nVkwfICI36L/9/4 QBco96CsctgKVbzCQgYXGNi9X9nvAQRE/UrY32pLRC6z/ju/wdybsn5v OB5DTAZ4aOM= jobnet.dk. 172800 IN RRSIG DNSKEY 5 2 172800 20201207044706 20201203034917 24586 jobnet.dk. qiy5/MF1+iNgmoTjaE0cgZ527j3hXOdX0StNIeXWIxX2MgOAgIZVCJyM Kq9v2xr1iD7MSPEARGRoE1/+g07Xu1NwMTEoWwFE9nT1GBd9WoLmpwGE YSNGE1vVF97WXkIcJpX6mIgMt2Vir+eMQmhTV3SU14jTT1KLb5QXgoLO CgnBAjqVcW//vqlMti518aUbC4bJNEtKtPeKNPrBJxa2qNAC1XrrHhXO pkITMKPyNi4WSokEjnQX3ycfZxaUEcvtwRzkLtjVHqNieegNewFXsRVI j6aTel+aOEJfKXzdV99MWtI/JFchhGg30XU+xEA/tVDZC9l1K/aHM/1P TY/vBA== jobnet.dk. 172800 IN RRSIG DNSKEY 5 2 172800 20201207044706 20201203034917 28768 jobnet.dk. T9Qf5BM05RB8tD7ZkjZlmCafnO7kJ04cn9Z7g+qXuW68rrmmpOmUS3Ry 35/DRGhz9HQNZ4ECF2qbECyyxn2Zuj3ItQzYhLKZ5IVni32BkbRfCuQE uxgegHDUmNLS/I0MZnzJ0JT6HI6zdhDa/n3PFmY0LoqcX2MWNyPYoDKE j5L0DZSMaAXTy217aL/O2CA8WvQ6/VBfi9gf089yEdK+spOta57z5ypa oK4i5MQjFd75jyALo1u8SmOOzi8NAjoIQad0cFs16SB82mcXd98uqjzo 9zbPtlfGgV2eJ1qrUslunV3vxmg2TCqg3sRXY9Ii3r2WBYmf5nOyysoY Bcq2NA== jobnet.dk. 172800 IN RRSIG DNSKEY 5 2 172800 20201207044706 20201203034917 15738 jobnet.dk. pDp+ccSY1XzFqXfKNRppbm9DT7jSrABNH8KcZMcOUxdnMOiFxhkMifpU ghVZxYwRYDBphDJ8XqIiBrjimKEWB71crQue3dHIB3jufWVNg3IM8tGs I7xH6FWsGdSru0Uo9UeHpekzJr4lxdQUuRJry2sEMKPIJmnKqrVNLUb0 CmQ= ;; Query time: 9 msec ;; SERVER: 188.64.157.26#53(188.64.157.26) ;; WHEN: Thu Dec 03 16:29:34 CET 2020 ;; MSG SIZE rcvd: 1501
Så det ser altså ud som om, der muligvis sidder en firewall eller lignende hos Statens IT, der blokerer for DNS-svar med mere end 1500 bytes i payload.
Det er noget rod, men kan vi løse problemet midlertidigt i vores ende?
Muligvis - i vores version af PowerDNS recursor er payload size på udgående forespørgsler sat til 1680 bytes by default:
Senere versioner af PowerDNS recursor anvender 1232 bytes som default, så det ændrer vi vores setting til:
$ dig @185.107.12.83 jobnet.dk ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> @185.107.12.83 jobnet.dk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4615 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;jobnet.dk. IN A ;; ANSWER SECTION: jobnet.dk. 3600 IN A 131.165.97.177 ;; Query time: 21 msec ;; SERVER: 185.107.12.83#53(185.107.12.83) ;; WHEN: Thu Dec 03 16:42:11 CET 2020 ;; MSG SIZE rcvd: 54
Så virker det!
Vi har kontaktet Statens IT og bedt dem om at se på sagen, men det ser ikke ud som om, det har fået den store bevågenhed endnu.
Hvis der er en venlig sjæl derude, som kan prikke til de rette folk hos Statens IT, ville det være værdsat.
Og nu vi er i gang med de venlige sjæle, kunne nogen måske tage fat i folkene bag coronaprøver.dk og fortælle dem, at deres DNS-servere er out of sync - og derfor fejler DNSSEC-opslag i ca. halvdelen af tilfældene:
Henrik Kramselund Jereminsen har i øvrigt helt ret: Lad nu være med at opfinde alle mulige mærkelige single-use-domæner til det offentlige - der sker alt for mange fejl, og det er komplet umuligt for den enkelte borger at gennemskue, om domænenavnet er legit eller ej.
Evt link også folk til https://dnsflagday.net/2020/ og man kan selv teste en del med https://www.dns-oarc.net/ eksempelvis deres reply-size-tester
Det er en fejl at have to autoritative navneservere ved siden af hinanden, på den måde. Det er simpelthen for nemt at lave DDoS.
Det med payload size hos dnsviz har jeg også godt bemærket et par gange, men ikke fået undersøgt nærmere - nu slipper jeg så for det, så tak for indlægget :-)
Det er som at slå i en dyne at prøve at få myndighedernes opmærksomhed. Heldigvis giver vi ikke op så let :-)
De mangler da også nogle IPv6-adresser på dem?
Rolig nu... Det er jo DK. Sammensværgelsen mellem de store ISP'ere om ikke at investere i IPv6 for at spare, har jo sikret at danske offentlige webservices ikke behøves bekymre sig om den salgs detaljer :-(
Det er dybt tragisk at leve i et moderne digitaliseret samfund, som samtidigt pga. nogle store ISP'ere berøver sin befolkning almindelig generel anvendt viden om det Internettet bliver mere og mere afhgængig af. Hvis man arbejder med IT og forstår behovet og hvor resten er verdenen er på vej hen - så må man skifte til Kviknet eller en af de andre få udbydere der kan se det større billede.
Hvis man bor et sted, hvor eneste udbydere er Yousee (coax) eller Fibia (fiber), er IPv6 desværre ikke en mulighed.
Hvis man bor et sted, hvor eneste udbydere er Yousee (coax) eller Fibia (fiber), er IPv6 desværre ikke en mulighed.
Ikke endnu, men det kommer.
Kviknet har indgået en aftale med Fibia og kan efter planen levere internet på Fibias net i løbet af 2021, og der var gode nyheder fra TDC Net på det seneste branchemøde for få dage siden: Man vil alligevel tilbyde layer 2-adgang på coax-nettet, hvilket gør det muligt for operatørerne at levere IPv6 til kunderne.
Så 2021 bliver muligvis året, hvor IPv6 bliver alment tilgængeligt i DK :)
De danske myndigheder kunne kaste et blik over på den anden side af Øresund med at få rullet IPv6 ud.
Synes det er en super overskuelig side der er på https://www.pts.se/ipv6 med cases som kan vise at nej, det er ikke dyrt at indføre.
Kunne man ikke opfordre myndighederne til lade sig inspirere af Norges" Forskrift om endringer i forskrift 5. april 2013 nr. 959 om IT-standarder i offentlig forvaltning", §11?
§ 11. Obligatoriske grunnleggende nettverksstandarder Offentlige virksomheter skal sette krav til støtte av både IPv4 og IPv6 i alt nytt nettverksutstyr og all IP-avhengig programvare som anskaffes.
Offentlige virksomheter skal gjøre alle nye og eksisterende, eksternt publiserte tjenester tilgjengelig både på IPv4 og IPv6, med unntak av peer to peer kommunikasjon mellom offentlige virksomheter, der man kan legge om på best egnet tidspunkt.
Alle interne klienter i offentlige virksomheter skal ha tilsvarende tilgang til eksterne tjenester publisert på IPv4 og IPv6.
Nye interne nett og løsninger i offentlige virksomheter skal ha støtte for IPv6. Det er tillatt å støtte IPv4 i tillegg.
Kære Yoel
Tak for din hjælp. Vi er på sagen!
MVH
Michael
Statens It
PS: Vi har IPv6 på programmet
En ting, der går igen i vores fejllog, er entries i stil med følgende:
Dec 4 11:09:23 dns1 pdns_recursor[17018]: Answer to _hbbtv-ait._tcp.hbbtvopapps.org|SRV for validates as Bogus
Lidt Google-søgning leder mig til følgende dokument:
https://www.hbbtv.org/wp-content/uploads/2017/12/HbbTV-SPEC-00127-046-Op...
Sektion 6.1.3.7: DNS SRV lookup to a standardised address
This mechanism is intended for use only within an operator’s IP network and would likely not work in the open internet. This FQDN is deliberately different from that used in ETSI TS 103 464 [i.1] which will be used by broadcasters in the open internet. Use of custom DNS servers by either a terminal or a router will likely result in the failure of this mechanism. This mechanism should only be relied upon in deployments where this failure won’t happen.
Er der nogen derude, der kan gennemskue hvad årsagen er - er der en TV-app et eller andet sted, der støjer?
Jeg skal gøre mit bedste!
Det er jeg glad for at høre, jeg glæder mig allerede til at høre mere!
Der i løbet af 2020 kommet en del nyheder ud via pressemeddelser via Ritzau fra diverse udbydere omkring open access adgang for andre udbydere synes jeg at have set i mine RSS nyhedsfeeds. Aftalerne er godt på vej sådan rundt omkring i den danske telebranche. 👍
Vi har IPv6 på programmet
Fandme dejligt at høre det det offentlige it danmark arbejder på sagen.
Er det noget soft-target (e.g. 2022-2023) for opgaven du kan tillade dig at kommentere på?
Tak for din hjælp. Vi er på sagen!
Kære Michael, er der noget nyt?
Så vidt jeg kan se, kan det stadig ikke lade sig gøre at lave opslag med buffer > 1500 bytes:
$ dig DNSKEY @188.64.157.26 jobnet.dk +short +dnssec +bufsize=1501 ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> DNSKEY @188.64.157.26 jobnet.dk +short +dnssec +bufsize=1501 ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
Er der nogen derude, der kan gennemskue hvad årsagen er - er der en TV-app et eller andet sted, der støjer?
Er HbbTV ikke det DR bruger til deres DRTV-overlay-halløj når man ser en DR kanal på en smarttv?
Hej Yoel Vi har her til aften lagt en softwarerettelse på vores firewall-miljø, som iflg. leverandøren skulle løse problemet. Vores egne tests her til aften bekræfter dette.
Som jeg forstår problemet skaber store pakker, overløb på en kø i softwaren.
Hvis du vil vide mere, så ping mig pr mail på moe@statens-it.dk
MVH Michael
Vi har her til aften lagt en softwarerettelse på vores firewall-miljø, som iflg. leverandøren skulle løse problemet. Vores egne tests her til aften bekræfter dette.
Som jeg forstår problemet skaber store pakker, overløb på en kø i softwaren.
Tak for tilbagemeldingen - det ser ud som om opslag med store pakker virker nu.
Til en anden gang - hvordan kan man som ekstern aktør komme i kontakt med jer omkring fejl i jeres systemer?
Hej
Man kan ringe til vores hovednummer på 72310001, som er bemandet 24/7.
MVH
Michael
