Publikus DNS szervereket jelentett be a Google

Google

A Google a "Make the web faster" erőfeszítésének részeként publikus DNS szervereket jelentett ma be kísérleti jelleggel. A szolgáltatás neve: Google Public DNS. A jelszavak: sebesség, biztonság és érvényesség (itt: a megfelelő oldalt adja vissza, nincs szűrés, blokkolás, elgépelés esetén nincs átirányítás). A szerverek IP címei: 8.8.8.8 és 8.8.4.4

[ Bejelentés | Mi a Google Public DNS? | Beállítási útmutató ]

( numen v | 2009. 12. 03., cs – 21:43 )

végre egy DNS, aminek meg tudom jegyezni a címeit…

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Google (8.8.8.8):

digg.com        42 msec
facebook.com    42 msec
flickr.com      43 msec
yahoo.com       41 msec
google.com      54 msec
altavista.com   44 msec

OpenDNS (208.67.222.222):

digg.com        46 msec
facebook.com    45 msec
flickr.com      46 msec
yahoo.com       44 msec
google.com      45 msec
altavista.com  182 msec

--
trey @ gépház

ez inspirált egy kis gányolásra:

digbench.sh

akit érdekel, futtatgassa. 20-szor futtat kérést, aztán abból átlagol, de be lehet állítani más számra is, illetve hogy ne csak az átlagot írja ki. lásd OPTIONS. nekem:


Google Public DNS (8.8.8.8):
digg.com: 24 ms
facebook.com: 24 ms
flickr.com: 25 ms
yahoo.com: 25 ms
google.com: 24 ms
altavista.com: 24 ms

Google Public DNS (8.8.4.4):
digg.com: 25 ms
facebook.com: 25 ms
flickr.com: 25 ms
yahoo.com: 25 ms
google.com: 25 ms
altavista.com: 25 ms

OpenDNS (208.67.222.222):
digg.com: 38 ms
facebook.com: 37 ms
flickr.com: 39 ms
yahoo.com: 38 ms
google.com: 37 ms
altavista.com: 37 ms

OpenDNS (208.67.220.220):
digg.com: 37 ms
facebook.com: 37 ms
flickr.com: 37 ms
yahoo.com: 38 ms
google.com: 37 ms
altavista.com: 37 ms

szerintem.

Nalam akarhany futtatasbol erre fut. Bár mindig máshol következik be az alábbi hiba. Ha jól sejtem ez abból fakad, hogy az egyik query nem fejeződik be, ezért " " lesz az érték, amit nem tud az int-hez hozzáadni.


Google Public DNS (8.8.4.4):
digg.com: 30 ms
./digbench.sh: line 61: 0 + : syntax error: operand expected (error token is "+ ")

Már csak azt lenne jó tudni, hogy minek/kinek a sara ...

Nem a bash a gond. Látszik, hogy az előző sort kiszámolta.

Egyszerűen csak annyi, hogy a 20 egymasutani queryből az egyik nem sikerül. És akárhányszor futtatom mindig elszáll valamelyik query, függetlenül a dns szervertől. Azt próbálom most kiderítgetni, hogy kinek a hibája? Gép, router, szolgálgató, stb ...

Nálam egyértelműen a google nyert:

Google Public DNS (8.8.8.8):
digg.com: 21 ms
facebook.com: 20 ms
flickr.com: 23 ms
yahoo.com: 20 ms
google.com: 25 ms
altavista.com: 36 ms
hup.hu: 21 ms

Google Public DNS (8.8.4.4):
digg.com: 20 ms
facebook.com: 21 ms
flickr.com: 20 ms
yahoo.com: 20 ms
google.com: 21 ms
altavista.com: 22 ms
hup.hu: 20 ms

OpenDNS (208.67.222.222):
digg.com: 35 ms
facebook.com: 34 ms
flickr.com: 34 ms
yahoo.com: 34 ms
google.com: 34 ms
altavista.com: 34 ms
hup.hu: 33 ms

OpenDNS (208.67.220.220):
digg.com: 34 ms
facebook.com: 33 ms
flickr.com: 33 ms
yahoo.com: 34 ms
google.com: 34 ms
altavista.com: 33 ms
hup.hu: 34 ms

