Як я можу знайти джерела суперечливих записів DNS?
Як я можу знайти джерела суперечливих записів DNS?
Відповіді:
Ви хочете записати SOA (Start of Authority) для даного доменного імені, і ось як це зробити, використовуючи універсально доступний інструмент командного рядка nslookup :
command line> nslookup
> set querytype=soa
> stackoverflow.com
Server: 217.30.180.230
Address: 217.30.180.230#53
Non-authoritative answer:
stackoverflow.com
origin = ns51.domaincontrol.com # ("primary name server" on Windows)
mail addr = dns.jomax.net # ("responsible mail addr" on Windows)
serial = 2008041300
refresh = 28800
retry = 7200
expire = 604800
minimum = 86400
Authoritative answers can be found from:
stackoverflow.com nameserver = ns52.domaincontrol.com.
stackoverflow.com nameserver = ns51.domaincontrol.com.
Рядок походження (або основний сервер імен у Windows) говорить вам, що ns51.domaincontrol є основним сервером імен для stackoverflow.com .
Наприкінці виводу перелічені всі авторитетні сервери, включаючи сервери резервного копіювання для даного домену.
dig
здавалося, для мене (див. відповідь нижче)
nslookup -type=soa stackoverflow.com
на Linux сьогодні (2019 - лютий), авторитетний розділ порожній.
Ви використовували однину у своєму запитанні, але зазвичай є кілька авторитетних серверів імен, RFC 1034 рекомендує принаймні два.
Якщо ви не маєте на увазі "сервер основного імені", а не "авторитетний сервер імен". Вторинні сервери імен є авторитетними.
Щоб дізнатися сервери імен домену в Unix:
% dig +short NS stackoverflow.com
ns52.domaincontrol.com.
ns51.domaincontrol.com.
Щоб дізнатися сервер, вказаний як основний (поняття "первинний" в ці дні досить нечітке і зазвичай не має гарної відповіді):
% dig +short SOA stackoverflow.com | cut -d' ' -f1
ns51.domaincontrol.com.
Щоб перевірити розбіжності між серверами імен, мої переваги переходять до старого check_soa
інструменту, описаного в книзі Лю і Альбіца "DNS & BIND" (редактор O'Reilly). Вихідний код доступний на веб-сайті http://examples.oreilly.com/dns5/
% check_soa stackoverflow.com
ns51.domaincontrol.com has serial number 2008041300
ns52.domaincontrol.com has serial number 2008041300
Тут два авторитетні сервери імен мають однаковий серійний номер. Добре.
www.pressero.com
, який є CNAME для іншого сайту - dig + short SOA просто повертає ціль CNAME.
www.pressero.com
, ви, напевно, думали про записи A (що є типом запису за замовчуванням, dig
якщо ви не вказуєте його). Але якщо потрібно, просто додайте а, tail -1
щоб отримати остаточний результат.
dig +short SOA www.pressero.com
. Це повертає лише ціль CNAME - не запис SOA для pressero.com
домену, що я очікував. tail -1
не допомагає питанням; dig +short SOA
випромінює лише один рядок.
On * nix:
$ dig -t ns <domain name>
У мене є інструмент поширення DNS, призначений відповідати на подібні запитання.
Джерело випускається під AGPLv3.
(Так, на даний момент інтерфейс досить базовий :))
Ви також можете дізнатися сервери імен для домену за допомогою команди "хост":
[davidp @ supernova: ~] $ host -t ns stackoverflow.com stackoverflow.com сервер імен ns51.domaincontrol.com. stackoverflow.com сервер імен ns52.domaincontrol.com.
Я виявив, що найкращий спосіб завжди додавати варіант + слід:
dig SOA +trace stackoverflow.com
Він також працює з рекурсивним CNAME, розміщеним у різних постачальників. + слід сліду означає + безрецидивний, тому результат відповідає лише вказаному домену.
Термін, яким ви повинні бути гуглінг, - "авторитетний", а не "остаточний".
У Linux або Mac ви можете використовувати команди whois
, dig
, host
, nslookup
або кілька інших. nslookup
також може працювати в Windows.
Приклад:
$ whois stackoverflow.com
[...]
Domain servers in listed order:
NS51.DOMAINCONTROL.COM
NS52.DOMAINCONTROL.COM
Щодо додаткового кредиту: Так, можливо.
aryeh, безумовно, помиляється, оскільки його пропозиція зазвичай дасть вам лише IP-адресу для імені хоста. Якщо ви використовуєте dig
, вам потрібно шукати записи NS, як-от так:
dig ns stackoverflow.com
Майте на увазі, що це може запитати ваш локальний DNS-сервер і, таким чином, може давати неправильні чи застарілі відповіді, які він має у своєму кеші.
Ми побудували інструмент пошуку dns, який дає вам авторитетні сервери імен домену та його загальні записи dns в одному запиті.
Приклад: https://www.misk.com/tools/#dns/stackoverflow.com
Наш інструмент знаходить авторитетних серверів імен, виконуючи пошук у режимі реального часу (без кешування) у кореневих серверах імен, а потім дотримуючись рефералів імені серверів імен, поки ми не дійдемо до авторитетних серверів імен. Це та сама логіка, яку використовує dns-резолютори для отримання авторитетних відповідей. У кожному запиті вибирається (і ідентифікується) випадковий авторитетний сервер імен, що дозволяє знаходити суперечливі записи dns, виконуючи кілька запитів.
Ви також можете переглянути шлях делегування серверу імен, натиснувши на "Авторитетні сервери імен" внизу результатів пошуку dns із наведеного вище прикладу.
Приклад: https://www.misk.com/tools/#dns/stackoverflow.com@f.root-servers.net
Ви можете скористатися послугою whois. У операційній системі на зразок UNIX ви б виконали таку команду. Можна також зробити це в Інтернеті за адресою http://www.internic.net/whois.html .
whois stackoverflow.com
Ви отримаєте таку відповідь.
... текст тут видалено ...
Сервери домену в перерахованому порядку: NS51.DOMAINCONTROL.COM NS52.DOMAINCONTROL.COM
Ви можете використовувати nslookup або копати, щоб дізнатися більше інформації про записи для певного домену. Це може допомогти вам вирішити описані конфлікти.
На жаль, більшість із цих інструментів повертає лише запис NS, як надано самим сервером імен. Щоб бути більш точним у визначенні того, які сервери імен справді відповідають за домен, вам доведеться або скористатися "whois" і перевірити перелічені там домени АБО використовувати "dig [domain] NS @ [сервер імені кореня імен]" і запустити це рекурсивно, поки ви не отримаєте списки серверів імен ...
Мені б хотілося, щоб був простий командний рядок, який можна було запустити, щоб отримати ТОГИЙ результат надійно та у послідовному форматі, а не лише результат, який задається від самого сервера імен. Метою цього для мене є можливість запитувати близько 330 доменних імен, якими я керую, щоб я міг точно визначити, на який сервер імен вказує кожен домен (відповідно до їх налаштувань реєстратора).
Хтось знає про команду, що використовує "dig" або "host" чи щось інше на * nix?
Записи SOA присутні на всіх серверах і надалі за ієрархією, над якою власник домену НЕ контролює, і всі вони фактично вказують на один авторитетний сервер імен, який контролюється власником домену.
Запис SOA на авторитетному сервері, з іншого боку, не є строго необхідним для вирішення цього домену, і може містити фальшиву інформацію (або прихований первинний, або інший сервер з обмеженим доступом) і не повинен покладатися на це для визначення авторитетного сервера імен для даного домену.
Потрібно запитати сервер, який є авторитетним для домену верхнього рівня, щоб отримати надійну інформацію SOA для даного дочірнього домену.
(Інформація про те, який сервер є авторитетним, для якого TLD можна запитувати з серверів кореневих імен).
Коли у вас є достовірна інформація про SOA з авторитетного сервера TLD, ви можете запитати авторитетний сервер основного імені (той, який є у записі SOA на сервері імен gTLD!) Для будь-яких інших записів NS, а потім приступити до перевірки всіх ті сервери імен, у яких ви отримали запит на записи NS, щоб побачити, чи є невідповідність будь-якій іншій записі на будь-якому з цих серверів.
Це все працює набагато краще / надійніше з Linux та dig, ніж з nslookup / windows.
Найпростіший спосіб - використовувати онлайн-інструмент домену. Мій улюблений - доменні інструменти (раніше whois.sc). Я не впевнений, чи зможуть вони вирішити конфліктуючі записи DNS. Прикладом є сервери DNS для stackoverflow.com
NS51.DOMAINCONTROL.COM
NS52.DOMAINCONTROL.COM
Я виявив, що для деяких доменів наведені вище відповіді не працюють. Найшвидший спосіб, який я знайшов, - це спочатку перевірити запис NS. Якщо цього не існує, перевірте наявність SOA. Якщо цього не існує, рекурсивно розв’яжіть ім'я за допомогою dig і візьміть останню повернуту NS-запис. Приклад, який відповідає цьому, єanalyticsdcs.ccs.mcafee.com.
host -t NS analyticsdcs.ccs.mcafee.com.
host -t SOA analyticsdcs.ccs.mcafee.com.
dig +trace analyticsdcs.ccs.mcafee.com. | grep -w 'IN[[:space:]]*NS' | tail -1
host analyticsdcs.ccs.mcafee.com. gtm2.mcafee.com.