Dette indlæg er alene udtryk for skribentens egen holdning.

DNS anbefalinger 2022

23. marts 2022 kl. 15:365
DNS er vigtigt. Du skal vælge DNS og ikke bare lade det være tilfældigt.
Artiklen er ældre end 30 dage

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.

Artiklen fortsætter efter annoncen

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

Artiklen fortsætter efter annoncen

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

  1. $ host l.root-servers.net
  2. l.root-servers.net has address 199.7.83.42
  3. 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.

  1. $ traceroute l.root-servers.net
  2. traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets
  3. ...
  4. 6 94.101.208.52 (94.101.208.52) 3.737 ms 4.620 ms 4.571 ms
  5. 7 94-101-208-53.taas11ar2dk.gc-net.eu (94.101.208.53) 3.857 ms 3.814 ms 3.772 ms
  6. 8 ae6-0.alb2nqe10.dk.ip.tdc.net (83.88.4.191) 6.564 ms 6.696 ms 6.657 ms
  7. 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
  8. 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
  9. 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
  10. 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
  11. 13 94.126.176.29 (94.126.176.29) 4.377 ms 4.381 ms 20.220 ms
  12. 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

  1. $ traceroute l.root-servers.net
  2. traceroute to l.root-servers.net (199.7.83.42), 64 hops max, 40 byte packets
  3. 1 customer-....ip4.gigabit.dk (212.237....) 4.222 ms 3.989 ms 4.021 ms
  4. 2 nl-ix.ip-max.net (193.239.118.22) 26.571 ms 27.957 ms 28.088 ms
  5. 3 te0-1-0-2.er01.lil02.ip-max.net (46.20.254.21) 39.119 ms 37.096 ms 35.778 ms
  6. 4 be4.er01.lil01.ip-max.net (46.20.254.16) 36.294 ms 36.174 ms 39.3 ms
  7. 5 te0-1-0-1.er02.par02.ip-max.net (46.20.254.203) 35.785 ms 36.071 ms 35.911 ms
  8. 6 te0-0-2-0.er01.lyo01.ip-max.net (46.20.254.132) 37.167 ms 35.708 ms 35.847 ms
  9. 7 te0-0-0-1.er01.gva02.ip-max.net (46.20.254.128) 36.332 ms 36.337 ms 36.004 ms
  10. 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

 

  1. $ dig -4 @L.ROOT-SERVERS.NET . SOA +nsid | grep NSID
  2. ; NSID: 64 6b 2d 63 70 68 2d 61 61 ("dk-cph-aa")
  3.  
  4. $ dig -4 @L.ROOT-SERVERS.NET . SOA +nsid | grep NSID
  5. ; 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:
 

  1. $ host -t ns kramse.dk
  2. kramse.dk name server ns01.zencurity.com.
  3. 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:

  1. $ host www.kramse.dk
  2. www.kramse.dk has address 185.129.60.130
  3. 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.

  1. $ host -t ns one.com
  2. one.com name server a.b-one-dns.net.
  3. one.com name server b.b-one-dns.net.
  4. $ host a.b-one-dns.net
  5. a.b-one-dns.net has address 195.206.121.11
  6. a.b-one-dns.net has IPv6 address 2001:67c:28cc::11
  7. $ host b.b-one-dns.net
  8. b.b-one-dns.net has address 195.206.121.139
  9. 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

  1. ns00$ cat /etc/rc.conf.local
  2. nsd_flags=

med config via Ansible og tilsvarende zoner filer:
 

  1. - name: Create name server NSD conf
  2.   template: src=roles/infrastructure-dns/{{ inventory_hostname_short }}/nsd.conf dest=/var/nsd/etc/nsd.conf owner=root group=_nsd mode=0640
  3.   notify:
  4. - restart nsd
  5.  
  6.   - name: Update primary zone files
  7.   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
  8.   with_fileglob:
  9. - 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. :-)

 

 

5 kommentarer.  Hop til debatten
Denne artikel er gratis...

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

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
4
24. marts 2022 kl. 19:23

Du skriver du benytter hidden primary DNS, hvilket jeg selv med glæde har benyttet hos gratisDNS. Men det var lidt uklart for mig hvem du benytter som udbyder at din primary nu? (kan være det bare er det nye, meget lidt læsevenlige v2 design der gør det uklart for mig).

5
25. marts 2022 kl. 20:51

jeg bruger ns01. og ns02.zencurity.com som er Zencurity ApS, mit eget firma. beklager jeg ikke fik skrevet tydeligt nok. Jeg tilbyder dem gerne til et mindre antal andre firmaer som er kommet i klemme i denne migrering.

3
24. marts 2022 kl. 16:30

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?

