Re: why does dig +trace change outcome? - DNS

This is a discussion on Re: why does dig +trace change outcome? - DNS ; On Sat, Jun 21, 2008 at 5:53 PM, Hal Brooks wrote: > > Some name servers, but not all, are unable to resolve > krensavage.com > > But even those which are ordinarily unable to resolve > krensavage.com seem to ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: why does dig +trace change outcome?

  1. Re: why does dig +trace change outcome?

    On Sat, Jun 21, 2008 at 5:53 PM, Hal Brooks wrote:
    >
    > Some name servers, but not all, are unable to resolve
    > krensavage.com
    >
    > But even those which are ordinarily unable to resolve
    > krensavage.com seem to be able to get answers with dig if
    > the +trace option is used.
    >
    > For example, this web site:
    >
    > http://www.kloth.net/services/dig.php
    >
    > offers a browser interface to dig. If you use their
    > localhost as the server and query for an A record, but
    > don't specify "trace", then the unhappy result is
    > "connection timed out; no servers could be reached", but if
    > you do specify "trace" then you get 6 answers.
    >
    > Similarly from the command line:
    >
    > dig @dns1.uga.edu krensavage.com # times out
    > dig @dns1.uga.edu krensavage.com +trace # OK
    >
    > But other name servers handle it fine (and dig works
    > even without +trace):
    >
    > dig @ns1.usg.edu krensavage.com # OK
    > dig @ns1.usg.edu krensavage.com # also OK
    >
    > The only shortcoming I see with the krensavage.com setup is
    > that the whois record only has 1 name server
    > (yns1.yahoo.com) listed.
    >
    > For comparison, olivebarn.com, has similar characteristics
    > (though the whois record lists both yns1.yahoo.com and
    > yns2.yahoo.com), but it doesn't result in the same failures
    > I'm seeing for krensavage.com.
    >
    > Any and all help appreciated.
    >
    > -hal
    >

    Hello Hal,
    This domain has been delegated to only 1 NS server at root servers.

    #dig +short +norec ns krensavage.com @a.gtld-servers.net
    yns1.yahoo.com.

    Whereas, authoritative server lists 3 other servers;

    #dig +short +norec ns krensavage.com @yns1.yahoo.com
    ns8.san.yahoo.com.
    yns2.yahoo.com.
    yns1.yahoo.com.
    ns9.san.yahoo.com.

    I suppose, it is better to fix this mismatch first. Because trace option
    causes dig to make iterative queries,
    you don't see the response from the cache.




  2. Re: why does dig +trace change outcome?

    "Genco Yilmaz" writes:

    > This domain has been delegated to only 1 NS server at root servers.


    you mean "at the TLD servers". the root servers delegate to COM in this case.

    > #dig +short +norec ns krensavage.com @a.gtld-servers.net
    > yns1.yahoo.com.
    >
    > Whereas, authoritative server lists 3 other servers;
    >
    > #dig +short +norec ns krensavage.com @yns1.yahoo.com
    > ns8.san.yahoo.com.
    > yns2.yahoo.com.
    > yns1.yahoo.com.
    > ns9.san.yahoo.com.
    >
    > I suppose, it is better to fix this mismatch first.


    always.
    --
    Paul Vixie


  3. Re: why does dig +trace change outcome?

    Hi,
    yes, indeed TLD servers not root ones.
    thanks for correcting

    On Sun, Jun 22, 2008 at 1:11 AM, Paul Vixie wrote:

    > "Genco Yilmaz" writes:
    >
    > > This domain has been delegated to only 1 NS server at root servers.

    >
    > you mean "at the TLD servers". the root servers delegate to COM in this
    > case.
    >
    > > #dig +short +norec ns krensavage.com @a.gtld-servers.net
    > > yns1.yahoo.com.
    > >
    > > Whereas, authoritative server lists 3 other servers;
    > >
    > > #dig +short +norec ns krensavage.com @yns1.yahoo.com
    > > ns8.san.yahoo.com.
    > > yns2.yahoo.com.
    > > yns1.yahoo.com.
    > > ns9.san.yahoo.com.
    > >
    > > I suppose, it is better to fix this mismatch first.

    >
    > always.
    > --
    > Paul Vixie
    >
    >





  4. RR Set order fixed


    Hi

    Iam using ISC -BIND 9.3.4. I am trying to fix the order of A records but
    its not being fully implemented and providing me the same order even I
    reverse the records
    Its always giving me the smaller IP Address firstly

    Can anybody tell that is it a bug and how I fix the order of A records
    in a specific order

    Regards
    Vivek Aggarwal


  5. Re: RR Set order fixed

    Agarwal Vivek-RNGB36 wrote:
    > Iam using ISC -BIND 9.3.4. I am trying to fix the order of A records but
    > its not being fully implemented and providing me the same order even I
    > reverse the records
    > Its always giving me the smaller IP Address firstly
    >
    > Can anybody tell that is it a bug and how I fix the order of A records
    > in a specific order


    Not knowing what you have tried, I'll tell you that the following works
    fine (BIND 9.4.2):

    options {
    [...]
    rrset-order {type A name "*.home.clegg.com" order fixed; order random;};
    [...]
    };

    AlanC




  6. Re: RR Set order fixed

    > I am using ISC -BIND 9.3.4.

    That's the problem. Switch to 9.4.2, or to 9.5.0 and compile
    with "configure --enable-fixed-rrset". (The feature is there by
    default in 9.4, but optional in 9.5.)

    --
    Evan Hunt -- evan_hunt@isc.org
    Internet Systems Consortium, Inc.


+ Reply to Thread