셀프호스팅 DDNS 설정: TSIG 키를 최소 권한으로 제한하는 법

공인 IP가 바뀔 때 집 서버나 소규모 서비스의 DNS 레코드를 자동으로 고치는 일은 평범해 보인다. 하지만 나는 이 자동화를 볼 때 “갱신되었나?”보다 **그 비밀키를 가진 클라이언트가 어디까지 바꿀 수 있나?**를 먼저 확인한다. 2026년 7월 19일 공개돼 Hacker News 새 글에 오른 Mohamed Akram의 셀프호스팅 DDNS 가이드는 Knot DNS와 nsupdate로 이 경로를 직접 구성하는 방법을 보여준다. DNS UPDATE 자체는 1997년 RFC 2136으로 표준화된 오래된 프로토콜이다. 새로워진 것은 개인 서버·원격 개발 환경·홈랩이 늘면서 이 오래된 쓰기 권한을 다시 많이 열고 있다는 현실이다. 좋은 DDNS는 IP를 빠르게 반영하는 기능만이 아니라, 키가 탈취돼도 home.example.com의 A/AAAA 레코드 밖으로 피해가 번지지 않게 만드는 권한 설계다. 달빛 아래에서 보면 DDNS는 편의 기능이 아니라 작은 배포 파이프라인이다.

DDNS는 DNS 조회가 아니라 DNS 쓰기 권한이다

일반 DNS 레코드는 대개 Git 저장소, DNS 사업자 콘솔, IaC 도구처럼 통제된 경로에서 바뀐다. DDNS는 네트워크 이벤트가 발생할 때 클라이언트가 권한 서버에 UPDATE 요청을 보내 레코드를 추가하거나 삭제한다. RFC 2136은 이 UPDATE가 사전 조건을 만족하면 원자적으로 처리된다고 정의한다. 즉 한 요청 안의 전제 조건이 맞지 않으면 변경이 일어나지 않는다. 이 성질은 재시도와 상태 검증에 유용하지만, 인증 범위를 자동으로 좁혀 주지는 않는다.

nsupdate 매뉴얼도 DDNS가 존 파일을 직접 편집하지 않고 레코드를 추가·삭제한다고 설명하며, 동적으로 관리되는 존을 손으로 수정하면 갱신과 충돌해 데이터를 잃을 수 있다고 경고한다. 같은 문서는 TSIG(Transaction SIGnatures)가 클라이언트와 이름 서버만 아는 공유 비밀을 바탕으로 UPDATE를 인증한다고 명시한다. 여기서 TSIG 키는 로그인 비밀번호보다 API 쓰기 토큰에 가깝다. 키를 복사한 프로세스는 서버가 허락한 업데이트를 서명해 보낼 수 있다.

그래서 “TSIG를 켰다”만으로는 부족하다. 먼저 다음 경계를 문서로 정해야 한다.

• 주체: IP 변화를 감지하는 장비 또는 updater 프로세스는 무엇인가.
• 대상 이름: home.example.com. 하나인가, 하위 도메인 전체인가.
• 레코드 타입: A와 AAAA만 필요한가, TXT·MX·CNAME까지 필요한가.
• 유효 범위: 키가 example.com. 존 전체를 바꿀 수 있는가, 특정 이름만 바꿀 수 있는가.
• 검증 경로: 갱신 뒤 권한 서버와 외부 resolver에서 무엇을 확인할 것인가.

Knot DNS에서는 키보다 ACL의 모양이 더 중요하다

Akram의 가이드는 Knot DNS의 keymgr -t로 TSIG 키를 만들고, key, acl, zone 블록을 연결하는 출발점을 제시한다. 이 방식은 테스트에는 충분하지만, 운영 설정을 그대로 “키가 있으면 update 허용”으로 끝내면 해당 키가 그 존에서 바꿀 수 있는 범위가 너무 넓어진다.

Knot DNS 공식 설정 문서는 동적 업데이트 ACL에 update-type, update-owner, update-owner-match, update-owner-name 같은 추가 제한을 둘 수 있다고 설명한다. 예컨대 갱신기 한 대가 home.example.com.의 주소만 갱신해야 한다면, 권한의 단위를 존 전체가 아니라 이름 하나 + A/AAAA 타입으로 잡아야 한다. 아래는 그 의도를 드러내는 예시다. 실제 키의 secret 값은 비밀 관리 경로에서 넣고, 저장소·셸 히스토리·로그에 넣지 않는다.

# /etc/knot/knot.conf — 의도를 좁힌 DDNS ACL 예시
key:
  - id: ddns-home.example.com.
    algorithm: hmac-sha256
    secret: "<secret-from-secret-store>"

acl:
  - id: update-only-home-address
    key: ddns-home.example.com.
    action: update
    update-type: [A, AAAA]
    update-owner: name
    update-owner-match: equal
    update-owner-name: [home.example.com.]

zone:
  - domain: example.com.
    acl: update-only-home-address

이 블록은 “이 키가 example.com. 아래 아무 이름이나 바꾼다”는 기본 상태를 피한다. 또 A/AAAA 외에 MX나 TXT를 고치는 요청을 막아, 키 유출이 메일 라우팅·도메인 검증·다른 서비스 설정으로 번지는 일을 줄인다. Knot 문서에서 ACL 규칙은 지정 순서대로 적용되고, 첫 번째로 일치한 규칙이 선택된다고 설명한다. 허용 규칙보다 앞에 둔 넓은 예외가 의도치 않게 전체 권한을 열 수 있다는 뜻이다. ACL은 YAML 문법보다 위에서 아래로 읽는 권한 정책으로 리뷰해야 한다.

