(Alan adı) alt alan adlarında alt çizgi “_” olabilir mi?


212

Alt alan adlarının (alan adları) alt çizgileri olabilir _mi?


12
Sorunuzu kelimenin tam anlamıyla aldım: DOMAIN NAMES demek istediniz. Bunun yerine, HOST NAMES demek istediyseniz, sorunuzu düzenleyin, çünkü cevap farklı olacaktır.
bortzmeyer

Yanıtlar:


362

Burada verilen cevapların çoğu yanlıştır . Bir alan adında alt çizgiye sahip olmak tamamen yasaldır. Standart RFC 2181, bölüm 11, "Ad sözdizimi" ni belirteyim :

DNS, kaynak kayıtlarını tanımlamak için kullanılabilen belirli etiketlere yalnızca bir kısıtlama koyar. Bu bir kısıtlama, etiketin uzunluğu ve tam adı ile ilgilidir. [...] DNS protokollerinin uygulamaları, kullanılabilecek etiketlere herhangi bir kısıtlama getirmemelidir. Özellikle, DNS sunucuları bazı DNS istemci programları tarafından kabul edilemeyecek etiketler içerdiğinden bir bölgeye hizmet vermeyi reddetmemelidir.

Ayrıca bkz. Orijinal DNS belirtimi, RFC 1034 , bölüm 3.5 "Tercih edilen ad sözdizimi", ancak dikkatle okuyun.

Alt çizgileri olan alanlar vahşi doğada çok yaygındır. Kontrol _jabber._tcp.gmail.comveya _sip._udp.apnic.net.

