ZABBIX BUGS AND ISSUES
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-7648

After using net.dns item, some of the host resolution (web.page.get) uses the name server used in net.dns instead of the configured name servers in /etc/resolv.conf

    Details

    • Type: Incident report Incident report
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.1
    • Fix Version/s: 2.0.11rc1, 2.2.2rc1, 2.3.0
    • Component/s: Agent (G)
    • Labels:
    • Environment:
      Ubuntu 12.04 LTS

      Description

      Prior to using the net.dns item key, all host resolutions (using web.page.get item key) use the name servers configured in /etc/resolv.conf
      After using the net.dns item key, some of the host resolutions use the name server provided in the net.dns item key above.

      This caused some web.page.get to fail, as it cannot resolve the host name.

      /etc/resolv.conf:
      nameserver 192.168.0.4
      nameserver 192.168.0.5

      name server used with net.dns
      zabbix_get -s127.0.0.1 -p10050 -k net.dns[69.164.211.158,pagekite.com]

      web.page.get
      zabbix_get -s127.0.0.1 -p10050 -k web.page.get[www.google.com]

      A restart of the Zabbix agent is needed in order to remove this "cached" name server entry.

        Activity

        Hide
        Juris Miščenko (Inactive) added a comment -

        Name resolver state now gets restored after net.dns requests that specify a nameserver for fulfilling the request. Fixed in svn://svn.zabbix.com/branches/dev/ZBX-7648

        Show
        Juris Miščenko (Inactive) added a comment - Name resolver state now gets restored after net.dns requests that specify a nameserver for fulfilling the request. Fixed in svn://svn.zabbix.com/branches/dev/ZBX-7648
        Hide
        Aleksandrs Saveljevs added a comment - - edited

        (1) How about we put the original nameserver back after the call to res_send()? In this case, this will only need to be done once, instead of before every return statement.

        Also, note that not only we have to reestablish the old servers back, but also _res.retrans and _res.retry.

        Finally, I think we could also work in case _res.nscount equals 0. For instance, if DNS server is specified in the item.

        Juris Miščenko

        Nameserver information is now restored after the final use of the _res structure. `retrans' and `retry' variables are also saved and restored before and after NS entry manipulation.

        _res.nscount should NEVER equal 0 unless res_init() hasn't been called (or any of the query functions, which call res_init() internall, if they detect that it hasn't been done previously). A 0 value for nscount indicates a broken implementation of `resolv' on the system or severe system failure. Handling such a case varies from implementation to implementation, but it should be noted that a 0 value nscount does not indicate error and does not result in the setting of the `_res.res_h_errno' variable responsible for reporting error status. It is safe to assume that in the case of an nscount of 0 further calls to resolver functions also fail. The case will not be handled directly. RESOLVED.

        Aleksandrs Saveljevs Yesterday we discussed that we should check for res_init() being successful. It was not done, however. Could you please look into it? REOPENED.

        Juris Miščenko Failure check added to resolver structure initialization routine. RESOLVED.

        Aleksandrs Saveljevs Looks good. Please see r41722 before merging. RESOLVED.

        Juris Miščenko Looks good! CLOSED.

        Show
        Aleksandrs Saveljevs added a comment - - edited (1) How about we put the original nameserver back after the call to res_send()? In this case, this will only need to be done once, instead of before every return statement. Also, note that not only we have to reestablish the old servers back, but also _res.retrans and _res.retry. Finally, I think we could also work in case _res.nscount equals 0. For instance, if DNS server is specified in the item. Juris Miščenko Nameserver information is now restored after the final use of the _res structure. `retrans' and `retry' variables are also saved and restored before and after NS entry manipulation. _res.nscount should NEVER equal 0 unless res_init() hasn't been called (or any of the query functions, which call res_init() internall, if they detect that it hasn't been done previously). A 0 value for nscount indicates a broken implementation of `resolv' on the system or severe system failure. Handling such a case varies from implementation to implementation, but it should be noted that a 0 value nscount does not indicate error and does not result in the setting of the `_res.res_h_errno' variable responsible for reporting error status. It is safe to assume that in the case of an nscount of 0 further calls to resolver functions also fail. The case will not be handled directly. RESOLVED. Aleksandrs Saveljevs Yesterday we discussed that we should check for res_init() being successful. It was not done, however. Could you please look into it? REOPENED. Juris Miščenko Failure check added to resolver structure initialization routine. RESOLVED. Aleksandrs Saveljevs Looks good. Please see r41722 before merging. RESOLVED. Juris Miščenko Looks good! CLOSED.
        Hide
        Juris Miščenko (Inactive) added a comment -

        Fixed in pre-2.0.11 r.41995, pre-2.2.2 r.41998, pre-2.3.0 r.42000.

        Show
        Juris Miščenko (Inactive) added a comment - Fixed in pre-2.0.11 r.41995, pre-2.2.2 r.41998, pre-2.3.0 r.42000.

          People

          • Assignee:
            Unassigned
            Reporter:
            Adrian Tan
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: