a_kleider at yahoo.com
Sun May 16 13:37:23 PDT 2010
A bit more clarification please:
dns queries can be iterative ('polite') or recursive ('demand' a definitive answer vs just a referral.) Assuming the foregoing to be correct, what exactly is ment by a "recursive dns server?"
>From what I've read, the implication is that a 'recursive server' (e.g. unbound) is a name server that is willing to _accept_ recursive requests but itself uses _iteration_ (so in that sense is 'iterative') to get the answer to the recursive request.
Am I on the right track?
--- 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, 7:39 PM
> Quoting Alex Kleider (a_kleider at yahoo.com):
> > 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.
> You're very welcome.
> > Am I right in my assumption that what's in
> /etc/resolv.conf on the
> > plug (the machine running unbound) becomes
> Well, not really. It's a good question, and the
> matter actually bears
> thinking about.
> Brief review of context: Any TCP/IP machine is (or
> can be) a DNS
> client. Unix machines have client functionality
> tucked away inside part
> of the system libc (which is GNU glibc in Linux's
> case). The
> configuration files for that client functionality are -- on
> most Unix
> machines -- /etc/resolv.conf and /etc/nsswitch.conf .
> (Don't worry
> about the latter if it seems mysterious. Leave it
> Most people don't think about resolv.conf (let alone
> because they either set it once and forget, or leave its
> entirely up to DHCP. However, it's worth remembering
> that _each_
> machine has a client setup, which affects how _its own_
> TCP/IP stack
> works -- and not anything else. That client setup
> thus affects only
> programs running _on_ the machine in question.
> Applying that general truth to host 'plug': If you
> tweak the contents
> of /etc/resolv.conf on 'plug', you are determining where
> the DNS queries
> go that are generated by programs running _on_ plug that
> make reference
> to hosts elsewhere by hostname -- DNS-using network
> You might be surprised to learn that Unbound (like other
> is _not_ one of those DNS-using network applications.
> Unbound doesn't
> use DNS client services. Why? Because that
> would create a
> chicken-and-egg problem. So, e.g., unbound.conf's
> references to
> machines elsewhere is by IP address only.
> But presumably you have things other than Unbound running
> on 'plug', or
> you might want to, at least, and you want to be able to use
> DNS services
> there. So, you wonder, should you tell 'plug' to
> consult 'plug' only
> for its DNS?
> > 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 184.108.40.206
> > nameserver 220.127.116.11
> > ??????
> You could. The argument in favour is 'Hey, I like
> sonic.net, but my own
> recursive nameserver is the last word in really, really
> close, and I'd
> rather get local nameservice from, y'know, a really local
> The argument against is: 'If Unbound is hung or not
> running, then all
> nameservice on plug will be offline.'
> You could make a good argument either way. One
> fence-straddling option
> would be to put '#' marks in front of the two existing
> lines referencing
> sonic.net nameserver IPs. If Unbound is ever not
> running, you just
> uncomment one or both of those lines, and you instantly
> will get local
> DNS services back.
> 'Hope that helps.
> By the way, you can certainly get away with 'nameserver
> localhost' in
> /etc/resolv.conf, because the static hosts mapping file,
> includes a stable and reliable definition of what IP the
> name 'localhost'
> should always resolve to (unless you screw up that file,
> which can
> result in some really puzzling problems, let me tell
> you). _However_,
> the 'nameserver' lines in /etc/resolv.conf should really
> point only to
> numerical IP addresses. Therefore, 'nameserver
> localhost' is a slightly
> irregular way to say it, avoidably making local nameservice
> dependent on
> the /etc/hosts file. The correct way to say that is
> 'nameserver 127.0.0.1'.
> sf-lug mailing list
> sf-lug at linuxmafia.com
> Information about SF-LUG is at http://www.sf-lug.org/
More information about the sf-lug