Burada bahsedilen diğer RFC farklı şeylerle ilgilenir. Asıl soru alan adları içindi . Soru, ana bilgisayar adları (veya bir ana bilgisayar adı içeren URL'ler için) ise, bu farklıdır, ilgili standart, ana bilgisayar adlarını letter-digit-tire ile sınırlayan RFC 1123 , bölüm 2.1 "Ana Bilgisayar Adları ve Sayıları" dır .


73
"Alan adları" ve "ana bilgisayar adları" arasındaki fark için +1
Alnitak

3
Soru (düzenlenmedikçe) alt alanlarla ilgilidir, yani. hostnamesini. Sorunun şu anda nasıl ifade edildiğine bağlı olarak, yanıtların yanlış olduğunu belirtmek dışında olgusal ifadelerinizde yanlış değilsiniz.
redreinard

4
Kafam karıştı, 1034 "Etiketler ARPANET ana bilgisayar adları için kurallara uymalıdır. Bir harfle başlamalı, harf veya rakamla bitmeli ve iç karakter olarak yalnızca harf, rakam ve kısa çizgi içermelidir." Bunun hangi kısmı alt çizgiye izin veriyor?
claudekennilol

2
İfadeler kafa karıştırıcı. URL'lerde alt çizgi olamaz. URL her zaman bir FQDN'dir, ana bilgisayar adı değildir. Bir FQDN'nin boş bir ana bilgisayar adı olabilir, bu durumda FQDN = etki alanı. _jabber._tcp.gmail.combir alan adı değil, bir FQDN. URL'lerde alt çizgi bulunamayacağından, muhtemelen alt çizgisi olan bir alan adı satın alamazsınız. Bu nedenle, tho alan adlarının DNS sözdizimi açısından alt çizgileri de olabilir, yerel bir alan olmadığı sürece hiçbiriyle karşılaşmazsınız.
Kapsül

1
Kısa çizgilerle ilgili izin verilen herhangi bir şeyden söz eden rfc1123'ün 2.1'deki alıntısını göremiyorum. Rfc952'de bir adın <let-or-digit-or-hyphen> olabileceğini görebiliyorum. Bahsettiğin bu mu?
AJP

93

Bortzmeyer'ın cevabına ilerleyerek terminoloji üzerine bir not

Tanımlar konusunda net olunmalıdır. Burada kullanıldığı gibi:

  • etki alanı adı , DNS veritabanındaki bir kaynağın tanımlayıcısıdır
  • etiketi , alan adının noktalar arasındaki bölümüdür
  • ana bilgisayar adı , İnternet ana bilgisayarlarını tanımlayan özel bir etki alanı adı türüdür

Hostname ait kısıtlamalara tabidir RFC 952 ve RFC 1123 hafif gevşeme

RFC 2181 , bir etki alanı adı ile ana makine adı arasında bir fark olduğunu açıkça belirtir:

... herhangi bir ikili etiketin bir MX kaydına sahip olabilmesi, herhangi bir ikili adın bir e-posta adresinin ana bilgisayar parçası olarak kullanılabileceği anlamına gelmez ...

Bu nedenle, ana makine adlarındaki alt çizgiler hayırdır, etki alanı adlarındaki alt çizgiler tamamdır.

Uygulamada, alt çizgileri olan ana makine adları görülebilir . As Gürbüzlük İlke diyor ki: "Eğer kabul ne, ne göndermek muhafazakar liberal olun".

Kodlama hakkında bir not

21. yüzyılda, alan adlarının yanı sıra ana bilgisayar adlarının uluslararasılaştırılabileceği ortaya çıkıyor! Bu , izin verilen kümenin dışında karakterler içeren etiketlerde kodlamalara başvurmak anlamına gelir .

Özellikle, tek kodlamak için izin verir _de ana bilgisayar adlarının (. Güncelleştirme 2017-07: Bu, yorumları görmek şüphelidir _.. Hala ana bilgisayar adları içinde kullanılamaz Gerçekten de, hatta uluslararası etiketlerde kullanılamaz)

Uluslararasılaştırma için ilk RFC , "Uygulamalarda Alan Adlarını Uluslararasılaştırma (IDNA)" Mart 2003 tarihli RFC 3490 idi. Bugün, elimizde:

  • RFC 5890 "IDNA: Tanımlar ve Belge Çerçevesi"
  • RFC 5891 "IDNA: Protokol"
  • RFC 5892 "Unicode Kod Noktaları ve IDNA"
  • RFC 5893 "IDNA için Sağdan Sola Kodlar"
  • RFC 5894 "IDNA: Arka Plan, Açıklama ve Gerekçe"
  • RFC 5895 "IDNA 2008 için Karakter Eşleme"

Wikipedia Girişini de kontrol etmek isteyebilirsiniz

RFC 5890 tanıtır süreli LDH (Letter Haneli-hypen) etiketi için etiket kullanılan ana bilgisayar adlarının ve der ki:

Bu, ana bilgisayar adlarında bazı ek kısıtlamalarla da olsa kullanılan klasik etiket formudur (RFC 952). Sözdizimi, RFC 1123 tarafından değiştirildiği şekliyle RFC 1034'ün 3.5 numaralı bölümünde "tercih edilen ad sözdizimi" olarak tanımlananla aynıdır. Kısaca, kısa çizgi ASCII harfleri, rakamlar ve kısa çizgiden oluşan kısa çizgiden oluşan bir dizedir dizenin başında veya sonunda görünür. Tüm DNS etiketleri gibi, toplam uzunluğu 63 sekizli'yi geçmemelidir.

Daha basit zamanlara dönersek, bu İnternet taslağı ana bilgisayar adı uluslararasılaşması için erken bir tekliftir . Uluslararası karakterlere sahip ana bilgisayar adları, örneğin 'RACE' kodlaması kullanılarak kodlanabilir .

'RACE kodlaması' teklif notlarının yazarı:

RFC 1035'e göre, ana bilgisayar parçaları büyük / küçük harfe duyarlı olmamalı, bir harf veya rakamla başlamalı ve bitmeli ve yalnızca harf, rakam ve kısa çizgi karakteri ("-") içermelidir. Bu, elbette, uluslararası karakterleri ve ASCII karakter repertuarındaki diğer birçok karakteri hariç tutar. Ayrıca, alan adı bölümleri 63 sekizli veya daha kısa olmalıdır. Uluslararasılaştırılmış karakterler içeren tüm dönüştürülmüş ad bölümleri "bq--" dizesiyle başlar. (...) "bq--" dizesi seçildi çünkü bu spesifikasyon üretilmeden önce konak parçalarda bulunması son derece düşük.


Bir yan notta, "DomainKeys ve hizmet kayıtları gibi sistemler, alt karakterini, özel karakterlerinin ana makine adlarıyla karıştırılmamasını sağlamak için bir araç olarak kullanır. Örneğin, _http._sctp.www.example.com bir SCTP için bir hizmet işaretçisi belirtir example.com etki alanındaki yetenekli web sunucusu ana bilgisayarı (www). " ( bağlantı )
x-yuri

RACE kodlama bölümlerini dikkate almayın, IDN zaten 'xn--' önekini kullanarak birleştirilmiş karakter dönüştürmeyi ASCII'ye ayarladı.
mootmoot

2
Nelda.techspiress @ Bir süre ama göre olmuştur RFC 1034: Alan Adları - Kavramlar ve Tesisleri , bir etki alanının "alt alan" denen bar.baz.altına hiyerarşik olan alan adlarının sadece toplama (örneğin) olduğu bar.baz., örneğin a.bar.baz., f.g.bar.baz., h.bar.baz.Bu "alt alan adı" gerçek ana bilgisayar adlarını içerebilir veya içermeyebilir .
David Tonhofer

2
Günlük kullanımda, dizeyi a.bar.baz(etki alanı adı) "dizenin alt bar.bazetki alanı (başka bir etki alanı adı)" olarak adlandırmak yanlış olabilir . Etki alanı adları (DNS veritabanı kaynakları) a.bar.bazve ana makine adlarıbar.baz olabilir veya olmayabilir .
David Tonhofer

1
On RFC 1034, sayfa 8 : Okuduğumuz bir alanı etki alanı adıyla tanımlanır ve ya etki alanını belirten alan adının altında olduğu alan adı alan bu bölümünde oluşur. Etki alanı, o etki alanında bulunuyorsa başka bir etki alanının alt etki alanıdır. Bu ilişki, alt alan adının içeren alan adıyla bitip bitmediğini test ederek test edilebilir. Örneğin, ABCD, BCD, CD, D ve "" nin bir alt alan adıdır.
David Tonhofer

47

Bilmeniz gerekebilecek ek bir şey daha vardır: URL'nin ana bilgisayar veya alt alan adı alt çizgi içeriyorsa, IE9 (diğer sürümleri test etmediyse) çerez yazamaz.

Bu yüzden dikkatli olun. :-)



