[374] in Hesiod
Re: HESIOD type=maildrop class=IN, Sendmail
daemon@ATHENA.MIT.EDU (Michael C. Richardson)
Sat Jan 24 20:01:01 1998
Cc: rsw@glue.umd.edu (Randall S. Winchester)
To: hesiod@MIT.EDU
In-Reply-To: Your message of "23 Jan 1998 14:14:04 EST."
<Pine.SOL.3.95q.980123133826.28590E-100000@atlantis.csc.umd.edu>
Date: Sat, 24 Jan 1998 20:02:31 -0500
From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
-----BEGIN PGP SIGNED MESSAGE-----
[i'm not on the list yet, but Russell had dropped me some posts from it.]
>>>>> "Randall" == Randall S Winchester <rsw@Glue.umd.edu> writes:
Randall> : : Essentially, this is having Sendmail do the equivalent of: :
Randall> : hesinfo $EMAIL maildrop : : on any $EMAIL address that
Randall> sendmail is sending out. The 'maildrop' type : essentially,
Randall> when given an email address, will just return another : SINGLE
Randall> email address (No pipes, multiple-addresses, or anything else :
Randall> supported).
Randall> I think I get the idea, thanks for the example.
Randall> Some sites are configuring their hesiod libraries to query both
Randall> class=IN and class=HS in one order or the other. You may want to
Randall> consider this support issue and what will be required from a
Randall> site that wants to use "maildrop" with either IN or HS classes.
Russell and I have been arguing over the merits of having maildrop in the
IN classes. I feel that it isn't something I want to do. I prefer hesiod
zones, because I can make a local machine be the hesiod root (in my case,
my mail server), and can arrange to be a secondary for all domains that I
want to do remappings for. Since I'm authoritative for ./hs, I answer no
without any network traffice.
If it were in the IN class, I couldn't do this, and:
1. it would do a lot more DNS lookups --- failed ones for every
piece of email processed. These would take network bandwidth
2. for large remote domains, I'm less likely to find the relevant
hesiod domain information in my cache, and so more reliant on the
remote DNS servers and the net being fully operational to deliver
email. Without the username lookups, I just need an MX and an A
record, and they fit in my DNS cache a lot easier.
[2b. since all this extra stuff is in the DNS zones, and they are
big, they are more expensive to secondary for.]
3. for very remote domains, most of the benefit is lost. ox.org is
a community network --- the load is handled by a number of equal
weight MX'ed hosts, and we use the hesiod map to forward mail to the
appropriate "real" mailbox. The avoids having a centralized, heavily
loaded machine (iki.fi does that, for instance. I don't know how
acm.org or pobox.com work), and also makes it more redundant. Unless
people in Ottawa start getting mail drops at remote places (like
iki.fi) and forward them back to Ottawa, we rarely save anything by
looking at iki's map before forwarding.
4. I'm not sure that we want just anyone to be aware of our
maps. Many people want an ox.org, etc. domain so that they can
have an address to post from at work, without having anyone attaching
their post to their employers.
Randall> Well we do alot of anti spam filtering here and drop literaly
Randall> thousands of spam on the floor each day, and we still see
Randall> it. Thie is one place where I would not feel comfortable with
Randall> security by obscurity. The people who write the large spam code
Randall> (i.e. for profit) monitor relevent lists discussing sendmail
Randall> issues. it would not be "obscure" for long. However, like I
Randall> mentioned, if the security/access to the data was well thought
Randall> out, it might be worth considering. If this gets high use then
One simple way I can think of is to use xfernets type controls, hesiod
class data, and always make all involved machines secondaries. Either run
another copy of bind on a different port, and protect that port from other
than localhost/localnet, or teach bind to answer IN class queries only.
Randall> involvement. Maintaining yet another root nameserver list has
Randall> its' own problems. However it has discussed before. Paul Vixie
Randall> had asked for a hands up of those interested in sponsering those
Randall> HS root servers. In the ensuing conversations, he was convinced
Randall> to support hesiod only with class=IN and *not* class=HS. Since
Randall> Paul is the supported of BIND, I think you should consider how
What I want to know is: why do I want to share hesiod data outside of my
zone of control? Specifically, why do I care where the hesiod zones for
umd.edu start? Is there information there that you really want me to see?
Randall> to fix the code to account for errors. I would suspect most new
Randall> Hesiod sites are using class=IN. Many of the older Hesiod sites
Randall> like us have it on our todo list to switch.
On my todo list to upgrade for awhile, but I wound up dropping it from my
list until I get a reason to do so.
Randall> Put something like this in the top of each relevant zone file.
Randall> secure_zone HS TXT 128.8.0.0:255.255.0.0 secure_zone HS TXT
Randall> 129.2.0.0:255.255.0.0 secure_zone HS TXT
Randall> 192.54.99.0:255.255.255.0 secure_zone HS TXT
Randall> 206.196.0.0:255.255.0.0 secure_zone HS TXT 127.0.0.1:H
Hmm. I've never seen this before. [reads source code a bit]
It appears that bind can already do the restricting that I mention above.
:!mcr!: | Sandelman Software Works Corporation, Ottawa, ON
Michael Richardson |Network and security consulting and contract programming
Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBNMqPHtiXVu0RiA21AQHE1wL/S+3V4Ss9qCE9jYsee/2g77DCgDqYgome
5+l22KbOwHPPbtaRqyNdhDyDGvPt/QsGsDgpFm2B+52uFalNPsqFdVcQIBW5UZRz
UtWyt7z5v9+h18jkZ/klBlTHeEjD+Oc1
=U80B
-----END PGP SIGNATURE-----
