Розбираючись з DNS

1. Розуміння DNS приходить з досвідом Нещодавно в нашій мережі стали виникати блукаючі помилки розпізнавання...
2. Про кешуванні
3. Техніка пошуку та усунення помилок
4. Про хостах
5. Багатосерверних / многоадаптерние конфігурації
6. Nslookup
7. Додамо трохи AD
8. Знання - в життя
9. Помилка маленька - проблеми великі
10. Управління позитивним і негативним кешуванням
11. Інструменти для виявлення і усунення несправностей DNS

Розуміння DNS приходить з досвідом

Нещодавно в нашій мережі стали виникати блукаючі помилки розпізнавання імен DNS. Відловлювати спорадичні помилки розпізнавання імен - заняття невдячне, тим більше що з неполадками в DNS я не стикався досить давно і мої навички злегка «припадають пилом». Я б вважав за краще битися з дюжиною інших проблем, ніж з цієї. Про існування служби DNS легко забути, поки вона не почне давати збій, - все чудово працює, як належить, - Internet, поштовий клієнт, поштовий сервер, контролери домену. Минуло кілька років з тих пір, як мені в останній раз довелося усувати проблеми з DNS, так що я розцінив виникли помилки як знак згори: пора згадати корисні навички.

Оскільки DNS є основою нормального функціонування середовища AD, а також тією ланкою, яка поєднує в ланцюжок все мережі в Internet, вміння точно виявляти джерело неполадок в DNS і усувати причину помилки має величезне значення для супроводу корпоративної мережі. Спочатку ми розглянемо особливості вирішення проблем DNS, не пов'язані з AD, а потім подивимося, що привносить AD.

дозвіл імен

Вся ієрархія DNS будується від кореневого домена (root domain). Кореневої домен підтримується 13 головними окремими серверами, робота яких забезпечується комерційними, урядовими та освітніми установами. У граничному випадку ці кореневі сервери беруть участь в процесі вирішення будь-яких громадських імен в Internet. Коли мережевий комп'ютер звертається до хосту з ім'ям download.beta.example.com, в першу чергу він повинен отримати IP-адресу цього хоста. Цей процес може зажадати до 10 різних запитів DNS, починаючи з першого, з яким комп'ютер звертається до сервера, налаштованому як сервер DNS. Стандартний процес розпізнавання імен зображений на Мал. 1 .

Як видно з малюнка, локальний сервер DNS для визначення відповідного IP-адреси використовує рекурсивні запити - один з двох видів запитів DNS (другий тип називається ітеративним). Кожен публічний сервер DNS, на який потрапляє запит, або видає кінцевий результат (виконує дозвіл імені), якщо йому відома відповідь, або відправляє на пов'язаний з ним вищестоящий сервер DNS, намагаючись визначити невідомий адресу. Оскільки кореневий сервер DNS нічого не знає про кінцевих індивідуальних хостах в Internet, яким є комп'ютер beta.example.com, він повідомляє, що нічого не знає про подібний адресу, але радить опитати сервер, що обслуговує домен .com. У міру того як рекурсивний процес триває, дозвіл імені може статися на одному з етапів, і результатом запиту буде або шуканий IP-адреса, або відмова.

Описана процедура розпізнавання імен може ввести користувача в оману: можна подумати, що кореневі сервери доменів - це гігантські суперкомп'ютери, які до того ж часто ламаються через надмірну навантаження. Насправді ж кореневі сервери великого навантаження не відчувають завдяки другому елементу процесу розпізнавання імен - кешуванню.

Про кешуванні

Повернемося до зображеного на Мал. 1 процесу розпізнавання імен, але на цей раз допустимо, що локальний сервер DNS вже звертався до поштового сервера для домена example.com, перш ніж звернутися до download.beta.example.com. В цьому випадку локальний сервер DNS вже володіє інформацією про те, як знаходити відповідальний за домен example.com сервер DNS (по крайней мере, він був таким кілька хвилин тому). В цьому випадку можна звернутися безпосередньо до сервера DNS домену example.com замість того, щоб знову звертатися до сервера кореневого домена. В цьому випадку кроки 2, 3, 4 і 5 в процесі дозволу імені виявляться необов'язковими, завдяки чому комунікаційний трафік знижується на 40%.

