In addition to devising an algorithm for dnsmasq to detect all and only
NNNs, the implementation of which will no doubt take a while, we should
consider implementing a quick fix too, along the lines suggested by
Sergio in #19. NM could be changed to do the following.
If the nameserver address
I have marked this issue as affecting dnsmasq since we may want to
implement a solution there along the lines of #28 or similar.
I have marked this issue as affecting resolvconf since we may want to
implement a fix there along the lines of #29 or similar. (In the
absence of NM and in the
On 31/05/12 08:47, Thomas Hood wrote:
In addition to devising an algorithm for dnsmasq to detect all and only
NNNs, the implementation of which will no doubt take a while, we should
consider implementing a quick fix too, along the lines suggested by
Sergio in #19. NM could be changed to do
Simon, your suggestion (call it #18) differs from the suggestion in #17 in
two ways. First, #18 sends the first-received reply back
to the client without waiting for the results of comparison with other
results whereas #17 does wait. Second, #18 switches to
strict-order mode when *any*
Background: Using dnsmasq can give rise to resolution failures on VPNs
and other nonequivalent-nameserver networks (NNNs) where early-listed
nameservers have more information than later-listed ones. As Sergio
(comment #15) and others point out, the failures are grave: dnsmasq
might fail to resolve
pdf: It sounds to me as if you are using the wrong GNU/Linux
distribution. You demand a perfect one, whereas Ubuntu is not perfect.
Perhaps you should switch to one of the perfect distributions?
If search domains are not working for your colleagues then please ask
them to look in
We appear to have another case of this, reported in #922677. For
convenience I copy the contributor's posts here.
- Louis Li in #922677 #14 --
I'm seeing this issue from a clean Ubuntu precise amd64 AMI
(http://cloud.ubuntu.com/ami/).
With nothing
Oops, please ignore comment #25 which was intended for #1000244. If
someone has the power, please delete #25 and this comment.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
Simon in #18:
Once we see different data from different nameservers,
we can go to --strict-order mode, but the opposite is not
true: the same answer for a particular query doesn't
guarantee that the answers to future queries will always agree.
There's no way to be sure that the nameservers
Pdf in #7:
Well, commenting the line is not too bad, except that
other resolvconf bugs mean that doing so actually
results in no name resolution at all
Pdf in #11:
I mentioned that resolv.conf was missing in #1000244,
and since it wasn't being populated correctly, so if it's
not being
On 29/05/12 07:06, Thomas Hood wrote:
We aren't getting duplicates of #1000244 so it's probably not a
frequently occurring problem. If resolvconf were systematically
failing to create the resolv.conf symlink we'd be getting hundreds of
reports about it. Based on what we know now it's most
Simon Kelley might have written dnsmaskq with the assumption that all
DNS servers upstream have the same view about the namespace. However,
this is not how RFC sees it nor how it is set up in a majority of
installations.
Can you provide an authoritative reference for that?
As far as I can see,
On 27/05/12 17:58, Simon Kelley wrote:
Executive summary: non-equivalent servers are bad, but --strict-order
will make things work, for the same value of work as the libc
resolver). Non-equivalent servers are bad, so don't encourage their
use by making --strict-order the default.
To be
To be frank, when changing the default system resolver, expected
behavior should be the default. It's all well and good saying that
non-equivalent resolvers are 'bad' - and in the case of dnsmasq, that
might be true - but that's a value judgement that shouldn't have a place
in this scenario,
To Thomas in #9
Yet, it is sufficient to retry the operation to have a good chance of
success.
How does an application know that it should retry? It has received an
authoritative answer on the first try that the name does not exist.
Most things that are critical to operation get retried even
To simon, in #14.
Question: does networkmanager's GUI expose the option to divert particular
domains to a special nameserver? That's an
alternative correct way to achieve layering local names over the global DNS.
IMHO, this cannot be use to solve all the current problems. The issue
came out
When a decision was made to introduce dnsmasq I doubt that anyone fully
realized that this would impair name resolution on systems connected to
networks with nonequivalent nameservers (bad networks). Dnsmasq was
introduced and works well most of the time. For those for whom it does
not work well
Thomas in #17
A heuristic for this is difficult, because you have to prove a negative.
If we can assume the first nameserver has local addresses, we can never
return a reply from any other nameserver until we have the reply from
the first one, in case the first one has different data. Once we see
My idea for a heuristic was indeed extremely simple. In case the first
name server has a non public ip address, auto switch to strict order.
Il giorno 27/mag/2012, alle ore 23:04, Simon Kelley
si...@thekelleys.org.uk ha scritto:
Thomas in #17
A heuristic for this is difficult, because you
On 28/05/12 08:05, Sergio Callegari wrote:
My idea for a heuristic was indeed extremely simple. In case the first
name server has a non public ip address, auto switch to strict order.
That may work in many scenarios, but not if the address happens to be
routable, and only until IPv6 is
Simon Kelley might have written dnsmaskq with the assumption that all
DNS servers upstream have the same view about the namespace. However,
this is not how RFC sees it nor how it is set up in a majority of
installations.
Consider a small installation where the main server also serves DHCP
address
Sergio in #6:
Yet, it is sufficient to retry the operation to have a good chance of success.
How does an application know that it should retry? It has received an
authoritative answer on the first try that the name does not exist.
An alternative would be not to search sequentially, but to
Pdffs in #7:
Well, commenting the line is not too bad, except that other resolvconf bugs
mean that doing so actually results in no name resolution at all
I haven't seen any such bug reported against resolvconf. What are you
talking about?
--
You received this bug notification because you
@jdthood - I mentioned that resolv.conf was missing in #1000244, and
since it wasn't being populated correctly, so if it's not being
populated, and you disable dnsmasq, that would result in no
resolution...
--
You received this bug notification because you are a member of Desktop
Packages, which
** Summary changed:
- Upgrading to Precise NM with dns=dnsmasq breaks systems with non-equivalent
upstream nameservers
+ Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream
nameservers
--
You received this bug notification because you are a member of Desktop
Packages,
In the past it has been noticed that dnsmasq does not try the nameservers one
after the other as some resolver libraries do (including the GNU libc
resolver(3)). People have asked if dnsmasq can be enhanced to exhibit the
one-after-the-other behavior. But dnsmasq's author, Simon Kelley,
1) Searching servers in order is IMHO not as problematic as the author
of dnsmasq suggests. If an udp packet gets lost, a name does not get
resolved, because you may switch to the following nameserver. Yet, it is
sufficient to retry the operation to have a good chance of success.
Which is exactly
@callegar - that's all well and good, and I agree, but this is unlikely
to get solved in dnsmasq (though that would be ideal).
@jdthood:
1. Would have been the sane option for an LTS release (and server installs
should use traditional resolv.conf model, if that's not the case)
2. Well,
28 matches
Mail list logo
