[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnsop@cafax.se
From: Markus Stumpf <maex-lists-dns-ietf-dnsop@Space.Net>
Date: Wed, 27 Feb 2002 14:38:58 +0100
Content-Disposition: inline
In-Reply-To: <iluelj8w21q.fsf@josefsson.org>; from simon+dnsop@josefsson.org on Tue, Feb 26, 2002 at 07:06:25PM +0100
Sender: owner-dnsop@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: Minneapolis - agenda items please.

On Tue, Feb 26, 2002 at 07:06:25PM +0100, Simon Josefsson wrote:
> Let's analyze that:
> 
> 1) example.com administrators did this intentionally to cause problems
> [ ... ]
> 2) example.com administrators did this unintentionally.  They won't
>    receive any mail so they will hopefully fix this themselves sooner
> [ ... ]

You'be missed the exapmle in the draft, where the admins did this
intentionally to have a MX but they don't want emails at all.
They don't do this to cause any harm intentionally, but they don't know
better.

> So it seems as if the intended target of this draft (or at least for
> the example above) is MTA authors.  MTAs should cope with receiving
> all these local or reserved addressed as "real" MX, NS etc addresses,
> and still do the right thing.  It should be required reading for
> anyone writing an MTA.

Sure. IMHO this draft is of general interest and with this topic it
targets MTA authors as well as DNS admins.

> Donald just gave an instance were this scenario "didn't seem to cause
> much problems" for DEC and "that over the years millions of pieces of
> mail were delivered this way".  Why forbid such scenarios?

I have checked with some people who are very familiar with sendmail and
exim. According to them neither of those MTAs has any provisions to
handle the situation effectively. They go best MX, time out and the
backup MX. I know qmail does handle it more effectively, as it maintains
an IP timeout table.

That it works/worked for one company doesn't mean it doesn't cause any
problems. Think of the situation where AOL, yahoo, hotmail and a few
other "big email players" will switch to such a setup and I predict
it *will* cause troubles on your mailserver, of course not on theirs.
You'll get lots of hanging smtp connections waiting for a timeout and
your mailqueue will grow and the load on your server will also.

IMHO the section "4. Unreachable servers" in RFC 2182 "Selection and Operation
of Secondary DNS Servers" applies also to backup MX servers and the
arguments there are well thought out.

> cases where it is difficult to define what "a public DNS zone" really
> is (e.g., if I firewall my mail server so that only people in country
> A can access it, should I put its IP address in the global DNS?).

Would you consider your mailserver a "public" mailserver or a mailserver
dedicated to country A ?
As long as you use ACLs on your mailserver to allow emails (not
connections) from country A through and reject all others with a
permanent error code (there's a note about it in the draft as well as in
RFC 2821) I would consider it public. I am aware that this scenario
is different from the DEC one.
If you use a firewall for the ACL task, I'd not consider it public and
ban it in global DNS.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Home | Date list | Subject list