Підпорядкована ідентифікація
NS-записи рівня Apex використовуються головним сервером для ідентифікації своїх підлеглих. Коли дані про авторитетний сервер імен змінюються, він буде рекламувати це за допомогою DNS NOTIFYповідомлень ( RFC 1996 ) усім своїм колегам у цьому списку. Ці сервери, у свою чергу, передзвонять із запитом на SOAзапис (який містить порядковий номер) і приймуть рішення про те, чи потрібно знімати новішу копію цієї зони.
- Ці повідомлення можна надсилати серверам, які не вказані в
NSрозділі, але для цього потрібні специфічні для сервера директиви щодо конфігурації (наприклад, also-notifyдиректива ISC BIND ). Записи вершин NS складаються з основного списку серверів, про які слід повідомляти за конфігурацією за замовчуванням.
- Варто відзначити, що вторинні сервери також надсилатимуть повідомлення NOTIFY один одному на основі цих
NSзаписів, що зазвичай призводить до відмов у реєстрації. Це можна відключити, доручивши серверам надсилати сповіщення лише для зон, для яких вони є майстрами (BIND:) notify master;, або пропускати NSсповіщення на основі повністю на користь сповіщень, визначених у конфігурації. (BIND: notify explicit;)
Авторитетне визначення
Питання вище містило помилковість:
Вони не використовуються для кешування DNS-серверів для визначення авторитетних серверів для домену. Це обробляється клеєм nameserver, який визначений на рівні реєстратора. Реєстратор ніколи не використовує цю інформацію для створення записів клею.
До цього легко дійти висновку, але не точного. Дані NSзаписів та клейових даних (такі, які визначені у вашому обліковому записі реєстратора) не є авторитетними. Цілком очевидно, що їх не можна вважати "більш авторитетними", ніж дані, що зберігаються на серверах, на які передано повноваження. Це підкреслюється тим, що для рефералів не встановлено aaпрапор (Авторитетний відповідь).
Проілюструвати:
$ 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записів на псевдоніми, визначені а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.