Is there a command that shows what's happening to a WISP at the DNSserver level?

Discussion in 'Wireless Internet' started by U vigilance, Sep 23, 2011.

  1. U vigilance

    U vigilance Guest

    I am trying to figure out why my Santa Cruz mountains Surfnet WISP setup
    takes so long to load a web page (even Google's bare bones home page
    takes, sometimes far too long) so I'm trying to better understand how DNS
    servers work.

    What I have in my wrt54g home router is a set of three supposedly fast DNS
    servers from this DNS server list:

    But, even so, on multiple computers in the home, Linux & Windoze, it
    takes far too long to 'get' the web pages, even though
    shows 18ms ping latency, 1Mbps upload, & 1.2 Mbps download.

    I keep getting intermittent "Microtik hotspot errors" from Surfnet ...
    and their (rather grouchy) technical support blamed my DNS servers setup.

    I can't prove or disprove that until/unless I better understand DNS
    servers, overall, and how they impact speed of loading (or not loading)
    web pages.

    Is 'this' what happens?

    1. I type in my laptop browser on PC
    2. That "" request goes wirelessly to my office wrt54g
    router which is


    3. The office wrt54g router sends that "" request to the
    rooftop ubuquiti radio which is but the office wrt54g
    router must also be sending its DNS server list to the bridge (right?)
    a) wrt54g DNS1 =
    b) wrt54g DNS2 =
    c) wrt54g DNS3 =
    d) wrt54g WINS = blank

    What command can I use to 'see' that DNS transaction?

    4. My rooftop ubiquiti radio sends the "" request & DNS
    list to my rooftop antenna which sends it through the air to the Surfnet
    line-of-sight antenna on


    5. Surfnet sees that request for "" and the list of three
    DNS servers (I guess), and it forwards that "" request to
    the first of those DNS servers (I guess) which is

    6. The DNS server at presumably forwards back the IP address of
    "" (e.g., but a "traceroute"
    on Ubuntu doesn't seem to show any of that).


    Here is a traceroute:

    $ traceroute
    traceroute to (, 30 hops max, 60 byte
    1 ( 2.587 ms 7.338 ms 7.903 ms
    2 ( 16.803 ms 17.272 ms 17.713 ms
    3 ( 20.221 ms 20.353 ms 20.523 ms
    4 ( 20.618 ms 20.837 ms 21.409 ms
    5 ( 23.447 ms 23.628 ms 23.856
    6 ( 24.043 ms 5.466 ms
    15.656 ms
    7 ( 16.140 ms
    16.763 ms 17.040 ms
    8 ( 17.494 ms core3.pc2- ( 21.470 ms core3.pc1- ( 21.654 ms
    9 ( 21.791
    ms 21.941 ms 22.055 ms
    10 ( 22.256 ms 25.348
    ms 27.017 ms
    11 ( 26.147 ms * 27.038
    12 * * *
    13 ( 13.144 ms
    13.649 ms 17.372 ms
    14 ( 17.558 ms 17.943 ms 18.496 ms
    15 ( 18.914 ms 26.702 ms 24.631 ms
    16 ( 26.859 ms 27.346 ms 27.018 ms

    Obviously I'm confused but I'm trying to debug why web pages,
    intermittently, take far too long to load (and one out of fifty fail
    outright, giving a Microtik hotspot error,

    Is there a command that shows what is happening at the DNS server level?
    U vigilance, Sep 23, 2011
    1. Advertisements

  2. Greeting from Ben Lomond.
    Pick your server using Google Namebench or Gibson's DNSbench.
    Are you cacheing DNSlookups in your router? If so, that may be the
    problem. Some routers are just plane buggy. Unfortunately, the
    WRT54G is one of those. If v4 and below, you're probably ok. If v5
    or v6, they're garbage. I forgot what v7 and v8 are like.
    I see you've talked to Brett. Say hellow for me. He's really a good
    guy, but thoroughly overloaded and minimally supported.

    You should NOT be seeing Microtik hotspot error messages unless
    SurfnetC is running their mesh as a hot spot or that you're connecting
    via wireless to their Mikrotik mesh router. My guess is the latter
    and that you're having connection issues between your wireless
    laptop/desktop and the Mikrotic wireless router on your roof? Since
    they are both operating on the same RF channel, you're going to get
    intererence from other users and other mesh routers connecting to it.
    Plenty of ways to screw up DNS lookups.
    So far, so good. Have you tried taking the office wireless link out
    of the picture and connecting to the WRT54G with a CAT5 cable? You
    Close. The WRT54G router has a DNS cache inside. It will first look
    in the unspecified operating system's DNS cache on the laptop for the
    IP address. If Windoze XP, you can get this list with:
    ipconfig /displaydns
    You can also clear it with:
    ipconfig /flushdns

    If there's nothing for google on the laptop, it goes to whatever is
    the default gateway. If your unspecified operating system on your
    laptop has as the default gateway, it will query for the IP address. The WRT54G router also has a DNS
    cache, where it looks for a match for If found, it
    returns whatever is stored. There's no way to get to the DNS lookup
    table with the stock firmware.

    If nothing is found in the router, it goes to the first DNS server and
    queries for (I do NOT want to dive into details on
    how it parses the FQDN, TLD servers, or recursive lookups). If the
    first DNS server is down or times out, it goes to the 2nd DNS server.
    This usually takes about 30-45 seconds. If both the first and 2nd are
    down, it goes to the third. It tries 3-4 times each and then gives up
    with an error message, which could easily take over a minute.
    What operating system are you using on your laptop?
    It can't be done with the stock Linksys firmware.
    I didn't know the SurfnetC is now using Ubiquiti. Are you sure?
    Ok, you're using Ubuntu. Good to know. Thanks.

    For Ubuntu, you may or may not have the DNS cache (nscd) enabled:
    If nscd is not installed, don't worry about the local cache. However,
    if installed, look for corruption and garbage.
    Namebench or DNSbench. Namebench should run on Linux.
    Hint: Take as much of the intermediate hardware at your house out of
    the picture. That means plug your PC directly into the
    Mikrotic/Ubiquiti/whatever router. Test again.
    Not that I know of.
    Jeff Liebermann, Sep 24, 2011
    1. Advertisements

  3. nslookup might be helpful. It will show which servers are being
    queried, but not the relevent timing. If it takes a while to get a
    response, then there are delays. Maybe someone has done a version
    that includes timing. Dunno.

    The idea behind the is to find a domain that is probably
    NOT in a cache somewhere. Much easier than flushing the caches. This
    is Windoze XP because I'm too lazy to warm up the Linux laptop.

    You can crank up the debug level with:
    set d2

    You can use Google DNS instead of your local DNS with

    C:\> nslookup
    Default Server: DD-WRT
    Server: DD-WRT

    Got answer:
    opcode = QUERY, id = 2, rcode = NOERROR
    header flags: response, want recursion, recursion avail.
    questions = 1, answers = 1, authority records = 2,
    additional = 0

    QUESTIONS:, type = ANY, class = IN
    internet address =
    ttl = 7200 (2 hours)
    nameserver =
    ttl = 172800 (2 days)
    nameserver =
    ttl = 172800 (2 days)

    Non-authoritative answer:
    internet address =
    ttl = 7200 (2 hours)
    nameserver =
    ttl = 172800 (2 days)
    nameserver =
    ttl = 172800 (2 days)
    Jeff Liebermann, Sep 24, 2011
  4. Also try dig.
    Jeff Liebermann, Sep 24, 2011
  5. Also try using "dig". It shows all the DNS servers that are being
    queried and supplies the times. Nice.

    C:\> dig +trace

    ; <<>> DiG 9.3.2 <<>> +trace
    ;; global options: printcmd
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    .. 248165 IN NS
    ;; Received 500 bytes from in 62 ms

    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    com. 172800 IN NS
    ;; Received 507 bytes from in 125
    ms 172800 IN NS 172800 IN NS
    ;; Received 114 bytes from in 250
    ms 300 IN A
    ;; Received 51 bytes from in 218
    Jeff Liebermann, Sep 24, 2011
  6. U vigilance

    miso Guest

    FWIW, I ran the google code. Their solution was twice as fast (so they
    claim) as my isp DNS, so I changed the DNSs to their suggestions. I
    don't know what I'm going to do with all the millisecond I've saved.
    miso, Sep 29, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.