DynDNS rosszalkodás

 ( zolej | 2017. július 24., hétfő - 22:42 )

Pár órája (napja?) nem megy normálisan a dyndns-em.
Az a "szolgáltató"-m, aki magyar, s ingyen adja. (Én komolyan, fizetnék is érte, mert eddig hibátlan volt!)
Nem értek hozzá, de a címem állandóan egy "berögzött", rossz IP-t ad vissza, s néha olyakor eltalálja a jót.
Gondoltam, megkérdezem a "nagyokat", google dns mit mond rá?
Ahogy én kiveszem a logokból, 2 szerver válaszolgat ezekre a sorozatos kérdéseimre.

Innen jó IP jön:
87.229.73.156

Innen meg nagyon nem:
217.150.132.221

Létezik, hogy valami beragadt náluk? Vagy valami DNS poisoning történik?

ui: Össze-vissza scripteltem mindent, hogy megtudjam a mindig aktuálisat a túloldal felől, de ez nem fogja járni hosszú távon.
ui2: van itt "illetékes" fórumtárs?
ui3: le tudom valahogyan tiltani a fenti IP címet, hogy ne ő dobja vissza a rossz címet? (legalább itthonra) - Tomato-val

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Háát...tényleg nem értesz hozzá. ;)
Tudnivalók:
1. A dyndns szolgáltatónak átadod a címedet, hogy publikálja.
2. A routerednek megmondod, vagy valaki megmondja, vagy ezeknek a kombinációja, hogy honnan kérdezzen dns-t. (Ezek a dhcp-vel és a kézzel konfigurált dns szervereket jelentik.)

Az 1. és 2. között általában semmi összefüggés nincs.
Tehát nem a dyndns szolgáltatód a hibás, hanem az egyik dns szerver rossz. Kivétel, ha a rossz dns szerver éppen a dyndns szolgáltatódé. Hogy miért rossz, azzal most nem foglalkozunk.

Ha routeredben nem az egyszerű "gyári" firmware-t használod, akkor lehetőséged van a dns szerverek felsorolására. Ehhez még hozzá lehet adni az internetszolgáltató dhcp-vel kiosztott szervereit is.
Egy ilyen kb. így néz ki:

/etc/config/network:
config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'
        option peerdns '0'
        option dns '213.46.246.53 213.46.246.54 195.184.181.4 195.184.180.4 129.250.35.250 8.8.8.8'
        option broadcast '1'
        option delegate '0'

A fentiben a 213.46.246.53 és 213.46.246.54 címeket a szolgáltató adta (UPC), a többit én raktam hozzá. Ez a config NEM tomato-ról való!

Tesztelni ezzel a DNS Benchmark programmal tudod.
A dns szervereidet berakva a 217.150.132.221 szerverre ezt írja:
DNS queries are not being consistently answered
illetve

217.150.132.221 | The DNS server at this IP address does
  not provide domain name service answering client queries.
  It should not be used for normal client-based resolution.
                  dd8496d9.itexpert.hu
                  Budapest, Hungary, HU

Ami roppant érdekes! Tehát ez nem dns szerver, de néha válaszolgat és néha rosszul? :)

Már csa az a kérdés, hogy honnan vetted ezeket a dns szerver címeket?

Köszönöm a választ,
a DNS működése (_nagyon_ alapfokon_) ismert előttem, de legalább bevallottam az elején, hogy nem értek hozzá. Jöhetnek a szakik!

Mutatom is, mit tapasztalok éppen most is!
Nem titok azon része a dolognak: dyndns pont hu-t használok.
Tomato firmware-en futkosok, egy régebbi Linksys (egy másik ilyen dyndns címmel - az is rossz) és egy újabb Asus.
Nem hiszem, hogy velük lenne a probléma.

