:: Re: [DNG] dns vs connection manager
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Rick Moen
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] dns vs connection manager
Quoting Steve Litt (slitt@???):

> Yes, and I think that's outdated.


You can configure your DHCP client software to _not_ use nameserver IPs
sent by the DHCPd and instead use locally defined ones. If using
ISC's dhclient, set

supersede domain-name-servers ip-address [, ip-address... ];
or
prepend domain-name-servers ip-address [, ip-address... ];

in dhclient.conf in the section for the interface concerned.
('supersede' means ignore what the DHCPd sends for resolv.conf namserver
IPs entirely. 'prepend' means accept them, but put the indicated IPs
as a line above any received from the DHCPd, so as to be used in
preference if available.)

Or, a different way, create a 'hook' file to signal that updates to
/etc/resolv.conf should be ignored: Create 'hook' shell script
/etc/dhcp/dhclient-enter-hooks.d/nodnsupdate to contain

#!/bin/sh
make_resolv_conf(){
    :
}


Then, make executable by doing
# chmod +x /etc/dhcp/dhclient-enter-hooks.d/nodnsupdate

The above replaces dhclient's make_resolv_conf() function with a NO-OP
function.

A different conffile incantation would be required if you were using
dhcpcd, and yet a third for the 'pump' DHCP client. So, consult
docs for your choice of DHCP client software.


> Today, you can do one of these two
> things to guarantee you'll never need to change resolv.conf again:
>
> 1) Set resolv.conf to use two public DNS servers
>
> 2) Put a recursive resolver right on your computer. I use unbound.


Or #3, use resolvconf to manage the contents of the file.
http://linuxmafia.com/faq/Network_Other/resolvconf.html

> #2 has the advantage that you can put an authoritative server on there
> also, and then when you're at home or whatever you have DNS on your LAN
> too.


Hmm, either I'm misreading this suggestion or you are forgetting that
only one daemon process may bind to port 53 (DNS) on a single IP
address. E.g., if Unbound is running on your IP, it'll grab port 53.
If you then subsequently try to launch an authoritative nameserver such
as NSD on the same IP, it'll try to bind to 53, fail, and terminate.

There are workarounds if you're _determined_ to run both recursive and
authoritative servers sharing an IP, such as having dnsproxy bind to 53
on a public-facing IP address, and have it forward queries as
appropriate to either the recursive or authoritative server running each
on its own high-numbered port on 127.0.0.1 (localhost).

Or you could have the authoritative server bound to 53 on the
public-facing IP address, and the recursive server bound to 53 on
127.0.0.1 (localhost) -- at the cost (obviously) of restricting the
recursive server to local queries only.

In a LAN setup, it's best practices to run recursive service on a
well-protected inside machine, thus separating it from authoritative
nameservice. (Recursive servers are at risk of cache poisoning; you
want to try to control who and what sends them queries.)


(Most Dng users would have simple use-cases for which they'd have no
reason to run an authoritative nameserver, though. If you're not
publishing your own or a friend's domain's DNS to the public from a
fixed IP address, ignore anything about providing authoritative
nameservice, as you'll not be doing it.)