yoel caspersen blog bloghoved

Case study: DNSSEC-fejl hos Statens IT?

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:

  • ufm.dk
  • udbud.dk
  • borger.dk
  • jobnet.dk
  • mst.dk
  • klimatilpasning.dk
  • ens.dk
  • star.dk

og ironisk nok:

  • adgangforalle.dk

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:

Illustration: Yoel Caspersen

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:

Illustration: Yoel Caspersen

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:

Illustration: Yoel Caspersen

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:

Illustration: Yoel Caspersen

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:

Illustration: Yoel Caspersen

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:

Illustration: Yoel Caspersen

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:

Illustration: Yoel Caspersen

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.

Relateret indhold

Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Uffe R. B. Andersen

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 :-)

  • 3
  • 0
#4 Tue Madsen

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.

  • 4
  • 0
#6 Yoel Caspersen Blogger

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 :)

  • 24
  • 0
#8 Lars Christensen

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.

  • 6
  • 0
#10 Yoel Caspersen Blogger

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?

  • 1
  • 0
#14 Chriztoffer Hansen

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. 👍

  • 0
  • 0
#16 Yoel Caspersen Blogger

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
  • 1
  • 0
#18 Michael Ørnø

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

  • 4
  • 0
#20 Yoel Caspersen Blogger

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?

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