Назад | Перейти на главную страницу

разрешение локального короткого имени хоста: DNS / BIND против netbios против Windows

Короткий вопрос: как я могу пинговать по короткому имени хоста из Windows, если DNS правильный?

Длительная экспозиция:

На удерживании

С самого начала мне было поручено заняться другими вещами, поэтому я еще не вернулся к этому. Спасибо тем, кто ответил до сих пор - и будьте уверены, я не сбежал с бесплатных советов, не оставив ни благодарности, ни подтверждения. Я вернусь к этому как можно скорее и сообщу, какое решение (будет) сработало.


У меня есть домен Windows (контроллер: Leo) и новый ящик RHEL7 (Peanut), обслуживающий внутренний DNS. Мне нужно проверить связь и получить доступ к ресурсам Samba по короткому имени хоста.

Лео и Сэм были здесь всегда, Лео обслуживает DNS. Арахис совершенно новый.

192.168.0.2  - Leo - Windows, domain controller, DNS server
192.168.0.3  - Sam - smug DNS resolution test target
192.168.0.29 - Peanut, BIND 9.9.4-RedHat-9.9.4-14.el7 (ESV)

Первым очевидным решением было добавить Peanut в DNS Лео; это работает, но разрешает только запросы FQDN - без коротких имен.

C:\bin>nslookup peanut.internal.local 192.168.0.2
Server:  peanut.internal.local
Address:  192.168.0.29

Name:    peanut.internal.local
Address:  192.168.0.29

Я видел много ссылок на NetBios, но ни один из них не назвал это хорошей идеей. Тем не менее я настроил netbios name в smb.conf. Следует отметить, что я ничего не знаю о NetBios.

Я установил DNS на Peanut, думая, что Linux предоставит мне больше возможностей и гибкости - так оно и было. Один парень сказал DNS не может использовать короткие имена - обескураживающе, но я нашел способ сделать это возможным. Я думал, что справился с этим, когда nslookup начал распознавать короткие имена.

DHCP теперь использует Peanut в качестве основного DNS-сервера, а Leo - в качестве вторичного, что я проверил с помощью ipconfig в Windows и nmcli в Linux. У меня был синдром преждевременного успеха из-за предвзятости в устранении неполадок Linux до того, как я удалил Сэма из моего файла hosts. Linux использует DNS именно так, как я хочу, чтобы это работало:

# [09.32.04] ROOT@linnicks [etc] 18   grep peanut /etc/hosts
:( [09.32.08] ROOT@linnicks [etc] 19   ping peanut
PING peanut (192.168.0.29) 56(84) bytes of data.
64 bytes from peanut.internal.local (192.168.0.29): icmp_seq=1 ttl=64 time=0.182 ms
64 bytes from peanut.internal.local (192.168.0.29): icmp_seq=2 ttl=64 time=0.339 ms
^C
--- peanut ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.182/0.260/0.339/0.080 ms
# [09.32.12] ROOT@linnicks [etc] 20

DNS работает, но клиенты Windoze по-прежнему игнорируют его. Я могу nslookup для любого хоста без указания сервера или FQDN.

C:\bin>nslookup sam
Server:  peanut.internal.local
Address:  192.168.0.29

Name:    sam.internal.local
Address:  192.168.0.3


C:\bin>nslookup peanut
Server:  peanut.internal.local
Address:  192.168.0.29

Name:    peanut
Address:  192.168.0.29

Я могу пинговать Сэма (всегда был здесь с Лео, DC / DNS), но не могу пинговать Арахиса; очевидно ping не находит имена одинаково. Что помогает Сэму и игнорирует Арахис?

C:\bin>ping sam
Pinging sam [192.168.0.3] with 32 bytes of data:
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.0.3:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\bin>ping peanut
Ping request could not find host peanut. Please check the name and try again.

Я мог бы выполнить сценарий входа в AD для репликации \ sys32 \ drivers \ etc \ hosts, но при этом мне все равно пришлось бы вручную обновлять / etc / hosts на нескольких компьютерах Mac и Linux. Правильно выполненные глобальные услуги не требуют ручных повязок SneakerNet - но я понятия не имею, что мне не хватает.

Я буду приветствовать любые идеи по этому поводу; стена болит там, где я бил ее лбом.

обновление: проверьте суффикс поиска домена

Шейн Мэдден и Дерфк должны быть на правильном пути, хотя я не уверен, что мне следует ожидать отсроченных результатов. Я обновил конфигурацию DHCP, указанную ниже, но все еще не вижу ее в моем WinBoxen.

pool 192.168.0.0/24 {
  address-range low 192.168.0.51 high 192.168.0.150;
  name-server {
  192.168.0.29;
  192.168.0.2;
  8.8.8.8;
  8.8.4.4;
  }
  domain-search {
  internal.local;
  }
  wins-server {
  192.168.0.2;
  }

Я ожидал, что это будет отображаться в выводе ipconfig для основного суффикса DNS, но этого не произошло - и пинги по-прежнему не работают. Я буду копать дальше, но я буду рад вмешаться ...

У вас должен быть настроенный суффикс поиска DNS для успешного разрешения коротких имен - это можно сделать либо с помощью параметров DHCP, автоматически настроенных членством в домене Windows, либо вручную настроенных в каждой системе (не рекомендуется).

(Примечание - пожалуйста, не используйте разрешение имен NetBIOS! Оно старое и плохое!)

Список поиска DNS-суффиксов также можно указать в групповой политике Active Directory по адресу:

Компьютер> Шаблоны> Сеть> DNS-клиент> Список поиска DNS-суффиксов

Это было бы особенно полезно для компьютеров, которые не используют DHCP.

Если запись не зарегистрирована в зоне, или если у вас слишком много зон для практического использования списка поиска, использование зоны глобальных имен может быть вариантом.

Развертывание зоны GlobalNames
http://technet.microsoft.com/en-us/library/cc731744.aspx

Это немного предположение, но, глядя на вашу конфигурацию DHCP, я предполагаю, что у вас установлена ​​роль WINS-сервера на вашем DC (выигрывает-сервер {192.168.0.2;}).

Есть ли у «sam» запись в WINS, а у «peanut» - нет? Если это так, я бы предположил, что ваше разрешение коротких имен всегда использовало WINS, а не DHCP.

Вы можете проверить это с помощью инструмента NBLookup от Microsoft (бесплатная загрузка);

http://support2.microsoft.com/default.aspx?scid=kb;en-us;830578

Я настоятельно рекомендую отказаться от WINS, но, надеюсь, это решит вашу краткосрочную проблему.