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 A 192.168.1.10 > >> IN A 10.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 A 192.168.1.10 > IN A 10.10.5.18 > www.another.com IN A 192.168.1.10 > IN A 10.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. > It's ugly, but not intractable. BTW, the web server itself > is only single-homed, but the network via its routers is > multiply-homed. > > Does that clarify things at all? > > Are you having nightmares yet? :) I have a better understanding. As a simpler example, I can imagine someone having both a DSL and a cable connnection (or even several of each), all of which lead to a network card in the SAME HTTP server machine, and wanting to be able to have the same domain name for the current address of each network card. This would provide a way to achieve a larger "upload" bandwidth (well sort of) at a location where no better alternative than DSL or cable is available. You might even want to have a DNS server that attempted to respond with "A" records for that domain name in a fashion that spread the bandwidth usage in an optimized way. Well of course the GnuDIP GUI right now does support anything like this. Do you really want it too? Would anyone provide such a facility as a free public service, or even as a "self serve" for fee service? The item in the "To Do List" to allow an update to a GnuDIP domain name to also update a non-GnuDIP domain name could be expanded, so that more than one GnuDIP domain name could contribute an address to a domain name that has more than one A record. But the client would also have to be far more sophisticated in order to know which GnuDIP domain name was associated with each network card, and send address updates for each card for the associated GnuDIP domain name. The rest could hopefully be handled by manual setup. The only part that really has to be done by GnuDIP is the reporting of IP addresses, unless you are determined to provide an extremely sophisticated "self serve" GUI. === I wonder how many people would ever use such elaborate features? Could you not expect a user with this kind of sophistication to just get a fixed IP address for each DSL and cable connection and handle it all themselves? How much do they expect for free? -- Creighton MacDonnell http://macdonnell.ca/ -- GnuDIP Mailing List http://gnudip2.sourceforge.net/#mailinglist
