Valg af DNS udbyder

Da internetudbydernes DNS servere ikke er gode nok til os alle er det heldigt at der findes alternative udbydere af DNS. Men hvilken udbyder er det bedste valg? Her er dem jeg kender, med hver udbyders fordele og ulemper. Desværre er der ingen af dem der er perfekte på alle punkter. Findes der en udbyder som jeg ikke kender, som er bedre end nedenstående?

Google
Fordele:
Troværdige svar

Ulemper:
Ingen IPv6 support mellem recursive resolver og autoritativ DNS server.
Ingen retry mellem recursive resolver og autoritativ DNS server, en tabt pakke kan resultere i fejlende DNS opslag.

censurfridns.dk
Fordele:
Troværdige svar

Ulemper:
Begrænset IPv6 support, har kun 6to4.

HE
Fordele:
IPv6 support
Troværdige svar
Er på IPv6 whitelist hos Google og Facebook, så man kan få AAAA records for deres domæner.

Ulemper:
DNS servicen er noget ustabil.

OpenDNS
Fordele:
IPv6 support

Ulemper:
Forkerte svar på nogle DNS opslag.

Ikke noget alligevel...

http://wiki.opennicproject.org/HomePage

meh (3) skrev:

http://wiki.opennicproject.org/HomePage

Det er så et helt andet namespace, som dog duplikerer det meste af det eksisterende namespace (hvis ikke det hele). Det var ikke lige det jeg spurgte efter, omend det selvfølgelig er interessant nok.

Det bliver noget interessant hvordan man får DNSSEC til at virke med opennic. Det kommer sikkert til at blive sat op med en helt separate rod, hvilket betyder at hvis man sætter sin software op til deres rod, så har opennic fuldstændig kontrol over ens DNS opslag, også i de konventionelle TLDer.

Det kunne være interessant hvis man kunne sætte sin software op således at man henter fra begge rødder og kun stoler på resultatet hvis de enten giver samme nøgle for TLDen, eller hvis den ene siger at den pågældende TLD ikke findes. Hvis de to rødder giver forskellig nøgle for TLDen skal det håndteres på samme måde som man ville have håndteret en ugyldig signatur.

#4
Nogle af de listet DNS servere er åbne for alle.
Se evt http://wiki.opennicproject.org/ClosestT2Servers

Hvad med Level 3 ?
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6

meh (5) skrev:

Nogle af de listet DNS servere er åbne for alle.

Ja, men det er stadig et andet namespace end standard DNS. Hvis man er indforstået med hvad det vil sige at bruge et andet DNS namespace, så er det sikkert et udmærket valg. Hvis man vil lave opslag i standard DNS namespace skal man ikke vælge opennic.

freesoft (6) skrev:

Hvad med Level 3 ?

Jeg ved ikke så meget om dem, men jeg har vist hørt dem nævnt før. De har tilsyneladende ingen IPv6 support.

Hvorfor vælger man at sætte dem op på seks IP adresser som man så placerer så tæt på hinanden?

Med traceroute konstaterede jeg at
4.2.2.1
4.2.2.3
4.2.2.5
er 20 hops væk fra mig og har 4.69.139.99 som næstsidste hop, mens
4.2.2.4
4.2.2.6
er 17 hop væk fra mig og har 4.69.154.67 som næstsidste hop, og endeligt er
4.2.2.2
placeret et sted hvor routerne ikke virker rigtigt, så traceroute kan ikke identificere den præcise rute.

De seks IP adresser dækker altså over blot tre forskellige placeringer.

#4

Hvis man skal sammenligne resultatet, så kræver det jo to opslag, i stedet for et enkelt.

Jeg tror det kunne være mere interessant, hvis man kunne vælge at bruge et sæt DNS servere, til "normale" TLD'er, og et andet sæt, til OpenNIC.

BurningShadow (8) skrev:

Hvis man skal sammenligne resultatet, så kræver det jo to opslag, i stedet for et enkelt.

Det vil kun være ved opslag af TLD at der skal sammenlignes. De har en lang TTL, så så snart de er cachet kommer du sjældent til at skulle vente på flere opslag af dem. Og selv hvis du tilgik alle TLDer er det ikke mere end nogle få hundrede indgange i cachen (i praksis tror jeg sjældent du tilgår mere end 20).

BurningShadow (8) skrev:

Jeg tror det kunne være mere interessant, hvis man kunne vælge at bruge et sæt DNS servere, til "normale" TLD'er, og et andet sæt, til OpenNIC.

Det er også det der sker når du bruger opennic rødderne. Men du er nødt til at stole på hvad opennic fortæller dig om hvilke der er under opennic, og hvilke der ikke er.

Mit forslag ville derimod betyde at du ikke ville kunne få forkerte svar da TLD skulle checkes imod DNSSEC nøglen for hver rod.

Humm jeg synes bestemt at de også resolvede std tld'er da jeg engang brugte dem.

meh (10) skrev:

Humm jeg synes bestemt at de også resolvede std tld'er da jeg engang brugte dem.

Det gør de også. Det er stadig et andet namespace, der er bare et stort overlap mellem de to.

Det betyder at hvis din recursive resolver bruger opennics rod, så er du nødt til at stole på at opennic til enhver tid sender dig til de samme servere som en officiel rodserver ville have gjort. Opennic har mulighed for hvornår som helst at sende dine opslag til standard TLDer et andet sted hen.

Du kan ikke bruge opennics rod med en recursive resolver, der bruger standard DNSSEC nøgle. Du er nødt til at give resolveren en anden nøgle til roden, og dermed vil du heller ikke kunne bruge DNSSEC til at sikre dig at du får korrekte svar fra opennic til standard TLDer, da det er opennics signatur du i så fald vil verificere. Desuden lyder det på dokumentationen som om opennic kun lige er begyndt at overveje hvordan de vil håndtere DNSSEC. De er altså langt bagefter de officielle rodservere på det punkt.

Selv hvis man får sat en recursive resolver op med en opennic DNSSEC nøgle og opennic har de nødvendige records i deres rodzone for at få det til at virke, så vil det stadigvæk fejle såfremt klienterne begynder at validere DNSSEC.

Hvis både klient og recursive resolver validerer DNSSEC, så skal de begge sættes op med den rodnøgle som opennic bruger. Det er ikke på nuværende tidspunkt til at vide hvad problemer det vil medføre på et senere tidspunkt.

I teorien kunne det virke uden problemer hvis den officielle rodzone lavede DNSSEC opt-out for alle de domæner som opennic vil håndtere anderledes. Men at regne med den grad af samarbejde fra den officielle rodzone går ligesom imod hele idéen med opennic.

Det er forståeligt nok hvis opennic ikke har en plan for hvordan de vil håndtere DNSSEC, men de er nødt til at finde på en plan før validering bliver almindeligt i klienterne.

Hvis man er indforstået med ovenstående konsekvenser ved at bruge et andet namespace, så er der ikke noget galt i at bruge opennic.

Nu lyder det som om DNSSEC i STD er piv nødvendigt for dig eller at namespace kun er STD. Du skulle måske havde præsiseret specifik hvad i DNS du ledte efter i #1

kasperd (11) skrev:

I teorien kunne det virke uden problemer hvis den officielle rodzone lavede DNSSEC opt-out for alle de domæner som opennic vil håndtere anderledes. Men at regne med den grad af samarbejde fra den officielle rodzone går ligesom imod hele idéen med opennic.

Efter at have overvejet det grundigt er jeg kommet frem til, at jeg synes dette er en mangel i DNSSEC.

DNSSEC burde udvides med krav der gør det muligt at flette to rodzoner underskrevet med hver deres rodnøgle. Kravene bør skelne meget klart mellem hvad der er krav til data og hvad der er krav til infrastrukturen til at håndtere dem.

