Šta je novo?

Koji koristite DNS

Pokusao sam da postavim static ip na supernova technicolor ruteru, medjutim izbacuje invalid ip. Koristim orangepi zero armbian za pihole.

Step 2: Reserve the IP Address on the Technicolor Router

  1. Access the Router's Web Interface:
    • Open a web browser and enter your router's IP address (e.g., 192.168.1.1).
    • Log in with your router's admin credentials.
  2. Navigate to DHCP Settings:
    • Look for a section like DHCP, LAN Settings, or Network Settings.
    • Find the option for DHCP Reservations or Static IP Assignments.
  3. Add a Reservation for the Pi-Hole:
    • Locate the Pi-Hole device in the list of connected devices (it may appear by its hostname or MAC address).
    • Assign the same static IP address you configured on the Pi-Hole (e.g., 192.168.1.100).
    • Save the changes.

Kaze DeepSeek find the option...
 

Prilozi

  • Screenshot 2025-02-27 at 17.22.14.png
    Screenshot 2025-02-27 at 17.22.14.png
    282.1 KB · Pregleda: 52
Poslednja izmena:
To je wan sekcija, ti treba da ides u LAN sekciju i DHCP.
 
Da ne otvaram novu temu a vezano je za dns. Imam Mikrotik RB5009 i podigao sam Adguard home na USB-u, definisao upstream servere i sve funkcioniše kako treba. Kao primarni DNS sam definisao IP container-a a sekundarni IP rutera tj. default gateway (uključen allow remote requests). Sad imam nedoumicu, pošto sam u IP DHCP client isključio use Peer DNS, u slučaju da se nešto desi sa USB-om, sekundarni DNS da radi resolve, a opet ne zna odakle ako sam u pravu?

Drugim rečima da li treba dodatno definisati u IP DNS makar jedan kako bi u slučaju da primarni ne reaguje sam ruter radio resolve?
Ako sam dobro postavio pitanje?
 
Kao primarni DNS sam definisao IP container-a a sekundarni IP rutera tj. default gateway (uključen allow remote requests). Sad imam nedoumicu, pošto sam u IP DHCP client isključio use Peer DNS, u slučaju da se nešto desi sa USB-om, sekundarni DNS da radi resolve, a opet ne zna odakle ako sam u pravu?
Tako je, napravio su cirklularnu zavisnost od AdGuard Home DNS, jer tvoj ruter efektivno kešira samo njegove upite. Razrešavanje na ruteru i klijentima gde si postavio iste adrese neće raditi ako AdGuard Home ne radi.

Drugim rečima da li treba dodatno definisati u IP DNS makar jedan kako bi u slučaju da primarni ne reaguje sam ruter radio resolve?
Ako sam dobro postavio pitanje?
Ovako sam razumeo pitanje: da li je potrebno imati rezervni DNS server u slučaju da primarni ne funkcioniše. Ukratko - da, naročito za te self-hosted stvari.

Prvo bih pomenuo da postoje razlike u ponašanju DNS klijent softvera na različitim platformama ukoliko imaju podešeno više upstream DNS servera.
  • Windows ima naviku da čeka do 1s na odgovor od preferiranog DNS servera (obično prvi u listi na mrežnom adapteru), pa onda pusti query na sve u isto vreme i čeka do 2s, itd. Mislim da se ovo menjalo u Windows 10 ali sam prestao da pratim u detalje.
  • Mikrotik koristi odvojene sortirane liste za statičke i dinamičke DNS servere iz upstreama. Obično se inicijalno koristi najbrži a ne primarni, i koristiće se sve dok ne uspe da odgovori na neki upit (ne znam koliki tačno timeout čeka). Dokumentacija im je očaj pa nisam 100% siguran da li je ovo i dalje slučaj, a prošlo je mnogo verzija od kada sam se profesionalno bavio samo mrežama.

