so here's a proposal. we (speaking for ISC here) could add a config
option
(default to OFF) to make bind send some kind of registration packet at
boot
time, containing an e-mail address for a technical contact for that
server,
and perhaps its hostname as well. the destination would be
On 3/26/2003 at 15:24:18 +, Paul Vixie said:
[snip]
so here's a proposal. we (speaking for ISC here) could add a config option
(default to OFF) to make bind send some kind of registration packet at boot
time, containing an e-mail address for a technical contact for that server,
and
Personaly I'v not looked favorably at given my email to various lists,
although its probably way too late and everyone by now has it...
1. I have another idea though, during setup of the server ask for email
address of list administrator, but keep that on the server itself.
2. Setup some dns
Thinking about it again, this would have additional advantage of
collecting statistics at where bind is being used (you get ips of the
servers) and what versions they are running. So even if they did not
update the software, you can still find out where they are by ip address
and if situation
On Wed, 2003-03-26 at 09:24, Paul Vixie wrote:
so here's a proposal. we (speaking for ISC here) could add a config option
(default to OFF) to make bind send some kind of registration packet at boot
time, containing an e-mail address for a technical contact for that server,
and perhaps its
On 26 Mar 2003, Jeffrey C. Ollie wrote:
What I would like to see is somewhat of the idea in
reverse. The ISC would host a zone that would contain TXT records with
security/bug advisories for every version:
I really like this solution. It seems clean and unobjectionable,
On 3/26/2003 at 08:31:40 -0800, Bill Woodcock said:
On 26 Mar 2003, Jeffrey C. Ollie wrote:
What I would like to see is somewhat of the idea in
reverse. The ISC would host a zone that would contain TXT records with
security/bug advisories for every version:
I really
* [EMAIL PROTECTED] (Paul Vixie) [Wed 26 Mar 2003, 16:24 CET]:
so here's a proposal. we (speaking for ISC here) could add a config option
(default to OFF) to make bind send some kind of registration packet at boot
time, containing an e-mail address for a technical contact for that server,
The ISC would host a zone that would contain TXT records with
security/bug advisories for every version:
I have a better idea.
ISC could set up a web page that would contain security/bug advisories for
every version. In order to make it easier for people to find this web
page, it could be
Jeffrey C. Ollie [EMAIL PROTECTED] wrote:
On Wed, 2003-03-26 at 09:24, Paul Vixie wrote:
so here's a proposal. we (speaking for ISC here) could add a config
option
(default to OFF) to make bind send some kind of registration packet
at boot
time, containing an e-mail address for a
On 26 Mar 2003, Jeffrey C. Ollie wrote:
What I would like to see is somewhat of the idea in
reverse. The ISC would host a zone that would contain TXT records
with
security/bug advisories for every version:
I really like this solution. It seems clean and
Perhaps nameservers could periodically poll
dig @?.root-servers.net 2.2.9.is-vuln.bind. txt chaos
or something similar; I suggest using roots because DNS queries
to them are far less likely to be filtered. If corresponding RR
is valid (see below), shut down BIND, thus forcing admins to
CK Date: Wed, 26 Mar 2003 11:59:02 -0500
CK From: Kuhtz, Christian
CK The way I see it, the issue isn't that there aren't enough
CK notifications of BIND vulnerabilities.
Perhaps. But how much is enough? Current notification levels
certainly get a fair number of admins to upgrade.
CK
On Wed, 26 Mar 2003, E.B. Dreger wrote:
CK The way I see it, the issue isn't that there aren't enough
CK notifications of BIND vulnerabilities.
Perhaps. But how much is enough? Current notification levels
certainly get a fair number of admins to upgrade.
The majority of those who don't
What are you talking about, DNS check option will work great for BIND,
I mean if BIND can not get to the root server and thereafter to ISC, you
don't have to worry about it getting hacked, its probably not connected to
internet. And dns already provides ability for ISC to have multiple
JL Date: Wed, 26 Mar 2003 13:00:57 -0500 (EST)
JL From: Jon Lewis
JL How hard would it be to have bind do some sort of secure.bind.isc.org
JL query at start-up or perhaps even periodically and have it log lots of
JL warnings or refuse to run if the query comes back and tells it the local
JL
CK The way I see it, the issue isn't that there aren't enough
CK notifications of BIND vulnerabilities.
Perhaps. But how much is enough? Current notification levels
certainly get a fair number of admins to upgrade.
Feel free to elaborate on where you think gaps exist..
CK
On Wed, 26 Mar 2003 08:14:45 PST, [EMAIL PROTECTED] said:
What are you talking about, DNS check option will work great for BIND,
I mean if BIND can not get to the root server and thereafter to ISC, you
don't have to worry about it getting hacked, its probably not connected to
Keep in
what i really want to talk
about is: how to get people to upgrade their software when defects
are found.
sending out announcements through CERT and the bind-announce m/l
isn't working.
Paul,
I seems to me that you are assuming that the problem is not enought
information gets to system
i see that a lot of folks are responding publically. sorry to spawn a thread.
[EMAIL PROTECTED] (Niels Bakker) writes:
So how much would this differ from `make install' running this shell script?
most bind installations are prefab -- the come with the operating system and
there's no make
PV Date: 26 Mar 2003 21:22:59 +
PV From: Paul Vixie
PV having the server check for updates and issue local mail is
This assumes the configured notification email address remains
valid, and the recipient doesn't sort them into a I'll get
around to it folder.
PV appealing, but i'm more
On Wed, 26 Mar 2003, E.B. Dreger wrote:
PV From: Paul Vixie
PV appealing, but i'm more concerned about MIM when fetching
PV update information than i am with simply registering package
PV version numbers, hosts, and e-mail addresses.
Distribute BIND with public key. Updates are encrypted
On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote:
One obvious problem with this would be that certain vendors prefer to
backport security fixes to older versions rather than test and release
new versions...so an insecure-looking version string may actually have
had fixes applied.
I think you're
SL Date: Thu, 27 Mar 2003 09:55:08 +1200 (NZST)
SL From: Simon Lyall
SL I'm also worried about any concept of trying to force
SL people to upgrade, even with bind I use some features (namely
SL an external named-xfer program) of bind v8 that arn't
SL available in bind v9 . For the servers which
Charles Sprickman wrote:
On Wed, 26 Mar 2003 [EMAIL PROTECTED] wrote:
One obvious problem with this would be that certain vendors prefer to
backport security fixes to older versions rather than test and release
new versions...so an insecure-looking version string may actually have
had fixes
25 matches
Mail list logo