자주 변경되는 DNS 레코드? [닫은]

자주 변경 될 수있는 도메인 레코드는 어떻게 만듭니 까?

의 말을하자 example.org에 포인트를 203.0.113.0. 2 분 후을 가리켜 야합니다 198.51.100.0.

도메인 뒤에있는 일반 웹 사이트 (일반 웹 브라우저를 사용하여 액세스한다는 의미에서 "일반")이지만 수명이 매우 짧습니다. 도메인은 전환되거나 종료되기 전에 최대 3-4 시간 동안 주소를 가리 킵니다. 빈번한 쿼리로부터 DNS 서버를 보호 할 필요가 없습니다.

내 접근 방식은 TTL을 60 초로 설정하고 전환해야 할 때 단순히 레코드를 변경하는 것입니다. 최악의 경우 새 서버에 액세스하기 전에 사용자가 최대 60 초 동안 대기하게됩니다.

어쨌든 나는 이것을 믿지 않습니다 ... 일부 ISP 또는 브라우저는 TTL을 무시하거나 무시할 수 있습니까? 그것이 유효한 관심사라면 합리적인 TTL은 무엇입니까?

감사합니다!

이것을 Fast Flux DNS Records 라고 합니다. 그리고 일반적으로 맬웨어 작성자가 인프라 서버를 숨기는 방법입니다.

이것이 귀하의 계획에는 효과가 있지만 최선의 계획은 아닙니다. 여분의 서버 이상이 온라인 상태 여야하며 거의 아무것도하지 않아도됩니다. 기본 서버에 문제가있는 경우에만 다음 서버로 전환하십시오.

TTL이 1 분인 경우에도 하나의 레코드가 다음보다 더 유효합니다.

1. 브라우저 캐시

   브라우저는 일반적으로 가변 시간 동안 DNS 레코드를 캐시합니다. Firefox는 60 초 , Chrome도 60 초 , IE 3.x 및 이전 버전은 24 시간 동안 , IE 4.x 이상은 30 분 동안 캐시합니다.

2. OS 캐시

   Windows는 일반적으로 TTL을 존중하지 않습니다 . DND의 TTL은 IPv4 패킷의 TTL과 다릅니다. 필수 새로 고침보다 신선도를 나타냅니다. Linux는 DNS TTL을 무시하고 사용자가 원하는 시간을 설정하도록 nscd를 구성 할 수 있습니다. 예를 들어 일주일 동안 항목을 캐시 할 수 있습니다.

3. ISP 캐시

   ISP는 트래픽을 줄이기 위해 적극적인 캐싱을 사용할 수 있습니다. TTL을 변경할 수있을뿐만 아니라 업스트림 DNS 서버를 요청하지 않고도 레코드를 캐시하고 클라이언트에 반환 할 수 있습니다. 모바일 클라이언트가 트래픽 대기 시간에 대해 불평하지 않도록 TTL을 변경하므로 모바일 ISP에서 더 많이 사용됩니다.

로드 밸런서는 원하는대로 정확하게 수행합니다. 로드 밸런서를 설치하면로드를 나누어 2 개 또는 4 개 또는 10 개의 서버를 동시에 온라인 상태로 만들 수 있습니다. 이들 중 하나가 오프라인 상태가되면 서비스에 영향을 미치지 않습니다. DNS 레코드를 변경하면 서버가 꺼진 시간과 DNS가 변경되는 시간 사이에 다운 타임이 발생합니다. 가동 중지 시간을 감지하고 레코드를 변경 한 후 전파 될 때까지 기다려야하므로 1 분 이상이 소요됩니다.

따라서로드 밸런서를 사용하십시오. 그것은 당신이 원하는 것을하도록 만들어졌으며, 당신은 무엇을 기대해야하는지 정확하게 알고 있습니다. 빠른 플럭스 DNS 설정은 혼합 된 결과와 일관성이 없습니다.

DNS와 그 작동 방식에는 IT의 모든 측면에서 더 많은 오해, 범례, 미신 및 신화가 수반 될 수 있습니다.

