ugrás a tartalomhoz

Hogyan működik a DNS?

janoszen · 2013. Szep. 29. (V), 21.22
Hogyan működik a DNS?

Megint egy olyan téma, amihez fejlesztőként nem sok közünk van. Vagy mégis? Ha megnézzük a weboldalunk betöltési sebességét, akkor bizony ott figyel a DNS lekérdezés ideje, így hát nem lényegtelen, hogy hogyan működik.

Alapok

A sorozatban megjelent

Ha konyhanyelven akarjuk megfogalmazni, a DNS (Domain Name System) arra szolgál, hogy domain neveket oldjon fel IP-címekre. Ez természetesen ilyen formán nem igaz, hiszen ez csak egy funkció a sok közül, de az alapok tisztázásig maradjunk ennél a definíciónál.

Van tehát valamink amit tudunk, a teljes domain név – más néven az FQDN (Fully Qualified Domain Name) –, amit keresünk, az pedig az IP-cím. A keresett végeredmény megfogalmazható a DNS-ben egy rekordként:

www.janoszen.com. IN A 188.227.224.12

Nézzük eme sor egyes alkotóelemeit:

Elem Magyarázat
www.janoszen.com. A teljes domain név, amit keresünk. Figyeljük meg, hogy a végén van egy pont, ez a root zóna, erről nemsokára szó lesz.
IN A lekérdezés osztályát jelöli, ez a gyakorlatban mindig IN mint Internet. (Lehet még pl. CH mint Chaos)
A A rekord típusa. Erről is mindjárt lesz szó.
188.227.224.12 A keresett IP cím.

Elsőként mindjárt szembetűnhet, hogy van egy rekord típus mező. Ebből máris nyilvánvaló, hogy a DNS-ben mást is tárolhatunk, például IPv6-os címet (AAAA), szöveges információt (TXT) vagy éppen szolgáltatás mutatókat (SRV).

Fától az erdőt, mindjárt jön a faragasztó

Már szó esett a pontról az FQDN végén, itt egy picit el is árultam, mi következik. A világ összes domainjét, DNS-rekordját egy adatbázisban tárolni és abból kiszolgálni némiképp túlzás lenne, nem beszélve a dolog műszaki kivitelezhetetlenségéről. Éppen ezért a DNS-t fastruktúrába szervezték, aminek a csúcsán a root (gyökér) névszerverek vannak.

A gyökér-névszerverek tárolják mindegyik végződés (TLD, Top Level Domain) adatait, legfőképpen azt, hogy melyik szervertől kell lekérdezni az abba tartozó domaineket. Gyakorlati példánál maradva, a root névszerverektől azt kérdezhetjük meg, hogy a .hu domainek adatait honnan kell lekérdezni. Erre a válasz így néz ki:

hu. IN NS b.hu.
hu. IN NS ns-com.nic.hu.
hu. IN NS d.hu.
hu. IN NS e.hu.
hu. IN NS ns2.nic.fr.
hu. IN NS ns.nic.hu.
hu. IN NS c.hu.

Itt három érdekességet is észrevehetünk. Egyrészt előkerült egy új rekord típus, az NS. Ezzel mondhatjuk meg a kérdezőnek, hogy hol találja a következő szint adatait. Ha ezt nem adjuk meg, akkor ugyanazon a szerveren fogja keresni. Erről még lesz szó a zónák címszó alatt.

A másik érdekesség, hogy megállapíthattuk, hogy a .hu domainek részben a franciákkal közös névszervereken laknak. A legtöbb kis végződés ugyanígy közösen működik más kis TLD-kkel hogy növeljék a megbízhatóságot és csökkentsék a költségeket.

Ami viszont szöget üthet a kedves olvasó fejébe (ha figyelt is, nem csak olvasott), hogy honnan tudhatjuk mondjuk a d.hu IP-címét, ha még csak a .hu-nál járunk? Hiszen a d.hu IP-címe nem oldható fel a .hu névszerverek IP-címének ismerete nélkül.

Itt jön képbe a glue record (ragadványrekord) fogalma. Ilyen esetekben ugyanis a d.hu IP-címének szerepelnie kell a root névszerverekben is, nem csak a .hu alatt! Ugyanez igaz, ha mondjuk a example.com névszerverének szeretnénk beállítani az ns1.example.com-ot.

Kiszolgálás

