그래서 방금 웹서버를 변경하고 영향을 받은 도메인의 네임서버를 변경했습니다. 전환을 더 쉽게 하기 위해 모든 DNS 레코드를 새 서버에 복제한 다음 네임서버를 변경했습니다. 그러나 변경 사항이 전파되지 않는 것 같습니다. 이제 변경 사항이 새 이름 서버를 가리키고 있지만 사이트가 확인되지 않는 것을 볼 수 있습니다.
마법사를 사용하여 Linux용 Plesk에서 이를 설정했습니다. 수행해야 할 작업과 수행하지 말아야 할 작업이 있습니까?
티아.
편집하다:
DNSStuff.com 검사를 실행했는데 어떤 이유에서인지 새 이름 서버가 다음과 같이 이전 이름 서버를 가리킵니다.
ns0.hostedsupportal.com [64.128.190.5] ns1.dreamhost.com. ns2.dreamhost.com. ns3.dreamhost.com. 39ms
이상한.
답변1
hostedsupportal.com
primary name server = ns1.dreamhost.com
responsible mail addr = hostmaster.dreamhost.com
serial = 2009071403
refresh = 15182 (4 hours 13 mins 2 secs)
retry = 1800 (30 mins)
expire = 1814400 (21 days)
default TTL = 14400 (4 hours)
4시간 13분 2초 동안 새로 고침을 설정하고 전파가 완료될 때까지 기다립니다. 인내심은 미덕입니다 :)
답변2
도메인에 대한 권한 있는 네임서버의 현재 설정을 보려면 dig( dig @< 신뢰할 수 있는 네임서버 > < 호스트 또는 도메인 >이 시작됨)를 사용하세요. 아직 변경 사항을 적용하지 않았을 수도 있습니다(호스팅 도메인과 연결된 네임서버의 경우 편집할 수 있는 레코드는 공개 네임서버에 있는 레코드가 아닌 경우가 많지만 호스팅 회사가 소유한 프로세스에 의해 검증된 후 그곳에 복사됩니다. 물론 네임서버가 실제로 귀하의 컴퓨터인 경우도 있습니다. 도메인의 기본 이름 서버에 새 정보가 있더라도 최근에 도메인을 확인하고 이전 정보를 받은 다른 DNS 서버는 TTL 시간 동안 이를 캐시하고 만료될 때까지 도메인을 다시 확인하지 않습니다. 해당 레코드를 제어할 수 있는 경우 DNS를 변경하기 훨씬 전에 TTL 시간을 줄여야 하는 이유입니다(이전 버전의 BIND는 SOA 레코드에 TTL을 설정합니다. TTL은 개별 리소스 레코드에도 설정할 수 있습니다).
dig( dig < 호스트 또는 도메인 > )를 사용하여 클라이언트가 사용 중인 네임서버에서 반환되는 레코드를 확인할 수 있습니다. 이 레코드는 사용 중인 버전과 나머지 TTL을 나타냅니다.
(GNU/LINUX/BSD 클라이언트를 사용한다고 가정하고 위의 내용을 언급하고 있지만 다른 플랫폼에도 이 도구 버전이 있다고 생각합니다.)
(저는 또한 귀하의 편집 내용을 읽기 전에 이 글을 쓰기 시작했습니다. 원래 설정된 방식입니까? -- 그렇다면 여전히 캐싱 문제일 수 있으므로 TTL 시간이 이에 대한 좋은 표시가 되어야 합니다. 불행히도 저는 익숙하지 않습니다. DNSStuff 또는 그 출력이 있으므로 도움이 될 수 없습니다)
답변3
DNS 캐시가 시간 초과되는 데 최대 48시간이 걸릴 수 있습니다. 하루 이틀 정도 기다리셨나요?