[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] RE: [RAM] dns discover in map-and-encaps schemes
Dino,
> -----Original Message-----
> From: Dino Farinacci [mailto:dino@cisco.com]
> Sent: Monday, March 19, 2007 5:23 PM
> To: Templin, Fred L
> Cc: rrg; ram@iab.org
> Subject: Re: [RAM] dns discover in map-and-encaps schemes
>
> > 1) source does DNS lookup for the FQDN "dest.example.com".
> > 2) source's DNS server is co-resident on the ingress tunnel router
> > and performs a lookup in the global DNS for a well-known prefix
> > appended to the FQDN suffix, e.g.: "egress.example.com".
> > 3) source's DNS server gets back locators for the egress tunnel
> > router from the global DNS, then sends an IP-in-IP encapsulated
> > RFC4620 Node Information Query asking the egress tunnel router
> > to resolve the FQDN "dest.example.com".
> > 4) egress tunnel router returns identifers associated with
> > "dest.example.com"; ingress tunnel router caches the resolution
> > and returns the resolution to the source as response to the
> > "real" DNS query.
>
> What happens when I type "ping <global-address>" on the source?
Not quite certain what you mean; do you mean ping the source IP
address from the destination IP address after the source has done
the DNS mapping for the destination. The intent is the egress tunnel
router nearest the destination will have cached the source IP to
locator mapping and so the ping will succeed.
> What if DNS is down, do I lose global connectivity?
What happens if the DNS is down in today's Internet? You can
ping any global IPv4 address and connect to any global IPv4
services by specifying an IP address instead of a FQDN, and
the very same will be true for this scheme. The only thing
you *won't* be able to do is ping IPv6 addresses and connect
to IPv6 services that are deeply embedded in distant sites,
but that is the very same condition as for devices that are
deeply embedded behind NATs in todays Internet. Bottom line
is the situation for loss of global DNS is no different from
and no worse than for the existing condition of today's Internet.
> What if one of the two domain names don't exist in DNS?
The idea is that the global DNS will only ever contain FQDNs
for IPv4-based services; not for any IPv6-based services. So,
there will be only one FQDN in the DNS ("egress.example.com"),
and the FQDN "peer.example.com" will be in the site-specific
name service for the peer's site. The "egress.example.com"
gives the ingress tunnel router unambiguous indication that
the egress tunnel router is participating in the scheme, so
the absense of this FQDN is a clear indication that the peer's
site does *not* implement the scheme. This only means that the
egress tunnel router is responsible for ensuring that its FQDN
is well-maintained in the global DNS.
> What if network administrators are totally against making routers DNS
> servers?
I want that the function be moved closer to the end devices, and
not in core routers - but, see more below:
> What if your ITR is a low-end router where it can (not) store both the
> DNS cache and mapping database?
The router doesn't need to store the full DNS cache, because the
function it is performing is not exactly that of a full DNS server.
It is really a "two-faced" DNS server that can resolve the FQDNs
for end nodes that are within the same site, but acts as a DNS
resolver for FQDNs for end nodes that reside within different
sites. So, it does not keep a database of global FQDN-to-resource
record mappings - it resolves them from another DNS server just
the same as an ordinary DNS resolver would do.
> What I am trying to say is, some things need to go into the network
> and some things should just stay out of the network.
I'm all for pushing the function closer to the end devices, and
preferrably on the end devices themselves. That would be consistent
with RFC1955.
Thanks - Fred
fred.l.templin@boeing.com
--
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