DNS-rekordtípusok listája

A Wikipédiából, a szabad enciklopédiából

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 | forrásszöveg szerkesztése]

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ása 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 emailcí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 emailcí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 | forrásszöveg szerkesztése]

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 | forrásszöveg szerkesztése]

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 | forrásszöveg szerkesztése]

Fordítás[szerkesztés | forrásszöveg szerkesztése]

Jegyzetek[szerkesztés | forrásszöveg szerkesztése]

  1. ^ 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
  2. RFC 3596: DNS Extensions to Support IP Version 6. The Internet Society, 2003. október 1
  3. RFC 2535, §3
  4. RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."
  5. 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."
  6. RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR..."
  7. ^ 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."
  8. 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."
  9. 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]."
  10. RFC 2845, abstract
  11. RFC 1123 section 2.2, 5.2.12, 6.1.3.6