우리가 변화의 "전파"에 대해 이야기 할 때 우리가 본질적으로 거짓말을하거나 (또는 ​​적어도 과도하게 단순화하고 있음) 알고있는 사람들조차도이 용어를 사용하여 매우 간단하고 간단한 것을 동시에 설명하는 경향이 있습니다 ... 그러나 설명하기가 어렵고 전파 자체 와는 관련이 없지만 캐싱 및 네거티브 캐싱과 관련된 모든 것은 시스템 작동 방식의 필수 구성 요소입니다. 본질적으로 실제 "전파"와 반대되는 내부-아웃 (in-out)-밀기 –

짧은 TTL에 대한 모든 걱정과 수고를 위해, 그들은 단순히 시험해 보는 것이 당신의 관심사에있을 수있을 정도로 더 자주 일하는 경향이 있습니다. $ {day_job}에 사이트가 "오래된"플랫폼에서 "새로운"플랫폼으로 마이그레이션 될 때 인프라의 어떤 것도 공유되지 않는 방식으로 마이그레이션되고 있음을 의미합니다. 이러한 마이그레이션의 첫 단계는 이전 TTL을 60 배로 떨어 뜨려 이전 TTL에 여러 배수가 없어서 TTL이 짧은 이러한 과도 적 RR이 "전파됨"을 합리적으로 보장합니다. " 컷을 할 준비가되면 인터넷을 통해 새로운 시스템에 트래픽을 고정하기 위해 기존 밸런서를 ¹로 재구성하여 밸런서가 더 이상 여러 내부 시스템의 밸런싱을 수행하지 않고 "

그런 다음 DNS를 컷 오버하고 새 밸런서와 이전을 봅니다.

나는 전환이 얼마나 빨리 일어나는지 항상 기쁘게 생각합니다. 유인물은 거의 항상 검색 스파이더와 오래된 레코드에 대한 예측이 불가능한 타사 "상태 확인"사이트 인 것 같습니다.

그러나 예측 가능한 세 가지 시나리오가 있습니다. 사용자의 브라우저 창이 열린 상태로 유지되면 이미 발견 된 주소에 고정되는 경향이 있으며 모든 브라우저 창이 닫힐 때까지 지속되는 경우가 많습니다.

그러나 위의 설명에서 문제에 대한 해결책을 찾을 수 있습니다. "로드 밸런서"-구체적으로 말하면 리버스 프록시는 노출 된 DNS 레코드가 가리키는 시스템 일 수 있습니다.

리버스 프록시는 요청을 올바른 대상 IP 주소로 전달합니다.이 주소는 실제 백엔드 서버를 가리키는 짧은 TTL을 가진 두 번째 "더미"호스트 이름을 사용하여 확인됩니다. ³ 프록시는 항상 더미 DNS를 입력하면 신속하고 완벽한 전환이 보장됩니다.

단점은 불필요한 추가 인프라를 통해 트래픽을 라우팅하거나 여러 네트워크 경계를 넘어서 전송하는 데 더 많은 비용을 지불 할 수 있다는 것입니다.

이러한 규모의 기능을 전 세계적으로 제공하는 서비스가 있으며 가장 친숙한 서비스는 CloudFront입니다. (아마도 내가 한 작은 테스트가 올바르게 작동한다는 것을 나타내며 다른 것들이 있다고 확신하기 때문에 Cloudflare는 정확히 동일한 목적을 수행합니다.)

기본적으로 CDN으로 판매되었지만 CloudFront는 선택적 으로 응답 캐싱 기능을 갖춘 글로벌 역 프록시 프록시 네트워크의 핵심 입니다. 경우 www.example.comCloudFront를하고 CloudFront를 포인트는 이러한 요청 전달하도록 구성되어 backend.example.com및 대한 DNS 레코드를 backend.example.com사용하는 짧은 TTL을 그 명예가하는 짧은 TTL 것을 때문에, 다음 CloudFront를가 옳은 일을 할 것입니다. 백엔드 레코드가 변경되면 TTL이 종료 될 때까지 트래픽이 모두 마이그레이션됩니다.

