الدرس 49 · أمن الشبكات: الهجمات ووسائل الدفاع

Defence: DNSSEC and encrypted DNS

لم يُترجم بعد؛ يُعرض باللغة الإنجليزية

In the last lesson a forged DNS reply could poison a resolver's cache. Here the same attack fails. Watch a validating resolver reject the fake, then learn why: every zone signs its records, every parent vouches for its child's key, and the resolver follows those seals up to one key it trusts. Finally, see why signatures alone do not hide what you look up, and how DNS over TLS and DNS over HTTPS do.

12 دقيقة12 خطوات5 أسئلةBeginner

شكل 49 · تفاعلي

جارٍ تحميل الرسم…

أو ← →

اختبر نفسك

5 أسئلة سريعة

اختر إجابة لتعرف السبب. تُحفَظ نتيجتك مع تقدّمك.

01A forged reply reaches a validating resolver before the real one. Why is it rejected?

The attacker can copy the format and even guess the query ID and port, but cannot produce a valid RRSIG without the zone's private key. The reply is bogus and is not cached.

02What does a DS record in the .com zone do?

DS (delegation signer) records live in the parent zone. Each one is a fingerprint of the child's key, and the parent signs it, which links the two zones into a chain.

03Which single key does a validating resolver trust in advance?

Every other key is trusted only because a chain of signed DS records leads back to the root's key, which is built into the resolver.

04Your laptop gets an answer with the AD flag set. What can an eavesdropper on the café Wi-Fi still learn if you use plain DNS?

DNSSEC adds signatures but no encryption. Plain DNS on UDP port 53 can be read by anyone on the path.

05What do DNS over TLS and DNS over HTTPS protect?

They encrypt only the hop to the resolver (DoT on port 853, DoH inside HTTPS). The resolver still sees every name, and DNSSEC is still what proves the answer is genuine.

المصطلحات الأساسية

المسرد

DNSSEC: DNS Security Extensions: signatures added to DNS so a resolver can check that an answer really came from the zone owner and was not changed.
DNSKEY: A record holding a zone's public key. Resolvers use it to check the zone's signatures.
RRSIG: A record holding a signature over a set of records, made with the zone's private key.
DS record: Delegation signer: a hash of a child zone's key, published and signed in the parent zone. It is how a parent vouches for its child.
Trust anchor: The one key a validating resolver trusts in advance: the root zone's key, built into the resolver.
Bogus: The verdict for data whose signatures do not check out. A validating resolver throws it away and never caches it.
AD flag: Authenticated data: a bit the resolver sets in its reply when the answer passed DNSSEC validation.
DoT and DoH: DNS over TLS (port 853) and DNS over HTTPS: two ways to encrypt DNS between your device and the resolver.

تفاصيل إضافية

الملاحظات والمصادر

192.0.2.53, 203.0.113.10 and 198.51.100.66 are RFC 5737 documentation addresses and 192.168.1.20 is a private RFC 1918 address; the example.com keys, key tags and signatures are illustrative.
A validating resolver that receives a reply that fails validation may ask the same or another server again; if nothing validates it returns SERVFAIL instead of an unverified answer (RFC 4035 §5.5).
Real zones usually split the work between two keys: a key-signing key (KSK) that signs only the DNSKEY set and is the one the parent's DS record points at, and a zone-signing key (ZSK) that signs everything else.
DNSSEC can also prove that a name does NOT exist, with signed NSEC or NSEC3 records (RFC 4034, RFC 5155), so an attacker cannot forge a "no such name" reply either.
DNSSEC protects you only when the zone is signed and your resolver validates. Many zones are still unsigned, and their answers stay unprotected.
Encrypted DNS protects only the hop between your device and the resolver. The resolver still sees every name, and its own queries to authoritative servers are usually plain text.
Even with encrypted DNS an observer still sees the IP addresses you then connect to, and the server name in the TLS ClientHello unless Encrypted Client Hello (ECH) is used.
DNS over QUIC (RFC 9250) is a third option, on UDP port 853.

اختبار يتاح بعد الخطوة الأخيرة.