Iz ovih razloga sam na MikroTik i njegovim DHCP klijentima podesio samo jedan DNS: AdGuard adresu. Slučaj gde AdGuard ne funkcioniše pokrivam proverom svakih 5s sa Mikrotika da li AdGuard razrešava testni domen (može i lokalni) i ako ne radi, automatski podešavam presretanje svih upita sa Mikrotikovim DHCP klijenata i usmeravanje na Mikrotik lokalni DNS cache, a sam Mikrotik podesim da priča sa drugim upstream DNS-om. Provere i dalje rade, i čim se AdGuard povrati isključujem pravila za presretanje i vraćam Mikrotik DNS na AdGuard. Ako ti ovo izgleda kao rešenje koje bi voleo da primeniš mogu da okačim skripte i ostala podešavanja za RB5009.
 
Voleo bih da probam tu kombinaciju posto koristim i Adguard i 5009 :)
 
Voleo bih da probam tu kombinaciju posto koristim i Adguard i 5009 :)
Fair enough. :)

Interface liste moraju biti podešene kao priperma za firewall pravila ispod. Naravno izmeni da se uklopi sa konfiguracijom tvog rutera, ako imaš sve LAN portove u bridge-u dovoljno je dodati samo bridge interface u LAN interface listu.

Kod:
/interface list
add name=WAN
add name=LAN

/interface list member
add interface=ether2-sbb list=WAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
add interface=ether6 list=LAN
add interface=ether7 list=LAN
add interface=ether8 list=LAN

U firewall pravilima podesi umesto 192.168.4.2 da bude adresa AdGuard-a kod tebe. Očigledno ja presrećem sve clear DNS (TCP i UDP port 53) upite u mreži i forsiram da koriste lokalni AdGuard kada sve radi, a kada je AdGuard nedostupan usmeravam sve upite na lokalni MikroTik DNS. Komentari su bitni jer se pravila uključuju i isključuju na osnovu tih vrednosti u automatizaciji ispod.

Kod:
/ip firewall address-list
add address=192.168.4.2 disabled=no dynamic=no list=dns-local

/ip firewall nat
add action=redirect chain=dstnat comment="dst-nat - dns is down" disabled=yes dst-address-list=dns-local dst-port=53 in-interface-list=!WAN protocol=udp to-ports=53
add action=redirect chain=dstnat comment="dst-nat - dns is down" disabled=yes dst-address-list=dns-local dst-port=53 in-interface-list=!WAN protocol=tcp to-ports=53
add action=dst-nat chain=dstnat comment="dst-nat - dns intercept" dst-address-list=!dns-local dst-port=53 in-interface-list=LAN protocol=udp to-addresses=192.168.4.2
add action=dst-nat chain=dstnat comment="dst-nat - dns intercept" dst-address-list=!dns-local dst-port=53 in-interface-list=LAN protocol=tcp to-addresses=192.168.4.2

Inicijalno podešavanje DNS servera na MikroTik ruteru. Izmene upstream DNS-a preuzima skripta ispod.

Kod:
/ip dns
set allow-remote-requests=yes cache-size=6000KiB max-concurrent-queries=200 max-concurrent-tcp-sessions=40 query-server-timeout=1s query-total-timeout=2s servers=192.168.4.2

Automatizacija se svodi na podešavanje schedulera i skripte. Startup skripta je opciona i kao što vidiš radi i update firmware-a ako identifikuje da je noviji dostupan. Ukoliko ti to smeta slobodno ukloni, jer jedina svrha što sam je postavio ovde je da podesi inicijalnu (praznu) vrednost globalne varijable koju donje skripte konzumiraju.

Naravno u skriptama prilgodi hostname, adresu AdHGuarda i javni failover DNS svom sistemu. Eksport skripti je malo ružan sa ovim line break karakterima, ako ti treba clean skripta mogu i to da iskopiram.

