DNS 정보가 전파되었는지 테스트하는 방법?

16

하위 도메인 중 하나에 대해 새로운 DNS 항목을 설정했습니다 (아파치 가상 호스트 또는 이와 유사한 것을 아직 설정하지 않았습니다). DNS 정보가 전파되었는지 어떻게 확인할 수 있습니까?

나는 간단하게 ping my.subdomain.com해결할 수 있다고 가정하고 해결할 수 있다면 A 레코드에 지정한 IP 주소를 표시한다고 가정합니다. 그러나 올바르게 가정하고 있는지 모르겠습니다. 이 정보를 확인하는 가장 좋은 방법은 무엇입니까?

domain-name-system 
— 앤드류
소스
3
바보 같은 질문이 아닙니다. 이런 종류의 것을 찾는 것은 그렇게 쉬운 일이 아닙니다.
— aseq
1
나는 이것이 바보 같은 질문이 아니라 "시도해보십시오"라는 답 을 @aseq에 동의합니다 . 또한 약간의 노력만으로도 Google이 쉽게 대답 할 수 있습니다 ( How to test if DNS information has propagated피 묻은 질문 제목 은 좋은 Google 결과를 생성 함).
— voretaq7
4
나는 당신이 사람들의 시간을 낭비했다고 생각하지 않습니다. 귀하의 질문은 몇 가지 귀중한 응답을 유발했습니다. 당신은 "구글 검색"될 수있는 겉보기 간단한 질문이 어떻게 나올지 모릅니다. 이 포럼의 가치 중 하나는 답변과 질문을 매우 쉽게 확장 할 수 있다는 것입니다.
— aseq
1
@andrew 많은 사람들이 간단한 질문으로 보는 것을 묻는 데 아무런 문제가 없습니다. 사이트 색인 생성 방법에 따라 며칠 만에 해당 문자열의 최상위 Google 검색 결과가 될 것입니다. 일반적으로 Google이
— 더보기
1
내가 시도한 것이 아무것도없는 이유를 알아 냈습니다. 분명히 우리 네트워크는 로컬 DNS에도 새로운 하위 도메인을 추가해야하는 방식으로 구성되어 있습니다. 따라서 하위 도메인은 테스트중인 네트워크가 아닌 외부 세계에서 액세스 할 수있었습니다. = [그러나 외부 서버를 사용 nslookup하고 dig지정하는 동안 외부 DNS 정보를 확인할 수있었습니다.
— 앤드류

답변:

15

dig 또는 nslookup을 사용할 수 있습니다. 귀하의 이름 서버는 ns1.example.com이라고 말하십시오.

nslookup 사용 :

nslookup - ns1.example.com

프롬프트에서 다음을 입력하십시오.

my.example.com

예상대로 해결되면 작동합니다. 그것은 당신에게 다음과 같은 것을 줄 것입니다 :

Name:   example.com
Address: 192.0.43.10

인터넷의 나머지 부분으로 전파되는 데 여전히 시간이 걸릴 수 있습니다.

발굴 사용 :

dig@ns1.example.com my.example.com

다음과 같은 내용이 표시되어야합니다.

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

ping을 사용하는 것만으로도 아이디어를 얻을 수 있지만 전파 된 경우 (원격 네임 서버로 캐시하는 것이 더 나은 방법 임) 로컬 dns 캐시를 플러시해야 할 수도 있습니다. 귀하의 경우 이것은 새로운 기록이므로 적용되지 않습니다. 이 경우 즉시 사용할 수 있어야합니다. 위의 방법은 단지 핑하는 것이 아니라 아이디어를 제공하는 데 더 정확합니다.

창을 사용하면 명령과 구문이 약간 다를 수 있지만 매우 비슷합니다.

— aseq
소스
3
+1 DNS로 무언가를하고 있다면, 사본을 얻으십시오 dig(* nix 시스템에는 이미 Windows 용 버전이 있습니다).
— Chris S
3
-1. 죄송 해요. 나는 진실로, 그러나이 답변은 DNS 레코드가 전파한다는 신화를 "전파"하는데, 그것들은 가장 확실하지 않습니다. 찾고있는 용어는 "캐싱"으로, 레코드의 TTL을 기반으로 DNS 레코드에서 발생합니다. OP가 새로운 DNS 레코드를 참조 할 때 캐싱이 발생하지 않았으므로 문제의 레코드를 해결하려는 모든 DNS 클라이언트가 해당 클라이언트에 의해 캐시 될 수 없으므로 즉시 응답을 얻습니다. 또는 클라이언트 DNS 서버 또는 다른 DNS 서버 DNS 레코드는 "다른 인터넷"으로 전파되지 않습니다.
— joeqwerty
1
joeqwerty는 절대적으로 맞습니다. dns 서버는 사전 정의 된 시간 동안 긍정적 또는 부정적 적중을 캐시합니다. 그러나 원래 게시물 외에도 이전 GTE (4.2.2.1, 4.2.2.2, 4.2.2.3 및 4.2.2.4) 및 Google (8.8.8.8, 8.8)을 포함하여 확인할 수있는 공개 이름 서버가 여러 개 있습니다. 4.4). 간단한 경험 법칙, 새로운 변경 사항은 긍정적 또는 부정적 적중에 대한 ttl의 지속 시간까지 걸릴 수 있습니다. 그러나 앱이 잘못된 로직을 구현하고 오랜 시간 동안 캐시 응답을 구현하는 경우가 있습니다.
— bangdang
2
포인트를 얻기 위해 정확한 정의를 고수해야한다고 생각하지 않습니다. 게다가 전파는 나쁜 단어가 아니라고 생각합니다. DNS 레코드의 캐싱이 더 넓은 범위의 서버로 확산된다는 점에서 주제를 다루고 있습니다. 퍼지는 것은 전파하는 것을 말합니다. 새 레코드를 즉시 사용할 수 있다는 사실을 반영하여 답변을 업데이트했습니다.
— aseq
1
@aseq, 오해의 소지가 있습니다. 그리고 DNS를 일종의 "전파"라고 생각하고 말하는 ppl은 DNS가 어떻게 작동하는지 알지 못하는 것이 대부분입니다. 일반적으로 "인터넷 / 지구 전체에 DNS 정보가 전파되는 데 2 ​​~ 3 일이 소요됩니다"등과 같은 문제가 있습니다.
— poige
7

