☰

바인딩9: 인터넷 연결이 끊어지면 로컬 이름 서버로 전달이 작동하지 않습니다.

tag-icon • tag-icon domain-name-system bind dns-zone forwarding
바인딩9: 인터넷 연결이 끊어지면 로컬 이름 서버로 전달이 작동하지 않습니다.

나는 다음과 같은 설정을 가지고 있습니다 :

내 로컬 네트워크의 이름을 확인하기 위해 매우 제한된 하드웨어의 바인딩9 인스턴스(아래 L이라고 함). home.mydomain.com 영역에 대한 권한 있는 마스터입니다. 이 서버에 대한 쿼리는 작동하고 homedns.home.mydomian.com을 NS로 반환하고 IP 192.168.1.77을 추가 레코드로 반환합니다.

인터넷 및 로컬 이름을 확인하기 위한 바인딩9 인스턴스(아래에서 M이라고 함) 여기서는 전역 전달 옵션이 사용되지 않습니다. 구성된 전달 영역이 있습니다.

zone "home.mydomain.com" in {
        type forward;
        forward only;
        forwarders { 192.168.1.77; };
};

참고 1: mydomain.com은 기존에 등록된 도메인이지만 home.mydomain.com에 대한 기록은 없습니다.

참고 2: M의 바인딩9 버전은 매우 오래된 버전입니다: 9.8.1-P1

이 설정은 인터넷 연결이 켜져 있는 한 작동하지만 연결이 끊어지면 로컬 이름 쿼리에 응답하지 않습니다. 로그는 syslog입니다.

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.mydomain.com/A/IN': 192.168.1.77#53

연결이 설정되었을 때 성공적인 해결을 위해 네트워크를 캡처하면 M이 L로부터 응답을 받은 후 인터넷에서 mydomain.com에 대해 쿼리한다는 것을 알 수 있습니다. M이 클라이언트에 대한 응답에서 AUTHORITY SECTION이 변경됩니다.

L까지 파헤쳐 보세요:

;; ANSWER SECTION:
syslog.home.mydomain.com. 3600  IN      A       192.168.1.99

;; AUTHORITY SECTION:
home.mydomain.com.        3600  IN      NS      homedns.home.mydomain.com.

;; ADDITIONAL SECTION:
homedns.home.mydomain.com. 3600 IN      A       192.168.1.77

M까지 파헤쳐 보세요:

;; ANSWER SECTION:
syslog.home.mydomain.com. 2134  IN      A       192.168.1.99

;; AUTHORITY SECTION:
net.                    171334  IN      NS      j.gtld-servers.net.
net.                    171334  IN      NS      m.gtld-servers.net.
net.                    171334  IN      NS      i.gtld-servers.net.
net.                    171334  IN      NS      k.gtld-servers.net.
net.                    171334  IN      NS      g.gtld-servers.net.
net.                    171334  IN      NS      e.gtld-servers.net.
net.                    171334  IN      NS      h.gtld-servers.net.
net.                    171334  IN      NS      a.gtld-servers.net.
net.                    171334  IN      NS      d.gtld-servers.net.
net.                    171334  IN      NS      f.gtld-servers.net.
net.                    171334  IN      NS      b.gtld-servers.net.
net.                    171334  IN      NS      c.gtld-servers.net.
net.                    171334  IN      NS      l.gtld-servers.net.

나는 왜 M이 L의 답변을 클라이언트에게 반환하지 않고 전달된 영역에 대한 인터넷 쿼리를 피하려고 할 수 있는지에 대한 아이디어가 남아 있지 않은 이유를 이해하지 못합니다.

답변1

질문에 인용된 로그 항목은 해당 오류가 인터넷에 연결되어 있지 않을 때 실패하는 DNSSEC 검증과 관련되어 있음을 나타냅니다.

오류 메시지의 "유효한 DS 없음" 부분을 참고하세요.

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.example.com/A/IN': 192.168.1.77#53

아마도 이 정방향 영역에 도달하는 쿼리에 대한 답변은 일반적으로 공개 영역이 서명되지 않은 영역으로 존재하기 때문에 (즉, 적절한 영역 위임의 일부로 example.com아니오라는 증거가 있음 )에만 허용되지만 이 증거를 더 이상 가져올 수 없는 경우 인터넷에 연결되어 있지 않기 때문에 답변이 서명되어야 하는지 여부/방법을 더 이상 확인할 수 없으므로 답변을 더 이상 받아들일 수 없습니다.DSexample.com

한 가지 옵션은 영역에 서명 home.example.com하고 정적을 추가하는 것입니다.트러스트 앵커특히 이 구역에 대해.

또 다른 방법은 유효성 검사를 선택적으로 비활성화하는 것입니다. 현재 BIND에는validate-except다음과 같이 검증을 수행하지 않아야 하는 도메인 이름 목록을 지정할 수 있는 옵션입니다.

validate-except

이는 해당 이름이나 그 위에 트러스트 앵커가 있는지 여부에 관계없이 DNSSEC 검증이 수행되지 않아야 하는 도메인 이름 목록을 지정합니다. 예를 들어, 루트 영역에서 해당 도메인에 대한 보안 위임이 없어도 유효성 검사가 실패하지 않도록 로컬 전용으로 의도된 최상위 도메인을 구성할 때 이 방법을 사용할 수 있습니다. (이는 영구 구성이라는 점을 제외하면 네거티브 트러스트 앵커를 설정하는 것과 유사합니다. 반면 네거티브 트러스트 앵커는 일정 기간 후에 만료되고 제거됩니다.)

또한 다음을 사용하여 유효성 검사를 완전히 비활성화할 수도 있습니다.dnssec-validation이 BIND 인스턴스가 이 특정 전달보다 더 광범위하게 사용되는 경우 권장하지 않는 옵션입니다.

example.com(참고 로 질문이 참조하는 도메인 이름이나 이를 소유한 기업과 관련이 없을 것 같아서 질문에 사용된 도메인 이름을 다음으로 대체했습니다 .)

관련 정보