Перейти к содержимому
Калькуляторы

Странная редкая штука с DNS Кто сталкивался, отзовитесь, плиз.

Ответить

man781   

man781
Опубликовано · Жалоба

Доброго всем времени суток.

Сижу я тихо, никого не трогаю.

Админю )

Все работает. Трафик ходит. Тыщи людей радуются нашему инету.

Но вот изредка меня огорчают некоторые пользователи, которые находят такие сайты, которые у них "не открываются", а у других провайдеров открываются.

 

Итак.

Последний случай.

Сайт www.li.ru.

Проверяю - не резолвится имя.

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

 

Для справки - резолв через гугл паблик днс

dig @8.8.8.8 www.li.ru

; <<>> DiG 9.9.5-3-Ubuntu <<>> @8.8.8.8 www.li.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21468
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.li.ru.                     IN      A

;; ANSWER SECTION:
www.li.ru.              806     IN      A       88.212.196.88
www.li.ru.              806     IN      A       88.212.196.87

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 05 14:07:35 FET 2014
;; MSG SIZE  rcvd: 70

 

Для справки - вот так выглядит запрос на свой днс серв.

 

dig @мой_серв_днс www.li.ru

 

; <<>> DiG 9.9.5-3-Ubuntu <<>> @мой_серв_днс www.li.ru

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59844

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;www.li.ru. IN A

 

;; Query time: 4999 msec

;; SERVER: мой_серв_днс#53(мой_серв_днс)

;; WHEN: Tue Aug 05 13:51:13 FET 2014

;; MSG SIZE rcvd: 27

 

Получаю SERVFAIL

Сервак bind9 на Debian7.

99,9% хостов резолвится без вопросов, но вот попадаются "странные".

 

И самое печальное, что в логах байнда - вообще ПУСТО по поиску www.li.ru

(хотя в других случаях хотя бы был REFUSED)

 

Кто виноват, куда рыть, что клиентам говорить.

Ткните, плиз, мордой )

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

ipaddr.ru   

ipaddr.ru
Опубликовано · Жалоба

Включить крупный подробный дебаг на байнде. Сделать dig +trace. Результаты можно сюда.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

st_re   

st_re
Опубликовано · Жалоба

вообще у них крывенько...

 

dig ns li.ru @a.dns.ripn.net.

;; AUTHORITY SECTION:
li.ru.			345600	IN	NS	ns2.li.ru.
li.ru.			345600	IN	NS	ns.li.ru.

 

На NS и NS2 зона прописана по другому

dig ns li.ru @ns.li.ru.

;; ANSWER SECTION:
li.ru.			900	IN	NS	ns4.li.ru.
li.ru.			900	IN	NS	ns2.li.ru.
li.ru.			900	IN	NS	ns3.li.ru.
li.ru.			900	IN	NS	ns.li.ru.

 

А там все плохо..

на NS3 и 4 зона не прописана

# dig ns li.ru @ns3.li.ru.

;; AUTHORITY SECTION:
ru.			172800	IN	NS	d.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	e.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.



# dig ns li.ru @ns4.li.ru.
ru.			172800	IN	NS	e.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	d.dns.ripn.net.

 

Ваш бинд спросил у 3-4 и обломался. rndc flush и наверное заработает, пока снова не попытается сходить на не удачный NS

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Включить крупный подробный дебаг на байнде. Сделать dig +trace. Результаты можно сюда.

 

Дебаг пока не включал, вот пока трассировка днс запроса

 

dig @мой_серв www.li.ru +trace

; <<>> DiG 9.9.5-3-Ubuntu <<>> @мой_серв www.li.ru +trace
; (1 server found)
;; global options: +cmd
.                       3600000 IN      NS      K.ROOT-SERVERS.NET.
.                       3600000 IN      NS      L.ROOT-SERVERS.NET.
.                       3600000 IN      NS      C.ROOT-SERVERS.NET.
.                       3600000 IN      NS      B.ROOT-SERVERS.NET.
.                       3600000 IN      NS      I.ROOT-SERVERS.NET.
.                       3600000 IN      NS      H.ROOT-SERVERS.NET.
.                       3600000 IN      NS      D.ROOT-SERVERS.NET.
.                       3600000 IN      NS      J.ROOT-SERVERS.NET.
.                       3600000 IN      NS      F.ROOT-SERVERS.NET.
.                       3600000 IN      NS      M.ROOT-SERVERS.NET.
.                       3600000 IN      NS      E.ROOT-SERVERS.NET.
.                       3600000 IN      NS      G.ROOT-SERVERS.NET.
.                       3600000 IN      NS      A.ROOT-SERVERS.NET.
;; Received 239 bytes from мой_серв#53(мой_серв) in 16 ms

