[Ietf-not43] #5 inetDnsDomain attributes for contacts and nameservers

[Eric A. Hall]

on 8/18/2003 2:16 PM Andrew Newton wrote:

> #5 inetDnsDomain attributes for contacts and nameservers
> 
> At first I thought the attributes for contacts and nameservers in 
> inetDnsDomain were LDAP url's, but after reading the example it would 
> seem they are just strings.  Correct me if I'm wrong (reading the OID 
> numbers starts to get confusing for me).

They used to be URLs, now they're just resource names which the client
uses to seed a new query.

There is no substantial difference there in terms of the followup
activitiy. A URL just provides a pre-packaged query to the client, and the
client still has to go through the same basic steps in any event (eg, it
has to find the SRV RRs, build the query, etc).

However, the pre-packaged URLs can be too static. The URL set may not
accurately reflect loading issues, for example, or may direct clients
somewhere they shouldn't be going. Making the client start the query with
the key value keeps these problems from happening.

Architecturally, this is similar to what DNS does. EG, when you get an NS
RR, you get a domain name as a value that you have to resolve.

> If they aren't LDAP URL's, then what is a client to do with them for 
> dereferencing?

They spawn new queries of the appropriate $resourceType with the attribute
value as the search key.

> Are these LDAP aliases?

No, they are input values for any followup queries that the user may be
interested in resolving. None of the attribute values are "automatically"
processed (referrals are the only data that get the automatic treatment).

> The OID number seems to define 
> their syntax as that of inetDnsDomain (also confusing since an email 
> address is not a domain name).

Contact entry names use an email-like syntax (user at domain) so that they
can overlap with email addresses, but these are not always going to
reference existing email addresses.

The idea here is that I can publish ehall at ehsco.com as my contact identity
and people will be able to remember this since that's what I use for all
of my crap anyway. However, if ~netsol assigns a nic handle to me, then
that identity can point to their portion of the namespace (eg, something
like eh26 at registry.netsol.com). Or as another example, I might be
eh26 at registry.arin.net, where that identity entry holds public information
about my role as a hostmaster. In either case, those entries could provide
additional information or services (such as forwarding mail to me, or
publishing subordinate reference referrals to my real identity, or
whatever). Those are feature-adds that are up to the provider.

So the idea here is that we have a flexible, universally applicable
pointer for contacts, and which may be the same "identity" as I use for
things like email, or a registrar-specific identity that provides public
delegation-related data.

The syntax uses the i18n domain logic for the @domain element for
consistency purposes. The localpart@ is also utf8 to allow for the i18n
work effort that is ongoing in the email space, but does not define a
syntax for that (yet) so the localpart element is technically limited to
the existing RFC 2822 syntax rules but is capable of supporting a richer
syntax when one becomes available.

> If the client gets an inetDnsDomain entry, what is it to do to follow 
> the information for a nameserver?  Does it requiry the same server? 
> Does it start the whole query bootstrapping process again?

It spawns new queries for each of the referenced domain names. If an
organization wants to force this, they can return the entries as
subordinate reference referrals which the client would then automatically
chase down.

> Either I just don't get it (entirely probable at this point), or these 
> should be LDAP URL's, or there needs to be text defining how a client is 
> to further dereference this information.

Probably need clarifications to the text.

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