이 글의 목적은 Windows 환경에서 “DNS 동적 업데이트 실패”로 인해 클라이언트가 DNS 서버에 자신의 레코드를 등록하지 못하는 문제를 재현·분석·해결할 수 있도록, 시스템 관리자 관점의 실무형 점검 절차와 설정 예시를 정리하는 것이다.
1. DNS 동적 업데이트와 클라이언트 등록의 기본 개념
Active Directory 도메인 환경에서 클라이언트 컴퓨터는 기본적으로 자신의 호스트 이름과 IP 주소를 DNS 서버에 자동 등록한다. 이를 DNS 동적 업데이트(dynamic update)라고 하며, 다음과 같은 방식으로 동작한다.
- 클라이언트가 IP 주소를 얻은 직후 또는 네트워크 설정이 변경되면 DNS 클라이언트 서비스가 A/PTR 레코드 등록을 시도한다.
- DHCP를 사용하는 환경에서는 DHCP 서버가 대신 A/PTR 레코드를 등록하거나, 클라이언트가 직접 등록하도록 설정할 수 있다.
- Active Directory 통합 DNS 존에서는 일반적으로 “보안(secure) 동적 업데이트만 허용”으로 설정하여, 도메인에 가입된 컴퓨터 계정만 레코드를 수정할 수 있게 한다.
DNS 동적 업데이트가 실패하면 클라이언트의 이름으로 DNS 조회 시 잘못된 IP가 응답되거나, 아예 레코드가 존재하지 않게 된다. 이 경우 아래와 같은 문제가 나타날 수 있다.
- 원격 접속, 파일 공유, 프린터 공유 시 컴퓨터 이름으로 연결이 실패한다.
- 도메인 로그인, 그룹 정책 적용이 느려지거나 실패한다.
- 서버 측 이벤트 로그에 NETLOGON, DNS Client 관련 경고와 오류가 반복해서 기록된다.
2. 증상 정리: 이벤트 로그와 실제 현상
Windows 클라이언트에서 DNS 동적 업데이트 실패는 주로 이벤트 로그에서 다음과 같은 형태로 나타난다.
2.1 클라이언트에서 자주 보이는 이벤트
- DNS Client 이벤트
- “시스템이 네트워크 어댑터에 대해 호스트(A) 자원 레코드를 등록하지 못했다”는 내용의 경고
- “DNS 서버가 동적 업데이트 요청을 거부했다”는 내용의 경고
- NETLOGON 관련 이벤트
- “하나 이상의 DNS 레코드에 대한 동적 등록 또는 등록 취소가 실패했다”는 내용의 경고
- 도메인 컨트롤러에서 특히 자주 나타나며, 클라이언트에서도 유사한 메시지가 기록되는 경우가 있다.
이벤트 메시지에서 중요한 부분은 다음과 같다.
- “No DNS servers configured for local system” 또는 “로컬 시스템에 구성된 DNS 서버가 없다”는 메시지: TCP/IP 설정에 DNS 서버가 올바르게 설정되어 있지 않거나, 네트워크 문제로 응답을 받지 못한 경우이다.
- “RCODE=5” 또는 “Refused”와 같이 응답 코드가 거부로 표시되는 경우: DNS 서버가 동적 업데이트를 거부하거나 보안 권한 문제로 인해 등록이 실패한 경우이다.
2.2 서버(도메인 컨트롤러/DNS)에서 보이는 경고
도메인 컨트롤러나 DNS 서버의 시스템 로그에는 다음과 같은 경고가 기록되는 경우가 많다.
- NETLOGON 5774, 5781, 5782 등: 도메인 컨트롤러가 자신의 레코드 또는 클라이언트 레코드를 동적으로 등록·삭제하는 과정에서 실패했음을 의미한다.
- DNS Server 이벤트: 특정 존에 대한 동적 업데이트가 거부되었거나, 권한 부족, 존 구성 문제로 인해 업데이트가 실패했음을 나타낸다.
클라이언트 등록 문제가 단순 클라이언트 설정 문제인지, DHCP 서버·DNS 서버·도메인 전체 구성 문제인지를 구분하기 위해서는 클라이언트와 서버 양쪽 이벤트 로그를 모두 확인하는 것이 좋다.
3. 1차 점검: 클라이언트 IP 및 DNS 설정 확인
클라이언트 측 설정이 잘못되면 아무리 서버 측 구성을 올바르게 해도 동적 업데이트가 이루어지지 않는다. 다음 절차를 우선적으로 수행한다.
3.1 ipconfig /all로 DNS 서버 설정 확인
- 클라이언트에서 명령 프롬프트를 관리자 권한으로 실행한다.
- 다음 명령을 입력하여 현재 네트워크 구성을 확인한다.
ipconfig /all 여기서 반드시 확인해야 할 항목은 다음과 같다.
- DNS 서버: 도메인 환경에서는 일반적으로 도메인 컨트롤러(AD 통합 DNS 서버)의 IP만 설정한다.
- 기본 게이트웨이: 잘못된 게이트웨이는 DNS 서버까지의 통신을 방해할 수 있다.
- 연결별 DNS 접미사와 기본 DNS 접미사: 도메인 이름과 일치하는지 확인한다.
주의 : 도메인에 가입된 클라이언트에 공용 DNS(예: 8.8.8.8, 1.1.1.1)를 직접 추가하면 동적 업데이트 및 도메인 이름 조회에 문제가 생길 수 있다. 도메인 환경에서는 내부 AD DNS 서버만 사용하도록 구성하는 것이 원칙이다.
3.2 네트워크 어댑터 DNS 등록 옵션 확인
DNS 동적 업데이트는 네트워크 어댑터 속성의 설정에 따라 수행 여부가 달라진다. 다음 순서로 확인한다.
- 제어판 → 네트워크 및 인터넷 → 네트워크 및 공유 센터 → 어댑터 설정 변경을 연다.
- 사용 중인 이더넷 또는 Wi-Fi 어댑터를 우클릭하고 “속성”을 선택한다.
- “인터넷 프로토콜 버전 4(TCP/IPv4)”를 선택하고 “속성” → “고급” 버튼을 클릭한다.
- 상단의 “DNS” 탭을 선택하여 다음 항목을 확인한다.
- “이 연결의 주소를 DNS에 등록”이 체크되어 있어야 한다.
- 도메인에 가입된 PC라면 “이 연결의 DNS 접미사를 등록” 또는 기본 DNS 접미사 사용 설정이 도메인 이름과 일치해야 한다.
이 항목이 해제되어 있으면 클라이언트가 자신의 호스트 이름을 DNS에 등록하지 않으므로, 동적 업데이트 실패가 발생할 수밖에 없다.
3.3 클라이언트에서 DNS 재등록 시도
기본 설정이 정상이라면 클라이언트에서 수동으로 동적 업데이트를 다시 시도해 본다.
ipconfig /flushdns ipconfig /registerdns 두 번째 명령을 실행한 직후 시스템 이벤트 로그의 DNS Client, NETLOGON 관련 이벤트를 확인하여 오류 코드와 메시지가 어떻게 변하는지 확인한다. 이 시점에서 오류가 사라진다면 일시적인 네트워크 문제였을 가능성이 높고, 여전히 실패한다면 서버 측 설정 또는 권한 문제일 가능성이 크다.
4. DHCP가 DNS를 대신 업데이트하는 환경 점검
많은 조직에서는 DHCP 서버가 클라이언트를 대신해 DNS에 A/PTR 레코드를 등록하도록 구성한다. 이 경우 DHCP의 설정이 잘못되면 클라이언트가 정상적으로 IP를 받더라도 DNS 등록이 이루어지지 않는다.
4.1 DHCP 서버의 동적 업데이트 옵션
Windows DHCP 서버를 예로 들면, 스코프 속성 또는 서버 속성의 “DNS” 탭에서 다음과 같은 옵션을 확인한다.
- “클라이언트가 요청하는 경우에만 DNS A 및 PTR 레코드를 동적으로 업데이트”
- “항상 DNS 레코드를 동적으로 업데이트”
- “이 DHCP 서버가 클라이언트의 A/PTR 레코드를 삭제하도록 허용” 옵션
Active Directory 환경에서 일반적으로 추천되는 설정은 다음과 같다.
- DHCP 서버가 클라이언트를 대신하여 A와 PTR 레코드를 등록한다.
- 클라이언트의 IP가 변경되거나 임대가 해제될 때 이전 레코드를 적절히 삭제한다.
4.2 DHCP 자격 증명(DNS 업데이트 자격 증명)
DNS 존이 “보안 동적 업데이트만 허용”으로 설정되어 있을 경우, DHCP 서버가 레코드를 생성·수정하려면 AD 도메인의 계정 권한을 사용해야 한다. 이를 위해 다음 항목을 점검한다.
- DHCP 서버 속성에서 DNS 동적 업데이트에 사용할 도메인 계정(예: 전용 서비스 계정)을 지정한다.
- 해당 계정에 DNS 존 및 레코드 생성 권한이 있는지 확인한다.
- 필요하다면 DHCP 서버를 DnsUpdateProxy 그룹에 추가하여 중복 갱신 시 권한 충돌을 줄인다.
4.3 DHCP와 DNS 점검을 위한 요약 표
| 구분 | 점검 항목 | 확인 포인트 |
|---|---|---|
| 클라이언트 | DNS 서버 설정, DNS 등록 옵션 | ipconfig /all 출력에서 AD DNS만 사용, “이 연결의 주소를 DNS에 등록” 체크 |
| DHCP 서버 | DNS 동적 업데이트 옵션 | 클라이언트 요청 여부, 항상 업데이트 여부, A/PTR 삭제 옵션 설정 |
| DHCP 자격 증명 | 도메인 계정 사용 여부 | DNS 업데이트용 전용 계정 지정, 암호 만료 여부 및 권한 확인 |
| DNS 서버 | 존 유형 및 동적 업데이트 허용 | AD 통합 존 여부, “보안 동적 업데이트만 허용” 설정 확인 |
| AD/그룹 정책 | DNS 등록 관련 정책 | 클라이언트 DNS 등록을 차단하는 정책이 적용되어 있지 않은지 확인 |
5. DNS 서버 측 설정: 존 구성과 권한 문제
클라이언트와 DHCP 설정이 정상인데도 여전히 “DNS 동적 업데이트 실패, 클라이언트 등록 안됨” 문제가 발생한다면 DNS 서버 자체의 존 구성 및 권한을 점검해야 한다.
5.1 존 속성: 동적 업데이트 허용 여부
DNS 관리자에서 문제가 발생하는 존의 속성을 열고 다음 항목을 확인한다.
- 존 유형이 Active Directory 통합(AD-integrated)인지 여부
- 동적 업데이트 설정이 “허용 안 함”으로 되어 있지 않은지 여부
- 도메인 환경에서는 “보안만(secure only)” 설정이 일반적이다.
만약 존이 파일 기반 기본(primary) 존으로만 존재하고 AD와 연동되지 않았다면, 도메인 컨트롤러 및 클라이언트 등록이 불안정할 수 있으므로 AD 통합 존으로 마이그레이션하는 것이 바람직하다.
5.2 레코드 소유권과 보안 권한
특정 클라이언트만 반복적으로 등록에 실패한다면 해당 호스트 이름의 기존 레코드 소유권이 문제일 수 있다.
- DNS 관리자에서 해당 호스트 이름(A 레코드)의 보안 탭을 열어 레코드의 소유자와 권한을 확인한다.
- 예전에 다른 컴퓨터 계정이나 사용자 계정이 만든 레코드라면 현재 클라이언트 계정이 수정 권한을 갖지 못해 동적 업데이트가 거부될 수 있다.
- 이 경우 오래된 레코드를 삭제하고 클라이언트에서 다시 ipconfig /registerdns를 실행하여 새 레코드를 만들게 하거나, 보안 ACL에 현재 컴퓨터 계정을 추가한다.
주의 : 문제 해결을 위해 간단히 “Everyone: 수정 허용”과 같이 과도한 권한을 부여하면 보안 위험이 커진다. 가능하면 컴퓨터 계정 또는 DHCP 업데이트용 서비스 계정에만 최소한의 권한을 부여하는 방식으로 조정한다.
5.3 역방향 조회 존(Reverse Lookup Zone) 확인
PTR 레코드 등록 실패도 동적 업데이트 실패로 보고되며, 일부 응용 프로그램은 역방향 조회 결과에 의존한다. 다음을 확인한다.
- 사용 중인 서브넷(예: 192.168.0.0/24)에 해당하는 역방향 조회 존이 존재하는지 확인한다.
- 해당 존 역시 동적 업데이트를 허용하도록 설정한다.
- PTR 레코드가 중복되거나 잘못된 IP로 남아 있지 않은지 점검한다.
6. 클라이언트 DNS 재등록 실무 절차(체크리스트)
실제 장애 현장에서 바로 적용할 수 있도록 클라이언트 한 대 기준으로 단계별 절차를 정리하면 다음과 같다.
- 클라이언트에서 ipconfig /all로 DNS 서버가 내부 AD DNS로만 설정되어 있는지 확인한다.
- 네트워크 어댑터 고급 DNS 설정에서 “이 연결의 주소를 DNS에 등록” 체크 여부를 확인한다.
- 관리자 권한 명령 프롬프트에서 다음 명령을 실행한다.
ipconfig /flushdns ipconfig /release ipconfig /renew ipconfig /registerdns - 실행 직후 이벤트 뷰어에서 “Windows 로그 → 시스템”을 열고 DNS Client, NETLOGON, TCPIP 관련 이벤트를 시간 순으로 확인한다.
- DNS 서버에서 해당 클라이언트 이름으로 A/PTR 레코드가 새로 생성되었는지 확인한다.
- 다른 PC에서 해당 클라이언트 이름으로 ping, nslookup 테스트를 수행하여 이름→IP 변환이 올바른지 검증한다.
- 여전히 실패한다면 DHCP 서버와 DNS 서버에서 동적 업데이트 옵션, 자격 증명, 존 권한을 순차적으로 점검한다.
7. 이벤트 코드와 RCODE로 원인 좁히기
동적 업데이트 실패의 근본 원인을 정확히 파악하려면 이벤트 로그에 기록된 오류 코드와 DNS 응답 코드를 함께 보는 것이 중요하다.
- “No DNS servers configured for local system”
- 클라이언트 TCP/IP 설정에서 DNS 서버가 비어 있거나 잘못된 IP로 설정된 경우이다.
- 네트워크 장애로 DNS 서버까지의 통신이 되지 않는 경우에도 동일 메시지가 나타날 수 있다.
- “RCODE=5” 또는 “Refused”
- DNS 서버가 요청을 거부했다는 의미이다.
- 동적 업데이트 미허용, 보안 권한 부족, 존 구성 오류 등 서버 측 설정 문제일 가능성이 높다.
- “NXDOMAIN”, “Name error”
- 존이 존재하지 않거나, 잘못된 DNS 접미사로 등록을 시도하는 경우이다.
- 클라이언트의 DNS 접미사 설정 또는 도메인 구조를 다시 확인해야 한다.
가능하다면 네트워크 트레이스를 사용하여 클라이언트와 DNS 서버 사이의 동적 업데이트 패킷을 캡처하고, 어떤 이름으로 어떤 존에 업데이트를 시도하는지 확인하면 원인 분석이 훨씬 명확해진다.
8. 운영 환경에서의 예방 전략
“DNS 동적 업데이트 실패, 클라이언트 등록 안됨” 문제를 반복해서 겪지 않으려면 다음과 같은 운영 상의 예방 전략을 세워두는 것이 좋다.
- 표준 네트워크 구성 정의
- 도메인 클라이언트용 표준 TCP/IP 설정(내부 DNS만 사용)을 문서화하고, 그룹 정책 또는 이미지 배포로 일관되게 적용한다.
- 정기 점검
- 주기적으로 DNS 존에서 오래된 레코드를 정리하고, DHCP 임대 정보와 불일치하는지 확인한다.
- 도메인 컨트롤러의 NETLOGON, DNS 관련 이벤트를 정기적으로 검토한다.
- 역방향 조회 존 관리
- 새 서브넷을 추가할 때마다 대응되는 역방향 조회 존을 함께 생성한다.
- 동적 업데이트 정책이 정방향 존과 일관되도록 유지한다.
- 권한 및 계정 관리
- DHCP DNS 업데이트용 서비스 계정의 암호 만료·잠금 여부를 모니터링한다.
- DNS 존과 레코드 ACL 변경 내역을 기록하고, 불필요한 Everyone 권한을 제거한다.
FAQ
Q1. 클라이언트에서 ipconfig /registerdns를 실행하면 항상 문제가 해결되는가?
A1. 그렇지 않다. 이 명령은 클라이언트가 DNS에 다시 등록을 시도하게 할 뿐이며, 서버 측에서 동적 업데이트를 허용하지 않거나 권한 문제가 있는 경우에는 여전히 실패한다. ipconfig /registerdns 후 이벤트 로그 메시지가 어떻게 바뀌는지를 확인하여, 클라이언트 문제인지 서버 문제인지 구분하는 용도로 활용하는 것이 좋다.
Q2. 공용 DNS 서버(8.8.8.8 등)를 함께 넣어도 되는가?
A2. 도메인에 가입된 Windows 클라이언트에서는 가급적 내부 AD DNS만 사용해야 한다. 공용 DNS가 함께 설정되어 있으면 도메인 컨트롤러 조회, SRV 레코드 검색, 동적 업데이트가 모두 불안정해질 수 있다. 공용 DNS는 방화벽이나 프록시에서 처리하고, 클라이언트는 내부 DNS를 통해 외부 이름을 조회하도록 구성하는 것이 일반적인 설계이다.
Q3. DHCP가 DNS를 업데이트하도록 구성한 환경에서 클라이언트도 동시에 등록해도 되는가?
A3. 이론적으로는 가능하지만, 실무에서는 권장하지 않는다. 동일한 이름에 대해 클라이언트와 DHCP가 서로 다른 계정으로 레코드를 소유하려고 하면 권한 충돌과 업데이트 실패가 발생할 수 있다. 한쪽 주체(DHCP 또는 클라이언트)만 책임지고 동적 업데이트를 수행하도록 설계를 단순화하는 것이 좋다.
Q4. DNS 존을 “보안 동적 업데이트만 허용”으로 바꾸면 어떤 점을 주의해야 하는가?
A4. 이 설정은 보안상 바람직하지만, 그에 따라 컴퓨터 계정 또는 DHCP 서비스 계정이 반드시 해당 존에 레코드를 만들 수 있는 권한을 가져야 한다. 기존에 익명 또는 Everyone 권한으로 만들어진 레코드가 많다면 권한 재조정 과정에서 일시적으로 업데이트 실패가 발생할 수 있으므로, 변경 전후로 테스트 환경에서 검증하는 것이 안전하다.
Q5. 동적 업데이트를 아예 사용하지 않고 수동으로 레코드를 관리해도 되는가?
A5. 소규모·정적인 서버 환경이라면 가능하지만, DHCP로 IP가 자주 바뀌는 클라이언트가 많은 조직에서는 현실적이지 않다. 수동 관리 시 레코드 누락·오타·갱신 지연이 빈번하게 발생하여, 오히려 장애 원인이 되기 쉽다. 도메인 환경에서는 동적 업데이트를 기본으로 하고, 중요한 서버 레코드만 추가 검증 절차를 두는 방식이 일반적이다.