ru.                     172800  IN      NS      a.dns.ripn.net.
ru.                     172800  IN      NS      b.dns.ripn.net.
ru.                     172800  IN      NS      d.dns.ripn.net.
ru.                     172800  IN      NS      e.dns.ripn.net.
ru.                     172800  IN      NS      f.dns.ripn.net.
ru.                     86400   IN      DS      51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE
ru.                     86400   IN      RRSIG   DS 8 1 86400 20140812000000 20140804230000 8230 . UeGaRKF+BM5KSYj+Nus8o+CE6vE9DRYeJz5tv1A4LjEhv8Fpev4RYA7M PriNyNQJlcfG2c9dgftLiL0zXMl7Wu1OLZB+83Gikj1p2N7zYH+7gutA CbRZgfmPUH2jxUjBBwFr+Ihcr21MS9lTpKh1oizWC19tZGvKHsEJZcjR lMQ=
;; Received 557 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 36 ms

li.ru.                  345600  IN      NS      ns.li.ru.
li.ru.                  345600  IN      NS      ns2.li.ru.
tdui9d4jkuds8b9t86gj39pgflcnlgm5.ru. 3600 IN NSEC3 1 1 3 00FF TK5F5CCCO39AMJ1KLIC9U1L5NTNNNBIE NS SOA RRSIG DNSKEY NSEC3PARAM
tdui9d4jkuds8b9t86gj39pgflcnlgm5.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140829185822 20140722092008 43590 ru. RJi6PuLXZUgZUV32Ou8M0jl0CAkenJl8242MrpToZzlgpYljKGr5a3x4 iDAzhtxBuEQy3AYL7wCqM6ngy5lgHDtp/PlmG3GHsrf4xaOzJgVBQ0i3 K4YS/s2FbnTG77zRrvfUqgJLUAvnvTWEwSUMxj1xF/k/JbWENF5OEUdH 8es=
7b5guvqhttcfnm68pqo7erle3lg9jpbg.ru. 3600 IN NSEC3 1 1 3 00FF 7MB13U9MUJE7KF370QNQ736NMEHS2AR7 NS DS RRSIG
7b5guvqhttcfnm68pqo7erle3lg9jpbg.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140903052404 20140722092008 43590 ru. VdtUlZn4rGZrk6wxNgRUf6FxCR0JYqBzSD2NQ6T0Ck1SnTjLJKfMvt7D n82hC2WRQikC/mnnsQGMmJipP3n8jNF5wq0YDACksaeW33mU1WTvr1Vt 2Tz6C+ue9cUE2r5JjocYe9D5sZQc3W5KlbGFCqkSSOSabi07omeSE5xn 3Fc=
dig: couldn't get address for 'ns.li.ru': no more

 

а вот трассировка днс запроса на гугл паблик днс

 

dig @8.8.8.8 www.li.ru +trace

; <<>> DiG 9.9.5-3-Ubuntu <<>> @8.8.8.8 www.li.ru +trace
; (1 server found)
;; global options: +cmd
.                       15331   IN      NS      h.root-servers.net.
.                       15331   IN      NS      c.root-servers.net.
.                       15331   IN      NS      a.root-servers.net.
.                       15331   IN      NS      m.root-servers.net.
.                       15331   IN      NS      l.root-servers.net.
.                       15331   IN      NS      k.root-servers.net.
.                       15331   IN      NS      e.root-servers.net.
.                       15331   IN      NS      i.root-servers.net.
.                       15331   IN      NS      f.root-servers.net.
.                       15331   IN      NS      b.root-servers.net.
.                       15331   IN      NS      j.root-servers.net.
.                       15331   IN      NS      g.root-servers.net.
.                       15331   IN      NS      d.root-servers.net.
.                       15331   IN      RRSIG   NS 8 0 518400 20140812000000 20140804230000 8230 . UP0wVkCFEC+cHbELEbOZal742nmggb31zzoJN23dVuaTuY5v+3tl9P4R LLpNuNjap99YHxezuIb8yZKI+Ipgtd27S1b88BpfSrSDacBHpqy80DhP u4SGdKh84b4xawlT8ek7KsSY3e8xa7aI4KrFXdeuzAERaB/cQ5qqZypt 4Lw=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 629 ms

