Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 18 16:00:46 2003

#6 inetDnsDomain objects and 2251 referrals

 From draft-ietf-crisp-firs-dns-02 Section 4 paragraph 1:

> If an entry exists as a 
>      referral source, the entry MUST also be defined with the referral 
>      object class, in addition to the above requirements.

Most of the attributes described are strings, but the attributes for the 
registry and registrar seem to be LDAP URL referrals... so this would 
seem to apply in that the objectclass would be of inetDnsDomain and 
referral.  Did I get the correct?

Anyway, I think this will cause problems after reading RFC 2251.

 From RFC 2251 Section 4.5.3 Paragraph 2:

>    In the absence of indexing information provided to a server from
>    servers holding subordinate naming contexts, SearchResultReference
>    responses are not affected by search filters and are always returned
>    when in scope.

Scope, in this sense, is base object, one level, or subtree.

The problem, as I see it, is that there will be policy limits on the 
number of entries.  So, let's say that I have 200 entries beneath dc=com 
and limit of 50 results per query.  And let's say that 100 of them have 
referrals in them (to the registry or registrar or both).  If I do a 
subtree or one-level search at dc=com, the response will be filled up 
with the first 50 entries because they have referrals that are in scope. 
  This is true even if the search filter says only give me back domains 
hosted by nameserver ns1.example.com.

It would seem that the referrals eat up the response even when they 
aren't appropriate to hand back.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 16:18:11 2003

on 8/18/2003 3:27 PM Andrew Newton wrote:

> Most of the attributes described are strings, but the attributes for
> the registry and registrar seem to be LDAP URL referrals...

No, they're pointers not referrals. They provide a way to point at a
registry's web page, for example.

This is neccessary to allow registration data to provide a "see also"
capability that exceeds the LDAP directory space. If I query for
example.com, I want to get information about the registry and registrar,
and this is meant to provide that pointer data. It's not a referral and
it's not intended to be automatically chased down (the user can click on
the URL and see where it goes, but that's the extent).

The attributes use the two-part labeledURI syntax, which is "URI text"
with the "text" potentially being displayed as a hyperlink with the URI as
the link context.

> Anyway, I think this will cause problems after reading RFC 2251.

I don't think this concern applies in light of the answer above but if you
think it still does, let me know.

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

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 18 17:24:35 2003

> with the "text" potentially being displayed as a hyperlink with the URI as

Is that how LDAP clients normally handle labeledURI syntax?  If not, you 
should probably include this in the draft.  Even if it is, you should 
probably include it as an informative item (perhaps in an appendix).

> think it still does, let me know.

Then why do have the following text:

      DNS domain name entries in FIRS MUST use the inetDnsDomain object
      class, in addition to the mandatory object classes defined in
      [FIRS-CORE]. DNS domain name entries MUST be treated as containers
      capable of holding subordinate entries. If an entry exists as a
      referral source, the entry MUST also be defined with the referral
      object class, in addition to the above requirements.

Why would they also use the referral objectclass?

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 17:55:19 2003

on 8/18/2003 4:51 PM Andrew Newton wrote:

> Is that how LDAP clients normally handle labeledURI syntax?

It's the prescribed behavior.

> Why would they also use the referral objectclass?

It's either-or, not also. The referrals are for use whenever a domain
entry needs to exist as an alias for some other entry.

An easy example is when www.example.com is really a set of web pages
hosted by an isp. In that case, a query for the www.example.com domain
entry would just return a referral to host.example.net.

Another example that we discussed recently would be variants for i18n
domain names, where all of the variants exist as entries but only exist as
referral entries. This allows a query for a variant to match the right
entry, and still get shunted off to the canonical entry.

---

From: davidb at verisignlabs.com (David Blacka)
Date: Mon Aug 18 19:22:38 2003

> entry needs to exist as an alias for some other entry.

Huh?  You've lost me.  

It seems you are saying that the object is *either* a inetDnsDomain object 
*or* a referral object.  But that is not how the quoted paragraph reads: 
"If an entry exists as a referral source, the entry MUST *also* be defined 
with the referral object class, *in addition to the above requirements*." 
[emphasis mine] says that some objects are *both* inetDnsDomain objects 
and referral objects.

Or have I misunderstood?

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 19:47:53 2003

> [emphasis mine] says that some objects are *both* inetDnsDomain objects 

Object classes are different from attributes.