3
Biz sadece bir projede vardı - ve orada garip IE sorunları hakkında deli olmak üzereydim. Alt alandaki alt çizgiyi bulana kadar. ; o)
Kai Mattern

3
IE10'da hala bir sorun var. MS bunu biliyor mu?
Piotr Kula

15
Daha alakalı: MS bunu önemsiyor mu?
Ajax


11

Netleştirilmesi bortzmeyer ve David TONHOFER , alan adı ve alt etki isim etiketleri başka hiçbir yerde öncü alt çizgilerden, ancak.

As David TONHOFER yazdığı, etiketler arasında kalan-dönemler parçalardır ve LDH kuralı takip etmeli dışında düzenli etiketler ayırmaktır hizmet etiketleri ve liman etiketleri belirtirken. Daha sonra etiketin başında, Hizmet Adı ve Bağlantı Noktası Numarası Kayıt Defteri'nden "Kısa Adlar", baştaki 0'ları olmayan bağlantı noktası numarası veya protokol (yani, tcp, udp) olmalıdır. Bu servis etiketleri ayrıca 15 karakterle sınırlıdır.

  • RFC2782, servis kaydı alt alanlarının önekini alt çizgi ile belirtir.
  • RFC6698 , TLSA sertifika kayıtlarındaki alt çizgi ile ön ek bağlantı noktası numaralarını belirtir.

David Tonhofer'ın aksine cevabının , IDN alt çizgiyi ('_' U + 005F DÜŞÜK HAT) veya başka bir geçersiz ASCII karakterini kodlamaya izin vermez.

Gönderen RFC5890

