Re: Now well off-topic - was Re: [Exim] how to configure HEL…

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Exim Users Mailing List
日付:  
To: James P. Roberts
CC: Exim Users Mailing List
題目: Re: Now well off-topic - was Re: [Exim] how to configure HELO/EHLO and DNS for multi-homed hosts
[ On Tuesday, July 1, 2003 at 11:58:14 (-0400), James P. Roberts wrote: ]
> Subject: Re: Now well off-topic - was Re: [Exim] how to configure HELO/EHLO and DNS for multi-homed hosts
>
> OK, now you've lost me, Greg. I suspect there is something in what you said
> here that might explain the root of the disagreement. I just don't know what
> it is, yet.


The reason the Reverse DNS can sometimes be used as a quite reliable way
to authenticate hostnames as having correct addresses is that the
records retrieved from the Reverse DNS come from separate nameservers
and from zones under separate authorities. This can raise the bar
against potential attackers by several levels.

OK, time for a lesson about a basic information security concept:

E.g. I ask Wietse if punster@??? is a valid address
for a "James P. Roberts", and then I ask Philip what e-mail address I
should use for "James P. Roberts". If I all the answers match up then I
know that I have the right address because though I might not trust
Wietse or Philip independently, I can probably trust that their answers
are good if they match since I won't expect any collusion between them.
However if one party is forging addresses then one of the answers I get
back cannot match up if the other answer is authentic and thus I know
there's something very wrong.

So although there's very little inherent security possible in the basic
DNS as it's implemented on the Internet today (i.e. with UDP over plain
IP being the primary mode of transport used for both queries and
replies), having separate nameservers and separate authorities for
forward and reverse DNS can raise the bar significantly against at least
some types of hostname spoofing attempts.

If you go back and research and read the discussions surrounding the
initial recommendations to use the Reverse DNS for hostname
authentication you'll discover that the reason this procedure was
suggested in the first place was that at that time a significant number
of in-addr.arpa zones were served by other people's nameservers.

Obviously lots of people do directly control their own DNS for both
their normal host domain names as well as for their in-addr.arpa zones,
and perhaps a lot more do today than back when this procedure was
sufficient to allow rsh to be used safely on the Internet. Assuming
such people run secure nameservers then the only risk is that they are
bad people that I don't want to talk to but at least no third party can
try to fake their names or addresses. On the other hand if some third
party can hijack their nameserver then that third party will have total
control and can make any attempt to authenticate hostname addresses fall
flat on its face (assuming the attacker either can use an address in the
vulnerable party's network, or also has control over the in-addr.arpa
zone for the the address they're trying to make me think belongs to the
vulnerable party).

Anyone who does directly control their own in-addr.arpa zones and who
really wants to keep at least some level of reliability for hostname
address authentication, will at least run their in-addr.arpa zones on
separate nameservers from their forward zones. Not very many people do
this on the Internet today (I don't, nor do the ISPs I support), but
some people do.

> How can I possibly assure a consistent Forward and Reverse DNS if I am not
> responsible for both sides of it? The short answer is, I cannot.


The long answer is that you can and you do so by way of your service
contract with your ISP. Having NS records pointing at your own
nameserver isn't even remotely the only way to have "control" over your
own Reverse DNS! As you can hopefully now see "direct" control isn't
even necessarily desirable.

--
                                Greg A. Woods


+1 416 218-0098;            <g.a.woods@???>;           <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>