하위 도메인 (도메인 이름)에 밑줄 _이있을 수 있습니까?
답변:
여기에 주어진 대부분의 대답은 거짓 입니다. 도메인 이름에 밑줄을 쓰는 것은 완벽하게 합법적입니다. 표준 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 "호스트 이름 및 숫자"로 호스트 이름 을 문자 숫자 하이픈으로 제한 합니다 .
_jabber._tcp.gmail.com도메인이 아니라 FQDN입니다. URL에는 밑줄을 사용할 수 없으므로 밑줄이있는 도메인을 구매할 수 없습니다. 따라서 tho 도메인도 DNS 구문 관점에서 밑줄을 가질 수 있으므로 로컬 도메인이 아닌 한 어떤 것도 만나지 않습니다.
정의에 대해 명확해야합니다. 여기에 사용 된대로 :
호스트 이름 의 제한 사항이 적용됩니다 RFC 952 과 RFC 1123의 약간의 휴식
RFC 2181 은 도메인 이름과 호스트 이름 사이에 차이점이 있음을 분명히합니다.
... [이진 레이블에 MX 레코드가있을 수 있다는 사실은 이진 이름을 전자 메일 주소의 호스트 부분으로 사용할 수 있음을 의미하지 않습니다 ...
따라서 호스트 이름의 밑줄은 아니요이며 도메인 이름의 밑줄 은 a-ok입니다.
실제로 밑줄이있는 호스트 이름 을 볼 수도 있습니다 . 는 AS 견고성 원리는 말한다 : "당신이 동의 무엇에, 당신이 보내는 어떤 보수적 자유주의해야합니다."
21 세기에는 도메인 이름 뿐만 아니라 호스트 이름 도 국제화 될 수 있습니다. 이는 허용 된 세트를 벗어난 문자가 포함 된 레이블의 경우 인코딩에 의존한다는 의미 입니다.
특히, 하나는 인코딩 할 수 있습니다 _에서 호스트 이름 (. 업데이트 2017-07 :이은, 주석을 볼 수있는 의문이다 _.. 아직 호스트 이름에 사용할 수없는 사실, 심지어 국제화 된 라벨에 사용할 수 없습니다)
국제화를위한 첫 번째 RFC는 2003 년 3 월의 RFC 3490 , "IDNA (Internationalizing Domain Names in Applications)"입니다. 오늘, 우리는 :
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--"는이 사양이 생성되기 전에 호스트 부품에 존재할 가능성이 거의 없기 때문에 선택되었습니다.
bar.baz.아래 계층있는 도메인 이름의 단지 컬렉션 (예를 들어)되어 bar.baz., 예를 들면 a.bar.baz., f.g.bar.baz., h.bar.baz.이 "하위 도메인"은 실제 호스트 이름을 포함하거나 포함하지 않을 수 있습니다 .
a.bar.baz(도메인 이름)을 문자열의 "하위 도메인" bar.baz(다른 도메인 이름) 으로 잘못 호출하는 경향이있을 수 있습니다 . 도메인 이름 (DNS 데이터베이스 자원) a.bar.baz이며 호스트 이름bar.baz 일 수도 있고 아닐 수도 있습니다 .
추가로 알아야 할 사항이 하나 더 있습니다. URL의 호스트 또는 하위 도메인 부분에 밑줄이 있으면 IE9 (다른 버전은 테스트하지 않은)가 쿠키를 쓸 수 없습니다.
그러니 조심하세요 :-)
명확히 bortzmeyer 와 데이비드 Tonhofer , 도메인 이름 및 하위 도메인 이름 라벨은 아무데도 선도 밑줄을 포함 할 수 있지만.
로 데이비드 Tonhofer가 쓴, 라벨은 그 사이 - 더 - 기간 부품이며, LDH 규칙을 따라야 을 제외한 일반 레이블에서 그들을 구별하기 위해 서비스 라벨 및 포트 라벨을 지정할 때를. 그런 다음 레이블의 시작 부분에 서비스 이름 및 포트 번호 레지스트리 의 "짧은 이름" , 선행 0이없는 포트 번호 또는 프로토콜 (예 : tcp, udp)이어야합니다. 이 서비스 레이블은 15 자로 제한됩니다.
David Tonhofer 의 답변과 달리 IDN은 밑줄 ( ' _'U + 005F LOW LINE) 또는 기타 유효하지 않은 ASCII 문자를 인코딩 할 수 없습니다.
에서 RFC5890
[..] IDNA의 도입으로 LDH 레이블의 두 가지 새로운 하위 집합이 만들어집니다. 이를 예약 된 LDH 레이블 (R-LDH 레이블)과 예약되지 않은 LDH 레이블 (NR-LDH 레이블)이라고합니다. 일부 다른 컨텍스트에서 "태그 된 도메인 이름"으로 알려진 예약 된 LDH 레이블에는 세 번째 및 네 번째 문자에 "-"가 포함되어 있지만 LDH 레이블 규칙을 따르는 속성이 있습니다 .
Punycode는 밑줄을 포함하여 모든 ASCII 코드 포인트를 ASCII로 직접 인코딩합니다. 결과 R-LDH는 LDH 레이블 규칙을 따르지 않습니다. 예를 들어, 규칙을 위반하는 Σ_.com것으로 인코딩됩니다 xn--_-zmb.com. 합법적으로 코딩 할 수있는 밑줄처럼 보이는 상동 코드 포인트가있을 수 있지만 ( '＿'U + FF3F 전폭 로우 라인), 이러한 종류의 코드 포인트는 2.3 IgnorableProperties에서 Noncharacter_Code_Point로 RFC5892 에서 DISALLOWED로 분류됩니다 .
RACE (다른 제안 된 IDN 인코딩 체계)는 IETF에서 표준으로 채택되지 않았으므로 사용해서는 안됩니다.
나는 RFC1034에 대한 링크를 따라 대부분을 읽었으며 이것을보고 놀랐다.
레이블은 ARPANET 호스트 이름 규칙을 따라야합니다. 문자로 시작하고 문자 또는 숫자로 끝나야하며 내부 문자로 문자, 숫자 및 하이픈 만 사용해야합니다. 길이에는 제한이 있습니다. 라벨은 63 자 이하 여야합니다.
명확하게하기 위해 도메인 이름은 점 "."으로 구분 된 레이블로 구성됩니다. 이 스펙은 밑줄 사용을 언급하지 않기 때문에 구식이어야합니다. 이 사양이 더 이상 사용되지 않는다는 사실을 모르고 넘어 지더라도 혼란을 이해할 수 있습니다. 더 이상 사용되지 않습니까?
RFC2181에 대한 링크를 따라 그 중 일부를 읽었습니다. 특히 정식 또는 정식 이름과 관련된 문제와 유효한 DNS 레이블을 만드는 문제와 관련된 경우.
이전에 게시 된 것처럼 길이 제한이 있다고 요약하면 다음과 같습니다.
(이름과 유효한 라벨에 대하여)
이것들은 이미 적절하게 지정되었지만 사양은 때때로 무시되는 것 같습니다. 기존 사양을 강화하려고합니다.
"길이 만 제한"이 "적절한"것인지 궁금해합니다. @ # $ %와 같은 도메인 이름을 볼 수 있습니까? 곧? 인터넷이 망쳐지지 않았습니까?
최근 CAB 포럼 (*)은
dNSName 항목에 밑줄 문자가 포함되고 유효 기간이 30 일을 초과하는 모든 인증서는 2019 년 1 월 15 일 이전에 취소해야합니다. https://cabforum.org/2018/11/12/ballot-sc-12- Dns에서 언더 스코어 /
이는 더 이상 ssl / tls 인증서가있는 도메인에서 밑줄을 사용할 수 없음을 의미합니다.
(*) 인증 기관 브라우저 포럼 (CA / 브라우저 포럼)은 주요 인증서 발급자 (아래 2.1 (a) (1) 및 (2)에 정의 된대로) 및 인터넷 브라우저 소프트웨어 및 기타 응용 프로그램 공급 업체를 자발적으로 모은 것입니다. 인증서 사용 (아래 2.1 (a) (3)에 정의 된 인증서 소비자)
개별 TLD 는 도메인 이름 에 자체 규칙 및 제한을 둘 수 있습니다 현지 언어를 수용하는 등 있습니다.
예를 들어 CIRA 에 따르면 캐나다의 .ca도메인 이름이 허용됩니다.
을
a통한 문자z및 다음 악센트 부호가있는 문자 :é ë ê è â à æ ô œ ù û ü ç î ï ÿ. 도메인 이름은 대소 문자를 구분하지 않습니다. 이는 대문자와 소문자 (A=a)를 구분하지 않음을 의미합니다 .숫자
0123456789와하이픈 문자 ( "
-) ( 도메인 이름을 시작하거나 종료하는 데 사용할 수는 없지만 )
최대 길이는 63 자이며, 각 강조 문자는 해당 제한을 4 만큼 줄입니다. 자로 줄입니다.
( 소스 )
또한, 이것은 dot-ca 도메인에 대해 약 4 개의 Quadragintillion 도메인 이름 가능성 (하위 도메인을 세지 않음)을 허용합니다.
여기 자바 세계에서 내 2 센트 :
Java 8이 포함 된 Spark Scala 콘솔에서
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
확실히 나쁜 생각입니다 ^^
인터넷에서 해결하기를 원한다면 아닙니다.
http://my_subdomain.example.com을 가질 수 없습니다 . 유효하지 않습니다.
하이픈이있는 http://my-subdomain.example.com 을 사용할 수 있습니다 .