인터넷상의 모든 도메인에 대한 모든 DNS 레코드를 하나의 파일로. 전체 그림을 파악한다는 것은 결국 이 문제로 귀결되며, 이를 해결하는 깔끔한 방법은 하나뿐입니다. 일주일 내내 리졸버를 두드리고도 인터넷의 절반에서 타임아웃이 나는 스크립트는 필요하지 않습니다. 필요한 것은 수억 개 이름에 대한 A, MX, TXT, NS 항목이 이미 수집, 파싱되어 바로 조회할 수 있는 상태로 준비된 것입니다. 이것이 바로 구매하는 대상입니다.
DNS 레코드란 무엇인가?
DNS 레코드는 인터넷 주소록의 한 줄입니다. 어떤 이름이 어디에 있고 어떻게 도달할 수 있는지를 세상에 알려줍니다. 웹에서 어떤 서버가 응답하는지, 이메일이 어디로 가는지, 어떤 네임서버가 권한을 가지는지 등을 담고 있습니다. 활성화된 이름은 모두 이러한 레코드를 여러 개 보유하며, 이를 합치면 해당 도메인의 운영상 지문이 됩니다.
반복해서 마주치게 되는 몇 가지 레코드 유형이 있습니다.
| 레코드 | 기능 | 예시 값 |
|---|---|---|
A |
도메인을 IPv4 주소로 연결합니다 | 93.184.216.34 |
AAAA |
도메인을 IPv6 주소로 연결합니다 | 2606:2800:220:1:: |
CNAME |
한 이름을 다른 이름의 별칭으로 만들며, 존 정점(zone apex)에는 사용할 수 없습니다 | cdn.example.com |
MX |
도메인의 이메일을 라우팅합니다 | mail.example.com (우선순위 10) |
TXT |
자유 형식 텍스트, SPF와 인증 토큰을 담습니다 | v=spf1 include:_spf.google.com ~all |
NS |
도메인의 권한 있는 네임서버 | ns1.cloudflare.com |
SOA |
존의 시작 권한(start-of-authority) 메타데이터 | 기본 NS, serial, refresh, retry, expire |
CAA |
어떤 기관이 인증서를 발급할 수 있는지 | letsencrypt.org |
하나의 이름에 대해 이 모든 것을 가져오면 그 이름이 어떻게 호스팅되는지, 누가 메일을 운영하는지, 소유자가 설정한 보안 수준까지 알 수 있습니다. 모든 이름에 대해 한 번에 가져오면 인터넷 전체 인프라의 지도를 손에 넣게 됩니다. 가질 가치가 있는 것은 바로 이 두 번째 데이터셋이며, 누구도 공짜로 내주지 않는 것이기도 합니다.
실질적인 역할을 하는 레코드들
이 중 소수의 유형이 대부분의 신호를 담고 있습니다. A 레코드는 대부분의 사람이 떠올리는 레코드로, 이름을 IPv4 주소에 매핑해 브라우저가 어떤 서버에 접속해야 하는지 알려줍니다. MX 레코드는 이메일에 대해 같은 역할을 하며, 메시지를 받는 서버의 이름과 우선순위를 지정합니다. TXT 레코드는 이메일 보안의 조용한 일꾼입니다. 도메인 자체에는 누가 그 이름으로 메일을 보낼 수 있는지 나열하는 SPF 레코드가 있습니다. 짝을 이루는 DKIM 서명 키와 DMARC 정책은 전용 하위 이름(_domainkey, _dmarc)에 존재하며, 이 셋을 합치면 주소가 얼마나 잘 보호되는지 알 수 있습니다. 실제로 무언가를 강제하는 것은 레코드의 존재 자체가 아니라 DMARC 정책이기 때문입니다. NS 레코드는 해당 존에 응답하는 권한 있는 서버의 이름을 담고 있으며, 이를 통해 실제로 누가 그 이름의 해석을 담당하는지 알 수 있습니다.
모든 DNS 레코드를 직접 수집할 수 없는 이유
이론적으로는 반복문 안에서 dig 명령으로 모든 이름을 조회할 수 있습니다. 하지만 실제로는 이 계획이 금방 무너집니다. 도메인은 수억 개에 달하고, 모든 유형을 확보하려면 각 도메인마다 여러 번의 쿼리가 필요하므로 결국 수십억 건의 조회를 마주하게 됩니다. 공개 리졸버는 속도를 제한하다가 작업을 끝내기 훨씬 전에 차단해 버립니다. 권한 있는 서버도 속도를 조절합니다. 타임아웃, 재시도, 일시적 실패로 인해 단 한 번의 전체 수집도 완전할 수 없으며, 크롤링이 진행되는 동안에도 데이터는 계속 바뀌기 때문에 결과가 도착했을 때는 이미 낡은 데이터가 되어 있습니다.
그다음은 파싱 문제입니다. 원시 응답은 깔끔하게 정리된 내보내기 파일이 아니라 와이어 포맷 패킷입니다. 이 수십억 개의 패킷을 실제로 조회 가능한 깔끔한 타입 기반 항목으로 바꾸는 작업은 크롤링과는 별개의 엔지니어링 프로젝트입니다. 대부분의 팀은 이 작업을 시작했다가 한 분기를 통째로 잡아먹는 것을 지켜본 뒤 조용히 포기합니다.
게다가 이런 실패는 무작위로 일어나는 것도 아닙니다. 대형 제공업체들은 대량 조회를 의도적으로 제한하므로, 크롤링이 철저할수록 더 빨리 차단당합니다. GeoDNS를 사용하는 권한 있는 서버는 위치에 따라 다른 응답을 돌려주므로, 단일 지점에서 조회하면 특정 지역에서만 나타나는 레코드를 조용히 놓치게 됩니다. 이 모든 문제를 우회하도록 설계를 마칠 즈음에는, 결국 누군가 이미 완성된 형태로 판매하고 있는 데이터를 유일한 결과물로 내놓는 작은 분산 시스템을 만들어낸 셈이 됩니다.
이것이 바로 webatla가 이미 해결한 문제입니다. 저희는 롤링 스케줄에 따라 전체 네임스페이스를 조회하고, 모든 응답을 구조화된 JSON으로 파싱하여 완성된 데이터셋을 제공합니다. 크롤링도, 차단도, 파싱도 건너뛰고 곧바로 데이터로 향할 수 있습니다.
webatla가 모든 레코드를 수집하는 방법
직접 진행하는 크롤링과의 차이는 분산과 인내심에 있습니다. webatla는 롤링 스케줄에 따라 여러 지점에서 네임스페이스를 조회하므로 어떤 리졸버도 집중적으로 두드리지 않으며, 모든 응답은 내보내기에 도달하기 전에 검증되고 타입 기반 항목으로 파싱됩니다. 한 번의 조회에 실패한 이름은 다음 회차에 다시 시도되므로, 커버리지는 시간이 지나며 줄어드는 것이 아니라 늘어납니다. 그 결과물은 처음부터 정말로 원했던 바로 그것입니다. 디버깅해야 할 패킷 더미가 아니라, 모든 이름에 대한 깔끔한 타입 기반 항목입니다.
모든 DNS 레코드를 하나의 파일로
webatla DNS 데이터셋은 모든 DNS 레코드를 한 번에 확보하는 문제에 대한 답입니다. 저희가 추적하는 모든 도메인의 A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, DNSSEC 항목을 수집하고 파싱해 하나의 깔끔한 데이터셋으로 만들었습니다. 모든 TLD를 아우르며, 롤링 방식으로 재구축되고, 도착하는 즉시 조회할 수 있는 JSONL 형식으로 제공됩니다.
직접 운영해야 할 리졸버 팜도, 파싱해야 할 패킷도, 도메인별로 싸워야 할 속도 제한도 없습니다. 한 번 구매하면 단일 계정에서 인터넷상의 모든 레코드를 가져올 수 있으며, 몇 개월이 아니라 몇 분 만에 분석에 착수할 수 있습니다.
각 줄은 어떤 모습인가
각 줄은 하나의 이름과 그 전체 그림을 담고 있습니다. 값 자체와 더불어, 모든 행에는 데이터를 마지막으로 확인한 시점과 조회 성공 여부가 함께 담겨 있어 각 응답이 얼마나 최신인지 항상 확인할 수 있습니다.
{"domain":"example.com","dnsAt":"2026-06-22","dnsStatus":"TRUE","dnsRecords":{"A":["93.184.216.34"],"MX":[{"host":"mail.example.com","priority":10}],"NS":["a.iana-servers.net","b.iana-servers.net"],"TXT":["v=spf1 -all"],"SOA":{"mname":"ns.icann.org","serial":2026062201,"refresh":7200}}}
| 필드 | 의미 |
|---|---|
domain |
레코드가 속한 도메인 |
dnsRecords |
이름별로 키가 지정된 모든 유형(A, MX, TXT 등) |
dnsAt |
이 도메인의 DNS를 마지막으로 확인한 날짜 |
dnsStatus |
조회 성공 여부 |
각 도메인의 등록 정보까지 필요하십니까? RDAP 및 WHOIS 데이터셋을 함께 활용하십시오. DNS, 등록 정보, 기술 스택을 한곳에서 보고 싶으십니까? All Data 번들이 이를 모두 합쳐 제공합니다.
파일을 다루는 방법
JSONL 형식으로 한 줄에 도메인 하나씩 담겨 있으므로, 메모리에 전부 올리지 않고도 jq, DuckDB, pandas, Spark로 스트리밍할 수 있습니다. 몇 가지 예시입니다.
모든 이름과 그 메일 서버를 가져옵니다.
jq -c '{domain, mx: .dnsRecords.MX}' dns.jsonl
네임서버가 Cloudflare에서 운영되는 모든 이름을 찾습니다.
jq -c 'select(.dnsRecords.NS[]? | test("cloudflare"))' dns.jsonl > cloudflare-dns.jsonl
데이터를 바로 대상으로 SPF 레코드를 게시한 이름의 개수를 셉니다.
grep -c '"v=spf1' dns.jsonl
마지막 한 줄로 인터넷 전체에 걸친 이메일 보안 질문에 몇 초 만에 답할 수 있습니다. 저희는 같은 데이터를 사용해 네임서버와 레지스트라 집중도를 분석했으며, 방법은 동일합니다. 파일 하나, 조회 한 번, 실제 답 하나.
완전한 DNS 데이터셋으로 할 수 있는 것
모든 항목이 하나의 조회 가능한 데이터셋 안에 모이면, 비용이 많이 들던 여러 문제가 한 줄짜리 필터로 압축됩니다. 가치는 누구나 손으로 실행할 수 있는 단일 조회에 있는 것이 아닙니다. 그것들을 한꺼번에 보유한다는 데 있으며, 그 덕분에 예전에는 백만 개의 이름을 크롤링해야 했던 질문이 이미 가지고 있는 데이터셋을 스캔하는 작업으로 바뀝니다.
패턴은 언제나 같습니다. 어려운 부분은 한 번도 분석 자체였던 적이 없습니다. 진짜 어려운 부분은 애초에 완전하고 최신이며 구조화된 데이터를 확보하는 것, 그것도 한 분기 내내 크롤러를 돌보는 팀 없이 해내는 것이었습니다. 그 병목을 제거하면, 오후 한나절 만에 답할 수 있는 질문들이 예전에는 프로젝트와 예산이 필요했던 질문들이 됩니다. 지불하는 대상은 영리한 쿼리가 아닙니다. 영리한 쿼리를 사소한 것으로 만들어주는, 깔끔하게 완성된 입력 데이터입니다.
- 대규모 이메일 보안. 모든 이름의 SPF 레코드와 메일 설정을 확인해 스푸핑 가능한 수신함을 찾거나, 고객 기반을 감사하거나, 이메일 제공업체별로 시장 규모를 파악할 수 있습니다.
- 공격 표면 매핑. A, AAAA, CNAME 레코드를 추적해 도메인과 그 서브도메인이 실제로 어디로 연결되는지, 어떤 호스트를 공유하며 클러스터를 이루는지 확인할 수 있습니다. 이 A 레코드를 IP 기준으로 그룹화하면 이 내보내기 데이터는 호스팅 도메인 데이터베이스가 됩니다.
- 제공업체 인텔리전스. 도메인을 NS 또는 MX 기준으로 그룹화해 누가 인터넷의 DNS와 이메일을 운영하는지 측정하고, 마이그레이션이 발생하는 순간을 추적할 수 있습니다.
- DNSSEC 도입 현황. DS, DNSKEY, RRSIG 레코드 수를 세어 어떤 존이 서명되어 있고 어떤 존이 그렇지 않은지 확인할 수 있습니다.
- 인증서 위생 관리. CAA 레코드는 어떤 기관이 해당 이름의 인증서를 발급하도록 신뢰받는지 보여주므로, 포트폴리오 전체에 걸친 잘못된 설정을 한 번에 찾아낼 수 있습니다.
- 마이그레이션 추적. 기업이 이메일이나 호스팅을 마이그레이션할 때는 MX와 NS 항목이 가장 먼저 바뀌므로, 이 두 레코드 유형을 시간에 따라 관찰하면 공식 발표 전에 마이그레이션 사실을 알아낼 수 있습니다.
이 모든 항목은 같은 출발점을 필요로 합니다. 손으로 직접 조회한 샘플이 아니라, 전체 도메인 네임스페이스에 대한 완전하고 최신인 DNS 레코드 세트입니다.
언제나 최신, 일회성 덤프가 아닙니다
DNS는 고정된 것이 아닙니다. 사이트가 호스트를 옮기면 A 레코드가 바뀌고, 이메일 마이그레이션 중에는 MX 레코드가 바뀌며, 누군가 보안 정책을 업데이트할 때마다 TXT 레코드가 달라집니다. 6개월 전에 조회한 파일은 이미 박물관에나 있을 유물입니다.
webatla DNS 데이터셋은 롤링 스케줄에 따라 재구축되며, 모든 이름은 각자의 dnsAt 타임스탬프를 가지고 있어 각 항목이 얼마나 최신인지 항상 확인할 수 있습니다. 작업에 필요한 주기에 맞춰 다시 받으면, 각 파일은 오늘의 DNS를 그대로 반영합니다.
자주 묻는 질문
어떤 DNS 레코드 유형이 포함됩니까? A, AAAA, CNAME, MX, TXT, NS, SOA, CAA를 비롯해 모든 도메인이 사용하는 일반적인 유형과, 존재하는 경우 DS, DNSKEY, RRSIG 같은 DNSSEC 레코드까지 포함됩니다. 모든 데이터는 타입 기반 JSON으로 파싱되므로 원시 패킷을 직접 다룰 일이 없습니다.
몇 개의 도메인을 다룹니까? webatla가 추적하는 모든 TLD에 걸친 도메인의 DNS 레코드로, 수억 개에 달하는 도메인이 하나의 파일에 담겨 있습니다.
MX 레코드나 TXT 레코드만 받을 수 있습니까?
네. 파일에는 도메인별 모든 레코드 유형이 담겨 있으므로, jq나 SQL 필터 한 줄이면 MX 레코드만, SPF 문자열만, 또는 필요한 어떤 부분이든 뽑아낼 수 있습니다. 이는 별도 구매가 아니라 하나의 필터일 뿐입니다.
어떤 형식입니까?
한 줄에 도메인 하나씩 담긴 깔끔한 JSONL이며, DNS 레코드는 구조화된 JSON 형태입니다. jq, DuckDB, pandas, BigQuery에 바로 넣을 수 있습니다.
데이터는 얼마나 최신입니까?
롤링 스케줄에 따라 재구축되며, 각 도메인은 dnsAt 날짜를 가지고 있어 레코드가 얼마나 신선한지 확인할 수 있습니다. 낡은 일회성 덤프가 아닙니다.
레코드를 IP 소유권이나 위치에 매칭할 수 있습니까? A와 AAAA 레코드가 IP 주소를 제공하므로, 이를 IP 인텔리전스 소스와 조인하면 ASN은 신뢰성 있게, 지리적 위치는 근사치로 확인할 수 있습니다.
레코드가 서브도메인도 포함합니까? 이 세트는 등록된 이름을 기준으로 키가 지정되며, 그 이름에 게시된 항목을 담고 있습니다.
비용은 얼마입니까? 단일 계정으로 한 달간 이용할 수 있는 단일 정액 요금입니다. 현재 가격은 요금 안내를 참고하십시오.
모든 DNS 레코드 다운로드
끝내기도 전에 차단당하는 리졸버 팜을 직접 구축하는 일은 이제 그만두십시오. webatla DNS 데이터셋 다운로드 →에서 A부터 DNSSEC까지 모든 도메인의 모든 DNS 레코드를 오늘 바로 조회 가능한 깔끔한 JSONL로 받으실 수 있습니다. 등록 정보와 기술 데이터도 함께 필요하십니까? All Data 번들이 DNS와 나머지 모든 것을 한곳에 담아 제공합니다. 「모든 DNS 레코드가 필요하다」에서 실제로 그것을 손에 넣기까지 가장 빠른 길입니다.