Julkiset DNS-palvelut

  • Keskustelun aloittaja Keskustelun aloittaja east
  • Aloitettu Aloitettu
  • Avainsanat Avainsanat
    dns
escalibur sanoi:
Tuohon iCloud Relayyn kannattaa suhtautua varauksella, kun kyse on vasta lanseeratusta palvelusta.

fingerprintjs.com

iOS 15 iCloud Private Relay Vulnerability Identified

Learn more about this vulnerability in Apple’s new iCloud Private Relay service and how you can prevent your data from being leaked.
fingerprintjs.com fingerprintjs.com
Napsauta laajentaaksesi...
Joo tuo on vielä beta.
1633851548706.png

Tuli tuota testattua kun mulla on Apple One tilaus ja perjantaina tuli Appleltä sähköpostia, että "Tilauksesi on päivitetty iCloud+:aan ilman lisämaksua". Tuo iCloud Relay kuuluu tuohon iCloud+ palveluun.

iCloud+ plans and pricing - Apple Support

When you sign up for iCloud, you automatically get 5GB of free storage. If you need more space in iCloud, you can upgrade to iCloud+.
support.apple.com support.apple.com
 
Viimeksi muokattu:
Itsekin testasin sitä kun on iCloud+-tilaus mutta jätin käyttämättä kun vaikutti, ettei ihan kaikki sivut ja palvelut toimi. Selvä BETA-fillis koko ominaisuudesta. Tpivotaan että tuo kypsyy tulevien kuukausien aikana.
 
Terve ! DoT asiaa vähäsen.

Tämä kysymys ehkäkin kuuluu tähän. Vähän aikaa sitten cloudflaren dns muuttui dnsleaktest sivun mukaan joksikin icloud nimiseksi isp palveluksi joten hieman säikähdin ja vaihdoin äkkiä quad9 palveluun, aiemmin on ollu nextdns, mutta DoT stubbyn kanssa tuli ongelmia enkä jaksanu enää tapella niin aloin etsimään parempaa tilalle. On vaikea löytää palvelua omilla kriteereillä, mutta se on nyt sivuseikka tässä.

Edgerouter er-x:ssä on pihole kiinni, jonne kyselyitä tulee tällä hetkellä kahdelta laitteelta. 1kpl ps4 & 1kpl tietokone.
Edgerouterissa traffic analyser näyttää että Piholen Dns Over Tls on ainoastaan 74% , ja loput se näyttää olevan "other" kategoriassa mitä sitten ikinä onkaan...(25%). Kummallinen juttu tuo 25% "other" kategoria, koska ei edes pitäisi olla mitään muuta. Nollasin äskettäin traffic analyserin edgessä kun aloin seuraamaan mitä tapahtuu tuossa Edgen traffic analyserissä.

Pihole pyörii linuxissa läppärillä, stubby (DoT) on asennettu tähän samaan läppäriin missä pihole pyörii. Jos läppäri hakee esimerkiksi päivityksiä, niin meneeköhän ne stubbyn kautta Dot:tina, vai oikaiseeko läppäri ja edgerouter tulkistee tämän "other" kategoriaksi jotka ei näy Dns Over TLS:ssänä Edgerouterissa ?

Pihole näyttää kuitenkin kaikki mitä näillä kahdella laitteella tapahtuu mielestäni aivan oikein, eli kaikki ne dns kyselyt sekä vierailemani sivut ja pelit ps4:lla. Eli, näyttääkö edgerouter vääriä tietoja vai meneekö piholesta osa dns kyselyistä aivan jonnekkin muualla ja vielä noin suuri määrä kuin 25%. Se olisi suurempi jos edgen trafikkia seuraisi pidemmän aikaa (nollasin sen n.2h sitten kun aloin vähän seuraamaan mitä tapahtuu). Tänä aikana pelasin vähän ps4:lla ja pc vain "afkannu" tyhjällä työpöydällä. Dnsleaktest näyttää kyllä aivan oikein quad9 palvelun kun tekee testin. Pihole näyttää omasta mielestä välillä kyllä debianin osoitteita joten luulis että läppärinkin (linux läppäri + pihole + stubby) liikenne menisi myös DoT eikä sivusta ohi ilman DoT.

Mitä on tuo kummallinen edgen kertoma ainoastaan 74% Dns Over tls ja mihin muut kyselyt sitten ovat menneet ?Edgessä kun on vain pihole dns asetuksissa, eikä secondary palvelinta ollenkaan ole määritetty. Eihän sinne voi edes kakkos palvelinta Edgerouteriin nimetä kun sitten kyselyt eivät menis piholelle. Pitäiskö piholeen lisätä tuon stubbyn lisäksi secondary osoite ? Sitten osa tai kaikki menis ilman stubbya eli DoT voisi pudota pois kokonaan välistä ?

Voiko tuota jotenkin varmistaa että kaikki kyselyt menis varmuudella piholeen ? Sitten välillä ilmestyy edgen traffic analyseriin xboxia vaikken omista edes xboxia, ja pc:lläkin on käytössä linux niin ei tässä ole microsoftin kanssa mitään tekemistä ? Konffien pitäis olla ok edgessä sekä piholessa, mutta voiko tuohon edgen traffic analyseriin luottaa ja kannattaako tuosta huonosta DoT lukemasta edgessä välittää miten paljon ?

