Windows, що додає доменний суфікс до всіх пошукових запитів

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

C:\Users\Username>nslookup www.yahoo.com 
Server: Linksys
Address: 192.168.0.1

Non-authoritative answer:
Name: www.yahoo.com.EXAMPLE.COM
Address: 192.0.2.99

Я замінив IP-адресу, про яку повідомляється заповнювачем, але я можу вам сказати, що те, що він повертає, є *.записом за замовчуванням у нашій конфігурації Network Solutions. Оскільки явно www.yahoo.com.EXAMPLE.COMне існує, це має сенс. Я вважаю, що внутрішнє обладнання користувача працює належним чином. Внутрішньо ми запускаємо сервер DHCP і DNS на базі Windows 2k3 Active Directory w / Windows. Врешті-решт проблема вирішується зазвичай через пару годин або кілька перезавантажень.

Хтось бачив таку поведінку раніше?

Якщо запустити nslookup і ввімкнути налагодження, ви побачите, що Windows завжди намагається спочатку додати свій суфікс.

C:\>nslookup
Default Server:  itads.example.com
Address:  0.0.0.0

> set debug=true
> www.yahoo.com
Server:  itads.example.com
Address:  0.0.0.0

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        www.yahoo.com.example.com, type = A, class = IN
    AUTHORITY RECORDS:
    ->  example.com
        ttl = 3600 (1 hour)
        primary name server = itads.example.com
        responsible mail addr = itads.example.com
        serial  = 12532170
        refresh = 1200 (20 mins)
        retry   = 600 (10 mins)
        expire  = 1209600 (14 days)
        default TTL = 3600 (1 hour)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 4,  authority records = 0,  additional = 0

    QUESTIONS:
        www.yahoo.com, type = A, class = IN
    ANSWERS:
    ->  www.yahoo.com
        canonical name = www.wa1.b.yahoo.com
        ttl = 241 (4 mins 1 sec)
    ->  www.wa1.b.yahoo.com
        canonical name = www-real.wa1.b.yahoo.com
        ttl = 30 (30 secs)
    ->  www-real.wa1.b.yahoo.com
        internet address = 209.131.36.158
        ttl = 30 (30 secs)
    ->  www-real.wa1.b.yahoo.com
        internet address = 209.191.93.52
        ttl = 30 (30 secs)

------------
Non-authoritative answer:
Name:    www-real.wa1.b.yahoo.com
Addresses:  209.131.36.158, 209.191.93.52
Aliases:  www.yahoo.com, www.wa1.b.yahoo.com

Як ви бачите вище, моя машина спершу спробувала пошукати www.yahoo.com.example.com, і сервер DNS відповів NXDOMAIN(запис не знайдено). Ви можете підтвердити це, запустивши nslookup www.yahoo.com.(зверніть увагу на крапку в кінці .com!), І ви побачите, що це вирішено нормально.

Що відбувається, що ваш зовнішній DNS-сервер відповідає, що у них є запис для "www.yahoo.com.example.com", і повертає вашу IP-адресу для кореня вашого сайту. Я не впевнений, якою послугою ви користуєтесь, але я здогадуюсь, що у вас є відображення підстановки, яке повідомляє ваш сервер відповідати на будь-який невідомий запит з дійсною відповіддю, а не повертатися NXDOMAIN. Вам потрібно перевірити ще раз свої настройки для сервера і переконайтеся , що він встановлюється тільки відповідати на запити для записів він на самому справі має ( example.com, www.example.com, mail.example.comі т.д.).

Пам'ятайте, що DNS працює, перевіряючи налаштований сервер і працюючи звідти. Запит DNS може пройти такий шлях, як наступний малюнок (звичайно, це лише приклад, це, мабуть, неправильно): Машина -> локальний маршрутизатор DNS (linkys) -> DNS провайдера -> (2-й DNS провайдера?) -> Root DNS сервера -> TLD DNS -> Ваш зовнішній DNS-сервер. Хтось на цьому шляху говорить, що www.yahoo.com.example.comіснує. Ймовірно, це ваш зовнішній DNS-сервер.

