호스팅 업체의 웹 인터페이스에서 DKIM 키에 대한 긴 TXT 레코드를 생성하는 데 문제가 있습니다.
각 줄에는 256자를 사용할 수 있습니다.
우리는 여러 줄을 시도한 다음 ("처음과 ")마지막에 추가를 시도 했습니다 . 둘 다 작동하지 않습니다.
그런 다음 다른 호스트의 레코드에 cname을 작성하여 DKIM TXT 레코드를 작성할 수 있습니다 .
그러나 이제 웹 인터페이스는 CNAME기록 에서 불법적 인 이름에 대해 불평합니다 .
mail._domainkey.example.com TXT확인이
mail._domainkey.example.com CNAME확인되지 않습니다
mail.domainkey.example.com CNAMEOK이지만, 우리가 원하지 않는 것을.
웹 인터페이스가 방금 우리를 미치게하기로 결심 CNAME했습니까?
답변
예, DNS 이름 (A / AAAA도 포함)은을 포함 할 수 [0-9], [a-z], -있으므로 밑줄이 유효하지 않습니다. TXT 레코드는 호스트 이름이 아니며이 제한 사항은 적용되지 않습니다. 마지막 편집 : -첫 번째 문자로도 사용 mail.-domainkey.our.dom되지 않을 수 있으므로 유효하지 않습니다.
https://ko.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames
최종 편집 : 부분적으로 잘못되었습니다. CNAME을 호스트 이름으로 사용하는 경우 위 제한이 적용됩니다. CNAME은 DKIM 컨텍스트에서 호스트 이름으로 간주되지 않는 경우 _CNAME 항목의 유효한 부분이어야합니다. /programming/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491를 참조 하십시오.
답변
유효한 문자는 DNS에 허용됩니다. https://tools.ietf.org/html/rfc2181#section-11을 참조 하십시오.
“DNS 자체는 리소스 레코드를 식별하는 데 사용할 수있는 특정 레이블에 대해 하나의 제한 사항 만 적용합니다. 한 가지 제한은 레이블의 길이와 이름과 관련이 있습니다. 한 레이블의 길이는 1에서 63 옥텟으로 제한됩니다. “
클라이언트는 이름 값의 유효성을 검사해야합니다. 예를 들어 MX 레코드에 “Alice”값이 포함될 수 있지만 “Alice”는 유효한 전자 메일 주소가 아니기 때문에 조회 후 해당 값을 거부해야합니다.
이 경우, 호스팅 담당자가 입력을 “확인”하는 것처럼 보이고 수동으로 입력 할 수 있어야합니다.
답변
RFC 1034 : 레이블은 ARPANET 호스트 이름 규칙을 따라야합니다. 문자로 시작하고 문자 또는 숫자로 끝나야하며 문자, 숫자 및 하이픈 만 내부 문자로 사용해야합니다. 길이에는 제한이 있습니다. 라벨은 63 자 이하 여야합니다.
답변
편집과 함께 @Sven의 대답은 이미 옳았지만 직접 문구를 표현하는 것입니다.
TL; DR 예 밑줄이 CNAME양쪽 레코드 모두 에서 유효합니다 . 이유를 보려면 아래를 읽으십시오.
RFC 1034 및 기타는 “도메인 이름”을 기반으로하여 모든 문자가 포함 된 레이블 인 레코드를 정의합니다 _.
그러나 일부 레코드에는 소유자 이름 및 / 또는 리소스 데이터 (RDATA)에 대해보다 엄격한 규칙이 있습니다. 호스트 이름 만 허용되며 실제로 규칙은 이제 ASCII 문자 (대소 문자 구분 안 함), ASCII 숫자 및 하이픈을 사용할 수있는 규칙이 완화되었습니다 (이전에는 호스트 이름이 숫자로 시작할 수 없었습니다). , 추가 위치 규칙 : 시작 또는 끝에 하이픈 없음 및 위치 3 및 4에 이중 하이픈 없음 ( xn--대소 문자 만 허용되는 IDN의 “예약”때문에 ).
예를 들어 A또는 AAAA레코드 의 소유자 이름은 도메인 이름이 아닌 호스트 이름입니다. 그래서
test.example.com A 192.0.2.1이 모든이없는 이유는 유효합니다 :
_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1
프로그램을 사용하여 쉽게 테스트 할 수 있습니다 (이름 서버 소프트웨어의 named-checkzone일부 bind이지만 별도로 사용 및 설치 될 수 있으며 다른 이름 서버에는 유사한 검사 도구가있을 수 있으며 온라인 인터페이스가있을 수도 있습니다). 파일에 레코드를 넣고 실행하십시오. 그것에 :
$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)
(이전의 숫자 IN는 TTL이며, 이것은 우리의 문제와 관련이 없지만 레코드의 구문 유효성 검사를 통과하는 데 필요합니다).
다른 레코드의 경우 반대입니다. NS소유자에 대한 제한은 없지만 데이터 인 “대상”에 대한 제한이 있기 때문입니다. DNS 쿼리에 응답하는 물리적 호스트 인 신뢰할 수있는 네임 서버를 가리켜 야하기 때문에 데이터는 도메인 이름이 아닌 호스트 이름 일 수 있습니다.
이제 CNAME섹션 3.6의 RFC 1034 관련 인용문이 있습니다.
“소유자 : RR이있는 도메인 이름입니다.” 이는 기본적으로 호스트 이름뿐만 아니라 모든 이름을 의미합니다 (CNAME 레코드의 소스로).
“RDATA : 자원을 설명하는 유형이며 때로는 클래스 종속 데이터입니다.”
“CNAME 도메인 이름.”
따라서 CNAME(왼쪽에 있는) 소유자 와 그에 연결된 리소스 데이터, 대상 / 대상 (오른쪽에있는)은 모두 도메인 이름이며 호스트 이름 만 아닙니다. 기본적으로 모든 문자가 포함되므로 _양쪽에 모두 허용됩니다.
다시 한번, named-checkzone다음 과 같이 쉽게 테스트 할 수 있습니다 .
$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.
[정보] 어떠한 오류가 없다 CNAME(내 가짜 영역에서 내가 어떤 넣지 않았기 때문에 다른 오류 예상 SOA이나 NS했을 진정한 지역처럼 레코드)