A DNS protokoll mind UDP, mind TCP fölött tud működni. Az UDP teljesen állapotmentes, tehát az különböző adatcsomagok között igen nehéz külső szemlélőként összefüggést teremteni. Éppen ezért a DNS kérdésnek és válasznak UDP esetén bele kell férnie egy-egy UDP csomagba, ahol a hasznos adatmennyiség a gyakorlatban 512 bájt. A TCP egy állapottal rendelkező protokoll, ezért a csomagok között van összefüggés, így nagyobb adatmennyiséget lehet mozgatni.

A DNS-nél elsődlegesen UDP-t használunk, mivel a TCP inicializálása időt vesz igénybe, míg az UDP-nél már az első csomaggal elküldhetjük a teljes kérést, és a válaszcsomagban már meg is kaphatjuk a választ.

Szerverek

Szerverek tekintetében sok megoldás létezik, a legelterjedtebb a szabvány referencia impementációjaként is szolgáló ISC BIND. Egy DNS infrastruktúra tervezésénél érdemes szem előtt tartani, hogy egy átlagos domainnek két, hálózatilag és infrastrukturálisan elkülönített szervert szokás üzembe helyezni, azonban vannak ettől eltérő példák is, például (noha a szabvány megköveteli a két névszervert) 1 vagy akár 8 szerveres domainek is léteznek.

Ha két névszerverünk van, nyilván szeretnénk ha ugyanazokat az adatokat szolgálnák ki a domainjeinkre. (Ugyan van néhány nagyon speciális eset amikor nem, de ettől most tekintsünk el.) Ehhez az adatokat szinkronban kell tartani. Erre ugyan a legkézenfekvőbb megoldás egy közös adatbázis lenne, de ezzel pont a megkettőzött névszerverek előnye veszne el, az egymástól való függetlenség.

Erre ad megoldást a DNS protokoll maga, ugyanis a másodlagos névszerverek az elsődlegestől le tudják tölteni az adatokat. Az összes egy szerveren található adat letöltését AXFR-nek hívjuk, de a korszerűbb szerverek támogatják a részleges transzfert is, az úgynevezett IXFR-t.

Természetesen nem kötelező a protokoll transzfer funkcióját használni, de határozottan előnyös, ha nem akarunk sokat gondolkozni a rendelkezésreálláson.

Zónázó

Mint említettem, a DNS rekurzió a root zónától indul, és lefele halad. Már szó volt itt zónákról, de akkor tegyük tisztába. A zóna alatt egy olyan rekordhalmazt kell érteni, ami egy szervertől, további ugrálás nélkül lekérdezhető, illetve egy menetben transzferálható két névszerver között. Gyakran beszélünk zónafájlokról is, mert a referenciaimplementációként is funkcionáló BIND egészen a 10-es verzióig kizárólag fájlból tudott olvasni.

Ugyanitt tisztázzuk a glue rekordok fogalmát is. Glue rekordon olyan rekordot értünk, amit noha további ugrással kellene elérni egy NS rekorddal, mégis a szülő zónában található.

Hogy az egész hivatalos is legyen, a zónát egy úgynevezett SOA (Start of Authority, avagy hatókör kezdete) rekord jelöli meg. Ez a rekord jelzi, hogy igen, ez a szerver autoritatívan (hivatalosan) szolgáltatja a zónát, nem mástól kérdezte le (lásd rekurzió a következő bekezdés alatt). A SOA rekord nem csak szemantikai jelentősséggel bír, hanem több fontos információt is hordoz. Nézzük ezeket:

janoszen.com. IN SOA ns1.janoszen.com.
                     ops.janoszen.com. (
                         2013091101 ;Szériaszám
                         86400      ;Frissítés 
                         7200       ;Újrapróbálkozás
                         604800     ;Lejárat
                         3600)      ;Negatív cache

Nézzük tételesen, mi mit is jelent.

ns1.janoszen.com.

Ez jelöli meg az elsődleges névszervert. Ez kizárólag a névszerverek közötti frissítéshez kell, a normál kiszolgálás szempontjából lényegtelen.

ops.janoszen.com

Ez igazából egy e-mail cím, az első pontot le kell cserélni egy @ jelre. Különlegessége, hogy noha sok nemzetközi domain típusnál ez lényegtelen, de a .hu domaineknél ennek a címnek ténylegesen léteznie kell, különben nem állítható be a névszerver a domainnek.

Szériaszám

