LINUX.ORG.RU

резолв адресов в браузере

 , , resolve.conf


1

2

Здравствуйте. Почему то стали долго резолвиться адреса в браузере (порой по 30 сек) использую chromium-browser. Интересно, что при пинге, например:

stas@debian:~$ ping linux.org.ru
PING linux.org.ru (217.76.32.61) 56(84) bytes of data.
64 bytes from linux.org.ru (217.76.32.61): icmp_req=1 ttl=53 time=76.3 ms
^C
--- linux.org.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 76.382/76.382/76.382/0.000 ms
все резолвиться моментально. мой /etc/resolv.conf:
# Generated by NetworkManager
nameserver 192.168.1.4
nameserver 8.8.8.8
nameserver 8.8.4.4

В чем могут быть проблемы?

★★★

Последнее исправление: cetjs2 (всего исправлений: 2)
Ответ на: комментарий от cadaber

МесьЁ, 196.168... не может быть роутером, который подхватывает вышестоящий днс?

anonymous
()
Ответ на: комментарий от SergMarkov

dnsmasq - не поддающееся контролю кривое поделие с лишним в данном случае функционалом. Нафига все советуют его ставить, я не понимаю, ведь есть же гораздо более вменяемый pdnsd

nu11 ★★★★★
()
Ответ на: комментарий от cadaber

192.168.1.4 это сервер с настроенным bind9:


root@SunFire:/etc/bind# cat named.conf.options 
options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable 
        // nameservers, you probably want to use them as forwarders.  
        // Uncomment the following block, and insert the addresses replacing 
        // the all-0's placeholder.

        forwarders {
                #192.168.1.1;
                8.8.8.8;
                8.8.4.4;
        };
        listen-on {
                192.168.1.4;
                127.0.0.1;
        };
        auth-nxdomain no;    # conform to RFC1035
        #listen-on-v6 { any; };
};

На домашнем компе:



root@debian:/home/stas# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
/code]

disee ★★★
() автор топика
Ответ на: комментарий от SergMarkov

«Оно работает»

да вот кривенько оно работает, кеширует рандомно и может забывать через минуту.

А кривизна как всегда она в руках :-)

эти самые руки настраивали pdnsd и там все работает как часы. А вот как раз к dnsmasq руки не притрагивались, ибо настроек там нифига нет, и работает оно из коробки в зависимости от погоды на Марсе.

nu11 ★★★★★
()

# Generated by NetworkManager

какое подключение у тебя? Откуда этот самый манагер получает адреса dns?
Фишка может быть в том, что при старте хромого resolv.conf был другим.

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

nu11 ★★★★★
()
Ответ на: комментарий от nu11

NetworkManager получает настройки от dhcp сервера, которые выглядят вот так:

stas@SunFire:~$ cat /etc/dhcp/dhcpd.conf
subnet 192.168.1.0  netmask 255.255.255.0 {
  range 192.168.1.10 192.168.1.50;
 
  option routers 192.168.1.1;
  option ntp-servers 192.168.1.4;
  option domain-name-servers 192.168.1.4, 8.8.8.8, 8.8.4.4; 
# option netbios-name-servers 192.168.1.4;
# option domain-name "fire";

host debian {
  hardware ethernet 40:xx:xx:xx:xx:54;
  fixed-address 192.168.1.2;
}
....
}
Насколько я понимаю лог действий примерно такой: 1) комп загрузился 2) получили от dhcp правильный резолв 3) когда понадобилось запустил chromium . ТАк что в принципе такой ошибки быть не должно

выхлоп от dig:

stas@debian:~$ dig dell.com

; <<>> DiG 9.7.3 <<>> dell.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5428
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dell.com.                      IN      A

;; ANSWER SECTION:
dell.com.               420     IN      A       143.166.224.244
dell.com.               420     IN      A       143.166.83.38

;; Query time: 58 msec
;; SERVER: 192.168.1.4#53(192.168.1.4)
;; WHEN: Sun Jun 10 18:30:34 2012
;; MSG SIZE  rcvd: 58


disee ★★★
() автор топика
Ответ на: комментарий от disee

так что с другими браузерами? Те же проблемы? Пока могу посоветовать тяжелую артиллерию в виде wireshark

nu11 ★★★★★
()
Ответ на: комментарий от nu11

Кстати dnsmasq по умолчанию кэширует только 150 записей, может это и есть твое «не все кеширует» ? Так оно правится в конфиге :-)

SergMarkov
()
Ответ на: комментарий от SergMarkov

Так оно правится в конфиге :-)

это единственное, что там настраивается. Нет, дело не в размере кеша.

nu11 ★★★★★
()
Ответ на: комментарий от nu11

Да там конфиг в полкилометра :-) Единственное «но» - не сохраняет при перезагрузке, но это как то пофиг при аптайме месяцами. А pdnsd спотыкается на ровном месте, в чем там дело непонятно

SergMarkov
()
Ответ на: комментарий от SergMarkov

Да там конфиг в полкилометра :-)

вот и посчитай в нем количество параметров, относящихся к кешу днс ;)

nu11 ★★★★★
()
Ответ на: комментарий от SergMarkov

попоробовал и снес нахрен, какие то совершенно непонятные затыки

кто-то говорил про кривые руки? :)

nu11 ★★★★★
()
Ответ на: комментарий от SergMarkov

вот как раз в pdnsd лучше руками конфиг сделать, благо там куча опций на любой вкус

nu11 ★★★★★
()

проблема решена. Дело в том, что я настраивал домен, и поэтому редактировал nsswitch.conf, а конкретнее строку hosts, после редактирования она у меня стала выглядить вот так:

hosts:          files wins mdns4_minimal [NOTFOUND=return] dns mdns4
из за местоположения «wins» в этой строке у меня и возникала проблема сделал вот так:
hosts:          files mdns4_minimal [NOTFOUND=return] dns wins mdns4
все заработало отлично

disee ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.