Please remember to reply to the mailing list, not the original sender:
http://gnudip2.sourceforge.net/#mailinglist
+
Devin Reade wrote:
What I meant is that GnuDIP maintains two MX records. Each is either
present or not present, independently of each other. One is the the
user's own dynamic domain name (if the user selects Backup Mail
Exchanger). The other is the one the user can type in (which I called
foreign).
Ah! Now I understand what the semantics of that button are supposed
to be. Hmm. How about the case where the user has both a primary
and secondary MX for his host, but neither are supposed to be the
host itself? (He has email going to his FQDN, but does not run
the MTA/MDA himself?)
At the moment GnuDIP only allows one MTA domain name other than his own
domain name.
Let me try to be sure everyone reading this understands.
Both of the MX records have the user's domain name on the left side. One
also has the user's name on the right side (the one that gets set by the
Backp Mail Exchanger button), as the domain name to deliver to. The
other has a name that the user can specify. So the user can just set up
the second of these MX records, using the domain of an MTA that is
willing to receive mail for them. But th euser can only provide one such
domain name.
I suppose GnuDIP could be extended to allow more than one user specified
mail exchanger.
I suspect that quite a few people use GnuDIP for managing their own
private virtual domains, rather than to provide a public service. But
for such people, I think the wildcard and MX abilities of the GUI are
not that important. They can after all just use nsupdate to add
anything they want! They can just use GnuDIP to maintain those A
records whose addresses can change. in fact. GnuDIP can share the BIND
database with either a manual maintenance procedure or some in-house
custom system that also uses nsupdate. I think many such GnuDIP
installers don't even use the GUI. They just use the minidip.pl
script.
The wildcard and mail exchanger features of the GUI were targeted at
typical users of a public (maybe free) GnuDIP service. Some providers of
a free GnuDIP service might want to just suppress this altogether, and
instead offer backup mail service as a fee-based service.
- permitting an update to result in multiple 'A' records
rather than just one, thus winding up with entries
like this:
host.example.com. IN A192.168.1.10
IN A10.10.5.18
IN MX 100 mx1.example.com.
IN MX 200 mx2.example.com.
Think of the case where you have a multiply-homed site
where at least one of the interfaces is on dhcp. The
fix my particular problem case is allowing for one
IP via dhcp, and one IP which is static. The general
case would be two or more, any of which can be dynamic
or static.
I am not sure I follow the details of this scenario.
There's a few variations on the theme, but consider this one
(which exists today), simplified somewhat:
One of my users is a hobbiest who has a routable /24 with a
residential DSL upstream. It's usually good, but sometimes
takes an outage. It's a bit annoying but he doesn't want the
expense or administrative hassle of running a proper multihomed
network, which would imply BGP et al. Instead, he has gotten
a 2nd connection by getting a residential cable modem from another
provider, which provides a single IP via dhcp. Enter GnuDIP.
The machine on the cable modem and the one on his DSL modem act
as gateways for the network.
Now the 2nd link is good for acting as an ssh gateway, and with
appropriate magic we can also use it for an MX. There are a
few services which aren't as convenient to set up for redundancy,
though, such as HTTP (which I will use as the example although
there are other services which fall into the same category).
The web servers on the /24 do virtual hosting. As a consequence
(the reasons of which I shall not go into here) if one were to
provide multihomed services for both www.example.com and
www.another.com (where they are on the same server), then one
would need the following records:
www.example.com IN A192.168.1.10
IN A10.10.5.18
www.another.com IN A192.168.1.10
IN A10.10.5.18
In other words, both hostnames need two 'A' records, and
you can't fake it out with CNAMEs. As far as I can see,
GnuDIP will only permit a single 'A' record for a given
host, thus my original comments.
I know that in this scenario there are potential routing issues
(such as what happens if the packets come in on one interface
and out on another), but that is beyond the scope of GnuDIP.
