DNS 클라이언트는 DNS 메시지 압축(포인터가 레이블 이름 대신 다른 포인터를 가리킬 수 있음)에 대해 걱정해야 합니까? 그렇게 하는 것이 분명해 보이지만 내가 언급하는 RFC에서는 이에 대해 언급하지 않습니다.
DNS rfc1035에서:
압축 방식을 사용하면 메시지의 도메인 이름을 다음과 같이 표현할 수 있습니다.
0옥텟으로 끝나는 태그 시퀀스
포인터
포인터로 끝나는 일련의 태그
DNS 클라이언트가 서버 응답에서 이러한 동작을 예상할 수 있습니까?
답변1
예, 그럴 수 있습니다.
관련 DNS 표준에서 이를 허용하지 않는 항목을 찾지 못했기 때문에 이를 얻게 되면 이를 디코딩할 수 있어야 합니다. 메시지 압축의 정의RFC 1035 4.1.4설명하다:
이 방식에서는 전체 도메인 이름이나 도메인 이름 끝에 있는 태그 목록이 동일한 이름의 이전 발생을 가리키는 포인터로 대체됩니다.
여기에는 이 사례가 문자 그대로의 태그 목록이어야 한다고 제안하는 내용이 없습니다. "네이키드 포인터"는 "포인터로 끝나는 태그 목록"의 특별한 경우일 뿐이므로 이를 디코딩하는 데 추가적인 복잡성이 필요하지 않습니다.
포인터를 생성할 실제 이유가 없고 코딩을 복잡하게 만들기 때문에 포인터에 대한 포인터는 실제로는 드뭅니다. 그러나 사양에 관한 한 완전히 유효한 것 같습니다.
답변2
아니요(이론적으로는 가능하지만 실제로는 어떤 일이든 일어날 수 있음)
놀랍게도 그 대답은 다른 RFC에 있다고 생각합니다.
RFC 2929: DNS(도메인 이름 시스템) IANA 고려 사항
섹션 3.3에서는 다음과 같이 말합니다.
현재 태그에는 데이터 태그와 압축 태그라는 두 가지 유형이 있습니다 . 압축 태그는
NAME의 행 인코딩을 단축하기 위한 RR 또는 DNS 메시지의 다른 위치에 있는 데이터 태그에 대한 포인터입니다.
특히 압축 태그가 데이터 태그에 대한 포인터라는 점에 유의하세요. 압축 태그가 다른 압축 태그에 대한 포인터가 될 수 있다고 말하지 않으므로 사양에 포인터 사례가 없다고 생각합니다.
댓글에서 논의한 것처럼 사양에는 이 상황이 금지된다고 명시되어 있지 않지만 금지될 수 있는 다른 모든 항목도 나열되어 있지 않습니다. 그들은 무엇이 허용되고 그 밖의 모든 것은 허용되어서는 안 되는지 알려줍니다. 따라서 나는 "사양에서 명시적으로 금지되지 않았으므로 허용됩니다"라는 주장과 그로부터 도출된 결론을 사용하여 @TooTea의 답변에 동의하지 않습니다.
이를 바탕으로 DNS 사양을 준수한다고 주장하려면 포인터가 다른 포인터를 가리켜서는 안 되지만 동시에 알려지지 않은 수신 메시지를 처리해야 한다면 다음과 같은 위험으로부터 자신을 보호해야 한다는 결론에 도달했습니다. 그러한 이벤트는 다른 이벤트(예: 전달 포인터 등)에 영향을 주고 수락할지 거부할지 결정합니다.
포스텔의 법칙에 따르면 받아들이는 것이 더 낫다고 생각할 수도 있지만, 이 정보에 적응하려고 하기보다는 놓아 두는 것이 더 낫다고 생각합니다. 그 이유는 다음과 같습니다.
- 위에서 언급한 바와 같이 이러한 상황은 스펙에 나와 있지 않으므로 "발생해서는 안 된다"는 것입니다.
- 나는 이것이 야생에서 드물 것이라고 예상합니다(그러나 나는 다음 요점 때문에 어떤 증거도 가지고 있지 않습니다).
- 이런 일이 발생하면 보낸 사람의 압축 알고리즘이 좋지 않다는 의미일 수 있으므로 이 결함이 있는 소프트웨어를 보상하려고 할 필요가 없습니다.
X가 Y를 가리키고 Y가 Z를 가리킨다면 X가 Z를 가리키도록 놔두는 것이 어떨까요? "중간" 포인터가 있으면 추가 기능이 제공되지 않으므로 존재할 이유가 없습니다(버그 및 유효하지 않은 구현 제외).