Conference turris::digital_unix

9217.0. "bind version on 4.0B ...is it 4.9.3 beta? any patch/4.9.3 release version?" by GIDDAY::SANKAR ("") Tue Mar 18 1997 23:32

I ahve a customer call where he is getting bind errors 
and he knows that it was problem in the 4.9.3 beta release of bind.

Do we have any suggestions on how he can move to the proper 4.9.3 
release version of bind on 4.0B digital_unix o/s.

thanks for any suggestion.

srinivasan sankar
csc (sydney)

===================================

Here is what we are seeing in /var/adm/messages:

        Mar 14 12:37:09 dust syslog: gethostby*.getanswer: asked for
        "4.16.155.130.in-addr.arpa IN PTR", got type "CNAME"
        Mar 14 12:37:09 dust syslog: gethostby*.getanswer: asked for
        "4.16.155.130.in-addr.arpa", got "4.1.16.155.130.IN-ADDR.ARPA"

when we tried to rsh into the machine 'dust' from the host
pride.syd.dms.CSIRO.AU (130.155.16.4). We have the following DNS entries in
regard to the PTR record for 130.155.16.4:

4.16.155.130.in-addr.arpa.      18000   CNAME   4.1.16.155.130.IN-ADDR.ARPA.
4.1.16.155.130.in-addr.arpa.    18000   PTR     pride.syd.dms.CSIRO.AU.

As you can see, from the error messages, the resolver bombs out when it
encounters a CNAME record when trying to resolve the PTR record. This is
causing hostname authenications to fail.


According to the standard RFC 1034:

--

3.6.2. Aliases and canonical names

CNAME RRs cause special action in DNS software.  When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class.  If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.  The one exception to
this rule is that queries which match the CNAME type are not restarted.

--

The above bug was introduced in the bind 4.9.3 beta cycle and was fixed
before 4.9.3 went release. So we suspect that it was bind 4.9.3 beta code in
the resolver that is shipped with DU 4.0B
                                                 

    
    I'd suggest logging a call via IPMT etc., the 4.9.3 release of BIND 
    in V4.0* "should not" exhibit the 4.9.3 beta error 

Hi,

Engineering knows of this problem and has fixed it in the next OS
release.  There was also already a large patch for 3.0 -> 4.0 done,
but I'm not sure when it will be available.  The original CLD was
CLD-00805.

-Brian
[Posted by WWW Notes gateway]