Ennek megint a névszerverek közötti frissítéskor van létjogosultsága, ugyanis ezen szám növelésével jelzi az elsődleges szerver, hogy a zóna megváltozott, újra le kell töltenie a másodlagos szerver(ek)nek. A gyakorlatban itt a módosítás dátumát és az aznapi módosítások számát szokás feltűntetni, de szigorúan véve erre szabály nem létezik.

Frissítés

Ez a szám mondja meg, hogy a másodlagos névszerver(ek)nek hány másodpercenként kell kötelezően letölteniük a teljes zónát.

Újrapróbálkozás

Amennyiben a letöltés nem sikerült, a másodlagos névszerver ennyi másodperc múlva próbálja meg újra a zónafájl letöltését.

Lejárat

Ez az idő adja meg, hogy sikertelen letöltés esetén a zóna meddig érvényes. Amennyiben ennyi ideig nem sikerül letölteni a zónát az elsődleges névszervertől, a másodlagos névszerver nem fogja tovább kiszolgálni, a zónában tartalmazott FQDN-ek elérhetetlenek lesznek.

Negatív cache

Ez a szám jelzi a kérdezőnek, hogy egy negatív, nem talált válasz (NXDOMAIN) meddig tekinthető érvényesnek.

Gyorsulási verseny vs. traffipax

Ha ezt az utat minden egyes letöltött fájlra végig akarnánk járni, akkor az egész internet baromi lassú lenne. Éppen ezért ezt a feloldást nem a mi számítógépünk végzi, hanem az internetszolgáltatónknál telepített rekurzor.

Ez a rekurzor nem csak leveszi a terhet a gépünkről, hanem gyorstárazza is a már lekérdezett rekordokat. Hogy milyen rekordot mennyi ideig menthet el, azt szintén a DNS-ben eltárolt TTL írja le.

Ha megnézzük az első példaként felírt DNS-rekordot a TTL információkkal kiegészítve, így nézne ki:

www.janoszen.com. 3600 IN A 188.227.224.12

A www.janoszen.com DNS-bejegyzés tehát egy óráig érvényes. Ez az érvényesség rekordonként értendő, noha sok szoftver kínál megoldást arra, hogy egy-egy zóna TTL-jét globálisan állítsuk.

Ha egyszer megnéztünk a szolgáltatónktól egy oldalt, és az oldal rendszergazdája IP-címet vált, a forgalom ettől a szolgáltatótól a TTL lejáratáig továbbra is a régi IP-címre fog menni. A dolog pikantériája az, hogy az internet egy része az átállás idejéig még a régi szerverre fog menni, a másik része pedig már az új szerverre. Éppen ezért érdemes a költözéseket igen jól előkészíteni, például egy névszerver váltás akár 48 órát is igénybe vehet.

Fontos megjegyzeni, hogy a már említett BIND mind autoritatív névszerverként, mind rekurzorként használható. Ez azonban nem minden szoftverre igaz. Ha saját névszervert akarunk üzemeltetni, érdemes szem előtt tartani, hogy egy rosszul konfigurált DNS-szerver tetszőleges kérésre rekurzorként viselkedik, ezzel adott esetben közel akkora bajt csinálva, mint egy open relay e-mail szerver. A helyesen felkonfigurált DNS-szerverek csak saját hálózatból engednek rekurzív kéréseket, mások számára csak autoritatív zónákat szolgálnak ki.

Gyakorlati feladatok

Ez a gyakorlatban igen szépen hangzik, de gyakorlat nélkül nem ér semmit. Ezen a ponton kedves olvasó, nyisd ki az operációs rendszered terminálját vagy parancssorát, DNS-lekérdezéseket fogunk folytatni. Bármilyen operációs rendszert is használsz, rendelkezésedre áll az nslookup, amivel DNS-lekérdezéseket tudsz futtatni. Tehát indítsd el az nslookup-ot a parancssorodban és kezdjünk neki.

Ahhoz, hogy megfigyelhessük az nslookup működését, először is kapcsoljuk be a debug funkciót:

> set debug

Semmi választ nem kapunk, így kérdezzük le a www.weblabor.hu IP-címét:

> www.weblabor.hu

Na itt már van információ bőven. Az nslookup kiírja a választ, amit az internetszolgáltatónk szerverétől kapott. Ebből nézzük a Non-authoritative answer szekciót:

