On Wed, 2011-09-21 at 11:23 -0400, Paul Wouters wrote:
On Wed, 21 Sep 2011, Tomas Mraz wrote:
solve a part of the problem how can you even consider removing the
ability for disabling dnssec when implementing and deploying and running
dnssec increases the complexity times hundred and
On Wed, 2011-09-21 at 12:37 +0200, Adam Tkac wrote:
On 09/20/2011 05:19 PM, Dan Williams wrote:
On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote:
Hi developers of NM and Fedora,
We are trying to get DNSSEC validation on the end nodes. One way of doing
that is to run a caching
On Thu, 22 Sep 2011, Dan Williams wrote:
But I'm not really familiar with unbound. Is it a long-running service?
Yes, It's a fully dnssec validating caching resolver. You start it at boot
and leave it running.
What does its config file look like? Does it re-read config data on
SIGHUP?
You
snip
If people are testing this it would be good if they could test the unit
files for this too on F15+ hosts.
Afaik I have already converted the whole xelerance.com stuff and it's
just laying there in bugzilla.
Create the relevant files in there relevant paths then run...
systemctl
On Thu, 2011-09-22 at 14:26 -0400, Paul Wouters wrote:
On Thu, 22 Sep 2011, Dan Williams wrote:
But I'm not really familiar with unbound. Is it a long-running service?
Yes, It's a fully dnssec validating caching resolver. You start it at boot
and leave it running.
What does its
On Thu, Sep 22, 2011 at 11:27:41AM -0500, Dan Williams wrote:
right. the big problem is not working around a broken network or a network
with an attacker. The problem is false positives due to the pletora of
hotspot mangling techniques out there. Ideally, NetworkManager would deal
with
On Thu, 22 Sep 2011, Dan Williams wrote:
You properly talk to it via unbound-control, which uses SSL certs between
it and the daemon. No need to re-write config files or send it weirdo
signals.
Ok, this part mystifies me. I assume it just has a TCP socket listening
that you talk to it on?
On Thu, 2011-09-22 at 22:29 +0200, Tomasz Torcz wrote:
On Thu, Sep 22, 2011 at 11:27:41AM -0500, Dan Williams wrote:
right. the big problem is not working around a broken network or a network
with an attacker. The problem is false positives due to the pletora of
hotspot mangling
On 09/17/2011 08:00 PM, Paul Wouters wrote:
Hi developers of NM and Fedora,
We are trying to get DNSSEC validation on the end nodes. One way of doing
that is to run a caching resolver on every host, but that strains the
DNS infrastructure because all DNS caches would be circumvented. Since
On 09/20/2011 05:19 PM, Dan Williams wrote:
On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote:
Hi developers of NM and Fedora,
We are trying to get DNSSEC validation on the end nodes. One way of doing
that is to run a caching resolver on every host, but that strains the
DNS
On Wed, 2011-09-21 at 12:45 +, Jóhann B. Guðmundsson wrote:
On 09/21/2011 10:21 AM, Adam Tkac wrote:
Another argument for enforcing DNSSEC is that in future (well, I believe
:) ) DNS will be used as storage for X.509 certs, SSHFP records and
other stuff. If we adopt leisure approach
On 09/21/2011 01:00 PM, Tomas Mraz wrote:
You probably did not understand the meaning of removing the ability for
disabling dnssec in the Adam's e-mail. It is not meant to disable the
ability to not use of dnssec completely but that it should not be
possible to simply click away any failures
On Wed, 21 Sep 2011, Adam Tkac wrote:
this is a great idea and work. We talked (inside Red Hat) about similar
approach how to secure the clients but this proposal is better, ready
for use, and I like it.
Great. Please test and give us feedback :)
The only one question for discussion is if
On Wed, 21 Sep 2011, Tomas Mraz wrote:
solve a part of the problem how can you even consider removing the
ability for disabling dnssec when implementing and deploying and running
dnssec increases the complexity times hundred and people and isp's alike
cant even implement and properly run a
Le samedi 17 septembre 2011 à 14:00 -0400, Paul Wouters a écrit :
Hi developers of NM and Fedora,
We are trying to get DNSSEC validation on the end nodes. One way of doing
that is to run a caching resolver on every host, but that strains the
DNS infrastructure because all DNS caches would be
On Sun, 18 Sep 2011, Nicolas Mailhot wrote:
We are trying to get DNSSEC validation on the end nodes. One way of doing
that is to run a caching resolver on every host, but that strains the
DNS infrastructure because all DNS caches would be circumvented.
However, there are many networks out
Hi Paul,
(off-list)
On Sat, Sep 17, 2011 at 02:00:04PM -0400, Paul Wouters wrote:
dnssec-trigger consists of NetworkManager hooks, a daemon that rewrites
resolv.conf and signals unbound, and a gnome applet to show the user the
DNSSEC status and to warn the user if the network is (too?)
Hi all,
Sorry for my previous message to this list.
It was intended as a personal message (in Dutch) to Paul, hence the
off-list remark at the top, but I made a stupid mistake...
Cheers,
--
--Jos Vos j...@xos.nl
--X/OS Experts in Open Systems BV | Phone: +31 20 6938364
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote:
You can find source and package pre-releases at:
ftp://ftp.xelerance.com/dnssec-trigger/
At least for Fedora 15:
BuildRequires: glib-devel, gtk2-devel, ldns-devel
and in %install
mkdir -p
19 matches
Mail list logo
