Subject: [dnsext] Channel Security Example

From: "George Barwood" <[email-masked]>
Date: Tue, 9 Mar 2010 22:22:09 -0000

I thought an example might be useful, to explain how Channel ( Link level ) Security can work in conjunction with DNSSEC
to secure "user" zones against network attacks without signing them.

[ QRP Draft is at http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport-16 ]

Suppose a client needs to resolve [ www.example.com A ].

This is how a local ( trusted ) recursive resolver proceeds:

(1) Send unencrypted priming query [ . NS ] to a root server

Response is

. NS a.root-servers.net
a.root-servers.net A .................

[ . NS ] will be signed with DNSSEC.

(2) Send unencrypted query [ a.root-servers.net A ] to a.root-servers.net

Response is

a.root-servers.net A .................
a.root-servers.net QRPK ..........................

Note : no privacy issue up to here. All these records will be signed by DNSSEC ( assuming root-servers.net is signed ). The QRPK record is a public key, used to encrypt and authenticate queries to a.root-servers.net.

(3) Send encrypted query [ www.example.com A ] to a.root-servers.net

Result will be a referral

com NS a.gtld-servers.net
a.gtld-servers.net A ......

Note: this is not signed under current DNSSEC rules, but it is channel protected.

(4) Obtain authoritative NS for com, send unencrypted query [ com NS ] to a.gtld-servers.net

Result will be

com NS a.gtld-servers.net
a.gtld-servers.net A ......
a.gtld-servers.net QRPK ..........................

Note : very minor privacy issue for this step ( but see Notes below). All these records should be DNSSEC signed.

(5) Send encrypted query [ www.example.com A ] to a.gtld-servers.net

Result will be a referral

example.com NS a.big-reg.net

Note: this is not signed under current DNSSEC rules, but it is channel protected.

(6) Send encrypted query [ a.big-reg.net A ] to a.gtld-servers.net

Result will be referral
big-reg.net NS a.ns.big-reg.net
a.ns.big-reg.net A ........

Note: this is not signed under current DNSSEC rules, but it is channel protected.

(7) Obtain authoritative NS for big-reg.net : send unencrypted query [ big-reg.net NS ] to a.ns.big-reg.net

Result will be

big-reg.net NS a.ns.big-reg.net
a.ns.big-reg.net A ......
a.ns.big-reg.net QRPK ..........................

Note : minor privacy issue for this step ( but see Notes below). All these records will be DNSSEC signed.

(8) Finally send encrypted query  [ www.example.com A ] to a.ns.big-reg.net

Result will be

www.example.com A .........

Result is not signed by DNSSEC, but is channel protected.

Notes: 

(1) All this relies on a trusted recursive resolver - simplest solution is for resolver to be local.

(2) We have gained some privacy. If our ISP is monitoring our DNS traffic, it knows
that we have accessed a "com" domain, which is hosted on "big-reg.net".
But our ISP does not know (from the DNS traffic) that we are accessing www.example.com

(3) If QRPK records can be uploaded to parent zone, steps (3) and (7) can be encrypted,
which gains some extra privacy.

(4) The really good thing is that the administrator for www.example.com has not
done anything at all, but the resolution of www.example.com has nevertheless been
secured against network attacks ( including MITM attacks ).

Regards,
George Barwood
PS It's a long example, hope I have not made too many typos/errors.