HEADER:
    opcode = QUERY, id = 11, rcode = NOERROR
    header flags:  response, want recursion, recursion avail.
    questions = 1,  answers = 1,  authority records = 1,  additional = 0

Itt láthatjuk a különböző fejlécparamétereket a válaszból. Mint látjuk, nem történt hiba, rekurzív lekérdezést kértünk és a szerver hajlandó is volt ennek teljesítésére.

QUESTIONS:
    www.weblabor.hu, type = AAAA, class = IN

Itt láthatjuk azokat az adatokat, amiket kérdeztünk. Itt egy AAAA rekordot kértünk, avagy IPv6-os IP-címet.

ANSWERS:
->  www.weblabor.hu
    canonical name = weblabor.hu
    ttl = 59857 (16 hours 37 mins 37 secs)

Itt kapjuk meg a választ a szervertől. A válasz adatrésze egy CNAME rekordot mutat, ami annyit jelent, hogy a keresett domain adatait nem itt, hanem egy másik domain alatt kell keresni. A rekurzor ekkor a www.weblabor.hu adatai helyett lekérdezi a weblabor.hu adatait, és azt fogja használni.

A válaszban láthatjuk a TTL-t is. Mivel itt egy rekurzortól kérdeztünk le, a még hátralevő cache-időt kapjuk vissza, nem a teljes TTL időt.

AUTHORITY RECORDS:
->  weblabor.hu
    ttl = 11734 (3 hours 15 mins 34 secs)
    primary name server = ns1.linode.com
    responsible mail addr = adam.jooadam.hu
    serial  = 2013082356
    refresh = 14400 (4 hours)
    retry   = 14400 (4 hours)
    expire  = 1209600 (14 days)
    default TTL = 86400 (1 day)

Itt kapjuk meg a SOA rekord adatait. Remélhetőleg ezen a ponton ezt már senkinek nem kell elmagyarázni.

További feladatok

Amennyiben a fenti feladat nem okozott problémát, oldd meg a következő feladatokat gyakorlásként:

  • Nézz utána, mit csinál az MX rekord!
  • Olvasd el az nslookup súgóját! (nslookup help)
  • Kérdezd le a Weblabor adatait az autoritatív névszervertől!

A cikk megírását a Neticle Technologies támogatta.

 
janoszen arcképe
janoszen
Pásztor János a fejlesztés és az üzemeltetés témakörével is foglalkozik, igyekszik az egyikben szerzett tapasztalatokat a másikba is átültetni. A Weblaboron kívül Facebookon ,Twitteren, a Refaktor Magazinon és a Refactor Zone-on publikál.
1

Infódömping :)

Pepita · 2013. Szep. 29. (V), 23.08
Megint egy olyan téma, amihez fejlesztőként nem sok közünk van.
Őszintén szólva hiába irónia, bizony egyben igaz is. Kellene, hogy közünk legyen hozzá.

Rendkívül hiánypótló cikk, én nagyon köszönöm!
Egyelőre emésztenem kell, de kb. 100 kérdésem lesz még... Lehet, hogy nekem "szájbarágósabb" jobb lenne, de így viszont jó tömör.

A feladat
  • Az MX rekord szerintem külön cikket érdemelne (megoldásban), mutatóként még nem mond eleget (nekem), én tudni szeretném a folyamatot is. Ha már van erről cikk, akkor nem találtam.
  • Itt én már problémába ütköztem: amit írt nekem szintaktikákat, parancsokat már nemigazán tudtam használni, de az első eredmény is egész más volt (IpV4, több névszerver, stb).
  • Fenti miatt nekem nem sikerült, pedig a teljes megértéshez kéne.

Visszatérve az idézetre: én kérném bővebben, ha lehet, így még homályos a dolog. Nagyjából eddig is értettem, hogy mi a DNS, de csak távolról, nagyjából, és szerintem nagyon is kellene tudnom, pontosan.
2

Hm. Izgalmas.(pláne azok

H.Z. · 2013. Szep. 29. (V), 23.16
Hm. Izgalmas.
(pláne azok után, amit az imént szerencsétlenkedtem mysql-ben - de végül összejött, hogy kicsit olvastam is, nem csak néztem a doksit! :)) )
Sok valódi újdonság van benne számomra. (franciák, glue, meg még egy pár "apróság")

