[373] in Hesiod
Re: HESIOD type=maildrop class=IN, Sendmail
daemon@ATHENA.MIT.EDU (Randall S. Winchester)
Fri Jan 23 14:14:31 1998
Date: Fri, 23 Jan 1998 14:13:35 -0500 (EST)
From: "Randall S. Winchester" <rsw@Glue.umd.edu>
To: Russell McOrmond <russell@flora.ottawa.on.ca>
Cc: hesiod@MIT.EDU, maildomain@flora.org
In-Reply-To: <199801231800.NAA25972@fox.flora.ottawa.on.ca>
On Fri, 23 Jan 1998, Russell McOrmond wrote:
: Randall S. Winchester wrote:
: > OPPS that was class=hs. We plan to migrate to class=in when we do some cell
: > merging. Hesiod is supported (being integrated...) in BIND 8.8.x in the form
: > of class=IN. This will be the long term future of hesiod most likely (IMO).
:
: Bind 8, and even the 4.9.5 I am using also directly supports the use of
: class=HS as well, which is what I am doing on FLORA. I am suggesting,
: however, that there are problems with the migration to class=IN that
: needs to be fully looked into before HESIOD moves that direction.
:
: The migration to class=IN, if you query any DNS servers other than your
: own servers, is going to cause you problems. What we are trying to do
: with the HESIOD type=maildrop information is to create a network of sites
: that could share the load in addressing community-based domains which are
: comprised completely of 'forwarded' email addresses. The more sites that
: participate in this mapping, the more shortcuts in Email delivery that
: can be done, leaving the MX listed sites to only have to handle Email
: delivery for those sites not participating, or for the bouncing of
: invalid Email addresses.
:
:
: In this scenario, the more participating sites the more robust the
: community Email addressing becomes.
:
: What we are doing in Sendmail is the following:
:
: --cut from http://www.flora.org/flora/server/hes-sendmail-mc.html --
: LOCAL_CONFIG
:
: # Declare mbt as a hash-lookup database:
: Kmbt hash /etc/mbt.db
:
: # Hesiod Database - look it up in the 'maildrop' hesiod type
: Khesmail hesiod maildrop
:
: LOCAL_RULE_0
:
: # Use mailboxtable-database:
: R$+ < @ $+ . > $: $1 < @ $2 > .
: R$+ < @ $+ > $* $: $(mbt $1@$2 $: $1 < @ $2 > $3 $)
: R$+ < @ $+ > $* $: $(hesmail $1@$2 $: $1 < @ $2 > $3 $)
: R$+ < @ $+ > $* $: $(mbt $2 $: $1 < @ $2 > $3 $)
: RERROR $* $#error $: $1
: R$+ < @ $+ > . $: $1 < @ $2 . >
:
: --cut--
:
: Essentially, this is having Sendmail do the equivalent of:
:
: hesinfo $EMAIL maildrop
:
: on any $EMAIL address that sendmail is sending out. The 'maildrop' type
: essentially, when given an email address, will just return another
: SINGLE email address (No pipes, multiple-addresses, or anything else
: supported).
I think I get the idea, thanks for the example.
:
: This construct causes HESIOD to look up information in any domain. If
: one restricts themselves to class=HS , then through their use of a
: private root-server, they can restrict which domains they will do this
: mapping for. If they allow their hesiod to query class=IN, then they
: will be making use of the regular Internet root-servers and will run into
: various problems with other DNS sites that do not understand that query.
Some sites are configuring their hesiod libraries to query both class=IN and
class=HS in one order or the other. You may want to consider this support
issue and what will be required from a site that wants to use "maildrop"
with either IN or HS classes.
:
: Your comment about publishing Email addresses via HESIOD, in a world of
: SPAMMERS, is noted: If this became more universal, then HESIOD tables
: could be used to collect Email addresses. I guess I see that as
: security through obscurity as there are so many easier ways to collect
: Email addresses. SPAM problems are going to need to be addressed in
: other ways: PGP signature filtering of Email, authenticated SMTP, secured
: DNS (Only allow participating sites to copy the zone?), and so on. We
: cannot continue to hide ourselves from the public view in order to avoid
: what should be an illegal act. Maybe the Bit tax, with the SENDER
: charged for the transmission as with phone calls, will deal with that
: problem eventually (Let's not follow that thread now ;-).
Well we do alot of anti spam filtering here and drop literaly thousands of
spam on the floor each day, and we still see it. Thie is one place where I
would not feel comfortable with security by obscurity. The people who write
the large spam code (i.e. for profit) monitor relevent lists discussing
sendmail issues. it would not be "obscure" for long. However, like I
mentioned, if the security/access to the data was well thought out, it might
be worth considering. If this gets high use then class=IN will probably be
the only way to get it heavy involvement. Maintaining yet another root
nameserver list has its' own problems. However it has discussed before. Paul
Vixie had asked for a hands up of those interested in sponsering those HS
root servers. In the ensuing conversations, he was convinced to support
hesiod only with class=IN and *not* class=HS. Since Paul is the supported of
BIND, I think you should consider how to fix the code to account for errors.
I would suspect most new Hesiod sites are using class=IN. Many of the older
Hesiod sites like us have it on our todo list to switch.
:
:
: I remember reading that BIND does have a method of restricting zone
: transfers and lookups. I suspect that this will be the appropriate way
: to deal with SPAMMERS. Being able to lookup is not the problem as a SPAMMER
: could do that by firing Email at your SMTP server with random Email
: addresses, most of which you would try to bounce-back to their BOGUS
: addresses - being able to transfer the zone and then build a list of
: legitimate Email addresses from it is a problem.
:
Put something like this in the top of each relevant zone file.
secure_zone HS TXT 128.8.0.0:255.255.0.0
secure_zone HS TXT 129.2.0.0:255.255.0.0
secure_zone HS TXT 192.54.99.0:255.255.255.0
secure_zone HS TXT 206.196.0.0:255.255.0.0
secure_zone HS TXT 127.0.0.1:H
Randall