En tiedä pystyykö piholen asetuksiin lisäämään esimerkiksi dnscrypt-proxyn vielä rinnalle, auttaisko se noissa edgen mukaan hukatuissa dns kyselyissä jos olis DoT & Dnscrypt rinnakkain käytössä piholessa, vai lieneekö tuo edes mahdollista käyttää dnscrypt-proxyä sekä stubbya piholessa yhtäaikaa ?

Pahoittelut sekavan oloisesta viestistä, mutta tuota kysymystä on vähän hankala muotoilla helpomminkaan ja yritin kuvailla mahdollisimman selkeäksi tuon kummallisen seikan. Kiitos kuitenkin jos jollain on tietoa. Lähinnä ihmettelen tota edgerouterin 74%:sta DoT lukemaa että mihin loput on menny ?


Edittiä koska, Edgerouteriin ilmesty traffic analyseriin nyt Pihole laitteelle debian / ubuntu update kategoria. Menikö tuo nyt edgerouterin mukaan ilman Dns Over TLS ? Nyt DoT & "other" kategoari on noin tasan, 50/50%. Onko tuo normaalia vai nyt joku pahasti vialla ?
 
Viimeksi muokattu:
Pah0lain3 sanoi:
Terve ! DoT asiaa vähäsen.

Tämä kysymys ehkäkin kuuluu tähän. Vähän aikaa sitten cloudflaren dns muuttui dnsleaktest sivun mukaan joksikin icloud nimiseksi isp palveluksi joten hieman säikähdin ja vaihdoin äkkiä quad9 palveluun, aiemmin on ollu nextdns, mutta DoT stubbyn kanssa tuli ongelmia enkä jaksanu enää tapella niin aloin etsimään parempaa tilalle. On vaikea löytää palvelua omilla kriteereillä, mutta se on nyt sivuseikka tässä.

Edgerouter er-x:ssä on pihole kiinni, jonne kyselyitä tulee tällä hetkellä kahdelta laitteelta. 1kpl ps4 & 1kpl tietokone.
Edgerouterissa traffic analyser näyttää että Piholen Dns Over Tls on ainoastaan 74% , ja loput se näyttää olevan "other" kategoriassa mitä sitten ikinä onkaan...(25%). Kummallinen juttu tuo 25% "other" kategoria, koska ei edes pitäisi olla mitään muuta. Nollasin äskettäin traffic analyserin edgessä kun aloin seuraamaan mitä tapahtuu tuossa Edgen traffic analyserissä.

Pihole pyörii linuxissa läppärillä, stubby (DoT) on asennettu tähän samaan läppäriin missä pihole pyörii. Jos läppäri hakee esimerkiksi päivityksiä, niin meneeköhän ne stubbyn kautta Dot:tina, vai oikaiseeko läppäri ja edgerouter tulkistee tämän "other" kategoriaksi jotka ei näy Dns Over TLS:ssänä Edgerouterissa ?

Pihole näyttää kuitenkin kaikki mitä näillä kahdella laitteella tapahtuu mielestäni aivan oikein, eli kaikki ne dns kyselyt sekä vierailemani sivut ja pelit ps4:lla. Eli, näyttääkö edgerouter vääriä tietoja vai meneekö piholesta osa dns kyselyistä aivan jonnekkin muualla ja vielä noin suuri määrä kuin 25%. Se olisi suurempi jos edgen trafikkia seuraisi pidemmän aikaa (nollasin sen n.2h sitten kun aloin vähän seuraamaan mitä tapahtuu). Tänä aikana pelasin vähän ps4:lla ja pc vain "afkannu" tyhjällä työpöydällä. Dnsleaktest näyttää kyllä aivan oikein quad9 palvelun kun tekee testin. Pihole näyttää omasta mielestä välillä kyllä debianin osoitteita joten luulis että läppärinkin (linux läppäri + pihole + stubby) liikenne menisi myös DoT eikä sivusta ohi ilman DoT.

Mitä on tuo kummallinen edgen kertoma ainoastaan 74% Dns Over tls ja mihin muut kyselyt sitten ovat menneet ?Edgessä kun on vain pihole dns asetuksissa, eikä secondary palvelinta ollenkaan ole määritetty. Eihän sinne voi edes kakkos palvelinta Edgerouteriin nimetä kun sitten kyselyt eivät menis piholelle. Pitäiskö piholeen lisätä tuon stubbyn lisäksi secondary osoite ? Sitten osa tai kaikki menis ilman stubbya eli DoT voisi pudota pois kokonaan välistä ?

Voiko tuota jotenkin varmistaa että kaikki kyselyt menis varmuudella piholeen ? Sitten välillä ilmestyy edgen traffic analyseriin xboxia vaikken omista edes xboxia, ja pc:lläkin on käytössä linux niin ei tässä ole microsoftin kanssa mitään tekemistä ? Konffien pitäis olla ok edgessä sekä piholessa, mutta voiko tuohon edgen traffic analyseriin luottaa ja kannattaako tuosta huonosta DoT lukemasta edgessä välittää miten paljon ?