Mindenféle "whois" szolgáltatókkal szoktam megnézni, hátha magasabb szintű DNS szerverekről néznek, vagy esetleg többről,
s szoktam nézni, átmegy-e a tengerentúlra is hamar a DNS változás. (Nem mintha erre oltári nagy szükségem lenne .. :) )
De aztán rábukkantam a google dns oldalára, mert amúgy is a 8.8.8.8, 8.8.4.4-gyel szoktam játszani.
https://dns.google.com
Itt, ha beütöm a dyndns címemet, s egymás után lekérem-kéregetem, akkor 2 különböző ip cím jön le.
Az egyik mindig a helyes, a másik pedig mindig ugyanaz a rossz.

Képek (katt a nagyobbért):
1. a rossz:
kép

2. a jó:
kép

Több hálózatra át szoktam lépni, van a környezetemben T-, Digi, UPC, mobilinternet, s olyankor végigfutok mindegyiken,
milyen ip címeket ad vissza az egyszerű ping. Van, ahol a jót, s általában többnyire a rosszat.

Ez zavaró, nagyon....
Az ugyanarra a címre beállított no-ip.com-os dyndns szépen teszi a dolgát.
Pár nappal ezelőttig nem volt probléma.

Elsőre is értettem. ;)
A fent ajánlott benchmark program ezt is írja:
217.150.132.221 DNS lookup not offered by this server.

Miért gondolod, hogy ez egy publikus nameserver? Itt alant a routeremről kérdezve:

[admin@MikroTik] > put [resolve hup.hu server 217.150.132.221]          
failure: dns server failure
[admin@MikroTik] > put [resolve hup.hu server 87.229.73.156]               
185.43.206.113

Kérdezd le itt a két szervert! Láthatod, hogy teljesen más céghez tartozik. (Keresés: 217.150.132.221;87.229.73.156 )

Tehát:
Miért ettől a szervertől kérdezgetsz? Honnan kapod a dns szerver címét. (Előző hozzászólás 2. pont.)

Ha az internet szolgátató adja dhcp-vel, akkor
- átírod a dns szerver címét mondjuk 8.8.8.8-ra
- ÉS hibát jelentesz a szolgáltatónál

Ha a tomato konfigurációjában van - mert valaki beírta - akkor kitörlöd a 217.150.132.221 címet.

Értem azt, hogy az a másik IP az nem egy DNS szerver.
Megnéztem, (gondolhatod :) ), hogy ki a fene az.

Nálam nincsenek átírva a a DNS címek sehol sem!
A becsatolt képek a dns.google.com -ról vannak!

Viszont a dolog egyszerű, szinte az összes internetkapcsolaton, amit el tudok érni, mindenhol így viselkedik.
Egyik pillanatban egyik IP, másik pillanatban másik IP-t dob vissza a rendszer!
Szóval nem hiszem, hogy nálam van a hiba.

Budapest, DIGI
Pécs, T-com
Budapest, T-com
Debrecen, BIX
Telenor, mobilnet
Externet, adsl
T-com kirendeltség, bolt
.. és még sokan mások, legalább 30 putty ablak volt nyitva előttem... egész éjjel ezt nézegettem, mint valami hülye
...
....