Faktisk sikrer BGP kun den korteste AS-PATH hvilket intet siger om hvor langt der er rent fysisk. Hvis jeg tjekker vores routing tabel for den angivne adresse ser det således ud:

  1. admin@gc-edge1> show route table internet.inet.0 199.7.83.42
  2.  
  3. internet.inet.0: 913898 destinations, 3399561 routes (913895 active, 197 holddown, 195178 hidden)
  4. @ = Routing Use Only, # = Forwarding Use Only
  5. + = Active Route, - = Last Active, * = Both
  6.  
  7. 199.7.83.0/24 *[BGP/170] 3d 07:00:11, MED 100, localpref 100, from 193.239.117.0
  8. AS path: 25091 20144 E, validation-state: unknown
  9. > to 193.239.118.22 via nl-ix
  10. [BGP/170] 3d 07:00:11, MED 100, localpref 100, from 193.239.116.255
  11. AS path: 25091 20144 E, validation-state: unknown
  12. > to 193.239.118.22 via nl-ix
  13. [BGP/170] 3d 07:00:11, MED 200, localpref 100, from 194.68.128.254
  14. AS path: 25091 20144 E, validation-state: unknown
  15. > to 194.68.128.78 via netnod-stockholm-1500
  16. [BGP/170] 1w0d 04:48:22, MED 200, localpref 100, from 195.69.119.254
  17. AS path: 6939 20144 E, validation-state: unknown
  18. > to 195.69.119.187 via netnod-stockholm-4470
  19. [BGP/170] 5w2d 13:27:11, MED 200, localpref 100, from 212.237.192.254
  20. AS path: 6939 20144 E, validation-state: unknown
  21. > to 212.237.192.187 via netnod-copenhagen
  22. [BGP/170] 12w1d 15:57:18, MED 210, localpref 100
  23. AS path: 1299 20144 E, validation-state: unknown
  24. > to 62.115.180.72 via telia
  25. [BGP/170] 14:56:08, MED 290, localpref 100
  26. AS path: 174 35313 20144 E, validation-state: unknown
  27. > to 149.6.137.49 via cogent
  28. [BGP/170] 3d 05:46:40, MED 100, localpref 100
  29. AS path: 2603 21320 5408 8522 20144 E, validation-state: unverified
  30. > to 185.1.88.18 via sthix
  31. [BGP/170] 3d 05:46:40, MED 100, localpref 100
  32. AS path: 2603 21320 5408 8522 20144 E, validation-state: unverified
  33. > to 212.237.192.24 via netnod-copenhagen

Ud fra det kan vi se, at AS 25091, AS 6939 og AS 1299 alle tilbyder en AS-PATH længde på 2. Ud fra BGP algoritmen er de at betragte som lige gode. Givet de tre lige gode valgmuligheder er 25091 blevet valgt fordi den er gratis (det er en peer) hvorimod 6939 og 1299 er betalte IP transits. AS 174 og AS 2603 er blevet fravalgt på at have længere AS-PATH.

PS.: Jeg håber dette indlæg ender med at se ok ud. Version2 har glemt preview knappen og det er usikkert om de gamle debat tags stadig fungerer som sædvanligt.

1
24. marts 2022 kl. 12:22

Dine resolver anbefalinger. Der mangler en meget vigtig pointe. Flere af de rigtig store CDN udbydere laver geografisk loadbalancing via DNS. Når man anvender en DNS resolver, der ikke står i det netværk man kommer fra, så vil man risikere at blive sendt til et netværk langt væk fra det man kommer fra. Men også mere belasted netværk, der vil skade den oplevelse man har af brugen af sit net.

Jeg ynder at bruge adobes trial side til at teste med. Den er hostet af måske den største CDN udbyder Akamai. De reklamere selv med at de er repræsenteret i mere end 1450 netværk i 135 lande. Det er ret fintmasket.

Lookup til trals.adobe.com giver følgende: Fra TDC DNS på mit arbejde: 95.166.126.11 - TDC i København Fra 4 x 1 DNS: 2.16.63.218 - Akamai i København Fra anycast.censurfridns.dk DNS: 109.105.109.32 - Akamai i Nordunet et sted i Sverige Fra unicast.censurfridns.dk DNS: 2.16.63.218 - Akamai i København Fra 4 x 9 DNS: 23.62.99.18 - Akamai i Amsterdam AMSIX

Og der er mange flere udfaldsrum. Min pointe er at i jagten på at undgå ISP'ens DNS servere (som er en del af den service, som man betaler for), så sender man trafik, som man måske ikke ønsker at sende til en uønsket part. Og risikere dermed at få et markant dårligere resultat, da man ikke nødvendigvis rammer det CDN der er tættest og dermed mest optimalt, for ens brugeroplevelse. Google og Cisco/OpenDNS resolvers har løst det ved at implementere EDNS Client Subnet (ECS). Implementationen giver i sig selv visse privacy bekymringer, men løser problemer med CDN. Jeg synes ikke det er helt simpelt valg, at skifte væk fra ISP'ens resolver. I en sidebemærkning, så anvender Hiper Google Public DNS. Det mener jeg man bør undgå.

2
24. marts 2022 kl. 15:53

Tak for kommentar.

Det rører ved noget helt centralt, at man ikke ud fra hverken routing eller geografisk placering kan spå om performance. Der kan være alskens grunde til at endepunktet du efter DNS besøger kan være ringe, perfekt, uoptimalt eller anbefalet til netop dig. Jeg kan til nøds gå med til at TDC DNS vil sende dig til en cache indenfor eget netværk, at de har en DNS med logik bagved. Du siger Akamai, men det kunne være Netflix eller andet. Mange andre DNS resolvere hos udbydere er en sidegeschjæft som lider en stille død. Det er ikke noget der er fokus på, hvis den bare virker nogenlunde.

De andre svar uanset om det er Nordunet Stockholm, eller via Amsterdam AMSIX kan godt være tilnærmelsesvis lige så gode som Akamai Kbh. Der er mange tilfælde hvor trafikken mellem to danske netværk går ud af landet, grundet økonomi og peerings.

Vi glemte også begge to at nævne at browsere begynder at lave andre tricks, og måske pludselig benytter en anden resolver end dit operativsystem via DoH ... det er også noget skidt i mange tilfælde, og så igen måske en fordel for nogle. Se https://en.wikipedia.org/wiki/DNS_over_HTTPS og https://en.wikipedia.org/wiki/DNS_over_TLS