CloudFront를 가리키는 전면 레코드의 TTL과 브라우저 및 캐싱 리졸버가이를 존중하는지 여부는 중요하지 않습니다. 백엔드 대상을 변경할 때 www.example.com레코드를 변경할 필요가 없기 때문에 "인터넷"이라는 개념 www.example.com백엔드 시스템의 위치에 상관없이 올바른 대상과 관련하여 일관성이 있습니다.

이것은 나에게 원래 서버의 IP에 대한 변경을 "따라야"할 필요가없는 브라우저를 줄여서 문제를 완전히 해결합니다.

tl; dr : 요청을 실제 웹 서버의 프록시 역할을하는 시스템으로 라우팅하여 프록시 구성 만 브라우저 기반 DNS가 아닌 원래 서버 IP의 변경을 수용하면됩니다.

CloudFront는 또한 전면에 부과하는 일부 DNS 마법에 의해 대기 시간을 최소화 하므로 www.example.com쿼리하는 브라우저의 위치를 ​​기반으로 가장 최적의 CloudFront 엣지 로케이션 을 해결 www.example.com하므로 트래픽이 불필요하게 회로적인 경로를 취할 가능성이 최소화됩니다. 브라우저에서 가장자리, 원점까지 ...하지만이 부분은 투명하고 자동이며 질문의 범위를 벗어납니다.

물론 오리지널 서버 또는 전송의로드를 줄임으로써 컨텐츠 캐싱도 가치가있을 수 있습니다. 오리진 서버가 ADSL 회로에있는 CloudFront에서 웹 사이트를 구성했으며 ADSL은 본질적으로 업스트림 대역폭으로 제한되어 있습니다. 컨텐츠를 가져 오기 위해 CloudFront가 연결되는 오리진 서버는 AWS 에코 시스템 내부의 서버 일 필요는 없습니다.

¹ 실제로 여러 노드가있는 경우 밸런서를 단일 엔티티로 말합니다. 밸런서가 ELB 인 경우 밸런서 뒤의 시스템은 더미 앱 서버 역할을하며 ELB가 자체적으로이를 수행 할 수 없으므로 새 플랫폼의 밸런서에 실제 헤어핀을 수행합니다.

² 이전 밸런서에 대한 새로운 밸런서의 유일한 지식은 이전 밸런서의 X-Forwarded-For를 신뢰해야하며 이전 밸런서의 소스 주소에 대해 IP 기반 속도 제한을 수행해서는 안된다는 것입니다.

³ 프록시가 사용자가 제어하는 ​​하나 이상의 서버 인 경우 뒷면에서 DNS를 사용하지 않고 프록시 구성에서 IP 주소를 사용하는 옵션을 사용할 수 있지만 이후에 논의되는 호스팅 / 분배 시나리오에는 DNS의 두 번째 계층이 필요합니다 .

DNS 레코드를 변경할 때 종종 이전 IP 주소가 몇 달 동안 사용됩니다. 예를 들어, 몇 초의 TTL은 아마존이 폴백 서비스를 생성하는 데 사용하는 것입니다.

DNS를 변경하는 대신 프록시 서버 /로드 밸런서를 앞에 놓을 수 있습니다.

동적 DNS를 사용할 수 있습니다. 이것은 @glglgl이 위의 주석에서 언급 한 시나리오를 위해 설계되었습니다. 나는 그들이 앞서 지적했듯이 클라이언트가 그것을 무시할 수 있기 때문에 100 % 효과적이지 않을 수도있는 낮은 TTL을 사용한다고 생각합니다. 그러나 "꽤 잘"작동합니다.

IP를 자주 변경하지 않더라도 TTL을 합리적으로 유지하는 것이 중요합니다. 몇 년 전, 내가 ISP를 변경하기 위해 일했던 회사는 IP가 변경되었습니다. 불행히도, 우리는 TTL을 한 달과 같이 어리석은 것으로 설정하여 오래된 DNS 레코드가 오랫동안 유지되었습니다.