DIG question

Kevin Darcy kcd at daimlerchrysler.com
Mon Apr 5 23:17:14 UTC 2004


Well, what did you think the "+trace" parameter was going to do? Here's 
the relevant excerpt from the man page, with some of my own emphasis added:

+[no]trace
          Toggle tracing of the delegation  path  
*from*the*root*name*servers  for the name being looked up. Tracing is 
disabled by default. When tracing is enabled, dig makes iterative  
queries to resolve the name being looked up. It will *follow* referrals 
from the root servers, showing the answer from *each*server* that was 
used to resolve the lookup.

Since your local server is not -- apparently -- in the delegation chain 
for the name www.fakedomain.gr, then it is never found and therefore 
never consulted by dig when the "+trace" flag is in effect. These are 
exactly the results that you should expect to see for a "fake" (= 
undelegated) domain.

                                                                         
                                             -Kevin

Sara wrote:

>Hi all,
>
>I created a fake domain on my server (BIND 9.2.3 Linux Red-Hat 7.3).
>
>Then I issued the following:
>
>        # dig @localhost www.fakedomain.gr +short
>
>Correct IP received.
>
>
># dig @localhost www.myfakedomain.gr  +trace
>
>; <<>> DiG 9.2.1 <<>> @localhost www.myfakedomain.gr +trace
>;; global options:  printcmd
>..                       95722   IN      NS      E.ROOT-SERVERS.NET.
>..                       95722   IN      NS      F.ROOT-SERVERS.NET.
>..                       95722   IN      NS      G.ROOT-SERVERS.NET.
>..                       95722   IN      NS      H.ROOT-SERVERS.NET.
>..                       95722   IN      NS      I.ROOT-SERVERS.NET.
>..                       95722   IN      NS      J.ROOT-SERVERS.NET.
>..                       95722   IN      NS      K.ROOT-SERVERS.NET.
>..                       95722   IN      NS      L.ROOT-SERVERS.NET.
>..                       95722   IN      NS      M.ROOT-SERVERS.NET.
>..                       95722   IN      NS      A.ROOT-SERVERS.NET.
>..                       95722   IN      NS      B.ROOT-SERVERS.NET.
>..                       95722   IN      NS      C.ROOT-SERVERS.NET.
>..                       95722   IN      NS      D.ROOT-SERVERS.NET.
>;; Received 436 bytes from 127.0.0.1#53(localhost) in 1 ms
>
>gr.                     172800  IN      NS      GRDNS.ICS.FORTH.gr.
>gr.                     172800  IN      NS      ESTIA.ICS.FORTH.gr.
>gr.                     172800  IN      NS      NIC.AIX.gr.
>gr.                     172800  IN      NS      DNS1.ICS.FORTH.gr.
>gr.                     172800  IN      NS      GRDNS-DE.DENIC.DE.
>gr.                     172800  IN      NS      GRDNS-US.ICS.FORTH.gr.
>gr.                     172800  IN      NS      GRDNS-AT.ICS.FORTH.gr.
>gr.                     172800  IN      NS      GRDNS-BR.ICS.FORTH.gr.
>;; Received 356 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in
>241 ms
>
>gr.                     3600    IN      SOA     grdns.ics.forth.gr.
>hmaster-info.ics.forth.gr. 404051313 21600 7200 2592000 3600
>;; Received 102 bytes from 139.91.1.1#53(GRDNS.ICS.FORTH.gr) in 104 ms
>
>
>Why in one case does BIND respond with its own data and in the other
>case goes to the Internet and fails?
>TIA all!
>
>Sara
>
>
>
>
>  
>




More information about the bind-users mailing list