[9fans] dns - Plan9

This is a discussion on [9fans] dns - Plan9 ; i realize this is apolitical and offtopic. i apologize in advance. geoff's improvements in dns are really quite nice. dns appears do a good job in the face of well-behaved servers, but there are some ill behaved ones for popular ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: [9fans] dns

  1. [9fans] dns

    i realize this is apolitical and offtopic. i apologize in advance.

    geoff's improvements in dns are really quite nice. dns appears do a good
    job in the face of well-behaved servers, but there are some ill behaved ones
    for popular sites that give me occasional fits.

    for example, www.apple.com decided to disappear last evening. i looked
    into the problem and nserver*.apple.com were not reachable. and the
    reason the local nameserver didn't have www.apple.com cached is that
    the ttl of www.apple.com is 60 seconds.

    interestingly, a dsl modem we have here continued to resolve www.apple.com
    during this time, though it also couldn't reach the nameserver.
    it seems that the dsl modem's resolver or upstream cache was just
    serving up a stale rr.

    this is a common problem around here (esp.) for akadns-served sites
    with very low ttls. i'm thinking it would make sense to either
    (in order of increasing preference andimplementation difficulty )

    a) ignore very short, but nonzero, ttls and make them at least 3600s.

    b) serve up stale rrs if a fresh answer isn't available up to some multiple
    of the real ttl.

    c) activly refresh the "most active" cache entries starting at 1/2 the ttl
    and increasing in frequency until some mutiple of ttl has expired.

    - erik

  2. Re: [9fans] dns

    I've seen the same thing with ibm.com and google.com; they tend to use
    ttls of 5 minutes or less. On the other hand, we use short ttls
    internally for zones like cs.bell-labs.com. It's tempting to set a
    floor on ttls for NS records at least, but ultimately I wonder why
    expired data isn't just getting replaced. Perhaps the time-outs on
    queries need to be adjusted.

    One problem we see locally is that we never seem to get negative
    answers to queries, notably for AAAA and CNAME queries, which rarely
    succeed, so we wait for the queries to time out instead of getting
    prompt negative answers from our upstream nameservers.


  3. Re: [9fans] dns

    ah, we're out of phase 180 degrees.

    the particular problem i happened to catch the other day found
    nserver*.apple.com unreachable starting from the root. i tried with
    dig on linux, too. that didn't work either. but perhaps trying harder
    would make sense.

    i noticed that you aren't seeing negative responses to cname queries
    from the code. is that something particular to your
    environment or is that something we are likely to see, too.?

    unfortunately akadns uses cnames in their scheme. this really stinks.
    it seems that the timeout in such a case should depend on the name.
    (awful, no?)

    i wonder if it might be safe to replace small tts with the expire time in the
    soa. being on the other end of that a decade ago, i remember to maintaining a
    server at an old ip address for 2*expiretime to ensure that everybody had
    updated. it was suprising how long the old ip address was cached.

    - erik

  4. Re: [9fans] dns

    I'm not sure if the lack of negative answers is a local phenomenon or
    not, but I suspect so. Our dns environment got more complex a few
    months ago and our upstream dns servers may be at fault.


+ Reply to Thread