Алтернативни DNS-и, мнения

[w00x]

На Куулбокс DNS-ите падаха супер често. Затова ги смених аз моите.

[plameni]

Аз не бих сложил всички DNS-и да са само от един доставчик.

[tedy]

Аз не бих сложил всички DNS-и да са само от един доставчик.

Това съвсем принципно може и да има резон, но затова по принцип се дават по два, за предопчитане лежащи в различни мрежи. 99.9% от потребителите получават през DHCP два само от техния си ISP.

Ако се случи да паднат и двата на CF по едно и също време, ще го мислим тогава . Аз лично много силно се съмнявам това да се случи, при цялата резервираност на CF, дори и на гугъл.

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

Поне тия настройки се сменят за секунди, така че не е проблем.

[plameni]

...Ако се случи да паднат и двата на CF по едно и също време, ще го мислим тогава . Аз лично много силно се съмнявам това да се случи, при цялата резервираност на CF, дори и на гугъл.

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

Поне тия настройки се сменят за секунди, така че не е проблем.

 

Шансът да паднат едновременно и двата на CF сигурно е под 1/1000000, но шансът да има проблем с едно международно трасе, което ползваш за достъп и до двата DNS-а е значително по-голям.

Какво като работят и двата, ама има flood? Или има временно превключване по алтернативно (по-бавно и натоварено трасе)?

Защо да го мисля, когато се случи, а да не заложа предварително на автоматично решение?

[tedy]

1.1.1.1 както се оказа, са си в България, просто минават през телиа. Имам 2ms пинг към него.

plameni, какво беше твоето решение в този случай, защото си спомням, че ти ползваше гугълските. Или ползваш само тях, защото са в пиъринга, и тези проблеми, които си описал, не те касаят?

Аз иначе Ок, сложих трети, и сега съм така

[plameni]

От месец съм така:

1.1.1.1

8.8.8.8

212.116.136.2

 

Третият е на 2 хопа:

traceroute to 212.116.136.2 (212.116.136.2), 18 hops max, 40 byte packets
 1  94.155.94.22 (94.155.94.22)  2.692 ms  2.640 ms  3.258 ms
 2  ns1.itdnet.net (212.116.136.2)  2.825 ms  2.871 ms  2.787 ms

Не помня дали съм споменавал, но рутерът има много хубава опция Enable All Servers, която естествено съм включил 

By default, when more than one upstream server is available, it will send queries to just one server. Setting this flag forces all queries to all available servers. The reply from the server which answers first will be returned to the original requestor.

[instinct]

Някой има ли идея колко големи са (архивирани с хубава компресия) тия DNS записи...

 

А иначе най-бързият достъп е до сървърите на доставчиците. И логично всеки компютър се настройва да взима адресите оттам по подразбиране. Другото са вторични възможности при евентуални временни проблеми, и отделно privacy issues.

[plameni]

Най-бързият достъп не означава непременно най-бърз отговор!

Сървърът на доставчика пази кеширана информация за най-честите запитвания. За всичко останало пак пита нагоре по веригата.

[instinct]

Май не е точно така, защото при създаване на нов адрес, докато се ъпдейтнат с него записите на всички отделни DNS бaзи данни, може да мине и цял ден. Според мен всеки доставчик си държи по едно копие локално, и от време на време го ъпдейтва.

[tedy]

И това не е точно така. Тия периоди "докато се ъпдейтнат днс-ите по света" идва точно от кеша. Ако е по-известен домейн, все някой от абонатите на даден ISP ще го заявява често, и ако записа е с TTL 1 ден, с голяма сигурност ще присъства в кеша, и този 1 ден е максималния период, който трябва да се изчака за всички кеширали го днс резолвери по пътеката, да им изтече този 1 ден и да го заявят те отново когато техен клиент го поиска отново.

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

 

Иначе поне за 1.1.1.1, закъснението/пингът към него при мен е същия като на ДНС-ите на ISP, около 2 до 2.5ms. Оттам нататък май стана ясно, че 1.1.1.1 е по-бърз резолвер поне от днс-ите на кулбокс.

Cloudflare също държат кешове, сигурно доста големи.

[instinct]

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

[tedy]

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

Но да държи цялата база ДНС локално.... не. Това "преди" е било преди 50 години сигурно, когато са се менкали пълните бази данни с адресите като текстови файлове между нодовете .

[plameni]

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

 

 Ти направо зачеркна TTL-а

[instinct]

Това проверил ли си го, или само мислиш, че не ги държат локално? Неслучайно питах за размера на базата данни.

 

Факт е (или поне беше), че отнема време преди нов или променен адрес да започне да "работи". Ако всяка заявка отиваше нагоре по веригата, то адресите щяха да работят веднага. Само че нямаше да отнеме 2 ms питането, а да кажем 5 секудни докато отиде до най-горе и оттам върнат ип-то.

[tedy]

Това проверил ли си го, или само мислиш, че не ги държат локално? Неслучайно питах за размера на базата данни.

 

Факт е (или поне беше), че отнема време преди нов или променен адрес да започне да "работи". Ако всяка заявка отиваше нагоре по веригата, то адресите щяха да работят веднага. Само че нямаше да отнеме 2 ms питането, а да кажем 5 секудни докато отиде до най-горе и оттам върнат ип-то.

