90분 DNS 전파, 이제는 수 초 컷! 자체 DNS 서버 구축 비법 공개

Hetzner DNS의 레코드 제한 및 전파 속도 문제로 자체 DNS 서버 구축을 결정, 확장성(Scalability)과 속도 개선(Speed Improvement)을 목표로 함

Go 언어 기반의 1,000줄 코드, Hidden Primary 패턴 및 Postgres를 활용한 DNS 서버 아키텍처 설계

DNS 전파 시간(Propagation Time)을 최대 90분에서 수 초로 단축, DNS 성능 대폭 향상(Significant DNS Performance Boost)

IXFR(Incremental Zone Transfer) 미지원으로 인한 초기 문제 발생, 이후 IXFR 구현을 통해 안정성 확보

Hidden Primary 패턴: DNS 서버 아키텍처 핵심

본문에서 소개된 Hidden Primary 패턴(Hidden Primary Pattern)은 DNS 서버의 가용성을 높이고, 유연한 DNS 관리 환경을 제공한다. 이 패턴은 퍼블릭 DNS 쿼리(Public DNS Query)를 처리하지 않는 숨겨진 Primary 서버를 두고, AXFR(AXFR)을 통해 Secondary 서버로 존 데이터를 전송한다.

장점: DNS 서버 변경(DNS Server Change) 시, Primary 서버만 변경하면 되므로, Secondary 서버 설정을 일일이 수정할 필요가 없다.

기술적 특징: Postgres(Postgres)를 이벤트 버스(Event Bus)로 활용하여, DNS 레코드 변경 시 Secondary 서버에 알림을 전송한다. 이를 통해, DNS 레코드의 전파 시간(Propagation Time)을 단축하고, 시스템의 확장성(Scalability)을 확보한다.

Postgres를 활용한 DNS 레코드 관리

저자는 Postgres(Postgres)를 DNS 레코드의 단일 진실 공급원(Single Source of Truth)으로 사용하고, LISTEN/NOTIFY 기능을 활용하여 DNS 레코드 변경을 감지한다. 이는 별도의 메시지 큐(Message Queue) 없이, Postgres(Postgres) 자체의 기능을 활용하여 시스템을 단순화한다.

LISTEN/NOTIFY: DNS 레코드 변경 시, pg_notify(pg_notify) 함수를 호출하여 Secondary 서버에 알림을 전송한다.

장점: 인프라 운영 비용(Infrastructure Cost)을 절감하고, 시스템 복잡도(System Complexity)를 줄인다.

단점: 대량의 레코드 변경(Massive Record Change)이 빈번하게 발생하는 경우, Postgres(Postgres)의 부하가 증가할 수 있다. 하지만, 본 사례에서는 레코드 변경 빈도(Record Change Frequency)가 낮아 문제가 되지 않았다.

AXFR 및 IXFR: DNS 존 데이터 전송 프로토콜

DNS 서버는 AXFR(AXFR) 및 IXFR(IXFR) 프로토콜을 사용하여 Secondary 서버로 존 데이터를 전송한다. AXFR은 전체 존 데이터를 전송하는 방식이며, IXFR은 변경된 레코드만 전송하는 증분 전송 방식(Incremental Transfer Method)이다.

AXFR: 초기 존 데이터 전송에 사용되며, 모든 레코드를 전송한다.

IXFR: SOA(SOA) 시리얼 번호(Serial Number)를 비교하여 변경된 레코드만 전송한다.

문제점: Hetzner Robot의 Secondary 서버는 IXFR을 지원하며, IXFR 미지원 시 AXFR로의 폴백(Fallback)이 제대로 동작하지 않아, 초기 DNS 전파에 문제가 발생했다. 이후 IXFR을 구현하여 문제를 해결했다.