Soru Neden bir alanın apeksinde (aka root) bir CNAME kaydı kullanılamaz?


Bu bir Kanonik Soru CNAME'ler hakkında bölgelerin apisleri (veya kökleri) hakkında

Bu nispeten yaygın bilgi CNAME Bir alanın tepesindeki kayıtlar tabu bir uygulamadır.

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

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

Son zamanlarda, bir webhosting firmasının yeni bir rekor için alanımızın apeksini CNAME'ye ihtiyaç duyduğumuz bir iş birimine talimatlar verdim. BIND'e verildiğinde bunun bir intihar planı olacağını bilerek, onlara uymayacağımızı ve bunun genel olarak ranza tavsiyesi olduğunu söylemiştim. Webhosting şirketi, standart tanımlayıcı RFC'ler tarafından açıkça yasaklanmadıklarını ve onların yazılım bunu destekler. Apex'i CNAME yapamazsak, önerileri hiç bir apeks kaydına sahip değildi ve yönlendirici bir web sunucusu sağlamayacaktı. ...Ne?

Çoğumuz bunu biliyoruz RFC1912 ısrar ediyor A CNAME record is not allowed to coexist with any other data.ama burada kendimize dürüst olalım, RFC sadece bilgilendirme. Uygulamayı yasaklayan en yakın olanı bildiğim en yakın RFC1034:

Bir düğümde bir CNAME RR varsa, başka bir veri bulunmamalıdır.   mevcut; Bu, kanonik ad ve diğer adlar için verilerin olmasını sağlar   farklı olamaz.

Ne yazık ki, “olmamalı” nın “olmamalı” ile aynı şey olduğunu bilecek kadar uzun bir süredir vardım ve bu da çoğu tasarımcı için kendilerini asmak için yeterli ipti. Slam dunk'una özlü bir bağlantının kısa bir zamanının benim zamanımı boşa harcayacağını bilerek, firmanın, yaygın olarak kullanılan yazılımı uygun bir açıklama olmadan bozabilecek konfigürasyonları önerdiği için azarlamaktan vazgeçtim.

Bu bizi Q & A'ya getiriyor. Bir kereliğine almamızı isterdim. Gerçekten mi Apex CNAME'lerin çılgınlığıyla ilgili teknikler ve konuyla ilgili olarak birileri konuyla ilgili yayınlar yapmazız. RFC1912 Burada, benim düşünmediğim diğer herhangi bir bilgilendirme RFC'si olduğu gibi limitler kapalıdır. Hadi bebeği kapatalım.


108
2017-07-19 10:53


Menşei


RFC 1034, RFC 2119'dan önce oldukça fazla zaman ve deneyim sunar. - Michael Hampton♦


Cevaplar:


CNAME kayıtlar vardı aslında Kaynak için tek bir "kanonik adı" ile aynı kaynağın takılmasını sağlayan birden çok adaya izin vermek için oluşturuldu. Adına dayalı sanal barındırma ile birlikte, onları, IP adresi takma adının genel bir biçimi olarak kullanmak için yaygın hale gelmiştir. Ne yazık ki, web barındırma arkaplanından gelen çoğu kişi beklemektedir CNAME belirtmek için kayıtlar DNS'de denklikki bu asla niyet değildi. Apex, açıkça kayıt tiplerini içerir değil bir kurallı ana bilgisayar kaynağının tanımlanmasında kullanılır (NS, SOA) standardı temel seviyede bozmadan taklit edilemez. (özellikle de bölge keser)

Ne yazık ki, standart yönetim standartları, tutarlı davranışları tanımlamak için açık sözlü ifadenin gerekli olduğunu fark etmeden önce orijinal DNS standardı yazılmıştır.RFC 2119). Yaratmak gerekliydi RFC 2181 belirsiz ifadeler nedeniyle çeşitli köşe durumlarını açıklığa kavuşturmak ve güncellenmiş verbiyeler bunu daha net hale getirmektedir. CNAME  yapamam standart kırmadan apeks takma elde etmek için kullanılabilir.

6.1. Bölge yetkisi