[..] IDNA'nın tanıtılmasıyla iki yeni LDH etiketi alt kümesi oluşturulmuştur. Bunlara Ayrılmış LDH etiketleri (R-LDH etiketleri) ve Ayrılmamış LDH etiketleri (NR-LDH etiketleri) denir. Diğer bazı bağlamlarda "etiketli alan adları" olarak bilinen ayrılmış LDH etiketleri, üçüncü ve dördüncü karakterlerde "-" içerdikleri ancak LDH etiket kurallarına uyduğu özelliğe sahiptir .

Punycode, alt çizgi dahil tüm ASCII kod noktalarını doğrudan ASCII olarak kodlar. Ortaya çıkan R-LDH, LDH etiketi kurallarına uymayacaktır. Örneğin , kuralları ihlal ettiği Σ_.comşekilde kodlanır xn--_-zmb.com. Bir eşyazımlı kod noktası olabilir ki yasal olarak kodlanmış (belki de, '_' u + FF3F düşük hat Fullwidth), ancak codepoints bu tür tarafından izin olarak kategorize edilebilir edilebilir bir alt çizgi gibi görünüyor RFC5892 bir Noncharacter_Code_Point olarak 2.3 IgnorableProperties altında.

RACE (önerilen diğer IDN kodlama şeması) IETF tarafından standart olarak kabul edilmemiştir ve kullanılmamalıdır.


1
En sonunda. Bu, tüm sayfada punycode hakkında konuşan tek gönderi olduğuna inanamıyorum.
Pacerier

6

RFC1034 bağlantısını izledim ve çoğunu okudum ve bunu görünce şaşırdım:

Etiketler ARPANET ana bilgisayar adlarına ilişkin kurallara uymalıdır. Bir harfle başlamalı, harf veya rakamla bitmeli ve iç karakter olarak yalnızca harf, rakam ve kısa çizgi içermelidirler. Uzunluğunda bazı kısıtlamalar da vardır. Etiketler 63 karakter veya daha az olmalıdır.

Açıklığa kavuşturmak için, bir alan adı "." Noktalarıyla ayrılmış etiketlerden oluşur. Alt çizgilerin kullanılmasından bahsetmediği için bu özellik eski olmalıdır. Birisi bu spesifikasyonun eskimiş olduğunu bilmeden tökezliyorsa karışıklığı anlayabilirim. Eski, değil mi?

RFC2181 bağlantısını takip ettim ve bir kısmını okudum. Özellikle, yetkili veya kanonik olanın ne olduğu ve geçerli bir DNS etiketi yapan şeyin ne olduğu konusuyla ilgilidir.

Daha önce yayınlandığı gibi, özetlemek için sadece bir uzunluk kısıtlaması olduğunu belirtir:

(adlar ve geçerli etiketler hakkında)

Bunlar zaten yeterince belirtilmiş olsa da, teknik özellikler bazen göz ardı edilmiş gibi görünmektedir. Mevcut spesifikasyonları güçlendirmeye çalışıyoruz.

Biraz "sadece bir uzunluk kısıtlaması" "yeterli" olup olmadığını merak bırakır. @ # $% Gibi alan adlarını görmeye başlayacak mıyız !! yakında? İnternet yeterince berbat değil mi?


3
Hayır, kullanılmıyor. RFC1034, DNS veritabanındaki kaynakların genel tanımlayıcıları olan özel bir etki alanı adları örneği olan ana bilgisayar adları hakkında bir belirtimdir . Örneğin, URI'lerin "ana bilgisayar" kısmı oldukça rahat bir şekilde tanımlanır ( tools.ietf.org/html/rfc3986#section-3.2.2 ), ancak RFC şunları uyarır : "Kayıtlı bir adla tanımlanan bir ana bilgisayar genellikle bir karakter dizisidir yerel olarak tanımlanmış bir ana bilgisayar veya hizmet adı kayıt defterinde arama için tasarlanan ... DNS'de arama amaçlı kayıtlı bir ad, [RFC1034] Bölüm 3.5 ve [RFC1123] Bölüm 2.1'de tanımlanan sözdizimini kullanır. "
David Tonhofer

3

Son zamanlarda CAB forumu (*)