EDIT

Я подумав, що включу ще один примх про випадковість, яку ви згадуєте. Якщо це справді відбувається епізодично, у вас може бути неправильно налаштований зовнішній сервер DNS або їх провайдер може надавати службу викрадення DNS. На жаль, я бачив, що все більше і більше приватних Інтернет-провайдерів надають "послугу пошуку" для недійсних доменних імен. Оскільки майже всі кінцеві користувачі використовують свої DNS-сервери провайдерів, то тепер Інтернет-провайдери починають перенаправляти недійсні записи домену на сторінку пошуку - зазвичай це об’ява, нерелевантні посилання та невелике "Ви мали на увазі www.example.com?" з деякими результатами, які можуть бути або не пов’язані з доменним іменем. Я знаю, що Verizon і Comcast починають це робити, я вважаю, що Quest також починає. Іншою можливістю є OpenDNS, оскільки вони забезпечують той самий "пошук пов'язаного домену", якщо він не '

Моя проблема з тим, що я вважаю, що проблема полягає в тому, що ви говорите, що вона повертає адресу вашої кореневої записи, що жодне з них не зробило б, якби вони намагалися її шукати, вони дадуть вам IP-адресу одного їх веб-серверів для обробки пошуку.

Після п'яного загального налаштування реєстру Windows 7 tcpip у мене виникла та сама проблема. В:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters

переконайтеся, що ваш запис для домену такий самий, як ваш запис для dhcpdomain, тоді вам добре піти.

Я боровся з тією ж проблемою, що мої вікна додають основний суфікс домену під час використання nslookup. Я знайшов таке рішення, що додавання крапки до запиту не дозволяє цим Windows робити. Тож замість використання:

nslookup yahoo.com 192.168.0.1

використання

nslookup yahoo.com. 192.168.0.1.

За словами джерела, інші запити не повинні показувати цю поведінку.

Джерело (3-е повідомлення) тут https://social.technet.microsoft.com/Forums/windows/en-US/a34896f6-d784-4e52-8252-54f6520bc495/dns-queries-all-have-my-internal-domain- ім'я, застосоване до запитів, наприклад, googlecommydomaincom? forum = winserverNIS

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

Наприклад, якщо ваше доменне ім’я провайдера - це x.com, а ви доменне ім’я вводите в цьому полі як y.com. Маршрутизатор все ще надасть DNS, налаштований в інтерфейсі WAN та LAN, як авторитетний DNS, але неавторитетний буде наданий з цього сайту y.com.

Я знайшов відповідь. У налаштуваннях реєстру HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ Параметри, знайдіть список пошуку. Двічі клацніть по ньому та видаліть те, що є у вікні. Виправлена ​​шахта. Тепер nslookup правильний. У мене було щось від роботодавця, що я використовував свій особистий ПК для віддаленої роботи. Ніколи більше не буду працювати в цій компанії. Я все ще знаходжу шахрайські записи.

У мене був такий самий випуск.

Був наданий сервером DHCP

Видалення значення реєстру домену вирішує проблему HKLM \ SYSTEM \ CurrentControlSet001 \ Services \ Tcpip \ Параметри

Для мене, використовуючи bind9 як авторитетний локальний сервер імен та авторитетний сервер імен для того ж домену, я можу виправити цю поведінку, видаливши *.example.comзапис (коментується нижче).

З /etc/bind/example.com зонального файлу

; *. example.com. У CNAME example.com. ; ГЛОБАЛОК

Це було встановлено для зручності, не потрібно вручну встановлювати всі перенаправлені порти піддомени на один і той же загальнодоступний IP.

Побічний ефект є таким, як описано батьком. Усі запити відповідають одній загальнодоступній IP-адресі. Програми та сервіси працюють нормально, проте nslookup ніколи не повертає IP-адреси, що є невеликим неприємністю, яке я витримав за півроку до того, як відкрити цю сторінку і приведуть мене до вищевказаного виправлення.