DNS-rekordtípusok listája
Ez a DNS-rekordtípusok listája áttekintést nyújt a DNS (Domain Name System) zónafájljaiban tárolt erőforrásrekordokról (adatbázisrekordokról).
A DNS az internetes tartománynevekkel és címekkel kapcsolatos információk elosztott, hierarchikus és redundáns adatbázisa. Ezen DNS-kiszolgálók zónáiban különböző célokra különböző rekordtípusokat használnak.
Erőforrásrekordok
[szerkesztés]| Típus | Érték (decimális) | RFC | Leírás | Funkció |
|---|---|---|---|---|
| A | 1 | RFC 1035[1] | címrekord | 32 bites IPv4-címmel tér vissza, feladata leggyakrabban a hosztnév és a hozzá tartozó IP-cím összerendelése, de használják a DNSBL-ek, az RFC 1101-ben alhálózati maszkokat tárolnak benne stb. |
| AAAA | 28 | RFC 3596[2] | IPv6-címrekord | 128 bites IPv6-címmel tér vissza, feladata leggyakrabban a hosztnév és a hozzá tartozó IP-cím összerendelése. |
| AFSDB | 18 | RFC 1183 | AFS adatbázisrekord | Egy AFS-cella adatbázisszervereinek elérési helye. AFS-kliensek használják a helyi doménjükön kívül eső AFS-cellák elérésére. Ennek a rekordnak egy altípusát használta a mára elavult DCE/DFS fájlrendszer. |
| APL | 42 | RFC 3123 | Address Prefix List (címelőtag-lista) | Kísérleti. Különböző címtartományok listái, pl. CIDR formátumban. |
| CERT | 37 | RFC 4398 | Certificate record (tanúsítványrekord) | PKIX, SPKI, PGP stb. tanúsítványokat tárol. |
| CNAME | 5 | RFC 1035[1] | Kanonikus névrekord | A tulajdonos kanonikus vagy elsődleges neve. Egy névről egy másikra mutat (alias): a DNS-lekérdezés az új név lekérdezésével fog folytatódni. |
| DHCID | 49 | RFC 4701 | DHCP identifier (DHCP-azonosító) | A DHCP FQDN-opciójával együtt használatos. |
| DLV | 32769 | RFC 4431 | DNSSEC Lookaside Validation record | DNSSEC bizalmi horgonyok a DNS bizalmi láncon kívüli publikálására szolgál. Formátuma megegyezik a DS rekordéval. Az RFC 5074 leírja használatuk egy módját. |
| DNAME | 39 | RFC 2672 | delegation name | A DNAME létrehoz egy aliast egy névhez és a hozzá tartozó al-nevekhez, a CNAME-től eltérően, ami csak egyetlen névről mutat egy másikra. A CNAME-hez hasonlóan a DNS-lekérdezés az új név lekérdezésével fog folytatódni. |
| DNSKEY | 48 | RFC 4034 | DNS Key record | A DNSSEC-ben használt kulcsrekord, formátuma megegyezik a KEY rekordéval. |
| DS | 43 | RFC 4034 | Delegation signer | Egy delegált zóna DNSSEC aláírókulcsának meghatározására szolgáló rekord. |
| HIP | 55 | RFC 5205 | Host Identity Protocol | Elkülöníti az IP-címek végpont-azonosító és helymeghatározó szerepkörét. |
| IPSECKEY | 45 | RFC 4025 | IPSEC Key | IPSEC-hez használható kulcsrekord |
| KEY | 25 | RFC 2535[3] és RFC 2930[4] | key record (kulcsrekord) | A SIG(0) (RFC 2931) és a TKEY (RFC 2930) használja.[5] Az RFC 3445 megszüntette alkalmazásszintű használatát és a DNSSEC-re korlátozta azt,.[6] az RFC 3755 pedig a DNSSEC-hez a DNSKEY-t jelöli ki használatra a továbbiakban.[7] Az RFC 4025 az IPsec-beli használatra az IPSECKEY-t jelöli ki.[8] |
| KX | 36 | RFC 2230 | Key eXchanger record (kulcscsere-rekord) | Egyes kriptográfiai rendszerekben (de nem a DNSSEC-ben) a hozzá tartozó domain kulcskezelő ügynökét azonosítja. Az IETF szabványosítási folyamatán kívül, informális használatban van. |
| LOC | 29 | RFC 1876 | Location record (helyrekord) | Egy tartománynévhez tartozó földrajzi helyet határoz meg. |
| MX | 15 | RFC 1035[1] | mail exchange record | A tartománynévhez rendelt levéltovábbító ügynökök (Mail Transfer Agent, MTA) listája |
| NAPTR | 35 | RFC 3403 | Naming Authority Pointer | Lehetővé teszi a tartománynevek reguláris kifejezésekkel történő újraírását (URI-kra, további tartománynevekre stb.) |
| NS | 2 | RFC 1035[1] | name server record (névkiszolgáló-rekord) | Kijelöli egy DNS-zóna számára használható autoritatív névkiszolgálókat. |
| NSEC | 47 | RFC 4034 | Next-Secure record (következő biztonságos rekord) | A DNSSEC része; egy név nem létezését igazolja. Formátuma megegyezik az elavult NXT rekordéval. |
| NSEC3 | 50 | RFC 5155 | NSEC record version 3 | A DNSSEC kiterjesztése, egy név nem létezését igazolja a zónabejárás (információszivárgás) veszélye nélkül. |
| NSEC3PARAM | 51 | RFC 5155 | NSEC3 parameters | Az NSEC3 paraméterrekordja. Kiderül belőle, hogy a nem létezési igazolás kiállításakor milyen algoritmussal és milyen salttal képeztek hasht a zóna neveiből, és hogy a DNSSEC-kel alá nem írt neveket is belefoglalták-e. |
| PTR | 12 | RFC 1035[1] | pointer record (mutatórekord) | Kanonikus névre mutat. A CNAME-től eltérően nem történik további, DNS-beli feldolgozás, maga a név a visszatérési érték. Leggyakrabban reverse DNS-lekérdezéseknél használják, de pl. az Apple DNS-SD-jében is használják. |
| RRSIG | 46 | RFC 4034 | DNSSEC signature | Egy DNSSEC-kel biztosított rekord(halmaz)hoz tartozó aláírás. Formátuma megegyezik a SIG rekordéval. |
| RP | 17 | RFC 1183 | Responsible person | A tartományhoz rendelt felelős személy. Általában egy e-mail-cím, amiben a @ karaktert . helyettesíti. |
| SIG | 24 | RFC 2535 | Signature | A SIG(0) (RFC 2931) és a TKEY (RFC 2930) által használt aláírásrekord.[7] Az RFC 3755 szerint a DNSSEC protokoll esetében az RRSIG váltja ki.[7] |
| SOA | 6 | RFC 1035[1] | start of authority record | Irányadó információk a DNS-zónáról; az elsődleges névkiszolgáló, a tartomány rendszergazdájának e-mail-címe, a tartomány sorozatszáma, a zóna frissítési időközei. |
| SPF | 99 | RFC 4408 | Sender Policy Framework | Az SPF protokoll része, a korábban TXT rekordokban tárolt SPF adatoknak. A formátum megegyezik a korábbi TXT rekordéval. |
| SRV | 33 | RFC 2782 | Service locator (szolgáltatáskereső) | Általános szolgáltatás-helymeghatározó rekord, újabb protokollok számára, elkerülendő a protokoll-specifikus rekordokat, mint az MX. |
| SSHFP | 44 | RFC 4255 | SSH Public Key Fingerprint | Egy hoszt SSH nyilvános kulcsának ujjlenyomatainak tárolására szolgáló erőforrásrekord. A hoszt autentikusságának megállapítását segíti. |
| TA | 32768 | N/A | DNSSEC Trust Authorities | Az aláírt DNS gyökér nélküli DNSSEC protokoll javaslatához tartozik. A részletekhez lásd: IANA database és Weiler Spec. Formátuma a DS rekordéval megegyező. |
| TKEY | 249 | RFC 2930 | secret key record | A TSIG-gel használatos, a hozzátartozó KEY RR nyilvános kulccsal titkosított kulcs („keying material”) tárolására.[9] |
| TSIG | 250 | RFC 2845 | Transaction Signature (tranzakció-aláírás) | Dinamikus DNS-frissítések kliensforrásának autentikálására, vagy annak ellenőrzésére, hogy a válasz a megbízhatónak minősített rekurzív névkiszolgálótól jött.[10] A DNSSEC-hez hasonló. |
| TXT | 16 | RFC 1035[1] | Text record (szöveges rekord) | Eredetileg tetszőleges, emberi fogyasztásra szánt szöveg tárolására szolgált. Az 1990-es évek elejétől egyre többször tároltak benne gépi adatokat az RFC 1464 szerint, pl.:opportunista titkosítás, a Sender Policy Framework (ez végül saját SPF rekordot kapott), DomainKeys, DNS-SD stb. |
Egyéb rekordtípusok és pszeudo-erőforrásrekordok
[szerkesztés]Vannak további erőforrásrekordok, amelyek valamilyen egyszerű információt nyújtanak (pl. egy HINFO rekord a gazdagép platformjáról/OS-éről ad leírást), mások kísérleti funkciókhoz tartozó adatokat tartalmaznak. A „típus” mezőt is több protokoll használja műveleteiben. Az alábbi pszeudo-rekordtípusok a zónafájlban nem tárolódnak, csak átvitelkor (on-the-wire) értelmezhetők:
| Code | Number | RFC | Leírás | Funkció |
|---|---|---|---|---|
| * | 255 | RFC 1035[1] | Az összes gyorsítótárazott rekord | Visszaadja az összes rekordot, valamennyi típusból, amiről a névkiszolgálónak tudomása van. Ha nincs semmilyen információja a névről, a kérést továbbítja. A listázott rekordok nem feltételenül teljesek. Ha például egy névhez A és MX rekord is tartozik, de a névkiszolgáló gyorsítótárában csak az A rekord szerepel, akkor csak az A rekord lesz benne a válaszban. Egyes megvalósítások ANY típusnak hívják, köztük a Windows nslookup-ja és a Wireshark. |
| AXFR | 252 | RFC 1035[1] | Autoritatív zónatranszfer | A teljes zónafájlt továbbítja az elsődleges névkiszolgálóról egy másodlagosra. |
| IXFR | 251 | RFC 1995 | Inkrementális zónatranszfer | Adott zóna továbbítását kéri, de csak egy korábbi sorozatszámtól képezett különbségeket kéri elküldeni. Ha konfigurációs okból vagy a kívánt delták hiányában a kiszolgáló nem tud eleget tenni a kérésnek, átküldheti helyette a teljes zónát (AXFR) is. |
| OPT | 41 | RFC 2671 | Option | Pszeudo-rekordtípus, az EDNS támogatásához szükséges. |
| UPDATE | 5 | RFC 2136 | Update | A dinamikus DNS (a zóna kliensoldali frissítéséhez) támogatásához szükséges. |
Elavult rekordtípusok
[szerkesztés]Néhány, eredetileg használatban lévő rekordtípus fölött már eljárt az idő. Az IANA-nál felsorolt rekordok közül egyeseket különböző okokból csak igen korlátozottan használnak. Ezek közül vannak elavult minősítésűek, másokat ritka, különös szolgáltatásokhoz használnak vagy szolgáltatások régebbi verzióiban, végül néhányhoz megjegyzésként hozzáfűzték, hogy „nincsenek rendben”.
- Az RFC 973 óta idejétmúlt: MD(3), MF (4), MAILA (254)
- Levelezőlisták előfizetői listáját a DNS-ben publikáló rekordok: MB(7), MG(8), MR(9), MINFO(14), MAILB (253). Az RFC 883 által meghatározott cél az volt, hogy az MB helyettesítse az SMTP VRFY parancsot, az MG az SMTP EXPN parancsot, az MR pedig az "551 User Not Local" SMTP-hibát. A későbbi RFC 2505 útmutatása szerint a VRFY és EXPN parancsokat célszerű letiltani, ami valószínűtlenné teszi, hogy az MB és MG rekordok használatát valaha is bevezessék.
- Nem megbízhatónak minősítette az RFC 1123 (további információk az RFC 1127-ben): WKS(11)[11] (well-known service)
- Tévedések: NB(32), NBSTAT(33) (az RFC 1002 szerint); a típusszámok jelenleg a NIMLOC és SRV RR-eknek vannak kiosztva.
- Az RFC 1035 által elavultnak minősített: NULL(10). Az RFC 883 definiálta a teljesülési lekérdezéseket ("completion queries", opcode 2 és talán 3), amik ezt a rekordot használták. Később az RFC 1035-ben a 2-es opcode-ot a "status" kapta, az opcode 3-at fenntartották)
- Az IPv6 kezdeti szakaszában definiálták, de később kísérletinek minősítette az RFC 3363: A6(38)
- A DNSSEC frissítésével (RFC 3755) idejétmúlttá vált: NXT(30). Ugyanebben az időben a KEY és SIG alkalmazhatóságát megszüntették a DNSSEC protokoll esetében.
- Jelenleg semmilyen említésre méltó alkalmazás nem használja: HINFO(13), RP(17), X25(19), ISDN(20), RT(21), NSAP(22), NSAP-PTR(23), PX(26), EID(31), NIMLOC(32), ATMA(34), APL(42)
- A Kitchen Sink internet draft definiálja, de nem jutott el az RFC státusig: SINK(40)
- A LOC rekord egy korábbi, korlátozott képességű verziója: GPOS(27)
- Az IANA fenntartotta, de egyetlen RFC sem definiálta őket [1] és a BIND az 1990-es évek elején megszüntette a támogatásukat: UINFO(100), UID(101), GID(102), UNSPEC(103)
Az RP(17) (Responsible Person) egy specifikus gazdagép, alhálózat vagy a SOA rekordtól eltérő tartományi szint kapcsolattartójának megadására használható.
További információk
[szerkesztés]- IANA DNS Parameters registry. (Hozzáférés: 2008. május 25.)
- Google: A DNS alapvető ismertetése. (Hozzáférés: 2011. november 17.)
- Az erőforrásrekordok típusai. (Hozzáférés: 2011. november 27.)[halott link]
Fordítás
[szerkesztés]- Ez a szócikk részben vagy egészben a List of DNS record types című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
Jegyzetek
[szerkesztés]- ↑ a b c d e f g h i Paul Mockapetris: RFC 1035: Domain Names - Implementation and Specification. Network Working Group of the IETF (Internet Engineering Task Force), 1987. november 1.
- ↑ RFC 3596: DNS Extensions to Support IP Version 6. The Internet Society, 2003. október 1.
- ↑ RFC 2535, §3
- ↑ RFC 3445, §1. "The KEY RR was defined in [[[RFC:2930|RFC 2930]]]..."
- ↑ RFC 2931, §2.4. "SIG(0) on the other hand, uses public key authentication, where the public keys are stored in DNS as KEY RRs and a private key is stored at the signer."
- ↑ RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..."
- ↑ a b c RFC 3755, §3. "DNSKEY will be the replacement for KEY, with the mnemonic indicating that these keys are not for application use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace SIG, and NSEC (Next SECure) will replace NXT. These new types completely replace the old types, except that SIG(0) [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY."
- ↑ RFC 4025, Abstract. "This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445."
- ↑ RFC 2930, §6. "... the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR RFC 2535."
- ↑ RFC 2845, abstract
- ↑ RFC 1123 section 2.2, 5.2.12, 6.1.3.6