가벼운 반론도 있다. 개인 도메인 하나에 이렇게 세밀한 제한은 과하다는 주장이다. 갱신 실패를 고치는 일이 더 귀찮아 보일 수 있다. 그러나 DDNS 키는 보통 인터넷 연결이 바뀔 때마다 자동 실행되는 장비에 오래 남는다. 그 장비의 백업, 로그, 설정 복사본이 늘어날수록 키 노출 표면도 늘어난다. 가장 작은 정상 권한을 먼저 열면, 나중에 TXT 갱신 같은 요구가 생겼을 때도 예외를 명시적으로 추가하게 된다.

갱신은 성공 로그가 아니라 사전·사후 검증으로 운영한다

실제 DDNS updater는 부팅 직후, DHCP lease 변경 뒤, 주기적 타이머에서 여러 번 실행될 수 있다. 따라서 “명령이 exit 0으로 끝났다”만 기록하면 불충분하다. UPDATE 요청은 권한 서버에 닿지 못할 수 있고, 키·ACL·존 이름이 틀리면 거절될 수 있으며, 외부 DNS 캐시에는 이전 값이 남을 수 있다.

BIND의 nsupdate는 RFC 2136 UPDATE를 이름 서버에 제출하는 도구이며 -k keyfile로 TSIG 키 파일을 받을 수 있다. 아래는 단일 A 레코드를 갱신한 뒤 권한 서버에서 확인하는 최소 절차다. <...> 부분은 실제 환경 값으로 교체하고, 비밀이 담긴 키 파일의 권한은 updater 계정만 읽을 수 있게 제한해야 한다.

# 1) UPDATE 권한과 대상 레코드를 명시한다.
nsupdate -k /etc/ddns/home.key <<'EOF'
server ns1.example.com
zone example.com.
update delete home.example.com. A
update add home.example.com. 300 A 203.0.113.42
send
EOF

# 2) 권한 서버에 직접 질의해 새 값과 TTL을 확인한다.
dig @ns1.example.com home.example.com. A +noall +answer

검증은 두 층으로 나누는 편이 낫다. 첫째, 권한 서버 질의로 UPDATE가 실제 존 데이터에 반영됐는지 본다. 둘째, 외부 resolver 또는 실제 접근 경로로 캐시·방화벽·IPv6 경로까지 확인한다. TTL 300은 예시일 뿐이다. 짧은 TTL은 변경 전파를 빠르게 하지만 resolver 질의를 늘린다. 서비스가 끊길 수 있는 순간에는 “IP 탐지 → UPDATE → 권한 서버 확인 → 외부 확인”을 하나의 상태 전이로 로그에 남겨야 원인을 분리할 수 있다.

운영자가 확인할 다섯 가지 실패 경로

DDNS를 한 번 붙여 놓고 잊기 쉬운 이유는 정상일 때 너무 조용하기 때문이다. 그래서 장애가 나기 전에 실패 경로를 정해 둬야 한다.

1. 키 노출: 키를 리포지터리나 셸 명령 인자에 넣지 않는다. nsupdate -k처럼 키 파일을 쓰고 파일 소유자·권한을 updater 전용으로 제한한다.
2. 과권한 ACL: action: update만 둔 넓은 규칙을 피한다. 이름, 타입, 가능하면 업데이트 주체의 네트워크 범위도 함께 제한한다.
3. 주소 종류 혼동: A와 AAAA 갱신을 별도 성공 조건으로 본다. IPv4만 고쳤는데 클라이언트가 IPv6를 우선하면 서비스는 계속 이전 주소로 갈 수 있다.
4. 수동 편집 충돌: 동적 관리 레코드를 DNS 콘솔이나 존 파일에서 수동으로 고치지 않는다. 변경 책임자를 updater 한 경로로 고정한다.
5. 관측 없는 재시도: 실패를 무한 재시도하지 않는다. 마지막 성공 IP, 요청 시간, 거절 코드, 권한 서버 확인 결과를 남기고 일정 횟수 뒤 경보로 넘긴다.

내 의견: DDNS의 품질은 자동 갱신률이 아니라 피해 반경으로 측정해야 한다

내 의견은 명확하다. DDNS를 편리한 네트워크 유틸리티로만 보면 “갱신 성공률”이 유일한 지표가 된다. 하지만 실제 운영에서 더 중요한 것은 탈취되거나 오작동한 updater가 어떤 DNS 자산까지 손댈 수 있는가다. 최소 권한 TSIG 키, 이름·타입 제한 ACL, 권한 서버 검증은 작은 개인 도메인에서도 값싼 안전장치다. 다만 모든 IP 변경을 실시간으로 DNS에 반영해야 하는 것은 아니다. 외부 공개가 필요 없거나 접속자가 제한된 서비스라면 VPN·overlay network·고정 egress 같은 대안을 비교하는 편이 더 단순할 수 있다. 핵심은 DDNS가 필요한 경우에만, 쓰기 권한을 가장 좁은 단위로 열자는 것이다.

김덕환 운영자 관점

김덕환 운영자 관점에서는 홈랩, 원격 작업기, 에이전트용 서비스 엔드포인트를 하나의 DDNS 키로 묶지 않는 것이 중요하다. 역할마다 키를 분리하고, 각 키가 갱신할 호스트명과 레코드 타입을 정책에 적어 두면 IP가 바뀌는 평범한 날에도 DNS 변경을 설명하고 되돌릴 수 있다. 자동화가 편해질수록, 변경 범위를 설명하는 설정이 운영비를 낮춘다.

참고 자료

• Self-Hosted Dynamic DNS — Mohamed Akram, 2026-07-19
• Hacker News: Self-Hosted Dynamic DNS — 2026-07-20 확인
• RFC 2136: Dynamic Updates in the Domain Name System
• Knot DNS Configuration: Dynamic updates and restricting dynamic updates
• BIND 9 nsupdate manual