Jump to content
  • 0

Бавно отваряне на страници,проблем с DNS


angelnet

Въпрос

Здравейте имам следния проблем от 2 дни.Имам микротик рутер който дава реални айпи адреси нямам DHCP Server айпитата на клиентите са статични интернета го получавам през VLAN на клиентите давам айпита 46.55.161..... а DNS-a е 46.55.161.1 гейта е същия като DNS-са за 2 години нямах никакви проблеми до вчера някой страници ги отваря а други не,някои нормално други за по 10-15 секунди установих,че като си сложа вместо моя DNS 46.55.161.1,DNS-а на достачвика ми 46.55.162.1 няма проблем,обаче в същата мрежа имам 3 компютъра с кракнат Микротик 5.20 които правят НАТ като сложа  DNS 46.55.162.1 пак някои ги отваря бавно а други не ми ги отваря.....МОЛЯ ЗА ПОМОЩ!!!0898242357 или тук

Адрес на коментара
Сподели в други сайтове

Recommended Posts

  • 0

аз днс кеш на мой рутер не съм виждал пълен дори и с по 300 дни ъптайм и бая други рутери да правят запитване към него. 

Теория - това е когато знаете всичко, но нищо не работи

Практика - това е когато всичко работи, но не знаете защо

При нас съчетаваме теорията с практиката - НИЩО не работи и нямаме понятие защо!!!

Адрес на коментара
Сподели в други сайтове

  • 0

:) 300 дни пратете снимка да го видя ::)  явно микротик са искарали перфекната версия ???

 

я прегледайте дази тема и ми говори за препълване  

Редактирано от net-sar
Адрес на коментара
Сподели в други сайтове

  • 0

ето разгледай 

Теория - това е когато знаете всичко, но нищо не работи

Практика - това е когато всичко работи, но не знаете защо

При нас съчетаваме теорията с практиката - НИЩО не работи и нямаме понятие защо!!!

Адрес на коментара
Сподели в други сайтове

  • 0
  • Администратор

Без отметката Allow Remote Requests, днс услугата се ползва само от микротика

и не предоставя на други машини

то това може лесно да се види на клиентите от къде си взимат

по подразбиране DHCP и тунелните клиенти ползват dns адресите здадени за сървъри на микротик-а

 

примерно задал си на микртика

/ip dns
set allow-remote-requests=yes cache-size=32768KiB servers=208.67.222.222,8.8.8.8

то и DHCP сървъра и тунелните сървъри раздават тях, ако изрично не си задал други.

Махайки отметката при зададен днс сървър на дадената машина всичко секва поради липса на днс

 

 

allow-remote-requests (yes | no; default: no) specifies whether to allow network requests

 

http://wiki.mikrotik.com/wiki/Manual:IP/DNS#DNS_Cache_Setup

Харесай поста ^^^
acer.gif htc.gifsigpic4024_2.gif

Форумът е за взаимопомощ а не за свършване на чужда работа


ɹɐǝɥ uɐɔ noʎ ǝɹoɯ ǝɥʇ 'ǝɯoɔǝq noʎ ɹǝʇǝınb ǝɥʇ

Адрес на коментара
Сподели в други сайтове

  • 0

да и бе на машина с Allow Remote Requests а !!! :) Ще спра до тук че се уливаме вместо да помагаме :)

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

Теория - това е когато знаете всичко, но нищо не работи

Практика - това е когато всичко работи, но не знаете защо

При нас съчетаваме теорията с практиката - НИЩО не работи и нямаме понятие защо!!!

Адрес на коментара
Сподели в други сайтове

  • 0

Защо за бога като имате централен сървър, правите DNS proxy ?

1) Да пълните паметта на рутерборда за да не стои празна

2) Да си блъскате главата като забие някоя нишка устройството

 

Всяко устройство като почне да извършва много работи е податливо на чупене...

 

Аз поддържам сравнително малка мрежа и имам 2 DNS сървъра, като на половината клиента раздавам единия като primary, а другият като secondary. На другата половина обратното. Проблеми няма.

Адрес на коментара
Сподели в други сайтове

  • 0

Само, че при вас схемата до колкото разбирам е друга

Рутер с някаква ос и 2 отделни DNS сървъра.

 

Колегата който е пуснал темата според мен има една щайга х86 която е рутер и я ползва и за DNS сървър.

Analog Audio™

Адрес на коментара
Сподели в други сайтове

  • 0
  • Администратор
Отговорено (Редактирано)

@kokaracha

Просто не си погледнал:

