gigacampus » start page » dns_recursive_ip_fragments

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

gigacampus:dns_recursive_ip_fragments [2013/07/14 13:37] (current)
gunnarb@uninett.no created
Line 1: Line 1:
 +====== Hvorfor må min rekursive navnetjener kunne motta IP-fragmenter? ======
  
 +
 +===== Sammendrag =====
 +
 +DNS-protokollen har i løpet av de siste 10-15 årene blitt utvidet med
 +flere typer ny funksjonalitet.  En viktig utvidelse som i økende grad
 +tas i bruk er DNSSEC.  En følge av dette er at alle rekursive
 +navnetjenere må kunne motta fragmenterte UDP-pakker for at
 +navneoppslag skal fortsette å fungere tilfredstillende.  Dette notatet
 +vil forklare bakgrunnen for hvorfor det er slik.
 +
 +
 +===== Introduksjon=====
 +
 +DNS transporteres oftest over lettvektsprotokollen UDP, men kan også
 +transporteres over den mer komplekse TCP.  UDP foretrekkes fremdeles
 +for oppslag, siden den krever færre pakker / rundreisetider for
 +oppslag.  For oppslag over UDP var det opprinnelig slik at
 +spesifikasjonen for protokollen sa at den maksimale størrelsen for et
 +DNS-svar var 512 bytes, og tidligere har ikke denne
 +størrelsesbegrensningen vært noe vesentlig problem.  Dette endrer seg
 +med innføringen av DNSSEC, som muliggjør kryptografisk bekreftelse av
 +dataene som blir publisert i DNS.
 +
 +Her følger en kort beskrivelse av bakgrunnen for DNSSEC, og dette vil
 +forhåpentligvis lede fram til en forståelse for hvorfor alle
 +navnetjenere må kunne motta fragmenterte UDP-pakker.
 +
 +
 +===== Bakgrunn=====
 +
 +DNS infrastrukturen har over tid vært gjenstand for sikkerhetsangrep.
 +Spesielt nevneverdig her er den såkalte "Kaminsky-bugen", identifisert
 +ved CVE-2008-1447.  Dette angrepet utnyttet en svakhet i DNS-
 +protokollen til å injisere uriktig informasjon i en rekursiv
 +navnetjeners cache -- informasjon som denne i sin tur gir videre til
 +sine klienter.  Dette angrepet kan brukes til å dirigere brukere av en
 +gitt tjeneste til et annet sted enn dit man trodde man skulle, og
 +brukere kan derved avlures bruker-id, passord og det som verre er.
 +
 +Den umiddelbare forbedringen som ble implementert av alle som
 +produserer DNS navnetjenerprogramvare for rekursiv oppslagstjeneste
 +var å introdusere mer tilfeldighet i valg av DNS query-ID og i valg av
 +UDP portnummer å sende forespørselen fra, men begge disse nummer-
 +rommene er relativt små, og som sikkerhetsadvarselen fra ISC som
 +vedlikeholder BIND sier: DNSSEC er den eneste definitive løsningen av
 +dette problemet.
 +
 +
 +===== DNSSEC =====
 +
 +DNSSEC er en DNS protokollutvidelse som har blitt utviklet over de
 +siste 10-15 årene, og den er i øyeblikket inne i sin tredje revisjon
 +og er nå regnet som stabil.  Man startet altså å utvikle DNSSEC lenge
 +før Kaminsky-bugen ble oppdaget.
 +
 +DNSSEC brukes for kryptografisk sikring av informasjon fra de
 +publiserende navnetjenerne for en sone fram til hver enkelt rekursiv
 +navnetjener som ønsker å slå opp informasjonen, der hver enkelt
 +rekursiv navnetjener selv kan verifisere at de dataene den har mottatt
 +er autentiske, dvs. stammer fra den opprinnelige kilden, og at dataene
 +ikke har blitt modifisert underveis.
 +
 +DNSSEC introduserer en rekke nye DNS post-typer.  Dersom en rekursiv
 +navnetjener indikerer at den gjerne vil motta DNSSEC-postene (det
 +finnes et flagg i headeren i forespørslene som signaliserer dette), så
 +må mange av disse post-typene transporteres sammen med det "egentlige"
 +svaret på et gitt spørsmål for at en rekursiv navnetjener effektivt
 +skal kunne verifisere at dataene er autentiske.  Dette vil føre til at
 +svaret som skal sendes i de aller, aller fleste tilfeller vil være
 +større enn 512 bytes, og i mange tilfeller også større enn 1500 bytes.
 +
 +DNSSEC tas stadig mer i bruk.  I juli 2010 ble rot-sonen signert med
 +DNSSEC, og i skrivende stund er bl.a. mer enn 10% av svenske domener
 +og mer enn 20% av nederlandske domener DNSSEC-signert.  I tillegg er
 +også de store generiske domenene .com, .net og .org i tillegg til
 +mange fler også DNSSEC-signerte.  Dette betyr at mange domeneeiere nå
 +*kan* ta DNSSEC i bruk.
 +
 +
 +===== EDNS0 -- mekanisme for store DNS-pakker =====
 +
 +For å kunne bære DNS svar-pakker som har flere enn 512 bytes innhold
 +har utvidelsen med navn EDNS0 blitt laget (ref. RFC 2671, datert
 +august 1999).  En klient eller rekursiv navnetjener kan ved å bruke
 +denne opsjonen indikere at den er i stand til å motta mer data enn det
 +som ellers var historisk standard, 512 bytes, og det er ikke uvanlig å
 +indikere EDNS0 bufferstørrelse på 4096 bytes.  Siden denne trafikken
 +fremdeles stort sett går over UDP og de aller fleste av oss fremdeles
 +har våre maskiner på nett som bare støtter 1500 bytes store
 +Ethernett-pakker, så betyr det at det må gjøres fragmentering.
 +Derfor: for ikke å ødelegge for moderne bruk av DNS må IP-fragmenter
 +slippes igjennom eventuelle pakkefiltre eller brannmurer, minimum til
 +alle rekursive DNS navnetjenere.
 +
 +Saken er nemlig den at moderne versjoner av rekursive navnetjenere,
 +det være seg om de kommer fra Microsoft (Windows 2008R2 eller nyere),
 +eller om det er open-source variantene Unbound (alle versjoner) eller
 +BIND (alle supporterte versjoner, dvs. 9.6 eller nyere) vil alle
 +sammen både gjøre bruk av EDNS0 med bufferstørrelse > 1500 bytes (4096
 +bytes ser ut til å bli brukt av majoriteten), *og* indikere til alle
 +publiserende navnetjenere at de skal sende med DNSSEC-informasjon
 +dersom dette finnes tilgjengelig, *selv om de ikke er konfigurert til
 +faktisk å gjøre validering av svarene*.
 +
 +Dersom fragmenterte pakker ikke slipper igjennom til de rekursive
 +navnetjenerne har de enkelte implementasjonene litt ulike strategier
 +for å falle tilbake på alternativ oppførsel, der de f.eks. bruker en
 +mindre EDNS0 bufferstørrelse enn 1500, evt. faller helt tilbake til
 +ikke å bruke EDNS0.  Dette innebærer imidlertid også at man må vente
 +på en time-out før man kan starte å bruke disse alternative
 +strategiene, og det vil derfor ta ekstra lang tid å slå opp navn der
 +svarpakken i utgangspunktet er større enn 1500 bytes.  Konsekvensen
 +for sluttbrukeropplevelsen blir at "nettet er tregt", selv om det ikke
 +er det som faktisk er årsaken.
 +
 +
 +===== Konklusjon =====
 +
 +
 +Moderne rekursive DNS navnetjenere har behov for å motta UDP
 +fragmenter for at DNS oppslagstjenesten skal kunne fungere godt.
 +Dette vil dessuten også være en nødvendig forutsetning for at en
 +rekursiv navnetjener skal kunne validere dataene den mottar med
 +DNSSEC, noe som vil være et naturlig første skritt å ta i
 +forbindelse med å ta i bruk DNSSEC.  Dette behovet for mottak av
 +IP-fragmenter må tas hensyn til når man setter opp pakkefiltre
 +og/eller brannmur-regler.
 
 
gigacampus/dns_recursive_ip_fragments.txt · Last modified: 2013/07/14 13:37 by gunnarb@uninett.no

Viktig melding: openwiki.uninett.no

UNINETT OpenWiki er under utfasing. Wikier som er lite brukt er satt i kun-lese-modus. Ta kontakt med UNINETT for å åpne for skrivetilgang ved behov.

Group memberships: no groups