Ми именно. Ако е кеширан някъде по веригата (колкото по-нагоре, толкова по-вероятно да е с по-малко оставащ TTL), този ТТЛ трябва да изтече при всички, които са го кеширали по веригата от руут-а до твоята машина, преди да видиш промяната. То това е базовата същност на ДНС и ТТЛ-а.

Ако примерно имам мой слабо посетен домейн и не съм го зареждал скоро и променя ИП адреса му в ДНС сървъра където се хоства, и след това заредя, веднага виждам промяната, защото не е кеширан никъде.

 

P.S. Цялата база данни ти и да искаш не можеш да я събереш. Има милиарди (сигурно десетки милиарди) домейни, голяма част с доста ИП-та зад един домейн, както и други видове записи (MX, AAAA, TXT и др), примерно за един домейн ще имаш 4-5КБ ДНС информация. Повечето домейни имат поддомейни и под-под домейни, за които се грижат ДНС сървъри под самите домейни, под техен контрол. Там вече какви поддомейни има ти не знаеш централизирано докато отнякъде не намериш линкове към тях, и пак не можеш да знаеш обфускирани разни поддомейни и т.н.

Ако предположим, че има 10 милиарда главни домейни и всеки има поне по 5, 50 милиарда домейна по 5КБ средно, това прави примерно 250 терабайта данни .

[plameni]

Само списъкът на домейните през 2015-а е над 550 мегабайта. Има го като торент.

Сега може да е няколко пъти повече. Като добавиш и всички останали записи... направо не ми се смята.

Не знам кой провайдер би отделил машина(и) с толкова сериозен ресурс, за да държи почти пълно копие на информацията (пълно е невъзможно).

Тези казват, че за $499 могат да ти продадат цялата база    

(total of 256,347,215 gTLD and ccTLD domains)

[instinct]

Аз си спомням, че имаше период, през който не беше активен новият адрес. Докато не влезе в базите данни на сървърите. Което означава, че няма как заявката веднага да се изпълни от top level сървър (или поне не във всички случаи).

 

Очевидно не става въпрос за цялостно кеширане локално поне за държава, град или доставчик (което би било най-бързия метод, но пък предвид вече добрата свързаност на мрежата може би не е толкова необходимо), но все пак има разни обновявания на бази и подбази докато най-после всичко заработи. Не е достатъчен само един сървър най-горе, до който отивали всички заявки непознати на кеша.

 

Some registries take longer than others to make DNS changes or activate domains in their zone for the first time.  After the registry has delegated your domain, remember that any DNS change is subject to propagation over local DNS server caches, which usually takes up to 24 hours.

 

Even if your domain is delegated to the right name servers at the registry, if these name servers aren't set up to answer for your domain your domain will not resolve and none of the services at your domain will function correctly.

 

After you have registered a domain name with No-IP, it will take 24-72 hours for your domain name to propagate to all of the root DNS servers. Your domain may show up in the WHOIS database before it has fully propogated to the root DNS servers.

[plameni]

Защо смесваш два различни случая?

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

По темата.

Пуснах един NameBench с тези настройки:

 

 

и препоръчаната подредба се оказа точно каквато аз съм преценил:

 

[tedy]

Е, то това се подразбираше

1.1.1.1 е по-бърз от гугълските, а тоя на итднет къв е... на мен дхцп-то ми дава някакви съвсем други 82.хххххх

[ARPAnet]

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

Та инстинкте пишеш абсолютни глупости

[plameni]

... а тоя на итднет къв е... на мен дхцп-то ми дава някакви съвсем други 82.хххххх

 

Още от времето преди кулбокс го има. Другите ги пуснаха за хоум клиентите.

[tedy]

Още от времето преди кулбокс го има. Другите ги пуснаха за хоум клиентите.

Ясно.

Интересно, но пинга ми към този е по-висок от пинга към 1.1.1.1 . Някъде около 3.6 средно. Тоя клаудфлеър бива, като се има предвид, че е минаващ през телиа и водещ се "международен". Говоря само за пинга, а колко е по-бърз или бавен този ДНС, е отделен въпров, явно е и по-бавен според твоя тест.

[instinct]

Хубаво, аз не съм се интересувал от точната технология на кеширането, да кажем - няма общи бази данни, и ще спестите 0,1 ms (голямата печалба ) ако не ползвате DNS на доставчика. Ама другото, ако тръгнете с някакви гуугл международни и подобни, струва ли си - за мен спрямо "печалбата" - не, и затова ми е странно как чак се мери и коментира нещо толкова дребно в замяна на което се дава друго, дето струва много:
 

и отделно privacy issues.

[ARPAnet]

Хубаво, аз не съм се интересувал от точната технология на кеширането, да кажем - няма общи бази данни, и ще спестите 0,1 ms (голямата печалба ) ако не ползвате DNS на доставчика. Ама другото, ако тръгнете с някакви гуугл международни и подобни, струва ли си - за мен спрямо "печалбата" - не, и затова ми е странно как чак се мери и коментира нещо толкова дребно в замяна на което се дава друго, дето струва много:

 

За разликата от ISP–тата, Cloudflare обещават да не събират данни за юзърите си.

Винаги можеш да рънваш собствени днс-и

[Midex]

От вчера съм с трите DNS-а в реда 1.1.1.1. / 1.0.0.1 / 8.8.8.8 и засега нямам оплаквания.