Det første punkt i specifikationen skal angive regler for hvordan der flettes. Fletningen skal flyttes så tæt på klienten som muligt, hvis support for multiple DNSSEC rødder eksisterer hele vejen fra klient til rodservere skal det være ude på brugerens egen computer der træffes beslutning om hvilke rødder denne bruger ønsker at modtage records fra.

Hver TLD skal tages fra præcist én af rødderne. Således skal det ikke være muligt for en klient at modtage svar fra opennic for et subdomæne under en TLD og officielle svar for et andet subdomæne under samme TLD.

Blandt svarene fra de forskellige rødder skal der prioriteres i følgende rækkefølge:
- Svar med en DNSSEC nøgle for TLD
- Svar med DNSSEC opt out for TLD
- Svar med NXDOMAIN for TLD

Det vil sige at man kun får NXDOMAIN, hvis alle de rødder man bruger siger NXDOMAIN. Hvilke autoritative DNS servere man vælger for et givent TLD skal der ikke være noget krav til, der kræves blot at de er underskrevet med den DNSSEC nøgle man valgte for pågældende TLD.

Hvis to eller flere rødder giver forskellige DNSSEC nøgler for et TLD er der tale om en konflikt, og valget om hvordan en sådan konflikt håndteres skal flyttes så tæt på klienten som muligt.

Der er to muligheder. Enten prioriterer man DNSSEC rødderne og tager svaret fra DNSSEC roden med højeste prioritet blandt dem der svarede med en nøgle. Eller også sidestiller man rødderne og betragter det som en fejl hvis to rødder med samme prioritet giver forskellige svar. Den type fejl bør så håndteres på samme måde som en ugyldig signatur ville være håndteret.

Hvis man bruger tre eller flere rødder vil man godt kunne have en situation hvor man både har prioritering på flere niveauer og har et niveau med sidestillede rødder.

Endeligt skal det være muligt at markere nogle rødder som optional, således at man er villig til at flette de andre såfremt en optional rod ikke er tilgængelig. F.eks. kunne en klient sættes op således at den officielle rod er mandatory og opennic er optional. Dermed vil klienten kunne fungere både med en resolver der kun har adgang til officielle svar og med en resolver der har adgang til både opennic og officielle svar.

Der skulle så introduceres en EDNS option hvor en klient kan fortælle serveren hvilke rødder den bruger, og hvilken rækkefølge de prioriteres i. Der skal enten kunne sendes en komplet liste eller blot en hashværdi. Således kan en resolver cache oplysningerne og man behøver ikke bruge så mange bytes på at sende den komplette liste hver gang.

Både rodservere og recursive resolvers med support for flere DNSSEC rødder skal forstå denne EDNS option, men skal samtidigt også konfigureres til at træffe en beslutning på vegne af de klienter, der ikke selv har support for det.

For klienter helt uden DNSSEC support kan en recursive resolver således godt flette zoner for klienten. For klienter med DNSSEC support, men uden support for at fortælle den recursive resolver hvilken rod den bruger til validering skal en recursive resolver være konfigureret til at bruge en enkelt DNSSEC rod.

En recursive resolver bør kunne cache og besvare forespørgsler der inkluderer rødder, som den ikke ville inkludere hvis den selv skulle træffe på vegne af klienten.

Endeligt skal der være krav om at rodserver softwaren kan håndtere flere rødder på samme infrastruktur. Samtidigt skal det også være et krav at man inkluderer den officielle DNSSEC rod som en af rødderne på den pågældende pulje af servere.

Sidstnævnte krav lyder måske lidt mærkeligt, men det er et meget rimeligt krav af følgende årsager:
- Det er en meget lille mængde data der er tale om, og de ændres sjældent, det er altså ikke et problem med resourcer.
- Der er ikke noget krav om at man skal inkludere den officielle rod i svar til klienter, med mindre klienten direkte spørger om den.
- Kravet betyder at klienter som kun understøtter den oficielle DNSSEC rod vil kunne bruges imod resolvere som anvender en alternativ DNS rod.