DNS bölge aktarımı

Bu makalenin bilgisayarlardaki içeriği kontrol edilmelidir (eylül 2016).

İyileştirin veya kontrol edilecek şeyleri tartışın . Pankartı yeni eklediyseniz, lütfen kontrol etmeniz gereken noktaları burada belirtin .

İşlem kodu anımsatıcı AXFR ile de bilinen DNS bölge aktarımı , bir tür DNS işlemidir . Bu, DNS verilerini içeren dağıtılmış veritabanlarını bir DNS sunucusu kümesi genelinde çoğaltmak için kullanılabilen birçok mekanizmadan biridir. Bölge aktarımı iki farklı şekilde yapılabilir: tam bölge aktarımı (AXFR) veya artımlı bölge aktarımı (IXFR). Modern DNS sistemleri tarafından sağlanan veritabanı çoğaltma mekanizmalarıyla rekabet eder.

Operasyon

AXFR işlemi (tam aktarım)

Bölge aktarımı , TCP üzerinden bir istemci-sunucu modu işleminde çalışır . İstemci (bağımlı veya bağımlı ), dağıtılmış veritabanının ( bölge ) bir kısmının bilgilerini , bunu sağlayan bir sunucudan (ana veya ana ) ister ( RFC 2136). Her bölge için her zaman bir Ana Birincil Sunucu vardır. Bu tanımlar, RFC 1035'in tanımlarını tamamlayıcı niteliktedir (birincil ve ikincil).

Bölge aktarımı , söz konusu bölgenin DNS SOA kaydının doğrulanmasıyla başlar ve bölge aktarımı işlemi sırasında dört parametresi kullanılır:

Seri numarası , veri versiyonu belirler
ikincil sunucunun master'ı tekrar sorguladığı süreyi saniye cinsinden belirleyen yenileme süresi (veya yenileme ),
Yedek sunucunun başarısız bir bölge aktarımından sonra ana sunucuyu tekrar yoklaması için geçmesi gereken süreyi saniye cinsinden belirleyen yenileme girişimleri (veya yeniden deneme ) süresi,
Ardı ardına gelen bölge aktarım hatalarında ikincil sunucunun verinin süresinin dolduğunu düşünmesi gereken süreyi belirleyen sona erme süresi (veya sona erme ) (bağımlı sunucu artık bölgenin etki alanı adlarını çözmez).

Bu kontrol sırasında, ana bölgenin seri numarası (sürüm), bağımlı bölgenin son kopyasıyla aynı (veya daha düşük) ise, herhangi bir değişiklik yapılmadığı için transfer durur. . Bu sürüm daha yeniyse (ana birimin seri numarası, ikincil birimin bölge kopyasından daha büyükse), ikincil birim, bölge aktarım talebini bu şekilde yapar.

Bölge aktarımının kendisi , ana sunucuya TCP bağlantısında AXFR'ye (değer 252) karşılık gelen QTYPE (istek türü veya sorgu türü ) ile istemci tarafından bir DNS isteği (işlem kodu 0) göndererek başlar . Sunucu, bölgenin tüm kayıtlı kaynaklarını (RRdata) içeren bir dizi yanıt mesajı ile yanıt verir. İlk yanıt, bölgenin SOA kaydını içerir, diğer kayıtlar önceden tanımlanmış bir sırayla takip etmez. Transferin sonu, SOA kaydı yeniden gönderilerek belirtilir.

Bazı bölge aktarım istemcileri, bir bölge aktarımından önce bir SOA isteği gerçekleştirmek için standart çözünürlük istemcilerini kullanır. Bu istemciler, bölge aktarımı gerekene kadar sunucuya bir TCP bağlantısı açmazlar. Her neyse, TCP, bölge aktarımı gibi normal bir DNS işlemini gerçekleştirmek için protokol olarak kullanılabilirken, diğer bölge aktarım istemcileri ilk SOA talebini ve ardından tek bir bölgede bölge aktarımını gerçekleştirebilir, TCP bağlantısı. Bu istemciler, bölge aktarımından önce SOA isteği için ana sunucuda sistematik olarak bir TCP bağlantısı açar.

IXFR işlemi (artımlı aktarım)

Artımlı bölge aktarımı, yalnızca aşağıdaki noktalarda tam bölge aktarımından farklılık gösterir:

bağımlı, QTYPE AXFR yerine QTYPE IXFR'yi (değer 251) kullanır ve sunucuya, bölgenin doğru olduğunu düşündüğü sürümünü (seri numarası) belirtir (önceki istek SOA'da yeni aldığı) ),
Slave, sahibi olduğu bölgenin kopyası için SOA girişini master'a geri gönderir,
ana sunucu daha sonra AXFR protokolüne göre yanıt verebilir ve tüm bölgeyi daha önce açıklandığı gibi veya IXFR artımlı protokolüne göre aktarabilir. İkincisi, bağımlı tarafından tutulan son bölgenin seri numarası ile şu anda ana birim tarafından tutulan arasında ardışık seri numaraları (sürümlerin) sırasına göre bölgenin (RRdata) kaydedilmiş kaynaklarına yapılan değişikliklerin listesini içerir. . Değişiklikler, biri silinecek kayıtlar, diğeri eklenecek olanlar için olmak üzere iki listeden oluşur.

