- 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 기반 전파, 다중 리전 네임서버를 제공함
- 무료 가입과 문서를 제공함
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요청을 보내 새 존을 프로그래밍 방식으로 등록할 수 있음
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 코드를 스캔하고 코드를 검증하는 절차로 구성됨
관련 링크
댓글과 토론
Hacker News 의견들
-
스웨덴의 네트워크 엔지니어 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류 공격을 하는 식의 보안 문제가 생기지 않는지 걱정됨
어렴풋이 이런 게 보안상 금기였던 기억이 있음
- DDNS 분야 전문가는 아니지만, 비슷한 기능을 제공하는 desec.io도 살펴볼 만함
-
피치는 꽤 좋아 보이지만, 지금 바로 써볼 시간은 없음
다만 여기 댓글의 설명을 읽지 않았다면 랜딩 페이지에서 바로 탭을 닫았을 것 같음
너무 직설적이라 미안하지만, 페이지가 흔한 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아래 업데이트를 지켜보면 됨
- BIND는 RFC 2136을 포함해 여러 가지를 할 수 있고, 현재 구조로 정하기 전에 여러 옵션을 살펴봤음
-
RFC 2136 지원은 보너스 점수를 줄 만하고, external-dns와 쉽게 동작함
몇 년째 온프레미스 Kubernetes와 external-dns를, 공개 호스트의 최소 구성 자체 호스팅 BIND 서버와 함께 쓰고 있음- external-dns + RFC 2136 조합은 좋은 포인트임
이미 플릿 운영 가이드는 있고, Kubernetes 패턴은 자연스러운 확장이니 가이드를 써야 할 듯함
- external-dns + RFC 2136 조합은 좋은 포인트임
-
예전에는 OpenWrt DDNS 스크립트를 직접 만들어 AWS Route 53이나 Cloudflare DNS를 갱신했고, 그걸로 충분히 해결됐음
이후 Tailscale이 나오고 나서는 DDNS나 CGNAT에 더 이상 신경 쓰지 않게 됨- Tailscale, Netbird, WireGuard 모두 훌륭하고 지금은 이런 도구들이 있어서 정말 좋은 시대임
https://dynip.dev/guides/tailscale에 서로 어떻게, 왜 공존할 수 있는지 설명한 가이드를 써두었음
OpenWrt DDNS 스크립트는 키와 비밀값 때문에 좀 번거롭지만, snippet 기능이 “어떻게 동작하지?”를 추측하지 않게 해줘서 꽤 만족하고 있음 - 지금은 둘 다 씀
공개 서비스에는 DynIP를 쓰고, 나만 접근하면 되는 것에는 Tailscale을 써서 공격 표면이 크게 줄었음
다행히 CGNAT는 신경 쓰지 않아도 됨
- Tailscale, Netbird, WireGuard 모두 훌륭하고 지금은 이런 도구들이 있어서 정말 좋은 시대임
-
가입을 시도했지만 검증 메일이 도착하지 않음
가입 직후 메일 서버 로그에도 비슷한 흔적이 없었고, 몇 번 재전송을 요청했는데도 6~7시간 뒤까지 메일함에 아무것도 없음- 검증되지 않은 모든 이메일에 대해 재전송을 트리거했으니 새 검증 토큰이 생겼을 수 있음
- 주소를 알려주면 확인해보겠음
-
무료 티어의 인증 토큰이 24시간 뒤 만료되는 게 맞는지 궁금함
JWT의exp클레임을 봤고, 마이그레이션에 시간을 쓰기 전에 이 부분을 알고 싶음
핵심은 무료 티어가 지속 가능한지임- “long-lived token”은 실제 DNS 업데이트용 TSIG 키가 아니라, 존 생성·삭제·조회나 Terraform식 자동화에 쓰는 관리 API 토큰을 뜻함
모든 존은 모든 티어에서 자체 TSIG 키를 받고, 실제 업데이트는 그 키가 담당함
무료 티어는 대시보드로 존을 관리하고, 유료 티어는 프로그램 방식 관리를 위한 API 토큰을 추가로 제공함
따라서 인증 토큰은 API용 bearer로 쓰는 것이고, TSIG는 도메인이 삭제되지 않는 한 계속 유효함
무료 티어는 존 5개를 허용하고 각각 개별 TSIG 키가 항상 활성화되므로, 수백 개 존을 만들고 갱신·삭제하는 식이 아니라면 결제할 필요가 없음
- “long-lived token”은 실제 DNS 업데이트용 TSIG 키가 아니라, 존 생성·삭제·조회나 Terraform식 자동화에 쓰는 관리 API 토큰을 뜻함
-
훌륭한 댓글과 질문이 많아 고맙고, 몇 시간 동안 딸 수영 수업에 데려갔다가 돌아와서 스레드를 계속 보겠음
- 수영도 좋고, 유체역학도 중요함
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만 포함하는 것이 아니라 더 넓은 기능 기반을 다루려는 중임
- dyndns식