DNS-zonöverföring

DNS-zonöverföring , även ibland känd som den inducerande DNS-frågan AXFR , är en typ av DNS- transaktion . Det är en av många tillgängliga mekanismer för administratörer att replikera DNS-databaser över en uppsättning DNS-servrar .

En zonöverföring använder Transmission Control Protocol (TCP) för transport och tar formen av en klient-servertransaktion . Klienten som begär en zonöverföring kan vara en sekundär server som begär data från en primär server . Den del av databasen som replikeras är en zon .

Drift

Zonöverföring består av en inledning, följt av själva dataöverföringen. Ingressen omfattar en uppslagning av Start of Authority (SOA) resursposten för "zonens apex", noden för DNS-namnområdet som är överst i "zonen". Fälten i denna SOA-resurspost, i synnerhet "serienumret", avgör om den faktiska dataöverföringen överhuvudtaget behöver ske. Klienten jämför serienumret för SOA-resursposten med serienumret i den sista kopian av resursposten som den har. Om serienumret för posten som överförs är större, anses data i zonen ha "förändrats" (på något sätt) och den sekundära fortsättningen för att begära den faktiska zondataöverföringen. Om serienumren är identiska, anses data i zonen inte ha "förändrats", och klienten kan fortsätta att använda den kopia av databasen som den redan har, om den har en sådan.

Själva dataöverföringsprocessen börjar med att klienten skickar en fråga (opkod 0) med den speciella frågetypen AXFR (värde 252) över TCP-anslutningen till servern. Även om DNS tekniskt stöder AXFR över User Datagram Protocol (UDP), anses det inte acceptabelt på grund av risken för förlorade eller förfalskade paket. Servern svarar med en serie svarsmeddelanden, som omfattar alla resursposter för varje domännamn i "zonen". Det första svaret omfattar SOA-resursposten för zonens spets. Övriga uppgifter följer i ingen angiven ordning. Slutet på data signaleras av servern som upprepar svaret som innehåller SOA-resursposten för zonens apex.

Vissa zonöverföringsklienter utför SOA-uppslagningen av ingressen med hjälp av deras systems normala DNS-förfrågelösningsmekanism. Dessa klienter öppnar inte en TCP-anslutning till servern förrän de har bestämt att de behöver utföra själva dataöverföringen. Men eftersom TCP kan användas för normala DNS-transaktioner, såväl som för zonöverföring, utför andra zonöverföringsklienter SOA-uppslagspreamblen över samma TCP-anslutning som de sedan (kan) utföra den faktiska dataöverföringen. Dessa klienter öppnar TCP-anslutningen till servern innan de ens utför ingressen.

Det föregående beskriver full zonöverföring. Inkrementell zonöverföring skiljer sig från full zonöverföring i följande avseenden:

  • Klienten använder den speciella QTYPE IXFR (värde 251) istället för AXFR QTYPE.
  • Klienten skickar SOA-resursposten för zonens apex som den för närvarande har, om någon, i IXFR-meddelandet, och låter servern veta vilken version av "zonen" den tror är aktuell.
  • Även om servern kan svara på normalt AXFR-sätt med fullständig data för zonen, kan den också istället svara med en "inkrementell" dataöverföring. Denna sistnämnda omfattar listan över ändringar av zondata, i zonens serienummerordning, mellan versionen av zonen som klienten rapporterade till servern att ha och versionen av zonen som är aktuell på servern. Ändringarna omfattar två listor, en med resursposter som raderas och en med resursposter som infogas. (En ändring av en resurspost representeras som en radering följt av en infogning.)

Zonöverföring är helt klientinitierad. Även om servrar kan skicka ett NOTIFY-meddelande till klienter (som de har informerats om) närhelst en ändring av zondata har gjorts, är schemaläggningen av zonöverföringar helt under kontroll av klienterna. Klienter schemalägger zonöverföringar initialt, när deras databaser är tomma, och därefter med jämna mellanrum, i ett mönster som kontrolleras av värdena i fälten "refresh", "försök igen" och "expire" i SOA-resursposten för zonens apex.

Begränsningar

Även om det är standardiserat, full-zon transfer beskrivs som en av de möjliga databasreplikeringsmekanismerna i RFC 1034 och RFC 5936 (inkrementell zonöverföring beskriven i RFC 1995), är zonöverföring den mest begränsade av dessa databasreplikeringsmekanismer. Zonöverföring fungerar i termer av " trådformat " resursposter, dvs resursposter när de överförs med hjälp av DNS-protokollet. Schemat för resursposter i trådformat kanske inte är identiskt med databasschemat som används av själva DNS-servrarnas bakändar .

Driftsproblem

Serienummer ändras