BİLDİR işlemi

Bir bölge transferi tamamen bağımlı tarafından başlatılır. Bu, bölge aktarımlarını önce bölge (boş bölge) için bir kayıt olmadığında, ardından bölgenin SOA kaydında belirtilen yenileme , yeniden deneme ve sona erme değerlerini izleyen düzenli aralıklarla zamanlar .

Bununla birlikte, bazı ana sunucular, bildirilen bağımlı sunuculara bir BİLDİRİM mesajı gönderebilir ve ana sunucu yeniden başlatma veya yeniden yüklemeden sonra bölgenin seri numarasında bir değişiklik tespit eder etmez, ikincil sunucu tarafından planlanan sürelerin dışında bir bölge transferine neden olabilir. .

güvenlik

TSIG ( RFC 2845) kullanımı , ana-bağımlı değişimin doğrulanmasını ve bağımlı sunucu tarafından alınan verilerin bütünlüğünün sağlanmasını mümkün kılar. Bu mekanizma, bir bölgeden sorumlu kişinin, bağımlı sunucu tarafından sağlanan verilerin gerçekten doğru ana sunucudan gelmesini ve değişim sırasında üçüncü bir taraf tarafından değiştirilmediğinden emin olmasını sağlar.

DNS BIND uygulaması , bu mekanizmanın kullanımına izin verir.

Operasyonel sorunlar

Seri numarasını değiştirme

Bölge aktarımının gerçekleştirilip gerçekleştirilmeyeceği kararı, yalnızca bölgenin SOA kaydının seri numarasına bağlıdır. Bu seri numaraları bir yönetici tarafından elle yapılandırılırsa, her değişiklikte seri numarasını güncellemeye ve her zaman arttığına, aksi takdirde yayılmayacağına dikkat etmelidir . Bu süreç kolaylıkla hatalar oluşturabilir. İyi bir uygulama (hiçbir şekilde zorunlu değildir ve her zaman takip edilmemektedir), seri numarasını YYYYMMDDSS biçiminde kaydetmekten ibarettir; burada YYYY yıl, MM ay, DD gün ve SS, değişiklik yapılırken artırılan bir sayıdır. gün.

Bazı DNS sistemleri, bölge dosyasının son değiştirilme tarihine göre ( djbdns durumu ) bu seri numarasını otomatik olarak üretir . Sorumluluk işletim sistemine ve senkronizasyonuna aktarılır. Dosya, örneğin bir yorum eklemek için düzenlenirse, hiçbir değişiklik yapılmazken seri numarası otomatik olarak değiştirilir.

Seri numarasının (ve bölge aktarımının) paradigması, tek başına tüm bağımlı sunucular için bölgenin referansını sağlayan tek bir ana sunucuya sahip olmayı gerektirmesidir (bir bağımlı sunucu, başka bir bağımlı sunucunun yöneticisi olabilir). Bazı DNS sistemleri , belirli SQL veya LDAP veritabanlarının ( openldap , Active Directory ) çok yöneticili çoğaltma mekanizmalarını gizlice kullanarak bölge aktarımını ortadan kaldırmayı mümkün kılar . Bununla birlikte, bu tür uygulamaların çok bant genişliği yoğun olduğu ve hassas zaman senkronizasyonu gerektirdiği belirtilmelidir.

Seri numaralarının karşılaştırılması

Seri numaralarının karşılaştırılması, RFC 1982'de açıklanan aritmetik seri numaralarına (inç) dayanmalıdır . Ancak RFC 1034, açıkça ifade edilmez, bu da tüm bağımlı birimlerin aynı kriterlere göre bölge aktarımını tetiklemediği anlamına gelir.

Birden Fazla Kayıtlı Kaynak (RR)

Orijinal veri aktarım işleminde, benzersiz bir alan adı için her kayıt grubu (RR), sunucudan istemciye bant genişliği açısından verimsiz olan ayrı bir DNS mesajında aktarılır. Bazı DNS sistemleri, verileri sıkıştırarak ve aşağıdaki gibi ekleyerek bu sorunu hafifletir:

kullanımı ek kayıtların ( ek bölüm işleme dahil etmek için) tutkal girişleri SRV MX veya NS tip talepleri ile aynı zamanda,
boyut izin veriyorsa, bir alan adıyla ilgili tüm kayıtların tek bir DNS yanıtında gruplanması.

Daha sonra bu sistemler, standarda kesinlikle uyan veya belirli bir seçeneği uygulayan sistemlerle uyumsuz hale gelir.

Notlar ve referanslar

Ayrıca görün

birincil DNS (RR) kayıtları .

Yorum İstekleri (RFC)

RFC 1034 Etki Alanı Adları - Kavramlar ve Tesisler. (AXFR'yi tanımlar)
RFC 1995 DNS'de Artımlı Bölge Aktarımı. (IXFR'yi tanımlar)
RFC 1996 Bölge Değişikliklerinin Hızlı Bildirimi için Bir Mekanizma (DNS BİLDİRİMİ)
draft-ietf-dnsext-axfr-clarify DNS Zone Transfer Protocol (AXFR) internet taslağı