On 2013-09-17, at 08:42, Paul Tinson
I believe it is listed as Orcon Magical Pony... Or a version of unbound, depends of sleep deprivation levels...
If you use the acl and set allow, trace fails, set allow_snoop and trace works.
I had not actually ever heard of "cache snooping" as a concept. Resolvers exist to answer questions from their client pool, and mechanisms that act to ignore queries (like RRL on authoritative-only servers) are generally considered inappropriate for resolvers. "snooping" seems like a weird word for "using a service provided for you to use" :-)
I seem to recall looking at what dig did during a +trace and it was doing non RD requests, it only showed up like that if you also happen to have @<IP> specified. Which while i type makes sense, because dig "Should" be acting as a recursor and doing non recursive queries.
Clearly I am rambling and in need of sleep. Sorry if you read all the way to this point:)
Makes sense, RD=0 queries are not obviously client queries of the type you'd expect end-users to trigger, and dropping them doesn't seem like a completely horrible idea, although you're making assumptions about your users behaviour that might make the support phone ring. The unbound docs say: The action allow_snoop gives nonrecursive access too. This give both recursive and non recursive access. The name allow_snoop refers to cache snooping, a technique to use nonrecursive queries to examine the cache contents (for malicious acts). However, nonrecursive queries can also be a valuable debugging tool (when you want to examine the cache contents). In that case use allow_snoop for your administration host. which seems like it's intended to be used to expand the possible access to your server without opening it fully to the world ("give full access to my users, but allow non-users also to inspect the cache with queries that have RD=0 for diagnostic purposes"). I think the "malicious acts" above does not mean opening the cache to abuse, but rather giving people outside your user pool the opportunity to see whether your particular cache has been poisoned with respect to their names. If I'm reading that right, then I think the expectation is that you would provide full access to your own users, and (if you feel like it) provide allow_snoop access to others. I don't think the implication is that you should expect any advantage to restricting your own users with allow_snoop. ("allow_snoop" to the world would make you a reasonable amplifier for people doing reflection attacks, which I think makes it a bad idea unless contributing to the global effort to fill the pipes is part of your game plan.) I usually tell people that dig +trace is a pretty horrible diagnostic tool, for what that's worth. When it works it doesn't really mean that everything is ok, and when it fails it doesn't really mean that everything is broken. That's not very much awesome. Joe