En tiedä pystyykö piholen asetuksiin lisäämään esimerkiksi dnscrypt-proxyn vielä rinnalle, auttaisko se noissa edgen mukaan hukatuissa dns kyselyissä jos olis DoT & Dnscrypt rinnakkain käytössä piholessa, vai lieneekö tuo edes mahdollista käyttää dnscrypt-proxyä sekä stubbya piholessa yhtäaikaa ?

Pahoittelut sekavan oloisesta viestistä, mutta tuota kysymystä on vähän hankala muotoilla helpomminkaan ja yritin kuvailla mahdollisimman selkeäksi tuon kummallisen seikan. Kiitos kuitenkin jos jollain on tietoa. Lähinnä ihmettelen tota edgerouterin 74%:sta DoT lukemaa että mihin loput on menny ?


Edittiä koska, Edgerouteriin ilmesty traffic analyseriin nyt Pihole laitteelle debian / ubuntu update kategoria. Menikö tuo nyt edgerouterin mukaan ilman Dns Over TLS ? Nyt DoT & "other" kategoari on noin tasan, 50/50%. Onko tuo normaalia vai nyt joku pahasti vialla ?
Napsauta laajentaaksesi...

Pieni päivitys kummalliseen asiaan.

Nyt eilisestä tilanne muuttunu sen verran, että edgerouterissa traffic analyser näyttää....Jaa. Se näyttääkin aivan mitä sattuu.
- Äsken edgerouter näytti piholen DoT liikenne 100%, mutta tätä kirjoittaessa tilanne muuttui aivan päinvastaiseksi. Nyt sitten näyttää että Dns Over Tls olisi piholessa ainoastaan vain alle 5% liikenteestä. Tuo taitaa nyt puhua ihan höpö höpö juttuja tuo edgerouterin traffic analyser ?

Nyt tuntuu kyllä että tuo edge näyttää aivan mitä sattuu. Pihole kuitenkin näyttää vierallut sivut oikein, eli dns kyselyt taitavat mennä kaikki kyllä oikein piholen & stubbyn kautta. Läppärissä dig komento minusta näyttää ihan normaalilta niinkuin aina, sekä dnsleaktest sivu näyttää oikeaa quad9 palvelua joka on määritetty stubbyyn. Vähän näyttää siltä että tuo edge ei nyt osaa tulkita asioita ihan oikein ? Tai tuo traffic analyser näyttää mitä sattuu, netti siis toimii aivan normaalisti mutta eilen aloin ihmettelemään että voiko tuo edgerouterin traffic analyser pitää paikkaansa kun valtaosa sen mukaan dns kyselyistä menis jonnekkin muualle kuin piholeen.

Tuohon kysymykseen en myöskään ole löytäny vastausta, voiko piholessa pitää Stubbya & dnscrypt-proxya samanaikaisesti käytössä jotta kyselyt menis jommallekummalle piholessa ? Vai miten sais varmistuksen sille että jos quad9 palvelussa tulee vähän pidempi toimintakatko niin olis sitten joku "plän B" sille että verkko jatkais toimintaa vain toisella palvelulla sen aikaa että quad9 toimis jälleen. Miten tuollaisen voisi toteuttaa ?


Edittiä vielä, kovasti tuo edge nyt vaan esittää traffic analyserissä että tuon DoT osuus olisi tuo 5% ja loput aivan jotain muuta.
 
Päivitin ketjun otsikkoa vastaamaan paremmin sen sisältöä. "DNS-palvelimet" -> "Julkiset DNS-palvelut"
 
Tämäkin DNS keskustelu jäänyt minulla vähiin, kun käytän VPN kanssa sen omia DNS osoitteita, mutta joo Cloudflare se käytetyin varmasti ja nopein.

Viimeksi kun testasin Quad9 niin heitti että ranskasta asti vetää, mutta eiköhän suomesta tule jo.
 
runboy93 sanoi:
Tämäkin DNS keskustelu jäänyt minulla vähiin, kun käytän VPN kanssa sen omia DNS osoitteita, mutta joo Cloudflare se käytetyin varmasti ja nopein.

Viimeksi kun testasin Quad9 niin heitti että ranskasta asti vetää, mutta eiköhän suomesta tule jo.
Napsauta laajentaaksesi...
Ehkä tuo 9.9.9.9 "tavallinen" voi näyttää, mutta mulla on ainakin käytössä tuo DoT quad9:llä nyt ja browserleaks näyttää ranskaa ja dnsleaktest näyttää jenkkilään. Tiedä sitte mikä on oikein...Tämä siis tietenkin ilman mitään vpn palveluita. Kyllä vpn ollessa käytössä sitten pitää ne vpn tarjoamat dns osoitteet olla käytössä.

Mulla on käytössä tämä ilman vpn palveluita
IPv4
9.9.9.11
tls://dns11.quad9.net
Secured w/ECS: Malware blocking, DNSSEC Validation, ECS enabled
 
Viimeksi muokattu:
runboy93 sanoi:
Tämäkin DNS keskustelu jäänyt minulla vähiin, kun käytän VPN kanssa sen omia DNS osoitteita, mutta joo Cloudflare se käytetyin varmasti ja nopein.

