DNSSEC in Fedora-11: Enable or Disable?
by Paul Wouters
Hi people,
Adam Tkac and I maintain the two recursive nameservers in Fedora. We need
to decide before the beta freeze whether we want recursing caching
nameservers to enable or disable DNSSEC per default.
For some details on how this is implemented, please see:
http://fedoraproject.org/wiki/Features/DNSSEC
There are two questions:
For Fedora-11:
1) Should we enable DNSSEC when a recursing nameserver is installed?
2) If we do, should we enable DLV support?
(The only real DLV being http://dlv.isc.org/)
DNSSEC software has been run for a long time. It is mature, stable and
runs in production on many systems, including Fedora. What's been slow
has been the signing of the root and TLD deployments. This however,
is quickly gaining speed. A few days ago .gov was signed into production.
With the root not signed, key management is the hardest part of DNSSEC,
but we now have the required packages in Fedora to distribute and update
these.
Pro's:
- It adds much needed security to DNS
- Newly installed resolvers would use DNSSEC out of the box with all
known DNSSEC keys preconfigured. These closely resemble the current
ICANN/IANA Trust Anchor Repository at https://itar.iana.org/
- TLD Key management is taken care of (via autotrust and dnssec-conf)
- DLV will allow every DNS administrator to start taking advantage of
DNSSEC - even within unsigned TLD's such as .com and .org.
- Everyone can start using SSHFP records with their ssh client.
- Fedora contains all the tools to create and serve signed zones already.
(bind, bind-utils, ldns)
- Fedora contains two DNSSEC capable resolvers (bind and unbound) and
libraries to add DNSSEC to applications (bind or unbound-libs)
- Trivial to enable/disable dnssec-configure (and soon system-config-dnssec)
- Bind and Unbound are both very stable DNSSEC capable resolvers.
- Fedora shows it is a front runner when it comes to deploying new
technology :)
- It will make many TLD's, DNSSEC people, and the .gov people very happy.
Cons:
- It's perhaps technically too late for feature freeze. Though we are not
talking about putting new code in, just flipping a switch. So we could
do this in time for beta freeze.
- Support for using DNSSEC forwarders for endusers via NetworkManager is
not yet done (though support for on-the-fly reconfiguring forwarders
was added to unbound in preparation for this already). So using DNSSEC
via a resolv.conf using localhost for desktops/laptop clients is not
ready yet.
- DNSSEC requires EDNS0 and stupid firewall administrators might be blocking
TCP port 53 and UDP packets > 512 bytes, possibly causing DNS problems if
these are located in front of DNSSEC capable resolvers.
- Some NAT router brands drop DNS packets with DNSSEC options enabled. If
using a cheap NAT router as forwarder for your DNSSEC enabled Fedora
machine, DNS connectivity might cause intermittent problems.
Both Adam and I think we are ready to enable DNSSEC per default for
those Fedora installs that install a recursive nameservers.
The DLV has not been very active yet. Likely it contains many keys that
DNS administrators once submitted but then forgot about. Those people
would lose their domains when DLV is used, and could wrongly blame
Fedora for that. I would recommend leaving the DLV disabled for now.
Though in the future, I would like to see all fedora installs use a
local DNSSEC nameserver using the DNS servers presented by Network
Manager as forwarders, I would not recommend doing that at this point.
Please, let me know what you think. Feel free to ask any questions. I
would like to hear what people think, and then we can make a collective
decision on how to proceed.
Paul
15 years, 2 months
gcc 4.4 bug while rebuilding asterisk?
by Jeffrey Ollie
>From http://koji.fedoraproject.org/koji/getfile?taskID=1223918&name=build.log:
gcc -o app_voicemail.o -c app_voicemail.c -pthread
-I/builddir/build/BUILD/asterisk-1.6.1-rc1/include -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-Werror-implicit-function-declaration -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -march=k8 -fPIC
-DAST_MODULE=\"app_voicemail\" -DIMAP_STORAGE -DUSE_SYSTEM_IMAP -MD
-MT app_voicemail.o -MF .app_voicemail.o.d -MP
app_voicemail.c: In function 'open_mailbox':
app_voicemail.c:2086: internal compiler error: in
referenced_var_lookup, at tree-dfa.c:563
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccqqDlrj.out file, please attach
this to your bugreport.
--
Jeff Ollie
15 years, 2 months
Re: rpms/eclipse-systemtapgui/F-10 eclipse-systemtapgui.spec, 1.1, 1.2 import.log, 1.1, 1.2 sources, 1.2, 1.3
by Andrew Overholt
Hi Anithra,
On Thu, 2009-03-05 at 14:05 +0000, Anithra P Janakiraman wrote:
> %changelog
> +* Thu Mar 05 2009 Anithra P Janakiraman <anithra(a)linux.vnet.ibm.com> 1.0-7
> +- Bumping release to get rid of tag problems
> +* Thu Mar 05 2009 Anithra P Janakiraman <anithra(a)linux.vnet.ibm.com> 1.0-6
> +- Bug Fix.
> * Mon Feb 10 2009 Anithra P Janakiraman <anithra(a)linux.vnet.ibm.com> 1.0-5
> - Modified spec file.
> * Fri Feb 06 2009 Anithra P Janakiraman <anithra(a)linux.vnet.ibm.com> 1.0-4
One other thing: your changelog entries should have new lines between
them :)
Thanks,
Andrew
15 years, 2 months
Re: Broken dependencies: gdal
by Orion Poplawski
buildsys(a)fedoraproject.org wrote:
> gdal has broken dependencies in the development tree:
> On ppc:
> gdal-1.6.0-4.fc11.ppc64 requires libhdf5.so.5()(64bit)
> gdal-1.6.0-4.fc11.ppc64 requires libodbcinst.so.1()(64bit)
> gdal-1.6.0-4.fc11.ppc64 requires libodbc.so.1()(64bit)
I'm happy to do the bootstrap rebuild to fix this, but ACLs are closed.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
15 years, 2 months
Watching tasks in koji is no longer reliable?
by Tom Lane
Recently (in the past few weeks) I've noticed that the command-line koji
tool consistently fails to watch tasks for longer than a few minutes.
It watches okay for awhile and then fails with
error: (104, 'Connection reset by peer')
Anyone else seen this? Is this an intentional behavioral change
somewhere, or should I file a bug?
regards, tom lane
15 years, 2 months
Re: rpms/ntop/devel .cvsignore,1.3,1.4 ntop.spec,1.4,1.5 sources,1.3,1.4
by Rakesh Pandit
I had been dealing with ntop bugs always. I did not upgraded to 3.3.9
because that had a dependency for a dat file with is actually a big
big binary with different license which is itself an issue. So, I
thought about waiting for 4.x.x release.
I had been mentioning this in different bugs against it. Why would you
update without even pinging me ?
2009/3/2 Peter Vrabec wrote:
> Author: pvrabec
>
> Update of /cvs/extras/rpms/ntop/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv7164
>
> Modified Files:
> .cvsignore ntop.spec sources
> Log Message:
> - upgrade
> - invalid certificate fix (#486725)
>
>
>
> Index: .cvsignore
> ===================================================================
> RCS file: /cvs/extras/rpms/ntop/devel/.cvsignore,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- .cvsignore 22 Oct 2008 13:36:48 -0000 1.3
> +++ .cvsignore 2 Mar 2009 18:09:12 -0000 1.4
> @@ -1 +1,4 @@
> -ntop-3.3.8.tar.gz
> +GeoIP.tar.gz
> +GeoIPASNum.dat.gz
> +GeoLiteCity.dat.gz
> +ntop-3.3.9.tar.gz
>
>
> Index: ntop.spec
> ===================================================================
> RCS file: /cvs/extras/rpms/ntop/devel/ntop.spec,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -r1.4 -r1.5
> --- ntop.spec 26 Feb 2009 06:19:10 -0000 1.4
> +++ ntop.spec 2 Mar 2009 18:09:12 -0000 1.5
> @@ -1,6 +1,6 @@
> Name: ntop
> -Version: 3.3.8
> -Release: 3%{?dist}
> +Version: 3.3.9
> +Release: 1%{?dist}
> Summary: A network traffic probe similar to the UNIX top command
> Group: Applications/Internet
> License: GPLv2
After these inclusions license is not right ?
Check:
http://geolite.maxmind.com/download/geoip/database/LICENSE.txt
> @@ -8,17 +8,21 @@
> Source0: http://downloads.sourceforge.net/ntop/ntop-%{version}.tar.gz
> Source1: ntop.init
> Source2: ntop.conf
> +Source3: GeoIP.tar.gz
> +Source4: GeoLiteCity.dat.gz
> +Source5: GeoIPASNum.dat.gz
Complete URL would be better ?? These are big big files which have
text data but it is equivalent to binary in the sense that it cann't
be comprehended straight away. Is it okay for including in Fedora is a
question ?
> Patch1: ntop-am.patch
> Patch2: ntop-running-user.patch
> Patch3: ntop-dbfile-default-dir.patch
[..]
>
> %changelog
> -* Wed Feb 25 2009 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 3.3.8-3
> -- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
> +* Fri Feb 27 2009 Peter Vrabec <pvrabec(a)redhat.com> - 3.3.9-1
> +- upgrade
> +- invalid certificate fix (#486725)
Why would you remove old changelog entry ? Some more information in
addition to upgrade wouldn't hurt also.
Well certificate fix was also not that important. Now the rpm size is big.
My point is a ping before an upgrade or a mail would not have hurt ? I
was just away for past 10 days (I had noted that down in wiki also)
--
Regards,
Rakesh Pandit
15 years, 2 months
Orphaning a few (desktop-ey) packages
by Bastien Nocera
Here we are:
gnome-vfs2-obexftp (replaced by gvfs-obexftp)
gnome-audio (replaced by the XDG sound themes)
galago-filesystem, galago-daemon (replaced by the presence API in
gnome-session)
esound (dead, replaced by PA, nothing I care much about uses it
directly)
Cheers
15 years, 2 months
packagedb API change coming
by Toshio Kuratomi
For those of you with scripts that read information from the PackageDB,
there's going to be an API visible change sometime in the near future
(I'm hoping by the end of the mont). The next deployment of the
packagedb will switch from using userid and groupid to using username
and groupname.
This may make it easier for some people as you will not have to lookup
the username in the fedora account system anymore but it will require
code changes. I'll have a more detailed announcement when I have a test
server up and running for you to test your code against.
-Toshio
15 years, 2 months