Blog: DNS på non-standard port – !53

Domain Name System er en stor hierarkisk database med alle vores domænenavne – herunder .dk

Dette system har fungeret i snart 30 år som en afløser for hosts filen som sammenkoblingen af et hostnavn og en IP-adresse. Idag bruger vi allesammen DNS, men jeg tror de færreste tænker over hvor vigtigt det er for vores oplevelse af internet. Det er krumptappen som gør at selvom alt andet i forbindelsen virker, så virker browseren og applikationerne næppe uden DNS.

Når vi så bruger DNS ved de færreste også at DNS er hamrende usikkert, både imod opsamling af pakkerne, ændring af pakkerne i lokalnet og ændring af pakkerne længere ude på internet. Faktisk er vi jo i Danmark kommet så vidt at vi tillader at vores udbydere skal pille ved en central del af infrastrukturen for at tilgodese en mediabranche ude af trit med virkeligheden.

En del af problemet kan løses med DNSSEC, som kan sætte signatur på DNS navne, således at man kan verificere at svaret man får tilbage rent faktisk er rigtigt, autoritativt og signeret med DNSSEC. Det anbefales således at bruge en DNSSEC enablet resolver når man slår navne op på internet.

Jeg har tidligere talt om et godt alternativ til udbyderens navneservere, som hedder Dnssec-trigger
http://www.nlnetlabs.nl/projects/dnssec-trigger/ Dette stykke software gør det nemt at bruge DNSSEC idet softwaren starter en lokal Unbound DNS server på din laptop, med et GUI der midlertidigt kan slå den fra under login til captive portales m.v. – den løsning bruger jeg, og har dermed censurfri DNS overalt.

Men hvad så hvis ISP’en laver deep-packet-inspection på DNS pakkerne? Så kan denne udbyder jo stadig sniffe og ændre på pakkerne (mange har ikke slået DNSSEC til).

Så er der ihvertfald to måder at komme omkring det på er (udover VPN ud af ISP’ens netværk som også er oplagt for mange). Den jeg vil beskrive idag er at bruge en anden port til DNS. Fordelen ved denne metode er at den ikke nødvendigvis kræver installation af ny software.

Skift DNS til en anden port

Normalt bruger DNS port 53/udp, og mange ved slet ikke at den også falder tilbage på 53/tcp. Det vil således være nemt at blokere for brugen af en anden DNS ved at blokere alle pakker til port 53. Det vil også være naturligt at deep-packet-inspection kun kigger efter DNS i traffik på port 53. Det vil tage DNS for næsten alle opslag, men sådan er det heldigvis ikke mere!

Censurfridns som er en gratis DNS service med udgangspunkt i Danmark har nemlig udvidet servicen til at kunne bruges på en ny port 5353. Du kan læse mere om Censurfri DNS og censur på http://www.censurfridns.dk/ og http://blog.censurfridns.dk/

Der vil du finde de nuværende IP-adresser for denne service:

• ns1.censurfridns.dk / 89.233.43.71 / 2002:d596:2a92:1:71:53::
• ns2.censurfridns.dk / 89.104.194.142 / 2002:5968:c28e::53

Disse svarer som sædvanligt på port 53/udp og 53/tcp – så normalt indtaster man blot adresserne fra ovenstående og så bruger man censurfri DNS

Antager vi så nu at denne port er blokeret af en eller anden årsag så kan du skifte porten som din resolver på den lokale arbejdsstation bruger på en af følgende måder.

Dig

Dig kommandoen er den primære genvej til at teste DNS opsætning, og med denne kan man verificere adgangen til navneservere og svar fra disse.

Denne kommando har en option -p som naturligt er portnr.:

Unbound som forwarder

Når man bruger Dnssec-trigger som angivet ovenfor er der en indbygget Unbound navneserver med i pakken. Denne software kan kun være rekursiv server, og ikke autoritativ DNS server, men med alle de funktioner som en sådan skal have. Denne server kan man derfor naturligvis installere som en dedikeret rekursiv navneserver, som normalt så vil spørge direkte til de autoritative navneservere for domænerne direkte (udenom ISP navneservere).

Hvis vi så igen antager at man vil bruge censurfridns skal man skrive de navneservere ind som forwarder. Det betyder at Unbound sender alle forespørgsler videre til disse servere, istedet for som normalt at slå domænerne op via root-servere og dernæst på autoritative servere.

Det virker måske lidt fjollet fordi Unbound selv kan sende videre, men i næste step antager vi så at port 53 er blokeret. Hvis dette er tilfældet vil man kunne bruge port 5353 således:

Det betyder at Unbound som en almindelig rekursiv navneserver modtager forespørgsler fra det lokale netværk på port 53 men sender videre ud på internet via port 5353. Derefter overtager CensurfriDNS servere, slår op i DNS og sender svaret retur til Unbound, der sender det til arbejdsstationen på det lokale netværk. Det kunne eksempelvis være så almindelige Windows klienter kan slå navne op – jeg kan nemlig ikke finde en indstilling som vil gøre at Windows kunne bruge port 5353?

Hvis du nu helst vil se det som pakker, er her Tcpdump output fra serveren som sender forespørgsel på port 5353 til Censurfri DNS servere:

Hvor sikkert er det

Overhovedet ikke, men det kan måske du godt nok til at man med få resourcer kan surfe mere frit på internet. Det kan også være at man mener eller har set at Censurfri DNS er mere stabilt og svarer hurtigere end den normal DNS som ISP’en har sat op. Næste gang vil jeg skrive om DNSCrypt http://dnscrypt.org/ som er en metode til at sikre kommunikationen mellem client og navneserver med kryptering.

Full disclosure: jeg er med i gruppen som driver CensurfriDNS services, og vi er netop igang med at forbedre service, så stay tuned