Ü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.
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
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)
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.
Ú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 wget biztos, hogy rendesen letölti? Ennek kimenetét másold be, légyszives:
wget http://help.prestashop.com -O /dev/null# 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
"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.
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.
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.
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. :)
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 topiknyitóban help.prestasop.com-ot írt, itt viszont már help.prestashop.com-ot.
Az viszont elérhető. Francos typok. :)
-
Debian Squeeze
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 resolv.conf-ban nincs search sorod?
Nincs, azt már az elején kiszedtem
Valami ötlet?
tcpdump + wireshark + strace + dig?
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.
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/.
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.
futtatnék egy avirát
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á.
Tipp: ne etesd...
Ez nálad mit ír ki?
host -v help.prestashop.comsrv1:~# 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...
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.
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.
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
ne
Jó, értem a reakciódat...
/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.
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...
Most újraindítás után AAAA rekordal jó lett vagy sem? Jó lenne látni a zónafájlt is.
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
ne!
Kifejtenéd bővebben?
... kössön senki üzletet az nt-hosting-gal :)
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.
nem.
Nagyon titokzatos vagy. Kifejtenéd mi konkrét probléma?
szemlátomást a felületesség
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.
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.