ru.                     172800  IN      NS      f.dns.ripn.net.
ru.                     172800  IN      NS      d.dns.ripn.net.
ru.                     172800  IN      NS      e.dns.ripn.net.
ru.                     172800  IN      NS      a.dns.ripn.net.
ru.                     172800  IN      NS      b.dns.ripn.net.
ru.                     86400   IN      DS      51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE
ru.                     86400   IN      RRSIG   DS 8 1 86400 20140812000000 20140804230000 8230 . UeGaRKF+BM5KSYj+Nus8o+CE6vE9DRYeJz5tv1A4LjEhv8Fpev4RYA7M PriNyNQJlcfG2c9dgftLiL0zXMl7Wu1OLZB+83Gikj1p2N7zYH+7gutA CbRZgfmPUH2jxUjBBwFr+Ihcr21MS9lTpKh1oizWC19tZGvKHsEJZcjR lMQ=
;; Received 557 bytes from 199.7.91.13#53(d.root-servers.net) in 223 ms

li.ru.                  345600  IN      NS      ns.li.ru.
li.ru.                  345600  IN      NS      ns2.li.ru.
TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.ru. 3600 IN NSEC3 1 1 3 00FF TK5F5CCCO39AMJ1KLIC9U1L5NTNNNBIE NS SOA RRSIG DNSKEY NSEC3PARAM
TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140829185822 20140722092008 43590 ru. RJi6PuLXZUgZUV32Ou8M0jl0CAkenJl8242MrpToZzlgpYljKGr5a3x4 iDAzhtxBuEQy3AYL7wCqM6ngy5lgHDtp/PlmG3GHsrf4xaOzJgVBQ0i3 K4YS/s2FbnTG77zRrvfUqgJLUAvnvTWEwSUMxj1xF/k/JbWENF5OEUdH 8es=
7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.ru. 3600 IN NSEC3 1 1 3 00FF 7MB13U9MUJE7KF370QNQ736NMEHS2AR7 NS DS RRSIG
7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.ru. 3600 IN RRSIG NSEC3 8 2 3600 20140903052404 20140722092008 43590 ru. VdtUlZn4rGZrk6wxNgRUf6FxCR0JYqBzSD2NQ6T0Ck1SnTjLJKfMvt7D n82hC2WRQikC/mnnsQGMmJipP3n8jNF5wq0YDACksaeW33mU1WTvr1Vt 2Tz6C+ue9cUE2r5JjocYe9D5sZQc3W5KlbGFCqkSSOSabi07omeSE5xn 3Fc=


dig: couldn't get address for 'ns.li.ru': no more

 

вообще у них крывенько...

 

dig ns li.ru @a.dns.ripn.net.

;; AUTHORITY SECTION:
li.ru.			345600	IN	NS	ns2.li.ru.
li.ru.			345600	IN	NS	ns.li.ru.

 

На NS и NS2 зона прописана по другому

dig ns li.ru @ns.li.ru.

;; ANSWER SECTION:
li.ru.			900	IN	NS	ns4.li.ru.
li.ru.			900	IN	NS	ns2.li.ru.
li.ru.			900	IN	NS	ns3.li.ru.
li.ru.			900	IN	NS	ns.li.ru.

 

А там все плохо..

на NS3 и 4 зона не прописана

# dig ns li.ru @ns3.li.ru.

;; AUTHORITY SECTION:
ru.			172800	IN	NS	d.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	e.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.



# dig ns li.ru @ns4.li.ru.
ru.			172800	IN	NS	e.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	d.dns.ripn.net.

 

Ваш бинд спросил у 3-4 и обломался. rndc flush и наверное заработает, пока снова не попытается сходить на не удачный NS

rndc flush, конечно, пробовал - не помогает. (хотя в других случаях бывало да, помогало на некторое время).

Почему же тот же гугл в итоге все таки отдает запись. Неужели они в кеше храняят последнюю удачную запись?

Я как-то тоже брал и делал для таких вот случаев "временно", чтобы клиенты не сожрали - зону и записи прямо у себя на серве прописывал.

Правда это очень не красивый вариант.

 

Вот думаю написать администрации того ресурса про некорректность их записей.

Но могут и послать, а скорее проигнорят. Ведь у остальных типа работает....

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Так что в итоге посоветуете оптимально в таких случаях?

