[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] DNS Map: Mapping Resolution Combining Pull/Push Advantages
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.
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?
FWIW: DNS Map already does separate DNS queries for domain name
resolution and for mapping resolution. A or AAAA records are requested
in the former, MAP records in the latter. And MAP records can be
requested by EID or domain name. (MAP record retrieval by domain name
is used in pre-fetching.)
2. The DNS resolver needs to determine whether a particular EID is
directly available in the routing system or whether it needs a map.
Discovery of whether a mapping is needed for a given EID can be handled
through mapping resolution if you assume that mappable EIDs are always
mapped in packets that cross an edge network border. The existence of
a mapping for an EID is then equivalent to the need to map the EID.
What you suggest in addition is a means to allow an edge network with
mappable EIDs to be reached without mapping by other networks in its
proximity. And yes, using a routing feed to achieve this would be
possible. I would prefer this to be handled as an optional
however, because it can be deployed locally and without special support
from the mapping resolution system.
3. The DNS resolver needs a way to laterally query the caches of
Right, this would be an optimization to reduce latency. Specifically,
it would help taking advantage of pre-fetching more often.
There are two approaches of "pre-loading" an ITR with the mappings it
may need in the near future. It is up to an edge network which approach
to follow, and how to specifically implement it:
- An ITR itself pre-fetches mappings for a given domain name upon a
trigger. This trigger could be a regular DNS query for that domain
name, being forwarded by the ITR. It could also be a trigger from a
local DNS server resolving that domain name on behalf of a client.
- A different network entity than the ITR pre-fetches mappings and makes
them somehow available to the ITR. It could push the mappings to all
local ITRs, or have an ITR pull the mappings when the first data
packet needs to be mapped.
The DNS Map paper actually considers both of these cases.
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.
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