Bir bölge için yetkili sunucular NS kayıtlarında numaralandırılır      Otorite Başlangıcı ile birlikte, bölgenin kökeni için      (SOA) kaydı, her bölgedeki zorunlu kayıtlardır.  Böyle bir sunucu      içinde olmayan bir bölgedeki tüm kaynak kayıtları için yetkilidir      başka bir bölge. Bir bölge kesimini gösteren NS kayıtları      Çocuk bölgesi mülkiyeti,      o çocuk bölgesinin kökeni veya herhangi bir alt alanı. Bir sunucu için      ilgili sorgularla ilgili yetkili cevapları döndürmemelidir      NS ve belki A, kayıtları içeren başka bir bölgedeki isimler      diğer bölgeler için bir sunucu olmadıkça, bir bölgedeki kesim      bölge.

Bu kurar SOA ve NS Kayıtlar zorunlu, ama hakkında hiçbir şey söylemiyor A veya burada görünen diğer tipler. Bunu teklif ettiğim için gereksiz görünebilir, ama bir anda daha alakalı hale gelecektir.

RFC 1034 ne zaman ortaya çıkabilecek sorunlar hakkında biraz belirsiz CNAME diğer kayıt türlerinin yanında bulunur. RFC 2181 belirsizliği ortadan kaldırır ve yanlarında bulunmasına izin verilen kayıt türlerini açıkça belirtir:

10.1. CNAME kaynak kayıtları

Sağlamak için DNS CNAME ("canonical name") kaydı bulunmaktadır.      bir takma adla ilişkilendirilmiş kurallı ad. Sadece bir tane olabilir      herhangi bir takma ad için böyle kurallı ad. Bu isim genel olarak olmalı      Bazı yerlerde nadir olsa da, DNS’de başka bir yerde bulunan bir ad      ilişikteki kanonik isimle takma adlar için başvurular      DNS'de tanımlanmamış. Diğer ad (CNAME kaydının etiketi),      DNSSEC kullanılıyorsa, SIG, NXT ve KEY RR'leri var, ancak      diğer veri.  Yani, DNS'deki herhangi bir etiket için (herhangi bir alan adı)      Aşağıdakilerden tam olarak doğrudur:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

Bu bağlamda "takma ad", sol tarafın CNAME kayıt. Madde işaretli liste, bunu açıkça açıkça belirtir. SOA, NS, ve A Kayıtlar bir düğümde görülemez. CNAME ayrıca görünür. Bunu bölüm 6.1 ile birleştirdiğimizde, bir CNAME Zorunlu yanı sıra yaşamak zorunda olduğu gibi apekste var olmak SOA ve NS kayıtları.

(Bu iş gibi görünüyor, ama eğer birisi ispat için daha kısa bir yol varsa, lütfen ona bir çatlak verin.)


Güncelleştirme:

Görünen o ki daha yeni karışıklık geliyor Cloudflare'nın son kararı A kayıtlarının sentezini yapacakları alanların tepe noktasında tanımlanacak yasadışı bir CNAME kaydına izin vermek. Bağlantılı makalede anlatıldığı gibi "RFC uyumlu", Cloudflare tarafından sentezlenen kayıtların DNS ile iyi oynayacağı gerçeğini ifade eder. Bu tamamen özel bir davranış olduğu gerçeğini değiştirmez.

Benim düşünceme göre bu, daha büyük bir DNS topluluğuna karşı bir kıtlıktır: aslında bir CNAME kaydı değildir ve insanları, diğer yazılımların buna izin vermemek için eksik olduğuna inanmaları konusunda yanlış yönlendirir. (benim sorumun gösterdiği gibi)


87
2017-07-19 10:53