Viimeksi kun testasin Quad9 niin heitti että ranskasta asti vetää, mutta eiköhän suomesta tule jo.
Napsauta laajentaaksesi...

Tracerouten perusteella allekirjoittaneella menee sekä 9.9.9.9 että 9.9.9.11 TREXiin ja sieltä sitten PCH42:een. Latenssien puolesta (3ms kuituliittymästä) lähin anycast-palvelin taitaa olla TREXillä Tampereella.
Luulen että jokaisella vähänkään suuremmalla suomalaisella operaattorilla menee näin (testattu Telialla (AS1759) ja FUNETilla).
Sen sijaan Twelve99:llä (AS1299, ent. Telia Carrier/TeliaSonera International Carrier) menee ilmeisesti Pariisiin (36ms Helsingistä), eli riippuu käytettävän operaattorin peeringien mukaan. Traceroutella selviää.

IP-osoitteiden näyttäminen huuhaata ei ole mitenkään uusi juttu.
En ole juurikaan tutustunut Quad9:iin, joten en tiedä mitä IP:tä näyttävät noissa DNS-leak-testeissä. Näyttääkö 9.9.9.9 vai jotain muuta (todennäköisempi vaihtoehto)?
 
Pikkis sanoi:
Tracerouten perusteella allekirjoittaneella menee sekä 9.9.9.9 että 9.9.9.11 TREXiin ja sieltä sitten PCH42:een. Latenssien puolesta (3ms kuituliittymästä) lähin anycast-palvelin taitaa olla TREXillä Tampereella.
Luulen että jokaisella vähänkään suuremmalla suomalaisella operaattorilla menee näin (testattu Telialla (AS1759) ja FUNETilla).
Sen sijaan Twelve99:llä (AS1299, ent. Telia Carrier/TeliaSonera International Carrier) menee ilmeisesti Pariisiin (36ms Helsingistä), eli riippuu käytettävän operaattorin peeringien mukaan. Traceroutella selviää.

IP-osoitteiden näyttäminen huuhaata ei ole mitenkään uusi juttu.
En ole juurikaan tutustunut Quad9:iin, joten en tiedä mitä IP:tä näyttävät noissa DNS-leak-testeissä. Näyttääkö 9.9.9.9 vai jotain muuta (todennäköisempi vaihtoehto)?
Napsauta laajentaaksesi...
Mikäs tuo TREX on ?

Mulla dnsleaktest ilmoittaa ISP:ksi Woodynet.IP osoite ei tosiaan ole 9.9.9.9 vaan "normaalimpi" osoitemuoto. Nyt aloin vähän miettimään että mikähän homma tässä nyt on kun quad9 ei mainita missään kun tuota woodynettiä googlettelee. quad9 osoitteet on kyllä käytössä, mutta tulokset on nyt jotain ihan muuta mitä pitäis...

Ehkä tuo edgen sekoilu johtuu osittain myös tästä kun nyt meni koko homma vain entistä sekavemmaksi...
 
Pah0lain3 sanoi:
Mikäs tuo TREX on ?

Mulla dnsleaktest ilmoittaa ISP:ksi Woodynet.IP osoite ei tosiaan ole 9.9.9.9 vaan "normaalimpi" osoitemuoto. Nyt aloin vähän miettimään että mikähän homma tässä nyt on kun quad9 ei mainita missään kun tuota woodynettiä googlettelee. quad9 osoitteet on kyllä käytössä, mutta tulokset on nyt jotain ihan muuta mitä pitäis...

Ehkä tuo edgen sekoilu johtuu osittain myös tästä kun nyt meni koko homma vain entistä sekavemmaksi...
Napsauta laajentaaksesi...

TREX on internetin liikenteen vaihtopiste (ISP:t vaihtaa liikennettä siellä toistensa kanssa): TREX Regional Exchanges
 
FireExit sanoi:
TREX on internetin liikenteen vaihtopiste (ISP:t vaihtaa liikennettä siellä toistensa kanssa): TREX Regional Exchanges
Napsauta laajentaaksesi...
Okei, kiitos.

Laitoin quad9:lle sähköpostia ja kysyin tosta woodynet hommasta kun kaikki testisivut kaikilla koneilla tarjoaa ISP:ksi vain tuota Woodynet nimeä, eikä woodynetissä mikään viittaa omien hakujen mukaan quad9 palveluun...kai ? Katsotaas jos sieltä joku kerkiäisi joskus yhden kerran ummikolle vastailemaan joskus.

Jos jollain on quad9 käytössä niin vois kokeilla tehdä dnsleaktest.com sivulla testin ja kertoa mitä se tarjoaa ISP kohdalla vaihtoehdoksi.



Edit, tulikin ihan hemmetin nopeaa vastaus sieltä
Quad9 does not own our own IP addresses. We utilize the addresses provided by our upstream providers: PCH.net (formerly WoodyNet), GSL, and i3D.

In this case, WoodyNet means that you're using Quad9 if that's what you're seeing on a dns leak test.
Napsauta laajentaaksesi...

Eli, ilmeisesti se on ihan ok että dnsleaktest testisivu näyttää ISP kohdalla Woodynet.
Onks tuo nyt sitten hyvä vai huono juttu muuten että eivät omista itse tuota ?
 
