[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] DNS Map: Mapping Resolution Combining Pull/Push Advantages



On Sun, Mar 2, 2008 at 8:05 AM, Christian Vogt
<christian.vogt@nomadiclab.com> wrote:
>  DNS Map handles mapping resolution /separately/ from regular domain
>  name resolution.  It uses separate DNS queries and different DNS
>  resource records.

Hi Christian,

You talk about initiation by the DNS server for prefetching when it
sees an A record query. This is an interesting idea. For it to work,
some component of your mapping system will need to interact with the
DNS server that performs the A-record query.


>  Not sure I understand your comment right.  Do you recommend that a
>  mapping should always come from the same (authoritative) DNS server
>  as the EID?

Even if you look up something like "www.herrin.us MAP?" instead of
accepting the MAP as an additional record to the AAAA response, HOW DO
YOU KNOW what EIDs the authoritative server for herrin.us is permitted
to offer MAP records for? If you blindly trust that the information is
correct, a rogue DNS server can take over traffic from your system.

The DNS authentication model says that you know because any record
retrieved from the authoritative server for herrin.us MUST end in
herrin.us and any record which does not MUST be discarded by the
resolver. In your model, the query for "www.herrin.us MAP?" returns
"ABC::1 MAP 1.0.0.1". ABC::1 does not end in "herrin.us".

You don't magically know which server is authoritative to herrin.us.
You know because the resolver asked a root server "What servers are
authoritative for www.herrin.us" and it told the resolver, "These
servers are authoritative for .us". Then the resolver asked one of
these servers, "What servers are authoritative for www.herrin.us" and
it told the resolver, "those servers are authoritative for herrin.us."

How do you follow that authority chain for a map record for ABC::1
when you don't yet know that www.herrin.us has a AAAA for ABC::1?


>  This is why neither the use of different DNS resolvers in hosts and
>  Six/One routers, nor reordering of equal-priority resource records,
>  nor caching should be a problem.

When you ask the DNS guys to add MAP records to the protocol, one of
the early things they'll tell you is: record ordering is not the
responsibility of the DNS server or the DNS protocol. If your
application requires the records in a particular order then the MAP
records themselves should designate that order.

If you're going to use DNS, why go against the grain?


>  > Prefetch in the original style you describe could also be used in some
>  > other non-DNS pull-based mapping system [...]
>
>  That's correct.  Pre-fetching is a mapping resolution technique that
>  applies to pull systems in general.

What I mean is that if you designed a pull-based mapping system in
which response authentication was not tied up in the query hierarchy
then your prefetching during the name lookup could work as you
envision. DNS is NOT such a system.

Perhaps you might use cryptographic signing by a certificate authority
so that a response record can be authenticated independently of the
query or source. In such a system, you'd have to supply several
cryptographic elements in the response from the authoritative server:

1. An address scope of authority statement signed by the address
authority indicating that a particular public key is valid for
authenticating map records within a given CIDR block.

2. A MAP record in the CIDR block signed by the private key for which
the public key is valid.

This approach has three obvious drawbacks:

A. It requires more bytes than can comfortably fit in a 512 byte
payload for a standard DNS response so if you want to keep things
efficient you're necessarily into a new protocol, not just something
layered on top of DNS.

B. It requires each resolver to maintain a truly massive CRL since
every time an address space is redelagated the old certificate has to
be revoked.

C. The resolver has to run a relatively slow cryptographic algorithm
for each and every response.

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg