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ókzónáiban különböző célokra különböző rekordtípusokat használnak.
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.
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.
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.
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.
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]
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.
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.
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.
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.
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ő.
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ó.
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
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:
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étlenü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.
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.
A dinamikus DNS (a zóna kliensoldali frissítéséhez) támogatásához szükséges.
Elavult rekordtípusok
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 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ó.
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.
↑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..."
↑ abcRFC 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."