Inledningsdelen av zonöverföring förlitar sig på serienumret, och endast serienumret, för att avgöra om en zons data har ändrats och således om den faktiska dataöverföringen krävs. För vissa DNS-serverpaket underhålls serienumren för SOA-resursposter av administratörer för hand. Varje redigering av databasen innebär att två ändringar görs, en till posten som ändras och den andra till zonens serienummer. Processen kräver noggrannhet: administratören kan glömma att ändra serienumret eller ändra det felaktigt (minska det). RFC 1912 (avsnitt 2.2 SOA-poster) rekommenderar att du använder värdet ÅÅÅÅMMDDnn som nummer (ÅÅÅÅ=år, MM=månad, DD=dag, nn=revisionsnummer). Detta kommer inte att svämma över förrän år 4294.

Vissa DNS-serverpaket har övervunnit detta problem genom att automatiskt konstruera serienumret från den senaste ändringens tidsstämpel för databasfilen på disken. Detta är fallet för djbdns till exempel. Operativsystemet säkerställer att den senaste ändringens tidsstämpel uppdateras varje gång en administratör redigerar databasfilen, vilket i praktiken automatiskt uppdaterar serienumret och därmed befriar administratörer från behovet av att göra två redigeringar (på två olika ställen) för varje enskild ändring.

Paradigmet för databasreplikering för vilket serienummerkontrollen (och faktiskt zonöverföringen i sig) är utformad, vilket innebär att en enda central DNS-server håller den primära versionen av databasen med alla andra DNS-servrar som bara innehåller kopior, stämmer helt enkelt inte överens. det för många moderna DNS-serverpaket. [ citat behövs ] Moderna DNS-serverpaket med sofistikerade databasbackends som SQL- servrar och Active Directory tillåter administratörer att göra uppdateringar av databasen på flera ställen (sådana system använder multimasterreplikering), med databasbackends egen replikeringsmekanismhantering replikeringen till alla andra servrar. Detta paradigm matchar helt enkelt inte det för ett enda, centralt, monotont ökande antal för att registrera förändringar, och är därför oförenligt med zonöverföring i stor utsträckning. [ citat behövs ] Moderna DNS-serverpaket med sofistikerade databasbackends skapar ofta ett "shim"-serienummer, som simulerar existensen av en enda central plats där uppdateringar görs, men detta är i bästa fall ofullständigt.

Lyckligtvis, av detta och flera skäl som beskrivs senare, använder DNS-servrar som använder sådana sofistikerade databasbackends i allmänhet sällan zonöverföring som sin databasreplikeringsmekanism i första hand, och använder vanligtvis istället de mycket överlägsna distribuerade databasreplikeringsmekanismer som backendarna själva tillhandahålla. [ citat behövs ]

Jämförelser av serienummer

Serienummerjämförelser är avsedda att använda serienummeraritmetik enligt definitionen i RFC 1982. Detta var dock inte tydligt specificerat i RFC 1034, vilket resulterar i att inte alla klienter utför serienummerkontrollen, i ingressen, på samma sätt. Vissa klienter kontrollerar bara att serienumret som tillhandahålls av servern skiljer sig från det som klienten känner till, eller inte är noll. Andra klienter kontrollerar att serienumret som tillhandahålls av servern ligger inom ett givet intervall för det serienummer som klienten redan känner till. Ytterligare andra klienter utför fortfarande den senare kontrollen och kontrollerar dessutom att serienumret som tillhandahålls av servern inte är noll.

Flera resursposter

Ursprungligen överfördes i själva dataöverföringen varje uppsättning resursposter för ett enda domännamn och typ i ett separat svarsmeddelande från servern till klienten. Detta är dock ineffektivt, och vissa DNS-serverprogramvara implementerade optimeringar, inriktade på att tillåta svarskomprimeringsmekanismen i DNS-protokollet att minska de totala bandbreddskraven för dataöverföringar, såsom:

  • utföra "ytterligare sektionsbearbetning" för att inkludera alla "lim"-resurspostuppsättningar i samma svar som en NS-, SRV- eller MX-resurspostuppsättning
  • samla alla resurspostuppsättningar som hänför sig till ett enda domännamn och skicka dem, om de passar, i ett enda svar

Vissa klienter skrevs för att endast förvänta sig det ursprungliga svarsformatet och skulle misslyckas med att utföra dataöverföring om sådana optimeringar användes. Flera DNS-serverpaket har alltså en konfigurationsinställning som tillåter administratörer att specificera användningen av "single answer format"-svar för de klienter som kräver det.

Exponering av data

Uppgifterna i en DNS-zon kan vara känsliga ur en driftssäkerhetsaspekt. Detta beror på att information som servervärdnamn kan bli allmänt känd, som kan användas för att upptäcka information om en organisation och till och med ge en större attackyta . I juni 2017 aktiverade registraren ansvarig för ryska toppdomäner av misstag DNS-zonöverföringar via AXFR vilket ledde till att 5,6 miljoner poster av misstag exponerades.

År 2008 beslutade en domstol i North Dakota, USA, att utföra en zonöverföring som en obehörig utomstående för att få information som inte var allmänt tillgänglig utgör ett brott mot North Dakotas lag.

Se även

externa länkar

Information om säkerhetsstandarder

Relaterad begäran om kommentarer

Hämtad från " https://en.wikipedia.org/w/index.php?title=DNS_zone_transfer&oldid=1124514836 "