[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 ...
-
[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
-
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.
-
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
-
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.