[admin@R1] > tool traceroute 8.8.4.4
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS                                                      
 1 212.70.158.89                      0%    6   4.2ms    10.6     4.2    36.4    12.9                                                             
 2 193.169.198.80                     0%    5   4.2ms     4.3     4.1       5     0.3                                                             
 3 72.14.235.41                       0%    5   4.4ms     4.5     4.4     4.6     0.1                                                             
 4 8.8.4.4                            0%    5   4.1ms     4.1     4.1     4.2       0                                                             

 

@111111

8.8.8.8 , 8.8.4.4 , 208.67.222.222 , 208.67.222.222 -  Не са DNS сървъри от първо ниво а са кеширащи DNS сървъри които питат DNS сървърите от първо ниво. Предполагам като говорите за кеширащ DNS сървър при доставчика става въпрос за Bind. Да, той прави запитване към сървърите от първо ниво само при условие, че в /etc/resolv.conf има само един ред и той е localhost и съществува следния файл в който се намират въпросните сървъри от първо ниво:

root@host:~# cat /etc/bind/db.root 
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers 
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC 
;       under anonymous FTP as
;           file                /domain/named.cache
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;
;       last update:    Jun 17, 2010
;       related version of root zone:   2010061700
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30
;
; FORMERLY NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
;
; FORMERLY C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; FORMERLY TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; FORMERLY NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2F::F
;
; FORMERLY NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; FORMERLY AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::803F:235
;
; FORMERLY NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
I.ROOT-SERVERS.NET.      3600000      AAAA  2001:7FE::53
;
; OPERATED BY VERISIGN, INC.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:C27::2:30
;
; OPERATED BY RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7FD::1
;
; OPERATED BY ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:3::42
;
; OPERATED BY WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
M.ROOT-SERVERS.NET.      3600000      AAAA  2001:DC3::35
; End of File

DNS сървърите от първо ниво не са длъжни да отговарят бързо а да знаят къде се намират топ левъл домейните тоест ауторитативните сървъри, Тези сървъри отговарят само на определени домейни (те не са кеширащи и не отговарят на заявки освен на собствените си домейни) ,за пример ауторитативните сървъри на google са:

root@host:~# dig google.com

; <<>> DiG 9.7.3 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31858
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 4, ADDITIONAL: 4

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

;; ANSWER SECTION:
google.com.		300	IN	A	212.70.159.110
google.com.		300	IN	A	212.70.159.112
google.com.		300	IN	A	212.70.159.113
google.com.		300	IN	A	212.70.159.117
google.com.		300	IN	A	212.70.159.121
google.com.		300	IN	A	212.70.159.123
google.com.		300	IN	A	212.70.159.80
google.com.		300	IN	A	212.70.159.84
google.com.		300	IN	A	212.70.159.88
google.com.		300	IN	A	212.70.159.90
google.com.		300	IN	A	212.70.159.91
google.com.		300	IN	A	212.70.159.95
google.com.		300	IN	A	212.70.159.99
google.com.		300	IN	A	212.70.159.101
google.com.		300	IN	A	212.70.159.102
google.com.		300	IN	A	212.70.159.106

;; AUTHORITY SECTION:
google.com.		79094	IN	NS	ns2.google.com.
google.com.		79094	IN	NS	ns4.google.com.
google.com.		79094	IN	NS	ns1.google.com.
google.com.		79094	IN	NS	ns3.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.		54378	IN	A	216.239.32.10
ns2.google.com.		54378	IN	A	216.239.34.10
ns3.google.com.		54378	IN	A	216.239.36.10
ns4.google.com.		54378	IN	A	216.239.38.10

;; Query time: 58 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 00:35:56 2014
;; MSG SIZE  rcvd: 420

Тоест Bind в кеширащ режим и настроен правилно събира записи от DNS сърървите от първо ниво и отговаря бързо на клиентите.

 

Mikrotik прави dns маскиране което е същото (кеширане) само, че не пита DNS сървърите от първо ниво а друг кеширащ сървър.

 

@tsvgos

DNS Proxy  е програма която филтрира а не кешира dns записи, предполагам имаш впредвид dnsmasq.

1) Идеята на dns маскирането е кешираните записи да са в памета най близо до клиента и следователно да отговаря по бързо от който и да е друг кеширащ сървър след забележете WAN порта. (ако имате кеширащ сървър преди WAN порта глупаво е да ползвате dns masq)

2) Нямам представа за каква нишка говориш, ако не ти е проблем, сподели ?

Клиентския резолвър въобще не прави разлика между primary и secondary, както и да ги въртиш той винаги пита хаотично или единия или другия така, че това което си направил няма смисъл. 

 