Nagy Péter
www.konquer.org

Nyilván minden terhes kismama elkezd majd google dns-re migrálni ha a hotspotos cafeban az ISP dns meghal. Nem teljesen értem hogy pontosan kinek szól a szolgáltatás. Annak a szűk rétegnek akinek hasznára válhat, már van a tarsolyában pár ilyen cím. (nem csak az opendns létezik).

szerk. elírás

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

( adriankoooo | 2009. 12. 03., cs – 23:10 )

Szlovakia, Parkany:

adrian-macbook:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=239 time=44.948 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=239 time=47.615 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=239 time=43.110 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=239 time=43.467 ms

adrian--macbook:~$ ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 56 data bytes
64 bytes from 8.8.4.4: icmp_seq=0 ttl=242 time=34.462 ms
64 bytes from 8.8.4.4: icmp_seq=1 ttl=242 time=34.565 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=242 time=34.796 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=242 time=35.168 ms

( djsilas | 2009. 12. 03., cs – 23:44 )

st1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=247 time=22.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=247 time=22.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=247 time=22.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=247 time=22.0 ms

st1:~# dig @192.168.0.1 weblap-tarhely.hu
;; Query time: 20 msec

st1:~# dig @4.2.2.2 weblap-tarhely.hu
;; Query time: 59 msec

st1:~# dig @8.8.8.8 weblap-tarhely.hu
;; Query time: 102 msec

Úgy látom, még ráérek a cserével :P Tapasztalatok, gyorsaság, stabilitás, stb, stb... Egyelőre van jobb :P

( numen v | 2009. 12. 04., p – 01:13 )

Azt hiszem, a localhostra most telepített dnsmasq az esetek többségében azért verni fogja sebességben és megbízhatóságban :)
Nem nézek én annyi weboldalt, hogy lokális cache-ből ne szolgálhassam ki cca. 90%-át…

01:05:07 balint@gombocartur:~$ dig google.com | grep "Query time"
;; Query time: 64 msec
01:05:12 balint@gombocartur:~$ dig google.com | grep "Query time"
;; Query time: 0 msec 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( anr | 2009. 12. 04., p – 01:30 )

apt-get install pdnsd

--
Live free, or I f'ing kill you.

A PowerDNS az első kettőben nagyon rendben van...
08:48:09 mik@miktmp$./digbench.sh 


(saját windows caching-only 1. futás):
digg.com:       6 ms
facebook.com:   2 ms
flickr.com:     2 ms
yahoo.com:      2 ms
google.com:     2 ms
altavista.com:  4 ms

(sahát pdns-recursor 1. futás):
digg.com:       0 ms
facebook.com:   0 ms
flickr.com:     6 ms
yahoo.com:      0 ms
google.com:     1 ms
altavista.com:  8 ms

08:48:15 mik@miktmp$./digbench.sh
(saját windows caching-only 2. futás):
digg.com:       0 ms
facebook.com:   0 ms
flickr.com:     0 ms
yahoo.com:      0 ms
google.com:     0 ms
altavista.com:  0 ms

(sahát pdns-recursor 2. futás):
digg.com:       0 ms
facebook.com:   0 ms
flickr.com:     0 ms
yahoo.com:      0 ms
google.com:     0 ms
altavista.com:  0 ms

pdns cache törlés után:
digg.com:       23 ms
facebook.com:   2 ms
flickr.com:     23 ms
yahoo.com:      19 ms
google.com:     1 ms
altavista.com:  3 ms

Persze, nem ugyanaz a célterület mint OpenDNS-nél vagy GoogleDNS-nél.

( uid_16591 | 2009. 12. 04., p – 04:26 )

ha vegul mondjuk par even belul minden a google kezeben osszpontosul majd akkor nem tudom milyen securityrol beszelnek ezek...

ok sorry, megiscsak 4 ora van, ez csak valami felparanoid kirohanas volt. :c

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

( vtechun | 2009. 12. 04., p – 08:49 )

é meg bírtam a BME DNS szervereit is jegezni :) ha kell még minidg a torpapa.eik.bme.hu IP-jét pingeltetem

( Hiena v | 2009. 12. 04., p – 09:03 )

