[H-GEN] problems with accessing mail at bigpond

[Greg Black]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Robert Brockway wrote:

| On Sat, 4 May 2002, Greg Black wrote:
| 
| > | I certainly find having remote dns servers ready to answer queries useful
| > | for diagnostics
| > 
| > Right now, I can't imagine a case where an open DNS server would
| > be necessary for any diagnostics that I'd want to run, but maybe
| > that's a failure of my imagination.
| 
| If I've delegated a domain recently, I might like to check how propogation
| is going on remote servers. Granted within 48 hours it should have all
| happened :)

Honestly, I don't see this as a legitimate case.  Although
people who have not taken the time to understand how DNS works
do manage to make a mess of it, in fact it's a simple system and
it's quite possible to be sure that you've got it right before
deployment by internal testing.  Any change to a domain will
usually be performed in two steps:  shorten the TTLs of the
affected records sufficiently in advance so that, when the
change is made, it will be picked up quickly enough by remote
servers; then implement the change.  This is not rocket science.

| Imagine dual masters with differing views of the
| zone with no (or imcomplete) network diagrams.  Usually along the lines of
| internal/external servers - but not a proper split dns.

This only happens when handled by incompetent admins.  The
solutions are obvious.  Getting a full, correct, set of DNS
records is simple, if tedious, grunt work.

| > All the servers that I run are closed to outsiders and I find
| > that is increasingly the case.
| 
| I'm certainly interested in your reasons behind it and will consider this
| also if I beocme convinced :)

My reasons are a desire to avoid waste of my bandwidth (as
previously mentioned), a desire to reduce my exposure to
possible exploits in name servers, and a desire to avoid being
sued if my name servers are implicated in a DoS attack of the
type mentioned in the reference Mark posted where name servers
can be used to amplify an attack.

| > | I'd be interested in any security issues relating directly to having
| > | a dns server which will answer queries from any host.
| > 
| > There was a time when new BIND exploits came out regularly and
| 
| Indeed, but I don't think exploits are directly connected to what we are
| talking about.
| 
| ***WHAT***?!?!?! you say ... I shall explain :)
| 
| The way to stop exploits is to block port 53, not necessarily to block a
| particular type of dns query.  I block AXFR from non-slaves as this
| information might be used to obtain a hostname, valid IP, etc for a future
| attack.  Almost all dns servers now block AXFR except from hosts that need
| it.
| 
| If a server I'm running is authorative for a zone I'll need to leave port
| 53 open anyway thus I gain nothing by blocking external queries as the box
| is open to the net anyway.
| 
| If I don't need to open port 53 I certainly won't.
| 
| I hope I was able to convey my meaning here.

I think it was clear, but I think you're wrong.  Leaving aside
the DoS attack referred to above, the thing is that a name
server has two distinct roles.  Unfortunately for everybody, the
BIND authors folded the two roles into one program, named, in
their implementation and so much confusion exists in the minds
of users and admins.

The big advantage of djbdns (as an example) is that it separates
the roles: tinydns is the authoritative name server and is
designed to be accessible to the entire world; dnscache is the
caching and recursively resolving name server used by internal
clients for normal name service.

The role of an authoritative name server can be accomplished by
simple code and is easily audited.  It's a simple trick to write
such a tool and to be sure that it's both lightweight enough to
be easy to run and secure enough to be trusted.  Since it never
does recursive lookups and since it never answers questions
about stuff it's not authoritative for, it's difficult to get
into trouble with it.

Sadly, BIND still uses the monolithic approach, violating
standard Unix programming principles and common sense.  Happily,
its authors are finally taking the security implications of
their software a bit more seriously and I think they'll have a
reasonably safe system in place soon -- although they'll always
have a greater exposure to bugs because of the code size in the
one program.

I'm not arguing that people should stop using BIND -- the pain
would be too great for many large installations.  But I do
strongly advocate that they lock it down as tightly as possible
before it bites them and that they do not offer general name
service to outsiders under any circumstances.

Greg

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/