а) Писать каждый раз таким ресурсам? (геморрой, да и просто проигнорят в 0,9 случаях )

б) Что говорить клиентам? Они то видят, что у других провайдеров работает - значит наш сервис (ISP) "плохой".

в) Что-то еще сделать, чтобы у меня тоже работало ?

г) Почему у других провайдеров данный ресурс работает?! :)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

g3fox   

g3fox
Опубликовано · Жалоба

Как костыльный но рабочий вариант можете завести себе эту зону с типом forward и как forwarders указать "рабочие" NS-серверы.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

No_name   

No_name
Опубликовано · Жалоба

2 man781

Да, тоже бывали такие ситуации, редко, но бывали.

Помогало кратковременное включение форвардинга на гугловский днс.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

st_re   

st_re
Опубликовано · Жалоба

Посмотрел по логам. Мои на li.ru ходят. Ошибок ресолва нет. unbound. на тестовом бинде первые полсотни запросов разным *.li.ru без ошибок. бинд правда 9.9.3-P1 и люди у него не спрашивают, только роботы. Я бы снял трафик к ns*.li.ru тисипидампом и сделал параллельно rbdc flush и посмотрел че там спрашивается и че отвечается. что то кеш отравляет.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Ivan_83   

Ivan_83
Опубликовано · Жалоба

Мой ну очень тупой резолвер.

 

 

REQUESTING DNS record for www.li.ru

Results: founded: 18 records, request time: 0
DNS head:  Size	=557
	ID	=29218
	Flags	=[QR=1, OPCODE=0, AA=0, TC=0, RD=0, RA=0, Z=0, AD=0, CD=0, RCODE=0]
	QDCount=1
	ANCount=0
	NSCount=7
	ARCount=11
Win32 DNS error 0: Операция успешно завершена.


Server: RU, Type=2 (NS), Class=1, TTL=172800, server: A.DNS.RIPN.NET
Server: RU, Type=2 (NS), Class=1, TTL=172800, server: B.DNS.RIPN.NET
Server: RU, Type=2 (NS), Class=1, TTL=172800, server: D.DNS.RIPN.NET
Server: RU, Type=2 (NS), Class=1, TTL=172800, server: E.DNS.RIPN.NET
Server: RU, Type=2 (NS), Class=1, TTL=172800, server: F.DNS.RIPN.NET
Server: RU, Type=43 (DS), Class=1, TTL=86400
Server: RU, Type=46 (RRSIG), Class=1, TTL=86400
Server: A.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 193.232.128.6
Server: B.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 194.85.252.62
Server: D.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 194.190.124.17
Server: E.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 193.232.142.17
Server: F.DNS.RIPN.NET, Type=1 (A), Class=1, TTL=172800, address: 193.232.156.17
Server: A.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.17.0.193.232.128.6
Server: B.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.16.0.194.85.252.62
Server: D.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.18.0.194.190.124.17
Server: E.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.15.0.193.232.142.17
Server: F.DNS.RIPN.NET, Type=28 (AAAA), Class=1, TTL=172800, address: 2001.678.14.0.193.232.156.17
OPT_RR: UDPPayloadSize=1472, Flags= [DO=0], Version=192, ExRCode=5, RRDataSize=0

Results: founded: 9 records, request time: 0
DNS head:  Size	=592
	ID	=29296
	Flags	=[QR=1, OPCODE=0, AA=0, TC=0, RD=0, RA=0, Z=0, AD=0, CD=0, RCODE=0]
	QDCount=1
	ANCount=0
	NSCount=6
	ARCount=3
Win32 DNS error 0: Операция успешно завершена.


Server: LI.RU, Type=2 (NS), Class=1, TTL=345600, server: NS2.LI.RU
Server: LI.RU, Type=2 (NS), Class=1, TTL=345600, server: NS.LI.RU
Server: TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.RU, Type=50 (NSEC3), Class=1, TTL=3600
Server: TDUI9D4JKUDS8B9T86GJ39PGFLCNLGM5.RU, Type=46 (RRSIG), Class=1, TTL=3600
Server: 7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.RU, Type=50 (NSEC3), Class=1, TTL=3600
Server: 7B5GUVQHTTCFNM68PQO7ERLE3LG9JPBG.RU, Type=46 (RRSIG), Class=1, TTL=3600
Server: NS.LI.RU, Type=1 (A), Class=1, TTL=345600, address: 88.212.202.56
Server: NS2.LI.RU, Type=1 (A), Class=1, TTL=345600, address: 88.212.196.87
OPT_RR: UDPPayloadSize=4096, Flags= [DO=0], Version=0, ExRCode=16, RRDataSize=0

