Bir CNAME kaydı neden bir alanın tepesinde (aka root) kullanılamıyor?

Bu, bölgelerin apekslerinde (veya köklerinde) CNAME'ler hakkında Kanonik bir Soru .

Bir CNAMEalanın zirvesinde kayıtların bir tabu uygulaması olduğu nispeten yaygın bir bilgidir .

Örnek: example.com. IN CNAME ithurts.example.net.

En iyi durumda, senaryo sunucusu yazılımı yapılandırmayı yüklemeyi reddedebilir ve en kötü durumda bu yapılandırmayı kabul edebilir ve example.com için yapılandırmayı geçersiz kılabilir.

Geçenlerde bir web barındırma şirketimden, alan adımızı zirveye yeni bir sicile CNAME olarak vermemiz gereken bir işletme birimine talimatlar ilettim. Bunun BIND ye verildiğinde intihar olayı olacağını bilerek, onlara uymayacağımızı ve bunun genel olarak ranza tavsiyesi olduğunu öğrendim. Web barındırma şirketi, RFC'leri standart olarak tanımlamanın tamamen yasak olmadığı ve yazılımlarının onu desteklediği fikrini aldı. Eğer tepeyi CNAME olarak tanımlayamazsak, onların önerileri hiçbir zaman tepe kaydının olmamasıydı ve yönlendirici bir web sunucusu sağlamıyorlardı. ...Ne?

Çoğumuz RFC1912'nin bu konuda ısrar ettiğini biliyoruz A CNAME record is not allowed to coexist with any other data., ancak burada kendimize karşı dürüst olalım, RFC'nin yalnızca Bilgilendirici olduğunu. Uygulamayı yasaklayan bir söz vermeyi bildiğim en yakın şey RFC1034'ten :

Bir düğümde bir CNAME RR mevcutsa, başka veri bulunmamalıdır; bu, kanonik bir ad ve diğer adı için verinin farklı olamamasını sağlar.

Maalesef, "yapmamalı" nın "yapmamalı" ile aynı olmadığını bilmek için yeterince uzun zamandır sektörde bulundum ve bu, çoğu yazılım tasarımcılarının kendilerini asması için yeterli ip. Bir smaçla kısa ve öz bir bağlantıya sahip olan herhangi bir şeyin zamanımı boşa harcayacağını bilerek, şirketin, yaygın olarak kullanılan yazılımı uygun şekilde ifşa etmeden kırabilecek yapılandırmaları önermek için azarlamaktan kaçmasına izin verdim.

Bu bizi Q & A'ya getiriyor. Bir keresinde apeks CNAME'lerin deliliği hakkında gerçekten teknik bilgi sahibi olmamı ve genellikle birileri konuya yazarken yaptığımız gibi bu konunun etrafında durmamasını istiyorum. RFC1912 , burada düşünmediğim kadar geçerli olan herhangi bir Bilgilendirici RFC'de olduğu gibi, limitler dışındadır . Bu bebeği susturalım.

CNAMEkayıtları alındı aslen aynı kaynak kaynak için tek bir "kurallı adı" diğer adı edilecek sağlayan birden çok ad izin vermek için oluşturuldu. Ad tabanlı sanal barınmanın ortaya çıkışıyla, bunun yerine, genel bir IP adresi diğer adı biçimi olarak kullanmak yaygınlaştı. Ne yazık ki, bir web barındırma arkaplanından gelen çoğu kişi , DNS’de , hiç niyeti olmayan eşdeğerliğiCNAME belirtmek için kayıtlar beklemektedir . Tepe açık olan kayıt tiplerini içerir olmayan bir standart ana kaynak (tanımlanmasında kullanılan , bir temel düzeyde bir standart kırılmadan ad verilmiş değildir). (özellikle bölge kesimleri ile ilgili olarak )NSSOA

Ne yazık ki, orijinal DNS standardı, yönetim organları, tutarlı davranışı tanımlamak için açık sözlü yayınlamanın gerekli olduğunu fark etmeden önce yazılmıştır ( RFC 2119 ). Oluşturmak için gerekli olan RFC 2181 nedeniyle belirsiz metinlerinde birkaç köşe durumlarda netleştirmek için, ve güncel verbiage bir o daha net hale getirir CNAME olamaz standardını bozmadan apeks aliasing elde etmek için kullanılabilir.

6.1. Bölge yetkisi

Bir bölge için yetkili sunucular, bölgenin başlangıcına ilişkin NS kayıtlarında numaralandırılır; bunun yanı sıra, bir Otorite Başlangıcı (SOA) kaydı, her bölgedeki zorunlu kayıtlardır. Böyle bir sunucu, başka bir bölgede olmayan bir bölgedeki tüm kaynak kayıtları için yetkilidir. Bir zon kesiğini gösteren NS kayıtları, o alt bölgenin kökenine veya diğer alt alanlarına ait diğer kayıtlar gibi yaratılan alt bölgenin mülküdür. Bir bölge için bir sunucu, NS'yi içeren başka bir bölgedeki adlarla ilgili sorgular için yetkili cevaplar vermemelidir ve A ve diğer bölge için bir sunucu olmadıkça, A, bir bölge kesimindeki kayıtları kaydeder.

Bu, kayıtların zorunlu olduğunu SOAve NSkayıtların zorunlu olduğunu ancak Aburada görünen diğer türlerle ilgili hiçbir şey söylemediğini belirler . O zaman bunu alıntılamam gereksiz olabilir, ancak bir an için daha alakalı hale gelecektir.

RFC 1034 , CNAMEdiğer kayıt türlerinin yanında olduğu zaman ortaya çıkabilecek problemlerde bir miktar belirsizdi . RFC 2181 belirsizliği ortadan kaldırır ve açıkça yanlarında bulunmalarına izin verilen kayıt türlerini belirtir:

