HomeAbout Us A-Z IndexSearch * Contact Us Register LoginPress Shop

The Open Brand -- Problem Reporting and Interpretations System


Problem Report 1151 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1151.


Report 1151 Actions


    Problem Report Number 1151
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0353
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Sockets (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSU version 4.1.1
    Test Identification sockets/ghostbynam 5
    Problem Summary PG4U.00117 This request claims that the error returned is dependent on the result of a DNS query and should be allowed to vary based on the DNS server configured for use.
    Problem Text

    The h_errno values according X/Open in case of failures are given
    for reference:
    ******************************************************************
    HOST_NOT_FOUND No such host is known.

    TRY_AGAIN A temporary and possibly transient error
    occurred, such as a failure of a server to
    respond.

    NO_RECOVERY An unexpected server failure occurred which
    cannot be recovered.

    NO_DATA The server recognized the request and the
    name but no address is available, another
    type of request to the name-server for the
    domain might return an answer.
    ******************************************************************

    When remote DNS is configured, gethostbyname() in libsocket
    calls the libresolv code. The libresolv code, will send a
    query to the name-server requesting the address of the name given
    in a DNS specified format and it interprets the reply
    information from the name-server.

    On failure, the libresolv code interprets the error returned in
    the DNS header to the h_errno values HOST_NOT_FOUND, TRY_AGAIN,
    NO_RECOVERY and NO_DATA. That is the h_errno values set on
    failure is entirely dependend on the information returned by the
    name-server.

    In our investigation, we tested with 25 name-servers on the
    Internet and a local name-server. With our current libresolv
    code, the test passed with all 25 name-servers on the Internet.
    But it failed with the local name-server giving TRY_AGAIN in h_errno.

    When the nameserver was configured to ns.hcla.com, the following
    excerpt from the journal file shows PASSING of test suite:


    10|1 /tset/CAPIsockets/fghostbynam/fghostbynam1 08:43:03|TC Start,
    scenario ref 3-1, ICs {5}
    15|1 1.10 1|TCM Start
    400|1 5 1 08:43:04|IC Start
    200|1 5 08:43:04|TP Start
    520|1 5 3028 1 1|SPEC1170TESTSUITE CASE 5
    520|1 5 3028 1 2|HOST_NOT_FOUND in h_errno and return a null pointer on
    520|1 5 3028 1 3|a call to struct hostent *gethostbyname(const char
    520|1 5 3028 1 4|*name) when no such host is known.
    520|1 5 3029 1 1|TEST: Call gethostbyname with a bad name.
    520|1 5 3029 1 2|TEST: Return value
    520|1 5 3029 1 3|TEST: h_errno value
    220|1 5 0 08:43:08|PASS
    410|1 5 1 08:43:08|IC End
    80|1 0 08:43:08|TC End
    300|2 /tset/CAPIsockets/fghostbynam/fghostbynam1 08:43:08|Clean Start,
    scen ario ref 3-1
    320|2 0 08:43:08|Clean End
    900|08:43:08|TCC End

    We did the same study on a m/c with UnixWare2.1.1.
    For our surprise, UnixWare2.1.1 also failed with two name-server
    ns.hcla.com and vgr.arl.mil. But it passed with the local name-server.
    We further investigated on this problem and found the difference
    in MP-RAS and UnixWare2.1.1 is

    * MP-RAS tries name as it is, even though there are no
    dots in the given name.
    * But UnixWare2.1.1 does not try as it is, if there are
    no dots in the given name.


    We changed the MP-RAS libresolv code, to behave the same
    way UnixWare2.1.1 does. Then it passed with the local
    name-server, but it failed with the name-server ns.hcla.com
    on the Internet with NO_DATA as error. We found that
    this was the result of the information sent by that name-server.

    This ascertains the fact that, the test result is entirely depending on
    the return information from the name-server.

    As of now, we do not see any problem in our libresolv code. The
    values depend entirely on return information from the name-server,
    and we do not have any control on the information returned by the
    name-server. Currently all the error returned by the libresolv are
    valid h_errno values as specified in XPG4 specification.

    The testsuite checks only for HOST_NOT_FOUND, which we feel is not
    reasonable as this error depends on the information returned in the
    DNS reply from the name-server.

    Test Output
    15|1 1.10 1|TCM Start
    400|1 5 1 08:51:13|IC Start
    200|1 5 08:51:13|TP Start
    520|1 5 3081 1 1|SPEC1170TESTSUITE CASE 5
    520|1 5 3081 1 2|HOST_NOT_FOUND in h_errno and return a null pointer on
    520|1 5 3081 1 3|a call to struct hostent *gethostbyname(const char
    520|1 5 3081 1 4|*name) when no such host is known.
    520|1 5 3082 1 1|TEST: Call gethostbyname with a bad name.
    520|1 5 3082 1 2|TEST: Return value
    520|1 5 3082 1 3|TEST: h_errno value
    520|1 5 3082 1 4|ERROR: h_errno not set correctly, expected
    HOST_NOT_FOUND(1), received 4
    220|1 5 1 08:51:14|FAIL
    410|1 5 1 08:51:14|IC End
    80|1 0 08:51:14|TC End
    300|2 /tset/CAPIsockets/fghostbynam/fghostbynam1 08:51:14|Clean Start,
    scenario ref 3-1
    320|2 0 08:51:14|Clean End
    900|08:51:14|TCC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused.

    We believe the portion of the XNI spec quoted above is clear and
    the IUT should be required to adhere to it.

    We believe this is a test suite configuration issue. It is
    probably best to disable DNS on the IUT. This isolates the
    IUT and test suite from remote databases and procedures that
    may interfere with predictable test suite operation.

    Configuring a DNS server that returns results which map to proper
    results for all tests is also an option.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   


Contact the Certification Authority