Üdv!
Érdekes problémával szembesültem. Be van állítva 3 névszerver, nslookupban látszólag feloldják a kérést, pingeléskor és wgetnél sincs gond a feloldássalm, de például a lynx furcsán működik: http://google.hu -> betölt, http://help.prestashop.com -> http://szolgaltatocim.hu használata
ÉS sajnos ez PHP oldalon is létezik, tehát nem a kért oldal jön be, hanem a szolgáltató oldala. A névszerverekkel játszva sikerült azt elérni, hogy a google bejön, előtte még az sem, igazából nem is tudom mi befolyásolja hogy CSAK az bejön (lehet más is) a többi meg nem.
resolv.conf:
nameserver 195.228.240.249
nameserver 195.228.242.180
nameserver 84.2.46.1
nameserver 84.2.44.1
interfacesban is ilyen sorrendben vannak felsorolva (reboot nem történt még, ha nem muszáj nem kéne).
rndc flush megvolt, hátha az okozná, bind-et is újraindítottam, bár külső dns-t használok. Nincs jelenleg ötletem, mi okozná ezt.
Remélem tud valaki segíteni ebben.
Szerk.:
nameserver 2001:4c48:1::1
nameserver 2001:4c48:2::1
nameserver 84.2.44.1
nameserver 84.2.46.1
Jelenleg így használom, ezek mind a telekom szerverei, még nem megoldás a problémára.
- 2879 megtekintés
Hozzászólások
Azt hiszem volt már itt szó róla korábban, a 195.228-as NS-eket évekkel ezelőtt kukázta az axelero/t-köm. A 84-eseket használd csak.
A leírt hibát mondjuk nem igazán sikerült dekódolnom.
suckIT szopás minden nap! Perl script 11 millió forintért
- A hozzászóláshoz be kell jelentkezni
Ha kiszedem azok nélkül is produkálja (amúgy a 84.2.44.1 pl nem is érhető el, tehát csak a másik megy).
Tehát úgy néz ki a probléma, hogy beírom ezt:
# lynx http://help.prestashop.com/
[...]
http://www.******.hu/ használata
Például a google esetében:
# lynx http://google.com/
[...]
www.google.com süti: PREF=ID=8095e9e41eb3c90c:FF=0:TM=1311017743:LM=1311017743:S=Ht-aTPmWNjBVOqzq Engedjük? (Igen/Nem/Mindig/Soha)
Tehát míg ez első esetben nem találja meg a cél oldalt, és vmiért a szerver fő domainjére irányít, addig a második esetben simán betölt az oldal. nslookup-al lekérdezve azonban mindkét oldalt feloldja, wget-el is letölti, de például php-ból már ugyan ilyen elven működik, azaz file_get_contents("http://help.prestashop.com/"); kiírására a szolgáltató oldala jön be, a kért oldal helyett, viszont a google például itt is bejön (a google csak egy példa, ami működik)
- A hozzászóláshoz be kell jelentkezni
Nekem jó:
# lynx http://help.prestashop.com/
[...]
help.prestashop.com süti: sym=kchv1d1u7o7k Engedjük? (Igen/Nem/Mindig/Soha)
Nem biztos, hogy névfeloldási gondod van. A fentiekből nekem úgy tűnik, mintha a szolgáltató egy transzparens proxyval blokkolná az oldalt. Bár egy mezei internetszolgáltatónak ezt nem szabadna megtenni. Céges hálózatban talán elképzelhetőnek tartom, hogy van ilyen.
- A hozzászóláshoz be kell jelentkezni
Úgy jön be a szolgáltató oldala, hogy ez egy szerver gép, tehát a MI domainünk jön be, ezt rosszul írtam. Eddig ez a hiba nem volt, kérdéses mitől jött elő.
- A hozzászóláshoz be kell jelentkezni
A wget biztos, hogy rendesen letölti? Ennek kimenetét másold be, légyszives:
wget http://help.prestashop.com -O /dev/null
- A hozzászóláshoz be kell jelentkezni
# wget http://help.prestashop.com -O /dev/null
--2011-07-18 23:02:10-- http://help.prestashop.com/
help.prestashop.com feloldása... 213.186.52.66, 2001:4c48:2:a365:223:aeff:feff:564f
Csatlakozás a következőhöz: help.prestashop.com[213.186.52.66]:80... kapcsolódva.
HTTP kérés elküldve, várom a választ... 200 OK
Hossz: 3969 (3,9K) [text/html]
Mentés ide: ,,/dev/null"
100%[==========================================================================================================>] 3.969 --.-K/s idő 0s
2011-07-18 23:02:10 (284 MB/s) - ,,/dev/null" mentve [3969/3969]
Most így megpillantva az ipv6 címet, lehet olyan, hogy az bekavar neki? Bár ha már van ipv6 cím, akkor sem a mi szerverünk oldalát kéne feloldania rá...
De lehet itt lesz a bökkenő! Csak nincs ötletem mi
- A hozzászóláshoz be kell jelentkezni
"Bár ha már van ipv6 cím, akkor sem a mi szerverünk oldalát kéne feloldania rá..."
Például a hosts file-ba valamilyen oknál fogva beírtad a help.prestashop.com névhez a (DNS által adottal megegyező) francia IPv4-es címet, valamint a saját szervered IPv6-os címét is.
- A hozzászóláshoz be kell jelentkezni
Igen, tényleg az ipv6-tal lesz a gond. Ez a cím, amit felold (2001:4c48:2:a365:223:aeff:feff:564f), ez a whois szerint a Magyar Telekom hálózatában van. Ennek semmi köze nincsen a help.prestashop.com (213.186.52.66) szerverhez. Nekem a wget ezt nem is írja ki, csak az ipv4-est:
--23:17:29-- http://help.prestashop.com/
=> `/dev/null'
IP keresés help.prestashop.com... 213.186.52.66
Connecting to help.prestashop.com|213.186.52.66|:80... kapcsolódva.
HTTP kérés elküldve, várom a választ... 200 OK
Hossz: 3.969 (3.9K) [text/html]
100%[====================================>] 3.969 --.--K/s
23:17:29 (189.03 KB/s) - `/dev/null' saved [3969/3969]
Neked viszont feloldja azt a 2001:4c48:2:a365:223:aeff:feff:564f címet is, amit nem szabadna. Erre az ipv6-os címre nem csatlakozik a wget, mert az ipv4-est részesíti előnyben. A lynx és a PHP pedig az ipv6-ost részesíti előnyben és azért csatlakozik erre a Magyar Telekom hálózatában lévő szerverre.
Valami rosszul van beállítva a szerveren, mert a DNS-nek a 2001:4c48:2:a365:223:aeff:feff:564f címet nem szabadna visszaadnia.
- A hozzászóláshoz be kell jelentkezni
Ekkora marhát mint én :) Ez az ipv6 cím a mi címünk, és nemrég hozzáadtam a AAAA rekordot a domainünkhöz, és valószínűleg ettől. Viszont erre kellene egy megoldás, hogy azért ne erre oldja fel.
- A hozzászóláshoz be kell jelentkezni
Az az érdekes, hogy ha te csak hozzáadod a zónádhoz az AAAA rekordot, akkor a szervernek elvileg csak akkor szabadna visszaadni azt az ipv6 címet, hogy ha ahhoz a hostname-hez kéred le. Ha csak authoritatív a szerver, akkor más zónához tartozó kéréseket ki sem szabadna szolgálnia. De az /etc/resolv.conf-odból úgy látom, hogy a lekérésekhez nem a saját Bindodat használod, hanem a T névszerverét. Így viszont nem értem, hogy miért van ez. Ilyet még nem láttam. Megyek aludni. Holnap is ránézek a HUP-ra. Kiváncsi vagyok, hogy mi lesz ebből. :)
- A hozzászóláshoz be kell jelentkezni
Jól összetosztad a configod :)
1. resolv.conf szerkesztés után nem kell reboot.
2. Az interfacesből szedd ki a DNS szerverek címeit, az oda nem való.
3. resolv.conf -ba írd be: 8.8.8.8
összes többi IP-t commentezd ki # -vel.
4. bind service-t állítsd le, mert bekavart.
ping, stb a resolv.conf -ból keresi a DNS servereket, míg lynx valószínüleg a bind-ed kérdezné, de az meg nincs jól belőve.
5. Ha szerinted a bind tökjól működik, akkor:
127.0.0.1 legyen csak a resolv.conf-ban, vagy az az IP amin elérhető a szolgáltatás(bind).
A jelzett oldallal kapcsolatban konkrétan:
nick@host~$ dig help.prestasop.com
; <<>> DiG 9.7.3 <<>> help.prestasop.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53148
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;help.prestasop.com. IN A
;; Query time: 367 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jul 18 22:28:09 2011
;; MSG SIZE rcvd: 36
nick@host~$ nslookup help.prestasop.com
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find help.prestasop.com: NXDOMAIN
Nem nálad van a gond.
-
Debian Squeeze
- A hozzászóláshoz be kell jelentkezni
A topiknyitóban help.prestasop.com-ot írt, itt viszont már help.prestashop.com-ot.
- A hozzászóláshoz be kell jelentkezni
Az viszont elérhető. Francos typok. :)
-
Debian Squeeze
- A hozzászóláshoz be kell jelentkezni
Bocsi, tényleg elírtam :) Javítva.
Bind leállításával, valamint az interfaces és a resolv.conf szerkesztésével is ugyan az a jelenség!
- A hozzászóláshoz be kell jelentkezni
A resolv.conf-ban nincs search sorod?
- A hozzászóláshoz be kell jelentkezni
Nincs, azt már az elején kiszedtem
- A hozzászóláshoz be kell jelentkezni
Valami ötlet?
- A hozzászóláshoz be kell jelentkezni
tcpdump + wireshark + strace + dig?
- A hozzászóláshoz be kell jelentkezni
Konkrétabban? :)
Ilyen hálózatelemzéseket nem nagyon csinálok. Meg amúgy is, itt névfeloldási gond van, simán eléri például a wget, mert az az ipv4-et használja, viszont látszik, hogy az ipv6 címet is feloldja a mi gépünkre. Sajnos a PHP és a Lynx is az ipv6-ot részesíti előnyben. Az ipv6 letiltásával meg is szűnik a probléma. Természetesen szeretnénk használni az ipv6-ot, csak rá kellene jönni, mi okozza ezt a dns feloldási gondot.
- A hozzászóláshoz be kell jelentkezni
tcpdump-al és wireshark-al meg tudod nézni, hogy milyen hálózati kommunikációt is folytat a kliensed.
Honnan kéri le az IP-t és utána hova próbál kapcsolódni.
A többit rád bízom, hogy googlizd meg.
Ha itt egy kliens problémáról van szó, akkor meg kell mondani a kliensnek, hogy ne használjon IPV6-ot.
Links-nek meg lehet mondani, hogy ne használjon IPV6-ot ha jól látom:
http://linux.die.net/man/5/elinks.conf
connection.try_ipv4 [0|1] (default: 1)
Whether to try to connect to a host over IPv4. Note that if connection.try_ipv6 is enabled too, it takes precedence. And better do not touch this at all unless you are sure what are you doing. Note that you can also force a given protocol to be used on a per-connection basis by using an URL in the style of i.e. http4://elinks.or.cz/.
connection.try_ipv6 [0|1] (default: 1)
Whether to try to connect to a host over IPv6. Note that you can also force a given protocol to be used on a per-connection basis by using an URL in the style of i.e. http6://elinks.or.cz/.
- A hozzászóláshoz be kell jelentkezni
Tehát, tcpdump kimenetek + lynx:
HUP.HU - Van IPv6 címe:
13:00:22.242318 IP 84.2.35.84.32564 > 77.72.229.251.53: 4932 [1au] AAAA? hup.hu. (35)
13:00:22.284111 IP 77.72.229.251.53 > 84.2.35.84.32564: 4932- 0/3/3 (129)
13:00:22.284570 IP 84.2.35.84.11591 > 193.224.40.5.53: 10285 [1au] AAAA? hup.hu. (35)
13:00:22.285926 IP 193.224.40.5.53 > 84.2.35.84.11591: 10285*- 1/3/3 AAAA 2001:4c48:2:a33e::6 (157)
13:00:22.286982 IP 84.2.35.84.47685 > 194.38.96.80.53: 1061 [1au] A? hup.hu. (35)
WORMSNEVELDE.HU - Nincs IPv6 címe, elősször hívom meg lynxből:
13:02:23.523820 IP 84.2.35.84.12850 > 193.6.16.1.53: 25921 [1au] AAAA? wormsnevelde.hu. (44)
13:02:23.524813 IP 193.6.16.1.53 > 84.2.35.84.12850: 25921- 0/2/1 (86)
13:02:23.525419 IP 84.2.35.84.47851 > 194.0.1.12.53: 26624% [1au] A? ns1.vhost.hu. (41)
13:02:23.525478 IP 84.2.35.84.13915 > 193.239.149.3.53: 60458% [1au] A? ns2.vhost.hu. (41)
13:02:23.525552 IP 84.2.35.84.10451 > 192.174.68.11.53: 32078% [1au] AAAA? ns1.vhost.hu. (41)
13:02:23.525595 IP 84.2.35.84.30432 > 193.239.148.48.53: 50676% [1au] AAAA? ns2.vhost.hu. (41)
13:02:23.526412 IP 194.0.1.12.53 > 84.2.35.84.47851: 26624- 0/2/1 (102)
13:02:23.526866 IP 84.2.35.84.38275 > 195.70.35.250.53: 32837% [1au] A? ns2.serverfarm.hu. (46)
13:02:23.526918 IP 84.2.35.84.39633 > 193.6.16.1.53: 1214% [1au] A? ns.serverfarm.hu. (45)
13:02:23.526934 IP 193.239.149.3.53 > 84.2.35.84.13915: 60458- 0/2/3 (119)
13:02:23.526999 IP6 2001:4c48:2:a365:223:aeff:feff:564f.61479 > 2001:67c:1bc::11.53: 53085% [1au] AAAA? ns2.serverfarm.hu. (46)
13:02:23.527028 IP 84.2.35.84.60666 > 193.239.148.48.53: 55456% [1au] AAAA? ns.serverfarm.hu. (45)
13:02:23.527238 IP 193.239.148.48.53 > 84.2.35.84.30432: 50676- 0/2/3 (119)
13:02:23.527395 IP 84.2.35.84.57407 > 217.113.62.7.53: 47305% [1au] A? ns2.vhost.hu. (41)
13:02:23.527557 IP 84.2.35.84.31422 > 217.113.62.7.53: 57627% [1au] AAAA? ns2.vhost.hu. (41)
13:02:23.527850 IP 193.6.16.1.53 > 84.2.35.84.39633: 1214- 0/2/3 (109)
13:02:23.528178 IP 195.70.35.250.53 > 84.2.35.84.38275: 32837- 0/2/3 (109)
13:02:23.528227 IP 193.239.148.48.53 > 84.2.35.84.60666: 55456- 0/2/3 (109)
13:02:23.528291 IP 84.2.35.84.27075 > 195.228.76.1.53: 53731% [1au] A? ns.serverfarm.hu. (45)
13:02:23.528485 IP 217.113.62.7.53 > 84.2.35.84.57407: 47305*- 1/0/0 A 195.56.147.5 (46)
13:02:23.528728 IP 217.113.62.7.53 > 84.2.35.84.31422: 57627*- 0/1/0 (104)
13:02:23.528776 IP 84.2.35.84.20116 > 195.228.76.1.53: 19210% [1au] AAAA? ns.serverfarm.hu. (45)
13:02:23.528878 IP 84.2.35.84.57150 > 217.113.62.7.53: 55988% [1au] A? ns2.serverfarm.hu. (46)
13:02:23.529220 IP 84.2.35.84.18815 > 195.56.147.5.53: 57319 [1au] AAAA? wormsnevelde.hu. (44)
13:02:23.529950 IP 217.113.62.7.53 > 84.2.35.84.57150: 55988*- 1/0/0 A 195.228.76.1 (51)
13:02:23.530246 IP 195.228.76.1.53 > 84.2.35.84.27075: 53731*- 1/2/2 A 217.113.62.7 (109)
13:02:23.530423 IP 84.2.35.84.40945 > 195.228.76.1.53: 38318% [1au] A? ns1.vhost.hu. (41)
13:02:23.531654 IP 195.228.76.1.53 > 84.2.35.84.20116: 19210*- 0/1/1 (92)
13:02:23.532514 IP 195.228.76.1.53 > 84.2.35.84.40945: 38318*- 1/2/3 A 195.56.44.125 (135)
13:02:23.532753 IP 195.56.147.5.53 > 84.2.35.84.18815: 57319*- 0/1/0 (90)
13:02:23.533655 IP 84.2.35.84.60802 > 195.56.44.125.53: 24027 [1au] A? wormsnevelde.hu. (44)
13:02:23.541359 IP 195.56.44.125.53 > 84.2.35.84.60802: 24027*- 1/2/0 A 217.113.62.40 (91)
13:02:23.565898 IP6 2001:67c:1bc::11.53 > 2001:4c48:2:a365:223:aeff:feff:564f.61479: 53085- 0/2/3 (109)
13:02:23.566363 IP 84.2.35.84.12747 > 195.228.76.1.53: 17825% [1au] AAAA? ns2.serverfarm.hu. (46)
13:02:23.567815 IP 195.228.76.1.53 > 84.2.35.84.12747: 17825*- 0/1/1 (96)
13:02:23.571041 IP 192.174.68.11.53 > 84.2.35.84.10451: 32078- 0/2/3 (119)
13:02:23.571406 IP 84.2.35.84.53529 > 195.228.76.1.53: 65106% [1au] AAAA? ns1.vhost.hu. (41)
13:02:23.572829 IP 195.228.76.1.53 > 84.2.35.84.53529: 65106*- 0/1/1 (102)
Na itt látszik, hogy az én szerverem ip-jét adja vissza. Bár ahogy kiveszem, vmi tök idegen DNS-t kérdez a 84.2.44.1 és 84.2.46.1 helyett (valamint ezek ipv6 variánsai helyett).
Update: Megnézve ezeket teljesen természetesen kérdezi le őket... Nincs ötletem.
- A hozzászóláshoz be kell jelentkezni
futtatnék egy avirát
- A hozzászóláshoz be kell jelentkezni
Nem futtatunk idegen programokat csak úgy. Más részről az említett mappa nem létezik.
Amúgy is, avira létezik linux alá? :) Mert ez egy szerver, nem csak úgy átbootolni windows alá.
- A hozzászóláshoz be kell jelentkezni
Tipp: ne etesd...
- A hozzászóláshoz be kell jelentkezni
Ez nálad mit ír ki?
host -v help.prestashop.com
- A hozzászóláshoz be kell jelentkezni
srv1:~# host -v help.prestashop.com
Trying "help.prestashop.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28163
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;help.prestashop.com. IN A
;; ANSWER SECTION:
help.prestashop.com. 33200 IN A 213.186.52.66
;; AUTHORITY SECTION:
prestashop.com. 33158 IN NS ns1.mailclub.fr.
prestashop.com. 33158 IN NS ns2.mailclub.fr.
;; ADDITIONAL SECTION:
ns1.mailclub.fr. 33158 IN A 80.245.60.10
ns2.mailclub.fr. 33158 IN A 193.151.86.13
Received 132 bytes from 127.0.0.1#53 in 42 ms
Trying "help.prestashop.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53947
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;help.prestashop.com. IN AAAA
;; AUTHORITY SECTION:
prestashop.com. 10800 IN SOA ns1.mailclub.fr. domaines.mailclub.fr. 2009112746 28800 14400 3600000 33200
Received 97 bytes from 127.0.0.1#53 in 40 ms
Trying "help.prestashop.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50570
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;help.prestashop.com. IN MX
;; AUTHORITY SECTION:
prestashop.com. 10800 IN SOA ns1.mailclub.fr. domaines.mailclub.fr. 2009112746 28800 14400 3600000 33200
Received 97 bytes from 127.0.0.1#53 in 40 ms
Ez érdekes, miért 127.0.0.1-ről kérdezget? Hiszen nem az van megadva...
- A hozzászóláshoz be kell jelentkezni
Jó kérdés, hogy miért a 127.0.0.1-ről kérdezget. A szerver válasza viszont jó, mert itt nem ad vissza AAAA rekordot. Úgy tűnik, hogy nem a névszerverrel van baj, hanem valami mással. Azt tudom javasolni, hogy az /etc alatt nézz végig minden fájlt tartalom alapján. Nézd meg, hogy milyen konfigurációs fájlokban szerepel a 2001:4c48:2:a365:223:aeff:feff:564f IP cím. Midnight Commander remélem van, azzal egyszerű tartalom alapján keresni.
- A hozzászóláshoz be kell jelentkezni
Végig kerestem az egész rendszert. Csak access.logokban van (mivel azt az oldalt hozta ugye be) illetve a zónafájlban, ami a mi domainünk (AAAA rekord). Máshol nincs beállítva.
- A hozzászóláshoz be kell jelentkezni
srv1:~# ping6 help.prestashop.com
PING help.prestashop.com(2001:4c48:2:a365:223:aeff:feff:564f) 56 data bytes
64 bytes from 2001:4c48:2:a365:223:aeff:feff:564f: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from 2001:4c48:2:a365:223:aeff:feff:564f: icmp_seq=2 ttl=64 time=0.055 ms
Így pingelve is látszik, hogy ezt oldotta fel. A ping a "Name Service Switch"-et használja, ahogy olvastam, így a lynx és a php is ezt használja minden bizonnyal. Ez lehet a rendszer névfeloldó gyorsítótára.
Update: Viszont nekem ilyen nincs telepítve, tehát máshol keresendő a dolog
- A hozzászóláshoz be kell jelentkezni
ne
- A hozzászóláshoz be kell jelentkezni
Jó, értem a reakciódat...
- A hozzászóláshoz be kell jelentkezni
/etc/nsswitch.conf
Ebben van egy hosts: kezdetű sor, ahol meg lehet adni, hogy a rendszer a hosts fájlhoz vagy a dns szerverhez forduljon-e először a név feloldásakor. Bár nem hiszem, hogy az /etc/hosts fájl tartalma okozza nálad a problémát, de azért nézd meg. stra ötlete is ez volt.
- A hozzászóláshoz be kell jelentkezni
Kiszedtem a zónából az AAAA rekordokat, és most jó. Hol van elbaszva akkor a dolog? Eleve, ha leállítom 1x a bind-et, az hogy válaszol továbbra is? Mert teszteltem úgy is.
Update: Na, ha most leállítom a bind-et és visszaírom az AAAA rekordot, akkor jó. A bind van elbaszva, de hogyan...
Update2: A resolv.conf már egy symlink és 127.0.0.1-re mutat, istenem... libnss csomag csinálta biztos. Ezért van az, hogy jó, mert más se megy olyankor...
- A hozzászóláshoz be kell jelentkezni
Most újraindítás után AAAA rekordal jó lett vagy sem? Jó lenne látni a zónafájlt is.
- A hozzászóláshoz be kell jelentkezni
AAAA rekorddal ugyan az... Ha kikommenteltem azokat, és úgy indítottam, akkor jó volt.
A zóna:
; Bind9 zone: /etc/bind/zones/db.******.hu for nt-hosting.hu zone.
; Zone serial: 2010010201
$TTL 38400
@ IN SOA ns1.******.hu. info.******.hu. (
2010010201 ; serial
10800 ; refresh
3600 ; retry
604800 ; expire
38400 ; minimum TTL
)
@ IN NS ns1.******.hu.
@ IN NS ns2.******.hu.
@ IN NS ns3.******.hu.
;ns-end
@ IN MX 10 mail.******.hu.
@ IN MX 20 mail2.******.hu.
;mx-end
@ IN A 84.2.35.84
* IN A 84.2.35.84
srv1 IN A 84.2.35.84
srv2 IN A 84.2.35.85
srv3 IN A 91.82.250.163
ns1 IN A 84.2.35.84
ns2 IN A 84.2.35.85
ns3 IN A 91.82.250.163
mail IN A 84.2.35.84
mail2 IN A 84.2.35.85
mail3 IN A 91.82.250.163
[...]
;a-end
@ IN AAAA 2001:4c48:2:a365:223:aeff:feff:564f
* IN AAAA 2001:4c48:2:a365:223:aeff:feff:564f
ipv6 IN AAAA 2001:4c48:2:a365:223:aeff:feff:564f
;aaaa-end
;cname-end
- A hozzászóláshoz be kell jelentkezni
ne!
- A hozzászóláshoz be kell jelentkezni
Kifejtenéd bővebben?
- A hozzászóláshoz be kell jelentkezni
... kössön senki üzletet az nt-hosting-gal :)
- A hozzászóláshoz be kell jelentkezni
Igen, benne maradtak az IP címek. De kösz a véleményt.. Nyilván a szolgáltatás megy, az elszeparált környezetben viszont még kísérlet folyik, jelen esetben az IPv6-al.
- A hozzászóláshoz be kell jelentkezni
nem.
- A hozzászóláshoz be kell jelentkezni
Nagyon titokzatos vagy. Kifejtenéd mi konkrét probléma?
- A hozzászóláshoz be kell jelentkezni
szemlátomást a felületesség
- A hozzászóláshoz be kell jelentkezni
Nekem így látszólag jónak tűnik. De ha így mégse jó, akkor majd egy nálam jobban hozzáértő szaki kijavít. Így látatlanban nem tudom, hogy mi lehet a baj. Már nincs ötletem.
- A hozzászóláshoz be kell jelentkezni
Semmi gond, ezt is megköszönöm. Töröltem az AAAA rekordokat, majd visszatérek rá, meg utána nézek mi okozhatja.
- A hozzászóláshoz be kell jelentkezni