[sf-lug] pdns-recursor

Tue May 4 18:55:00 PDT 2010

It's working!

Adding 
access-control: 10.0.0.0/8 allow
to /etc/unbound/unbound.conf
did the trick.
Grant was pointing me in that direction but I didn't really appreciate what he was trying to tell me until I read Rick's notes on how to trouble shoot DNS.

Thank you very much.

Am I right in my assumption that what's in /etc/resolv.conf on the plug (the machine running unbound) becomes irrelevant? Should I change it to a one liner consisting of 
nameserver localhost
and delete what was there before, namely:
search sonic.net
domain sonic.net
nameserver 208.201.224.11
nameserver 208.201.224.33
??????

Cheers and thanks again.
alex

a_kleider at yahoo.com

--- On Tue, 5/4/10, Rick Moen <rick at linuxmafia.com> wrote:

> From: Rick Moen <rick at linuxmafia.com>
> Subject: Re: [sf-lug] pdns-recursor
> To: "Linux userGroup" <sf-lug at linuxmafia.com>
> Date: Tuesday, May 4, 2010, 9:09 AM
> Quoting Alex Kleider (a_kleider at yahoo.com):
> 
> > Thanks, Rick, for the tip. 
> > 
> > I've got 'unbound' installed and 
> > # ps aux | grep unbound 
> > tells me it's running.
> > It's running on host 'plug' that has IP address
> 10.0.0.175
> > 
> > .. but it's still not actually being used for DNS!
> > I can't seem to get the configuration figured out.
> > If I instruct my dhcp server (also running on 'plug')
> to direct clients to 10.0.0.175 for dns, things fail.
> > I would have thought that part of the unbound
> configuration would be
> > to direct it to an outside DNS server (or servers)
> where it could
> > begin it's queries but the documentation makes no
> mention of such an
> > entry.
> 
> There is such a configuration.  It's a default. 
> 
> To be more precise, the daemon has an internal list of the
> 13 root
> nameservers that it relies on to find the rest of the DNS
> world, e.g.,
> the top-level domain nameservers for .COM namespace, the
> domain-specific
> nameservers for linuxmafia.com namespace, etc.  You
> might be used to
> forwarder-type nameservers that don't actually do the work
> of resolution
> themselves, but just send all queries off to a full-service
> nameserver
> whose IP is listed in the forwarder's conffile. 
> Unbound _is_ a
> full-service nameserver, so all it needs to do its job is
> its internal
> knowledge of what IPs the world's 13 root nameservers
> have.
> 
> Just in case the roster of root nameservers changes, which
> happens at
> long intervals, Unbound's unbound.conf file supports a
> 'root-hints'
> keyword, which can point to a list of root nameservers in
> standard
> zonefile format.  You _might_ already find such a file
> referenced from
> your unbound.conf .
> 
> Anyway, you might be thinking 'That's cool, but I don't see
> how it helps
> me solve my problem.'  True, but I wanted to address
> your question.  ;->
> Also, you should know how the thing works.
> 
> What you want to do is use a simple tool like 'dig' for
> diagnostic
> purposes, to see _where_ things are failing.  So, for
> starters, login to
> the 'plug' host.  You're now on the machine where
> Unbound is running.
> That host has (at least) two active network
> interfaces:  the loopback
> interface has (as always) IP address 127.0.0.1, and one of
> the others,
> probably eth0, has IP 10.0.0.175.  Let's send Unbound
> a query from the
> local machine, on each of those interfaces:
> 
> $ dig  linuxmafia.com  @127.0.0.1  +short
> $ dig  linuxmafia.com  @10.0.0.175  +short
> 
> You've asked Unbound to resolve 'linuxmafia.com' (looking
> up the
> 'A'-type forward-lookup record by default), and told the
> 'dig' utility
> to pass that request to Unbound via first the loopback IP
> and then the
> network-connected one.  The '+short' flag is a 'Just
> the facts, ma'am' 
> request to return just the tersest possible response,
> omitting much of
> the detail.  You might want to also see what the full
> response looks
> like, without that flag.  
> 
> Among the details suppressed by the '+short' flag is any
> error-debugging
> information such as the reasons _why_ you are getting a
> null response,
> so it's good to get to know when '+short' is a bit too
> terse.  For
> example, dig might be encountering error condition
> 'SERVFAIL', which
> means it got a socket to a running DNS daemon, which
> reported that it's 
> sick and unable to do work at the moment. 
> 
> The 'dig' utility is really good for getting to the bottom
> of DNS
> problems, and also for just observing how it works. 
> (Try the +trace
> flag, some time.)  Many people are still being advised
> to use
> 'nslookup'; don't!  That's really bad advice, because
> nslookup is buggy
> and gives provably wrong DNS answers in some cases.
> 
> Anyhow, the answers you get to the above-cited queries
> determine where
> your problem is.  If neither one gives an answer, then
> either Unbound
> isn't running at all, or something (firewall rules, overly
> tight
> 'interface' and 'access-control'-line ACLs in unbound.conf)
> is
> preventing anything from querying Unbound at all.  Fix
> that.
> 
> If you're getting an answer on the 127.0.0.1 interface but
> not on the
> 10.0.0.175 one, again, probably overly tight ACLs or such.
> 
> If you're getting answer on _both_ interfaces, now you
> should login to 
> your local workstation, the one you're trying to convince
> to talk to the
> Unbound instance on 'plug', and re-submit the non-loopback
> query:
> 
> $ dig  linuxmafia.com  @10.0.0.175  +short
> 
> (Oh, and make sure you can ping 10.0.0.175, just as a
> sanity check.)
> 
> If you are unable to sucessfully query 10.0.0.175 via 'dig'
> from the 
> workstation, e.g., dig encounters a timeout, then I'll bet
> your ACL list in
> Unbound's unbound.conf needs rewriting to permit queries
> from your local
> network.
> 
> If the 'dig' query _does_ succeed, then your problem isn't
> DNS, and I
> don't know what happened, because you've just vetted
> everything all the
> way out, one step at a time.
> 
> Actually, there's one way I can think of, that that might
> happen:  Let's
> say you had a DNS-using utility like a Web browser already
> running when
> you configured your DHCP daemon to point clients towards
> 10.0.0.175 for
> nameservice.  (By the way, did you verify that the
> desired IP
> information actually _is_ propagating out from your DHCP
> daemon to the
> client machine's /etc/resolv.conf file?  If not,
> there's your problem.)
> User programs like Web browsers tend to have 'stub DNS
> resolvers' built
> into them, limited functionality DNS client software that's
> just a
> little dumb, and picks up data from your system DNS client
> configuration
> (/etc/resolv.conf, /etc/nsswitch.conf) at program launch
> time -- and
> never revises it thereafter.  So, your already-running
> Web browser would
> not have picked up resolv.conf changes from your DHCP
> daemon.
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/
> 