Kod:
/system scheduler
add name=startup on-event="/system script run startup" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-time=startup
add interval=5s name=check-local-dns on-event="/system script run check-local-dns" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=2021-10-01 start-time=08:00:00

/system script
add dont-require-permissions=no name=startup owner=che policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":global globalHostnameResolved\r\
    \n:set globalHostnameResolved \"\"\r\
    \n\r\
    \n# Check for new firmware\r\
    \n\r\
    \n:delay 60s;\r\
    \n\r\
    \n:local oldfirm [/system routerboard get current-firmware];\r\
    \n:local newfirm [/system routerboard get upgrade-firmware];\r\
    \n:if (\$oldfirm != \$newfirm) do={\r\
    \n    /system routerboard upgrade\r\
    \n    :delay 30s;\r\
    \n    :log info \"Firmware is updated from version \$oldfirm to \$newfirm. Restarting.\"\r\
    \n    /system reboot\r\
    \n}"

add dont-require-permissions=no name=check-local-dns owner=che policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":global globalHostnameResolved\r\
    \n:local testHostname \"cher.lan\"\r\
    \n:local testServer \"192.168.4.2\"\r\
    \n:local publicFailoverServer \"1.1.1.1\"\r\
    \n:local testHostnameResolved \"\"\r\
    \n:do {\r\
    \n  :set testHostnameResolved [:resolve \$testHostname server=\$testServer]\r\
    \n} on-error={}\r\
    \n\r\
    \n:if (\$globalHostnameResolved != \$testHostnameResolved) do={\r\
    \n    :if (\$globalHostnameResolved = \$testServer) do={\r\
    \n      /ip firewall nat enable [find where comment=\"dst-nat - dns is down\"]\r\
    \n      /ip firewall nat disable [find where comment=\"dst-nat - dns intercept\"]\r\
    \n      /ip dns set servers=\$publicFailoverServer\r\
    \n      :set globalHostnameResolved \$testHostnameResolved\r\
    \n      :log info \"AdGuard is down!\"\r\
    \n    } else={\r\
    \n      /ip firewall nat disable [find where comment=\"dst-nat - dns is down\"]\r\
    \n      /ip firewall nat enable [find where comment=\"dst-nat - dns intercept\"]\r\
    \n      /ip dns set servers=\$testServer\r\
    \n      :set globalHostnameResolved \$testHostnameResolved\r\
    \n      /ip/dns/cache/flush\r\
    \n      :log info \"AdGuard is back!\"\r\
    \n  }\r\
    \n}\r\
    \n"
 
  • Like
Reagovanja: MT
Pomoc Yettel ZTE ruter 36000, stavio smart dns da imam pristup UK serveru za gledanje njihovih TV programa, sva periferija ok sem Roku uredjaja gde su u hardver ubacili Google dns servere, e sad dobio savet od vlasnika servera da na ruteru blokiram Google dns servere , odnosno kad ih blokiram Roku ne moze da kontroliše geo lokaciju, kako to na ovom ruteru , hvala
J
 
Pomoc Yettel ZTE ruter 36000, stavio smart dns da imam pristup UK serveru za gledanje njihovih TV programa, sva periferija ok sem Roku uredjaja gde su u hardver ubacili Google dns servere, e sad dobio savet od vlasnika servera da na ruteru blokiram Google dns servere , odnosno kad ih blokiram Roku ne moze da kontroliše geo lokaciju, kako to na ovom ruteru , hvala
J
To moras preko firewalla da uradis. Pitanje je da li je moguce na tvom ruteru.
 
Hvala izgleda da ne mogu da pristupim firewallu, samo nivo low, middle i high..Hvala
 
Hvala puno nisam blizu kuce da probam ali koliko sam pogledao jasno mi je izuzev sta je cher.lan (igram se sa MT ali sam samouk :) ) . Pretpostavljam naziv aduard containera ? Mislio sam da si pokrenuo docker na mikrotiku na usb-u - gresim ?
 
