[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] DNS Map: Mapping Resolution Combining Pull/Push Advantages
- To: "Christian Vogt" <email@example.com>
- Subject: Re: [RRG] DNS Map: Mapping Resolution Combining Pull/Push Advantages
- From: "William Herrin" <firstname.lastname@example.org>
- Date: Tue, 26 Feb 2008 11:29:30 -0500
- Cc: "Routing Research Group Mailing List" <email@example.com>
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=k8gtHJVSfGvVWJI8DyTCppgBYnGt10YNjkVGbMUZjzA0l/cN+45rsUjjhcqn+h0tQK+i5SROUoR2qTMH0uKZ3q+S+KHI+Nf2DFBR1q7HDwm3I05gMHjqmKzew39Y6seb98DbMAa37OwqxY7pxkKSMcCnv+iPZ7ecIgQV5oRUuoI=
- In-reply-to: <AE3DBEBF-27F0-4859-80B2-A99F8CA1D533@nomadiclab.com>
- References: <AE3DBEBF-27F0-4859-80B2-A99F8CA1D533@nomadiclab.com>
On Tue, Feb 26, 2008 at 3:57 AM, Christian Vogt
> system that combines advantages of push and pull systems. DNS Map
> exploits the non-critical time hosts spend waiting for a domain name
> resolution, by "pre-fetching" the mappings that tunnel routers are
> likely to need in the immediate future. This allows DNS Map to support
I should qualify my prior post: I think your idea for pre-fetching the
map is interesting.
There are a couple things you'll need to do to make it work:
1. The DNS resolver has to make a second query for the EID MAP once it
knows the EID. Looking to the authoritative server for a particular
entry is how DNS resolvers verify that the the result is authentic.
2. The DNS resolver needs to determine whether a particular EID is
directly available in the routing system or whether it needs a map.
This could be done by giving the resolver a routing feed or by
including a record in the additional section of the DNS response for
the hostname that means a map lookup is required. The routing feed is
probably better. The latter would create some administrative overhead
and a split horizon problem because the address is directly available
in some parts of the 'net (e.g. those on the near-side of the ETR) and
only available via a map in others.
3. The DNS resolver needs a way to laterally query the caches of
nearby resolvers. That way if the ITR uses a different resolver than
the client but the resolver happens to be nearby, the ITR's resolver
can still get a hold of the pre-fetched map. Currently a recursive
query will cause the neighboring resolver to go out and fetch the
records while a non-recursive query will cause it to return only
If you do all this then whatever the round trip time is between the
resolver and the client, you get about that much of a head start on
the map pull. If the client happens to be 150 ms away on a dialup, you
could well have the map by the time the client's TCP SYN reaches the
ITR. If the resolver is 20ms away over broadband, you probably won't
but you will have a 20ms head start.
Prefetch in the original style you describe could also be used in some
other non-DNS pull-based mapping system where a different
authentication approach would allow the hostname lookup to return both
the address and the address map. That would imply replacing the DNS as
a deployment prerequisite.
William D. Herrin firstname.lastname@example.org email@example.com
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
to unsubscribe send a message to firstname.lastname@example.org 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