Resolving CNAMEs when pointing to another domain

[G. Del Merritt]

At 08:12 AM 5/8/00 -0700, Eric A. Hall wrote:
> > The problem is that if I just point my browser (IE, Netscape, Lynx -
> > doesn't matter) at "foo.mydomain.com" I get a lookup failure.
>
>The browser sees a multi-label domain name, so it assumes the name is an
>FQDN, and issues a query for the FQDN of "foo.domain.com." Try to ping
>foo.domain.com (without the trailing dot) and see what happens, your
>resolver ought to try it as is.

Actually, ping behaves just as my browser does.  When I ping before the 
nslookup, it fails (bad IP address).  I do the nslookup, then ping, and I 
get an address.

> > However, if I do the following:
> >     # nslookup
> >     > lserver myispDNShere
> >     > set type=any
> >     > foo.mydomain.com
> >     foo.mydomain.com   canonical name = foo.mydomain.com.theirdomain.com
> >
> > Then I point my browser at "foo.mydomain.com" and, voila!, it "works".
>
> > it doesn't seem to matter whether my client's nameserver is pointing
> > at a Windoze or a Linux box.
>
>Since it doesn't work with any of your local servers -- but does work
>with your ISPs servers -- then it sounds like you've typo'd the CNAME
>record on your local servers. The exact syntax should be:

My servers are not actually running BIND at all.  They are using lbnamed, 
which I have munged.
         http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html

The issue is that I must programattically generated hundreds of thousands 
of CNAME and MX RRs.  Specifically, if I get a query for 
"foo.site1.mydomain.com", I turn it into 
"foo.site1.mydomain.com.theirdomain.com".  If I get a query for 
"foo.site2.mydomain.com", I turn it into 
"foo.site2.mydomain.com.theirdomain.com".  Etc.  Rather than store each of 
these, I generated them on the fly.

The fly in the ointment is/(may be) that lbnamed isn't a recursive server, 
and it's only authoritative for "mydomain.com".  It's also the case that it 
currently generates RRs only in the answer section, and not in the 
authority or additional records sections.  I'm not sure if it's one of 
these facts or a combination of both that is giving resolvers fits.

Since I clear the "Recursion Available" bit when my servers respond, I 
would have hoped that the nameserver or resolving calling my servers 
directly would iterate.  It sort of looks like they aren't.  Something 
about the way nslookup pokes the ISP server, though, is sufficient to get 
information in place.

When is it appropriate to add information to the "additional records" 
section, and when is it mandatory?  RFC 1035 says:
   CNAME RRs cause no additional section processing, but name servers may
   choose to restart the query at the canonical name in certain cases.  See
   the description of name server logic in [RFC-1034] for details.

RFC 1034 says:
    - Queries contain a bit called recursion desired or RD.  This
      bit specifies specifies whether the requester wants recursive
      service for this query.  Clients may request recursive service
      from any name server, though they should depend upon receiving
      it only from servers which have previously sent an RA, or
      servers which have agreed to provide service through private
      agreement or some other means outside of the DNS protocol.
                 :
   If recursive service is not requested or is not available, the non-
   recursive response will be one of the following:
    - An authoritative name error indicating that the name does not
      exist.
    - A temporary error indication.
    - Some combination of:

      RRs that answer the question, together with an indication
      whether the data comes from a zone or is cached.

      A referral to name servers which have zones which are closer
      ancestors to the name than the server sending the reply.

    - RRs that the name server thinks will prove useful to the
      requester.

My servers return the CNAME RR, and only that.  Without becoming a 
recursive server, what other information will "prove useful" to a resolver?

--
G. Del Merritt                                dmerritt at intranets.com
http://www.intranets.com - Get everyone on the same page(sm)