Erdekes. Szep es jo kezdemenyezes, egyetlen problemam vele, hogy a paranoiam picit megszolalt.
Ugye eddig is sok adatot adunk ki a googlenek, de most mar ontudatlanul is kiadhatjuk. Ugyebar eddig a google a preferenciankat a keresoszavainkbol, es korabbi kereseseinkbol tudta kimagozni. Mostmar azokat az oldalakat is "latni" fogja amiket nem a keresojukon keresztul nyitunk meg.
Mindenesetre hasznalni fogom, dnsmask es request stat poisoningon keresztul, max. a google ads "En kicsi ponim" hirdeteseket fog feldobni.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Most is azonosítható. Webezés közben a legtöbb ember rendszeresen indít a Google felé azonosítható kéréseket, ha mást nem, reklámokat. Így ha naponta változik az IP-címed, elég egyértelműen beazonosítható, hogy mi az IP címed. (Ha néhány óra különbséggel ugyanarról az IP címről ugyanaz a felhasználó indít kérést, akkor valószínűsíthető, hogy közte is ugyanaz volt az IP címe, nem kétszer váltott néhány órán belül, és véletlenül ugyanazt kapta meg.)

Ó, hát "joceg", tuti igazat mond :P
Egyébként szerintem az utsó 24 óra már épp elég reprezentatív nekik, amíg nem egyénekre, csak csoportokra akarják bontani a felhasználóikat.
És amíg az információkat marketingcélokra akarják felhasználni, addig az bőven elég, mert a hirdetést nem úgy adják fel (remélem), hogy "ez jelenjen meg Gipsz Jakabnak háromszor", hanem hogy jelenjen meg az iylen érdeklődésű embereknek. Google meg az utolsó 24 (?) óra alapján jól beskatulyáz mindenkit. Legalább tudni fogjuk, ha távollétünkben valaki több pornót nézett a gépen, mint mi :D

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

A Google a Nagy Testvér, dns cache poisoningot egy óra alatt detektál, a 24 órából fennmaradó 23 óra csak arra kell már nekik, hogy eltüntessék a felelősöket :P 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( skynetpro | 2009. 12. 04., p – 09:16 )

miért nem képesek egy normális domain nevet regisztrálni a szerverüknek? nem kéne megjegyezni az ip címet ;)

jah, pff. mondjuk ezzel a probléma megoldásához semmivel nem leszel közelebb, mivel magától nem fog bekerülni *minden* gép hosts fájljába, márpedig a beíráshoz emlékezned kell rá, szóval ezzel inkább csak bonyolítod (és akkor arról még nem beszéltem, hogy mekkora fasság ez az ötlet:D)...
szerintem.

( crown v | 2009. 12. 04., p – 10:20 )

Valaki osszehasonlitana pl. a UPC / T-MATAV / egyebek DNS server sebessegevel?

Mie' te nem tudod? Ugy jelenleg kb barmilyen oprendszer alatt add ki ezt a parancsot: 


nslookup lekerdezendo_nev_vagy_IP

- ez feloldja neked a jelenleg beallitott nevszerveren keresztul. 


nslookup lekerdezendo_nev_vagy_IP 8.8.8.8

- ez pedig a GDNS-en at. Es nyilvan, barmilyen egyeb nevszerveren keresztul is ugyanugy le tudod tesztelni, csak tudni kell hozza az adott nevszerver IP-jet, ehhez meg ez kell: 


nslookup -ty=ns t-home.hu
nslookup -ty=ns digi.net
nslookup -ty=ns pannongsm.hu

stb. Majd a valaszul kapott nevre is inditasz egy kereset 


nslookup ns1.pannon.hu

es meg is van a kivant (masodik parameterkent a 8.8.8.8 helyere irando) IP.

Az mas teszta, hogy egyre tobb szolgaltato nem hajlando kulso helyrol jovo kereseket nem a sajat zonaibol kiszolgalni - ilyenkor elhajt a francba.

dupe (reszletesebben: FF alatt akartam postolni, "Bekuldes" lenyomasa utan kifagy a FF. ujrainditasnal visszajon az post ablak, en meg naivan azt hittem, nem kuldte el, amit irtam, es elkuldtem ujra) Amugy masodjara is kifagyott a FF. Windows / 2 FF ablak / egyik ablak hup.hu, masikban meg egy Flex alkalmazas...

