On Friday and Saturday I sent messages to this list but they
appear to have been filtered out. I try again and CC:
Helmut Grohne this time so at least he will receive this
message and we can continue the discussion over e-mail.
My Friday message contained a C program and its output
when run on
On 03/07/13 14:30, Ian Jackson wrote:
Ian Jackson writes (Re: boot ordering and resolvconf):
4. Therefore in most installations there should be a local
proxy or cache. It should use DHCP-provided, PPP-provided or
similar, as a forwarder. The local DNS provider address
On Sun, Jun 30, 2013 at 12:03:47PM +0200, Thomas Hood wrote:
That resolvconf leaves resolv.conf empty of nameserver entries when
no nameservers are available is intentional. The idea is to advertise
only addresses where something is actually listening.
Even though intentional it might be a
Sorry for the noise,
I finally verified some more claims and discovered that my other recent
mail is wrong in multiple places. I guess this discussion really is
moot.
So what happens when you getaddrinfo ...
... a non-existent name? - EAI_SYSTEM ENOENT
... something when nothing is bound to
On Wed, Jul 03, 2013 at 10:24:42AM +0200, Tollef Fog Heen wrote:
What do you do when you are on a network that blocks DNS lookups that
don't go via the DNS servers for that network? Or for networks that do
that until you visit a web page and press a button on a form?
Manually reconfigure
Ian Jackson wrote:
I think the first thing to do is recognise the underlying problem. To
fix this problem properly we need a coherent system design. The two
designs lead to different sets of fixes.
A. resolv.conf is a static file which changes only very rarely.
B. resolv.conf is not
]] Bob Proulx
Tollef Fog Heen wrote:
]] Don Armstrong
Tollef Fog Heen wrote:
It seems resolvconf wants to get its name servers from
/etc/network/interfaces?
Resolvconf can get its nameservers from anywhere that calls
echo 'namserver information'|resolvconf -a
On Wed, Jul 3, 2013 at 2:36 PM, Tollef Fog Heen wrote:
No, in my setup it should not do that without admin intervention. Doing
that means it's likely to cause security-related problems. I use DNSSEC
and don't want to trust random resolvers, I want to trust the one that
I've set up myself
]] Paul Wise
On Wed, Jul 3, 2013 at 2:36 PM, Tollef Fog Heen wrote:
No, in my setup it should not do that without admin intervention. Doing
that means it's likely to cause security-related problems. I use DNSSEC
and don't want to trust random resolvers, I want to trust the one that
On Wed, Jul 3, 2013 at 4:24 PM, Tollef Fog Heen wrote:
Manually reconfigure unbound to use those DNS servers as forwarders.
...and then manually reconfigure it to do its own lookups when you go
to another network and find they aren't reachable from there?
--
bye,
pabs
Thomas Hood writes (Re: boot ordering and resolvconf):
Well, you are right that resolvconf was designed to support mode B,
and only supports mode A as a trivial case of mode B where a local
forwarding nameserver is always running.
But mode A involves /etc/resolf.conf not changing during
Ian Jackson writes (Re: boot ordering and resolvconf):
...
I think the first thing to do is recognise the underlying problem. To
fix this problem properly we need a coherent system design. The two
designs lead to different sets of fixes.
A. resolv.conf is a static file which changes only
To those who aren't yet familiar with resolvconf, I'd suggest reading
the resolvconf package README and the resolvconf(8) manpage.
http://anonscm.debian.org/gitweb/?p=resolvconf/resolvconf.git;a=blob;f=README
]] Ian Jackson
Ian Jackson writes (Re: boot ordering and resolvconf):
...
I think the first thing to do is recognise the underlying problem. To
fix this problem properly we need a coherent system design. The two
designs lead to different sets of fixes.
A. resolv.conf is a static
On Wed, 03 Jul 2013, Tollef Fog Heen wrote:
Does that mean it's an RC bug for any non-manual process to overwrite
[/etc/resolv.conf]? I'd be happy to file bugs.
I don't believe it's RC, but it's certainly a bug. [The fact that
dhclient does this when it's not called with appropriate arguments
On Wed, 03 Jul 2013, Ian Jackson wrote:
But mode A involves /etc/resolf.conf not changing during the boot
process. As I wrote in my original description:
A. resolv.conf is a static file which changes only very rarely.
So your statement that resolvconf supports mode A is simply incorrect.
Tollef Fog Heen wrote:
I think changing /etc/resolv.conf automatically is broken at all.
What's the malfunction?
We should have a generated /run/resolv.conf that's overridden by the
settings in /etc/resolv.conf (if it exists). This allows you to have a
consistent set of domains searched for
]] Thomas Hood
Tollef Fog Heen wrote:
I think changing /etc/resolv.conf automatically is broken at all.
What's the malfunction?
Automatic processes overwrite explicit admin setups.
We should have a generated /run/resolv.conf that's overridden by the
settings in /etc/resolv.conf (if
On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
Automatic processes overwrite explicit admin setups.
If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it by writing to
somewhere else. If it's not a symlink, then it shouldn't be
overridden.
Don Armstrong wrote:
On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
Automatic processes overwrite explicit admin setups.
If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it by writing to
somewhere else. If it's not a symlink, then it
On Tue, Jul 02, 2013 at 12:38:24PM -0700, Howard Chu wrote:
Don Armstrong wrote:
On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
Automatic processes overwrite explicit admin setups.
If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it
Steve Langasek wrote:
On Tue, Jul 02, 2013 at 12:38:24PM -0700, Howard Chu wrote:
Don Armstrong wrote:
On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
Automatic processes overwrite explicit admin setups.
If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic
]] Don Armstrong
On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
Automatic processes overwrite explicit admin setups.
If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it by writing to
somewhere else. If it's not a symlink, then it
Tollef Fog Heen wrote:
]] Don Armstrong
Tollef Fog Heen wrote:
It seems resolvconf wants to get its name servers from
/etc/network/interfaces?
Resolvconf can get its nameservers from anywhere that calls
echo 'namserver information'|resolvconf -a interface.program;
If I do
]] Helmut Grohne
* Treating an empty /etc/resolv.conf as a permanent error or failing
to discover changes in /etc/resolv.conf later on.
* Changing /etc/resolv.conf during startup of a local dns cache.
So if /etc/resolv.conf is declared to be static (A), then the second
practise is
In addition resolvconf does not properly support mode (A), due to the
local forwarding nameserver is running requirement. It can leave
/etc/resolv.conf empty until the name server is actually started.
Well, you are right that resolvconf was designed to support mode B,
and only supports mode A
Helmut Grohne wrote:
All that I am aiming for is to declare one of the following practises
as broken:
* Treating an empty /etc/resolv.conf as a permanent error or failing
to discover changes in /etc/resolv.conf later on.
* Changing /etc/resolv.conf during startup of a local dns cache.
On Fri, Jun 28, 2013 at 05:02:51PM +0200, Thomas Hood wrote:
Resolvconf supports both mode A and mode B and allows switching between them.
With resolvconf installed, (A) so long as a local forwarding nameserver is
running, resolv.conf points to this nameserver and thus rarely changes; but
Ian Jackson wrote:
The two designs lead to different sets of fixes.
A. resolv.conf is a static file which changes only very rarely.
Implications:
1. Existing DNS client applications do not need to change.
2. DNS service should always be provided at a fixed address
3.
On Wed, 12 Jun 2013, Wouter Verhelst wrote:
On 10-06-13 18:36, Ian Jackson wrote:
B. resolv.conf is not static and may change due to network
environment changes.
Implications:
1. All existing DNS applications must be modified to notice
changes to resolv.conf.
2.
Thanks for all the suggestions on how to implement either
On Mon, Jun 10, 2013 at 05:36:46PM +0100, Ian Jackson wrote:
A. resolv.conf is a static file which changes only very rarely.
Implications:
or
B. resolv.conf is not static and may change due to network
environment changes.
]] Helmut Grohne
Just how do we move from these suggestions to a coherent system design?
Fact is that some applications don't cope with /etc/resolv.conf changing
(i.e. A). Also fact is that in the presence of resolvconf,
/etc/resolv.conf can be a dynamic file (i.e. B). The current situation
On Wed, Jun 12, 2013 at 01:42:58PM +0200, Tollef Fog Heen wrote:
I'm not sure why you think systemd changes anything here?
One of the main purposes of systemd is to eliminate dependencies and
fulfil them with socket activation. When converting init scripts to
.service files, this will likely
Ian Jackson ijackson at chiark.greenend.org.uk writes:
B. resolv.conf is not static and may change due to network
environment changes.
Implications:
1. All existing DNS applications must be modified to notice
changes to resolv.conf.
OpenBSD implements that:
On Tue, Jun 11, 2013 at 09:39:40AM +0800, Chow Loong Jin wrote:
Shuffled the quotes:
The difficulty with plan A is probably B4. Do we have a suitable
minimal proxy we can install, a way to reconfigure it based on dhcp
etc., and a means to displace it when something more substantial
On Tue, Jun 11, 2013 at 10:38:52AM -0700, Steve Langasek wrote:
[...]
Not for what he's described. dig @$other_server would still work just fine,
you would merely have /etc/resolv.conf pointing at 127.0.0.1 and have the
*kernel* handle the DNS forwarding instead of using dnsmasq or another
On 10-06-13 18:36, Ian Jackson wrote:
B. resolv.conf is not static and may change due to network
environment changes.
Implications:
1. All existing DNS applications must be modified to notice
changes to resolv.conf.
2. Corollary: all existing DNS resolver libraries must
Helmut Grohne writes (boot ordering and resolvconf):
Why is this assumption problematic?
A number of DNS caches (dnsmasq, pdns-server, pdnsd, and unbound) employ
a technique to update /etc/resolv.conf with themselves. This updating
happens after the respective cache is started. Usually any
No need to CC me here, see Mail-Followup-To.
On Mon, Jun 10, 2013 at 05:36:46PM +0100, Ian Jackson wrote:
I think this is a somewhat different problem to the one you originally
state. The real problem here is that resolv.conf is changing and
programs don't have the means to cope.
Thanks for
On Mon, Jun 10, 2013 at 09:45:35PM +0200, Helmut Grohne wrote:
[...]
A. resolv.conf is a static file which changes only very rarely.
Implications:
1. Existing DNS client applications do not need to change.
2. DNS service should always be provided at a fixed address
3.
Currently awe number of services assume the following setting.
A service that retries DNS lookups, does not need to declare a boot
ordering relation on a name server.
I am currently aware of two examples of this assumption:
1) When using systemd, the DNS server is a socket service, so
41 matches
Mail list logo
