당신은 이미 오래 전에 답장을 받았지만, 우리가 더 정확할 수 있다고 생각하고 후속 질문이 있습니다. 그것은 실제로 또 다른 질문이었습니다.
처음부터 다시 돌아가겠습니다.
루트 서버에 쿼리하여 .COM위임 에 대해 배우 면 (아래의 모든 항목 .NET이 동일한 레지스트리에서 처리되는 것과 동일한 방식으로 적용됨 )이 응답이 표시됩니다.
$ dig @a.root-servers.net com. NS +noall +auth
; <<>> DiG 9.12.0 <<>> @a.root-servers.net com. NS +noall +auth
; (1 server found)
;; global options: +cmd
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
따라서 요약하면 이러한 네임 서버는 모두 신뢰할 수 .COM있으며 모두 동일한 데이터를 갖습니다 (따라서 질문을 넓힐 수 있으며 a.gtld-servers.net특별한 것은 아닙니다. 아래의 모든 것이 이러한 네임 서버에 적용됩니다).
.COM/.NET도메인 이름에 대해 이러한 네임 서버를 쿼리 할 때는 요청한 도메인 이름에 대해 권한있는 네임 서버로 정식으로 응답해야합니다.
따라서 정의에 따라 "a.gtld-servers.net (및 * .gtld-servers.net)에 모든 .com 도메인의 레코드가 로컬에 있습니까?" "전체"주위에 약간의 경고가 있으며, 아래에 더 있습니다.
글루 레코드에 대해 말하는데, 이것은 가장 일반적인 경우가 아니라 특정한 경우입니다. 일반적으로 위의 네임 서버 중 하나에서 도메인을 요청하면 하나 이상의 NS 레코드가 반환됩니다.
텍스트의 다른 사소한 사항을 해결하기 위해 시간을 내주십시오.
그들은 매우 빠르게 응답하므로 더 이상 질문을하지 않는다고 생각합니다.
신뢰할 수있는 네임 서버는 정의에 따라 외부 리소스에 의존 할 필요없이 쿼리에 응답해야하는 데이터를 가지고 있습니다. 그렇지 않으면 실제로 신뢰할 수있는 것은 아닙니다.
속도에 관해서는 이것은 부분적으로 주관적이고 테스트 대상과 방법에 크게 의존하지만 몇 가지 요인이 있습니다. 기본적으로 DNS는 TCP보다 가벼운 UDP를 사용하므로 속도가 빠르며 그러한 네임 서버는 캐스트됩니다. "인근"이 있습니다.
a.gtld-servers.net이 아마도 여러 시스템이라는 것을 알고 있습니다.
"아마도"를 제거 할 수 있습니다. :-)이 네임 서버는 너무 많은 쿼리를 받아 단일 상자에서 절대 견딜 수 없습니다.
https://stat.ripe.net/192.5.6.30#tabId=routing으로 이동하면 소화하기 어려울 수 있지만 기본적 으로이 단일 IP a.gtld-servers.net(실제로 그것은 하나의 회사에 의해 통제되는 여러 AS에 의해 발표되며, 이는 대부분의 DNS에서 아름답게 작동하는 애니 캐스팅의 강력한 지표입니다.
http://www.root-servers.org/ 로 이동 하면 자세한 내용을 알 수 있습니다. 이것은 .COM더 이상 루트 네임 서버와 관련이 없지만 기술적으로는 정확히 동일합니다. 예를 들어 13 개의 루트 서버가 930 개의 인스턴스에 대해 12 개의 서로 다른 조직에 의해 관리되고 있음을 발견 할 수 있습니다 (인스턴스는 하나의 서버가 아니라 위치, 운영자가 일반적으로 "노드"를 갖는 "존재 지점"인 위치) 라우팅 장비,로드 밸런싱 / 페일 오버 설정의 여러 서버, 일부 모니터링 / 원격 핸즈 기능 등). F예를 들어 222 개소에 있습니다.
그리고 (새로운 one-ip-multiple-machine 기술을 통해) 가장 가까운 곳으로 라우팅되고 있지만 이는 다른 여러 시스템에 모든 .com 도메인이 있음을 의미합니다.
예. 많은 컴퓨터에는 모든 .COM도메인 이름 목록이 있습니다. 그러나 먼저 정밀도 :이 네임 서버에서 모든 .COM 도메인 이름에 대한 모든 네임 서버 목록을 얻게됩니다. 이는 위임되지 않은 도메인 이름의 경우 여기에서 찾을 수 없음을 의미합니다. 여러 경우에 발생할 수 있습니다.
- 도메인 이름을 등록 할 때 이름 서버를 설정하지 않거나 나중에 제거 할 수 있습니다.
- 예를 들어 지불 분쟁으로 인해 등록 기관이
clientHold도메인 이름에 상태 를 추가 하여 DNS에서 사라질 수 있습니다.
- 레지스트리는
serverHold어떤 이유로 든 도메인을 설정할 수 있습니다.
( 이러한 상태 및 기타에 대한 자세한 내용 은 https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-ko 참조 ).
"모두"를 정의하는 방법과 이러한 데이터로 수행 할 작업에 따라 실제로 모든 데이터를 얻지 못할 수 있습니다.
위의 모든 경우에 도메인은 레지스트리 DNS 서버에 나타나지 않지만 whois 쿼리를 수행 할 때는 나타납니다. 따라서 whois 서버 (단일 상자가 아님)도 다음과 같은 이유로 네임 서버보다 모든 .COM 도메인 이름 및 훨씬 더 많은 데이터 목록을 갖게됩니다.
- 레지스트리 이름 서버에없는 도메인 이름을 포함하여 해결되지 않은 도메인 이름을 포함한 모든 도메인 이름이 있습니다.
- whois는 연락처 데이터와 같은 훨씬 더 많은 정보를 제공합니다
그리고 이들은 여전히 어떤 방식 으로든 도메인 이름의 목록 (또는 그 일부)을 가진 공개 레지스트리 서비스입니다.
후속 조치에 관해서 :
후속 질문 : 누군가이 컴퓨터 중 하나를 "해킹"하면 모든 .com 도메인 목록을 얻을 수 없습니까?
기술적으로는 그렇습니다. 그러나:
- 이것은 온라인에서 찾을 수있는 가장 쉬운 대상은 아닙니다.
- 이 특정 경우에 데이터는 이미 무료로 제공됩니다.
.COMgTLD이며 ICANN과 계약을 맺고 있습니다. ICANN은 모든 gTLD 레지스트리가 존 파일 (기본적으로 네임 서버가 사용하는 것이므로 NS 레코드와 A / AAAA 접착제)을 하루에 한 번 게시하도록 요구하며, 계약서에 서명하는 한 누구나 무료로 액세스 할 수 있습니다. 이 데이터를 "나쁜"목적 (예 : 직접 게시)과 같은 목적으로 재사용하지 않도록합니다.
이에 대한 자세한 내용은 https://czds.icann.org/en 을 참조 하십시오 . 이를 통해 수백 개의 gTLD 영역 파일에 액세스 할 수 있습니다.
질문이 "누군가 이러한 컴퓨터 중 하나를 해킹하여 .COM 도메인 이름을 추가 또는 제거하는 콘텐츠를 변경 하는 경우"로 확장되면 다음과 같이 신속하게 답변 할 수 있습니다.
- 하나의 상자 만 해킹하고 이름과 애니 캐스팅을 통해 수많은 네임 서버가 있으므로 변경 사항은 전 세계에 표시되지 않습니다.
- DNSSEC는 변경 사항을 오류로 표시 할 수 있으므로 운영자가 직접 로컬 대책을 수행하는 것 외에 빠르게 발견됩니다.
간단히 말해서 .COM도메인 이름 을 망칠 수있는 다른 방법이 있습니다.
도메인 정보는 공개적이지만 대량으로 얻기는 여전히 어렵다는 것을 알고 있습니다.
ICANN 프로그램에 대해서는 위를 참조하십시오. ccTLD의 경우 상황은 다양하지만 더 자주 실시간이 아닌 영역 파일에 대한 액세스 권한을 부여하지 않습니다.
경우에 따라 "데이터 열기"이동을 통해 일정 시간이 지나면 액세스 할 수 있습니다. 한 가지 예 : https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html 에 대한 .FR도메인 이름.
* .gtld-servers.net은 영역 전송을 지원하지 않는 것 같습니다 (최소한 몇 년 전 .edu의 네임 서버는 그랬지만).
테스트 용이성 :
$ for ns in $(dig NS . +noall +ans | grep 'IN NS' | awk '{print $5}') ; do echo $ns ; dig @$ns com. AXFR; done
c.root-servers.net.
; <<>> DiG 9.12.0 <<>> @c.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
m.root-servers.net.
; <<>> DiG 9.12.0 <<>> @m.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
i.root-servers.net.
; <<>> DiG 9.12.0 <<>> @i.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
e.root-servers.net.
; <<>> DiG 9.12.0 <<>> @e.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
j.root-servers.net.
; <<>> DiG 9.12.0 <<>> @j.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
l.root-servers.net.
; <<>> DiG 9.12.0 <<>> @l.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
g.root-servers.net.
; <<>> DiG 9.12.0 <<>> @g.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
k.root-servers.net.
; <<>> DiG 9.12.0 <<>> @k.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
b.root-servers.net.
; <<>> DiG 9.12.0 <<>> @b.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
h.root-servers.net.
; <<>> DiG 9.12.0 <<>> @h.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
d.root-servers.net.
; <<>> DiG 9.12.0 <<>> @d.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44
;; connection timed out; no servers could be reached
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
a.root-servers.net.
; <<>> DiG 9.12.0 <<>> @a.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
f.root-servers.net.
; <<>> DiG 9.12.0 <<>> @f.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44
; Transfer failed.
아니요. 현재 .COM권한있는 네임 서버는 AXFR 쿼리를 허용 하지 않습니다 . 그러나 이것은 모든 곳에서 반드시 같은 것은 아닙니다. 쿼리하면 f.root-servers.net네임 서버를 사용하면 게시 된 모든 TLD (최상위 도메인)를 얻기 위해 AXFR 쿼리를 할 수 있습니다. 다른 TLD도이를 허용 할 수 있습니다.
공개 AXFR 쿼리를 허용하지 않는 것에 대한 권장 사항이 많이 있습니다. 사실은 정의에 따라 큰 대답이며 반복되면 서버에 부담을 줄 수 있습니다. On은 왜 / 대중이이 정보를 필요로하는지에 대해 끊임없이 논쟁 할 수 있습니다. DNS의 시작 부분에서 네임 서버 사이의 영역을 복사하는 데 더 많이 사용되었습니다 (지금은 훨씬 더 나은 대안이 있습니다). 따라서 AXFR은 종종 비활성화됩니다 ... DNSSEC를 동시에 수행하는 경우 (NSEC3 변형이 아닌 NSEC) 특정 방식으로 표준 DNS 쿼리를 통해 AXFR없이 쉽게 걸을 수 있습니다. 영역 파일을 재구성하십시오. 이를위한 도구가 있습니다.
또한 온라인으로 다양한 공급자가 다양한 TLD에 대한 영역 파일 및 / 또는 모든 도메인 이름 목록을 판매합니다.이 도구는 다양한 방법으로 획득합니다 (한 가지 아이디어 중 하나 : 오픈 영역 파일을 가져오고 .COMTLD의 .example경우 하나씩 쿼리합니다). 에서 찾은 모든 이름은 .COM검색된 TLD에서 가장 많이 사용 된 언어를 기반으로하는 사전 걷기 외에도 몇 가지 아이디어를 제공 할 수 있습니다.