Форум русскоязычного сообщества Ubuntu


Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!

Автор Тема: Ubuntu Server 12.04.1 LTS Не работает резолвинг хостов.  (Прочитано 4604 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн mindcube

  • Автор темы
  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
дали такой сервер:
Intel Xeon, Ubuntu Server 12.04.1 LTS, одна сетевая карта (один статический IP-адрес, смотрит в инет и локалку).
стоит вебсервер, мускул, exim (перенаправляет почту на внешний яндекс), bind9 (кэширующий DNS для локалки).

Проблема вот в чем:

av@server1:~$ nslookup yandex.ru
;; connection timed out; no servers could be reached
av@server1:~$ wget ya.ru
--2012-11-06 16:45:24--  http://ya.ru/
Resolving ya.ru (ya.ru)... ^C

ни одна программа для которой требуется резолвинг хостов попросту не работает.
работа почты(exim) стоит. wget и прочие тоже не резолвят.

напрямую по IP все работает!
av@server1:~$ curl -I http://213.180.204.11/
HTTP/1.1 302 Found
Date: Tue, 06 Nov 2012 06:55:28 GMT
Location: http://www.yandex.ru/
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked

53-порт (dns)
тоже работает:
av@server1:~$ telnet 8.8.8.8 53
Trying 8.8.8.8...
Connected to 8.8.8.8.
Escape character is '^]'.

av@server1:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=43 time=268 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=43 time=277 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=43 time=271 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=43 time=270 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 268.239/271.905/277.273/3.348 ms


настройки:
root@server1:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 80.73.64.251
nameserver 8.8.8.8
search ru
80.73.64.251 это днс провайдера


root@server1:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth1
iface eth1 inet static
        address 46.48.*******
        netmask 255.255.255.0
        network 46.48.*******
        broadcast 46.48.140.255
        gateway 46.48.*******
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 80.73.64.251 8.8.8.8
        dns-search ru

sudo dpkg-reconfigure resolvconf
не помогло.

и днсы менял на другие, и сервер перезагружал - бестолку. резолва нет.
подскажите, куда еще копать?

Оффлайн ArcFi

  • Старожил
  • *
  • Сообщений: 15189
    • Просмотр профиля
    • aetera.net
1.
nslookup ya.ru 8.8.8.8
cat /etc/nsswitch.conf
?

2.
        dns-search ru
Это точно нужно?

3. В /etc/resolv.conf руками не лазали?

Оффлайн mindcube

  • Автор темы
  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
1. этот файл не трогал.
root@server1:~# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

2. он и не мешает вроде) я даже убирал dns-search ru - тоже безрезультатно.
3. да, сначала правил руками. после перезагрузки старые значения появлялись обратно.
я тогда не знал что есть пакет resolvconf который парсит /etc/network/interfaces на dns-nameservers :)



Пользователь решил продолжить мысль 06 Ноября 2012, 12:44:59:
а вот, похоже что проблема в провайдере, режут UDP-пакеты?
root@server1:~# dig @8.8.8.8 ya.ru

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 ya.ru
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
« Последнее редактирование: 06 Ноября 2012, 12:44:59 от mindcube »

Оффлайн ArcFi

  • Старожил
  • *
  • Сообщений: 15189
    • Просмотр профиля
    • aetera.net
режут UDP-пакеты?
sudo iptables-save
dig @8.8.8.8 ya.ru +tcp
dig @8.8.8.8 ya.ru +notcp
В общем, направление понятно. =]

Оффлайн mindcube

  • Автор темы
  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
sudo iptables-save
ответ пустой. оно и видно, фаервол не настраивали) похоже дело в провайдере.

sudo iptables-save
dig @8.8.8.8 ya.ru +tcp
dig @8.8.8.8 ya.ru +notcp

root@server1:~# dig @8.8.8.8 ya.ru +tcp

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 ya.ru +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16819
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  1558    IN      A       87.250.251.3
ya.ru.                  1558    IN      A       93.158.134.3
ya.ru.                  1558    IN      A       93.158.134.203
ya.ru.                  1558    IN      A       213.180.193.3
ya.ru.                  1558    IN      A       213.180.204.3
ya.ru.                  1558    IN      A       77.88.21.3
ya.ru.                  1558    IN      A       87.250.250.3
ya.ru.                  1558    IN      A       87.250.250.203

;; Query time: 241 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Nov  6 19:07:43 2012
;; MSG SIZE  rcvd: 151
ура! есть ответ)




root@server1:~# dig @8.8.8.8 ya.ru +notcp

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 ya.ru +notcp
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
нет ответа. значит 53 порт UPD блокируют.

а можно ли настроить локальный bind9 чтобы по умолчанию запрашивал по TCP 53?
по гуглу советуют поставить pdnsd.

Пользователь решил продолжить мысль 06 Ноября 2012, 13:14:53:
pdnsd кажется то что доктор прописал) сейчас попробуем его поставить вместо bind9

Пользователь решил продолжить мысль 06 Ноября 2012, 14:21:08:
облом)
root@server1:~# dig @127.0.0.1 ya.ru +notcp

; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 ya.ru +notcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7172
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov  6 20:11:41 2012
;; MSG SIZE  rcvd: 23
похоже бинарный пакет pdnsd собран без поддержки TCP QUERY (пытался настроить с гуглом 8.8.8.8 по TCP). попробую пересобрать из apt-sources. вдруг что-нибудь получится - но это уже другая история.

резюмируя тему - проблема была не в самой системе, во всем виноват провайдер :)
тему можно закрыть.

arcfi, больше спасибо за помощь.
« Последнее редактирование: 06 Ноября 2012, 14:21:08 от mindcube »

Оффлайн mindcube

  • Автор темы
  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
продолжение темы:
после долгих поисков DNS-серверов с поддержкой TCP Query, остановился на следующем варианте:

это замечательный python-скрипт Tcp-DNS-proxy.
забирать тут: https://github.com/henices/Tcp-DNS-proxy

делает следующее:
слушает на локалхосте 53 UDP-порт, все запросы перенаправляет на внешние сервера dns, которые поддерживают запросы по TCP (в скрипте уже есть готовый список 8.8.8.8, 8.8.4.4 и др., можно прописать свои сервера), ответ возвращает клиенту.

пример работы:
root@server1:~# sudo python tcpdns.py
>> Please wait program init....
>> Init finished!
>> Now you can set dns server to 127.0.0.1
domain:yandex.ru, qtype:1, thread:1

в это время на другой консоли запускаем
av@server1:~$ nslookup yandex.ru 127.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   yandex.ru
Address: 213.180.204.11
Name:   yandex.ru
Address: 77.88.21.11
Name:   yandex.ru
Address: 87.250.250.11
Name:   yandex.ru
Address: 93.158.134.11
Name:   yandex.ru
Address: 213.180.193.11
работает!

т.к. скрипт не кэширует запросы, само собой возникло желание поставить шокирующийкэширующий DNS-сервер BIND9.
чтобы не было конфликтов с bind9 на локалхосте, правим скрипт tcpdns.py
находим
    server = ThreadedUDPServer(('127.0.0.1', 53), ThreadedUDPRequestHandler)меняем порт 53 на 5300
    server = ThreadedUDPServer(('127.0.0.1', 5300), ThreadedUDPRequestHandler)сохраняем. идем дальше.

правим конфиг /etc/bind/named.conf.options
root@server1:~# cat /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";
        forwarders {127.0.0.1 port 5300;};
        forward first;
        dnssec-validation auto;
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };
};

для автоматизации, запускаем скрипт через кронтаб:
root@server1:~# crontab -l
@reboot python /root/tcpdns.py | tee -a /var/log/tcpdns.log > /dev/null 2>&1 (не забывайте оставить пробел или перевод на новую строку)

/var/log/tcpdns.log для просмотра работы скрипта.


теперь настраиваем /etc/network/interfaces
dns-nameservers указать 127.0.0.1.

root@server1:~# cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth1
iface eth1 inet static
        address 46.48.***.***
        netmask 255.255.255.0
        network 46.48.*.0
        broadcast 46.48.*.*
        gateway 46.48.*.*
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 127.0.0.1
        dns-search ****.ru

при перезагрузке обновится файл /etc/resolv.conf и там должны стоять адреса указанные в dns-nameservers.
root@server1:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search ****.ru
если этого не произошло, настройте resolv.conf вручную.


получается простейшая схема:
bind9: если такой-то запрос уже запрашивался и есть в кэше, выдаем ответ клиенту.
если запрос новый, запрашиваем 127.0.0.1:5300 и кэшируем ответ, выдаем ответ клиенту.

из минусов:
такой механизм работает немного медленнее чем обычный UDP Query.
скрипт не проверялся на переполнение буфера или еще чего)

ЗЫ: скорее данная статья заметка для себя, но буду рад если кому-то помогло ;)

Оффлайн ArcFi

  • Старожил
  • *
  • Сообщений: 15189
    • Просмотр профиля
    • aetera.net
Проверьте ещё NTP (123/udp):
(Нажмите, чтобы показать/скрыть)

Хотя, по-любому, провайдеру можно и нужно высказать обоснованные претензии.

Оффлайн mindcube

  • Автор темы
  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
что интересно, время пашет :) походу только днс зафильтровали.
(Нажмите, чтобы показать/скрыть)

Оффлайн intervision

  • Активист
  • *
  • Сообщений: 312
  • Только тяжелая музыка
    • Просмотр профиля
    • Сумеречное Радио
Сорри за оффтоп, но зафильтровали ИМХО не зря - с 1го числа закон вышел о блэклистах сайтов, а провайдер может фильтровать сайты на своих провайдерских ДНС. и чтобы умники не убегали с провайдерских ДНС и не видели зацензуренные сайтеги - резут UDP на 53м порту ко всему, что не в зоне провайдера... о как...

Всем китайский фаерволл и цензуросайты...

Оффлайн mindcube

  • Автор темы
  • Новичок
  • *
  • Сообщений: 7
    • Просмотр профиля
нашел еще такое:

http://dnscrypt.org/

Цитировать
DNSCrypt proxy can force outgoing queries to be sent over TCP

кажется это наиболее идеальный вариант :)

 

Страница сгенерирована за 0.021 секунд. Запросов: 21.