On 07/06/2012 10:54 AM, Jesse Keating wrote:
If dnsmasq is already running, NM will probably not mess with it. Try
disabling it from start at boot and allow NM to manage the process.
If dnsmasq is running and listening on 127.0.0.1, the dnsmasq instance
started by NetworkManager will fail to
Dan Williams wrote:
On Wed, 2012-06-20 at 16:24 -0400, Paul Wouters wrote:
On Wed, 20 Jun 2012, Simo Sorce wrote:
There are at least 2 situations where it is needed, and they are common
or will be common enough.
The 2 use cases for which a properly configurable and dynamically
Jesse Keating wrote:
On 06/20/2012 09:57 AM, Adam Williamson wrote:
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote:
Simo Sorce (s...@redhat.com) said:
Of course for this to work properly we need some level of integration
between Network Manager and the DNS caching server so that
Neal Becker wrote:
Jesse Keating wrote:
On 06/20/2012 09:57 AM, Adam Williamson wrote:
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote:
Simo Sorce (s...@redhat.com) said:
Of course for this to work properly we need some level of integration
between Network Manager and the DNS
On 06/20/2012 12:06 PM, Jesse Keating wrote:
So I just gave this a try. Already had dnsmasq installed so I just
edited the config file and restarted the NetworkManager service. Then
connected to my VPN.
It. Just. Works. Amazing! Not only does it just work for resolution,
but it also
On Fri, 2012-06-22 at 09:46 +0200, Nicolas Mailhot wrote:
Le Jeu 21 juin 2012 01:09, Dan Williams a écrit :
I spent some time looking at this today. NM already has plugins for
dnsmasq and a long-since-dead one for bind. We can certainly add a
plugin for dnssec-trigger or even unbound
On Wed, 2012-06-20 at 19:45 -0400, Paul Wouters wrote:
On Wed, 20 Jun 2012, Dan Williams wrote:
I spent some time looking at this today. NM already has plugins for
dnsmasq and a long-since-dead one for bind. We can certainly add a
plugin for dnssec-trigger or even unbound itself as
Le Mer 20 juin 2012 17:47, Simo Sorce a écrit :
The 2 use cases for which a properly configurable and dynamically
changeable caching DNA name server would be really useful are:
- DNSSEC verification
- Clients using VPNs into private networks.
3. ISP has junk DNS services and bypassing them
Le Jeu 21 juin 2012 01:09, Dan Williams a écrit :
I spent some time looking at this today. NM already has plugins for
dnsmasq and a long-since-dead one for bind. We can certainly add a
plugin for dnssec-trigger or even unbound
Which is a mess. How many DNS services do we need on a single
On 06/20/2012 07:09 PM, Dan Williams wrote:
(also, an aside: why the heck do resolvconf and dnssec-trigger require
an interface name??? DNS information has nothing do with network
interfaces, despite some DNS info coming from interface-specific sources
like DHCP...)
resolvconf requires an
On Wed, 2012-06-20 at 16:42 -0400, Paul Wouters wrote:
Install dnssec-trigger, start the dnssec-trigger panel application and
please give me feedback! Especially when you experience dns failures at
hotspots. There are so many different kinds of broken dns out there, I'm
sure we need to do more
On Thu, 2012-06-21 at 09:32 -0400, Dan Winship wrote:
On 06/20/2012 07:09 PM, Dan Williams wrote:
(also, an aside: why the heck do resolvconf and dnssec-trigger require
an interface name??? DNS information has nothing do with network
interfaces, despite some DNS info coming from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/21/2012 10:44 AM, Stephen Gallagher wrote:
On Wed, 2012-06-20 at 16:42 -0400, Paul Wouters wrote:
Install dnssec-trigger, start the dnssec-trigger panel
application and please give me feedback! Especially when you
experience dns failures
Ok, I guess this topic has been brought up before, but I think some
things changed recently that would warrant seriously considering adding
a default caching name server in fedora installs.
There are at least 2 situations where it is needed, and they are common
or will be common enough.
The 2
On Wed, 20 Jun 2012 11:47:17 -0400
Simo Sorce s...@redhat.com wrote:
Ok, I guess this topic has been brought up before, but I think some
things changed recently that would warrant seriously considering
adding a default caching name server in fedora installs.
...snip...
Discuss.
You can
On Wed, 2012-06-20 at 10:01 -0600, Kevin Fenzi wrote:
On Wed, 20 Jun 2012 11:47:17 -0400
Simo Sorce s...@redhat.com wrote:
Ok, I guess this topic has been brought up before, but I think some
things changed recently that would warrant seriously considering
adding a default caching name
On Wed, 20 Jun 2012 12:05:57 -0400
Simo Sorce s...@redhat.com wrote:
Yes this is all good 'n' nice.
The point is, can we/should we/want we make this the default ?
(And work on integrating NM - unbound automatic configuration ?)
I'd be in favor of that. ;)
I don't want to speak for the
Simo Sorce (s...@redhat.com) said:
Of course for this to work properly we need some level of integration
between Network Manager and the DNS caching server so that the dynamic
configurations can be pushed in/out when the related networks come
up/down.
Discuss.
man NetworkManager.conf:
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote:
Simo Sorce (s...@redhat.com) said:
Of course for this to work properly we need some level of integration
between Network Manager and the DNS caching server so that the dynamic
configurations can be pushed in/out when the related
On 06/20/2012 09:57 AM, Adam Williamson wrote:
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote:
Simo Sorce (s...@redhat.com) said:
Of course for this to work properly we need some level of integration
between Network Manager and the DNS caching server so that the dynamic
Simo,
For the VPN scenario I've been happily using dnrd for some time.
I use it to steer DNS requests for mycompany.com to the
company's DNS servers, and all other DNS requests to the
external servers.
Unlike just adding the company DNS servers to /etc/resolv.conf,
this never uses the
On Wed, 20 Jun 2012, Simo Sorce wrote:
There are at least 2 situations where it is needed, and they are common
or will be common enough.
The 2 use cases for which a properly configurable and dynamically
changeable caching DNA name server would be really useful are:
- DNSSEC verification
-
On Wed, 20 Jun 2012, Kevin Fenzi wrote:
Connect your vpn, etc.
Then tell unbound what you want it to do:
unbound-control forward_add redhat.com x.x.x.x y.y.y.y
unbound-control forward_add yourdomain z.z.z.z
(unbound-control gives you a lot of control, you can flush cache, setup
forward, see
People have might missed it before, but Fedora does a lot now with
handling the various DNS manglings it can encounter in the wild.
If you install dnssec-trigger from rawhide, then your DNS will be
automatically configured using DNSSEC and with as much security as
possible, while detecting
On Wed, 2012-06-20 at 10:19 -0600, Kevin Fenzi wrote:
On Wed, 20 Jun 2012 12:05:57 -0400
Simo Sorce s...@redhat.com wrote:
Yes this is all good 'n' nice.
The point is, can we/should we/want we make this the default ?
(And work on integrating NM - unbound automatic configuration ?)
On Wed, 2012-06-20 at 16:24 -0400, Paul Wouters wrote:
On Wed, 20 Jun 2012, Simo Sorce wrote:
There are at least 2 situations where it is needed, and they are common
or will be common enough.
The 2 use cases for which a properly configurable and dynamically
changeable caching DNA name
On Wed, 20 Jun 2012, Dan Williams wrote:
I spent some time looking at this today. NM already has plugins for
dnsmasq and a long-since-dead one for bind. We can certainly add a
plugin for dnssec-trigger or even unbound itself as well. The mechanism
by which dnssec-trigger currently interfaces
27 matches
Mail list logo
