도메인 등록 기관 대신 AWS를 DNS로 사용하십시오(간단한 단계).

4954 단어 domaindnsdevopsaws

왜요?



대부분의 도메인 공급자는 DNS 레코드를 업데이트하는 프로그래밍 방식을 제공하지 않습니다.
AWS 외부에서 이미 도메인을 구입했고 이전할 수 없지만 프로그래밍 방식으로 DNS 레코드를 제어하려는 경우 이 문서가 적합합니다.

단계



AWS Route 53 준비



먼저 AWS에 로그인하고 Route53으로 이동합니다.
호스팅 영역 섹션이 표시됩니다. 호스팅 영역 생성을 클릭합니다.



영역이 생성되면 NS 레코드가 표시됩니다. 이것은 도메인 공급자를 업데이트하는 데 필요한 이름 서버 레코드입니다.



Note: A hosted zone acts as a domain manager for your domain



도메인 공급자 준비



도메인 공급자에 로그인하고 DNS 섹션으로 이동합니다.
여기에 이름 서버 섹션이 표시됩니다. 네임서버 관리를 클릭합니다.

기본적으로 도메인 공급자는 귀하의 도메인에 대한 일련의 이름 서버를 보유합니다.



Note: A nameserver is a server that stores the DNS records for a domain, like an IP address, for example.



작동하는지 확인하는 방법?



CLI 방식




> dig ns iusearchbtw.blog

; <<>> DiG 9.18.6 <<>> ns iusearchbtw.blog
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61482
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;iusearchbtw.blog.    IN  NS

;; ANSWER SECTION:
iusearchbtw.blog. 21600 IN  NS  ns-1210.awsdns-23.org.
iusearchbtw.blog. 21600 IN  NS  ns-1878.awsdns-42.co.uk.
iusearchbtw.blog. 21600 IN  NS  ns-396.awsdns-49.com.
iusearchbtw.blog. 21600 IN  NS  ns-825.awsdns-39.net.

;; Query time: 43 msec
;; SERVER: 192.168.1.107#53(192.168.1.107) (UDP)
;; WHEN: Sun Sep 11 19:55:18 BST 2022
;; MSG SIZE  rcvd: 185



온라인 방식


  • https://dnschecker.org/ns-lookup.php
  • https://www.whatsmydns.net/dns-lookup/ns-records?query=iusearchbtw.blog&server=google
  • https://mxtoolbox.com/SuperTool.aspx?action=dns%3aiusearchbtw.blog&run=toolpage

  • 위험



    실행 순서



    네임서버를 업데이트하기 전에 DNS 레코드가 올바르게 설정되었는지 확인하십시오.
    이렇게 하면 한동안 도메인이 다운되지 않습니다.

    DNS 전파



    새 DNS 레코드를 설정하는 동안 변경 사항이 전파되는 데 최대 24시간이 걸릴 수 있습니다. 이는 DNS 레코드가 ISP 및 기타 DNS 서버에 의해 캐시되기 때문입니다.
    TTL(Time To Live)을 낮게 설정하면 도움이 될 수 있습니다.

    정적 웹사이트와 동적 웹사이트


  • 정적 콘텐츠가 있는 사이트에서는 비교적 쉽습니다. 전환 기간 동안 이전 위치와 새 위치 모두에 동일한 사이트를 유지합니다. 주의해야 할 점은 HTTPS/SSL 인증서입니다. 특히 certbot과 같은 것을 실행하는 경우 전환 기간 동안 두 시스템 모두에서 인증서 유효성을 확인해야 합니다.
  • 동적 사이트에서는 훨씬 더 어렵습니다. 세션을 처리하는 방법에 따라 일종의 복제를 조작하거나 즉시 다시 연결할 수 있는 한(또는 다른 솔루션) 모든 사람의 연결을 끊을 수 있다는 관점을 가질 수 있습니다. 여기서 트릭은 리버스 프록시/로드 밸런서를 사용하는 것입니다. 이를 수행하는 방법에는 여러 가지가 있습니다. 하나는 사이트를 미리 구성된 로드 밸런서로 마이그레이션하고, 로드 밸런서를 새 IP로 지정하고, DNS를 다시 업데이트하고, 로드 밸런서를 제거하는 것입니다. 임시로 이전 시스템을 새 시스템의 역방향 프록시로 전환하는 것을 포함하여 주제에 대한 다양한 변형이 있습니다.

  • An important aside - if a short period of downtime for current users is OK, you can reduce TTLs in DNS to 60 seconds (lower is not a good idea) - in that way, the vast majority of users will be switched from old to a new server in a minute or 2.



    참조


  • https://www.virtuallyboring.com/migrate-godaddy-domain-and-dns-to-aws-route-53/
  • https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html
  • https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/MigratingDNS.html
  • 좋은 웹페이지 즐겨찾기