REQUEST COMPLETE, FOUND, results: hops: 3, total time: 62
DNS head:  Size	=70
	ID	=29297
	Flags	=[QR=1, OPCODE=0, AA=1, TC=0, RD=0, RA=0, Z=0, AD=0, CD=0, RCODE=0]
	QDCount=1
	ANCount=2
	NSCount=0
	ARCount=1
Win32 DNS error 0: Операция успешно завершена.


Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.87
Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.88
OPT_RR: UDPPayloadSize=4096, Flags= [DO=0], Version=0, ExRCode=16, RRDataSize=0
==================================================================================

REQUEST COMPLETE, FOUND, results: hops: 3, total time: 62
Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.87
Server: WWW.LI.RU, Type=1 (A), Class=1, TTL=900, address: 88.212.196.88
==================================================================================
DONE

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

2 man781

Да, тоже бывали такие ситуации, редко, но бывали.

Помогало кратковременное включение форвардинга на гугловский днс.

Действительно помогло

 

Как костыльный но рабочий вариант можете завести себе эту зону с типом forward и как forwarders указать "рабочие" NS-серверы.

Да - такой вариант оставлял на крайний случай, тем более и раньше его успешно использовал

Но не понадобилось - я написал письмо администрации ресурса. Они подправили у себя.

Теперь у меня все резолвится корректно.

Всем спасибо за отклик.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Еще тогда по теме dns два вопросика

 

1) Кто использует у себя на площадке решение от skydns (типа родительский контроль, автообновление базы категорий, интеграция с биллингом)?

Мы вот давно юзаем. Все работает. Юзеры сами себе в кабинете выбирают белые/черные списки, категории.

 

Возник вопрос - на данный момент схема работает только с одним DNS сервером.

Вот по такой инструкции http://www.lanbilling.ru/sky_dns - юзеры шлют запросы, слушает их скайднс прокси на IP адресе физического фейса, "фильтрует" и резолвит запрос через 127.0.0.1, где уже bind слушает)

Хотелось бы узнать - кто-нить делал все тоже самое (имею ввиду решение скай днс прокси) но с использованием двух серверов (для горячего резерва)?

 

2) Насколько критично, когда я своим юзерам передаю (with DHCP) всего один DNS сервер?

Ходят байки, что какие-то девайсы неадекватно работают, когда нет секондари днс (типа = 0.0.0.0)

Либо вообще не работают, пока руками не впишешь, и люди всякую хрень туда вбивают.

 

3) Насколько важно для каких-либо служб/сервисов, чтобы корректно резолвился IP адрес фейса в имя, (имеется ввиду IP адрес - на котором висит мой днс сервер (ессно - сервак имеет белый адрес и держит реальную зону (не локальный фейк)).

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

 

Заранее благодарен за ответы.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

ayf   

ayf
Опубликовано · Жалоба

Еще тогда по теме dns два вопросика

 

1) Кто использует у себя на площадке решение от skydns (типа родительский контроль, автообновление базы категорий, интеграция с биллингом)?

Мы вот давно юзаем. Все работает. Юзеры сами себе в кабинете выбирают белые/черные списки, категории.

 

Возник вопрос - на данный момент схема работает только с одним DNS сервером.

Вот по такой инструкции http://www.lanbilling.ru/sky_dns - юзеры шлют запросы, слушает их скайднс прокси на IP адресе физического фейса, "фильтрует" и резолвит запрос через 127.0.0.1, где уже bind слушает)

Хотелось бы узнать - кто-нить делал все тоже самое (имею ввиду решение скай днс прокси) но с использованием двух серверов (для горячего резерва)?

 

2) Насколько критично, когда я своим юзерам передаю (with DHCP) всего один DNS сервер?

Ходят байки, что какие-то девайсы неадекватно работают, когда нет секондари днс (типа = 0.0.0.0)

Либо вообще не работают, пока руками не впишешь, и люди всякую хрень туда вбивают.

 

3) Насколько важно для каких-либо служб/сервисов, чтобы корректно резолвился IP адрес фейса в имя, (имеется ввиду IP адрес - на котором висит мой днс сервер (ессно - сервак имеет белый адрес и держит реальную зону (не локальный фейк)).

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

 

Заранее благодарен за ответы.

 

Некритично. Если бы проблема была, вас бы уже нашли. Никто не мешает клиенту адрес получать по DHCP, а DNS прописать руками. Если, конечно, вы все запросы на 53 порт не редиректите на свой днс.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

спасибо за ответы

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Заметил, если пропадает инет - то если глянуть rndc status на моем DNS сервере (bind9) - к-во запросов в секунду взлетает под плеху (т.е. сколько в конфиге разрешено, столько и фигачит).

recursive clients: 1000/0/1000

Хотя обычно не более 200 в сек.

Такое ощущение, что возникает рекурсия к самому себе.

Кто-нить знает, в чем фишка?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

GrandPr1de   

GrandPr1de
Опубликовано · Жалоба

Поидее в таймаутах.

Когда ответы клиентам нормально отдаются - то и нагрузка идет средняя, а когда запросы всё идут, а ответов нету.

У меня анбаунд тоже с ума сходит если есть прерывание инета. Готов весь проц сожрать в тот момент.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Вполне логичное объяснение.

Спасибо.

 

Вот подкрутил для прикола в конфиге байнда вместо 1000 - 20000 максимально разрешенных рекурсивных запросов в секунду изнутри своей сети.

Сэмулировал "отключение Инета" - моментально в 20000 уперлось.

 

Просто суть такая, что когда связь с "вышестоящими" днс серверами поршивая - эта хрень мгновенно подскакивает, а отпускает медленней.

Вроде даже один раз пришлось руками перезапустить - чтобы из клинча вывести...

 

А кто в курсе - можно ли в качестве forwarders прописать гуглосервера 8.8.8.8 и 8.8.4.4 с средней нагрузкой в 200 запросов в секунду от моего днс сервера (нерекурсивные запросы)?

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

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

GrandPr1de   

GrandPr1de
Опубликовано · Жалоба

Да можно и на руках ходить.

можно ли в качестве forwarders прописать гуглосервера 8.8.8.8 и 8.8.4.4

Да только смысл? Выдайте сразу клиентским компам гуглоднсы.

Просто делать рекурсию на рекурсивный днс, это как нат за натом. Сделать можно - смысла\толку мало.

Мой анбаунд общаеться с корневыми и бед я не знаю.

Зачем вам бинд, кстати говоря? Он у вас домен обслуживает?

Я лично с бинда ушел на анбаунд ибо начались таймауты с ответами, анбаунд у меня таким не балуеться. :)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Байнд мне нужен, потому что я зону свою держу. Это раз.

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

(имя днс одно - тазиков VPN много).

И еще не могу отдать юзерам сразу гуглоднс - потому что юзаю днс фильтрацию (услуга типа родительский контроль).

Вообще, я пробовал в свое время unbound - очень понравился (конфигурирование).

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

Это плохо для распределения нагрузки впн серверов - клиент всегда использовал первый адрес в списке.

 

P.S. Понятно, что нужно уходит от тазиков с VPN - на IPoE BRAS.

 

ну так все таки - кто-нить прописывал в качестве forwarders 8.8.8.8 и 8.8.4.4 ?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

GrandPr1de   

GrandPr1de
Опубликовано · Жалоба

Да я пробовал так делать, работает.

Если вы уже уверелись, что хотите так сделать - то работать будет.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Я тоже пробовал. Не долго. Работает.

Но может если на постоянку врубить - через какое-то время начнут дропать? (через неделю, месяц)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

Значит совпало - пару недель поработало, потом "что-то пошло не так", некогда было разбираться - убрал forwarders, снова корневые днс серверы юзаются.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Ivan_83   

Ivan_83
Опубликовано · Жалоба

Им не выгодно дропать.

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

 

Поэтому плох тот провайдер, который не держит собственный рекурсивный днс с кешем а сливает всё левым конторам.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

man781   

man781
Опубликовано · Жалоба

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

решил таки я уйти от bind9 на unbound.

 

На unbound внезапно нормально резолвится проблемный сайтик.

 

Но вот столкнулся я с тем, что в unbound не работает запись для retracker.local в частности

и вообще CNAME запись из "чужого" домена.

Как я не крутил варианты полдня.

 

Может кто показать кусок примера конфига unbound для вышеописанных случаев?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
Подписчики 0
Перейти к списку тем Программное обеспечение, биллинг и *unix системы