오늘 흥미로운 문제에 직면했습니다. 누군가 xxx1.pt와 xxx2.pt라는 두 도메인의 또 다른 상황에 대한 임시방편으로 DNS/BIND에서 두 개의 MX 레코드를 급히 변경했습니다.
따라서 이 레코드의 특정 TTL을 미리 줄이기 위한 조치는 취해지지 않습니다.
2주 TTL 이내에 변경이 이루어졌습니다.
흥미롭게도 Google DNS 공개 서버에 대한 답변이 정확히 동일하지 않다는 것이 나에게 지적되었습니다.
8.8.8.8로 테스트하면 여전히 이전 주소의 문제가 해결되고 새 주소로 이상한 대답이 반환됩니다.
SOA 시리즈는 확실히 업데이트되었습니다. 로컬 프로세스/구성을 통해 사람들이 업데이트하는 것을 잊지 않도록 자동으로 업데이트되기 때문입니다.
그래서 누군가 나에게 왜 이런 이상한 대답이 나오는지, 뭔가 조치를 취할 수 있는지 물었습니다.BIND 측에서.
게다가매우 긴급하다Google 측의 캐싱 문제 해결과 관련하여, 원인은 이 문제와 관련이 없습니다.
BIND 측에서는 무엇을 할 수 있나요?
답변1
여기서 분명한 것은 BIND 측에서 할 수 있는 일은 아무것도 없다는 것이다.
RR 레코드의 TTL이 2주인 경우 DNS 서버가 여전히 캐시에 주소를 유지할 위험이 항상 있습니다.
구글도막연하게 암시하는 것 같아일부 도움말 페이지에서는 긴 TTL을 준수합니다.최소 3일 이상.
더 흥미로운 점은 새 주소에 대한 이상한 대답은 Google DNS CDN/클러스터의 일부 DNS 서버가 캐시를 플러시하고 새 주소를 얻었거나 도메인을 본 적이 없거나 변경 중일 수 있기 때문일 수 있다는 것입니다. 이전 주소는 실제로 본 적이 없습니다). 아니면 때로는 CDN/다른 DNS 클러스터의 다른 지점이 답변을 반환하기 때문일 수도 있습니다. 조사되지 않았습니다.
8.8.8.8 DNS 서비스는 단일 서버에서 제공되지 않고 그 뒤에 복잡한 인프라가 있기 때문에 집에 더 가깝다면 다른 답변이 있다는 것은 특별히 놀라운 일이 아닙니다.
Google DNS 서버 측 캐싱에 관해서는 대중이 임의의 DNS RR 레코드를 전역적으로 새로 고칠 수 있는 매우 흥미로운 페이지를 발견했습니다.여기
문제 도메인에 대한 MX 레코드 캐시를 수동으로 새로 고치고 테스트 Google 공개 DNS 서버를 다시 사용한 후에는 dig이미 새로운 RR 데이터가 응답되었습니다.