"Mondja maga marha, mondja maga marha, hogy mindent kétszer mond, hogy
mindent kétszer mond?" (Bocs)

Amúgy pedig: nslooklup -pal lekérdezek a helyi szolgáltatói nameservertől bármit. Ezzel a saját gépem memóriájába behúzom magát az nslookup-ot. Ezek után a 


$ time nslookup akarmi.hu
$ time nslookup akarmi.hu 8.8.8.8

parancsokkal kapok két időtartamot, amennyi ideig a kétféle (helyi/google-féle szerver) lekérdezés tartott. Jó (no jó: nagyvonalú) közelítéssel a két idő a kétféle szolgáltató elérésének és válaszának megérkezésének az idejét adja, így a különbségük már csak az, hogy én mennyi különbséget érzek a használatukban - azaz az én helyemről nézve egyik, vagy másik a gyors. Nyilván semmilyen méréshez nem elég egyet próbálkozni, nyilván az lenne az ideális, ha mindezt mondjuk single-user módban tennéd, hogy a saját géped egyéb terhelései ne nagyon zavarjanak, stb. Ez kb olyan, mint a glxgears. Nem mérőszám, de azért megnézi az ember - és vagy hisz abban, hogy az jó eredmény, vagy nem.

"Ugy jelenleg kb barmilyen oprendszer alatt add ki ezt a parancsot:"

még szerencse, hogy az indítórészben explicit szerepelt, hogy miért nslookup és nem dig.

szerintem.

Szerk: és igen, lehet használni erre a dig-et, sőt a "host -v" -t is, de nem véletlenül szerepelt az nslookup - ez ugyanis tudtomal az egyetlen eszköz, amit akár Windows-on is lehet használni (igaz, ott meg erre nem jó a time parancs - meggyőztél. Csak az a stílus...)

Az eredmény szempontjából valóban (szinte) teljesen mindegy az oprendszer. Ellenben a lényeg - feltett egy kérdést (amit többen is), amire én adtam egy választ (ezt hívtam indítónak). Mivel gőzöm nincs, hogy ki milyen oprendszert használ, az általam ismert 3-féle névszerverlekérdezi parancsból kiválasztottam azt az egyet, amelyikről *tudom*, hogy *X és W* környezetben is van. Leírom, hogyan kérdezzen. Ezek után jön valaki, és odaböffent egy hasznos infót, ami pontosabb eredményt ad, csak esetleg nem tud vele mit kezdeni a kérdés feltevője. És mivel nem a kérdés feltevőjének ad válaszul egy szerinte jobb eredményt produkáló módszert hanem nekem, ezzel jelzi, hogy amit írok baromság, "teljesen használhatatlan mérési módszer". Megmutatnád, hogy windowson hogy futtatsz dig-et vagy host-ot?

Leírom lassabban: "csak az a stílus ..."

mielőtt nagyon elájulsz az überkrosszplatform megoldásodtól (time nslookup akarmi.hu), írd be egy windows-os gépen, nálam ugyanis ez az output:

The system cannot accept the time entered.

ennyit erről.

a segítőkészség ("Mie' te nem tudod?") részét meg inkább hagyjuk, nem arra irányult a kérdés, hogy hogy lehet valamit cross-platform megoldani...

szerintem.

mielott nagyon elajulsz magadtol, javaslom a kovetkezot: olvasd vegig a szalat. Ugyanis a "mie" utan volt mas is. Valamint: amikor windows alatt begepelted, probaltal esetleg konstruktiv is lenni? Este ugyanis, amikor eszembe jutott, hogy win alatt nem jo a time - leven valami ezer eves hagyomany miatt az ido beallitasara szolgal, nem pedig futasi ido megmeresere, akkor:

a) ezt jeleztem is - asszem itt van kettovel e felett

b) a te morgolodasodnal tovabb is jutottam, ugyanis kicsit gondolkoztam, es arra jutottam, hogy elvben win alatt is jo lehet a time es nslookup. Mit szolsz ehhez? 


time < nul:
nslookup ...
time < nul:

