하위 식별
마스터 서버는 Apex 레벨 NS 레코드를 사용하여 하위 서버를 식별합니다. 신뢰할 수있는 네임 서버의 데이터가 변경되면 DNS NOTIFY메시지 ( RFC 1996 )를 통해 해당 목록의 모든 피어에게이를 알립니다. 해당 서버는 SOA일련 번호가 포함 된 레코드 요청으로 다시 전화를 걸어 해당 영역의 최신 사본을 풀다운할지 여부를 결정합니다.
- 이 메시지를
NS섹션에 나열되지 않은 서버로 보낼 수 있지만 서버 특정 구성 지시문 (예 : ISC BIND의 also-notify지시문) 이 필요합니다 . apex NS 레코드는 기본 구성에서 통지 할 기본 서버 목록을 구성합니다.
- 보조 서버는 이러한
NS레코드를 기반으로 NOTIFY 메시지를 서로에게 보내 므로 일반적으로 거부 된 로그가 기록됩니다. 이는 서버가 마스터 인 영역에 대한 알림 만 보내도록 (BIND :) , 구성에 명시 적으로 정의 된 알림에 대해 전체 알림 notify master;을 건너 뛰 도록 지시하여 비활성화 할 수 있습니다 NS. (BIND : notify explicit;)
권위있는 정의
위의 질문에는 오류가 있습니다.
도메인의 권한있는 서버를 결정하기 위해 DNS 서버를 캐시하는 데 사용되지 않습니다. 이것은 레지스트라 수준에서 정의 된 네임 서버 접착제에 의해 처리됩니다. 레지스트라는이 정보를 사용하여 글루 레코드를 생성하지 않습니다.
이것은 도달하기 쉬운 결론이지만 정확하지는 않습니다. NS기록 (예 : 사용자의 등록 계정 내에서 정의 된 것과 같은) 접착제 기록 데이터는 신뢰할 수 없습니다. 권한이 위임 된 서버에있는 데이터보다 "권한있는"것으로 간주 될 수없는 이유가 있습니다. 이는 추천에 aa(Authoritative Answer) 플래그가 설정되어 있지 않기 때문에 강조됩니다 .
설명하기 위해 :
$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.135.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8f::53
b.iana-servers.net. 172800 IN A 199.43.133.53
b.iana-servers.net. 172800 IN AAAA 2001:500:8d::53
aa위의 응답에 대한 플래그 부족이 있습니다. 추천 자체는 신뢰할 수 없습니다. 반면에 참조되는 서버의 데이터 는 신뢰할 수 있습니다.
$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
그러나이 관계는 추천의 부모쪽에 정의 된 NS비 정식 레코드가 없으면 이러한 레코드 의 정식 버전에 대해 배울 수 없으므로 매우 혼란 스러울 수 있습니다 NS. 동의하지 않으면 어떻게됩니까?
- 짧은 대답은 "일관되지 않은 동작"입니다.
- 긴 대답은 네임 서버가 처음 스텁 빈 캐시에 추천 (와 접착제)의 오프 다, 그러나 그 것입니다
NS, A그리고 AAAA그들이 새로 고칠 때 기록은 결국 대체 될 수있다. 임시 레코드의 TTL이 만료되거나 누군가 해당 레코드에 대한 답변을 명시 적으로 요청할 때 새로 고침이 발생합니다.
A및 AAAA영역 데이터의 출력에 대한 레코드 (익스플로러 com의 데이터 밖에 용 접착제 정의 네임 서버 com영역과 같은 example.net그것 네임 서버로 간주되지 않아야 함을 잘 이해할 개념은 권위있는 정보 소스처럼) 명확히 끝날, 리프레쉬되고 . (RFC 2181)NS레지스트라 제어판에 입력 한 이름 서버와 같은 서버에 있는 레코드와 다른 레코드와 같이 조회의 상위 및 하위 측 에서 레코드 값이 다를 경우 NS, 경험 한 동작은 최대 하위를 포함하여 일관되지 않습니다. NS레코드가 완전히 무시됩니다. 이는 동작이 표준에 의해 잘 정의되어 있지 않기 때문에 구현은 다른 재귀 서버 구현에 따라 다릅니다. 다시 말해, 도메인에 대한 네임 서버 정의가 추천의 부모와 자식 사이에 일관성이있는 경우에만 인터넷을 통한 일관성있는 동작이 예상 될 수 있습니다 .
추천의 부모쪽에 정의 된 레코드가 해당 레코드의 신뢰할 수있는 버전과 일치하지 않는 경우 인터넷 전체의 재귀 DNS 서버가 대상간에 반송됩니다. 처음에는 추천에 존재하는 데이터가 선호되며, 권한있는 정의로만 대체됩니다. 캐시는 인터넷을 통해 처음부터 지속적으로 재구성되기 때문에이 구성으로 인터넷이 단일 버전의 현실에 정착하는 것은 불가능합니다. 신뢰할 수있는 기록은 가리키는 등의 기준에 따라 불법적 인 일, 수행하는 경우 NS별칭에서 기록을 a로 정의CNAME이로 인해 문제 해결이 더욱 어려워집니다. 도메인은 위반을 거부하는 소프트웨어의 작동 및 중단 사이를 번갈아 표시합니다. (즉, ISC BIND / 명명)
RFC 2181 §5.4.1 은이 데이터의 신뢰성에 대한 순위표를 제공하며 참조 및 글루와 관련된 캐시 데이터를 참조 레코드에 대한 명시 적 요청에 대한 응답으로 반환 할 수 없음을 명시 적으로 지정합니다.
5.4.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
<snip>
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.