Egy bajom van, ha nem veszed kötekedésnek: az nslookup-ról emlékeim szerint már évek óta próbálják lebeszélni a t. felhasználókat, mondván: elavult.
Amit ugyan nem teljesen értek, mert pl. a windows7 annyira még nem lejárt lemez, de abban sem találtam hirtelenjében mást... (dig biztosan nincs benne gyárilag)

ui: a traffipax két eff! ;)
3

a traffipax két eff!

Joó Ádám · 2013. Szep. 29. (V), 23.31
a traffipax két eff! ;)


Javítva.
4

nslookup

janoszen · 2013. Szep. 30. (H), 01.18
A baj az, hogy kb. az nslookup az egyetlen, ami crossplatform modon elerheto.
5

Tetszik a cím, már azt hittem

inf3rno · 2013. Szep. 30. (H), 03.47
Tetszik a cím, már azt hittem élő sejteket fogsz modellezni meg genetikus algoritmusokról lesz szó :D Egyébként lehetne, meg én fogok is, az élő sejtek és a robotok között csak bonyolultságban van különbség, egyébként felépítési elvet tekintve tök ugyanolyanok.

Visszatérve a cikkhez, hiánypótló, nekem sok újat mondott. Lehetne folytatni az MX rekorrdal, illetve ha már gyakorlati példáról volt szó, akkor lehetne arról is írni, hogy hogyan kell átírnod a zóna fájlodat, ha költözteted a hostingot, de a domain ugyanannál a szolgáltatónál marad, stb..
6

Türelem

janoszen · 2013. Szep. 30. (H), 08.01
Türelem, ezekről a gyakorlati témákról is lesz a jövőben szó, de nem lehet mindent egy cikkbe sűríteni.
22

Vágom, csak rögtönzött

inf3rno · 2013. Szep. 30. (H), 17.31
Vágom, csak rögtönzött brainstormingot tartok :-)
7

Jó összefoglaló, de aki

meni · 2013. Szep. 30. (H), 08.44
Jó összefoglaló, de aki ezeket nem tudja és programozó az szégyellje magát. :) Ezek tényleg nagyon az alapok.
8

Én tizenöt éven át

H.Z. · 2013. Szep. 30. (H), 08.58
Én tizenöt éven át üzemeltettem banki rendszereket. Közöm nem volt az ilyen témákhoz. Többségét azért tudom, mert miután elküldtem anyukájába az összes főnökömet és távoztam a cégtől, itthon, unalomból elkezdtem összerakni egy kisvállalati hálózat modelljét.
Ha nekem nem volt szükségem minderre, üzemeltetőként, miért egy programozótól várod el, hogy x év után emlékezzen ezekre, mikor talán soha életében nem használta?

Említhetnék pár dolgot, amit a mai napig nem tudtam:
- miért UDP, miért nem TCP, mikor az utóbbi is támogatott?
- "kötelező" két DNS (mindig úgy tudtam, hogy csak a biztonságos működés miatt kell kettő, nem tudtam, hogy szabvány/RFC írja elő)
(gyanítom, az üzemeltetők jó része sincs teljesen tisztában mindezekkel, amiket janoszen itt leírt)

----------------------------------------------

Nem tudom, beleférne-e a folytatás kereteibe, megemlíteni a dnsmasq nevű mini szervert, ami szintén képes DNS-ként is működni (kisebb LAN-okra elégséges, amit tud) és jóval egyszerűbb konfigurálni, mint a bind-ot.
9

Egyetértek veled, hogy egy

Hidvégi Gábor · 2013. Szep. 30. (H), 09.05
Egyetértek veled, hogy egy átlag fejlesztőnek erre a tudásra nem feltétlenül van szüksége – bár jó tudni, hogyan is működik.

Megoldható-e a dnsmasq-kal vagy bármivel a következő: egy helyi hálózaton, ha beírja valaki, hogy http://szerver/, akkor kapcsolódik ahhoz a szerverhez a böngészője? Jelenleg ezt úgy oldottuk meg, hogy a Windows hosts fájljába írkáltuk bele azt, ami szükséges, de ez nagyobb mennyiségű számítógépnél már nem olyan kényelmes.
10

Igen, de nem érdemes

janoszen · 2013. Szep. 30. (H), 09.20
Igen, megoldható, de nem érdemes. Ha csak a szerver nevet használod, bajban vagy ha valamilyen okból kifolyólag nem a belső névfeloldót használod, pl. VPN-en csatlakozol a céges hálózathoz, stb.

A megoldás amit én szeretek, így néz ki:

