Hello,
New to the list and running unbound svn rev 1281.
With unbound I'm not able to successfully resolve a particular IP address and
the query times are very long compared to bind. Also dig's "+trace" does not
appear to work from systems on my lan.
Hi Chris,
I notice that the servers for 2.112.119.209.in-addr.arpa. are
recursion-lame. They are not authoritative, but recursive for that zone.
This is why unbound refuses to accept the answer, and tries other
servers. However, the servers are identical.
The servers are also open recursors.
As for the run time, that could be because you have a freshly started
unbound, with an empty cache. That means it has to spend time to fetch
com, org, root data. I tested quickly, empty cache + query for
www.google.com and google.org, then www.xo.com and it takes 250 msec
only (twice as fast as your number), although that could be just luck.
I am prepared to make fallback code that handles 'all servers are
recursive instead of authoritative'-error, and send a +RD(recursion
desired) query there, but only as a last resort. It is unsafe you see,
that caching recursive server may have been cache poisoned.
Thank you for the detailed error report.
Best regards,
Wouter
Chris Smith wrote:
Thank you!
Easily overlooked in my post was that dig's +trace switch doesn't seem to work
with unbound:
Chris Smith wrote:
Thank you for the detailed error report.
Thank you!
Easily overlooked in my post was that dig's +trace switch doesn't seem to work
with unbound:dig host.domain.example +trace
Does not return a trace as it does with bind.
Oops,
ok, never used that option before - it seems to make +nonrec queries
against the local resolver to find the roots. Unbound (from svn) does
not allow cache snooping by default.
You can either change the acl to allow the cache snooping
or do dig @c.root-servers.net host.domain.example +trace
Best regards,
Wouter
Hi David,
David Miller wrote:
I didn't realize that this had changed between 1.0.2 to the current SVN
version.How would one "change the acl to allow the cache snooping"?
access-control: 127.0.0.0/8 allow_snoop
or even
access-control: 0.0.0.0/0 allow_snoop
in the config file.
Does dig +trace really require "cache snooping"? Sounds ominously bad
Well, if you are willing to type @c.root-servers.net on the
commandline (or make an alias), then it doesn't require snooping, I noticed.
(the nonrecursive query is sent to the root server, instead of to the
local resolver).
dig +trace uses nonrecursive queries, which are useful for debugging.
And dig is a debugging tool. But they are also used for 'cache
snooping', which is where you probe the resolver to find out which
domains are in the cache (i.e. what websites have been visited).
What is the downside of allowing this?
The text above. Also it can be used to see which domains are not in the
cache, which is useful to know for cache poisoning.
You can only allow your own workstation, for example.
Or make an alias digtrace="dig +trace @h.root-servers.net"
BTW: I find the +trace option amazingly useful in troubleshooting
reverse DNS delegations (see below).
Yeah that is nice.
FYI: DJB has never supported queries with +trace. I am sure that he has
his reasons, but I don't believe that they have ever been publicly stated.
Well I heard DJB disallows cache snooping as well, I think for the same
reasons.
Best regards,
Wouter
Hi Chris,
The current svn (r1294) contains such last resort fallback code. I hope
this means all your queries resolve now.
Best regards,
Wouter
W.C.A. Wijngaards wrote:
Hi Wouter,
Thanks much! Although my client did dump that ISP (they had a lot of problems).
Chris
