Tag: névfeloldás

Ki mennyire autoritatív?

2010-07-26 / / 0 Comments

Érdekes jelenségbe futottam bele a napokban. Különböző tartományok felé DNS lekérdezéseket kellett volna futtatnom – és nem igazán értettem az eredményeket.

De ehhez egy kis ismétlés.

Anélkül, hogy túlzottan belemennék a DNS részleteibe: tudjuk, hogy vannap primary zónák, vannak AD integrált zónák… de ezek most hidegen hagynak minket.
A finomságok a secondary és a stub zónáknál kezdődnek, illetve bejönnek a képbe a zónadelegálások is.

Secondary zóna:
A primary (elsődleges) zónát tükrözi le egy másik DNS szerverre, gyakorlatilag teljes egészében.

Stub zóna:
Szintén tükröz, de nem az egész zónát, hanem csak az A, NS és SRV rekordokat szedi le.

Zónadelegálás:
Megadjuk, hogy egy hozzánk tartozó zóna alzónájának ki a DNS szervere. Ez tetszőleges külsős DNS szerver is lehet.

És akkor a konkrét jelenség. Nemzetközi környezet, tartomány tartomány hátán. Szeretném megtudni az egyes tartományok MX rekordjait. Aztán nem mindegyikét kapom meg. Viszonylag hamar kiderült, hogy ahol stub zóna van, ott megkapom, ahol meg zónadelegálás, ott nem.
Mondanom sem kell, a névfeloldás mindegyik esetben tökéletesen megy – de az MX rekord beszerzése nem egy egyszerű kérés.

nslookup
ls -t MX kerdeses.domain

Stub zóna esetén vagy megkapom a kérdéses MX rekordot, vagy jogosultsági hiányosságból kifolyólag elutasítanak. Delegált zóna esetén viszont azt kapom vissza, hogy a zóna ismeretlen. Pedig – mint írtam is – a névfeloldás remekül megy, azaz dehogyis ismeretlen a zóna.

Keresgélés a neten. Azt írja a DNS hibakereső doksi, hogy ha nem autoritatív DNS szervert kérdezek, akkor jöhet ilyen üzenet. Ellenteszt: delegált zónánál kiegészítettem a lekérdezést:

nslookup
server a.zona.eredeti.dns.szervere.ahova.a.delegacio.mutat
ls -t MX kerdeses.domain

Láss csodát, egyből működött.

Ezzel akár már elégedett is lehetnék, de nem hagyott nyugodni a kisördög. Most akkor mi van a stub zónával? Gyors teszt: a stub zóna is non-authoritative választ ad, tetszőleges lekérdezésre. Azaz olyan rekord esetén is, mely egyébként már letükröződött a helyi DNS szerverre. Akkor meg miért működik az MX lekérdezés? Ha mindkét módszernél egyformán nem-autoritatív a kérdezett helyi szerver, akkor miért működik az MX lekérés a stub zónánál és miért nem a delegálásnál?
Nyilván azért, mert a stub egy hajszállal autoritatívabb, mint a delegálás.

Rasszista TLD

2010-01-28 / / 4 Comments

Kutyafuttában, mert tényleg őrült nagy hajtás van.

Belecsöppentem egy újabb remek nemzetközi projektbe. A héten megy az adatgyűjtés, illetve a tesztlabor összerakása. Nem kicsi laborról van szó, rögtön indulásképpen 5 tartományból álló erdőt kell összekötözni két másik erdővel.

A külső erdőknél igyekeztem semleges nevet választani. Az első az lett, hogy akarmi.akarhol. Szépen le is mentek vele a kísérletek. Ekkor derült ki, hogy az egyik partner élesben már Windows 2008 erdőt használ, tehát azt is le kell tesztelnünk. Így jött be még egy erdő, ennek roppant frappánsan az akarmi.akarhol.2008 nevet adtam. Tartomány működik, kliensgépet be lehetett léptetni.

A DNS rendszereket összelőttem, nslookup oda-vissza feloldott minden címet, minden tartományban. Oké, a biztonság kedvéért jöjjön egy ping. Semmi. Nincs ilyen cím.

Aha. Biztosan elgépeltem. A felfelé nyíllal elővettem a korábbi sikeres nslookup sort, átírtam pingre – nincs ilyen cím.

Aztakurva. Ezt meg akkor hogyan? Az nslookup feloldja a címet, a ping meg nem? Dehát nem ugyanazt az algoritmust használják? Mi van itt?

Egy bájos, nem túl gyakran kommunikált bug. Pedig valamikor mintha olvastam volna róla, csak most későn jutott eszembe: a TLD nem lehet szám. Azaz a tartomány nevében bárhol használhatok számot, de a legutolsó elem nem lehet az.

Lebontottam az új tartományt, létrehoztam egy másikat akarmi.akarhol.longhorn néven – és azóta is tökéletesen megy minden.

Csak éppen kiesett egy fél nap. Azon meg már nem is morgok, hogy valami, akármelyik fázisban, igazán figyelmeztethetett volna, hogy ‘hé, te, ez a cím nem lesz frankó mindenhol’.

Agyonütni… de csak az egyiket

2008-09-11 / / 0 Comments

Régi probléma. Van egy DNS szerverként is működő tartományvezérlő számítógépünk, melyben két hálókártya is van. Az egyik a külvilág felé néz, a másik a belső háló felé. (Csak a pontosság kedvéért: a külvilág azért nem a vad internet, hanem VPN-en keresztül egy másik kontinensen lévő társ vállalat.) Mindkét kártya felé adunk névfeloldási szolgáltatást.

Mi a gond?

Hát az, hogy a belső zónába simán beregisztrálódik a DC mindkét hálózati kártyájának a címe, sőt, az összes két hálókártyás gép címe is – emiatt néhányan panaszkodnak, hogy rossz IP címeket kapnak vissza.

Jó, mik a lehetőségeink?

A leginkább logikus természetesen az, hogy bemegyünk a hálózati kártyák beállításai közé, aztán a külsőn kikattintjuk, hogy automatikusan beregisztrálja magát. Logikus… de nem működik. Mégpedig azért nem, mert van ennél erősebb beállítás is. A DNS konzolban a konkrét szerver tulajdonságainál lehet beállítani, hogy mely hálózati kártyáin ad névfeloldási szolgáltatást a szerver. Márpedig ha mindkettőn, akkor mindkettő be is regisztrálódik. Ha a gép nem DNS szerver, akkor ugyanezt a registry-n keresztül tudjuk szabályozni:
a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters kulcs alatt fel kell venni egy változót PublishAddresses néven (reg_sz), majd pontosvesszővel elválasztva be lehet írni a regisztrálandó IP címeket. (Ha a változó nem létezik, akkor mindkét IP cím regisztrálódik.)

Ez mind szép, persze, de a mi problémánkat nem oldja meg. Ugyanis mi mindkét kártyán szolgáltatunk. Csak éppen nem szeretnénk, ha a külső cím is megjelenne a belső zónánkban.

Váltsunk csapásirányt. Miért is baj, hogy megjelenik a DC külső címe is? Vagy az Exchange szerveré? Egyáltalán, baj? Hiszen akik kintről kiváncsiak a zónára, azoknak szükségük is lehet erre a bejegyzésre. Azt kellene megoldani valahogyan, hogy a DNS kaméleon legyen: ha a külső hálózati kártyájáról jön egy kérdés, akkor a külső IP címeket dobja vissza, ha a belső kártyájáról, akkor a belsőket.

Happy end: van ilyen beállítás. DNS konzol, a szerver tulajdonságainál az advanced fül alatt ott vigyorog egy olyan beállítás, hogy ‘enable netmask ordering’. Ő a barátunk.