kramselund jereminsen

Anycast DNS - robust skalerbart

Der er sket en lille ting i Danmark. Der er kommet en ny censurfridns server - hos min gode ven Thomas der bestyrer censurfridns.dk navneservere sammen med en mindre gruppe, inkl undertegnede.

NOTE: Dette indlæg kan ses som en reklame, og er det til dels. Dog er det også vigtigt at brugere af en DNS service får opdateret indstillingerne, for at undgå problemer med lange svartider på DNS og der forsvinder en navneserver om MEGET kort tid. Jeg håber I tillader det, og samtidig giver det mig lejlighed til at gentage lidt information om anycast DNS. Censurfridns for dem som ikke kender det er et gratis alternativ til OpenDNS, GoogleDNS osv. uden censur.

Anycast DNS

Anycast DNS betyder kort fortalt at man smider en DNS forespørgsel ud på internet i form af en UDP pakke (glem lige DNS over TCP for nu). Denne pakke sendes så til destinationsadressen, så langt så godt. Til dette kan man bruge kommandoen host som anbefales kraftigt fremfor nslookup. Nslookup bruger ikke samme metode som dit resolverbibliotek, og derfor kan du ikke være sikker på de kommer til samme resultat, brug nu bare host. Til Peter og Thomas, ja ja brug I bare dig - I har så høj opløsning at I kan klare en hel side med information for et enkelt opslag. :-)

Nå men host kommandoen bruges på kommandolinien således:

$ host l.root-servers.net
l.root-servers.net has address 199.7.83.42
l.root-servers.net has IPv6 address 2001:500:3::42

og hvis jeg ønsker at slå op på en bestemt navneserver sætter man blot den på som argument:

hlk@katana:hlk$  host l.root-servers.net 10.0.42.1
Using domain server:
Name: 10.0.42.1
Address: 10.0.42.1#53
Aliases:
l.root-servers.net has address 199.7.83.42
l.root-servers.net has IPv6 address 2001:500:3::42

Men hvad nu hvis den navneserver som ligger bagved adressen ikke kan håndtere alle opslagene? Så må man vel ud og købe et større miljø med loadbalancere og clustersoftware? eller nej. Internet har nemlig begrebet Anycast implementeret. Dette trick tillader at man annoncerer samme adresserum flere steder - samtidigt:

On the Internet, anycast is usually implemented by using Border Gateway Protocol to simultaneously announce the same destination IP address range from many different places on the Internet. This results in packets addressed to destination addresses in this range being routed to the "nearest" point on the net announcing the given destination IP address.

Så hvis man bruger BGP, annoncerer et adresserum - som best practice for tiden er minimum en /24 og lægger en DNS server på en adresse i dette adresserum - så kan man sprede opslagene gevaldigt. Faktisk er det præcist hvad man har gjort med rodzonen, de 13 IP-adresser som man kender som a.root-servers.net til m.root-servers.net. er annonceret fra mange steder på internet. Det kan man læse en hel masse om på hjemmesiden http://www.root-servers.org/

Anycast DNS i praksis for brugeren

I praksis betyder det at man kommer til den DNS server som er tættest på, fordi BGP foretrækker en kort AS-path, så en server i Finland tdc01.ring.nlnog.net får en L-root instans gennem Bahnhof i Sverige, men en tilsvarende apnic01.ring.nlnog.net i Japan går til Australien efter samme IP. Disse noder er en del af RING NLNOG som er perfekt til den slags undersøgelser.

solido@tdc01:~$ traceroute 199.7.83.42
traceroute to 199.7.83.42 (199.7.83.42), 30 hops max, 60 byte packets
 1  te4-3-549.hsrp-srv-pe1.hel.fi.ip.tdc.net (194.100.40.50)  0.454 ms  0.529 ms  0.512 ms
 2  netnod-ix-ge-b-sth-4470.bahnhof.net (195.69.119.85)  7.618 ms  7.731 ms  7.721 ms
 3  sto-cr3.sto-cr1.bahnhof.net (46.59.112.162)  7.549 ms  7.676 ms  7.655 ms
 4  sto-cr1.pio-dr3.bahnhof.net (85.24.151.225)  6.991 ms  7.204 ms  7.071 ms
 5  pio-dr3.pio-dr2.bahnhof.net (85.24.151.72)  7.663 ms  7.270 ms  7.513 ms
 6  l.root-servers.net (199.7.83.42)  6.986 ms  7.029 ms  7.052 ms
solido@tdc01:~$ dig +short @199.7.83.42 ID.SERVER chaos txt
"arn01.l.root-servers.org"
 
solido@apnic01:~$ traceroute 199.7.83.42
traceroute to 199.7.83.42 (199.7.83.42), 30 hops max, 60 byte packets
 1  gw.rand.apnic.net (203.133.248.254)  0.719 ms  0.713 ms  0.709 ms
 2  p7575.syd.equinix.com (202.167.228.46)  12.664 ms  12.684 ms  12.739 ms
 3  tengigabitethernet2-1.pe1.a.syd.aarnet.net.au (202.158.202.19)  12.870 ms  12.884 ms  12.879 ms
 4  l.root-servers.net (199.7.83.42)  12.863 ms  12.865 ms  12.918 ms
solido@apnic01:~$ dig +short @199.7.83.42 ID.SERVER chaos txt
"syd01.l.root-servers.org"

Så langt så godt! Denne funktion tillader altså at IP-adressen 199.7.83.42 findes flere steder, annonceret med BGP og det giver redundans og robusthed. Hvis eksempelvis servere(n) hos Bahnhof går ned, forsvinder BGP annonceringen, og en anden route til dette adresserum bliver den active route. Fedt nok Internet. Faktisk betyder det at en rod navneserver idag ofte kan klares med langt færre resourcer, eksempelvis en enkelt server.

Anycast hos CensurfriDNS / UncensoredDNS

Det som nu er sket hos CensurfriDNS er at ns2.censurfridns.dk lukker 1. oktober, og erstattes med anycast.censurfridns.dk! Læs annonceringen her: http://blog.censurfridns.dk/node/57
Der skal samtidig lige være et stort tak til Comendo der siden starten i oktober i 2009 har medvirket villigt til dette projekt. Det er blandt andet den slags der giver mig glæde ved at være i internetmiljøet i Danmark.

Så hvis du vil bruge censurfridns skal du benytte disse adresser:

  • 91.239.100.100 anycast.censurfridns.dk
  • 89.233.43.71 ns1.censurfridns.dk
  • 2001:67c:28a4:: anycast.censurfridns.dk
  • 2002:d596:2a92:1:71:53:: ns1.censurfridns.dk

Bemærk at der nu indgår anycast i navnet på IP adressen 91.239.100.100 - og denne er rigtigt nok anycast'et. Samtidig er dette IP-adresserum registreret til censurfridns projektet og den IP skifter således ikke uanset om servere tilføjes eller fjernes fremover. Så både 91.239.100.100 og 2001:67c:28a4:: er en del af censurfridns' egne "Provider Independent (PI)" IP ranges og burde være stabile i mange år frem i tiden. Hvis du ikke kan huske den, så kan det måske hjælpe at tænke 9 123 9 100.100, tak til BTDK i #BSD-DK for dette tip.

Jeg checkede også om den nye IP kunne nåes fra "internet" og fra RING netværket kan man lave en ring-ping, som gav en gennemsnits ping tid fra hele verden til 91.239.100.100 fra 260 servers på 61ms average. Det lyder måske slemt, men reelt er de fleste netværk i Europa under eller omkring 20 ms.

solido@tdc01:~$ ring-ping -v 91.239.100.100
coloclue01:                    17.933
cyso01:                        16.263
widexs01:                      14.475
duocast01:                     16.306
interconnect01:                16.821
xlshosting01:                  14.871
bit01:                         44.099
previder01:                    17.821
leaseweb01:                    14.740
oxilion01:                     18.224
...

TL;DR bruger du censurfridns skal ud udskifte ns2 til anycast adressen 91.239.100.100

Var ovenstående ligetil? Er der spørgsmål omkring Anycast? DNS?

PS Hvis du gerne vil vide hvilke navneservere der performer bedst for dig, fra dit netværk kan du bruge https://code.google.com/p/namebench/

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Bjerregaard

Godt indlæg som sædvanligt Henrik. Kan du ikke lige kort foklare en DNS idiot som mig, hvorfor man skulle bruge CensurfriDNS frem for OpenDNS? Jeg har brugt OpenDNS i lang tid og har været meget glad for det. Altid hurtig (virker det til) og aldrig nogen hickups.

  • 3
  • 0
Henrik Kramselund Jereminsen Blogger

hvorfor man skulle bruge CensurfriDNS frem for OpenDNS

Der findes mange DNS leverandører og hvem du bruger afhænger blandt andet hvordan du vægter performance, spam, tillid. Performance for censurfridns vil formentlig ligge i samme boldgade som OpenDNS - hvis du er i Danmark og bruger en navneserver i Danmark, som cacher opslag for en del danske brugere.

Mht spam har OpenDNS indimellem givet svar, uanset om domænet/navnet fandtes eller ej, aka redirect til egen side osv. De siger nu at det er væk, men kommer det igen? "As of June 6th, all of OpenDNS’s users will get NXDOMAIN and SERVFAIL messages to get truly RFC compliant DNS." http://www.opendns.com/no-more-ads/

DNSSEC supporteres af censurfridns, en del andre DNS services gør ikke - OpenDNS gør vist? - DNSSEC benyttes til at validere de DNS svar man får, men langt fra alle benytter dette. Det kan eksempelvis benyttes til DNSSEC DANE

OpenDNS er stolte af deres DNScrypt som krypterer dine DNS forespørgsler, deres kode er bare noget klamt slam! Vi har rodet med en OpenVPN løsning hvor du bruger en tunnel til censurfridns - der mangler testere af dette. Dette berører også tillid, hvem stoler du på? Din internetudbyders DNS som er instrueret i at lyve omkring thepiratebay og andre opslag? I censurfridns stoler du basalt set på Thomas som person, og du har rig lejlighed til at møde ham på diverse open source arrangementer, eller invitere ham til at komme og fortælle om DNS censur i DK og censurfridns. Så censurfridns er altså en rå ufiltreret DNS service, som det bør være.

Jeg ville anbefale at du og andre prøver namebench, som kører en masse test mod DNS servere, og man kan angive censurfridns, eller andre og få dem testet med. Burde måske lave et indlæg med det en dag.

  • 3
  • 0
Johannes Ulfkjær Jensen

Er det ikke problematisk at have en censurfri dns i Danmark ? Umiddelbart kan samme retskendelse som gælder for ISP'erne vel overføres til DNS udbydere eller ?

Og så lidt flueknepperi..

Nslookup bruger ikke samme metode som dit resolverbibliotek

Teknisk set gør host det heller ikke på OSX:

Mac OS X NOTICE The host command does not use the host name and address resolution or the DNS query routing mechanisms used by other processes running on Mac OS X.

  • 0
  • 0
Jacob Rasmussen

Jeg ved at netflix bruger DNS til at afgøre, om jeg er en amerikansk eller dansk kunde. Eller mere specifikt, om jeg må se det amerikanske udvalg, eller det danske.

Hvordan hænger Anycastet DNS nu sammen med Netflix? De ser vel min resolvers DNS adresse, og afgør dermed hvor jeg befinder mig. Det vil altså sige, at hvis Thomas nu får et par Digital Ocean maskiner på hvert kontinent, og jeg bruger 91.239.100.100 som primær DNS, så vil jeg kun kunne se det 'lokale' content, men bruger jeg den Unicastede 89.233.43.71, kan jeg se det 'Danske' content, da den server vel stadig står herhjemme i Danmark.

Jeg har problemer med at se netflix, når jeg har IPv6 enabled, fordi min tunnel er termineret i Amsterdam. Det her Anycast tilføjer endnu en dimension af kompleksitet, som potentielt kan 'snyde' netflix, og alternativt bare gøre livet lidt mere surt for mig som Internet forbruger.

Hvis jeg brugte min ISP's resolvere, eller en lokalt installeret resolver, går jeg ud fra at Netflix altid vil virke, i hvert fald på ren IPv4.

