[Ietf-not43] dns mapping

[Eric A. Hall]

This message is an attempt to address Ed's concern that everything has to
be mapped to DNS, or that DNS is the only allowable mapping service.

First, let me talk about the requirements, then I'll address the issue of
implementation considerations.

Section 3.2.6 of the -05 requirements seems to specifically require
mapping to DNS delegations, but the last sentence in 3.2.6.2 clarifies
that it isn't required in all cases:

| 3.2.6 DNS Delegation Referencing
|
| 3.2.6.1 Protocol Requirement
|
|  The protocol MUST use the delegation authority model available in DNS
|  [1] as the primary means for determining the authoritative source for
|  information regarding domains or any other objects when applicable.
|
| 3.2.6.2 Service Description
|
|  The intent of this requirement is to have clients use the DNS
|  delegation model to find servers authoritative for resources instead
|  of using a master or central server containing pointer information.
|  In other words, when a resource is naturally mapped by DNS, the
|  desired behavior is to consult the DNS to find an authoritative
|  server containing information about that resource.  Using
|  'example.com', the authoritative server for information about
|  example.com according to the registrant of that domain may be found
|  by querying the DNS zone for example.com.  To find the registry
|  information for example.com, the DNS zone for com should be queried.
|
|  There are cases where resources will not naturally map into the DNS
|  delegation hierarchy.  This requirement is not meant to force such a
|  mapping.

Reviewing the mail between Andy, Marcos and myself, we wanted to enforce
the point that some kind of external delegation system had to be used in
all cases (that a crisp-specific, centralized database could not be used)
but that DNS had to be used as the external delegation system for domain
name resources in particular.

So the requirements more-or-less say that any delegation system *can* be
used for any resource other than domain names. If the requirements imply
otherwise, then that's what they are supposed to say anyway.

As far as FIRS goes, there are generally two places where domain name
appear, but only of those instances are related to the above. The two
instances are (1) mapping inputs to an LDAP partition according to the
resource-specific behavioral rules, and (2) specifying the name of the
target partition in the resulting query. I think that these are being
viewed as one-and-the-same, even though they are actually separate.

Mapping a resource name to an LDAP partition is a client operation, with
the client examining the input and then determining the appropriate
partition to use for the initial query. For example, the FIRS
specification for ASNs currently says that clients must use the LDAP
servers associated with the asn.arpa zone by default, while the IPv4
specification says that FIRS clients must use the LDAP servers associated
with the in-addr.arpa zone by default, while the IPv6 specification says
to use ip6.arpa by default. In all three of these cases, the data in the
LDAP servers will be used to answer the queries and generate referrals, so
the data in those servers (wherever that information is sourced from) is
the authoritative delegation data, and any DNS information that may be
used is limited to specifying the target partition by name (eg, locating
the top-level partitions and/or any referral targets).

So as far as that goes, the only real requirement with FIRS is that
resource specifications must specify a way for clients to locate an LDAP
server associated with that resource (which may include using a master
domain name, as in the cases above), and the resulting server must be
identifiable with a series of domainComponent labels (so that the servers
associated with that partition can be located), but the only real DNS
requirement is in the latter lookups, and not in the resource-mapping. If
the ~RIR community wants to use some other kind of mapping algorithm that
relies upon some other targetting mechanism (eg, using routing entries)
then they are free to do so, with the only requirement being that the
resulting partition(s) must be identifiable with domain names so that the
associated LDAP servers can be located.

Separately, the FIRS specifications (globally and at the resource level)
also allow clients to override the default top-down mapping algorithm by
mapping resources to resource-specific partitions, such as mapping a
fully-qualified domain name to a particular partition (rather than asking
the servers associated with the ~.com zone), or by mapping an IP address
to a particular partition (rather than asking the in-addr.arpa zone). The
exception here is ASNs, which do not have a mapping in DNS, so there is
not any way to perform this kind of mappiing with those resources. All of
this is a *secondary* benefit to using DNS for the primary mapping
service, but it is not a requirement (and as seen with the current ASN
approach, it won't necessarily be an option).

I would encourage the RIR community to provide these kinds of secondary
mapping algorithms, since they provide certain benefits which are
important. Specifically, the ability to bypass the delegation hierarchy
allows for shorter lookup times, and avoids problems with potentially
incomplete entries at top-level mappings (eg, missing referral data).

Hopefully that clarifies the situation somewhat. Any client-side mapping
algorithm may be specified (the current placeholder specs use LDAP by
default, and use DNS for secondary low-level mappings), but regardless of
the mapping algorithm that gets used, the target for the query must be an
LDAP partition and must be identifiable by DNS lookups for SRV RRs.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/