Hvala puno nisam blizu kuce da probam ali koliko sam pogledao jasno mi je izuzev sta je cher.lan (igram se sa MT ali sam samouk :) ) . Pretpostavljam naziv aduard containera ?
Adresa lokalnog servera mi je "cher.lan". Njega testiram jer mi je zgodno jer garantovano dobijam brz odgovor kada je AdGuard živ, obzirom da sam je postavio u statične hostove. Ti možeš da staviš www.google.com ili bilo šta drugo.
Mislio sam da si pokrenuo docker na mikrotiku na usb-u - gresim ?
Ne hostujem ni jedan kontejner unutar MikroTik rutera, već na lokalnom serveru u k3s klasteru (minimalna Kubernetes distribucija). Ukoliko ti je potrebna pomoć da zavrtiš AdGuard na samom RB5009 mogu da bacim pogled kad budem imao vremena u ponedeljak/utorak i napišem uputstvo korak po korak. Postoji objašnjenja kako uključiti kontejner mod na ruteru (MikroTik wiki) i sigurno više tema na zvaničnom forumu.
 
  • Like
Reagovanja: MT
Free TLS family ako na to mislis ne razumem se puno
Pa Mullvad ne blokira reklame po defaulutu. Blokiranje je moguće samo korišćenjem njihovih custom DNS servera. Vidi tabelu ispod.

HostnameIPv4 addressIPv6 addressDoH portDoT port
dns.mullvad.net194.242.2.22a07:e340::2443853
adblock.dns.mullvad.net194.242.2.32a07:e340::3443853
base.dns.mullvad.net194.242.2.42a07:e340::4443853
extended.dns.mullvad.net194.242.2.52a07:e340::5443853
family.dns.mullvad.net194.242.2.62a07:e340::6443853
all.dns.mullvad.net194.242.2.92a07:e340::9443853
 
family.dns.mullvad.net koristim ovaj ali reklame su dostupne bukvalno svuda mislim od danas
 
Proveri da li imaš DNS leak na ipleak.net. Noviji browseri mogu da zaobiđu DNS koristeći QUIC protokol. Na nekim chromium based browserima to možeš sprečiti gašenjem opcije use secure DNS.
 
Sweden - Stockholm County
31173 Services AB

Nema Laek a zato reklama budi bog s nama
 
Sweden - Stockholm County
31173 Services AB

Nema Laek a zato reklama budi bog s nama
Probaj AdGuard DNS 94.140.14.14. Ako ti sa ovim radi, znači da je problem sa Mullvad strane. Ako ne radi ni sa ovim, onda ti zaobilazi DNS sa QUIC protokolom. Nisi napisao ni koji je browser ni koji je uređaj u pitanju.
 
Možda će nekome biti korisno da napišem iskustvo sa enkriptovanim upstream DNS serverima iz ugla performansi.

Želeo sam da poboljšam performanse razrešavanja upstream DNS-ova na mom AdGuard home, jer sam primetio da se nekad Quad9 i Cloudflare DoH ponašaju tromo sa SBB kablovskog neta. Hteo sam da zadržim enkripciju na svojim upstream DNS serverima, pa sam istraživao javno dostupne i proverene DoH, DoT i DoQ opcije.

DoQ je jako brzo ispao iz priče jer specifikacija za QUIC protokol u okviru DNS implementacije nije još uspešno implementirana i pravilno istestirana, i zbog toga ni jedan veliki igrač nema u ponudi tu varijantu. Malo sam ispratio diskusije na Quad9 i Cloudflare boardovima i video da se čeka stabilizacija PowerDNS-ovog dnsdist balancera (koji pretpostavljam dosta ovih vendora koristi), i kada se to istestira verovatno će lagano krenuti da se pojavljuju i servisi i kod nama poznatih korporativnih imena. Tu ima mnogo mojih pretpostavki, ali nije mi ni bitno da dođem do suštine ove situacije jer sam samo korisnik, i ne monetizujem DNS servise.

Prva sledeća stvar koja je na listi unapređenja je bilo zamenjivanje DoH sa DoT. Iskreno, nisam obraćao pažnju prilikom inicijalnog korišćenja ovih enkriptovanih servisa, ali je sasvim logično da će DoH uvek biti sporiji od ekvivalentnog DoT jer u steku postoji još jedan protokol. Dakle:
je zamenjeno sa
tls://9.9.9.10
tls://1.1.1.1

Druga stvar je upstream mod. Tradicionalno sam koristio load-balancing, ali najbolji rezultati se dobijaju kada pitamo sve upstreamove i iskoristimo najbrži odgovor, tj parallel requests mod.

I pored svega ovoga neretko sam viđao da se neki odgovori čekaju preko 100ms (često sam viđao Netflix data streaming u ovako lošim statistikama), što je meni neprihvatljivo za domene koji nisu potekli iz Kine. Za test sam dodao i Google-ov DNS over TLS server i za divno čudo mnogo je pomoglo da se normalizuju upiti, čak je i sada taj prokleti Netflix app uglavnom opslužen ispod 50ms iz ugla DNS-a. Dakle finalna lista upstream DNS-ova je:
tls://9.9.9.10
tls://1.1.1.1
tls://8.8.8.8

Sada su najbrži odgovori skoro podjednako raspoređeni između tri upstreama, što znači da mi je odluka da ih koristim više bila dobra:
1747582005394.png

Processing time je uglavnim ispod 20ms. Ova brojka me iritira jer mnogo zavisi od procenta keširanih i blokiranih zahteva i ne reflektuje stvarno prosečno vreme odgovorenih zahteva, ali trenutno nemam bolju i mrzi me da pravim izraz koji bi bio tačniji:
1747581888206.png

Upstream response time, iako varira to me efektivno ne interesuje toliko obzirom da se svi takmiče za najbrži odgovor:
1747581938357.png
 
Problem je što mi u Srbiji generalno imamo problem sa tim public DNS serverima i odziv jako varira od provajdera do provajdera i od perioda do perioda.

1747583019827.png
Konkretno na 9.9.9.9 mi se dešava da po 2 nedelje imam preko 300ms odziv na MTS-u, tako da sam DNS gateway prebacio na VPN gde je odziv mnogo bolji jer saobraćaj izgleda ide drugom mnogo bržom rutom.

1747583215352.png
 
Na MTS optici si? Koliko je bizarno što moraš da koristiš VPN da bi zaobišao neoptimalno (nekompetentno?) rutiranje u sopstvenom internet provajderu.
 
Želeo sam da poboljšam performanse razrešavanja upstream DNS-ova na mom AdGuard home
Bitan update, iako posle dužeg vremena.

U početku nisam želeo da uključim opciju cache_optimistic jer potpuno menja ponašanje AdGuard servisa, koji bi potencijalno odgovarao sa pogrešnim (zastarelim) rezultatima. Međutim, posle testiranja mogu i da preporučim obzirom da nisam uočio ni jedan problem, a ukućani mi se takođe nisu žalili. Ubrzanje učitavanja web sajtova je primetno.

Ovde DNS keš postaje glavni faktor performansi, pa sam zbog toga izmenio cache_ttl_min (na "rizičnih" 2400 sekundi) i cache_size (overkill je, ali ne škodi u mom slučaju).

Kompletna lista opcija za keširanje koje su vezane za ovaj slučaj:
Kod:
      cache_enabled: true
      cache_size: 67108864
      cache_ttl_min: 2400
      cache_ttl_max: 84600
      cache_optimistic: true

