<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 02/15/2013 12:37 PM, Chris Buxton
      wrote:<br>
    </div>
    <blockquote
      cite="mid:99F80E51-6287-4106-B521-C3FAEDF4899B@buxtonfamily.us"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=iso-8859-1">
      <br>
      <div>
        <div>On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite"><span class="Apple-style-span">
            <div class="hmmessage">
              <div dir="ltr"><br>
                Running bind rooted on FC 16 using the standard package.<br>
                <br>
                The ca file is located in
                /var/named/chroot/var/named/named.ca<br>
                <br>
                The hints are not built in.<span
                  class="Apple-converted-space"> </span><br>
                [shawn@www ~]$ strings /usr/sbin/named | grep<span
                  class="Apple-converted-space"> </span><a
                  moz-do-not-send="true"
                  href="http://A.ROOT-SERVERS.NET/">A.ROOT-SERVERS.NET</a><br>
                returns nothing.<br>
              </div>
            </div>
          </span></blockquote>
      </div>
      <br>
      <div>Yes they are. All versions of BIND since 9.3 or so have had
        the root hints built in. Even Red Hat's version. Unfortunately,
        Warren missed a trick of some sort -- I suspect that if you
        strip the binary, the 'strings' command won't find the values.
        But they're still there. Adam Tkac would not remove this from
        the Red Hat SRPM.</div>
    </blockquote>
    <br>
    I will do some more testing with this to see if I can indeed remove
    the root.hint includes.  But I have a question.  I have tried to dig
    in my server for the root info like you can a root server, but
    obviously this is not the way to do it, as I get an empty list
    eventhough I know I can resolve names that I am not authoritative
    for.<br>
    <br>
    I tried<br>
    <br>
    dig +bufsize=4096 . ns @localhost<br>
    <br>
    (and without the bufsize) and it comes back with a warning that
    recursion requested but not available and an empty list.  More
    interestingly is that in /var/log/messages it shows:<br>
    <br>
    named[2872]: client ::1#57049: view external: query (cache)
    './NS/IN' denied<br>
    <br>
    I would think this should go to my internal view?  I even put
    127.0.0.1 into my match-clients/destinations network list and it is
    still using the external view.<br>
    <br>
    <blockquote
      cite="mid:99F80E51-6287-4106-B521-C3FAEDF4899B@buxtonfamily.us"
      type="cite">
      <div><br>
      </div>
      <div>Root hints, as somebody pointed out, are just hints. There is
        no reason to focus on making sure they're 100% accurate. There's
        also no point in stripping the IPv6 addresses out of the root
        hints zone if you don't have IPv6 -- the real list will be
        fetched (by DNS query) from the servers in the hints file,
        including all of their IPv6 addresses.</div>
      <div><br>
      </div>
      <div>If your DNS server doesn't have IPv6 connectivity, I have two
        comments for you:</div>
      <div><br>
      </div>
      <div>- Why not? It's easy to get a tunnel, if nothing else is
        available.</div>
    </blockquote>
    <br>
    I have a /48 allocated to my home lab  :)  (I also have a /26 IPv4
    allocation here)<br>
    <br>
    <blockquote
      cite="mid:99F80E51-6287-4106-B521-C3FAEDF4899B@buxtonfamily.us"
      type="cite">
      <div><br>
      </div>
      <div>- Start named with the -4 argument to prevent it from trying
        to contact IPv6 addresses.<br>
      </div>
    </blockquote>
    <br>
    <br>
  </body>
</html>