Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
On Fri, May 23, 2008 at 12:15:53PM +0200, Florian Weimer wrote: > It does not really matter because of the priming step at server start. > Just type "dig l.root-servers.net +norecurse", and you should get the > new address, or no address at all. Roughly one out of 13 times, l.root-servers.net will answer that question at startup. That's the situation that folks are caring about. > > We can't, no, but we can make sure our users are using the current > > root-servers; > BIND already takes care of that automatically. Not completely. Just mostly. :( lamont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
* Faidon Liambotis: > Even without the security tag, this is certainly not "wishlist" since > the old address for L is currently not responding to queries. It does not really matter because of the priming step at server start. Just type "dig l.root-servers.net +norecurse", and you should get the new address, or no address at all. > We can't, no, but we can make sure our users are using the current > root-servers; BIND already takes care of that automatically. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
Christoph Martin wrote: > >> No, it's not. The prefix containing the old route server address is > >> still assigned to Bill Manning, so there is no immediate cause for > >> alarm. Even the fake servers returned the correct address for the L > >> root, so the priming at the start would have removed the old L root > >> address. > > Even without the security tag, this is certainly not "wishlist" since > > the old address for L is currently not responding to queries. > > I'm leaving it to the maintainer, however, to avoid a bts war :) > > I think it is up to the Security-Team, because they have to do the Fix, > the code review and the security upload > > >> We can't fix broken Internet routing. The same thing could happen to > >> essentially all root servers. Changing addresses compiled/configured > >> into BIND does not prevent this. > > We can't, no, but we can make sure our users are using the current > > root-servers; a routing attack on those would be taken more seriously, I > > guess. > > I don't see the big problem doing a Security Update for this issue. It > is a minimal change, so the review by the Security Team would be easy. > > I don't think we can afford to ignore this issue and let our users ask > one wrong root-server if it happens to pop up again with spoofed > answers. I can imagine the bad press with "Debian taking Security Issues > lightly" Are you sure there is an issue to discuss at all? Hasn't the old address been operated by an operator of another root server? Hasn't the L root server's address been officially turned down already? Please explain the security problem in this. I believe, it would make sense to ask the SRMs whether an update of the nameserver packages in Debian stable is justified, and if they believe it is, talk to the respective maintainers to update their packages. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
Faidon Liambotis schrieb: > [removing [EMAIL PROTECTED] from Cc] > > Florian Weimer wrote: >> severity 449148 wishlist >> tag 449148 -security >> thanks >> >> * Faidon Liambotis: >> >>> You pointed out earlier in the bug log that is is a "critical" (sic) >>> bug but there wasn't a fix prepared for etch. >> >> No, it's not. The prefix containing the old route server address is >> still assigned to Bill Manning, so there is no immediate cause for >> alarm. Even the fake servers returned the correct address for the L >> root, so the priming at the start would have removed the old L root >> address. > Even without the security tag, this is certainly not "wishlist" since > the old address for L is currently not responding to queries. > I'm leaving it to the maintainer, however, to avoid a bts war :) I think it is up to the Security-Team, because they have to do the Fix, the code review and the security upload >> We can't fix broken Internet routing. The same thing could happen to >> essentially all root servers. Changing addresses compiled/configured >> into BIND does not prevent this. > We can't, no, but we can make sure our users are using the current > root-servers; a routing attack on those would be taken more seriously, I > guess. I don't see the big problem doing a Security Update for this issue. It is a minimal change, so the review by the Security Team would be easy. I don't think we can afford to ignore this issue and let our users ask one wrong root-server if it happens to pop up again with spoofed answers. I can imagine the bad press with "Debian taking Security Issues lightly" Christoph -- Christoph Martin, Leiter der EDV der Verwaltung, Uni-Mainz, Germany Internet-Mail: [EMAIL PROTECTED] Telefon: +49-6131-3926337 Fax: +49-6131-3922856 signature.asc Description: OpenPGP digital signature
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
[removing [EMAIL PROTECTED] from Cc] Florian Weimer wrote: severity 449148 wishlist tag 449148 -security thanks * Faidon Liambotis: You pointed out earlier in the bug log that is is a "critical" (sic) bug but there wasn't a fix prepared for etch. No, it's not. The prefix containing the old route server address is still assigned to Bill Manning, so there is no immediate cause for alarm. Even the fake servers returned the correct address for the L root, so the priming at the start would have removed the old L root address. Even without the security tag, this is certainly not "wishlist" since the old address for L is currently not responding to queries. I'm leaving it to the maintainer, however, to avoid a bts war :) We can't fix broken Internet routing. The same thing could happen to essentially all root servers. Changing addresses compiled/configured into BIND does not prevent this. We can't, no, but we can make sure our users are using the current root-servers; a routing attack on those would be taken more seriously, I guess. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
On Tuesday 20 May 2008 08:38, Florian Weimer wrote: > > You pointed out earlier in the bug log that is is a "critical" (sic) > > bug but there wasn't a fix prepared for etch. > > No, it's not. The prefix containing the old route server address is > still assigned to Bill Manning, so there is no immediate cause for > alarm. Even the fake servers returned the correct address for the L > root, so the priming at the start would have removed the old L root > address. > > We can't fix broken Internet routing. The same thing could happen to > essentially all root servers. Changing addresses compiled/configured > into BIND does not prevent this. I would suggest contacting the stable release managers to see if they will accept an update for this in the next stable point release. I agree with Florian that it doesn't have direct security implications so an advisory is out of place. Thijs pgpHAxt76DlVV.pgp Description: PGP signature
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
severity 449148 wishlist tag 449148 -security thanks * Faidon Liambotis: > You pointed out earlier in the bug log that is is a "critical" (sic) > bug but there wasn't a fix prepared for etch. No, it's not. The prefix containing the old route server address is still assigned to Bill Manning, so there is no immediate cause for alarm. Even the fake servers returned the correct address for the L root, so the priming at the start would have removed the old L root address. We can't fix broken Internet routing. The same thing could happen to essentially all root servers. Changing addresses compiled/configured into BIND does not prevent this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
severity 449148 grave tags 449148 + security thanks Hi, You pointed out earlier in the bug log that is is a "critical" (sic) bug but there wasn't a fix prepared for etch. I wasn't aware of this change until I discovered[1] (via slashdot) a blog post explaining that the old IP address was still in use by a non-authoritative body, possibly recording queries and therefore gathering sensitive information. The old IP address has actually stopped responding to queries and therefore this isn't a very great deal, security-wise, right now. It is, however, a serious (imho) bug since 1 of the 13 root NS on etch systems isn't responding to queries. Also, nothing (AFAIK) is stopping the new owner to start responding to queries again, perhaps for malicious purposes such as recording data -- or worse, responding with fake answers! Please fix this bug for etch; I'd vote to do it via a security upload (and a DSA) but I guess an update through a stable point release would also be an option. Thanks, Faidon 1: http://www.renesys.com/blog/2008/05/identity_theft_hits_the_root_n_1.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
On Sat, Nov 03, 2007 at 03:27:30PM +0100, Bjørn Mork wrote: > /etc/bind/db.root needs an update. Please see forwarded message Yes, it does. The forwarded message arrived in my mailbox a few hours earlier. And this obviously critical update needs to be done before too many of the root namerservers change IP addresses... Anyrate, it'll get uploaded once I'm back in the land of reasonable connectivity. lamont
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
Package: bind9
Version: 1:9.3.4-2etch1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/etc/bind/db.root needs an update. Please see forwarded message
From: Mark Andrews <[EMAIL PROTECTED]>
Subject: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
To: [EMAIL PROTECTED]
Date: Sat, 03 Nov 2007 08:37:24 +1100
Reply-to: [EMAIL PROTECTED]
If you already have a root hints zone defined in named.conf
you need to update the address in the file it loads from.
The easiest way to create a new file is to run dig, check
the contents of the file it generates then move the file
into place.
dig ns . @a.root-servers.net > newfile
If you don't have any root zone defined they you will be
using the built-in hints. In this case you should create
a root hints zone if you don't have a root zone already
defined and you are using class IN (the default class).
dig ns . @a.root-servers.net > root-hints
zone "." {
type hint;
file "root-hints";
};
If you are not using views you do this at the options level.
If you are using views you need to define this zone in
each view of class IN.
BIND 9.3.5, BIND 9.4.2 (9.4.2rc2) and BIND 9.5.0 (9.5.0a7) will
have their built-in root hints updated to reflect this change.
If you wish to change the built in hints apply the attached
patch. In the top level directory run.
patch -p1 < l-root-servers.patch
make clean
make
Mark
- --
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
- -- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (700, 'stable'), (650, 'testing')
Architecture: i386 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-2-amd64
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages bind9 depends on:
ii adduser3.102 Add and remove users and groups
ii libbind9-0 1:9.3.4-2etch1BIND9 Shared Library used by BIND
ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii libdns22 1:9.3.4-2etch1DNS Shared Library used by BIND
ii libisc11 1:9.3.4-2etch1ISC Shared Library used by BIND
ii libisccc0 1:9.3.4-2etch1Command Channel Library used by BI
ii libisccfg1 1:9.3.4-2etch1Config File Handling Library used
ii liblwres9 1:9.3.4-2etch1Lightweight Resolver Library used
ii libssl0.9.80.9.8c-4etch1 SSL shared libraries
ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip
ii netbase4.29 Basic TCP/IP networking system
bind9 recommends no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHLIVS10rqkowbIskRAlEeAJ9AAsAuFslD6rZe1k8rcl0FJePN9ACaAvDD
ViZMjQVDDTC6wL0XD387n4o=
=FfMo
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
