Results 1 to 7 of 7
  1. #1
    Join Date
    Aug 2004
    Location
    Tor-NY-BJ
    Posts
    330

    Question How is this DNS setup?

    http://www.dnsstuff.com/tools/dnstim...aol.com&type=A
    gives IPs of NS

    http://www.dnsstuff.com/tools/dnstim...dit.com&type=A
    does not give the IPs of the NS

    run from shell

    dig aol.com
    dig zoneedit.com

    and I did not see any difference from dig

    What is the difference in setup to make dnsstuff to return differently?
    Trusted

  2. #2
    Join Date
    Dec 2004
    Location
    New York City, NY, USA
    Posts
    735
    AOL returns what is called "glued" records, as opposed to Zoneedit which returns "glueless" records.

    The former is MUCH better. Since the IPs for nameservers are returned along with any DNS request for that domain, there is one less DNS request to resolve the IP of a nameserver, which means a faster DNS lookup.

    I don't know BIND, I use djbdns. For djbdns all you need to do is make sure the DNS servers has the IPs of your nameservers.

    Gluelessness is usually a sign of people who don't understand the DNS system and how to optimize it. See these "gluelessness" comment from DJB: http://cr.yp.to/djbdns/notes.html

    These extra DNS records are returned as "additional records." dig SHOULD return this information... at least I remember that it used to. Perhaps it's some option now?

  3. #3
    Join Date
    Aug 2004
    Location
    Tor-NY-BJ
    Posts
    330
    I don't think the glue thing is the problem as dnsstuff.com does not give a glue error. Look at the following two to see the difference a glue will make:

    http://www.dnsstuff.com/tools/dnstim....com.cn&type=A
    with glue

    http://www.dnsstuff.com/tools/dnstim...ide.com&type=A
    without glue

    Read the "take 6 points off" section

    If you dig all of those domains, they all return the same results, so I don't know how to check glueness except going to dnsstuff.com

  4. #4
    Join Date
    Dec 2004
    Location
    Canada
    Posts
    1,082
    If you want to check if there is glue for a record, you need to specify to dig that it should only query the TLD NS, not do a full recursive query.

    For .com/.net/.org:
    dig zoneedit.com @a.gtld-servers.net

    If you get an 'additional section' with A records, there is glue, otherwise there isn't. What DNSStuff is doing I couldn't tell you; ZoneEdit and AOL both seem to be configured as I would expect.

  5. #5
    Join Date
    Dec 2004
    Location
    New York City, NY, USA
    Posts
    735
    @error404: Thanks for the clarification on lookups against authoritative and recursive servers!

    There is a difference in output between zoneedit.com and aol.com...

    For AOL:
    % dig -t a dns-01.ns.aol.com
    Notice that the A records for the other authoritative nameservers are returned as "additional."

    For Zoneedit:
    % dig -t a ns1.zoneedit.com
    Notice that these A records are NOT returned.

    I don't understand why this is important, because contrary to what I said before, this is not technically "glue."

    Just a record for some of the other domains I tried:
    Ones that returned these extra A records (ala aol.com):
    • microsoft.com
    • nabladesign.com: (My domains and network of djbdns-powered nameservers)

    Ones that didn't (ala zoneedit.com):
    • espn.com

  6. #6
    Join Date
    Dec 2004
    Location
    Canada
    Posts
    1,082
    The root servers will only store glue related to the root domain, as they don't have authority over subdomains (such as ns1, dns-01 as in your queries). I'm not sure what you're saying -- if you do a query against the TLD authority, all of those domains return glue:
    Code:
    $> dig a microsoft.com @a.gtld-servers.net
    
    ; <<>> DiG 9.2.4 <<>> a microsoft.com @a.gtld-servers.net
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62661
    ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5
    
    ;; QUESTION SECTION:
    ;microsoft.com.                 IN      A
    
    ;; AUTHORITY SECTION:
    microsoft.com.          172800  IN      NS      ns1.msft.net.
    microsoft.com.          172800  IN      NS      ns2.msft.net.
    microsoft.com.          172800  IN      NS      ns3.msft.net.
    microsoft.com.          172800  IN      NS      ns4.msft.net.
    microsoft.com.          172800  IN      NS      ns5.msft.net.
    
    ;; ADDITIONAL SECTION:
    ns1.msft.net.           172800  IN      A       207.46.245.230
    ns2.msft.net.           172800  IN      A       64.4.25.30
    ns3.msft.net.           172800  IN      A       213.199.144.151
    ns4.msft.net.           172800  IN      A       207.46.66.75
    ns5.msft.net.           172800  IN      A       207.46.138.20
    
    ;; Query time: 418 msec
    ;; SERVER: 2001:503:a83e::2:30#53(a.gtld-servers.net)
    ;; WHEN: Wed Jul 20 15:42:28 2005
    ;; MSG SIZE  rcvd: 209
    
    [[email protected]:~]
    $> dig a nabladesign.com @a.gtld-servers.net
    
    ; <<>> DiG 9.2.4 <<>> a nabladesign.com @a.gtld-servers.net
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37370
    ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
    
    ;; QUESTION SECTION:
    ;nabladesign.com.               IN      A
    
    ;; AUTHORITY SECTION:
    nabladesign.com.        172800  IN      NS      a.ns.nabladesign.com.
    nabladesign.com.        172800  IN      NS      b.ns.nabladesign.com.
    nabladesign.com.        172800  IN      NS      c.ns.nabladesign.com.
    
    ;; ADDITIONAL SECTION:
    a.ns.nabladesign.com.   172800  IN      A       72.36.165.250
    b.ns.nabladesign.com.   172800  IN      A       70.56.138.17
    c.ns.nabladesign.com.   172800  IN      A       70.56.214.217
    
    ;; Query time: 441 msec
    ;; SERVER: 2001:503:a83e::2:30#53(a.gtld-servers.net)
    ;; WHEN: Wed Jul 20 15:43:19 2005
    ;; MSG SIZE  rcvd: 132
    
    [[email protected]:~]
    $> dig a espn.com @a.gtld-servers.net
    
    ; <<>> DiG 9.2.4 <<>> a espn.com @a.gtld-servers.net
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61168
    ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
    
    ;; QUESTION SECTION:
    ;espn.com.                      IN      A
    
    ;; AUTHORITY SECTION:
    espn.com.               172800  IN      NS      auth03.ns.uu.net.
    espn.com.               172800  IN      NS      auth50.ns.uu.net.
    
    ;; ADDITIONAL SECTION:
    auth03.ns.uu.net.       172800  IN      A       198.6.1.83
    auth50.ns.uu.net.       172800  IN      A       198.6.1.161
    
    ;; Query time: 418 msec
    ;; SERVER: 2001:503:a83e::2:30#53(a.gtld-servers.net)
    ;; WHEN: Wed Jul 20 15:43:59 2005
    ;; MSG SIZE  rcvd: 109

  7. #7
    Join Date
    Dec 2004
    Location
    New York City, NY, USA
    Posts
    735
    error404: Right. Like I said in my previous post, ignore what I said about gluelessness... The root servers already have these records so they are fine.

    DNSStuff's DNS time program, however, only appears to display what the "lowest" DNS server returns (which in the aol.com/zoneedit.com examples, is the name server A records). I don't know why since this isn't the "natural" path to follow of a DNS query--the root servers already had the glue so a query would not have had to go down so far.

    So to answer the OP, that's the difference between aol.com and zoneedit.com. I can't say I know the configuration that causes this, but since whatever DNSStuff's DNS time program isn't the normal way to resolve a query, it doesn't matter.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •