Як перевірити, чи поширюється інформація про DNS?

16

Я встановив новий запис DNS для одного з моїх піддоменів (я ще не встановив жодного віртуального хоста Apache або нічого подібного). Як я можу перевірити, чи розповсюджується інформація про DNS?

Я припускав, що я можу просто ping my.subdomain.comі припустити, що якщо це вдасться вирішити, він покаже IP-адресу, яку я вказав у записі A. Однак я не знаю, чи я припускаю правильно. Який найкращий спосіб перевірити цю інформацію?

domain-name-system 
— Андрій
джерело
3
Не дурне питання. Дізнатися подібну річ не так прямо.
— aseq
1
Я погоджуюся з @aseq, що це не тупе питання, але "спробуйте і подивіться", це дало б і вам відповідь. Це також те, що Google міг би відповісти так само легко за найменші зусилля (пошук How to test if DNS information has propagated- заголовок кривавого питання генерує хороші результати Google).
— voretaq7
4
Я не думаю, що ти витрачав час людей. Ваше запитання спровокувало кілька цінних відповідей. Ніколи не знаєш, як може вийти просте, здавалося б, просте запитання, яке може «просто заграти». Одне з цінностей цього форуму полягає в тому, що відповіді та питання можна легко розширити.
— aseq
1
@andrew нічого поганого в тому, щоб запитати те, що багато хто з нас розглядає як прості запитання - це, мабуть, буде найкращим результатом google для цієї рядка через кілька днів через те, як сайт індексується / займає рейтинг. Взагалі, хоча Google є кращим (швидшим) місцем для пошуку: якщо Google не знає, то запитайте тут (і Google навчиться) :-)
— voretaq7
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 може знадобитися очистити. Хоча у вашому випадку це не стосується, оскільки це новий запис. У такому випадку він повинен бути доступний негайно. Вищенаведений спосіб є більш точним у тому, щоб дати вам ідею, а не просто її пінг.

Якщо ви використовуєте Windows, то команди та синтаксис можуть дещо відрізнятися, але вони досить схожі.

— aseq
джерело
3
+1 Якщо ви щось робите з DNS, дістаньте копію dig(* nix систем уже є, доступні різні версії для Windows).
— Chris S
3
-1. Мені шкода. Я справді є, але ця відповідь "поширює" міф, який розповсюджують записи DNS, які вони, звичайно, НЕ. Термін, який ви шукаєте, це "кешування", що відбувається з записами DNS на основі TTL запису. Оскільки ОП посилається на новий запис 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 для позитивного чи негативного попадання. Однак є випадки, коли програми впроваджують неправильну логіку та кешують відповіді протягом більш тривалого періоду часу.
— Бангданг
2
Я не думаю, що вам дійсно потрібно дотримуватися точного визначення, щоб отримати бал. Крім того, я думаю, що пропагування не є поганим словом. Це висвітлює тему в тому сенсі, що кешування записів DNS поширюється на більш широке коло серверів. Це поширення - це те, що поширюється. Я оновив свою відповідь, щоб відобразити факт, що новий запис доступний негайно.
— aseq
1
@aseq, це оманливий термін. В основному виявляється, що ppl, які думають / говорять про DNS як своєрідне "поширення", не знають, як працює 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 знають, що насправді відбувається, оскільки вони читають технічні деталі.
— Скаперен
Щоправда ... Я просто ненавиджу використання терміна, який "поширює" помилкове уявлення про те, як працює DNS.
— joeqwerty
5

Хоча інші відповіді досить хороші, пам’ятайте, що те, що вам пропонується, може не передаватися мені. замість того, щоб використовувати DIG або NSlookup і витрачати годину на перевірку DNS-серверів по всьому світу, я зазвичай використовую http://www.whatsmydns.net/, щоб побачити, як відбувається поширення.

— Джим Б
джерело
У DNS немає поширення, цей термін є досить оманливим для всіх типів ламерів, які не опиняться читати RFC, тому не <strike> розповсюджуйте </strike>, не використовуйте цей термін, будь ласка. ;-D
— poige
1
Звичайно, існує поширення в DNS, коли RFC припускає, що читач розуміє, що інформація може поширюватися, коли сервери виконують пошук і кеш. Це особливо очевидно, коли ламери читають RFC, тоді дивуються, чому запис на їх сервері не відповідає результатам пошуку з іншого сервера. Вони виявляють, що у propagate є визначення "широко розповсюджуватися" (саме це потрібно перевірити - розповсюдження оновлених записів)
— Jim B
Ні поширення, ні розповсюдження (крім господаря до раба).
— poige
Це, мабуть, реліквія від того, коли іноді знадобилося близько дня, щоб змінити домени .com, завантажені на кореневі сервери імен (зворотній час, коли .com був у коренях!)
— Cakemox
@ poige- дякую за те, що ви не зрозуміли, як працює кешування DNS. Я б запропонував прочитати RFC про те, як працює DNS і, можливо, перевірити веб-сайт, на який я пов’язаний, на приклади реального світу.
— Джим Б
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

Це дотримуватиметься делегування серверам імен, авторитетним для вашого запиту. Остання відповідь, як правило, та, яка вас найбільше хвилює, але слід корисний у тому, що вона покаже, хто відповідає за кожну делегацію. Якщо ви змінюєте сервери імен, це може бути дуже корисно.

Майте на увазі, що слід буде безпосередньо запитувати авторитетні сервери, тому кешування немає. Це найкращий показник того, що відповіді повертаються так, як очікувалося, але це не є хорошим показником того, що можуть відчути кінцеві користувачі. Однак, оскільки ви часто не маєте контролю над кешуванням серверів імен інших людей (крім того, щоб передбачити знизити свій TTL, зачекайте оригіналу TTL, внісши зміни, а потім відновивши TTL), зазвичай не варто перевіряти факт.

— Cakemox
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.