Névszerver feloldási gond [IPv6]

Debian GNU/Linux

Ü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

( suckit | 2011. 07. 18., h – 21:23 )

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.


# 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.

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. :)

( Rt711 v | 2011. 07. 18., h – 22:33 )

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

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.


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...

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.

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

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...

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