Re: [Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
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 the following. > > "If the nameserver address list to be fed to dnsmasq contains one or > more local addresses followed by one or more non-local addresses then > run dnsmasq with the --strict-order option." > > I must confess that I am not sure what exactly should fall under "local > addresses" here. In IPv4 I presume that these would be the familiar > ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, but what about IPv6? I think you're right for IPv4. For IPv6, I'm tempted to treat it as a tabula rasa and explicitly not support NNNs. the rationale being that NNN support is to work around historical bad practice and such bad practice is not supported in the brave new world of IPv6. If that won't fly, then the IPv6 equivalent would be link-local (fe80::/64), site-local (fec0::/10) and ULAs (block fc00::/7), I think. > Nevertheless, I think we can safely proceed with this fix without being > sure that we have exactly the right definition of local address since > dnsmasq works no worse than libc in strict-order mode. > > ** Also affects: dnsmasq (Ubuntu) >Importance: Undecided >Status: New > > ** Also affects: resolvconf (Ubuntu) >Importance: Undecided >Status: New > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
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 probable that > #1000244 was a result of some sort of administrator error. The version > of resolvconf that was included in Precise wasn't perfect but the bugs > were fairly minor and the known ones have since been fixed. I'm certain that it was not an 'administration error' - I discovered that my networking was broken within an hour of clean install. Others at my office have complained of search domains not working, which smells of resolvconf being broken (my understanding is that resolvconf is responsible for populating search domains in this new resolution chain). I also don't know how you can release a system resolver implementation that "wasn't perfect", or even close to it (when the existing one wasn't broken and the new implementation adds serious complexity for questionable gain), particularly in an LTS release, but suggesting that 'the users broke it' isn't going to fix things. In any case, I'm still subscribed to the other bug, so happy for any continued discussion of that particular issue to happen there. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
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 prevalent. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
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 ha scritto: > 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 > 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 are equivalent > based on the history of returned queries. Unless we can assume that, we > always need to wait for the first nameserver to reply (or a timeout) and > have to stay in --strict-order mode forever. > > There is one possibility, which is to assume that nameservers are > equivalent, but switch to --strict-order mode if conflicting replies are > seen. When a query is forwarded to all available servers, and the first > reply sent back to the original requestor, keep the record of the reply > (at least, a bit indicating NODATA/NXDOMAIN or a valid reply. If another > reply comes in later from another nameserver which conflicts, then > switch to --strict-order mode. This will not get the first queries > right, but it will be triggered eventually (and it might be triggered, > swicthing mode forever, by random server glitches) > > For a single-host cache, --strict-order might be the simplest fix.. > > Simon. > > -- > You received this bug notification because you are subscribed to a > duplicate bug report (993794). > https://bugs.launchpad.net/bugs/1003842 > > Title: > Precise NM with "dns=dnsmasq" breaks systems with non-equivalent > upstream nameservers > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
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 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, since users haven't made the choice to enable dnsmasq, and so shouldn't have to be aware of the caveats (ie - "My DNS worked fine before upgrade"). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