Viimeksi muokattu:
Pah0lain3 sanoi:
Mulla dnsleaktest ilmoittaa ISP:ksi Woodynet.IP osoite ei tosiaan ole 9.9.9.9 vaan "normaalimpi" osoitemuoto. Nyt aloin vähän miettimään että mikähän homma tässä nyt on kun quad9 ei mainita missään kun tuota woodynettiä googlettelee. quad9 osoitteet on kyllä käytössä, mutta tulokset on nyt jotain ihan muuta mitä pitäis...
Napsauta laajentaaksesi...

Ilmeisesti Quad9 hyödyntää anycastia, joka valitsee ulkoisen-IP:si mukaan lähimmän palvelimen reitin lyhyyden mukaan. Eli suomalaisella IP-osoitteella saat DNS-palvelimen, joka todennäköisesti Suomessa/(latenssin perusteella) mahdollisimman lähellä Suomea (tämä siis sen takia, että client<->DNS -välinen latenssi olisi mahdollisimman pieni).
Quad9 käyttää palveluntarjoajanaan ainakin Suomen palvelimessaan (tai päätteessään) AS42:ta, joka peeraa TREXissä. Jos whoissaat saamasi WoodyNet-IP:n vaikkapa täällä, niin kohdassa "Origin AS" tulisi lukea "AS42" ja kuvauksessa "WoodyNet".
Tämän perusteella väitän DNS-liikenteen ohjautuvan 9.9.9.9:stä jonnekin AS42:n palvelimeen (WoodyNet), jonka takia DNS-leak yms. testeissä DNS-osoitteen palveluntarjoaja näkyy WoodyNettinä.
Sama juttu minulla Cloudflaren kanssa: vaikka olen määrittänyt DNS-osoitteekseni 1.1.1.1, niin liikenne ohjautuu siitä Cloudflaren suomipalvelimelle, ja oikea DNS-osoitteeni on 162.158.237.14.

Toivottavasti selvensi pohdintaa.
 
Pikkis sanoi:
Ilmeisesti Quad9 hyödyntää anycastia, joka valitsee ulkoisen-IP:si mukaan lähimmän palvelimen reitin lyhyyden mukaan. Eli suomalaisella IP-osoitteella saat DNS-palvelimen, joka todennäköisesti Suomessa/(latenssin perusteella) mahdollisimman lähellä Suomea (tämä siis sen takia, että client<->DNS -välinen latenssi olisi mahdollisimman pieni).
Quad9 käyttää palveluntarjoajanaan ainakin Suomen palvelimessaan (tai päätteessään) AS42:ta, joka peeraa TREXissä. Jos whoissaat saamasi WoodyNet-IP:n vaikkapa täällä, niin kohdassa "Origin AS" tulisi lukea "AS42" ja kuvauksessa "WoodyNet".
Tämän perusteella väitän DNS-liikenteen ohjautuvan 9.9.9.9:stä jonnekin AS42:n palvelimeen (WoodyNet), jonka takia DNS-leak yms. testeissä DNS-osoitteen palveluntarjoaja näkyy WoodyNettinä.
Sama juttu minulla Cloudflaren kanssa: vaikka olen määrittänyt DNS-osoitteekseni 1.1.1.1, niin liikenne ohjautuu siitä Cloudflaren suomipalvelimelle, ja oikea DNS-osoitteeni on 162.158.237.14.

Toivottavasti selvensi pohdintaa.
Napsauta laajentaaksesi...
Kyllä taidat olla ihan oikeassa, sain heiltä samantien vastauksen sähköpostiin jonka kerkesin jo editoida tuohon ylempään kirjoitukseeni.
 
1635179645455.png

Adguard non-filtering DoQ, ping average 11ms komentokehoitteessa. DNS Jumper 4-6ms?
Eikö Adguardilla ole palvelinta Suomessa?
 
Millä tota liikennöintiä pystyy tutkailemaan paremmin kuin pelkällä dnsleaktest testisivulla esimerkiksi linuxin komentorivillä ? Että näkis miten tuo se oma liikenne kiertää ja juuri näitä millisekunti vaihteluita.

Ihan laillisesti kuitenkin, ei ole tarvetta millekkään muulle. tcpdump ei tähän sovellu ?
 
Pah0lain3 sanoi:
Millä tota liikennöintiä pystyy tutkailemaan paremmin kuin pelkällä dnsleaktest testisivulla esimerkiksi linuxin komentorivillä ? Että näkis miten tuo se oma liikenne kiertää ja juuri näitä millisekunti vaihteluita.

Ihan laillisesti kuitenkin, ei ole tarvetta millekkään muulle. tcpdump ei tähän sovellu ?
Napsauta laajentaaksesi...
Jos tarkkaa tietoa haluat, niin pistä vaikka Wireshark päälle ja filtteröi DNS liikenne?
 
=JP= sanoi:
Jos tarkkaa tietoa haluat, niin pistä vaikka Wireshark päälle ja filtteröi DNS liikenne?
Napsauta laajentaaksesi...
En osaa käyttää sitä :) , ajattelin vähän jotain drill kaltaista komentoa vain komentoriville. Toki vois tietenkin tuon wiresharkin ottaa jälleen käyttöön ja kokeilla. Se tuntuu vähän turhan rajulta vaan tähän omaan käyttöön.