DNS 전파가 발생하지 않으므로 DNS 레코드 전파를 테스트 할 수 없습니다. 테스트 할 수있는 것은 DNS 클라이언트 또는 서버에 캐시 된 특정 DNS 레코드가 있는지 여부입니다.

이것은 새로운 DNS 레코드이므로 캐싱을 수행 할 수 없습니다. 이름 서버가 상위 서버에 올바르게 등록되어 있고 이름 서버가 올바르게 작동한다고 가정하면이 DNS 레코드는 모든 DNS 클라이언트 또는 서버에서 즉시 사용할 수 있어야합니다.

— joeqwerty
소스
기꺼이 도와 ...
— joeqwerty
유효한 IP를 입력했는지 확인할 수있는 방법이 있습니까? 방금 사용한 IP 주소가 올바른지 확인하고 싶었습니다. 내가 얘기 한 사람은 아직 Apache VHost를 설정하지 않으면 핑이 실패 할 것이라고 생각하는 것 같았습니다.
— 앤드류
Ping은 DNS 테스트 도구가 아닙니다. Dig와 Nslookup은 DNS 테스트 도구입니다. Dig 또는 Nslookup을 사용하여 새 DNS 레코드를 테스트하십시오. 이름 서버에 대한 레코드를 쿼리 한 다음 다른 이름 서버에 대한 레코드를 쿼리하여 이름 서버를 찾고 이름 서버가 정답으로 응답하는지 확인하십시오.
— joeqwerty
1
"전파"는 사람들이 캐시 에이징 및 만료와 같은 실제 상황을 이해할 수없는 경우에 만들어진 개념입니다. DNS 제공 업체가 말해야 할 것은 "XX 시간이 지나야 데이터가 표시되지 않을 수 있습니다"입니다. DNS 공급자처럼 보이지 않도록 필요한 이유에 대한 설명이 지연되었습니다. 너무 많은 사람들이 "진실을 다룰 수 없습니다". 구성된 "전파"는 효과적인 커버 스토리입니다. 진정한 DNS 전문가는 기술 정보를 읽었 기 때문에 실제로 어떤 일이 발생하는지 알고 있습니다.
— Skaperen
사실 ... DNS의 작동 방식에 대한 오해를 "전파"하는 용어를 사용하는 것이 싫습니다.
— joeqwerty
5