Кешування виконується на всіх рівнях ієрархічної інфраструктури DNS. Забігаючи вперед, скажу, що, якщо хто-небудь ще в локальній мережі звернеться до того ж хосту download.beta.example.com, локальний сервер DNS зможе обробити запит з локального кешу, оскільки потрібний хост вже був недавно знайдений, і таким чином залишаються тільки кроки 1 і 10 зі схеми, наведеної на рис. 1. Це відповідає 80-процентного скорочення комунікаційного трафіку.

Кешування виконують не тільки сервери DNS, а й клієнти, так що будь-яка робоча станція, яка нещодавно запитувала дозвіл імені хоста, буде деякий час пам'ятати його. Якщо додаток (Web-браузер, поштовий клієнт) на хості повторно запросить запис DNS, Windows буде використовувати локальну копію замість того, щоб кожен раз направляти запит DNS. Таким чином, комунікаційний трафік скорочується до нуля.

Ця ієрархія кешування, яка виконується на кожному сервері і клієнті, залучених до процесу розпізнавання імен DNS, підтримує працездатність DNS у всьому Internet. Однак кешування під час пошуку та усунення несправностей може і перешкодити.

Техніка пошуку та усунення помилок

Розуміння принципів взаємодії і кешування DNS дозволить витрачати менше часу на пошук і усунення несправностей. Давайте розглянемо, як працює механізм розпізнавання імен DNS при спробі дозволу імені DNS в IP-адресу. Як показано на екрані 2, в першу чергу виконується перевірка імені в локальному кеші, і, якщо шуканий адресу вже відомий, він відразу повертається, і ніякого мережевого трафіку не генерується, в іншому випадку виконується стандартна процедура розпізнавання імен. Це здається очевидним, але все ж слід знати, що саме відбувається в кеші.

У кеші зберігаються два основних типи записів - ті, які були знайдені в результаті запитів до сервера DNS, і ті, що були попередньо завантажені з файлу \% systemroot% system32driversetchosts. Записи першого типу застарівають після закінчення певного інтервалу часу TTL (Time To Live), який задається в отриманому від сервера DNS відповіді.

Для перегляду вмісту кеша і відображення залишку часу можна запустити з командного рядка команду ipconfig / displaydns. Як приклад я запустив пошуковий запит на www.google.com, а потім виконав перевірку ipconfig / displaydns. Як показано на екрані 1 , Запис має значення TTL, рівне 248 секундам. На момент виконання запиту DNS час зберігання інформації TTL про домен google.com становило 5 хвилин - що, втім, не дивно для компанії, яка має велике і динамічно змінюється присутність в Internet. Більш статичні організації зазвичай мають більш тривалий значення TTL, наприклад один день (86 400 секунд). У будь-якому випадку цей запис буде зберігатися в кеші протягом 5 хвилин, і, якщо звернутися до google.com повторно, Windows не направлятиме запит до сервера DNS, а візьме адреса з кешу.

Крім кешування позитивних відповідей, Windows також запам'ятовує негативні відповіді. Негативна відповідь полягає в тому, що сервер DNS вважає себе відповідальним за даний домен, але у нього немає запису про хості, необхідної в запиті. Хоча в негативних відповідях не міститься відомостей про TTL, Windows запам'ятовує ці відповіді на період часу від 5 до 15 хвилин, в залежності від використовуваної версії Windows і додаткових налаштувань. Більш докладно про управління кешуванням негативних відповідей за допомогою налаштувань реєстру розказано в урізанні «Управління позитивним і негативним кешуванням» .