Fogunk egy aldomaint a rendes céges domainünkből, pl. dev.cegneve.hu. Ebből delegálunk egy aldomaint és létrehozunk egy glue rekordot:

dev.cegneve.hu. IN NS office.dev.cegneve.hu.
office.dev.cegneve.hu. IN A 1.2.3.4


Itt az 1.2.3.4 az irodai névszerver publikus IP címe. Ezen a ponton használhatjuk a privát címet is, azonban akkor nem lesz elérhető külső resolver használatával, de még mindig globálisan egyedi a név, így nem ütközöl problémákba pl. két fejlesztői környezet összevonásánál.

Ezután az irodai névszerverbe felveszed a zónádat:

dev.cegneve.hu. IN SOA office.dev.cegneve.hu. rendszergazda.cegneve.hu. (...)
dev.cegneve.hu. IN NS office.dev.cegneve.hu.
office.dev.cegneve.hu. IN A 1.2.3.4
*.fejleszto1.dev.cegneve.hu. IN A 1.2.3.5
*.fejleszto2.dev.cegneve.hu. IN A 1.2.3.5


Ha nincs irodai névszervered, akkor kihagyhatod a delegálós lépést és egyszerűen beírhatod a cegneve.hu zónába ugyanezeket a rekordokat.

Ha szeretnéd ezután rövid névvel elérni a szervert, fel kell venni a gépeken a "search domainbe" a DNS beállításoknál. Ez az opció a DHCP szerverekben is állítható.

Ha leírod picit pontosabban, milyen adottságokkal dolgoztok, kifejtem részletesebben.
11

Köszönöm a választ, majd

Hidvégi Gábor · 2013. Szep. 30. (H), 09.26
Köszönöm a választ, majd rákérdezek a rendszergazdánál a belső architektúrára. Mi, fejlesztők VPN-en keresztül csatlakozunk a belső hálózatra, ami bonyolítja a dolgot, de nálunk a hosts fájl átírása nem okoz gondot, mert jóval kevesebben vagyunk a bent dolgozó alkalmazottaknál.
13

Most fogtam fel, hogy itt a

H.Z. · 2013. Szep. 30. (H), 10.00
Most fogtam fel, hogy itt a rövid név volt a probléma forrása, nem az, hogy egyre több az új szerver...
(Gábor! Ebben az esetben a mail amit küldtem, tárgytalan)
14

VPN

vbence · 2013. Szep. 30. (H), 12.07
A VPN tudja push-olni a saját névszerverét.
15

Mar amelyik

janoszen · 2013. Szep. 30. (H), 12.36
Mar amelyik, neha nem trivialis.
16

Szerintem...

vbence · 2013. Szep. 30. (H), 12.49
Nekem az a tapasztalatom, hogy így vagy úgy bármilyen környezetben lehetséges. Vagy a kliens képes kezelni push-sholt beállításokat, vagy a virtuális hálózati adapter paraméterei módosíthatók, vagy a DHCP szervertől szerezhető be a megfelelő beállítás. Gyakran mindhárom úton lehetséges.
17

Ket VPN

janoszen · 2013. Szep. 30. (H), 12.50
Kiveve, ha mondjuk ket VPN-t is hasznalnod kell. Onnantol mar nem trivialis milyen DNS resolvert hasznalsz.
18

Nem tipikus

vbence · 2013. Szep. 30. (H), 13.02
Nem tipikus eset, hogy egyszerre több VPN-en lógna az ember, és ha épp ezt teszi akkor is megoldható a fenti eszközök valamelyikével (ahol nem fontos a távoli DNS, ott használható DHCP "addresses only" módban).

Ha neked ezzel ellentétes a tapasztalatod - és nyilván az - akkor azt is készséggel elhiszem.
19

Pelda

janoszen · 2013. Szep. 30. (H), 13.22
Csak pelda volt. Az altalanos tapasztalatom az, hogy ha nem csinalsz globalisan rekurzolhato DNS-t, elobb-utobb valami sz*pasba fogsz utkozni. Pl VPN-nel, halozat-osszevonasnal, stb.
12

túlzás

Gixx · 2013. Szep. 30. (H), 09.42
aki ezeket nem tudja és programozó az szégyellje magát


Ezt azért túlzásnak érzem. Aki nem napi szinten foglalkozik ilyennel, annak miért kéne "tudnia" és miért nem elég "ismernie"?

