On Wed, Apr 30, 2014 at 03:55:59PM -0500, Dan Williams wrote:
> On Wed, 2014-04-30 at 16:12 -0400, Chuck Anderson wrote:
> > If I once connected to an open network called "MyFavoriteCoffeeShop"
> > then later on someone creates a network with the same name but with
> > malicous intent, will Network
On Wed, 2014-04-30 at 16:12 -0400, Chuck Anderson wrote:
> On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote:
> > On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams wrote:
> > > On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> > >> On Wed, 30 Apr 2014, Simo Sorce wrote:
> > >>
>
On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote:
> On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams wrote:
> > On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> >> On Wed, 30 Apr 2014, Simo Sorce wrote:
> >>
> >> > Why would you care for the domain name as provided by dhcp ?
On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams wrote:
> On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
>> On Wed, 30 Apr 2014, Simo Sorce wrote:
>>
>> > Why would you care for the domain name as provided by dhcp ?
>>
>> internal DNS views, eg server.internal.corp.com where the search domain
On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> On Wed, 30 Apr 2014, Simo Sorce wrote:
>
> > Why would you care for the domain name as provided by dhcp ?
>
> internal DNS views, eg server.internal.corp.com where the search domain
> gets set to "internal.corp.com" and "server.corp.com" do
On Wed, 30 Apr 2014, Simo Sorce wrote:
Why would you care for the domain name as provided by dhcp ?
internal DNS views, eg server.internal.corp.com where the search domain
gets set to "internal.corp.com" and "server.corp.com" does not exist.
By default you wouldn't want that as you roam with
On Wed, 2014-04-30 at 12:16 -0430, Robert Marcano wrote:
> On 04/30/2014 01:17 AM, P J P wrote:
> >> On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote:
> >> On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9.
> >> This local server also is my DHCP and Samba server. As usual
On Wed, 30 Apr 2014, Dan Williams wrote:
Untrusted networks use WPA too, like coffee shops that don't leave the
network open, but write the WPA key on the chalkboard menu or print it
on standup cards at the tables. I've seen quite a few of these.
You are at least consciously logging into that
Am 30.04.2014 20:38, schrieb Dan Williams:
> There's really no guessing what's trusted/not-trusted unless you're
> using 802.1x/WPA Enterprise, or if the user has told you explicitly to
> trust this network
thank you!
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
On Wed, 2014-04-30 at 13:22 -0400, Paul Wouters wrote:
> On Wed, 30 Apr 2014, Robert Marcano wrote:
>
> > What about domain and search lines? If NetworkManager will always use
> > 127.0.0.1, it should still modify resolv.conf with the domain name received
> > from DHCP
>
> That's actually not a
On Wed, 30 Apr 2014, Robert Marcano wrote:
What about domain and search lines? If NetworkManager will always use
127.0.0.1, it should still modify resolv.conf with the domain name received
from DHCP
That's actually not always correct from a security point of view.
If you set your system do h
On 04/30/2014 01:17 AM, P J P wrote:
On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote:
On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9.
This local server also is my DHCP and Samba server. As usual, dynamic
clients receive the LAN local domain ID and DNS serve
On 30.4.2014 15:29, Simo Sorce wrote:
On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide C
On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
> On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
> > On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
> > > On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> > > > = Proposed System Wide Change: Default Local DN
On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
> On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
> > On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> > > = Proposed System Wide Change: Default Local DNS Resolver =
> > > https://fedoraproject.org/wiki/Changes/Default_L
> On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote:
> On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9.
> This local server also is my DHCP and Samba server. As usual, dynamic
> clients receive the LAN local domain ID and DNS server ID
> automatically.
>
> How
On Tuesday 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> Change owner(s): P J P , Pavel Šimerda
> , Tomas Hozza
>
> To install a local DNS resolver trust
On Tue, Apr 29, 2014 at 12:41 PM, Matthew Miller
wrote:
> On Tue, Apr 29, 2014 at 09:29:00AM -0700, Andrew Lutomirski wrote:
>> OTOH, it would be straightforward to write a tiny stub that forwards
>> 127.0.0.1:53 to something outside the container.
>
> Is this tiny stub a process running inside th
- Original Message -
> = Proposed System Wide Change: Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> Change owner(s): P J P , Pavel Šimerda
> , Tomas Hozza
Ops, I was just pinged by Pavlix that the team planned this Change for F22
On Tue, Apr 29, 2014 at 09:29:00AM -0700, Andrew Lutomirski wrote:
> OTOH, it would be straightforward to write a tiny stub that forwards
> 127.0.0.1:53 to something outside the container.
Is this tiny stub a process running inside the container? What starts that
process? What about in the "single
On Tue, Apr 29, 2014 at 12:17 PM, P J P wrote:
> Hi,
>
>> On Tuesday, 29 April 2014 10:08 PM, Andrew Lutomirski wrote:
but the container itself runs in a network namespace, so it gets its own
loopback device. This will mean 127.0.0.1:53 points to the container
itself,
not t
Hi,
> On Tuesday, 29 April 2014 10:08 PM, Andrew Lutomirski wrote:
>>> but the container itself runs in a network namespace, so it gets its own
>>> loopback device. This will mean 127.0.0.1:53 points to the container itself,
>>> not the host, so dns resolving in the container will not work.
> On Tuesday, 29 April 2014 9:29 PM, Paul Wouters wrote:
> Note that FreeBSD also picked unbound recently for the exact same task.
True! ->
http://www.freebsdnews.net/2013/09/20/freebsd-10s-new-technologies-and-features/
---
Regards
-Prasad
http://feedmug.com
--
devel mailing list
devel@li
Hi,
> On Tuesday, 29 April 2014 8:59 PM, Dan Williams wrote:
> If NetworkManager is being used, users already don't touch resolv.conf,
> they edit /etc/sysconfig/network-scripts/ifcfg-* files and use
> DNS1/DNS2/DNS3 and SEARCHES to set DNS information.
Yes, true!
> If NetworkManager is n
On Tue, Apr 29, 2014 at 8:18 AM, Chuck Anderson wrote:
> On Tue, Apr 29, 2014 at 05:15:57PM +0200, Alexander Larsson wrote:
>> On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
>> > = Proposed System Wide Change: Default Local DNS Resolver =
>> > https://fedoraproject.org/wiki/Changes/Def
On Tue, 2014-04-29 at 17:39 +0200, Petr Spacek wrote:
> On 29.4.2014 17:27, Colin Walters wrote:
> > [ Dropping devel-announce ]
> >
> > On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson
> > wrote:
> >>
> >> Not sure how to fix something like that though...
> >
> > I think in both cases (host a
On Tue, 29 Apr 2014, P J P wrote:
Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the
new system?
We tell users to never edit the '/etc/resolv.conf' file and ensure that the
local resolver is listening at 127.0.0.1:53.
We should leave a comment in resolv.conf
On 29.4.2014 17:27, Colin Walters wrote:
[ Dropping devel-announce ]
On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson wrote:
Not sure how to fix something like that though...
I think in both cases (host and container) it would be best if the local
resolver offered a local-only API (e.g.
2014-04-29 17:15 GMT+02:00 Alexander Larsson :
> On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> > = Proposed System Wide Change: Default Local DNS Resolver =
> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> > To install a local DNS resolver trusted for the DN
[ Dropping devel-announce ]
On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson
wrote:
Not sure how to fix something like that though...
I think in both cases (host and container) it would be best if the
local resolver offered a local-only API (e.g. unix domain sockets,
kdbus). Would req
On Tue, 2014-04-29 at 22:10 +0800, P J P wrote:
>Hello,
>
> On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote:
> >So what exactly happens on upgrade? Before the upgrade,
> >most resolv.conf files will not point to 127.0.0.1.
> >What will they point to after the upgrade, and if they will
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
> On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> > = Proposed System Wide Change: Default Local DNS Resolver =
> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> >
> > Change owner(s): P J P , Pavel Šim
On Tue, Apr 29, 2014 at 05:15:57PM +0200, Alexander Larsson wrote:
> On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> > = Proposed System Wide Change: Default Local DNS Resolver =
> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> >
> > Change owner(s): P J P , Pa
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
>
> Change owner(s): P J P , Pavel Šimerda
> , Tomas Hozza
>
> To install a local DNS resolver trusted
> On Tuesday, 29 April 2014 7:56 PM, Matthew Miller wrote:
> Can the proposal owners clarify for me how this is intended to impact the
> cloud products?
Cloud products is somewhat of a hazy area(at-least for me). It's unclear how
things operate there. Any information about how we could/should a
> To install a local DNS resolver trusted for the DNSSEC validation running
> on 127.0.0.1:53. This must be the only name server entry in
> /etc/resolv.conf.
Can the proposal owners clarify for me how this is intended to impact the
cloud products? There's general resistance to having more servic
Hello,
On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote:
>So what exactly happens on upgrade? Before the upgrade,
>most resolv.conf files will not point to 127.0.0.1.
>What will they point to after the upgrade, and if they will point to 127.0.0.1,
>which package will actually do that, a
Hello,
2014-04-29 14:15 GMT+02:00 Jaroslav Reznik :
> = Proposed System Wide Change: Default Local DNS Resolver =
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> == Upgrade/compatibility impact ==
>
So what *exactly* happens on upgrade? Before the upgrade, most resolv.c
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P , Pavel Šimerda
, Tomas Hozza
To install a local DNS resolver trusted for the DNSSEC validation running on
127.0.0.1:53. This must be the o
39 matches
Mail list logo