Laitoinki tuon wiresharkin päälle, kiitos. Tuo rivien selvittely onkin sitte ihan oma juttunsa.
 
Viimeksi muokattu:
Pah0lain3 sanoi:
Millä tota liikennöintiä pystyy tutkailemaan paremmin kuin pelkällä dnsleaktest testisivulla esimerkiksi linuxin komentorivillä ? Että näkis miten tuo se oma liikenne kiertää ja juuri näitä millisekunti vaihteluita.

Ihan laillisesti kuitenkin, ei ole tarvetta millekkään muulle. tcpdump ei tähän sovellu ?
Napsauta laajentaaksesi...
Jos oikein ymmärsin mitä etsit, niin mtr voi olla etsimäsi työkalu, olettaen että DNS-osoite ei vaihtele.
 
NextDNS palveluun ilmestynyt tuollainen "AI-Driven Threat Detection" juttu. Beta tällä hetkellä ja aika vähän löytyy tarkempaa tietoa.



AI-Driven Threat Detection - Beta

Just saw this update. Now NextDNS really lives up to it's name as "next-gen" DNS 😍 Any more info or documentation how it works? Seems it's similar to Cisco Umbrella that also collects lots of…
help.nextdns.io help.nextdns.io
 
Cloudflarelta tietoa tuosta Applen iCloud Private Relay palvelusta.
blog.cloudflare.com

iCloud Private Relay: information for Cloudflare customers

iCloud Private Relay is a new Internet privacy service from Apple that allows users to connect to the Internet and browse with Safari in a more secure and private way. Cloudflare is proud to work with Apple to operate portions of Private Relay infrastructure
blog.cloudflare.com blog.cloudflare.com

Applen dokumentti:
iCloud Private Relay Overview
Learn how Private Relay protects 
 users’ privacy on the internet
 
Viimeksi muokattu:
Otin nyt tuon iCloud Private Relay kunnolla testiin. NextDNS on edelleen käytössä (pfSense), mutta ei suodata Safarin liikennettä.

AdGuard for Mac versio piti ottaa pois käytöstä ja tilalle AdGuard for Safari.

By default, AdGuard uses the "default route" which disables iCloud Private Relay.
Currently, AdGuard and iCloud Private Relay cannot work at the same time. AdGuard cannot block ads because iCloud Private Relay encrypts traffic before AdGuard can filter network connections. When iCloud Private Relay is active, any filtering (including local filtering) becomes impossible. Thus, AdGuard can't filter traffic or perform DNS filtering in Safari. Yet, AdGuard still filters traffic in other browsers. To keep using iCloud Private Relay, consider installing AdGuard for Safari.

As a result, AdGuard can't work together with iCloud Private Relay and Mail.app privacy features:
  1. iCloud Private Relay is applied to connections at the library level - before they reach the socket level, where AdGuard operates.
  2. iCloud Private Relay uses QUIC, which AdGuard can't filter in filtered apps because HTTP/3 filtering is not yet available.
  3. As AdGuard blocks QUIC, including iCloud Private Relay traffic - otherwise, ad blocking is impossible.
  4. When you use iCloud Private Relay and switch AdGuard into the "split-tunnel" mode, you can't open websites in Safari.
  5. To work around this issue for Monterey, we apply the "default route" rule. When Private Relay sees that rule, it disables itself automatically.
    So, AdGuard works seamlessly on Monterey, but iCloud Private Relay gets disabled.

iCloud Private Relay and AdGuard | AdGuard Knowledgebase

AdGuard
kb.adguard.com kb.adguard.com

Edit: NextDNS hallinnassa on myös ilmoitus tuosta iCloud Private Relay käytöstä.

1646320231376.png
 
Viimeksi muokattu:
Reilu viikko nyt ollut tuo iCloud Private Relay käytössä. Muutamia kertoja on ollut pätkimistä, eli ei pääse Safarilla jollekkin sivulle. Korjaantunut kun sulkee Safarin ja kokeilee uudestaan.
Mitään sijaintiin liittyviä ongelmia ei ole ollut.

Tuossa on siis kaksi palvelinta.

1647151078578.png


Relay 1 (ingress proxy): Tämä on Applen palvelin
Relay 2 (egress proxy): Tämä on Cloudflaren palvelin

Otin pfSensestä Packet Capturen:
07:32:26.284766 IP 192.168.1.13.64528 > 17.248.150.198.443: UDP
Eli kyseessä UDP liikennettä (QUIC)

QUIC - Wikipedia

en.wikipedia.org en.wikipedia.org

Suomesta kun tuota käyttää niin tuossa tulee ylimääräinen lenkki. Tuo Applen ingress proxy palvelin (17.248.150.198) on nähtävästi Ruotsissa ja Cloudflaren egress proxy palvelin sitten Suomessa.
Tuo iCloud Private Relay palvelu on vielä beta. Täytyy odotella, että saavat sen valmiiksi ja miettiä sitten, että ottaako käyttöön. Lähinnä tuo satunnainen pätkiminen Safarilla häiritsee niin en jatka tuon käyttöä.