Mvh. 'BTDK' ;-)

  • 1
  • 0
Claus Mattsson

Hej Henrik & Thomas,

Det er jo fantastisk med endnu en styrkelse af servicen. Det er enormt værdsat!

Men men. Hvornår forventer du/I at I kan understøtte edns-client-subnet? CDN bliver jo mere og mere populært og som BTDK også skriver, så kan der være problemer med forskellige resolvers på forskellige netværk... Så vidt jeg har forstået, så er edns-client-subnet løsningen...

Med edns-client-subnet mekanismen sendes man til den ønskede CDN, som CDN udbyderen ønsker det. På min linie er det f.eks. konkret ComX's datacenter i Albertslund frem for Google i Amsterdam...

Google Public DNS og OpenDNS understøtter dette... Gør I? Hvornår?

Pft.

  • 0
  • 0
Henrik Kramselund Jereminsen Blogger

Teknisk set gør host det heller ikke på OSX:

lol og tak, du har ret. Jeg har selv gennem årene kæmpet en brav kamp med OSX. Sågar lavet et script med "dscacheutil -flushcache" til at smide cachen når OSX drillede. Til gengæld er host og dig magen til dem på andre Unixsystemer som jeg bruger, og da det typisk er debug af nogle problemer er det fint med host. Jeg har ikke undersøgt alle programmerne på min Mac, men visse opfører sig anderledes end andre - udover at jeg naturligvis har DNSSEC extension i Firefox osv.

@claus, edns-client-subnet kender jeg ikke - jeg er jo netværksmanden og DNS data er bare overhead ;-)

@btdk, det er ligesom alt andet DRM, regionskoder og snask ... besværligt. Tak for VPN forbindelser. Alle burde lære at lave en SSH tunnel med socks til at browse med når man er ude i verden.

Hvis man rejser meget er DNSSEC-trigger IMHO en god løsning, nemt at skifte mellem den lokale DNS fra DHCP "hotspot signon" og en helt lokal Unbound der kører på 127.0.0.1 - og som så vil lave DNS opslag fra samme IP som du kommer fra.

  • 2
  • 0
Baldur Norddahl

Hvis jeg peger mine kunder hen på censurfridns.dk via vores DHCP opsætning, så får jeg nok bare en dom for at det må jeg ikke.

Lige nu er intet blokkeret hos os. Men når der en dag er en rettighedshaver der henvender sig, og forlanger nogle domæner blokkeret, så er vi nødt til at rette ind og blokkere. Den kamp blev tabt for længe siden.

Mit gæt er at situationen er det samme for censurfridns.dk. Det er kun censurfrit så længe at de store selskaber ikke har opdaget det endnu. Hvis de ser sig sure på jer, så må i rette ind eller lukke. Eller flytte til udlandet, men så er det ikke sikkert at .dk domænet kan overleve og der skal være nogle andre der (officielt) står for det.

Vi er nødt til at få en politisk løsning igennem eller noget teknologi, som ikke kan blokeres så nemt. Det er ikke nemt, når modparten bare behøver sige "tænk på børnene!" (børnepornofilteret viste vejen for filteret for kommercielle interesser).

  • 3
  • 0
Baldur Norddahl

ISP'erne som branche hverken kan eller blev dømt for noget. Der har været en række sager hvor specifikke virksomheder er blevet dømt. Men når nu sagen allerede er blevet kørt, og din egen sag er 100% magen til, så er det spild af penge ikke bare at rette ind med det samme.

Hvorfor skulle retten nå frem til et andet resultat, blot fordi der ikke er tale om en virksomhed der sælger internet eller fordi der er tale om et hobbyprojekt? Pointen er at retten mener at man ikke må videreformidle adgang til udenlandske hjemmesider, hvor der er indhold der krænker visse kommercielle interesser.

Mig bekendt er "hvordan er op til dem" hellere ikke korrekt. Retten bad specifikt om DNS blokkering. Og endvidere at mere indgribende blokkering, som eksempelvis deep packet inspection og IP-blokkering, ikke er nødvendig.

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