В кеширащите сървъри няма primary и secondary, тази терминология я има само в ауторитативните (тези който отговарят само за собствените си домейни) но те нас в случая не ни интересуват. Това, че така е направено в Windows има друг замисъл и той е, че всеки доставчик обикновенно има два сървъра за имена и е по лесно за клиента да направи аналогията. В UNIX системите клиента няма такава опция - просто пишеш ип адреса.

 

Но при всички операционни системи клиентския резолвър работи на един принцип избира хаотично сървър за имена и пита този домейн към кой ип адрес води и ако няма отговор пита следващия сървър. В промеждутъка от това се появява едно неприятно лагване. За пример ще дам моя домашен рутер който е EdgeMax:

ubnt@R3:~$ show dns forwarding statistics 
----------------
Cache statistics
----------------
Cache size: 150
Queries forwarded: 50498
Queries answered locally: 366644
Total DNS entries inserted into cache: 207235
DNS entries removed from cache before expiry: 15261

---------------------
Nameserver statistics
---------------------
Server: 8.8.4.4
Queries sent: 395
Queries retried or failed: 0

Server: 8.8.8.8
Queries sent: 450
Queries retried or failed: 25

От 8.8.8.8 имам 450 запитвания на които 25 не ми е отговорил, предполагам, че проблема с MikroTik е същия.

Редактирано от samyil
  • Харесай 1
Адрес на коментара
Сподели в други сайтове

  • 0
  • Администратор
Отговорено (Редактирано)

@samyil не съм погледнал,просто съм прогледнал :)

Погрешна е практиката да се ползват тия днс-и,и от това страдат единствено потребителите ви.Каква е гаранцията че оборудването на ексчейджа няма да се скапе или пък някои пиър през който транзитираш няма да отпадне,конкретно при тебе от поста по горе.

Схемата е проста и ясна,локален днс за собствената мрежа и query-та към най близките колокирани в БГ публични днс-и,а обикновенно това са на доставчика на свързаността.

Редактирано от kokaracha

Use since

OpenBSD 3.x

FreeBSD 4.x

Centos 5.x Debian 3.x Ubuntu 7.x

Аз съм фен на OpenWRT.

 

Горчивината от лошото качество остава дълго след като е преминало удоволствието от ниската цена.

_____________________________

___|____|____|____|____|____|__

_|____|____|____|____|____|____

___|____|_ Удряй _|____|____|__

_|____|___ главата ___|____|____

___|____|_ си тук!! |____|____|__

_|____|____|____|____|____|____

___|____|____|____|____|____|__

Адрес на коментара
Сподели в други сайтове

  • 0

Без отметката Allow Remote Requests, днс услугата се ползва само от микротика

и не предоставя на други машини

то това може лесно да се види на клиентите от къде си взимат

по подразбиране DHCP и тунелните клиенти ползват dns адресите здадени за сървъри на микротик-а

 

примерно задал си на микртика

/ip dns
set allow-remote-requests=yes cache-size=32768KiB servers=208.67.222.222,8.8.8.8

то и DHCP сървъра и тунелните сървъри раздават тях, ако изрично не си задал други.

Махайки отметката при зададен днс сървър на дадената машина всичко секва поради липса на днс

 

 

http://wiki.mikrotik.com/wiki/Manual:IP/DNS#DNS_Cache_Setup

Отново не съм съгласен с теб а с теорията по-горе!Мисля че всики разбраха какъв е проблемам на момчето,затова неми се спори повече.

Съвет:-Тоз който се сниши се възвишава а тоз който се възвиши се снижава :)^-^

Адрес на коментара
Сподели в други сайтове

  • 0
  • Администратор

Отново не съм съгласен с теб а с теорията по-горе!Мисля че всики разбраха какъв е проблемам на момчето,затова неми се спори повече.

Съвет:-Тоз който се сниши се възвишава а тоз който се възвиши се снижава :)^-^

Що не си докажеш твърдението в едно видео, да се види как така нещата само при теб са различни.

Харесай поста ^^^
acer.gif htc.gifsigpic4024_2.gif

Форумът е за взаимопомощ а не за свършване на чужда работа


ɹɐǝɥ uɐɔ noʎ ǝɹoɯ ǝɥʇ 'ǝɯoɔǝq noʎ ɹǝʇǝınb ǝɥʇ

Адрес на коментара
Сподели в други сайтове

Създайте нов акаунт или се впишете, за да коментирате

За да коментирате, трябва да имате регистрация

Създайте акаунт

Присъединете се към нашата общност. Регистрацията става бързо!

Регистрация на нов акаунт

Вход

Имате акаунт? Впишете се оттук.

Вписване
  • Потребители разглеждащи страницата   0 потребители

    • No registered users viewing this page.
×
×
  • Създай нов...

Important Information

By using this site, you agree to our Terms of Use.