On Nov 7, 2013, at 10:18, Wiley, Glen wrote:

> Be careful about conclusions you may draw from your data.  


That's a good point and that is why I am asking.  "Data" is just an indication 
of observations and nothing without outside interpretations.  

On Nov 7, 2013, at 10:24, Jelte Jansen wrote:

> On 11/07/2013 03:52 PM, Edward Lewis wrote:

> ...which would give you only the drawbacks and not the upside...

Fully aware that recursive servers are optimizing for their experience but that 
comes at the cost of predictability.  That sounds like a negative statement but 
it isn't meant to be.  The 'local' optimizations at caches are fine, they just 
make it harder for an authoritative server operator to know what to do.

And, to hark back to the first comment, they jumble up the data, making the 
data something less than an oracle of truth.


> thought), but I do have one immediate question: Did you see specific
> points at which TTLs are no longer adhered to? (e.h. do resolvers out
> there cap TTL values and if so, do they set it to said cap or reduce it
> to a fixed value, or does it appear completely random)?

I am aware that I haven't done that look.  Meaning, it's crossed my mind, I 
haven't gone back to the data though.

I can say though that there's a lot of crud in the data.  E.g., in the top 10 
hitters (meaning IP addresses that sent the most queries), some are mail 
forwarders, some are recursive servers, and some are simply monitors in labs 
measuring the Internet.  (The number 10 hitter is just that, it request the 
same set at a consistent number every day, amounting to a measurable percentage 
of the traffic.  I know the operator and we've talked about this, it's no 
mistake.  Ironically, those just measuring the Internet are also growing it 
just by measuring!)

I mention that because it's an excuse for me not to try to find other 
identifiable patterns.  E.g., it's been said one tool caps (by default) TTL to 
1 day and it would be tempting to look for that tool's use.  But it's drowned 
out by a whole gaggle of unidentifiable patterns.  So it's not like I'm just 
lazy... ;)

> TBH I don't think it's very important to the pre-fetch discussion
> itself; 

I'm citing that work as just an example of what makes it harder to "optimize" 
the authoritative side.  Above I've referred to it as a 'local optimization' 
and that shouldn't be taken as an insult.  But it is true it's "local," and 
even so beneficial.  It adds to the fact that there's never been a reliable 
characterization of how the non-authoritative servers operate.  Like - the 
retry strategies that caused "Rollover and Die" situations (NANOG presentation 
in Jan 2010 or so).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Why is it that people who fear government monitoring of social media are
surprised to learn that I avoid contributing to social media?

_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Reply via email to