Ті, кому довелося зіткнутися з проблемами розпізнавання імен в своїй мережі, можуть очистити кеш DNS за допомогою команди ipconfig / flushdns (і зовсім не обов'язково правити реєстр). Очищення кешу DNS - це одноразова операція, яка видаляє з пам'яті всі збережені значення і дозволяє почати все з чистого аркуша. Очищення кеша можна повторити в будь-який момент. При цьому слід мати на увазі, що, якщо у вас є локальний сервер DNS, він, швидше за все, запам'ятовує всі адреси, до яких звертаються комп'ютери мережі. Щоб очистити кеш DNS на серверах DNS, варто скористатися оснащенням DNS консолі управління MMC. Для запуску в меню «Пуск» потрібно вибрати «Програми», «Адміністрування», DNS. Клацніть правою кнопкою миші на імені сервера DNS і виберіть Clear Cache.

Очищення кешу DNS - хороший засіб налагодження для тих, хто займається тестуванням в мережі чого-небудь, пов'язаного з дозволом імен, якщо небажані події відбулися за останні 5-15 хвилин. Слід мати на увазі, що при очищенні кеша DNS Windows автоматично відразу завантажує в кеш адреси з файлу \% systemroot% system32driversetchosts.

Про хостах

Хоча кешування іноді заважає, воно може виявитися і дуже корисним. У кеші зберігаються як копії знайдених при вирішенні імен адрес, так і статичні елементи, які визначені в файлі hosts на локальному комп'ютері. Файл hosts виявився вельми зручним засобом пошуку та усунення несправностей, що дозволяє управляти дозволом імен DNS.

Наприклад, коли кілька серверів відповідають на одне й те саме ім'я, а потрібно, щоб мій комп'ютер підключався до одного конкретного, я можу використовувати файл hosts. Розглянемо випадок, коли кілька серверів доступу Microsoft Outlook Web Access використовують загальний адресу URL, який задається DNS. Якщо користувачі починають скаржитися на виникнення випадкових помилок OWA, як визначити, який з серверів тому причиною? Файл hosts дозволяє відмовитися від послуг розпізнавання імен DNS і підставити потрібну адресу - для цього необхідно всього лише внести в файл hosts значення, воно потрапить в кеш і буде присутній там постійно. Файл hosts має простий формат - в одному рядку вказуються IP-адреса і символьне ім'я. Служба розпізнавання імен оновлює значення в кеші автоматично при збереженні файлу hosts, так що зміни вступають в силу негайно.

Багатосерверних / многоадаптерние конфігурації

Розглянемо докладніше схему, наведену на Мал. 2 . Ми розглянули кроки, виконувані в тих випадках, коли запит може бути дозволений з локального кеша. Але якщо локальний кеш не дозволяє виконати дозвіл запиту, то як далі здійснюється процес розв'язання імені? Windows продовжує процес розпізнавання імен, видаючи рекурсивні запити DNS до серверів, зазначеним в якості бажаної (настройка сервера DNS виконується в параметрах протоколу TCP / IP для кожного мережевого адаптера, як показано на екрані 2). Якщо Windows не отримує жодної відповіді від переважного сервера DNS протягом секунди, цей же запит передається по іншим мережних інтерфейсів з інтервалом очікування 2 секунди. Якщо відповіді як і раніше немає, Windows виконує три повторні спроби отримати відповідь на запит. Кожен наступний раз встановлюється більш тривалий інтервал очікування (2, 4 і 8 секунд відповідно), а потім робиться звернення до всіх інших серверів DNS по всіх наявних мережних інтерфейсів. Загальний час дозволу адреси DNS не повинно перевищувати 17 секунд.

Який механізм вибору кращого і прийнятного мережевого адаптера (в Microsoft використовують термін under consideration - «розглянутий»). Технічна документація Microsoft дає розпливчасті відповіді в питаннях розпізнавання імен. Наприклад, якщо всі сервери DNS для певного адаптера було опитано і жоден з них не відповів, даний адаптер виключається з розгляду на 30 секунд. Можна припустити, що при цьому адаптер тимчасово виключається з категорії «прийнятний» на вказаний інтервал часу, хоча в документації про це ані слова. Крім того, в документації Microsoft зазначено, що служба дозволу імен DNS запам'ятовує час відгуку серверів DNS і може вибирати кращий сервер в залежності від швидкості отримання відповіді на запити, - мабуть, такий же підхід використовується і для визначення кращого адаптера.

Затвердження Microsoft про те, що служба дозволу імен може змінювати порядок проходження бажаних серверів DNS, суперечить налаштувань, які можна знайти в розширених вікнах налаштувань DNS для мережевих адаптерів, де порядок проходження визначається адміністратором при завданні конфігурації. У великій кількості документів Microsoft дана інша інформація. Тому я не дуже довіряю відомостями про те, в якому порядку служба дозволу імен звертається до серверів DNS при вирішенні імен. Коли мені доводиться займатися пошуком і усуненням несправностей, я користуюся інструментами типу Network Grep (Ngrep) і WinDump для перевірки відправляються комп'ютером запитів DNS і серверів, яким ці запити адресовані.

У наступній статті я планую розповісти докладніше про ці інструменти, а також про програми, з якими читачі, найімовірніше, не знайомі. Деякі корисні інструменти для роботи з DNS описані в урізанні «Інструменти для виявлення і усунення несправностей DNS» .

Nslookup

Тепер, розібравши принципи виконання запитів DNS і те, яким чином служба дозволу імен DNS направляє запити DNS через встановлені в комп'ютері мережеві інтерфейси, можна задіяти утиліту командного рядка Nslookup, яка, безумовно, є одним з основних інструментів вирішення проблем з DNS і пошуку та усунення несправностей.

Nslookup може запускатися в неінтерактивному режимі і дозволяє тестувати пошук і дозвіл імен хостів з використанням стандартної служби розпізнавання імен Windows. приклад:

nslookup www.windowsitpro.com

З іншого боку, можна направити запит DNS на конкретний сервер замість тих, які вказані на локальному комп'ютері. Для цього досить додати в кінці командного рядка адресу даного сервера DNS:

nslookup www.windowsitpro.com 10.0.0.1

Це знадобиться, якщо потрібно переконатися, що одержувані відповіді виходять саме від даного сервера DNS.

Щоб більш детально вникнути в процес розпізнавання імен, можна запустити Nslookup в інтерактивному режимі, який дозволяє вибирати сервер, тип запиту (рекурсивний або ітеративний) і деталізацію налагоджувальної інформації. Розглянемо для прикладу кілька сценаріїв виявлення несправностей.

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

Я виконав пошук для повного доменного імені комп'ютера (FQDN) www.windowsitpro.com , Налаштувавши Nslookup для використання ітеративних запитів. У запрошенні я ввів параметр Set Norecurse, потім вказав кореневий сервер за допомогою параметра Server і виконав запит. Слідуючи за адресами серверів, я простежив весь ланцюжок, вказуючи вручну цільової сервер при кожній ітерації. Такий спосіб дає значно більше інформації для пошуку і усунення несправностей, ніж виконання стандартного запиту до локального сервера DNS і аналіз даних, які приходять у відповідь.

Якщо для вирішення завдання не потрібно виконувати повний ітеративний опитування, а просто потрібна більш детальна інформація про проходження запитів і підлягає поверненню інформації, можна задіяти ключі Set Debug або Set D2 для відображення налагоджувальної інформації про виконання запиту DNS. На екрані 3 наведено результат виконання прикладу запиту дозволу імені www.windowsitpro.com . Аналогічно ключ Set Type дозволяє використовувати Nslookup для швидкого пошуку певних типів записів в домені по їх типу. Для пошуку поштових серверів потрібно вказати ключ MX (Mail Exchange), а для серверів імен - NS (Name Server).

Додамо трохи AD

Тепер, коли ми познайомилися з концепціями кешування, послідовного і рекурсивного виконання запитів, а також з прийомами діагностики проблем розпізнавання імен в Internet, не складе великих труднощів розібратися з тими особливостями, які привносить AD. Інтеграція DNS і AD відбувається на двох рівнях: по-перше, DNS є основним механізмом, за допомогою якого комп'ютери в мережі знаходять інші хости в середовищі AD, по-друге, дані DNS - список існуючих хостів і їх адреси IP - реплицируются між серверами DNS через механізм реплікації AD. Механізми реплікації AD обговорювалися на сторінках журналу досить докладно, так що розглянемо додаткову інформацію, яка міститься в записах DNS в середовищі AD.

Записи AD містять відомості про динамічної реєстрації, які створюються автоматично клієнтськими комп'ютерами, серверами і робочими станціями в середовищі AD і містять ім'я комп'ютера і його адреса IP. Клієнт служби DHCP виконує процес реєстрації при запуску служби навіть в тому випадку, якщо адреса присвоюється статично. У відповідних властивостях IP клієнт служби DHCP реєструє свою адресу на серверах DNS, для роботи з якими він налаштований. Якщо ви встановили додаткові мережеві інтерфейси, призначені для виконання спеціальних завдань (наприклад, виділена мережа для виконання резервування на стрічкові бібліотеки), причому ці інтерфейси не повинні відповідати на надходять по ним запити клієнтів, процес автоматичної реєстрації може створити проблеми з дозволом цих імен DNS.

Наприклад, ці спеціальні мережеві адаптери можуть бути зареєстровані з адресами IP в DNS, в той час як було небажано, щоб ці мережеві адреси видавалися в якості можливих варіантів при вирішенні імен. Якщо це все-таки сталося, можна скасувати реєстрацію мережевого інтерфейсу. Для цього необхідно виконати редагування додаткових властивостей DNS для даного інтерфейсу і зняти прапорець Register this connection? S address in DNS ( «Зареєструвати це з'єднання в DNS»), як показано на екрані 4. В іншому випадку Windows обов'язково спробує зареєструвати в DNS всі наявні мережеві інтерфейси.

Крім автоматичної реєстрації цих записів хостів (записи типу А), Windows виконує для контролерів доменів реєстрацію додаткових записів сервера (записи SRV). Запис SRV визначає тип участі комп'ютера в AD при обробці спеціальних завдань аутентифікації. Записи SRV не є чимось унікальним для AD, навпаки, це стандартний тип записів DNS, який визначає зареєстровані в домені служби, хости, на яких ці служби можуть бути знайдені, використовувані порти і протоколи. Аналогічно тому, як записи поштової служби MX вказують, що служба SMTP може бути знайдена на певному порту (т. Е. Порт 25) на даному сервері, записи SRV надають посилання для будь-якого типу служб на будь-якій системі. Наприклад, запис SRV, що визначає хост example.com як Web-сервер, може мати наступний вигляд:

_http._tcp.example.com SRV 0 0 80 www.example.com

Розглядаючи цей приклад, можна зробити наступні висновки: служба TCP, відома як HTTP, доступна в домені example.com; вона доступна по порту 80 для хоста з ім'ям www.example.com. У середовищі AD контролер домену реєструє чотири типи записів SRV на серверах DNS, на роботу з якими він налаштований:

_ldap._tcp.example.com SRV 0 0 389 dc.example.com _kerberos._tcp.example.com SRV 0 0 88 dc.example.com _ldap._tcp.dc._msdcs.example.com SRV 0 0 389 dc.example .com _kerberos._tcp.dc._msdcs.example.com SRV 0 0 88 dc.example.com

Ці записи дозволяють клієнтам AD визначати, де знайти служби LDAP і Kerberos, які необхідні в домені example.com для виявлення інших ресурсів AD і аутентифікації доступу до цих ресурсів. Ці чотири приклади записів SRV повідомляють залежать від AD клієнтам про контроллер домена dc.example.com (гіпотетичний контролер домену example.com), який буде використовуватися для всіх видів аутентифікації.

За допомогою оснастки DNS MMC слід зробити ці записи доступними для серверів DNS. Необхідно також мати можливість переглядати їх з клієнта за допомогою Nslookup.

Знання - в життя

Після застосування Nslookup мені вдалося швидко визначити джерело проблеми. Справа була в помилку кешування, пов'язаної з відповідями мого провайдера на деякі запити DNS. Для визначення причини неполадок мені довелося виконати ітеративний процес розв'язання адреси власного комп'ютера. Після цього я зміг швидко налаштувати альтернативне вирішення зовнішніх імен DNS, а провайдер зайнявся усуненням власних недоробок. Проблема була вирішена швидко, і мої клієнти знову змогли користуватися повнофункціональним дозволом імен. Знання принципів роботи DNS в поєднанні зі зручними засобами виявлення помилок дозволяють без праці усувати більшість проблем з DNS.

Дуглас Тумбс - Редактор журналу Windows IT Pro. [email protected]

Помилка маленька - проблеми великі

Адміністратор мережі Скотт Рассел розслідує містичну помилку DNS

«Я двічі перевстановив сервер DNS відповідно до наявної документацією, але це не допомогло. Зрештою я зв'язався з провайдером і дізнався, що головна компанія поміняла записи DNS і MX на всіх серверах ... »

Коли о 8 вечора Скотту Расселу подзвонив ІТ-адміністратор з колишнього місця роботи, він зрозумів, що це не просто данина ввічливості. Два дні тому у них в компанії перестало працювати підключення до Internet. Співробітники не могли користуватися електронною поштою через корпоративний сервер Exchange і реєструватися в мережі Windows 2000 Server. Фахівці в галузі інформаційних випробували все, що могли, але безуспішно. Скотт погодився допомогти, і скоро з'ясувалося, що вся справа в помилку настройки DNS. Рассел працює в галузі ІТ більше 10 років, в даний час він є адміністратором мережі в канадській компанії ABC Window Company. Старший редактор Windows IT Pro Енн Грабб поспілкувалася зі Скоттом Расселом про те, як йому вдалося визначити джерело проблеми і відновити працездатність компанії.

ІТ-адміністратор з вашої попередньої роботи попросив допомогти усунути проблему, яку вони не могли вирішити два дні. У чому ж була справа?

Так, у них нічого не працювало: вони не могли реєструватися в мережі, користуватися Internet і електронною поштою. Коли я був там мережевим адміністратором, ми створили два домена - зовнішній домен company.com для Web і SMTP і внутрішній домен company.net. Ми не реєстрували домен .net, оскільки він був внутрішнім. Наш провайдер забезпечував роботу Web-сайту компанії і тримав у себе зовнішні записи DNS і MX.

Прибувши на місце, я в першу чергу перевірив настройки DNS, щоб переконатися, що все в порядку. У компанії є три контролера домену та два сервера DNS, які я налаштовував, коли працював мережевим адміністратором - там використовувалася служба Windows DNS, інтегрована зі службою каталогу AD. Я двічі перевстановив сервер DNS з тієї документації, яку підготував перед відходом. Це був досить трудомісткий процес.

Треба було розібратися, чому DNS не міг дозволити IP-адреса контролера домену для локального домену company.net. Ми задіяли утиліту Traceroute для адреси IP, який ми використовували, як нам здавалося, і з'ясувалося, що в результаті повертається зовсім інший зовнішній IP-адреса. У нас не було ніяких припущень щодо того, що відбувається, хоча адреса був з того ж діапазону, що і наш. Насамперед ми подумали про зовнішній вторгнення в мережу.

Як же ви визначили, кому належить цей IP-адреса?

Ну, по-перше, я зайшов на сайт підтримки Microsoft ( http://www.support.microsoft.com ) І провів там майже два з половиною години. Поки я вивчав матеріали сайту, мені спало на думку, що хто-небудь міг просто зареєструвати це доменне ім'я. Тоді я вирішив зателефонувати провайдеру. Через три години мені повідомили, що невідомий адреса належить їх материнської компанії. У цей момент з'ясувалося, що материнська компанія зареєструвала доменне ім'я, що збігається з нашим локальним доменом .net.

Звернувшись до них, ми переконалися, що так воно і є. Вони зареєстрували домен .net і змінили всі записи DNS, включаючи і MX, нічого не повідомивши своїм користувачам.

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

Спочатку я запросив у провайдера новий IP-адресу та інформацію про зонах для їх DNS. Потім треба було зареєструвати нашу запис DNS в якості вторинного сервера DNS для їх сервера DNS, щоб ми змогли зареєструватися в системі та виконати необхідні зміни. Я додав вторинну зону в нашу запис DNS і налаштував їх DNS в якості вторинного DNS у нас, так що наш сервер DNS зміг розпізнавати зовнішні імена company.com коректно.

З цього моменту у нас з'явилася можливість працювати з Internet. Потім нам знадобилося реплицировать вторинну зону DNS в AD. Коли ми це зробили, все стало працювати нормально, користувачі отримали можливість реєструватися на сервері і працювати з електронною поштою.

Які рекомендації ви могли б дати колегам по цеху з урахуванням уроків, витягнутих з цієї історії?

По-перше, при виникненні проблем з Internet потрібно обов'язково звертатися до локального провайдера і його материнської компанії. Перш ніж змінювати налаштування своїх серверів DNS, треба дізнатися у технічного персоналу провайдера, не змінювали вони що-небудь в конфігурації. З огляду на нинішні тенденції злиття і поглинання компаній, таке трапляється часто-густо. Я сподіваюся, наш провайдер теж засвоїв, що, змінивши свої налаштування, слід повідомляти про це клієнтам.

І звичайно, я добре запам'ятав свою помилку з використанням домену .net. Тепер для всіх внутрішніх налаштувань DNS я використовую суфікс .local.

Енн Грабб - Старший редактор в Windows IT Pro. Вона маємо більш ніж двадцятирічний досвід роботи, є автором і редактором статей, книг та інших матеріалів з комп'ютерної та юридичної тематики. [email protected]

Управління позитивним і негативним кешуванням

Кешування в Windows виконується відповідно до встановлених за замовчуванням значеннями, які можуть варіюватися в залежності від використовуваної версії Windows і додаткових налаштувань. Для управління кешуванням застосовуються два параметра реєстру.

Розділ HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServices DNSCacheParameters містить параметри, що управляють тривалістю зберігання в кеші позитивних і негативних відповідей. Ці значення в версіях Windows Server 2003, Windows XP і Windows 2000 злегка відрізняються.

Для позитивного кешування в Windows 2000 цей параметр називається MaxCacheEntryTtlLimit, в Window XP і 2003 він називається MaxCacheTtl. Обидва параметра вказують максимальний термін, протягом якого позитивні відповіді можуть зберігатися в кеші. Якщо цей параметр визначений, за замовчуванням його значення дорівнює 86400 секундам (1 день). Це значення має перевагу перед усіма можливими значеннями TTL, які перевищують дане значення. Тому, якщо залишити значення за замовчуванням, Windows буде зберігати позитивні відповіді не більше одного дня, навіть якщо вказане значення TTL одно, скажімо, п'яти днів. Встановивши значення параметра рівним одній секунді, можна практично запобігти кешування позитивних відповідей DNS.

Кешування негативних відповідей управляється параметром NegativeCacheTime в Windows 2000, а в Windows XP і 2003 - MaxNegativeCacheTtl. Значення за замовчуванням становить 300 секунд (5 хвилин) для Windows 2000 і 900 секунд (15 хвилин) для XP і 2003. Негативні відповіді, які повертаються сервером DNS, будуть зберігатися в кеші саме такий час, так що, якщо після першої невдалої спроби сервер DNS отримає нормальне дозвіл імені, він все одно буде повертати відмову на цю адресу до того моменту, поки не закінчиться TTL негативної відповіді. Якщо ви підключаєте нові комп'ютери, негативне кешування дійсно може викликати проблеми в разі спроби знайти комп'ютер до того, як запис про його присутності буде поширена в мережі.

Більш докладні відомості про ці процедури можна знайти в статтях бази знань Microsoft «How to Disable Client-Side DNS Caching in Windows 2000» ( http://support.microsoft.com/default.aspx?scid=kb;en-us;245437 ) І «Disable Client-Side DNS Caching in Windows XP and Windows Server 2003» ( http://support.microsoft.com/default.aspx?scid=kb;en-us;318803 ).

Інструменти для виявлення і усунення несправностей DNS

У статті, присвяченій пошуку та усунення несправностей в роботі служби DNS, неможливо обійти увагою сайт DNSstuff.com ( http://www.dnsstuff.com ). Цей сайт розроблений і підтримується Р. Скотт Пері. Тут безкоштовно надаються кошти для роботи з DNS, IP-адресами, доменами і т.д., призначені для простого і зручного пошуку і усунення несправностей з використанням Web-служб. Ці інструменти дозволяють виконати розпізнавання в IP-адреси, зворотний пошук (reverse lookup), пошук WHOIS, а також перевірку вибраних адрес IP на входження в базу адрес - відомих джерел спаму. Я вважаю DNSstuff.com надзвичайно зручним інструментом для налагодження DNS у клієнтів.

Примітно, що пропонований цими засобами варіант пошуку хоста дозволяє автоматично виконати ітеративний запит DNS, починаючи з кореневих серверів, і пройти весь шлях до кінцевого імені хоста з використанням зручного і красивого Web-інтерфейсу. Це позбавляє від необхідності виконувати цю процедуру вручну за допомогою Nslookup і дозволяє продемонструвати клієнтам результати в набагато більш зручною і зрозумілій формі. До того ж DNSstuff.com містить функцію опитування основних Internet-провайдерів для перевірки, чи не видають вони різні кешированниє відповіді на один і той же запит DNS.