Resolving CNAMEs when pointing to another domain
G. Del Merritt
dmerritt at intranets.com
Mon May 8 15:52:26 UTC 2000
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)
More information about the bind-users
mailing list