Ki nem probaltam, de elvileg jo, hisz a time kiirja az aktualis idot (es az atiranyitas miatt fut tovabb, es nem allit be semmit), utana fut az nslookup, majd megint a time az immar uj aktualis idovel. Ki lehet vonni a kettot egymasbol, es meg is vagyunk.

c) a kerdes arra vonatkozott, hogy hogyan lehet megoldani. Te honnan tudod, hogy a kerdezo milyen oprendszer alatt kerdezi megoldani? Mert en sehonnan.

Viszont meg mindig nem valaszoltal arra, hogy milyen host es dig parancsokat futtatnal Windows alatt. Vagy mas szavakkal: segits nekem megmerni ezt a gguglis nevszerver sebesseget windows alatt, lecci!

Azt valtozatlanul nem ertem, hogy ha lemerem ugyanannak a programnak ket kulonbozo szerverrel valo kommunikaciojanak a futasi idejet, akkor a kulonbseg miert is nem a kivant eredmeny - mennyivel gyorsabban kommunikal egyikkel, vagy masikkal. Es hogy vilagos legyen, gyengebbek kedveert leirom: azert az nslookup-ot irtam, mert az cross-platform; valamint mert nekem az jobban kezreall, mint a dig; es nem utolsosorban elismertem, hogy nem tokeletes; te meg gorcsolsz itt mar miota, mert a te megoldasod mennyivel faszabb, ezert te mennyire uber vagy. Ugy van, most megnyugodtal?

én nem görcsölök, csak jeleztem, hogy szerintem nem megoldás a megoldásod, cserébe a kérdésre sem válasz, erre itt novellákat írsz nekem a cross-platformságról meg a modorról.

de hogy a legnagyobb hülyeségekre válaszoljak:
- semmivel nem mérném windows alatt. viszont egy livecd-t bedobni eltarthat akár 2 percig is. bár linkeltek valami benchmark progit lejjebb, gui-s!
- nem érted, hogy mi a probléma a time-os méréssel. csak annyi, hogy ilyen x ms nagyságrendű futásnál baromi nagy a zaj aránya, így semmi infót nem fog szolgáltatni a _lekérés_ tényleges sebességéről. max. elmondhatod, hogy hát igen, most ennyi ms alatt futott le a _parancs_, aztán levonhatod azt a (téves) következtetést, hogy ha az egyik nagyobb, mint a másik, akkor az első _lekérés_ gyorsabb volt. ez olyan, mintha az ember lábméretét a rajta lévő cipő hossza alapján határoznád meg kb.

azt a fasságot meg végképp nem tudom, honnan vetted, hogy én arra vágyok, hogy "az én megoldásom"-at ajnározd.

szerintem.

"mellesleg nem az indító részben szerepelt, hanem a te válaszodban."

Stimmel. 4-én déletlőtt feltette valaki a kérdést, én még aznap válaszoltam, rajtam kívül 8-ig a kutya nem akart/tudott válaszolni. Szerintem nem volt olyan nagy baj, hogy m,egtettem. De úgy látszik más másként vélekedik róla.

Koszi! ... bar ketlem, hogy ilyen trivialis lenne a DNS-t tesztelni. Nem ertek hozza, de en a DNS helyeben cache-elnem a cimet az elso hivas utan, ez a lekeres mar nem szimulalja mondjuk a valos hasznalatkori sebesseget. Gondolom, a DNS hangolasanal ok is kuzdottek rendesen a tesztelesen, ezert is csainaltak kulon eszkozt (mint kesobb lattam)

bervi digbench.sh-ját használtam, íme az eredmény:

Google Public DNS (8.8.8.8):
digg.com: 22 ms
facebook.com: 22 ms
flickr.com: 23 ms
yahoo.com: 22 ms
google.com: 26 ms
altavista.com: 23 ms

Google Public DNS (8.8.4.4):
digg.com: 23 ms
facebook.com: 22 ms
flickr.com: 22 ms
yahoo.com: 21 ms
google.com: 23 ms
altavista.com: 22 ms

Helyi DNS (195.111.2.2):
digg.com: 4 ms
facebook.com: 1 ms
flickr.com: 4 ms
yahoo.com: 0 ms
google.com: 0 ms
altavista.com: 2 ms

dnsmasq@localhost (127.0.0.1):
digg.com: 0 ms
facebook.com: 1 ms
flickr.com: 2 ms
yahoo.com: 2 ms
google.com: 2 ms
altavista.com: 3 ms

OpenDNS (208.67.222.222):
digg.com: 44 ms
facebook.com: 39 ms
flickr.com: 46 ms
yahoo.com: 45 ms
google.com: 41 ms
altavista.com: 61 ms

OpenDNS (208.67.220.220):
digg.com: 37 ms
facebook.com: 37 ms
flickr.com: 38 ms
yahoo.com: 40 ms
google.com: 38 ms
altavista.com: 36 ms

Majd később még összehasonlítom az otthoni kábelnetes dns szerverrel is.

( uid_16401 | 2009. 12. 04., p – 11:39 )

Ha jól tudom a nagyobb ISP-knek: Telekom, Invitel, UPC közvetlen peerje van a Google-hez.

( mauzi v | 2009. 12. 04., p – 12:01 )

8.8.8.8 ...

az 1-800-ERZSIKE mintájára már IP tartományt is lehet venni?
én meg éveket küzdök a RIPE-pal, hogy be tudjam röffenteni a kis szaros /24 subnetemet...

( azbest | 2009. 12. 04., p – 14:59 )

van egy tippem, hogy miért jó ez a google-nak:

ugye tele a net olyan oldalakkal, amiket csak azért regisztráltak be hogy ha véletlen elgépelnek valamit, akkor telenyomja a user képét reklámmal.

a google helyében az összes fel nem oldható cím esetén olyan reklámoldalra irányítanám a usert, ami a böngészési szokásainak megfelel.

másrészt a profilépítés (reklámozáshoz) is hatásosabb lehet, hisz így nem csak a google eszközöket és reklámokat mutató oldalakon, hanem minden általa látogatott oldal tartalma alapján lehet belőni, hogy milyen reklámra fogékony.

meg kell mondjam, ügyes

Miért, a Google-nek mi haszna van abból, hogy megnézed kispista reklámoldalát? Egyébként is azt írják, hogy nem irányítanak át.
A médiafogyasztási szokások figyelése tekintetében igazad van viszont.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( acidalcohol | 2009. 12. 04., p – 15:48 )

Eddig a 4.2.2.2 -t pingeltem mindig is tesztelésnél.. ez is egy dns valahol a neten. Mindig elérhető. A 8.8.8.8 könnyebben megjegyezhető.. azthiszem váltok :D Legalábbis elsődlegesség terén :D

( PunishR v | 2009. 12. 05., szo – 10:29 )

sajnos ez sem ad AAAA cimeket a googli szolgaltatasokhoz:( tud valaki whitelisted nst ami v6os ad guglihoz?

Igy van: 


$ host -t ns t-com.hu
t-com.hu name server ans1.t-online.hu.
t-com.hu name server ans0.t-online.hu.
$ host 8.8.8.8 ans0.t-online.hu.
Using domain server:
Name: ans0.t-online.hu.
Address: 195.228.240.85#53
Aliases: 

Host 8.8.8.8.in-addr.arpa not found: 5(REFUSED)
$ host 8.8.8.8 ans1.t-online.hu.
Using domain server:
Name: ans1.t-online.hu.
Address: 195.56.77.76#53
Aliases: 

Host 8.8.8.8.in-addr.arpa not found: 5(REFUSED)
$

Basszus, hát ezt írtam: ma egyre több szolgáltató:
- belső tartományból jövő kérés esetén megkeres nekem bármilyen külső adatot (mert ez a dolga)
- külső tartományból érkező kérésre viszony csak a saját adatbázisából szolgáltat (mert ez a dolga),

- ellenben ha kívülről jön a kérés, és nem a saját adatbázisából kéne válaszolnia, hanem mástól kéne kérdeznie (kívülről jövő, külső kérés), azt nem teszi meg: fordulj a saját szolgáltatód névszerveréhez. Az általam c'n'p-olt kimenetben ott is van a hibaüzenet, hogy elutasította a kérésemet (ebből tudható, amit nem írtam bele az eredeti hozzászólásba, hogy nem matáv-hálózatból kérdeztem).