SRV 레코드가 스스로 질의하는 클라이언트에게만 도움이 되는 이유

영역에 SRV 레코드를 추가해도 어떤 VPN 클라이언트도 그것을 조회하도록 배우지 않습니다. 클라이언트가 레이블을 알고 질의를 보내기로 결정하고 돌아온 결과에 따라 행동해야 하며, DNS는 그중 처음 두 가지를 제공할 수 없습니다. 따라서 실패한 SRV 계획의 대부분은 DNS 옷을 입은 클라이언트 문제입니다. 먼저 클라이언트의 검색 동작을 읽고, 그다음 그것이 실제로 질의하는 레이블만 게시하십시오.

아무도 질의하지 않는 레코드는 누구에게도 도움이 되지 않는다

SRV는 서비스의 위치를 게시하며 서비스를 알리지는 않습니다. 레코드를 클라이언트로 밀어 넣는 것은 없으며, 어떤 리졸버도 요청된 적 없는 이름을 먼저 제안하지 않습니다. 조회는 애플리케이션이 그것을 하기로 결정할 때 시작되므로 레이블은 제품 문서나 네트워크에서 소프트웨어를 관찰한 결과에서 나와야 합니다. 클라이언트에 검색 단계가 없는 곳에서는 레코드가 영역을 바꿀 뿐 그 밖의 것은 바꾸지 않습니다.

그래서 네트워크의 한 제품은 작동하기 시작하는데 다른 제품은 같은 변경에 영향을 받지 않을 수 있습니다. 변수는 소프트웨어이며, DNS 서버는 지시받은 대로 정확히 수행합니다. 편집 후에는, 잘못 입력한 레이블이 모두 비슷해 보이는 레코드 사이에 쉽게 숨으므로 영역을 다시 읽으십시오.

쓰기 전에 필드를 읽으십시오

레코드는 네 개의 값을 가지며 각각 다른 질문에 답하는데, 우선순위는 클라이언트가 시도할 수 있는 대상을 정렬하고, 가중치는 같은 우선순위의 대상 사이에서 부하를 나누고, 포트는 전송 포트를 지목하고, 대상은 호스트를 지목합니다. 명세는 . 대상을 서비스가 의도적으로 제공되지 않음을 뜻하도록 허용하며, 이는 깨진 응답이 아니라 유용한 응답입니다.

이 필드 중 어느 것도 자격 증명, 인증서 정책, 애플리케이션 버전을 담지 않으며, 가중치를 무시하는 클라이언트도 연결은 하지만 의도한 균형 없이 연결합니다. 대상에는 자체 주소 레코드가 필요하며 별칭이 아니라 정식 이름이어야 합니다. 수신기가 없는 호스트를 가리키는 레코드를 게시하면 DNS 결함처럼 읽히는 연결 오류가 생기며, 그것이 가장 값비싼 오도입니다. 전체 체인을 게시하거나 아무것도 게시하지 마십시오.

클라이언트가 실제로 보내는 레이블을 찾으십시오

제품 이름에 대한 추측이 아니라 증거로 레이블을 확정하십시오. 문서가 서비스 이름을 밝히거나, 캡처가 시작 시 클라이언트에서 나가는 질의를 보여 줍니다. 두 경로 모두 리졸버에 대해 시험할 정확한 이름과 유형이라는 같은 지점에 도달합니다.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

밑줄과 끝의 점도 이름의 일부이므로 응답을 게시한 레코드와 문자 단위로 비교하십시오. 실제로 보낸 질의에 대한 빈 응답은 영역을 가리키고, 질의가 전혀 없으면 클라이언트를 가리키며, 이 발견은 서로 다른 팀으로 이어집니다. 실제 응답은 아래 줄과 같으며, 우선순위 20은 더 낮은 우선순위의 어떤 레코드에도 지고 클라이언트는 지정된 대상의 포트 8443으로 연결합니다.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

대상도 존재해야 한다

확인되는 대상은 응답하는 서비스와 같지 않습니다. 대상의 주소 레코드를 확인한 다음 게시된 포트와 프로토콜에서 무언가 수신 중인지 확인하십시오. UDP만 수신하는 곳을 가리키는 TCP 레코드는 어떤 영역 편집으로도 고칠 수 없는 불일치입니다. 대상이 유동적인 동안 TTL을 짧게 유지하고, 이름이 움직이지 않으면 늘리십시오.

검색을 실제로 구현하는 클라이언트도 레코드를 어느 정도 존중하는지가 다릅니다. 일부는 우선순위만 사용하고, 일부는 가중치를 권고로 취급하며, 몇몇은 포트를 무시하고 기본값을 가정합니다. 그런 차이는 그렇지 않으면 리졸버 결함처럼 보이는 동작을 설명해 주므로 레이블 옆의 메모에 적어야 합니다.

검색은 인증이 아니다

SRV 응답은 어디에 연결할지 말하며, 도착한 뒤 누구를 신뢰할지에 대해서는 아무것도 말하지 않습니다. 다른 사람이 위조할 수 있는 레코드가 신뢰 결정이 되지 않도록 클라이언트의 인증서 검증과 서버 신원 확인을 있던 그대로 두십시오. DNS 응답은 캐시될 수 있고 영역을 통제하는 누구나 편집할 수 있으므로 정책을 담기에 나쁜 장소입니다.

검색을 지원하지 않는 클라이언트에는 그것이 받아들이는 프로필이나 게이트웨이 URL을 배포하고, 어느 제품이 어느 방식을 쓰는지 기록하십시오. 그 기록은 다음 관리자가 레코드를 추가하고 어디서나 작동할 것이라 기대하는 것을 막습니다. SRV 명세는 대상 사이의 선택을 설명하며, 그것을 권한 부여 메커니즘으로 읽는 것이 유용한 레코드를 보안 가정으로 만드는 길입니다. 의도적으로 게시하고, 문서에 레이블 이름을 적고, 클라이언트를 이것이 문제되는지를 결정하는 구성 요소로 대하십시오.