# DynIP – RFC 2136, IPv6, DNSSEC, BYOD를 지원하는 동적 DNS > Clean Markdown view of GeekNews topic #29935. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29935](https://news.hada.io/topic?id=29935) - GeekNews Markdown: [https://news.hada.io/topic/29935.md](https://news.hada.io/topic/29935.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-28T07:39:16+09:00 - Updated: 2026-05-28T07:39:16+09:00 - Original source: [dynip.dev](https://dynip.dev/) - Points: 1 - Comments: 1 ## Topic Body - **DynIP**는 홈랩, 엣지 라우터, 인프라 팀용 동적 DNS 서비스로, 60초 업데이트와 무료 티어를 제공함 - **RFC 2136 TSIG**, REST API, UDP/53 업데이트를 지원하며 FortiGate, OPNsense, OpenWRT, MikroTik과 통합됨 - **IPv6**를 IPv4와 함께 지원해 A·AAAA 레코드를 나란히 갱신하며, 듀얼스택과 IPv6 전용 존을 모두 다룸 - **DNSSEC**는 서명 키 생성, 부모 존 게시, 레코드 서명을 자동화하며 Let’s Encrypt 인증서 발급에 필요함 - **BYOD**로 보유 도메인을 연결해 동적 서브도메인을 만들 수 있지만, ns1.dynip.dev와 ns2.dynip.dev 위임이 필요함 --- ### DynIP 개요 - **DynIP**는 홈랩, 엣지 라우터, 인프라 팀을 위한 동적 DNS 서비스로, 60초 업데이트, 무료 티어, RFC 2136 TSIG, 자체 도메인 사용, DNSSEC를 내세움 - 라우터가 업데이트를 보내면 호스트명이 전 세계에서 약 **60초** 안에 올바르게 해석되도록 설계됨 - 60초 TTL, NOTIFY 기반 전파, 다중 리전 네임서버를 제공함 - [무료 가입](https://dynip.dev/#signup-form)과 [문서](https://dynip.dev/docs)를 제공함 ### DNS 표준과 라우터 통합 - **RFC 2136 TSIG**를 지원해 FortiGate, OPNsense, OpenWRT, DNS UPDATE 지원 라우터에서 사용할 수 있음 - MikroTik 사용자는 네이티브 **HTTP API** 통합을 사용할 수 있음 - 지원 방식은 RFC 2136 TSIG, REST API, UDP/53 네이티브 업데이트를 포함함 - 설정 스니펫 화면에서 장치 유형, 대상 IP 주소, 도메인, TSIG 키를 기반으로 설정 블록을 생성해 복사할 수 있음 - 새 존이 네임서버로 전파되는 동안 FortiGate의 RFC 2136/TSIG 업데이트는 대기해야 함 - cURL, PowerShell, Python, MikroTik 같은 **HTTP API 업데이트**는 즉시 동작함 ### IPv6와 DNSSEC - **IPv6**를 IPv4와 함께 지원해 A와 AAAA 레코드를 나란히 업데이트할 수 있음 - 듀얼스택 구성과 IPv6 전용 존을 모두 지원함 - Let’s Encrypt 인증서를 발급하려면 해당 존에서 **DNSSEC**가 활성화돼야 함 - DNSSEC를 켜면 서명 키 생성, 부모 존 게시, 모든 DNS 레코드 서명이 자동으로 수행됨 - DNSSEC 설정은 일회성 절차이며, 이후 해당 존은 계속 서명된 상태로 유지됨 - 예상 소요 시간은 30초로 표시됨 ### 빠른 시작과 존 관리 - 빠른 시작은 장치 이름 입력, 기본 도메인 선택, **Create Zone** 클릭으로 존을 만드는 흐름임 - 새 도메인 옆의 Snippets 버튼에서 설정을 가져오고, 장치 유형을 선택한 뒤 생성된 설정 블록을 라우터 CLI에 복사함 - IPv4와 IPv6는 들어오는 연결을 기준으로 자동 감지되고 업데이트됨 - 존 목록은 도메인과 도구, 현재 IP, TSIG Secret, DNSSEC, SSL 인증서 상태를 표시함 - 각 존에서 잠금 상태, 스니펫, 삭제, 알림, 동기화 시각, DNSSEC 켜기·끄기, SSL 인증서 다운로드·갱신·발급을 관리할 수 있음 ### 자체 도메인 사용 - **Custom Namespaces(BYOD)** 기능으로 보유 도메인을 DynIP에 연결하고, 해당 네임스페이스 아래에 동적 서브도메인을 만들 수 있음 - 네임스페이스를 활성화하려면 도메인 등록기관에 두 개의 NS 레코드를 모두 만들어야 함 - 단일 NS 위임은 거부됨 - 필요한 NS 레코드는 `ns1.dynip.dev`와 `ns2.dynip.dev`임 - 설정 검증은 위임 활성 상태 또는 등록기관에서 필요한 조치를 확인하는 흐름으로 제공됨 ### 빠른 동기화와 자동화 - **Quick Sync**는 선택한 존을 현재 장치의 외부 IP 주소와 즉시 맞추는 기능임 - 감지된 네트워크 IP를 표시하고, 사용자가 선택한 존을 한 번에 업데이트할 수 있음 - 세션 토큰으로 `/register` 엔드포인트에 `POST` 요청을 보내 새 존을 프로그래밍 방식으로 등록할 수 있음 ```bash curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \ -H "Authorization: Bearer {{ token }}" ``` - 세션 토큰은 로그아웃 시 만료되므로 장기 자동화에는 API 토큰을 사용해야 함 - **API tokens**는 Pro 이상 기능이며, 모니터링 스크립트, CI 파이프라인, MSP 통합 같은 자동화에 사용할 수 있음 - API 토큰은 로그아웃해도 만료되지 않으며, 읽기 전용 또는 전체 접근 범위로 제한하고 언제든 폐기할 수 있음 - 새 API 토큰은 생성 시 한 번만 표시되므로 비밀번호 관리자나 시크릿 저장소에 보관해야 함 ### 요금제와 계정 보안 - 요금제 화면은 구독 티어, 상태, 갱신일 또는 접근 종료일, 결제 주기, 사용 중인 존 수와 최대 도메인 수를 표시함 - 요금제가 다운그레이드되면 가장 오래된 허용 개수의 존만 활성 상태로 유지되고, 나머지 존은 잠겨 IP 업데이트를 받을 수 없음 - 결제 실패 시 접근 유지를 위해 결제 수단 업데이트가 필요함 - 계정 보안은 이메일 2FA와 **TOTP**를 지원하며, TOTP가 활성화되면 이메일 2FA를 대체함 - TOTP 설정은 Google Authenticator, Authy 또는 선호하는 2FA 앱에서 QR 코드를 스캔하고 코드를 검증하는 절차로 구성됨 ### 관련 링크 - [Documentation](https://dynip.dev/docs) - [Guides](https://dynip.dev/guides/) - [Contact](https://dynip.dev/contact) - [Pricing](https://dynip.dev/pricing) ## Comments ### Comment 58395 - Author: neo - Created: 2026-05-28T07:39:18+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48276363) - 스웨덴의 네트워크 엔지니어 Daniel이고, 기존 DDNS 서비스들이 2010년대식 네트워크에 머물러 있다고 느껴서 **DynIP**를 만들었음 독자 HTTP 전용 업데이트 프로토콜, 약한 IPv6 지원, DNSSEC 부재, 최신 장비 지원 부족이 반복됐고, DynIP는 **RFC 2136 / TSIG 업데이트**를 1급 경로로 다룸 FortiGate generic DDNS와 MikroTik `/tool dns-update`가 별도 클라이언트 없이 동작하고, 그 외 용도로 HTTP API도 제공함 권한 DNS 서버는 IPv6로 접근 가능하며 부모 `.dev` 존에 AAAA glue가 게시되어 있고, 고객 존은 A/AAAA를 발행하며 IPv6 전용 클라이언트도 지원함 선택된 존에서는 토글 하나로 DNSSEC를 켤 수 있고, 서브도메인 위임으로 자체 도메인을 가져올 수 있음 구조는 공개 트래픽을 받지 않는 숨은 primary와, 스웨덴·스위스의 지리적으로 분산된 secondary 2대가 TSIG를 로컬 검증한 뒤 primary로 전달하는 방식임 RFC 1918과 CGNAT 주소도 레코드에 허용해서, private APN의 셀룰러 플릿이 내부 IP를 가리키는 안정적인 공개 DNS 호스트명을 쓸 수 있게 했음 `ghcr.io/33k-org/dynip-updater`라는 작은 Docker 컨테이너도 있고, 스택은 PowerDNS 4.8 authoritative, FastAPI, Postgres, Postfix, Cloudflare, Paddle이며 `dynip.dev`에서 운영 중이고 무료 티어도 있음 - DDNS 분야 전문가는 아니지만, 비슷한 기능을 제공하는 **desec.io**도 살펴볼 만함 IPv6, DNSSEC, 자체 도메인 사용 같은 기능을 제공하고, 오픈소스 프로젝트이면서 안정적인 무료 호스팅 서비스도 운영함 문서에서 못 찾았을 수도 있지만, 이쪽에는 **IPv6 prefix delegation** 지원이 있어 ISP가 라우터에 할당한 IPv6 prefix가 바뀔 때 임의 도메인의 네트워크 prefix만 갱신할 수 있음 유럽에서는 이 prefix가 고정이 아니고 ISP 재접속 때마다 바뀌기 때문에, 호스트 부분은 유지하고 네트워크 부분만 자동 갱신하는 기능이 유용함 예: `/update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56` - Android의 **Firefox Focus**에서는 기본값인 추적 방지를 끄지 않으면 사이트가 동작하지 않음 이메일 확인 링크를 눌렀을 때 확인 완료나 상태 표시가 전혀 없어 꽤 헷갈렸음 - 대시보드에서 “change password”를 누르면 재설정 링크가 이메일로 오지만, 재설정 페이지는 **로그아웃된 세션**에서만 보임 로그인된 상태에서는 링크가 대시보드 홈으로 리다이렉트되므로, 보통 사용자는 비밀번호 변경 버튼을 누른 직후 이메일을 받기 때문에 먼저 로그아웃해야 함 이메일에 “먼저 로그아웃하라”는 문구를 넣거나, 링크가 현재 세션을 종료한 뒤 재설정 페이지를 보여주면 더 매끄러울 듯함 - 에이전트가 서비스를 구매할 수 있도록 **L402** 지원을 고려할 수 있는지 궁금함 - RFC 1918과 CGNAT 주소를 레코드에 허용하면, 남의 private server를 자기 도메인에 넣어 **XSS류 공격**을 하는 식의 보안 문제가 생기지 않는지 걱정됨 어렴풋이 이런 게 보안상 금기였던 기억이 있음 - 피치는 꽤 좋아 보이지만, 지금 바로 써볼 시간은 없음 다만 여기 댓글의 설명을 읽지 않았다면 랜딩 페이지에서 바로 탭을 닫았을 것 같음 너무 직설적이라 미안하지만, 페이지가 흔한 **AI 느낌의 양산형 랜딩 페이지**처럼 보이고, 실제로 그렇다는 뜻은 아니지만 설명이 좋은 만큼 개성을 더해 차별화하면 좋겠음 또 프로젝트 전용 Hacker News 계정은 만들지 않는 편이 좋음 “사용자명을 회사나 프로젝트명으로 하지 말라. HN을 홍보용으로 쓰는 느낌을 만들고, 사람으로서 참여하지 않는 것처럼 보인다. 실명을 쓸 필요는 없지만 브랜드가 아니라 인간으로 여기 있다는 신호는 있어야 한다. 사용자명을 바꾸고 싶으면 hn@ycombinator.com으로 메일하라.” [https://news.ycombinator.com/item?id=22336638]() [https://news.ycombinator.com/showhn.html]()도 참고하면 됨 - 좋은 지적이고 미안해할 필요 없음 지금은 알고 있는 것과 모르는 것, 희망과 꿈, 꽤 큰 기술 지식 덩어리가 있는 단계이고, 디자인 쪽은 강하지 않지만 당장은 괜찮다고 봄 - 여기 긴 댓글도 노골적인 **LLM 양산문**처럼 보임 Pangram 기준 100%이고, 사실 그런 도구가 없어도 알아볼 수 있을 정도라서, 여기서도 그걸 구분 못 하는 사람이 적지 않은 상황이 암울함 - 이 영역에 경쟁이 들어오는 건 반가움 다만 안정성이나 사용 편의성을 크게 신경 쓰지 않고 직접 호스팅하려면 **bind9**도 RFC 2136 DNS UPDATE와 DNSSEC를 지원함 내 구성에서는 집 라우터가 DNS UPDATE를 말하지 못해서 HTTP 요청을 변환하는 작은 Go 실행 파일도 직접 만들었음 - BIND는 RFC 2136을 포함해 여러 가지를 할 수 있고, 현재 구조로 정하기 전에 여러 옵션을 살펴봤음 FortiGate에서 몇 가지 테스트 케이스를 만들었고, DynIP도 처음에는 내부 DNS 위에 FortiGate 전용으로 단순 복붙해서 쓰는 형태에서 시작했음 Windows나 Linux의 여러 호스트에서 내부적으로 쓸 수 있는 코드 예제가 있고, 홈랩에 IoT 장비가 있다면 Arduino 예제도 있음 Go 실행 파일을 만드는 것도 좋은 방향이라 `/docs` 아래 업데이트를 지켜보면 됨 - **RFC 2136** 지원은 보너스 점수를 줄 만하고, [external-dns]([https://github.com/kubernetes-sigs/external-dns]())와 쉽게 동작함 몇 년째 온프레미스 Kubernetes와 external-dns를, 공개 호스트의 최소 구성 자체 호스팅 BIND 서버와 함께 쓰고 있음 - **external-dns + RFC 2136** 조합은 좋은 포인트임 이미 플릿 운영 가이드는 있고, Kubernetes 패턴은 자연스러운 확장이니 가이드를 써야 할 듯함 - 예전에는 OpenWrt DDNS 스크립트를 직접 만들어 AWS Route 53이나 Cloudflare DNS를 갱신했고, 그걸로 충분히 해결됐음 이후 **Tailscale**이 나오고 나서는 DDNS나 CGNAT에 더 이상 신경 쓰지 않게 됨 - Tailscale, Netbird, WireGuard 모두 훌륭하고 지금은 이런 도구들이 있어서 정말 좋은 시대임 [https://dynip.dev/guides/tailscale]()에 서로 어떻게, 왜 공존할 수 있는지 설명한 가이드를 써두었음 OpenWrt DDNS 스크립트는 키와 비밀값 때문에 좀 번거롭지만, snippet 기능이 “어떻게 동작하지?”를 추측하지 않게 해줘서 꽤 만족하고 있음 - 지금은 둘 다 씀 공개 서비스에는 **DynIP**를 쓰고, 나만 접근하면 되는 것에는 Tailscale을 써서 공격 표면이 크게 줄었음 다행히 CGNAT는 신경 쓰지 않아도 됨 - 가입을 시도했지만 **검증 메일**이 도착하지 않음 가입 직후 메일 서버 로그에도 비슷한 흔적이 없었고, 몇 번 재전송을 요청했는데도 6~7시간 뒤까지 메일함에 아무것도 없음 - 검증되지 않은 모든 이메일에 대해 재전송을 트리거했으니 새 검증 토큰이 생겼을 수 있음 - 주소를 알려주면 확인해보겠음 - 무료 티어의 인증 토큰이 24시간 뒤 만료되는 게 맞는지 궁금함 JWT의 `exp` 클레임을 봤고, 마이그레이션에 시간을 쓰기 전에 이 부분을 알고 싶음 핵심은 **무료 티어가 지속 가능한지**임 - “long-lived token”은 실제 DNS 업데이트용 TSIG 키가 아니라, 존 생성·삭제·조회나 Terraform식 자동화에 쓰는 **관리 API 토큰**을 뜻함 모든 존은 모든 티어에서 자체 TSIG 키를 받고, 실제 업데이트는 그 키가 담당함 무료 티어는 대시보드로 존을 관리하고, 유료 티어는 프로그램 방식 관리를 위한 API 토큰을 추가로 제공함 따라서 인증 토큰은 API용 bearer로 쓰는 것이고, TSIG는 도메인이 삭제되지 않는 한 계속 유효함 무료 티어는 존 5개를 허용하고 각각 개별 TSIG 키가 항상 활성화되므로, 수백 개 존을 만들고 갱신·삭제하는 식이 아니라면 결제할 필요가 없음 - 훌륭한 댓글과 질문이 많아 고맙고, 몇 시간 동안 딸 수영 수업에 데려갔다가 돌아와서 스레드를 계속 보겠음 - 수영도 좋고, **유체역학**도 중요함 [https://github.com/hickory-dns/hickory-dns]() 같은 것도 고려해봤는지 궁금함 물론 모든 걸 Rust로 만들 필요는 없지만 - 흥미로워 보이고, 집 서버에서 여러 서비스를 외부 클라이언트에 제공하려고 DDNS를 쓰고 있음 지금은 **NO-IP DDNS**를 쓰는데 무료 티어가 꽤 관대하지만, Let’s Encrypt 같은 것을 지원하지 않는 점이 불만임 Cloudflare에서 도메인을 살까 고민 중인데, DynIP가 구체적으로 무엇이 다른지 궁금함 - 현재 불만이 NO-IP에서 **Let’s Encrypt**를 쓸 수 없다는 점이라면, 이미 본인에게 차별점이 되는 기능을 찾은 셈임 - 2000년대식 **HTTP(S) 전용 업데이트**도 좋음 `curl`/`wget`/`fetch`만 있으면 어디서나 동작하고, 원하면 토큰만 추가하면 됨 duckdns도 아직 이런 방식을 지원하는 것 같고, 별도 클라이언트가 필요 없어 거의 어디서나 작동함 - dyndns식 `curl`/`wget`/`fetch`도 맞는 말이고, `/docs`에서 그 외에 할 수 있는 특수 기능들을 살펴보면 됨 여기서는 `curl`/`wget`/`fetch`만 포함하는 것이 아니라 더 넓은 기능 기반을 다루려는 중임