<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFCC" text="#000000">
    <br>
    <br>
    On 12/10/11 22:08, David Miller wrote:
    <blockquote cite="mid:4E95F3AC.5020707@tiggee.com" type="cite">On
      10/12/2011 3:01 PM, Kevin Darcy wrote:
      <br>
      <blockquote type="cite">On 10/12/2011 1:21 PM, Martin McCormick
        wrote:
        <br>
        <blockquote type="cite">Many years ago, various flavors of unix
          began distributing a
          <br>
          utility called host which did almost the same thing as
          nslookup.
          <br>
          Host is what I use most of the time, now, and I actually
          thought
          <br>
          that nslookup on unix systems was maybe going away.
          <br>
          <br>
              A coworker recently asked me about nslookup on our
          <br>
          FreeBSD system and I verified the behavior he was asking
          about.
          <br>
          <br>
              Other than a different output format, what are the
          <br>
          advantages of having both host and nslookup.
          <br>
          <br>
              On the FreeBSD system in question, nslookup is
          <br>
          definitely a different binary than is host so one is not
          <br>
          hard-linked to the other.
          <br>
          <br>
              The behavior he was asking about was simply that all
          <br>
          foreign domains that one looks up with nslookup report as
          <br>
          non-authoritative since the DNS one is using isnot
          authoritative
          <br>
          for, say, microsoft.com or yahoo.com.
          <br>
          <br>
              This is not a problem. I am just curious.
          <br>
          <br>
        </blockquote>
        nslookup has lots of problems. Four that I can cite off the top
        of my head:
        <br>
        1) most versions of nslookup will stop dead in their tracks if
        they can't reverse-resolve the name of whatever resolver they're
        trying to use (even though that's basically irrelevant to the
        actual lookup that the user requested)
        <br>
        2) nslookup will by default use a searchlist, but it does this
        completely invisibly by default (unless a debugging option is
        turned on), and thus will often mis-represent the real result of
        the query (e.g. you look up foo.example1.com, that gets a
        SERVFAIL, then unbeknownst to the user, nslookup tries the
        searchlist'ed name foo.example1.com.example2.com and reports the
        resulting NXDOMAIN as the final error of the lookup, thus
        obscuring the real error -- SERVFAIL)
        <br>
        3) the default output format of nslookup doesn't distinguish the
        result of the query from the identity of the resolver clearly
        enough, so unsophisticated users will often think that the name
        they're looking up actually resolves to the address of the DNS
        resolver, and much hilarity ensues (mis-routed trouble tickets,
        drama, confusion, etc.)
        <br>
        4) some versions of nslookup display atypical DNS responses
        (e.g. dangling CNAMEs, referrals) in very confusing,
        non-intuitive ways.
        <br>
        <br>
                                                                                                                                                       
                                                    - Kevin
        <br>
      </blockquote>
      <br>
      Use dig.
      <br>
      <br>
      Always use dig.  If dig isn't installed - install dig and then use
      dig.  Make dig part of your default set of packages on all boxes.
      <br>
      <br>
      "host vs nslookup?" is asking whether you should hit your self in
      the head with a small or large hammer.
      <br>
      <br>
      Put down the hammer and use dig.
      <br>
    </blockquote>
    I don't quite agree, for debugging bind, use dig - for debugging
    lookup issues on some machine, host will behave more like any normal
    program, using resolv.conf and what else and can point to some
    issues dig will not discover. E.g. normal SW using something else
    than DNS, because of some setup. Dig will never catch this.<br>
    <blockquote cite="mid:4E95F3AC.5020707@tiggee.com" type="cite">
      <br>
      -DMM
      <br>
      <br>
      _______________________________________________
      <br>
      Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to
      unsubscribe from this list
      <br>
      <br>
      bind-users mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 
</pre>
  </body>
</html>