DNS-utvidelsesmekanismer

The Extending Mechanisms for DNS (EDNS) er en spesifikasjon for å utvide størrelsen på forskjellige Domain Name System (DNS) parametere, som hadde størrelsesbegrensninger som internettingeniørmiljøet anså for begrenset til å øke funksjonaliteten til protokollen. Det første settet med utvidelser ble publisert i 1999 av Internet Engineering Task Force som RFC 2671 , også kjent som EDNS0. [ 1 ]

Motivasjon

Domenenavnsystemet ble først utviklet på begynnelsen av 1980-tallet. Siden den gang har det blitt forbedret med nye funksjoner samtidig som det opprettholder kompatibiliteten med tidligere versjoner av protokollen .

Restriksjonene på størrelsen på de forskjellige variabelfeltene, returkodene og typene etiketter som er tilgjengelige i den grunnleggende DNS-protokollen, var ikke nok til å støtte noen av de ønskelige funksjonene. Videre var DNS-meldinger båret av UDP begrenset til 512 byte, hvis Internet Protocol (IP) og transportlagoverskrifter ikke ble vurdert . [ 2 ] Å ty til å bruke Transmission Control Protocol (TCP) var ikke gjennomførbart fordi det i stor grad ville øke kontrolldatatrafikken ( overhead ). Dette utgjorde et stort hinder for å legge til nye funksjoner til DNS. I 1999 foreslo Paul Vixie å utvide DNS for å tillate nye parametere og svarkoder og for å tillate lengre svar i et rammeverk som er bakoverkompatibelt med tidligere implementeringer.

Mekanisme

Siden ingen nye parametere kunne legges til DNS-overskriften, ble differensieringen av det nye protokollformatet oppnådd med muligheten for pseudo-ressursposter , ressurspostene OPT. Dette er kontrollposter som ikke vises i sonefiler. DNS-systemelementer setter inn disse valgfrie postene i kommunikasjon mellom jevnaldrende for å annonsere at de bruker EDNS. Dette gir en gjennomsiktig og bakoverkompatibel mekanisme, ettersom eldre klienter uten EDNS ganske enkelt vil ignorere den nye posttypen. DNS-deltakere skal bare sende utvidede (EDNS) forespørsler til DNS-servere hvis de er forberedt på å håndtere EDNS-svar; og DNS-servere skal bare bruke EDNS som svar på forespørsler som inneholder OPT-poster.

OPT-pseudo-recorden gir plass til opptil 16 tilleggsalternativer og utvider plassen for svarkoder. Den totale størrelsen på UDP-pakken og versjonsnummeret (for øyeblikket 0) er oppført i OPT-loggen. Et datafelt med variabel lengde gjør at mer informasjon kan inkluderes i fremtidige versjoner av protokollen. Den originale DNS-protokollen ga to typer etiketter, som er definert av de to første bitene av DNS-pakker: [ 2 ]

EDNS introduserer tag type 01 som en utvidet tag . De nederste 6 bitene av den første byten kan brukes til å definere opptil 63 nye utvidede tagger.

Eksempel

Et eksempel på en OPT-pseudo-record, som vist av verktøyet Domain Information Groper (DIG) :

;; OPT PSEUDOSEKJON: ; EDNS: versjon: 0, flagg: do; utp: 4096

Resultatet "EDNS: Versjon: 0" indikerer full overensstemmelse med EDNS0 [ 3 ] Resultatet "flags: do" indikerer "DNSSEC OK" [ 4 ]

Applikasjoner

EDNS er avgjørende for implementering av DNS Security Extensions ( DNSSEC ). [ 5 ]

Problemer

I praksis kan det oppstå vanskeligheter ved bruk av EDNS som krysser brannmurer , ettersom noen brannmurer antar en maksimal DNS-meldingslengde på 512 byte og blokkerer DNS-pakker som er lengre.

Innføringen av EDNS muliggjorde en ny type tjenestenektangrep , kalt DNS-forsterkning , ettersom EDNS letter svært store svarpakker sammenlignet med relativt små forespørselspakker.

Arbeidsgruppen IETF DNS Extensions (dnsext) jobber med en foredling av EDNS0, kalt rfc2671bis.

Referanser

  1. P. Vixie (august 1999). Internet Society, red. "RFC 2671, utvidelsesmekanismer for DNS (EDNS0)" (på engelsk) . Hentet 6. mai 2012 . 
  2. a b RFC 1035 , Domenenavn - Implementering og spesifikasjon, P. Mockapetris (november 1987)
  3. . IETF Network Working Group, august 1999, RFC 2671 : Extension Mechanisms for DNS (EDNS0), side 3, Full overensstemmelse med denne spesifikasjonen er angitt med versjon "0".
  4. . IETF Network Working Group, desember 2001, RFC 3225 : Støtte for DNSSEC Indication Resolution, side 3, Valgmekanismen for uttrykkelig varsling om klientens evne til å akseptere (hvis ikke forstå) DNSSEC-sikkerhets-RR-er det er ved å bruke den mest betydningsfulle biten av Z-feltet i OPT EDNS0-overskriften i spørringen. Denne biten er kjent som "DNSSEC OK" (DO) biten.
  5. RFC 4035 , DNS Security Extensions Protocol Modification , R. Arends, Telematica Instituut, 2005. Seksjon 4.1 EDNS-støtte