# Mi a DNS-gyorsítótár-mérgezés?

> A Domain Name System (DNS) gyorsítótár-mérgezés (DNS cache poisoning) akkor történik, amikor a rekurzív resolver hamis DNS-adatot fogad el, és hitelesként tárolja.

- Kanonikus URL: https://yellowcube.eu/hu/glossary/domain-name-system-cache-poisoning/
- Kiadó: Yellow Cube
- Nyelv: hu
- Kapcsolat: hello@yellowcube.eu

## Tartalom

A későbbi kliensek a hamis leképezést a gyorsítótárból kaphatják meg, ami a forgalmat átirányítja vagy hibákat okoz, amíg a bejegyzés le nem jár, ki nem cserélődik vagy el nem távolítják. A támadás a gyorsítótárazott feloldási adatokat rontja meg; nem igényli a domain regisztrációja vagy autoritatív zónája feletti irányítást.

A hamis adat hamisított válaszban érkezhet vagy kompromittált feloldási úton. Az erős egyeztetés (matching) megnehezíti az útvonalon kívüli hamisítást. A DNS Security Extensions (DNSSEC) validálás elutasítja a módosított aláírt adatot, ha bizalmi lánc létezik, de nem hitelesíti az aláíratlan zónákat vagy minden kliens–resolver szakaszt.

### Legfontosabb pontok

- **Hatókör:** Azonosítani kell az érintett resolvereket, a neveket és rekordtípusokat, hogy mikor került a rekord a gyorsítótárba, mennyi a hátralévő élettartama, és mely kliensek vagy szolgáltatások kapták meg.
- **Bizonyítékok:** A gyorsítótár-tartalmat össze kell vetni az autoritatív adatokkal és a validáló resolverekkel, majd át kell tekinteni a válasznaplókat, a továbbítási útvonalakat, a változásokat, a validálási eredményeket és az átirányított tevékenységet.
- **Kockázatcsökkentés:** Naprakészen kell tartani a resolver-szoftvert, erős válaszegyeztetést és forrásport-entrópiát kell használni, korlátozni kell a rekurziót és az adminisztrációt, ahol indokolt DNSSEC-t kell validálni, védeni kell a resolver-csatornákat, és monitorozni kell a váratlan változásokat.
- **Fontos korlát:** A meglepő válasz nem automatikusan mérgezés. A gyorsítótárazás, az osztott DNS, a továbbítás, a helyi felülírások, a terheléselosztás és a konfigurációs hibák a nyilvános adatoktól eltérő válaszokat produkálhatnak; az aláírási hibák is okozhatnak DNSSEC-validálási hibákat.

### Kapcsolódó kifejezések

[Domainnév-rendszer (DNS)](<https://yellowcube.eu/hu/glossary/domain-name-system/>) · [DNS-biztonság](<https://yellowcube.eu/hu/glossary/domain-name-system-security/>) · [DNS-eltérítés](<https://yellowcube.eu/hu/glossary/domain-name-system-hijacking/>) · [Élettartam (TTL)](<https://yellowcube.eu/hu/glossary/time-to-live/>) · [Pharming](<https://yellowcube.eu/hu/glossary/pharming/>)

### Források

[IETF RFC 5452: Measures for Making DNS More Resilient against Forged Answers](https://www.rfc-editor.org/rfc/rfc5452.html) · [NIST SP 800-81 Rev. 3: Secure DNS Deployment Guide](https://csrc.nist.gov/pubs/sp/800/81/r3/final) · [ICANN: DNSSEC—What Is It and Why Is It Important?](https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en/)

## Forrásmegjelölés és hatókör

Ez a Markdown-változat ugyanazokból a jóváhagyott tartalmi rekordokból készül, mint a kanonikus HTML-oldal. Hivatkozáskor a kanonikus URL-t használja.