Különösen, hogy ez már szerintem inkább az üzemeltetés része a dolognak. A legtöbb helyen erre van külön ember/csapat.

Szóval én programozóként nem szégyellem magam, hogy nem tudom, csupán ismerem ezeket. Hallottam róluk, egyszer még az MX-rekordos dologba is beleástam magam, de most nem már nem mondanám vissza fejből a lényegét. Mert nincs rá szükségem.

// Nem mellesleg a Zend Frameworkben az én kódom alapján került be a Deep MX check az domain validatorba. Persze a nevemet szépen kifelejtették a kommentek közül. Mindegy, ez más történet. :)
20

+1

Pepita · 2013. Szep. 30. (H), 13.30
Szerintem sem szégyen, viszont fejlesztőként is erdemes tudni. Manapság nem ritka, hogy neked többet kell tudnod az üzemeltetőnél... Én nagyon várom a folytatást is.
21

Anno épp fordítva láttam: az

H.Z. · 2013. Szep. 30. (H), 13.39
Anno épp fordítva láttam: az üzemeltetőnek kellett ismernie a fejlesztési munkákat is, mert a fejlesztők egyébként az üzemeltethetőséggel nem nagyon törődtek.
23

Igen, de az

Pepita · 2013. Szep. 30. (H), 21.20
"régen volt, tán igaz sem volt". :)
Régen (és sajnos sok helyen most is) egyetlen tárhelyről meg lehetett fektetni a szervert. Idén viszont kaptam olyan support-tanácsot is (nem mondom meg hol), hogy php.ini helyett használjak .htaccess-ben php_value-t. A PHP pedig CGI módban futott... :)
24

Úgy öt-hat éve... :)

H.Z. · 2013. Szep. 30. (H), 21.49
Úgy öt-hat éve... :)
25

Folytatás? :)

T.G · 2013. Okt. 2. (Sze), 07.01
Köszönet! Hasznos cikk! Én is szeretnék csatlakozni azokhoz, akik szerint az itt leírtak szükséges információk, ám mivel napi szinten alig (vagy egyáltalán nem) használjuk, így könnyen elfelejtődik, emiatt tényleg hasznos egy ilyen összefoglaló.

Nem tudom, hogy lehet-e kér, hogy mi legyen a folytatásban? :)

Az itt leírtakat nekem sosem kellett beállítanom, illetve nem is szeretnék, olyan pozícióban lenne, ahol ezt kellene. Ám ennek ellenére az egyik gondom, hogy nem nagyon tudom ellenőrizni, hogy a rendszergazdák ezeket a beállításokat jól állították be vagy sem? Például mi van akkor, ha azt érzem, hogy lassú az oldal, onnantól kezdve tudom ellenőrizni, hogy ha elindul a PHP, de mi történik előtte? Nagyon örülnék, ha néhány példán keresztül megvizsgálnánk, hogy mi lehet a jó és mi a rossz beállítás? Miből tudom meg, hogy valóban rossz beállítások miatt történik az ami... (nem tudom mennyire érződik, de az is probléma nálam, hogy fel sem tudom tenni a jó kérdés, ami kapcsán előrébb jutok:)
26

Domain regisztráció

janoszen · 2013. Okt. 2. (Sze), 07.57
Következőnek a domain regisztrációról tervezek írni, de a hálózat debugolására is sort keríthetünk.
27

Kérések :)

Pepita · 2013. Okt. 2. (Sze), 20.11
Nem csak tőled, Ádámtól is (és Hídvégi Gábortól). Bocsi, kicsit offos is lesz, de egy helyen jobb.
  • MX rekord + e-mail szerver működése, kicsit gyakorlatban is, szerintem ez olyan szorosan kapcsolódik ehhez, hogy rögtön következőnek kéne, és összefűzve őket.
  • Ennek is és a többi nemrég megjelent fontos cikknek a Gábor-féle cikkajánló megfelelő helyére rendezése (update)
  • A Cikkajánlóra jobb link, Ádám, ti tudjátok a statisztikákat, de szerintem a kutya sem klattyol olyat, hogy Cikkek (menü) aztán a link. Tudom, ez design-kérdés is de vagy főmenübe, vagy a Cikkek lenyíló almenüjébe tenném. Nehéz ügy, de jobb helyet érdemel.
  • Gábornak közvetlen hozzáférést kéne adni az ő cikkajánlójának szerkesztéséhez, hogy bármikor tudja update-elni. Plusz valahogy oda kéne írnia (szerintem neki) a témakörökhöz, hogy ilyen-és-ilyen cikket kérünk valakitől. Egy csomó alap hiányzik.
  • Janoszen, légyszi mondj fel a munkahelyeden :) és sorozatgyártsd a cikkeket, mert itt elindítottál - szerintem sokunkban - egy olyan tudásvágyat, amit csak sok cikkel lehet kielégíteni. Hogy közben mit eszel, stb.: remélem eddig spóroltál. :) Komolyan: ez nagyon jó, 2. és 3. részt is kér. + a többi, amiket kértünk. Ez nem kevés, de én bízom benne, hogy ha lassan is, de sikerül. (Valaki igazán finanszírozhatná a cikkírásaidat, de ki?)