10.1. CNAME kaynak kayıtları

DNS CNAME ("kanonik ad") kaydı, diğer adla ilişkilendirilen kanonik adı sağlamak için var. Herhangi bir takma ad için yalnızca bir tane kanonik ad olabilir. Bu ad, genellikle DNS'de başka bir yerde bulunan bir ad olmalıdır; ancak, DNS'de tanımsız eşlikli adla birlikte takma adlar için bazı nadir uygulamalar vardır. Bir takma ad (bir CNAME kaydının etiketi), DNSSEC kullanımdaysa, SIG, NXT ve KEY RR'lere sahip olabilir, ancak başka veri içermeyebilir. Yani, DNS'deki herhangi bir etiket için (herhangi bir etki alanı adı) aşağıdakilerden biri tam olarak doğrudur:

• isteğe bağlı olarak SIG, NXT ve KEY RR'lerin eşlik ettiği bir CNAME kaydı bulunmaktadır.
• bir veya daha fazla kayıt var, hiçbiri CNAME kaydı değil,
• Bu ad var, ancak hiçbir türde ilişkili RR'ye sahip değil.
• isim hiç mevcut değil.

Bu bağlamda "takma ad", CNAMEkaydın sol tarafına atıfta bulunuyor . Madde işaretli liste, a SOAve NS, Akayıtlarının, CNAMEaynı zamanda görünen bir düğümde görülemeyeceğini açıkça belirtir . Bunu bölüm 6.1 ile birleştirdiğimizde, CNAMEzorunlu SOAve NSkayıtlarla birlikte yaşamak zorunda kalacakları için, bir zirvede bulunmak mümkün değildir .

(Bu işi yapıyor gibi gözüküyor, ancak birinin ispat etmek için daha kısa bir yolu varsa, lütfen ona bir çatlak verin.)

Güncelleme:

Görünüşe göre, daha yakın tarihli bir karışıklık Cloudflare’nin son zamanlarda A rekorlarını sentezleyeceği alanların tepesinde yasadışı bir CNAME kaydının tanımlanmasına izin verme kararından geliyor gibi görünüyor . Bağlantılı makale tarafından tarif edildiği gibi "RFC uyumlu", Cloudflare tarafından sentezlenen kayıtların DNS ile iyi bir şekilde oynatılacağı gerçeğini ifade eder. Bu tamamen özel bir davranış olduğu gerçeğini değiştirmez.

Bence bu, daha büyük DNS topluluğuna bir kötüye kullanımdır: aslında bir CNAME kaydı değildir ve insanları, diğer yazılımların izin vermediği için yetersiz olduğuna inanmak konusunda yanıltmaktadır. (sorumun gösterdiği gibi)

İnternet Sistemleri Konsorsiyumu yakın zamanda CNAME hakkında bir bölgenin tepesinde, bu kısıtlamanın neden mevcut olduğunu ve çeşitli alternatifleri içeren bir yazı yayınladı . Bu ne yazık ki yakında herhangi bir zamanda değişmesi muhtemel değildir:

Dünyadaki tüm>> DNS sunucusu uygulamalarını aynı anda değiştirmeden, özel CNAME kaydının nasıl kullanılacağını değiştiremeyiz. Bunun anlamı, anlamının ve yorumunun DNS protokolünde kesin olarak tanımlanmış olmasıdır; mevcut tüm DNS istemcisi ve sunucusu uygulamaları bu şartnameye uygundur. Şu anda çalışan tüm DNS çözümleyicilerini aynı anda değiştirmeden CNAME'nin yetkili sunucularda nasıl kullanıldığını 'gevşetme' denemesi, ad çözümlemesinin bozulmasına neden olacaktır (ve web ve e-posta hizmetleri, 'rahat' yetkili sunucu çözümleri uygulayan kuruluşlar için zaman zaman kullanılamaz hale gelecektir.

Ama umut var:

Halen tartışılmakta olan başka bir potansiyel çözüm, tarayıcıların tepesinde bulunabilecek yeni bir dns kaynak kaydı türü ekleyecektir. Bu, http istekleri için uygulamaya özel bir ana bilgisayar adı olabilir (MX'in çalışma biçimine benzer).

Artıları: Bu tamamen DNS tasarımı ile tutarlıdır.
Eksileri: Bu henüz mevcut değil ve bir tarayıcı istemcisi güncellemesi gerektiriyor.

Bölgenin tamamını yeniden yönlendiriyorsanız, DNAME kullanmanız gerekir. RFC 6672'ye göre ,

DNAME RR ve CNAME RR [RFC1034], sorgulanan alan adından farklı bir alan adına karşılık gelen verileri (potansiyel olarak) döndürmeye neden olur. İki kaynak kaydı arasındaki fark, CNAME RR'nin sahibindeki verilerin aranmasını başka bir tek adaya yönlendirmesidir; oysa bir DNAME RR, sahibinin adının soyundan gelen verilerin aranmasını farklı bir (tek) düğümü altındaki karşılık gelen adlara yönlendirir. ağaç.

Örneğin, "foo.example.com" alan adı için bir bölgeye bakın (bkz. RFC 1034 [RFC1034], Bölüm 4.3.2, adım 3) ve "example.com" adresinde bir DNAME kaynak kaydı bulundu "example.com" altındaki tüm sorguların "example.net" e yönlendirilmesi. Arama işlemi "foo.example.net" in yeni sorgu adı ile 1. adıma dönecektir. Sorgu adı "www.foo.example.com" olsaydı, yeni sorgu adı "www.foo.example.net" olur.