Bu kanıtı kabul ediyorum ve bu iki aşamalı kanıt yolunun özellikle uzun veya karışık olduğunu düşünmüyorum. (1. bölge apeksinin en azından olması garantili SOA + NS kayıtlar, 2. CNAME kayıtların diğer verilerle bir arada bulunmasına izin verilmez) - Håkan Lindqvist
Genel olarak, bence bu çok iyi bir açıklama. Herhangi bir şey eklenebilirse, bunun ne olacağını daha açıklayacağını düşünüyorum. CNAME Aslında kayıt, muhtemelen en yaygın yanlış anlaşılan kayıt türü olduğu anlamına gelir. Her ne kadar bu meselenin ötesinde olsa da, bence bu SSS olmanın çoğu kişinin (çoğu?) Doğru bir şekilde anlaşılmamasının doğrudan bir sonucudur. CNAME. - Håkan Lindqvist
@Denis Bir yorum içinde kapsamlı bir şekilde cevaplanamaz. En kısa cevap, RFC'leri (1034, 1035) okumanız ve tavsiyelerin ne olduğu, sevk için gerekli davranışların ne olduğu (YETKİ, SOA kayıt varlığı, vb.) Ve neden bu tür bir anlayışa sahip olmanız gerektiğidir. "yönlendirme-az" takma, DNS sunucularının işlevsel düzeydeki birçok beklentisini ihlal eder. Ve bu sadece başlamak için. Bu soru burada iyi bir konu değildir çünkü spekülatiftir ve düzgün tasarlanmış, standartlara uygun bir DNS sunucusuyla çalışmayla karşılaşabileceğiniz bir soruna kök salmaz. - Andrew B
@DenisHowe kısaca: NS ve SOA kayıtları olmadan "alan" diye bir şey yoktur. bunlar isteğe bağlı olmayan kayıtlardır. - hakamadare
@Ekevoo One, benimsenmesi gereken HTTP uygulamalarını tartışabilir SRV bunun yerine, bu da bir sorun değil. Sorun burada tartışılanla sınırlı değil; CNAME popüler inancın aksine, ihtiyaç duyulan şey için mükemmel bir eşleşme değildir. Sonunda, olarak CNAME İnsanların beklediği gibi çalışmaz (!) ve geriye dönük olarak yeniden tasarlanamaz ve HTTP uygulamaları kullanamaz SRV "alias" stili işlevselliğinin HTTP'ye hitap etmek için daha yaygın hale gelmesi daha muhtemel görünmektedir (görünür kayıt türü yerine sahnelerin arkasına uygulanan kayıt türüne özgü eşleme) - Håkan Lindqvist


Tüm bir bölgeyi yönlendiriyorsanız, DNAME kullanmalısınız. Göre RFC 6672,

DNAME RR ve CNAME RR [RFC1034],      (potansiyel olarak) farklı bir alan adına karşılık gelen verileri döndürür      sorgulanan alan adından. İkisi arasındaki fark      kaynak kayıtları, CNAME RR'nin veri aramasını yönlendirmesidir.      sahibini başka bir tek isimle, bir DNAME RR ise aramaları yönlendirir      sahibinin soyundan gelen veriler için karşılık gelen isimlere      ağacın farklı (tek) bir düğümü altında.

Örneğin, bir bölgeye bakmaya bakın (bkz. RFC 1034 [RFC1034],      "Foo.example.com" alan adı için Bölüm 4.3.2, 3. adım) ve      DNAME kaynak kaydının "example.com" adresinde bulunduğunu belirten      "example.com" altındaki sorgular "example.net" e yönlendirilmelidir. Arama      işlem, yeni sorgu adıyla 1. adıma dönecek      "Foo.example.net". Sorgu adı "www.foo.example.com" idi,      Yeni sorgu adı "www.foo.example.net" olacaktır.


0
2018-03-27 15:41



Bu yanlış bir yorumdur. Tablodaki ikinci satıra bakın. RFC 6672 §2.2. Bir apex DNAME, apekste DNAME dışındaki sorgu türleri için hiçbir eşleşme ile sonuçlanmayacaktır, yani bir Apex A veya AAAA kaydının fiili takma ile sonuçlanmayacaktır. - Andrew B
Apex DNAME sonuçlanmayacak yönlendirme apeks isminin sorguları için. Hiçbir şekilde sonuçlanmayacağını söylemek teknik olarak doğru değil. maç. NS, SOA veya gerçekte olan diğer RR türlerini sorgularsanız yine de bir eşleşme elde edersiniz mevcut apeks ismi için. itibaren RFC 6672: "Bölgenin zirvesinde bir DNAME kaydı varsa, yine de orada geleneksel SOA ve NS kaynak kayıtlarının olması gerekir. Böyle bir DNAME, ayna bir bölge tamamen değil, çünkü ayna bölge apex. " - Quuxplusone