Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Strange syslog error...

1 view
Skip to first unread message

Dave Anderson

unread,
Jun 6, 1996, 3:00:00 AM6/6/96
to

If you have any problems or fixes send them to....

Just trying this to see if i'll be told to read the manual.. <g> Been
running Bind for quite some time now on my network. I've had this gzero.db
for a domain called gzero.com that has never caused any syslog problems when
I ran BETA8, but when I compiled the -REL version it started giving me a
error warning in my syslog.

Here's the DB file for the gzero.com domain:
; updated 5/20 by dand...@citicom.com
gzero.com. IN SOA ns1.citicom.com. dandersn.citicom.com. (
9605201 ; Serial
10800 ; Refresh
1800 ; Retry
608400 ; Expire
86400 ) ; Minimum
IN NS ns1.citicom.com.
IN NS ns2.citicom.com.
IN NS ns1.packet.net.
IN NS ns2.packet.net.
IN A 204.251.133.2
ftp IN CNAME gzero.com.
www IN CNAME gzero.com.

Here's what i'm getting in the syslog... This doesn't happen every nslookup,
only about 1/2 of the time:
Jun 6 01:17:08 citicom named[11347]: "133.251.204.in-addr.arpa IN NS"
points to a CNAME (ns1.citicom.com)
Jun 6 01:17:08 citicom named[11347]: "133.251.204.in-addr.arpa IN NS"
points to a CNAME (ns2.citicom.com)
Jun 6 01:17:08 citicom named[11347]: "133.251.204.in-addr.arpa IN NS"
points to a CNAME (ns1.packet.net)
Jun 6 01:17:08 citicom named[11347]: "133.251.204.in-addr.arpa IN NS"
points to a CNAME (ns2.packet.net)
Jun 6 01:17:08 citicom named[11347]: "gzero.com IN NS" points to a CNAME
(ns1.citicom.com)
Jun 6 01:17:08 citicom named[11347]: "gzero.com IN NS" points to a CNAME
(ns2.citicom.com)
Jun 6 01:17:08 citicom named[11347]: "gzero.com IN NS" points to a CNAME
(ns1.packet.net)
Jun 6 01:17:08 citicom named[11347]: "gzero.com IN NS" points to a CNAME
(ns2.packet.net)

Suggestions?

Thanks ahead of time...

Dave Anderson
Net Admin, Citicom Online


Don Lewis

unread,
Jun 7, 1996, 3:00:00 AM6/7/96
to

On Jun 6, 1:18am, Dave Anderson wrote:
} Subject: Strange syslog error...

}
} If you have any problems or fixes send them to....
}
} Just trying this to see if i'll be told to read the manual.. <g> Been
} running Bind for quite some time now on my network. I've had this gzero.db
} for a domain called gzero.com that has never caused any syslog problems when
} I ran BETA8, but when I compiled the -REL version it started giving me a
} error warning in my syslog.

The check for this situation was added somewhere between BETA9 and BETA17.

When your server is looking for the A RRs for these servers to put in
the additional data section of a response, it is finding CNAME RRs for
them instead. In all versions of BIND, this will always result in an
empty additional data section. In older versions of BIND without this
check, BIND would send out a query for the A RRs for each of these
servers whenever it encountered this situation.

The RFCs say that NS RRs should not refer to CNAME RRs.

When BIND wants to send out a query, it has never followed
CNAME RRs when it's looking up the addresses of the servers
named by the NS RRs. If none of the NS RRs point to an
A RR, the query fails.

Even if BIND did follow CNAME RRs, it would be inefficient
at best, and DNS lookups could fail in a totally unrecoverable
manner unless the DNS protocol were modified to follow CNAME
chains and include the CNAMEs in the additional data section
of responses, as well as allow glue CNAME RRs wherever glue
A RRs are allowed.

The difference is that BIND is now telling you that things are broken.

--- Truck

Mark Andrews

unread,
Jun 8, 1996, 3:00:00 AM6/8/96
to

>
> If you have any problems or fixes send them to....
>
> Just trying this to see if i'll be told to read the manual.. <g> Been
> running Bind for quite some time now on my network. I've had this gzero.db
> for a domain called gzero.com that has never caused any syslog problems when
> I ran BETA8, but when I compiled the -REL version it started giving me a
> error warning in my syslog.
>

> Suggestions?
>
> Thanks ahead of time...
>
> Dave Anderson
> Net Admin, Citicom Online
>
>

This is just bind checking for illegal configurations. No record
(other than a CNAME) is suposed to point to a CNAME and CNAME
chains are discouraged.

This configurations DOES cause problems depending apon where the
CNAMES point. You should be using the real names of the
nameservers.

Mark
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: ma...@syd.dms.csiro.au
MOBIL: +61 41 942 9884 UUCP:....!uunet!syd.dms.csiro.au!marka

0 new messages