클라우드 DNS에서 발생한 비정상 NXDOMAIN 트래픽: 분석, 이전 및 교훈
2026년 3월, 클라우드 DNS의 공개 DNS 존에서 비정상 트래픽이 발생했습니다: NXDOMAIN 응답을 유발하는 쿼리가 초당 0.57회에서 2720회로 급증했습니다. 총 부하가 초당 2951회 쿼리로 증가하면서 청구 금액이 급격히 상승했습니다. 지원팀은 시의적절한 기술 분석을 제공하지 않아 존을 외부 호스팅으로 긴급 이전해야 했습니다.
지표는 NOERROR 쿼리보다 NXDOMAIN이 압도적으로 많음을 보여주었습니다. 비즈니스 이벤트 부재, 반복성, 제공업체의 설명 부족으로 인해 이 트래픽은 불법적인 것으로 판단되었습니다.
비정상 현상 상세
3월 22일 기준 정상 상태:
- A noerror: 초당 9.38회 쿼리
- A nxdomain: 초당 0.57회 쿼리
- 총계: 초당 9.96회 쿼리
3월 25일 비정상 상태:
- A nxdomain: 초당 2720.29회 쿼리
- A noerror: 초당 231.14회 쿼리
- 총계: 초당 2951.43회 쿼리
존에는 표준 레코드(A, CNAME, MX, TXT, NS)와 DKIM, DMARC, ACME용 서비스 레코드가 포함되어 있었습니다. 첫 번째 경고는 3월 7일부터 10일 사이에 발생했으며, 주요 사고는 3월 24일부터 31일까지 지속되었습니다.
트래픽은 다음과 같은 프로필로 인해 비정상으로 분류되었습니다: 합리적 이유 없이 NXDOMAIN이 우세한 점, 사건의 재발성, 지원팀의 응답 부족.
지원팀 응답 및 재정적 영향
지원팀에 문의한 결과는 없었습니다: 트래픽 분석 대신 동료를 기다리라는 일반적인 응답만 받았습니다. 존재하지 않는 이름에 대한 쿼리 비율에 따라 비용이 증가했습니다.
해결책: 이전 준비와 병행하여 클레임을 제출하는 것입니다. 우리는 존 파일 가져오기가 가능한 외부 DNS 호스팅을 선택했습니다.
이전 단계
- 레코드 내보내기:
yc dns zone list-records example-zone --format json > zone-records.json
JSON 구조:
{
"record_sets": [
{
"name": "*.service.example-company.ru.",
"type": "A",
"ttl": "300",
"data": [
"203.0.113.10"
]
},
{
"name": "_dmarc.example-company.ru.",
"type": "TXT",
"ttl": "300",
"data": [
"\"v=DMARC1; p=none; sp=none; rua=mailto:[email protected]\""
]
}
]
}
- JSON을 BIND 존 파일로 변환:
- 오리진에
@사용 - 이전 제공업체의 NS 레코드 제거
- 다중 TXT 레코드 풀기
- CNAME, ACME, DMARC 레코드 확인
- SOA 제외
예시 존 파일:
$TTL 1d
example-company.ru. IN SOA ns1.provider.example. hostmaster.ns1.provider.example. (
1
14400
3600
604800
10800
)
@ A 203.0.113.10
app A 203.0.113.20
www CNAME infra.example-company.ru.
모니터링 및 준비 권장사항
중급/시니어 데브옵스 및 SRE 대상:
- 응답 코드별 지표 모니터링: noerror, nxdomain, 부하 급증.
- 존 내보내기/변환 스크립트 준비.
- 이전 전 레코드 검토: NS, TXT(ACME/DKIM), 사설 IP.
별도 티켓: 기술 분석과 재정적 클레임을 분리 처리.
응답 없는 비정상 발생 시—플랜 B 활성화: 내보내기, 이전, 모든 내용 기록.
핵심 교훈
- NXDOMAIN 모니터링으로 청구 충격 방지.
yc dns zone list-records --format json를 통한 내보내기는 핵심 이전 단계.- 존 파일에서 제공업체 NS 레코드 제외로 충돌 방지.
- TXT/ACME 레코드 검토: 오래된 레코드 제거.
- 병렬 티켓 처리로 해결 속도 향상.
— Editorial Team
아직 댓글이 없습니다.