[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
when using dnsmasq, you may encounter situations where it fails to resolve private names in networks with non-equivalent nameservers. This can happen when the nameservers configured for your network do not have the necessary information to resolve the private names. To troubleshoot this issue, you can try the following steps: Verify DNS configuration: Double-check your network's DNS configuration settings. Ensure that the nameservers specified in the configuration have the ability to resolve private names. If needed, update the DNS configuration to include appropriate nameservers. Check firewall settings: If you have a firewall in place, ensure that it is not blocking the necessary DNS traffic. Adjust the firewall rules to allow DNS queries and responses to flow smoothly between your network and the nameservers. https://home-decoration-ideas.com/what-forms-do-i-need-to-become-a-licensed-garage-door-repair-in-highland-springs/ Configure dnsmasq options: Review the configuration options for dnsmasq. Ensure that it is properly configured to use the correct nameservers for resolving private names. Check for any specific settings related to resolving private names and adjust them if necessary. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Won't Fix Status in network-manager source package in Precise: Won't Fix Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Need for dell laptop repairing contact dell service center in thane because we have door step support for dell laptop users thane if you have problem with your laptop like motherboard issue ,screen issue ,battery issue or ram replacement we capable to resolve your issue at your place within same day .For more information please visit call our office dell service center thane . https://www.laptopsservice.center/dell-laptop-service-center-thane-mumbai.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Won't Fix Status in network-manager source package in Precise: Won't Fix Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
ake: Entering directory '/home/Christian/binutils-gdb/cygwin-obj/gdb' CXXLD gdb.exe http://www.compilatori.com/computers/smartphones/ cp-support.o: in function `gdb_demangle(char const*, int)': http://www.acpirateradio.co.uk/services/ios15/ /home/Christian/binutils-gdb/cygwin-obj/gdb/../../gdb/cp-support.c:1619:(.text+0x5502): http://www.logoarts.co.uk/property/lidar-sensor/ relocation truncated to fit: R_X86_64_PC32 against undefined symbol http://www.slipstone.co.uk/property/hp-of-cars/ `TLS init function for thread_local_segv_handler' http://www.mconstantine.co.uk/category/technology/ /home/Christian/binutils-gdb/cygwin-obj/gdb/../../gdb/cp-support.c:1619:(.text+0x551b): http://embermanchester.uk/property/chat-themes/ relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for thread_local_segv_handler' collect2: error: ld returned 1 exit status http://connstr.net/property/mars-researches/ make: *** [Makefile:1881: gdb.exe] Error 1 make: Leaving directory '/home/Christian/binutils-gdb/cygwin-obj/gdb' http://joerg.li/services/kia-rio-price/ $ g++ -v Using built-in specs. http://www.jopspeech.com/technology/thunderbolt-4/ COLLECT_GCC=g++ COLLECT_LTO_ http://www.go-mk-websites.co.uk/category/technology/ WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/10/lto-wrapper.exe Target: x86_64-pc-cygwin http://www.wearelondonmade.com/tech/driving-assistant/ Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0/configure -- http://fishingnewsletters.co.uk/category/technology/ srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0 --prefix=/usr --exec-prefix=/usr http://the-hunters.org/category/travel/ --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc -- https://waytowhatsnext.com/computers/discord-and-steam/ htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix -- http://www.iu-bloomington.com/property/properties-in-turkey/ libexecdir=/usr/lib --with-gcc-major-version-only --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 https://komiya-dental.com/sports/telegram/ --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath http://www-look-4.com/health/winter-sickness/ --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib https://www.webb-dev.co.uk/sports/gym-during-covid/ --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Won't Fix Status in network-manager source package in Precise: Won't Fix Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
The Precise Pangolin has reached end of life, so this bug will not be fixed for that release ** Changed in: network-manager (Ubuntu Precise) Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Won't Fix Status in network-manager source package in Precise: Won't Fix Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
The Precise Pangolin has reached end of life, so this bug will not be fixed for that release ** Changed in: dnsmasq (Ubuntu Precise) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Won't Fix Status in network-manager source package in Precise: Won't Fix Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: network-manager (Ubuntu Precise) Status: Invalid => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Incomplete Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: network-manager (Ubuntu) Status: Fix Released => Invalid ** Changed in: network-manager (Ubuntu Precise) Status: Fix Released => Invalid ** Changed in: dnsmasq (Ubuntu) Status: Fix Released => Triaged ** Changed in: dnsmasq (Ubuntu Precise) Status: Fix Released => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: network-manager (Ubuntu Precise) Status: Invalid => Fix Released ** Changed in: network-manager (Ubuntu) Status: Invalid => Fix Released ** Changed in: dnsmasq (Ubuntu Precise) Status: Triaged => Fix Released ** Changed in: dnsmasq (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in dnsmasq source package in Precise: Fix Released Status in network-manager source package in Precise: Fix Released Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: dnsmasq (Ubuntu) Status: Triaged => New ** Changed in: dnsmasq (Ubuntu Precise) Status: Triaged => New ** Changed in: network-manager (Ubuntu) Status: Invalid => New ** Changed in: network-manager (Ubuntu Precise) Status: Invalid => New ** Changed in: dnsmasq (Ubuntu) Assignee: nikhil (nikhilnikki) => (unassigned) ** Changed in: dnsmasq (Ubuntu Precise) Assignee: Mathieu Trudel-Lapierre (cyphermox) => (unassigned) ** Changed in: network-manager (Ubuntu Precise) Assignee: Mathieu Trudel-Lapierre (cyphermox) => (unassigned) ** Changed in: network-manager (Ubuntu) Assignee: Mathieu Trudel-Lapierre (cyphermox) => (unassigned) ** Summary changed: - dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers + SDFEEWRDSsdfdasfsdf ** Description changed: - A number of reports already filed against network-manager seem to - reflect this problem, but to make things very clear I am opening a new - report. Where appropriate I will mark other reports as duplicates of - this one. - - Consider a pre-Precise system with the following /etc/resolv.conf: - - nameserver 192.168.0.1 - nameserver 8.8.8.8 - - The first address is the address of a nameserver on the LAN that can - resolve both private and public domain names. The second address is the - address of a nameserver on the Internet that can resolve only public - names. - - This setup works fine because the GNU resolver always tries the first- - listed address first. - - Now the administrator upgrades to Precise and instead of writing the - above to resolv.conf, NetworkManager writes - - server=192.168.0.1 - server=8.8.8.8 - - to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to - resolv.conf. Resolution of private domain names is now broken because - dnsmasq treats the two upstream nameservers as equals and uses the - faster one, which could be 8.8.8.8. + dfasfwerwq2323sf ** Tags removed: precise xenial ** Information type changed from Public to Private -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: SDFEEWRDSsdfdasfsdf Status in dnsmasq package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in dnsmasq source package in Precise: New Status in network-manager source package in Precise: New Status in dnsmasq package in Debian: New Bug description: dfasfwerwq2323sf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Adding the needed domain to the /etc/NetworkManager/system-connections as an argument to : dns-search= see Works for me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Description changed: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: - nameserver 192.168.0.1 - nameserver 8.8.8.8 + nameserver 192.168.0.1 + nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes - server=192.168.0.1 - server=8.8.8.8 + server=192.168.0.1 + server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
This breaks domain name resolution in Ubuntu 16.04, as seen in bug #1522057. tags: added: precise xenial Changed in network-manager (Ubuntu): importance: Medium → Critical Changed in dnsmasq (Ubuntu Precise): importance: Medium → Critical Changed in dnsmasq (Ubuntu): importance: Medium → Critical Changed in network-manager (Ubuntu Precise): importance: Medium → Critical Changed in network-manager (Ubuntu): status: Confirmed → Invalid Changed in network-manager (Ubuntu Precise): status: Triaged → Invalid Changed in dnsmasq (Ubuntu): status: Confirmed → Triaged Changed in dnsmasq (Ubuntu Precise): status: Confirmed → Triaged ** Changed in: dnsmasq (Ubuntu) Assignee: sunil (chikkalli) => nikhil (nikhilnikki) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
another solution is to resolve 192.168.0.1 code it as server=/sample.com/192.168.0.1 which would send all dns lookups for sample.com to 192.168.0.1. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
The solution that can be proposed is that we can search in non sequential order. if the first server fails then it should continue until it gets matched to the other nameserver. Like, if the request needs to resolve private address then ,it first searches non sequentiall order and so it asks 8.8.8.8 nameserver initially. but in the first hit, it can resolve only public addresses. So now it contacts the other nameserver 192.168.0.1, at this time it can clearly resolve the public and private addresses. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: dnsmasq (Ubuntu) Assignee: Sachin Bawoor (bawoor) => sunil (chikkalli) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
The solution would be to search non-sequentially. If the first nameserver fails to answer, then it should ask other till it gets correct nameserver. For example if the request needs to resolve private address-it first searches non sequentially and asks 8.8.8.8 nameserver initially but it can resolve only public addresses. So now it asks other nameserver 192.168.0.1, it can resolve both public and private addresses. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: dnsmasq (Ubuntu) Assignee: Mathieu Trudel-Lapierre (cyphermox) => Sachin Bawoor (bawoor) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On Yakkety there is no file /etc/NetworkManager/dnsmasq.d/strict-order. Should a touch do the trick? If so why so? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Regarding #69: This does not work at all. In resolv.conf there is still nameserver 127.0.1.1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On Xenial I've set strict-order in /etc/NetworkManager/dnsmasq.d/strict- order. After a Restart of dnsmasq I have no failed DNS Queries to our internal Domain. For me this is fine, because the first (internal) Nameserver act as forwarder. If this fails the second Nameserver can be used to resolv Addresses from the Internet. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Adding the needed domain to the /etc/NetworkManager/system-connections as an argument to : dns-search=mycorporatedomain.com Works for me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
This breaks domain name resolution in Ubuntu 16.04, as seen in bug #1522057. ** Tags added: precise xenial ** Changed in: network-manager (Ubuntu) Importance: Medium => Critical ** Changed in: dnsmasq (Ubuntu Precise) Importance: Medium => Critical ** Changed in: dnsmasq (Ubuntu) Importance: Medium => Critical ** Changed in: network-manager (Ubuntu Precise) Importance: Medium => Critical ** Changed in: network-manager (Ubuntu) Status: Confirmed => Invalid ** Changed in: network-manager (Ubuntu Precise) Status: Triaged => Invalid ** Changed in: dnsmasq (Ubuntu) Status: Confirmed => Triaged ** Changed in: dnsmasq (Ubuntu Precise) Status: Confirmed => Triaged ** Changed in: dnsmasq (Ubuntu) Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox) ** Changed in: dnsmasq (Ubuntu Precise) Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Invalid Status in dnsmasq source package in Precise: Triaged Status in network-manager source package in Precise: Invalid Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Hope, my experience might help somebody affected with this issue. I've just put the needed domain into the "Additional search domains" line of the IPv4 settings of my VPN connection, and it did the trick. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Status in dnsmasq source package in Precise: Confirmed Status in network-manager source package in Precise: Triaged Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Christian, the workaround is to comment out the line "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Status in dnsmasq source package in Precise: Confirmed Status in network-manager source package in Precise: Triaged Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
I stumbled upon this Problem on 15.04. I cannot resolve company intranet hosts via VPN as my WLANs local DNS server is always faster and only knows about my local machines and internet. >From a users perspective I don't care about what might be the correct setup of the DNS-Servers (I cannot influence them) nor about personal opinions on how it should be done. I need my system to work. I'm very happy with Ubuntu, but this is a show stopper for me. I'll try to find a work around as I could not find one above (why not this is about 3 years old already). But if I cannot find one this will mean the end of ubuntu on my company notebook. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Status in dnsmasq source package in Precise: Confirmed Status in network-manager source package in Precise: Triaged Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: network-manager (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Status in dnsmasq source package in Precise: Confirmed Status in network-manager source package in Precise: Triaged Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
** Changed in: network-manager (Ubuntu) Status: In Progress => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in dnsmasq package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: New Status in dnsmasq source package in Precise: Confirmed Status in network-manager source package in Precise: Triaged Status in dnsmasq package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and "nameserver 127.0.0.1" to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