Köszönöm azért a segítséget, de nem értem még mindig az anomáliát. :( :(

Ötlete van valakinek?

Az indító posztban már megadtad a választ a kérdésedre, de nézzük sorban:


# host -v -t soa dyndns.hu. ns.tux.hu.
Trying "dyndns.hu"
Using domain server:
Name: ns.tux.hu.
Address: 87.229.73.156#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45318
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dyndns.hu. IN SOA

;; ANSWER SECTION:
dyndns.hu. 86400 IN SOA ns.tux.hu. postmaster.dyndns.hu. 2013783100 600 300 1209600 60

Received 81 bytes from 87.229.73.156#53 in 1 ms
#

# host -v -t soa dyndns.hu. ns2.tux.hu.
Trying "dyndns.hu"
Using domain server:
Name: ns2.tux.hu.
Address: 217.150.132.221#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11788
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dyndns.hu. IN SOA

;; ANSWER SECTION:
dyndns.hu. 86400 IN SOA ns.tux.hu. postmaster.dyndns.hu. 2013775973 600 300 1209600 60

Received 90 bytes from 217.150.132.221#53 in 3 ms
#

Látszik, hogy a zóna SOA serial a két szerveren eltér, az ns2-n lévő zóna sorozatszáma el van maradva az elsődleges szerveréhez képest.
Ez jó eséllyel azt jelzi, hogy a két zóna nincs szinkronban.

Találomra egy konkrét hostnévvel:


# host -v -t any alma.dyndns.hu. ns.tux.hu.
Trying "alma.dyndns.hu"
Using domain server:
Name: ns.tux.hu.
Address: 87.229.73.156#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11669
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;alma.dyndns.hu. IN ANY

;; ANSWER SECTION:
alma.dyndns.hu. 120 IN A 46.78.233.4

Received 48 bytes from 87.229.73.156#53 in 13 ms
#

# host -v -t any alma.dyndns.hu. ns2.tux.hu.
Trying "alma.dyndns.hu"
Using domain server:
Name: ns2.tux.hu.
Address: 217.150.132.221#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58540
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;alma.dyndns.hu. IN ANY

;; ANSWER SECTION:
alma.dyndns.hu. 120 IN A 46.78.112.49

Received 48 bytes from 217.150.132.221#53 in 2 ms
#

Itt ugyanaz a helyzet, mint nálad is.

Keresd meg a dyndns.hu üzemeltetőjét, és kérd meg, hogy az ns2.tux.hu-ra nézzen rá.

Épp most néztem rá, hogy a SOA mit fog segíteni nekem most :))
És te vagy az én emberem, ez lesz a baj.

ip alapján nem tudtam volna kitalálni, hogy ő az ns2!

Köszi!

Most már én is értem! ;)
Most teszteltünk egy kollégával néhány tűzfal+dns kombót, több féle hálózaton.
A tanulság igen vegyes:
- Végig fogom nézni a dns szerver listámat. Amelyik téveszt az repül!
- Ugyanakkor szomorú, hogy a google is boldogan osztja a hülyeséget, ami a laza beállítások eredménye lehet.
- A UPC szervere nem téveszt!
- Úgy néz ki, hogy egy pfSense vagy MikroTik több dns szerver és a kliens megfelelő beállításával képes eldobni a hibás válaszokat, hasonlóan a benchmark programhoz. Ezért ad mindig jó választ és dobja el a közvetlen lekérdezést!

