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


To: Markus Stumpf <maex-lists-dns-ietf-dnsop@Space.Net>
Cc: dnsop@cafax.se
From: Simon Josefsson <simon+dnsop@josefsson.org>
Date: Tue, 26 Feb 2002 19:06:25 +0100
In-Reply-To: <20020226151820.A9474@Space.Net> (Markus Stumpf's message of"Tue, 26 Feb 2002 15:18:20 +0100")
Sender: owner-dnsop@cafax.se
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2.50(i686-pc-linux-gnu)
Subject: Re: Minneapolis - agenda items please.

Markus Stumpf <maex-lists-dns-ietf-dnsop@Space.Net> writes:

> On Tue, Feb 26, 2002 at 12:31:46AM +0100, Simon Josefsson wrote:
>> see how it harms anyone else but the people that put incorrect
>> information in their own DNS zones.
>
> Assume  example.com has a MX to mail.example.com and mail.example.com
> has A 127.0.0.1.
> You receive e.g. spam from @example.com and your mailserver tries do deliver
> a bounce. I am sure there a lot of mailservers out there that will suffer
> quite some harm (and did in the past).

Let's analyze that:

1) example.com administrators did this intentionally to cause problems
   for you.  Then it is a MTA problem, and should be fixed.  People
   will do this to you if it causes problems in your software, so you
   must protect yourself from it.

2) example.com administrators did this unintentionally.  They won't
   receive any mail so they will hopefully fix this themselves sooner
   or later.  Even if they don't care and never fixes it, this
   shouldn't cause any problems because other people's MTA should
   handle it as an attempted attack in 1).

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.

> Another example is section
>      6.3 SMTP servers behind firewalls
> I know lot of e.g. universities do this. Their faculties are somewhat
> independant and want to maintain their own DNS and Mailservers, but
> they have zillions of relay open workstations. So the computing staff
> blocks port 25 incoming on the border routers and forces the departments to
> add a lower priority MX gate.university. That way they don't have to maintain
> static routing tables on the mailserver as gate.university delivers
> via MX and does "the right thing". However this has a big impact
> on the sending mailservers, as they never can reach the best prio MX,
> time out and then backup. So it doesn't harm the DNS maintainers but
> people that try to send email to that destination.

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?

>> Of course, the contents of the draft is good and everyone should
>> understand and follow it, but doesn't everyone already?  Is there any
>> point in caring about the people that doesn't?
>
> Yes. Some people simply don't think of consequences or are too unexperienced.
> Developers of software (e.g. mailservers) have a document of "bad things"
> that can happen and may put workarounds in.

Yes.  I agree that the draft documents some well known but not
previously documented problems.  You can point newbies to draft and
they will learn something.  Good.  For some more complex setups,
however, these recommendations can be questioned -- such as in the DEC
example, or putting "localhost" in SOA to prevent W2k flooding, or
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?).


Home | Date list | Subject list