Bármennyi is teljesül a kéréseim közül, mindenképp köszönöm, ahogy ezt a cikket is.
28

Nem mondok fel

janoszen · 2013. Okt. 6. (V), 15.35
A munkahelyemen nem mondok fel, mert ahhoz túl jól fizetnek, viszont megfogadtam, hogy a Bécs-Budapest vonatutakat ezen túl cikkírással fogom tölteni. A témaötleteket kéretik mailben elküldeni.
29

+100

Pepita · 2013. Okt. 6. (V), 15.45
megfogadtam, hogy a Bécs-Budapest vonatutakat ezen túl cikkírással fogom tölteni
Előre is köszönöm, mindenki nevében. Összeszedem az ötleteimet, az most néhány nap lesz, aztán megírom a "megrendelőt". :)
Köszi!
30

MÁV

Gixx · 2013. Okt. 7. (H), 09.04
ha MÁV-val jössz, akkor jó hosszú cikkekre számíthatunk ;)
31

3 ora

janoszen · 2013. Okt. 7. (H), 15.40
3 ora oda, 3 vissza. Altalaban 2 hetente egyszer. :)
32

A Windows és a DNS...

Jeno1 · 2014. Aug. 16. (Szo), 06.46
A site-költöztetés nekem is gyomorgörcsöt okozó dolog szokott lenni...
Különösen akkor, ha a szerveroldali kód "idegennél" hostolt adatbázis(ok)hoz (totál más hosting cégek) is kapcsolódik és azok is mozgatásra kerülnek egy lépésben. Nem kívánom senkinek :)
Már megvan a bevett módszerem rá, de egy kisebb imát azért el szoktam mormolni előtte a biztonság kedvéért :D

Ami viszont fontos - és nem volt róla szó eddig, ha jól láttam - az a Windows rendszereknél a kapcsolatokhoz beállított DNS szerverek szekvenciálása és megbízhatósága.

A világ nyolcadik csodájaként hatott rám anno a felismerés, hogy az összes Windows:
- valami agyafúrt, kiszámíthatatlan algoritus következményeképp néha még akkor is képes a secondary DNS szervertől lekérni a cuccot, ha az elsődleges IS elérhető
- ha egy DNS szerver válaszol, hogy "fogalmam sincs, mi az IP címe annak a vacaknak amit kértél" az maximálisan és univerzálisan respektált válasz;
ha van is másik DNS szerver beállítva, még akkor is: meg sem meri kérdezni tőle, mást gondol-e!
Nincs igazi failover; a secondary DNS server hivatalosan csak akkor lép képbe, ha a primary server NEM VÁLASZOL (pl. timeoutol). Ha azt mondja lövete sincs, a secondary felé nem is megy query, mert a válasz megvan: hogy ilyen NINCS.

Konklúzió: az AD server IPjén felül a 8.8.8.8-at secondary-ként kiszórni a klienseknek nagy csapda, mert sűrűn fognak anyázni a kollégák, ha a belső hálózaton dolgoznának :)

Res.: bízzunk a cég szerverében :D Elég az az egy DNS kiszolgáló.
Alt.: Deadwood/MaraDNS : ééévek óta hibátlanul használom ezt az ingyenes kis izét. Localban fut mint service. Egyetlen egy DNS servert állítok be: 127.0.0.1

Nála meg meg lehet adni, milyen címet mivel oldjon fel, melyik serverrel.
Innentől kezdve a .local, .att, .webnx, .test végződésű címeket feloldatom az AD-s serverrel, a többit meg ízlés szerint smartDNS providerekkel, otthoni serverrel, etc. Kinek mire van épp szüksége :)