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 my
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 for
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 recon
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 po
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
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 n
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 incorr
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
]] 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
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
http://anonscm.debian.org/gitweb/?p=resolvconf/resolvconf.git;a=blob;f=man/resolvcon
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
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
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
http://wiki.debian.org/
]] 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
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
]] 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 informati
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.progra
]] 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,
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 pro
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 over
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, 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
]] 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.co
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
]] 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
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 ca
> 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 mo
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. T
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.
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 mea
]] 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 situati
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.
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
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 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 subst
Ian Jackson 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:
http://www.openbsd.o
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
> >
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 fo
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 re
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 no
41 matches
Mail list logo
