Napster should offer the music industry ``dot-com''
style stock options. If Napster could make a
go of it, they both win. If Napster turns into
another ``dot-gone'' then the music industry
gets what they deserve.
The folks who wrote and/or maintain bind
had the best of intentions. Bind code
filled the need when Arpanet/Internet
sites were copying around large host files.
I don't
wish to denigrate / attack those who helped
create and maintain bind, but one cannot
ignore the fact that bind is
one of the larger infrastructure
vulnerabilities we face today. The track
record of bind v8 and previous version cast
doubt on the wisdom trust bind v9.
Bind's track record
clearly shows it for what it is: a
bug infested and many flawed chunk of code
that has lasted way past its prime. Bind is to name service as sendmail is to EMail.
Bind has and very likely continues to suffer from:
Buffer overruns
%n bugs
Denial-of-service attacks
Cache poisoning
Man-in-the-middle attacks
root exploits
protocol exploits
etc., etc., etc.
But all is not lost in the name service front.
A few alternatives to bind exist now. Several more efforts are in the works as well. Time and
experience will show which efforts will succeed.
For those cannot become a bind-free site now or
in the near term future, there are some things
you can do to minimize the damage bind code can cause.
Consider the following ideas.
These idea are not for everyone.
This list is by no means exhaustive.
You might want to:
run named on separate hosts (do not put
other services on your named server machines)
run named in a chrooted environment
dedicate a separate file system for named
if your OS allows it, mount that separate
file system with nosetuid, nodev, etc...
run named with ``-u dns'' or better yet...
never run named as root: use a small well
designed prog to listen on port 53 and forward
connections to named -or- change your kernel
to allow the dns user to use port 53 (on Linux
this is a simple change to inet_bind() function
in net/ipv4/af_inet.c)
where possible in applications, avoid
doing name service lookups; for example log
IP addresses instead of hostnames
do not run named on your firewall(s)
put a firewall(s) between your named host(s)
and machines you care about
use different named servers for different
needs - consider running separate services for:
your external authoritative name server
(configure to ONLY answer queries for your
external domains, no glue, no recursion)
your internal / intranet name service needs
your production services (accessible by
only your production servers, not the Internet
or your Intranet)
If you treat bind with caution, you will be
more likely to survive intact until a
bind-free solution with a good track record
presents itself.
From the conversations that I have had with
IOCCC
winners,
I would say about 1/2 of what drives them
recognition. More than a few IOCCC
winners tell is that they put the fact that
they won on the resume and/or web site.
I was told by one winner that they won a
promotion within their company and beat out
a number of other candidates in part because
their local newspaper had run a story about
their ``winning a programming contest''. And,
``I swear I am not making this up'':
their promotion gave them a significant new
role in the company QA department.
This winner credits
a clueless newspaper reporter as well as a
pointy-haired management selection committee
for not understanding the IOCCC.
Winners have the choice to remain anonymous.
Very few entries even request this option.
The only anonymous winner was back in 1984.
When asked by people doing stories on the IOCCC,
we tell them that this person as somewhat
well known for a number of things, not the
least is in regards to their early work with
C and Un*x.
To this day they remain steadfast in their
desire to remain anonymous.
I'd say about 1/3 are driven by the technical
challenge. Some winners have reported that they
worked off-and-on on their entry for several
years. In one case a winning entry became
part of their Ph.D. thesis!
Given the complexity of some of the winners,
I can certainly understand this motivation.
Of the remaining 1/6, one
is collecting multiple wins; to try
be the person who as won the most number of
times.
Another less common motivation is in finding
new ways
to abuse the IOCCC rules.
obfustification is not a word, but obfuscation is:
obfuscation is a noun
In a conversation with an OED editor, we learned that obfuscate in its various forms
have been used as far back as 1577, but fell into
disuse around 1900. The editor told us that
their had been an increase of the use of the word
in the early 1990's... and traced part of the
increase back to the
IOCCC. :-)
What prevents an enemy from forging a scan
of a recently hacked site... FBI is given
logs with the your IP address listed as the
source of a scan....
and then the FBI snarfs your computers, books, etc?!?!?
NOTHING!!!
Your tax payer dollars at work.:-(:-(
p.s. This is why we need to support folks
such as the eff.
Slashdot Mirror
They should offer the first options to Lars ... :-)
The folks who wrote and/or maintain bind had the best of intentions. Bind code filled the need when Arpanet/Internet sites were copying around large host files. I don't wish to denigrate / attack those who helped create and maintain bind, but one cannot ignore the fact that bind is one of the larger infrastructure vulnerabilities we face today. The track record of bind v8 and previous version cast doubt on the wisdom trust bind v9.
Bind's track record clearly shows it for what it is: a bug infested and many flawed chunk of code that has lasted way past its prime. Bind is to name service as sendmail is to EMail.
Bind has and very likely continues to suffer from:
But all is not lost in the name service front. A few alternatives to bind exist now. Several more efforts are in the works as well. Time and experience will show which efforts will succeed.
For those cannot become a bind-free site now or in the near term future, there are some things you can do to minimize the damage bind code can cause. Consider the following ideas. These idea are not for everyone. This list is by no means exhaustive. You might want to:
If you treat bind with caution, you will be more likely to survive intact until a bind-free solution with a good track record presents itself.
- To help with the DeCSS case by proving
that Source Code is entitled to the 1st Amendment
Protection under the US Constitution:
Search for the word ioccc in that web page.From the conversations that I have had with IOCCC winners, I would say about 1/2 of what drives them recognition. More than a few IOCCC winners tell is that they put the fact that they won on the resume and/or web site.
I was told by one winner that they won a promotion within their company and beat out a number of other candidates in part because their local newspaper had run a story about their ``winning a programming contest''. And, ``I swear I am not making this up'': their promotion gave them a significant new role in the company QA department. This winner credits a clueless newspaper reporter as well as a pointy-haired management selection committee for not understanding the IOCCC.
Winners have the choice to remain anonymous. Very few entries even request this option. The only anonymous winner was back in 1984. When asked by people doing stories on the IOCCC, we tell them that this person as somewhat well known for a number of things, not the least is in regards to their early work with C and Un*x. To this day they remain steadfast in their desire to remain anonymous.
I'd say about 1/3 are driven by the technical challenge. Some winners have reported that they worked off-and-on on their entry for several years. In one case a winning entry became part of their Ph.D. thesis! Given the complexity of some of the winners, I can certainly understand this motivation.
Of the remaining 1/6, one is collecting multiple wins; to try be the person who as won the most number of times. Another less common motivation is in finding new ways to abuse the IOCCC rules.
My favorite IOCCC abuse so far was done by:
Spinellis's 1988 entry:
#include </dev/tty>
obfuscation is a noun
In a conversation with an OED editor, we learned that obfuscate in its various forms have been used as far back as 1577, but fell into disuse around 1900. The editor told us that their had been an increase of the use of the word in the early 1990's ... and traced part of the
increase back to the
IOCCC. :-)
NOTHING!!!
Your tax payer dollars at work. :-( :-(
p.s. This is why we need to support folks such as the eff.
7) The film had sound, images and color ... though not necessarily
in that order.
6) The pot smoking dude in the front row of the movie theater
appeared have had a good time.
5) One had plenty of opportunities during the film to go to
the snack-bar or bathroom.
4) It was only based on a book by L. Ron Hubbard.
3) It contrasted well with the coming attraction previews
shown just prior to the film.
2) While set in the year 3000, there was little concern over
the Y3K bug.
1) It served as an interesting warm-up double-header to the
midnight showing of ``Rocky Horror''.
0) The film was not wound in an infinite loop. There was a
definite point in time when the film was no longer playing.