DNS anbefalinger 2022
Dette indlæg er en lille opfølger på sidste blog indlæg om GratisDNS, og hvad jeg har gjort, og hvad jeg anbefaler du gør med DNS. Det er holdt i generelle vendinger, for der er mange forhold som gør sig gældende.
En ting er dog, at DNS ofte ikke er forstået godt nok og savner kærlighed i hverdagen. Jeg opdagede selv for nyligt et par domæner som var registreret med forkerte admin email adresser og var lidt mere bøvlede at få flyttet.
Du bør jævnligt checke dine domæner, checke din DNS opsætning, passe DNS! Specielt for virksomheder vil jeg mene, og det underbygges flere steder, at man på DNS niveau kan fjerne og eliminere mange trusler - før de rammer dybt ind i vores organisationer.
Det kan gøres med kommercielle services eller byg-selv, og vil efter min mening være en langt bedre investering end seneste hypede AI machine-learning logging 2000 software som en smart sælger oversælger med uvederhæftige løfter.
Dette indlæg dækker ikke alt, men er et spark over skinnebenet til at du skal sætte det på din ToDo-liste - for det ER vigtigt!
Gør det nu, smid det på ToDo-listen
Det officielle lydspor til dette indlæg er Blame it on the boogie, fordi alle hele tiden skyder skylden på DNS og netværk. Dans og DNS er også næsten de samme bogstaver, så DaNS derudaf!
https://www.youtube.com/watch?v=nqxVMLVe62U
https://open.spotify.com/track/0ryUadrXsahO3mASlKUJlT?si=0f42bc142c9847ef
Bonus track er: https://open.spotify.com/track/76jBriPAnOJzGBsrcZ0ihl?si=57e0ffe6b2e748b4
DNS hvad er det
Domain Name System er det vi fik, da hosts listerne voksede sig for store. Det var i starten muligt at have lister over alle systemer, men det skalerede ikke. Derfor har vi idag, siden 1985 et distribueret system med navne og IP adresser, og alt muligt andet.
Det primære er at vi vil slå et navn op, som mail.kramse.org eller www.kramse.org fordi vi vil sende post, eller besøge min fancy hjemmeside. Hele systemet har mange dele, og nedenstående vil primært koncentrere sig om rekursiv DNS i starten og derefter en smule autoritativ DNS.
Da vi ikke sidder i DNS working group på et RIPE møde vil nogle ord måske blive brugt en smule løsere, så DNS eksperter behøver ikke være nitpicking i nedenstående.
Læs mere på: https://en.wikipedia.org/wiki/Domain_Name_System eller hvis du gerne vil vide mere om core protokoller som bruges på internet, køb bogen: Practical Packet Analysis, 3rd Edition Using Wireshark to Solve Real-World Network Problems af Chris Sanders https://nostarch.com/packetanalysis3
Jeg bruger den selv på mine kurser, eksempelvis REKLAME: Vi starter faktisk kurset Netværk og Kommunikationssikkerhed hos KEA 19/4, hybrid undervisning!
Du kan også finde alle slides gratis, samt 2021 lektionsplanen via links
https://zencurity.gitbook.io/kea-it-sikkerhed/net-og-komm-sikkerhed/lektionsplan
https://github.com/kramse/security-courses/tree/master/courses/networking/communication-and-network-security
Anbefalinger til private
Overvej at vælge en DNS service fremfor en tilfældig som din ISP har valgt.
DNS er kritisk for god oplevelse på internet, og der kan gøres meget for at sikre dig selv. Sikre dig selv er lidt løst, for er det mod overvågning eller malware, to forskellige ting.
Hvis du primært er interesseret i at undgå overvågning vil jeg anbefale
Uncensoreddns.org / CensurFriDNS
Bemærk at cleartext lookups slåes fra senere på året! Læs:
https://blog.uncensoreddns.org/blog/39-the-unfriendly-internet-turning-off-cleartext-lookups-in-september/
Hvis du som privatperson blot er interesseret i at undgå malware, så vil jeg anbefale at kigge på eksempelvis Quad-9 eller Cloudflare DNS. Begge betyder at hvis du/eller din familie får malware, phishing osv. så vil du i højere grad undgå at de virker og aktiverer. Der kan ikke hentes malware, hvis DNS for malwaredomænet ikke virker, fordi DNS ikke svarer med den "rigtige IP".
quad9 https://www.quad9.net/ - bruger opdaterede lister for at undgå malware domæner. Ligger under Schweizisk jurisdiktion
Cloudflare DNS for families
https://blog.cloudflare.com/introducing-1-1-1-1-for-families/
Der findes andre alternativer, og som altid fraskriver jeg mig ethvert ansvar -- du må selv vurdere hvad løsninger du vælger.
Se også byg-selv nedenfor.
Anbefalinger til firmaer
Hvis du har et firma af en vis størrelse, vurderet på antal ansatte, vil jeg anbefale at du overvejer nogle ekstra skridt.
De ekstra skridt jeg anbefaler er en højere grad af logning. Det er nemt på en vilkårlig recursive DNS server, Unbound YAY!, at lave query log. Det vil gøre det muligt at bekræfte OM der er lavet opslag til malwarexys.tld domæne, og hvis man har sin DHCP log hvilke systemer der er ramt af en malware.
Without saying, det siger sig selv at det skal ske med respekt for de ansattes privatliv, gæster osv.
TL;DR Lav en politik på området, informer om hvorfor I gerne vil logge, fortæl statistik på hvor godt det virker, lad være med at logge gæster - herunder studerende på undervisningssteder.
Jeg har nogle tanker omkring enterprise brug af Unbound, så lover jeg senere skriver mere uddybende omkring dette emne.
Byg selv løsninger
Personligt er jeg jo mere byg selv løsningen, så en kombination af Pi-hole og blokeringslisterne fra Maltrail vil nok være min løsning.
Pi-hole er en turn-key løsning til DNS, med statistik dashboard, nem konfiguration og ad-blocking. Dette kan udvides til blokering med andre lister, nemt og hurtigt. Random link med beskrivelse: https://obutterbach.medium.com/unlock-the-full-potential-of-pihole-e795342e0e36
Der er også mulighed for samarbejde med andre, omkring eksempelvis DNS via CrowdSec https://crowdsec.net/ hvor min ven Klaus Agnoletti arbejder.
NB: uanset navnet kan Pi-hole softwaren bruges på andre systemer end kun Raspberry Pi.
DNS root servers
Nå, men ovenstående er sådan set bare indledningen til emnet for idag. Autoritativ DNS for mine domæner privat og firma. Jeg har et lille firma Zencurity Aps og jeg er jo nørd. Det betyder at jeg har/havde i omegnen af 50 domæner for mig selv, for andre, til projekter, til gamle projekter osv.
Alle disse domæner skal jo kunne slåes op, og det foregår altsammen med udgangspunkt i root DNS. Det er 13 IP adresser som har været faste i MANGE ÅR, så mange år at det bliver svært og dumt hvis de forsvinder. Heldigvis bliver disse annonceret på internet omkring 1.500 steder af 12 oganisationer, se https://root-servers.org/ for mere information. Der er god redundans.
Generelt når man har en IP-adresse betegner det et interface på een enhed. Der er dog mange tilfælde hvor man kan lave ting som failover, en adresse kan dynamisk skifte mellem eksempelvis to routere, se Virtual Router Redundancy Protocol (VRRP) og Common Address Redundancy Protocol (CARP) . Der kan også annonceres med Border Gateway Protocol (BGP) https://en.wikipedia.org/wiki/Border_Gateway_Protocol samme netværk flere steder.
Denne model bruges blandt andet af root DNS servere, det samme /24 prefix annonceres flere steder. Princippet kaldes Anycast . Så ICANN som bestyrer L-root annoncerer 199.7.83.0/24 og bruger så IPv4 199.7.83.42. Tilsvarende på IPv6 annonceres 2001:500:9f::/48 og bruger service adressen: IPv6 2001:500:9f::42
$ host l.root-servers.net l.root-servers.net has address 199.7.83.42 l.root-servers.net has IPv6 address 2001:500:9f::42
Fra mit datacenter ender jeg eksempelvis via Global Connect til "Jay Net" - nu sentia, og så L-root.
$ traceroute l.root-servers.net traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets ... 6 94.101.208.52 (94.101.208.52) 3.737 ms 4.620 ms 4.571 ms 7 94-101-208-53.taas11ar2dk.gc-net.eu (94.101.208.53) 3.857 ms 3.814 ms 3.772 ms 8 ae6-0.alb2nqe10.dk.ip.tdc.net (83.88.4.191) 6.564 ms 6.696 ms 6.657 ms 9 cpe.xe-3-0-0-594.alb2nqe10.dk.customer.tdc.net (195.215.109.158) 7.074 ms 7.107 ms 7.048 ms 10 te0-0-0-3.core.asr-1.glo.jay.net (86.58.227.98) 7.527 ms te0-0-0-4.core.asr-2.glo.jay.net (86.58.227.41) 7.232 ms 7.262 ms 11 86.58.227.86 (86.58.227.86) 7.636 ms te0-1.metro-1.intx.jay.net (86.58.227.222) 7.666 ms 86.58.227.86 (86.58.227.86) 7.529 ms 12 86.48.111.94 (86.48.111.94) 4.483 ms 4.478 ms 86.48.111.90 (86.48.111.90) 4.413 ms 13 94.126.176.29 (94.126.176.29) 4.377 ms 4.381 ms 20.220 ms 14 l.root-servers.net (199.7.83.42) 4.461 ms 4.412 ms 4.384 ms
Potentielt er det den server jeg selv var med til at skrue op og overdrage administrationen til ICANN på.
Hjemmefra går jeg en anden vej via NL-IX
$ traceroute l.root-servers.net traceroute to l.root-servers.net (199.7.83.42), 64 hops max, 40 byte packets 1 customer-....ip4.gigabit.dk (212.237....) 4.222 ms 3.989 ms 4.021 ms 2 nl-ix.ip-max.net (193.239.118.22) 26.571 ms 27.957 ms 28.088 ms 3 te0-1-0-2.er01.lil02.ip-max.net (46.20.254.21) 39.119 ms 37.096 ms 35.778 ms 4 be4.er01.lil01.ip-max.net (46.20.254.16) 36.294 ms 36.174 ms 39.3 ms 5 te0-1-0-1.er02.par02.ip-max.net (46.20.254.203) 35.785 ms 36.071 ms 35.911 ms 6 te0-0-2-0.er01.lyo01.ip-max.net (46.20.254.132) 37.167 ms 35.708 ms 35.847 ms 7 te0-0-0-1.er01.gva02.ip-max.net (46.20.254.128) 36.332 ms 36.337 ms 36.004 ms 8 l.root-servers.net (199.7.83.42) 35.613 ms 35.539 ms 35.964 ms
Faktisk ser det lidt ringe ud. BGP sikrer korteste vej, AS-path med modifikationer. Der burde være bedre routing end at jeg skal omkring par lyo gva, Paris-Lyon-Geneva?
Vi kan undersøge hvilken instance vi snakker med via forskellige mekanismer, se A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes
https://tools.ietf.org/search/rfc7108
Fra datacenter og hjemmefra
$ dig -4 @L.ROOT-SERVERS.NET . SOA +nsid | grep NSID ; NSID: 64 6b 2d 63 70 68 2d 61 61 ("dk-cph-aa") $ dig -4 @L.ROOT-SERVERS.NET . SOA +nsid | grep NSID ; NSID: 63 68 2d 6d 6f 74 2d 61 61 ("ch-mot-aa")
Dette er ikke en fuld analyse af Wizer/Gigabit, og min server hjemme vil cache informationen længe, så no problem. Generelt er DNS en tilgivende service, der er caching som man selv styrer. Det kan dog give bøvl, hvis man ændre - fordi det netop er cachet.
Hvis du gerne vil lege mere med det, så led efter BGP looking glass eller brug RIPEstat https://stat.ripe.net/
Mine domæner
Næste niveau er eksempelvis kramse.org eller kramse.dk. Disse er på .org som er et af de gamle klassiske top level domains (TLD) henholdsvist det nye(ere) .dk Country Code TLD (ccTLD). Begge disse bestyres af organisationer med fokus på driftstabilitet. Det betyder at der er et antal DNS servere, på både IPv6 og IPv4, formentlig annonceret flere steder.
De indeholder information om et enkelt TLD, så hvis vi bruger DK, og dermed DK-hostmaster ved deres servere ALT om domæner der ender med .dk. Mit kramse.dk er således registreret hos dem, og deres funktion er at pege på de autoritative servere for kramse.dk
Det er i dagens blog indlæg kun de to navne her:
$ host -t ns kramse.dk kramse.dk name server ns01.zencurity.com. kramse.dk name server ns02.zencurity.com.
Så for at finde et navn www.kramse.dk skal vi spørge en af disse. En vilkårlig af disse kan hurtigt svare at:
$ host www.kramse.dk www.kramse.dk has address 185.129.60.130 www.kramse.dk has IPv6 address 2a06:d380:0:101::80
og vi er i mål.
Hele processen blev undervejs afbrudt og gentaget for .com, zencurity.com og ns1.zencurity.com. Heldigvis er der en del caching i DNS, så når der kommer et opslag for .com har man ofte cachet hvilke servere der skal spørges om dette TLD.
Af ovenstående kan også udledes at jeg fra at have mine domæner hos GratisDNS nu er skiftet til egen DNS infrastruktur. Det er som sådan ikke af lyst, men af nød. Der blev annonceret skifte til one.com sådan med kort varsel, ihvertfald før jeg opdagede det. Dernæst ville jeg helst have meget kontrol med mine data. Der var derfor ikke mange alternativer som jeg brød mig om.
Min tanke var også at jeg med tiden kunne tilbyde mine servere som sekundære for andre, og bytte-bytte købmand få lov til at bruge nogle andres servere som mine sekundære. Jeg ville helst ende med 3-4 servere på mindst 2-3 forskellige subnets, og forskellige netværksoperatører - dermed forskellige ASN .
Pt er mine to servere i hver deres /24 og det er minimum, og faktisk gider jeg ikke diskutere det. Det er SÅ nemt at smide to servere på hvert sit subnet, så gør det nu fucking bare allesammen. Hvis du IKKE gør det skal du HVER eneste gang forklare mig at du HAR designet systemet med anycast. Du skal også forklare mig at det altid virker. Comply or explain
Jeg fik også i samme ombæring opsagt nogle domæner, opdateret kontaktinformation på andre. Så helt skidt var det ikke.
Hvis man slår mine servere op, eller mine domæner på eksempelvis https://internet.nl/ får jeg desværre ikke 100% som jeg plejede på Zencurity.com domænet, men det bliver der arbejdet på.
Hvorfor gik du ikke bare med til one.com
En af mine anker imod one.com er nemlig at de kører deres DNS ud fra eeeeet ASN. Så hvis de fucker, eller andre fucker, eller noget fucker som påvirker DET ASN, så er deres DNS servere fucked, og dermed deres kunders DNS.
Til dem som ikke husker så langt tilbage var der et grimt nedbrud med Facebook relateret til BGP og DNS. Læs eksempelvis den fine gennemgang hos Cloudflare eller hos version2 Facebook problemer med DNS . Så ja one.com har både flinke, søde, rare, venlige ansatte som er kompetente, coladrikkende, troværdige - fortsæt selv. Det er dog ingen garanti for at der ikke en dag sker noget med det ENE prefix
195.206.121.0/24 som annonceres af AS51468 ikke bliver fucked.
$ host -t ns one.com one.com name server a.b-one-dns.net. one.com name server b.b-one-dns.net. $ host a.b-one-dns.net a.b-one-dns.net has address 195.206.121.11 a.b-one-dns.net has IPv6 address 2001:67c:28cc::11 $ host b.b-one-dns.net b.b-one-dns.net has address 195.206.121.139 b.b-one-dns.net has IPv6 address 2001:67c:28cc::139
Altså det virker underligt, men You do you, honey!
Mine servere
Til slut, hvis du stadig gider læse om DNS og mine erfaringer, så er her en kort gennemgang af mit setup.
Først og fremmest skulle jeg vælge DNS server software, autoriativ server. Den gamle BIND har jeg personligt lagt i graven, den var god og jeg brugte den for +20 år siden. De nyere alternativer indenfor Open Source som jeg sådan overvejede inkluderer PowerDNS fra Hubert, NSD fra RIPE, Knot DNS fra CZ.NIC.
Det blev dog en relativt kort process, da jeg elsker NLnet Labs og NSD følger med i OpenBSD. Det betyder at softwaren opdateres sammen med operativsystemet, ikke engang som en pakke men integreret. Dokumentationen for NSD ligner til forveksling den fra Unbound - og organisationen bagved er en jeg til fullde kan støtte og glædes over.
Jeg kunne derfor oprette et par nye Ansible filer, herunder Jinja templaetes til domæner der deler information, og så oprette et antal VMer til at administrere og servicere DNS.
Det endte med en hidden primary, ns00.zencurity.com som jeg kan logge på via SSH, og dermed Ansible og Python. Denne får opdateret zonerne som filer og NSD skulle blot startes på normal vis som andre OpenBSD daemoner
ns00$ cat /etc/rc.conf.local nsd_flags=
med config via Ansible og tilsvarende zoner filer:
- name: Create name server NSD conf template: src=roles/infrastructure-dns/{{ inventory_hostname_short }}/nsd.conf dest=/var/nsd/etc/nsd.conf owner=root group=_nsd mode=0640 notify: - restart nsd - name: Update primary zone files template: src=roles/infrastructure-dns/{{ inventory_hostname_short }}/zones/primary/{{ item | basename }} dest=/var/nsd/zones/primary/{{ item | basename }} owner=root group=_nsd mode=0644 with_fileglob: - roles/infrastructure-dns/{{ inventory_hostname_short }}/zones/primary/*
Disse fik jeg hevet ud fra GratisDNS med eksport funktion, tak Peter. Så med meget få ændringer var den første VM oppe.
De næste to, som er dem offentligheden ser, er endnu simplere, da disse trækker informationerne fra den primære. De er ligeledes konfigureret via Ansible, så det vil være simpelt at udvide med flere. Keep it simple.
En lille kommentar. Den første ns01 kunne sådan set godt agere primær server, men i det tilfælde at nogen ville synes det var sjovt at DDoS'e mit netværk og mine domæner vil det efter min mening være nemmere at smide et antal nye op og pege på den hidden primary jeg allerede kører.
BTW mit netværk er ikke så forretningskritisk at jeg ikke kan arbejde hvis DNS, Mail eller Web er nede. Det vil blot give en pause i indbakken :-D
Så kort og godt, DNS er noget alle burde se mere på. Der er mange faldgruber og der er nogle valg man skal foretage. Så tag nogle valg, dokumenter det.
Kom gerne med jeres foretrukne alternativer, eller input til forbedring af mit setup.
PS DNSSEC
De skarpe blandt publikum, eller dem som checkede med internet.nl vil bemærke at jeg ikke har slået DNSSEC til endnu .
Det er helt rigtigt, idet jeg ville sikre at rate-limit er aktiveret! Uden rate-limit kan man risikere et misbrug af ens server, der sendes queries med forfalsket afsender og min server vil svare med et større svar. Det kaldes reflection attacks og en beskrivelse af netop DNSSEC kan findes i artiklen DNSSEC and Its Potential for DDoS Attacks
https://conferences2.sigcomm.org/imc/2014/papers/p449.pdf første forfatter er også på Twitter som @reseauxsansfil
Så, før jeg liiige slår det til skal jeg se mere på NSD rate-limit. Det er indbygget, men jeg vil gerne tune det lidt. Til det vil jeg også gerne have lidt statistik først med hvor mange opslag der normalt er. Det må altså vente til måske BornHack eller lignende.
PS Addendum registrar
Jeg har oprettet egne servere som beskrevet ovenfor, men alle domænerne er flyttet til Joker.com. Det er dem som GratisDNS brugte i forvejen, så det var relativt nemt at vælge. De fungerer rigtig fint synes jeg. Jeg er også blevet reseller så næste gang kan jeg vel sælge domæner til mig selv. :-)

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