다른 답변은 꽤 좋지만, 당신에게 전파 된 것은 나에게 전파되지 않을 수 있습니다. DIG 또는 NSlookup을 사용하고 전 세계의 DNS 서버를 확인하는 데 1 시간을 소비하는 대신, 일반적으로 http://www.whatsmydns.net/ 을 사용 하여 전파 진행 상황을 확인합니다.

— 짐 B
소스
DNS에는 전파가 없으며,이 용어는 RFC를 읽지 않는 모든 종류의 라머에게는 오해의 소지가 있으므로이 용어를 <strike> propagate </ strike>하지 마십시오. ;-D
— poige
1
물론 DNS에서 전파되는 RFC는 독자가 서버가 조회 및 캐시를 수행 할 때 정보가 전파 될 수 있다고 이해한다고 가정합니다. 레이저가 RFC를 읽을 때 서버의 레코드가 다른 서버의 조회 결과와 일치하지 않는 이유가 궁금합니다. 그들은 전파가 "넓게 퍼지다"(정확히 점검해야 할 것-업데이트 된 레코드의 분포)라는 정의를 가지고 있음을 발견했다
— Jim B
배포 나 전파 (마스터 대 슬레이브 제외)는 없습니다.
— poige
그것은 아마 루트 네임 서버에로드 된 애플리케이션 도메인 .COM에서 변경을 얻기 위해 하루에 때로는 가까이 갔다 때의 유물입니다 (.COM은 뿌리에 때 방법 다시!)
— Cakemox
@ poige- DNS 캐싱 작동 방식에 대한 이해 부족을 확인해 주셔서 감사합니다. DNS 작동 방식에 대한 RFC를 읽고 실제 예제를 위해 링크 된 웹 사이트를 확인하는 것이 좋습니다.
— Jim B
3

위임 경로의 신뢰할 수있는 DNS 서버가 올바르게 응답하는지 확인하는 가장 쉬운 방법은 다음을 사용하는 것입니다 dig +trace.

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

이것은 귀하의 질의에 대한 권한을 부여한 네임 서버에 대한 위임을 따릅니다. 마지막 답변은 일반적으로 가장 우려되는 답변이지만 각 위임에 대해 누가 응답하고 있는지 보여주는 점에서 추적이 도움이됩니다. 이름 서버를 변경하는 경우 매우 유용 할 수 있습니다.

trace는 신뢰할 수있는 서버를 직접 쿼리하므로 캐싱이 없습니다. 이는 답변이 예상대로 반환되고 있음을 나타내는 가장 좋은 표시이지만 최종 사용자가 경험할 수있는 좋은 표시는 아닙니다. 그러나 TTL을 낮추고 원래 TTL을 기다렸다가 변경 한 다음 TTL을 복원하는 것 외에 다른 사람들의 캐싱 네임 서버를 제어하지 못하는 경우가 많으므로 일반적으로 사실을 확인하는 것이 좋습니다.

— Cakemox
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.