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

«Dig + trace fqdn» и «dig fqdn» не дают такого же результата в локальной сети с DNS-сервером Windows, почему?

в локальной сети моей компании у меня есть Сервер Ubuntu 14.04 работает в Virtualbox (в качестве гостя) на Windows 7 (хост) с сетевым интерфейсом мостовой (так что сервер Ubuntu принадлежит локальной сети, с его ip: 192.168.1.85). У меня есть сайт на этом сервере: mywebsite.com

Шлюз для локальной сети в Интернет 192.168.1.1 (Cisco 1841)->188.188.188.254 как публичный IP.

Есть сервер Windows 2008, который действует как DNS сервер и DHCP сервер в локальной сети. Я добавил зону пересылки "mywebsite.com" с Рекорд -> 192.168.1.85.

Вне локальной сети, mywebsite.com имеет общедоступные записи DNS, указывающие на общедоступный IP-адрес Cisco 1841 (188.188.188.254)

Теперь, когда я пингую mywebsite.com из локальной сети, Я быстро получаю 192.168.1.85.

Но когда я подключаюсь через браузер к клиентам, это не всегда быстро. Так что мне интересно:

Действительно ли мои просьбы /решено напрямую и отправлено 192.168.1.85, ИЛИ они отправлены вне локальной сети, а затем перенаправляется обратно в общедоступный CISCO 188.188.188.254:80 и NAT на сервер Ubuntu перед обслуживанием ???

Чтобы попытаться ответить на этот вопрос, я искал отслеживание DNS-запроса от моего Linux-клиента в локальной сети:

v@v-ss9:~$ dig mywebsite.com
; <<>> DiG 9.9.5-3-Ubuntu <<>> mywebsite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24850
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mywebsite.com.     IN  A

;; ANSWER SECTION:
mywebsite.com.  3600    IN  A   192.168.1.85

;; Query time: 1 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Aug 22 09:50:16 CST 2014
;; MSG SIZE  rcvd: 66

Этот ответ выглядит правильным: 192.168.1.85. Но тогда посмотрите на это:

v@v-ss9:~$ dig +trace mywebsite.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace mywebsite.com
;; global options: +cmd
.           12955   IN  NS  h.gtld-servers.net.
.           12955   IN  NS  g.gtld-servers.net.
.           12955   IN  NS  m.gtld-servers.net.
.           12955   IN  NS  i.gtld-servers.net.
.           12955   IN  NS  l.gtld-servers.net.
.           12955   IN  NS  k.gtld-servers.net.
.           12955   IN  NS  j.gtld-servers.net.
.           12955   IN  NS  d.gtld-servers.net.
.           12955   IN  NS  b.gtld-servers.net.
.           12955   IN  NS  c.gtld-servers.net.
.           12955   IN  NS  a.gtld-servers.net.
.           12955   IN  NS  e.gtld-servers.net.
.           12955   IN  NS  f.gtld-servers.net.
;; Received 516 bytes from 127.0.1.1#53(127.0.1.1) in 18 ms

mywebsite.com.  172800  IN  NS  ns3.rmi.fr.
mywebsite.com.  172800  IN  NS  ns4.rmi.fr.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20140825045016 20140818034016 6122 com. Imq8K9xlvFXlB4IjUkdxOc5YHoTEhqSQUlRSJ9QCIhd9wzGpWJ54AfVf WJ0SUKThalpzqS0cXdLGtNmuYgqLfwUMjpUlT4c+zJyx7I4QMPLImQZh Ov0xy3mUr7dLlymAJYGs9dLI2IaheLvpKTBwaV1gAvo8QEkU8VRiJ7gW 9dk=
U0PIA23FHMVPTKSDHC9PJ1BEA9SIB65R.com. 86400 IN NSEC3 1 1 0 - U0PL33R61V6TCCPBS1171PROP57ASRD9 NS DS RRSIG
U0PIA23FHMVPTKSDHC9PJ1BEA9SIB65R.com. 86400 IN RRSIG NSEC3 8 2 86400 20140825043502 20140818032502 6122 com. qsC5sJbwklao+OedCHpcYo56aQaY0N+7peKmPu8szvjAQoJFRWyuDfAh Nw/gvHXEMzG7tYLriQGVfsiK8GZdPXyG4Ghe1MNN4jOZnSahkT5LjlqL 5QyGC0QiClRMPDAYjUOFGQDkjOJcJYvTNkEyXC2BEpfLI5SwCbYqwqg3 RkE=
;; Received 585 bytes from 192.41.162.30#53(l.gtld-servers.net) in 297 ms

mywebsite.com. 86400 IN A   188.188.188.254
mywebsite.com.  86400   IN  NS  ns3.rmi.fr.
mywebsite.com.  86400   IN  NS  ns4.rmi.fr.
;; Received 204 bytes from 212.51.161.18#53(ns3.rmi.fr) in 310 ms

Здесь я получаю свой публичный IP CISCO 188.188.188.254!!!

  1. Это нормально?
  2. Как узнать, действительно ли мой браузер (из локальной сети) напрямую взаимодействует с 192.168.1.85 при использовании mywebsite.com?

Спасибо за помощь.

Это нормально? ДА!

dig + trace рекурсивно разрешает домен. он начинается с запроса корневых серверов и так далее. Так же, как любой резолвер по умолчанию,

Поскольку сайт размещен в вашей локальной сети, вы можете пропустить рекурсию и обслуживать зону непосредственно с DNS-сервера вашей локальной сети, что вы и делаете. Кроме того, вы можете указать локальный IP-адрес (который не будет работать в общедоступном Интернете) - что вы и делаете. Когда вы запрашиваете домен только dig DNS-сервер вашей локальной сети запрашивается напрямую - отсюда и локальный IP-адрес в ответе.

С другой стороны, dig +trace игнорирует ваш преобразователь по умолчанию. Вместо этого dig действует как собственный преобразователь и имитирует то, что сделал бы преобразователь в Интернете. Поскольку локальный IP-адрес будет недоступен из внешнего мира, вы необходимость публичный IP-адрес, который будет возвращен в качестве ответа. И это именно то, что вы видите ...

Ваш браузер в локальной сети достигает веб-сайта с помощью локального IP-адреса? НАВЕРНОЕ! dig возвращает локальный IP. Это указывает на то, что ваш DNS-сервер фактически возвращает локальный IP-адрес клиентам LAN, и что ваш компьютер фактически настроен на использование DNS-сервера LAN. Так что, если не произойдет чего-то странного, да.

Как ты можешь быть уверен? Журналы сервера - ваш друг.

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

С другой стороны, если исходный IP-адрес соответствует локальному IP-адресу вашего браузера, да, используется локальный IP-адрес.

Как можно быть действительно уверенным?

Wireshark. Сделайте захват пакета во время просмотра. Посмотрите, какой трафик куда идет.