Rezultati su bukvalno neverovatni. Sada je average processing time (vreme od kada klijentski zahtev dođe do AdGuard-a, do momenta kada server vrati klijentu odgovor) ispod 1ms! Efektivno, prosečna brzina razrešavanja domena je slična kao kada bi svi DNS serveri bili u vašoj lokalnoj mreži.

Ovo bih preporučio ukoliko imate veći broj klijentskih uređaja u mreži, nisam siguran koliko vredi za mali broj klijenata (1-5).

Upstream-ovi i dalje imaju svoj manje-više očekivani odziv, a koristim iste TLS servere kao i pre pola godine. Zanimljivo je da statistika za request count izgleda da broji samo upite koji nisu opsluženi iz keša (vidite da je za 24h taj broj nerealno mali, jer bi standardno trebalo biti desetine hiljada za moju mrežu):
1758912696844.png
AdGuard panel:
1758912583653.png

Grafana dashboard:
1758912601689.png
 
Da li znas da li se rezultati rekesiraju kada odes na sajt ili ne?
Stavio si max ttl na oko 24h. Podatak se upise u kes i do sutra se dns zahtev isporucuje iz kesa, ali da li se obnavlja tokom posecivanja.
Recimo da neki sajt gledam svako jutro i ne vise. Ako se kes ne obnavlja, onda ce jedan da bude brz odgovor, a drugi spor i tako u krug.
Sasvim mi je ok da on u pozadini odradi upstream upit i produzi kesiran podatak ili ga mozda i izmeni ako ima potrebe.
 
Da, rezultati se rekeširaju svaki put kada bilo koji klijent traži zapis koji je u kešu.

Od svih tih podešavanja max TTL ima najmanje uticaja na dobitak u performansama, jer ogromna većina DNS zapisa na internetu ima TTL do 5 minuta.

TTL mehanizmi koje sam podesio u stvari prepisuju TTL ukoliko je manji od min ili veći od max.

Hipotetički, dođe mi od neke klijentske mašine upit za neki Netflix-ov streaming server koji je originalno imao TTL 1 minut (CNAME ili A record, nebitno).
  • Ako nije bio u kešu, pitaće AdGuard upstream servere, proslediti rezultat klijentu i interno u kešu prepisati TTL na 40 minuta (2400s)
  • Ako je odgovor već u kešu, odmah će odgovoriti klijentu i pitati upstream za ažurni rezultat i ponovo osvežiti TTL na 40 minuta (ovde postoji mala šansa da klijent dobije zastareo odgovor, kao što sam pomenuo, ali nisam za sada imao problema)

Ako gledaš neki sajt svako jutro i ni jednom između tog perioda, velika je šansa da će sa ovim podešavanjima koje ja koristim AdGuard morati da pita regularno upstream, jer 40 minuta minimalni TTL ne pokriva tvoj use case i pretpostavljajući da njihov DNS nema dugačak TTL. Svakako, niko te ne sprečava da podesiš max TTL na nedelju dana, što opet ne garantuje da ćeš odgovor dobiti iz keša, već bi morao da povećaš i min TTL. Ali opet, koiliko bi dobio na percepciji brzine interneta mereći odziv sajta koji otvaraš samo jednom dnevno?
 
Kako bre imaš skoro 80% blokiranih? Kod mene je nekih 10-20% prosek obično.
Ja takođe koristim optimistic caching, ali sam primetio da često imam response iz keša koji je 20-30ms. U normalnim situacijama je ispod 1ms, i to imam isto, ali često se dešava ovo drugo. Pojma nemam zašto, nikako da uzmem da istražim malo..
 
Kako bre imaš skoro 80% blokiranih? Kod mene je nekih 10-20% prosek obično.
Uzrok visokog procenta blokiranih upita je samo jedan PC sa instaliranih nekoliko kineskih gacha igrica (Honkai, Genshin Impact), i te aplikacije su ekstremno agresivne u pokušaju slanja telemetrije što se blokira na AdBlock serveru. Nije tipična situacija.
 
Nazad
Vrh Dno