Edit: Tarkistin vielä WireSharkilla niin tuo liikenne Client <-> Applen palvelin käyttää tuota QUIC. Applen IP vaihtui kun käytin iCloud Private Relay alhaalla.
1647154479279.png
 
Viimeksi muokattu:
Kumpikohan näistä dns palveluista olisi parempi ja luotettavampi. Nextdns, vai Adguard dns, molemmista löytyy ristiriitaista tietoa, tuosta nextdns palvelusta väitetään redditissä, että olisi kuolemassa ja hylätty. Sitten taas tuota Adguard dns palvelua väitetään venäläiseksi ja epäluotettavaksi.
 
Mikkis78 sanoi:
Kumpikohan näistä dns palveluista olisi parempi ja luotettavampi. Nextdns, vai Adguard dns, molemmista löytyy ristiriitaista tietoa, tuosta nextdns palvelusta väitetään redditissä, että olisi kuolemassa ja hylätty. Sitten taas tuota Adguard dns palvelua väitetään venäläiseksi ja epäluotettavaksi.
Napsauta laajentaaksesi...

Eli haet just sellasta DNS-pavelua, jossa on noita suodatuksia?
 
Mikkis78 sanoi:
Kumpikohan näistä dns palveluista olisi parempi ja luotettavampi. Nextdns, vai Adguard dns, molemmista löytyy ristiriitaista tietoa, tuosta nextdns palvelusta väitetään redditissä, että olisi kuolemassa ja hylätty. Sitten taas tuota Adguard dns palvelua väitetään venäläiseksi ja epäluotettavaksi.
Napsauta laajentaaksesi...
Itse ottaisin NextDNS:n ja käyttäisin sitä niin kauan kun palvelu on hengissä. Se että sitä ei kehitetä jatkuvasti ei kuitenkaan tarkoita että palvelu olisi kuolemassa. NextDNS:n kehitys tapahtuu miltei kahden henkilön voimin, jotka tekevät sitä päivätöiden yms elämän ohella. On täysin mahdollista että projekti kuolee aikataulusyistä, mutta siihen asti en olisi huolissaan. DNS:n jos minkään saa vaihdettua hetkessä. :)
 
NextDNS palvelua kanssa suosittelen. Reilu vuoden on ollut nyt käytössä ja en muista, että tuossa olisi ollut mitään ongelmia. AdGuard on vielä beta ja en ole sitä testannut.
 
Quad9 panostaa DNS-viiveisiin tekemällä yhteistyötä i3D.net-palvelun kanssa:

Quad9 bolsters its DNS coverage with i3D.net’s global network | Quad9

i3D.net’s low-latency network enables a better experience for Quad9 users. We can attribute about 30 million blocking events in the past month to these i3D.net sites.
www.quad9.net www.quad9.net

Luvassa on siis uusia eurooppalaisia DNS-palvelimia luultavasti näissä paikoissa: Locations
 
Onko Nextdns mahdollista saada toimimaan tp linkin m5 purkkien kanssa?, ei millään meinaa onnistua. Huawei b818 on siis modeemina, mikä on sillatussa tilassa ja yksi m5 purkeista reitittimenä ja 2 muuta purkkia langallisina sen perässä.
 
mikajh sanoi:
Pitäisi onnistua ainakin linked ip -menetelmällä (ja DDNS:llä), mutta tuo taas vaatinee julkisen IPv4:n, onko sellainen käytössä?
Napsauta laajentaaksesi...
Julkista ip:tä ei ole ainakaan vielä käytössä, eli siis täytyykö muuttaa jotain asetuksia tuosta Huaweista, vai molemmista?.
 
Mikkis78 sanoi:
Julkista ip:tä ei ole ainakaan vielä käytössä, eli siis täytyykö muuttaa jotain asetuksia tuosta Huaweista
Napsauta laajentaaksesi...
Riippuu operaattorista ja sen palvelusta. Mahdollisesti selviää APN:n vaihdolla Huawein käyttämään profiiliin, ja sitten se DDNS viritys viimeiseksi
 
mikajh sanoi:
Riippuu operaattorista ja sen palvelusta. Mahdollisesti selviää APN:n vaihdolla Huawein käyttämään profiiliin, ja sitten se DDNS viritys viimeiseksi
Napsauta laajentaaksesi...
Tilasin Elisalta tuon julkisen ip:n ja vaihdoin Huaweihin tuon apn:n, mutta tuntuu hitammalta ja jotenkin "tahmaa" yhteys tuon julkisen ip:n kanssa.
 
Mikkis78 sanoi:
tuntuu hitammalta ja jotenkin "tahmaa" yhteys tuon julkisen ip:n kanssa
Napsauta laajentaaksesi...
Voi olla todellista tai sitten ei, mutta tuskin se Elisasta johtuu, vaan siitä että nyt palomuurisi saa oikeasti hommia torjua koputtelijoita

EDIT: Tällä voi reittien alkupäätä Elisan osuuden loppuun asti testata, onko reitityksessä olennaisia eroja:
traceroute ip4.me
Windows: tracert ip4.me
 
Viimeksi muokattu:
escalibur sanoi:
Quad9 panostaa DNS-viiveisiin tekemällä yhteistyötä i3D.net-palvelun kanssa:

Quad9 bolsters its DNS coverage with i3D.net’s global network | Quad9

i3D.net’s low-latency network enables a better experience for Quad9 users. We can attribute about 30 million blocking events in the past month to these i3D.net sites.
www.quad9.net www.quad9.net

Luvassa on siis uusia eurooppalaisia DNS-palvelimia luultavasti näissä paikoissa: Locations
Napsauta laajentaaksesi...

Mahtava homma, koska ainakin itsellä DNA:lla on Quad9 pingit nousseet kuun vaihteessa yli 100ms. Ruotsiin asti 20ms ja siitä hyppää ties mihin 100ms hopilla. Telialla sentään ohjautuu TREXin palvelimelle.

ping-year.png
 
Itsellä Quad9/CloudFlare/Google -nimipalvelimet ovat aiheuttaneet viivettä kun kyselyjä tulee kerralla paljon. Olen siirtynyt kompromissina käyttämään oman operaattorini (DNA) nimipalvelimia, mutta niissä taas tulee virheitä, mm. sellaisissa aika oleellisissa nimissä kuin :

- pubmed.ncbi.nlm.nih.gov
- www.ncbi.nlm.nih.gov

Quad9/CloudFlare/Google nimipalvelimet osaavat palautta osoitteet noihin nimiin oikein. En kuitenkaan haluaisi siirtyä käyttämään ym. palvelimia koko aikaa kaikissa kyselyissä niiden viiveiden takia.

Yritin kiertää ongelmaa käyttämällä kymmentä samanaikaista nimipalvelinta Windowsin Acrylic DNS Proxy -ohjelman kautta, mutta jostain syystä se valitsee kuitenkin vastaukseksi 1. asetetun DNS-palvelimen (DNA:n 62.241.198.245) vastauksen, joka on "DNS address could not be found. ". Eli Acrylix DNS Proxy ei ainakaan osaa ohittaa ongelmaa, vaikka DNA:n nimipalvelimet vastaavat noihin yo. osoitteisiin ajallisesti viimeisinä (eli Google/Cloudflare/Quad9 vastaukset saapuvat Acrylic DNS:lle ensimmäisenä ja sisältävä oikean osoitetiedon).

Onko mahdollista kiertää tätä ongelmaa Windowsissa järkevästi jonkin toisen paikallisen, välittävän/kyselevän/cachettavan DNS-välitysohjelmiston avulla?

DNS-välitysohjelmisto kyselisi samanaikaisesti heti kaikilta asetetuilta nimipalvelimilta haluttua nimeä, ja käyttäisi sitä, mikä ensimmäisenä saadaan, joka EI ole "not found" -vastaus, vaan oikea reitittyvä osoite? Toki edellyttäisi hieman älykkyyttä softalta, mutta en kuvittelisi että tuollainen olisi ihan mahdoton.

Tietääkö joku ohjelmaa, joka hoitaisi Windows -puolella usean samanaikaisen nimipalvelimen kyselyn ja tulosten cachettamisen älykkäästi ja toimivasti?

 
halcyon sanoi:
Itsellä Quad9/CloudFlare/Google -nimipalvelimet ovat aiheuttaneet viivettä kun kyselyjä tulee kerralla paljon.
Napsauta laajentaaksesi...

Oletkos koskaan koittanut ajaa esim isompaa määrää rDNS hostname lookup kyselyitä. Esim. logista kaikkien IP osoitteiden selvittäminen nimiksi, eli vaikka muutamia miljoonia lookuppeja. Varsinkin noi ilmaiset palvelut tykkää siitä aikalailla pahaa, myös ISP:n palvelimet alkaa usein nikottelemaan jos noita työntää sinne vauhdilla tai lakkaavat kokonaankin vastaamasta joksikin aikaa. Eivät sentään vielä abusesta ole koskaan ottaneet yhteyttä.

Joskus riittää jopa että on joku isompi mesh / p2p / DHT verkko päällä ja unohtaa vaikka iftopin tai tcpdumpin käyntiiin (reverse lookupin kanssa), joka tekee kaikille paketeille lookupit. -> Boom, DNS hajoaa hetken päästä konaan. Tuolloin vauhti ei ole päätä huimaava, muutama sata pyyntöä sekunnissa, mutta se jatkuu loputtomasti tappavan tasaisena.
 
Viimeksi muokattu:
ztec sanoi:
Oletkos koskaan koittanut ajaa esim isompaa määrää rDNS hostname lookup kyselyitä.
Napsauta laajentaaksesi...

Noita tullut lähinnä tehtyä kun tehnyt nimipalvelinten testaamista ja mukana verrokkina olleet nuo isot julkiset. En ole suoraan sanoen mennyt lokeja läpi, katsoen miten viive on muuttunut kyselyiden kasvaessa. Kiitos vinkistä.

 
Nextdns ilmeisesti lakkasi toimimasta kokonaan kaikissa laitteissa eilen, suodatuslistoilla ei merkitystä, eikä muillakaan säädöillä. Testasin tällä sivulla Ad Blocker Test
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
259 090
Viestejä
4 501 489
Jäsenet
74 328
Uusin jäsen
Arttu1337

Hinta.fi

Back
Ylös Bottom