(도메인 이름) 하위 도메인에 밑줄 "_"이있을 수 있습니까?

(도메인 이름) 하위 도메인에 밑줄 "_"이있을 수 있습니까?

---

하위 도메인 (도메인 이름)에 밑줄 _이있을 수 있습니까?

---

여기에 주어진 대부분의 대답은 거짓 입니다. 도메인 이름에 밑줄을 쓰는 것은 완벽하게 합법적입니다. 표준 RFC 2181, 섹션 11, "이름 구문"을 인용하겠습니다 .

DNS 자체는 리소스 레코드를 식별하는 데 사용할 수있는 특정 레이블에 하나의 제한 사항 만 적용합니다. 한 가지 제한은 레이블의 길이와 이름과 관련이 있습니다. [...] DNS 프로토콜 구현은 사용할 수있는 레이블에 제한을 두지 않아야합니다. 특히 DNS 서버에는 일부 DNS 클라이언트 프로그램에서 허용되지 않는 레이블이 포함되어 있기 때문에 영역 서비스를 거부해서는 안됩니다.

원래 DNS 사양 인 RFC 1034 , 섹션 3.5 "선호 이름 구문"을 참조하지만 자세히 읽으십시오.

밑줄이있는 도메인은 야생에서 매우 일반적입니다. _jabber._tcp.gmail.com또는을 확인하십시오 _sip._udp.apnic.net.

여기에 언급 된 다른 RFC는 다른 것들을 다룹니다. 원래 질문은 도메인 이름에 대한 것이었다 . 질문이 호스트 이름 (또는 호스트 이름 을 포함하는 URL )에 대한 것이면, 다른 표준입니다. 관련 표준은 RFC 1123 섹션 2.1 "호스트 이름 및 숫자"로 호스트 이름 을 문자 숫자 하이픈으로 제한 합니다 .

---

보르 츠 마이어의 답변에 대한 용어에 대한 메모

정의에 대해 명확해야합니다. 여기에 사용 된대로 :

• 도메인 이름 은 DNS 데이터베이스에서 리소스 의 식별자입니다.
• label 은 도메인 이름에서 점 사이의 일부입니다.
• 호스트 이름 은 인터넷 호스트를 식별 하는 특수한 유형의 도메인 이름입니다.

호스트 이름 의 제한 사항이 적용됩니다 RFC 952 과 RFC 1123의 약간의 휴식

RFC 2181 은 도메인 이름과 호스트 이름 사이에 차이점이 있음을 분명히합니다.

... [이진 레이블에 MX 레코드가있을 수 있다는 사실은 이진 이름을 전자 메일 주소의 호스트 부분으로 사용할 수 있음을 의미하지 않습니다 ...

따라서 호스트 이름의 밑줄은 아니요이며 도메인 이름의 밑줄 은 a-ok입니다.

실제로 밑줄이있는 호스트 이름 을 볼 수도 있습니다 . 는 AS 견고성 원리는 말한다 : "당신이 동의 무엇에, 당신이 보내는 어떤 보수적 자유주의해야합니다."

인코딩에 대한 참고 사항

21 세기에는 도메인 이름 뿐만 아니라 호스트 이름 도 국제화 될 수 있습니다. 이는 허용 된 세트를 벗어난 문자가 포함 된 레이블의 경우 인코딩에 의존한다는 의미 입니다.

특히, 하나는 인코딩 할 수 있습니다 _에서 호스트 이름 (. 업데이트 2017-07 :이은, 주석을 볼 수있는 의문이다 _.. 아직 호스트 이름에 사용할 수없는 사실, 심지어 국제화 된 라벨에 사용할 수 없습니다)

국제화를위한 첫 번째 RFC는 2003 년 3 월 "IDNA (Internationalizing Domain Names in Applications)"의 RFC 3490 입니다. 오늘, 우리는 :

• RFC 5890 "IDNA : 정의 및 문서 프레임 워크"
• RFC 5891 "IDNA : 프로토콜"
• RFC 5892 "유니 코드 코드 포인트 및 IDNA"
• RFC 5893 "IDNA를위한 오른쪽에서 왼쪽으로 쓰는 스크립트"
• RFC 5894 "IDNA : 배경, 설명 및 이론적 근거"
• RFC 5895 "IDNA 2008의 문자 매핑"

Wikipedia Entry 를 확인하실 수도 있습니다

RFC 5890 을 소개합니다 용어 LDH (문자 - 숫자 - 하이픈) 라벨 에 대한 라벨 에 사용되는 호스트 이름 과는 말한다 :

호스트 이름 (RFC 952)에는 몇 가지 추가 제한 사항이 있지만 사용되는 클래식 레이블 형식입니다. 구문은 RFC 1123에 의해 수정 된 RFC 1034의 3.5 절에서 "선호 이름 구문"과 동일합니다. 간단히 말해서 ASCII 문자, 숫자 및 하이픈으로 구성되는 문자열입니다. 문자열의 시작 또는 끝에 나타납니다. 모든 DNS 레이블과 마찬가지로 전체 길이는 63 옥텟을 초과해서는 안됩니다.

더 간단한 시대로 돌아가서, 이 인터넷 초안 은 호스트 이름 국제화를 위한 초기 제안입니다 . 국제 문자가있는 호스트 이름은 예를 들어 'RACE'encoding 을 사용하여 인코딩 될 수 있습니다 .

'RACE 인코딩'제안서 작성자 :

RFC 1035에 따르면 호스트 부분은 대소 문자를 구분하지 않아야하고 문자 나 숫자로 시작하고 끝나야하며 문자, 숫자 및 하이픈 문자 ( "-") 만 포함해야합니다. 물론 이것은 ASCII 문자 레퍼토리의 다른 많은 문자뿐만 아니라 국제화 된 문자는 제외합니다. 또한 도메인 이름 부분의 길이는 63 옥텟 또는 그보다 짧아야합니다. 국제화 된 문자를 포함하는 모든 변환 후 이름 부분은 "bq--"문자열로 시작합니다. (...) 문자열 "bq--"는이 사양이 생성되기 전에 호스트 부품에 존재할 가능성이 거의 없기 때문에 선택되었습니다.

---

추가로 알아야 할 사항이 하나 더 있습니다. URL의 호스트 또는 하위 도메인 부분에 밑줄이 있으면 IE9 (다른 버전은 테스트하지 않은)가 쿠키를 작성할 수 없습니다.

그러니 조심하세요 :-)