The object classes that define the entry must always be defined. This is
needed so that the matching process works as expected ("please give me all
of the resources like name X of object class Z").

If an entry is a referral source, then the only attributes should be
defined inside the entry are the objectlass= attributes themselves, the
naming attribute (cn=), and the ref attribute.

If an entry is terminal, then it may have any of the attributes from any
of the object classes that are defined.

A terminal entry:

   cn=host1.example.net,cn=inetResources,dc=...
      cn: host1.example.net
      objectClass: top
      objectClass: inetResources
      objectClass: inetDnsDomain
      o: example.net ISP
      description: the example.net hosting server
      <any other>: ...

A referral entry:

    cn=www.example.com,cn=...
      cn: www.example.com
      objectClass: top
      objectClass: inetResources
      objectClass: inetDnsDomain
      objectClass: referral
      ref: ldap:///cn=host1.example.net,cn=inetResources,dc=...

      [No other attributes allowed.]

A query for cn=www.example.com && objectClass=inetDnsDomain would match
against the appropriate entry, and the resulting referral data would kick
the client over to the canonical target entry.

---

From: davidb at verisignlabs.com (David Blacka)
Date: Mon Aug 18 20:30:31 2003

On Monday 18 August 2003 07:47 pm, Eric A. Hall wrote:
> >>>  DNS domain name entries in FIRS MUST use the inetDnsDomain
> >>>  object class, in addition to the mandatory object classes
> >>>  defined in [FIRS-CORE]. DNS domain name entries MUST be treated
> >>>  as containers capable of holding subordinate entries. If an
> >>>  entry exists as a referral source, the entry MUST also be
> >>>  defined with the referral object class, in addition to the
> >>>  above requirements.

> > Huh?  You've lost me.  
> > 
> > It seems you are saying that the object is *either* a
> > inetDnsDomain object *or* a referral object.  But that is not how
> > the quoted paragraph reads: "If an entry exists as a referral
> > source, the entry MUST *also* be defined with the referral object
> > class, *in addition to the above requirements*."  [emphasis mine]
> > says that some objects are *both* inetDnsDomain objects and
> > referral objects.
> > 
> > Or have I misunderstood?
> 

I see.  The paragraph is referring to what objectclass's these objects
must declare in their objectclass attributes, which pretty much
follows from the rules for referrals laid out in FIRS-core.

However, this paragraph is confusing.  Specifically the phrase: "...in
addition to the above requirements."  One of the "above requirements"
is that "DNS domain name entries MUST be treated as containers..."
Which is, of course, explictly disallowed in firs-core (4.3):

     Referral sources MUST NOT contain any user-definable attributes 
     (other than the mandatory naming attribute), and MUST NOT have any 
     subordinate child entries. 

Hence the confusion.

I believe that this paragraph (the first paragraph of section 4 of
firs-dns, for those keeping score at home) is unclear, because to me
it appears to contradict firs-core, which I am positive you do not
intend.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 20:53:36 2003

> Which is, of course, explictly disallowed in firs-core (4.3):

Yeah that's an error, and one I meant to call out earlier. Sorry.

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Tue Aug 19 06:47:14 2003

> probably include it as an informative item (perhaps in an appendix).

THis is LDAP standard behaviour for URIs. LabeledURI syntax is specified 
in RFC 2079, which is included in the normative references of FIRS-core.

Cheers,

Peter
> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 T?bingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Tue Aug 19 13:31:13 2003

Eric A. Hall wrote:
1  > A referral entry:
2  >
3  >     cn=www.example.com,cn=...
4  >       cn: www.example.com
5  >       objectClass: top
6  >       objectClass: inetResources
7  >       objectClass: inetDnsDomain
8  >       objectClass: referral
9  >       ref: ldap:///cn=host1.example.net,cn=inetResources,dc=...
10 >
11 >       [No other attributes allowed.]

I think the confusion is over lines 7 & 8.  How could it be either-or 
when your text says "also"?  Anyway, I believe I understand what you are 
saying.

I believe this comes down to a difference between 2251 style referrals 
and the named subordinate references in 3296.  After reading 3296, it 
would seem my original point is still somewhat valid because your draft 
does not mention the use of the manageDsaIT control.  You should add 
text requiring the recognition of it by the server and the use of it by 
the client.  Otherwise, all those domain variants you mentioned will 
fill up the result set before any valid response.

I also do not see where the thin registry model referral/reference is 
defined. But that should be a simple addition, correct?

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Aug 20 06:44:17 2003

> when your text says "also"?  Anyway, I believe I understand what you are 

As I said in the other message, that part of the text was in error and is
already fixed in the -03 drafts. The modified text says that referrals
must not be containers, must not have additional attributes, blah blah.
It's explicitly either-or in the -03 texts.

> the client.

That's not necessary. In the case of deployments that use packaged
servers, the control would need to be provided as part of the referral
service. In the case of servers that are going to be manipulating data in
a private back-end, LDAP isn't going to be used for editing the referral
data, but even if it is, RFC 3296 is the governing spec here not FIRS. In
any event, I don't think it's appropriate or necessary to restate RFC 3296
requirements in the FIRS specs.

> Otherwise, all those domain variants you mentioned will 

I'm not sure what you mean by this. The manageDsaIT control provides a way
for clients to edit an entry that contains referral data (in the default
case, a request for the entry would cause the server to generate the
referral, while the control says "no no, I want to change the entry not
read it"). It doesn't have anything to do with the "size" of the result
set to my knowledge. Am I misunderstanding you here?

> defined. But that should be a simple addition, correct?

Something like that should probably go in the architecture guide rather
than in the technical spec. I have some other text that I want to put in
there already so this would be a good time to include anything else along
those lines. What exactly do you think needs to be said here?

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Wed Aug 20 09:55:13 2003

> set to my knowledge. Am I misunderstanding you here?

<sarcasm>
I'm not sure why there is confusion on this topic.  3296 makes it 
plainly obvious what is going on.
</sarcasm>

I reread 3296 for the 3rd time this morning and feel no closer to the 
answer.  It seems to be talking about two completely separate things: 
named subordinate references and a control to manage DSE entries.

 From what I can tell, the manageDsaIt control simply allows the client 
to tell the server to treat these referral objectclass entries as normal 
results as opposed to a referral.  The side-effect is that you can edit 
them.

If that is not the case, how is the distinction made between:

   a: continue searching over there

        and

   b: the specific entry you are looking for is over there

These are completely seperate things to a client.

Also, if the manageDsaIT control does not counteract the 2251 specified 
behaviour of including referrals/references in a response regardless of 
search filter, then what does?

> those lines. What exactly do you think needs to be said here?

The inetDnsDomain objectclass should contain an attribute that is an 
LDAP URL named subordinate reference/referral/whatever to the entry in 
the registrar's LDAP server for that specific domain.  Atleast that's 
how I think it would be done, unless there is a better or more elegant 
method.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Aug 20 17:45:34 2003

on 8/20/2003 9:22 AM Andrew Newton wrote:

> Eric A. Hall wrote:
> 
>> Andrew Newton wrote:
>> 
>>> I believe this comes down to a difference between 2251 style
>>> referrals and the named subordinate references in 3296.

> to tell the server to treat these referral objectclass entries as
> normal results as opposed to a referral.  The side-effect is that you
> can edit them.

We may be having some confusion with the technology (I hope I don't make
it worse here).

2251 defines the LDAP message structure and not the database structures.

As part of a positive response, 2251 allows entry sets in an answer to
contain "continuation references", which is a long way of saying "soft
referral", meaning "here is some data but you should also start additional
queries at/with <ref>". The search succeeded, but some of the database
entries that matched the query exist as referrals, and those will need to
be chased down. 2251 doesn't say where this data comes from, only what it
looks like in the message.

3296 defines "subordinate references", aka "hard referrals", or "you must
restart the query at/with <ref>". These essentially use response messages
that have zero answers. Generally speaking, this means that the search
failed because the searchbase specifies an entry that only exists as a
referral stub. With FIRS, this usually only happen if the inetResources
container only exists as a pointer to an inetResources container in a
different partition, although it can also happen if the searchbase of a
query specified a child entry that was a referral stub (this is uncommon
but is not entirely unexpected).

3296 also defines the object class and attribute schema and a control that
allows the referral stubs to be managed via the protocol. None of this
stuff is used by FIRS directly, although the practices are mandated so
everything works as expected with existing LDAP tools.

On the subject of variant domain names... These should exist as referral
stub entries within the inetResources container of a registry's partition
(eg, cn=variant.dom,cn=inetResources,dc=registry,dc=com). In the usual
scenario, queries for that domain name would use the inetDnsDomainMatch
filter, and the inetResources container as the searchbase, resulting in
the variant's stub entry being returned as a continuation reference
referral (other domain entries in the domain's delegation path that also
existed on the queried server would also be returned, but that's not
particularly relevant to this point). The variant referral data would
likely point to another entry in the same container on the same server.

If somebody used a generic matching filter with wildcards or soundex
filters or something, and the server found 100 matching variants before
shutting off the lookup, the server could theoretically return 100
continuation referencereferrals as matches, and the client would have to
deal with that. This isn't the prescribed behavior; the specs define the
inetDnsDomainMatch filter specifically to avoid this kind of scenario.

> how I think it would be done, unless there is a better or more elegant

That's pretty much the way it's supposed to work:

 input: example.com

 client: find LDAP servers for com domain registry
         submit inetDnsDomainMatch query for example.com

 registry: search for all inetDnsDomain entries in example.com path
           return answer containing {
                 local entry for com (the delegation parent)
                 local entry for example.com
                 continuation reference to registrar
           }

 client: find LDAP servers for named registrar
         submit inetDnsDomainMatch query for example.com

 registrar: search for all inetDnsDomain entries in example.com path
            return answer containing {
                 local entry for example.com
                 continuation reference to operator (policy issues)
            }

I seemed to have misplaced some crucial text in the specs during one of
the subsequent rewrites. Since the continuation references cannot coexist
at the same leaf as the answer entries, additional entries are required in
order for the registry and registrar to return answers and soft referrals
simultaneously. In order for these entries to be located by the
inetDnsDomainMatch, they must have names which are in the delegation path
of the resource. This means having a referral stub entry as a child entry,
with a name like cn=referral,cn=example.com,cn=inetResources,dc=...

I'll add that discussion to the arch draft and a mention in each of the
resource drafts.