Vagyis néha választani kell az egyes címek elérhetetlensége és bizonytalansága között. :(

Itt még mindig úgy érzem, hogy félreértés van.
Jelen esetben nem az internetszolgáltatói (T, UPC stb.) caching nameservereinek, vagy más publikus rekurzív DNS szolgáltatásnak a problémáját látjuk.
Egy domain (zóna) adatai egy vagy több nameserverről származnak (ezek az adott zónára vonatkoztatott autoritatív NS-ek). A külvilág rekurzív feloldást nyújtó DNS szerverei ezek bármelyikéhez fordulhatnak, amikor ez alá a zóna alá tartozó rekordot keres valaki. Ebből következően a két (vagy több) autoritatív szervernek azonos rekordokat kell láttatnia a világ felé. Ez most itt nem teljesül. Nem az internetszolgáltatói caching szerverek miatt, hanem a dyndns.hu-t kiszolgáló két autoritatív szerver összhangjának hiánya miatt.

"Ugyanakkor szomorú, hogy a google is boldogan osztja a hülyeséget, ami a laza beállítások eredménye lehet."
A Google, és más is azt "osztja", amit az adott domain zónaadatait tartalmazó szervertől lekér. Az autoritatív szerver a nevéből adódóan a "főnök" az adott zónával kapcsolatosan. Hogy a két "főnök" mást mond, nem a Google, és nem is az ISP-k caching szervereinek baja. És nem is tudja mi alapján eldönteni, hogy az egyenrangú "főnökök" közül melyik mond jót, és melyik mond rosszat, hisezn definíció szerint az autoritatív szervertől származó infó jó.

"Végig fogom nézni a dns szerver listámat. Amelyik téveszt az repül!"
Szóval ennek a topikban szereplő esetben semmi értelme nem lenne, hiszen két vagy több szerver között inkonzisztens zónára gyakorlatilag mindenhol ezt fogod tapasztalni.

A DNS Benchmark azonnal kizárja a rossz szervert, még a benchmark előtt. Biztosan van, amire nem gondoltál.

Szerintem eléggé elbeszélünk egymás mellett.

Te azt mondod, hogy a 217.150.132.221 azért nem jó DNS szerver, mert nem válaszol rekurzív kérésekre, és a DNS Benchmark ezt jelzi is.
Én azt mondom, hogy a 217.150.132.221-et nem rekurzív szervernek szánták, hanem kizárólag autoritatív szervernek, így teljesen jogos, hogy nem válaszol másra, csak a dyndns.hu zónára. (Tehát nem mondja meg, hogy mi a hup.hu IP-je, de megmondja, hogy mi az alma.dyndns.hu IP-je, mert a dyndns.hu zónaadatai nála vannak.). A DNS Benchmark vélhetőleg nem valami.dyndns.hu címet kérdez tőle. A dyndns.hu-s kérésekre viszont szépen válaszol. Lehet ellenőrizni közvetlen hozzá intézett dyndns.hu-ra vonatkozó kérédsekkel.

A DNS Benchmark emlegetését azért nem teljesen értem, mert a kérdező gépén nem a 217.150.132.221 van beállítva rekurzorként, hanem ahogy írta is, a 8.8.8.8.
A 8.8.8.8 is változó IP-ket fog visszaadni, ha a dyndns.hu szerverein különböző adatok vannak. Szóval nem értem, hogyan zársz ki a DNS feloldás fastruktúrájának bármely részéről olyan szervert, amelyre a géped közvetlenül nem hivatkozik. Nem tudod megmondani a 8.8.8.8-nak, hogy az *.dyndns.hu név feloldásakor a 217.150.132.221-től ne kérdezzen.
Tehát: a rossz válasz oka nem az, hogy melyik rekurzortól kérdezel, hanem az, hogy az a rekurzor akkor éppen a dyndns.hu autoritatív szerverei közül melyiket kérdezte meg. Jelen esetben 2 szervere van a zónának, tehát hozzávetőlegesen 50% esély volt a rossz válaszra. A TTL lejártakor ismét kérdez, tehát az, hogy a 8.8.8.8-tól egyszer a rossz IP-t kapta vissza, nem jelenti azt, hogy pl. 10 perc múlva is ugyanazt kapná.

Egyébiránt a dyndns.hu-t már rendbetették:

# host -t soa dyndns.hu. ns.tux.hu.
Using domain server:
Name: ns.tux.hu.
Address: 87.229.73.156#53
Aliases:

dyndns.hu has SOA record ns.tux.hu. postmaster.dyndns.hu. 2013784672 600 300 1209600 60
#

# host -t soa dyndns.hu. ns2.tux.hu.
Using domain server:
Name: ns2.tux.hu.
Address: 217.150.132.221#53
Aliases:

dyndns.hu has SOA record ns.tux.hu. postmaster.dyndns.hu. 2013784672 600 300 1209600 60
#

"ip alapján nem tudtam volna kitalálni, hogy ő az ns2!"
Nem is IP alapján, hanem a dyndns.hu domainből kiindulva jutunk el odáig:

# host -v -t any dyndns.hu. ns.nic.hu
Trying "dyndns.hu"
Using domain server:
Name: ns.nic.hu
Address: 193.239.148.1#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5739
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;dyndns.hu. IN ANY

;; AUTHORITY SECTION:

dyndns.hu. 86400 IN NS ns2.tux.hu.
dyndns.hu. 86400 IN NS ns.tux.hu.

;; ADDITIONAL SECTION:

ns.tux.hu. 86400 IN A 87.229.73.156
ns2.tux.hu. 86400 IN A 217.150.132.221

Received 98 bytes from 193.239.148.1#53 in 1 ms
#

Igen, én megértettem, amit mondtál, ezért fogalmaztam előre úgy, hogy fordított úton nem is működhetett volna, hiába is..

:)

Köszönöm szépen a segítséget, rávilágítást, Stra!

Írtam az üzemeltetőnek, remélem, lesz reakció.