---

명확히 bortzmeyer 와 데이비드 Tonhofer , 도메인 이름 및 하위 도메인 이름 라벨은 아무데도 선도 밑줄을 포함 할 수 있지만.

로 데이비드 Tonhofer가 쓴, 라벨은 그 사이 - 더 - 기간 부품이며, LDH 규칙을 따라야 을 제외한 일반 레이블에서 그들을 구별하기 위해 서비스 라벨 및 포트 라벨을 지정할 때를. 그런 다음 레이블의 시작 부분에 서비스 이름 및 포트 번호 레지스트리 의 "짧은 이름" , 선행 0이없는 포트 번호 또는 프로토콜 (예 : tcp, udp)이어야합니다. 이 서비스 레이블은 15 자로 제한됩니다.

• RFC2782는 접두사 서비스 레코드 하위 도메인에 밑줄을 지정합니다.
• RFC6698 은 TLSA 인증서 레코드에서 접 두부 포트 번호를 밑줄로 지정합니다.

David Tonhofer 의 답변과 달리 IDN은 밑줄 ( ' _'U + 005F LOW LINE) 또는 기타 유효하지 않은 ASCII 문자를 인코딩 할 수 없습니다.

에서 RFC5890

[..] IDNA의 도입으로 LDH 레이블의 두 가지 새로운 하위 집합이 만들어집니다. 이를 예약 LDH 레이블 (R-LDH 레이블) 및 비 예약 LDH 레이블 (NR-LDH 레이블)이라고합니다. 일부 다른 컨텍스트에서 "태그 된 도메인 이름"으로 알려진 예약 된 LDH 레이블에는 세 번째 및 네 번째 문자에 "-"가 포함 되지만 LDH 레이블 규칙을 준수 하는 속성이 있습니다 .

Punycode encodes all ASCII codepoints as ASCII directly, including underscore. The resulting R-LDH would not conform the the LDH label rules. For example, Σ_.com would be encoded as xn--_-zmb.com which violates the rules. There may be a homographic codepoint which looks like an underscore that can be coded legally (perhaps '＿' U+FF3F fullwidth low line), but these kinds of codepoints would be categorized as DISALLOWED by RFC5892 under 2.3 IgnorableProperties as a Noncharacter_Code_Point.

RACE (the other proposed IDN encoding scheme) was not accepted as a standard by IETF and should not be used.

---

I followed the link to RFC1034 and read most of it and was surprised to see this:

The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.

For clarification, a domain names are made up of labels which are separated by dots ".". This spec must be outdated because it doesn't mention the use of underscores. I can understand the confusion if anybody stumbles over this spec without knowing it is obsolete. It is obsolete, isn't it?

I followed the link to RFC2181 and read some of it. Especially where it pertains to the issue of what is an authoritative, or canonical, name and the issue of what makes a valid DNS label.

As posted earlier it states there's only a length restriction then to sum it up it reads:

(about names and valid labels)

These are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specifications.

Kind of leaves me wondering if "a length only restriction" is "adequate". Are we going to start seeing domain names like @#$%!! soon? Isn't the internet screwed up enough?

---

Here my 2 cents from Java world:

From a Spark Scala console, with Java 8:

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

It's definitely a bad idea ^^

---

Individual TLD's can place their own rules & restrictions on domains names as they see fit, such as to accomodate local languages.

For example, according to the CIRA, Canada's .ca domain names are allowed:

• Letters a through z, and the following accented characters: é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Note that Domain Names are not case sensitive. This means there will be no distinction made between upper case letters and lower case letters (A = a);

• The numbers 0123456789, and

• The hyphen character ("-) (although it cannot be used to start or end a Domain Name).

The maximum length is 63 characters, except each accented character reduces that limit by 4 characters.

(Source)

---

_{Incidentally, this allows for around 4 Quadragintillion domain name possibilities (not counting sub-domains) for dot-ca domains.}

---

Recently the CAB-forum (*) decided that

All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019. https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/

This means that you are no longer allowed to use underscores in domains that will have a ssl/tls certificate.

(*) The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of leading Certificate Issuers (as defined in Section 2.1(a)(1) and (2) below) and vendors of Internet browser software and other applications that use certificates (Certificate Consumers, as defined in Section 2.1(a)(3) below).

---

Not if you want it to resolve on the Internet.

You cannot have: http://my_subdomain.example.com is invalid.

하이픈이있는 http://my-subdomain.example.com 을 사용할 수 있습니다 .

참고 URL : https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it