Herhangi bir dNSName girdisinde alt çizgi karakteri içeren ve geçerlilik süresi 30 günden fazla olan tüm sertifikalar 15 Ocak 2019 tarihinden önce iptal edilmelidir. Https://cabforum.org/2018/11/12/ballot-sc-12- sunset-of-çizgi-içinde-dnsnames /

Bu, artık ssl / tls sertifikasına sahip alan adlarında alt çizgi kullanmanıza izin verilmediği anlamına gelir.

(*) Sertifika Yetkilisi Tarayıcı Forumu (CA / Tarayıcı Forumu), önde gelen Sertifika Veren kuruluşların (aşağıdaki Bölüm 2.1 (a) (1) ve (2) 'de tanımlandığı gibi)) ve Internet tarayıcı yazılımı ve diğer uygulamaların gönüllü olarak bir araya getirilmesidir. sertifikaları kullanın (aşağıdaki Bölüm 2.1 (a) (3) 'de tanımlanan Sertifika Tüketicileri).


1

Bireysel TLD'ler , yerel dilleri karşılamak gibi uygun gördükleri alan adlarına kendi kurallarını ve kısıtlamalarını yerleştirebilir .

Örneğin, CIRA'ya , Kanada'nın .caalan adlarına izin verilir:

  • harfler a yoluyla zve aşağıdaki aksanlı karakterler: é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Alan Adlarının büyük / küçük harfe duyarlı olmadığını unutmayın. Bu, büyük harfler ile küçük harfler arasında bir ayrım yapılmayacağı anlamına gelir ( A= a);

  • Sayılar 0123456789ve

  • Kısa çizgi karakteri ("- ) (o her ne kadar can not başlatmak veya Alan Adı sonlandırmak için kullanılabilir).

Maksimum uzunluk 63 karakterdir, ancak her aksanlı karakter bu sınırı 4 karakter azaltır .

( Kaynak )


Bu arada, nokta-ca alan adları için yaklaşık 4 Quadragintillion alan adı olasılığına (alt alanları saymaz) izin verir .


0

İşte Java dünyasından 2 sentim:

Java 8 ile bir Spark Scala konsolundan:

scala> new java.net.URI("spark://spark_master").getHost
res10: String = null

scala> new java.net.URI("spark://spark-master").getHost
res11: String = spark-master

scala> new java.net.URI("spark://spark_master.google.fr").getHost
res12: String = null

scala> new java.net.URI("spark://spark.master.google.fr").getHost
res13: String = spark.master.google.fr

scala> new java.net.URI("spark://spark-master.google.fr:3434").getHost
res14: String = spark-master.google.fr

scala> new java.net.URI("spark://spark-master.goo_gle.fr:3434").getHost
res15: String = null

Kesinlikle kötü bir fikir ^^


0

Sadece yerel proje (vagrant ile) oluşturdu ve ip adresi üzerinden erişildiğinde mükemmel çalışıyordu. Sonra hosts dosyasına some_name.test ekledim ve bu şekilde erişmeye çalıştım, ama her zaman "kötü istek - 400" alıyordum. Sadece domain-some-name.test olarak değiştirilmesinin problemi çözdüğünü anlayana kadar saat kaybettim. Yani en azından Mac OS'de yerel olarak çalışmıyor.


0

Hayır, alt alanda alt çizgi kullanamazsınız, ancak hiper (tire) kullanırsınız. yani my-subdomain.agahost.com kabul edilebilir ve my_subdomain.agahost.com kabul edilemez.


-2

İnternette çözülmesini istiyorsanız değil.

Sahip olamazsınız: http://my_subdomain.example.com geçersiz.

Şunlara sahip olabilirsiniz: http://my-subdomain.example.com kısa çizgi ile.


15 Ocak 2019'dan sonra - karşı örneğiniz çalışmıyor.
Joe Inwap

@JoeInwap Lütfen yorumunuz için bir kaynağa yönlendirebilir misiniz?
19'da ankshah

Ben cabforum.org/2018/11/12/… ve o_o.lgms.nl o ana bilgisayar adı için geçerli olmayan bir sertifika sunduğu gerçeği gidiyordu . Ancak ad çözümleniyor.
Joe Inwap
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.