Please remember to reply to the mailing list, not the original sender: http://gnudip2.sourceforge.net/#mailinglist
+++++++++ Creighton MacDonnell wrote: > I also don't like seeing page after page building up in > the browser stack (on the "Back" button) I don't like that behavior either, but I can live with it. > [...] and I wanted to avoid Javascript as much as possible Agreed. > Since you seem to have some experience (with Perl?), perhaps you would > like to get involved in maintaining GnuDIP? This could be your first > GnuDIP project. Heh. I was afraid that was going to be the answer. :) Sure, if you wouldn't mind addressing the MX issue when you get the chance (no rush, I've just put on my web pages "don't use secondary MXes, they're broken"), I'll put the "back to the top" button on my stack. How soon I get to it will depend on how much it annoys me compared to other things I have on my plate. As far as the experience goes, I am a very experienced UNIX systems programmer (>10 years), and have been programming in general for about 17 years. I have good perl4-ish skills, but tend to avoid object oriented perl5-isms, so I'd say only intermediate in that area. I don't do Windows. > I don't understand what you mean. When you enter a mail exchanger, it > will show on the response screen You're right, it does. I think I was seeing a caching issue. > Yes. There is a problem with the priorities. I am sure I had this right > to start with!!! I suspect the blocks where you're first checking for an mx entry, then a backup mx entry just have to be flipped in order and made into an if-elsif instead of an if-if. However, I've not tested that. > The design is that only one "foreign" MX can be specified. I don't understand the concept of a "foreign" MX here. What do you mean by that? And are you referring to the design of GnuDIP or the DNS dynamic updates protocol? (The latter with which I as yet have only passing familiarity -- my own package predated dynamic updates). > But as I have said, I have little interest in adding new features. > Again would you like to? Depends on whether you would classify what I'm looking for as a weird agenda :) My operating environment is BIND 9 and Apache. If I were to get involved, some of they key things I would be looking for are: - permitting a single update to affect multiple hosts (which I believe is already on your wish list) - 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 realize that these would almost certainly involve a change to the on-the-wire protocol and thus would have to be planned with backward compatibility in mind. My own package (which I am abondoning) permitted the update of entire zone files for selected subdomains, but the fact is that I was the only person ever to use it (in support of a split DNS). That, combined with "views" that have been introduced to BIND make me consider this to be a feature that is no longer required, so you need not worry about me trying to add *that* feature ... My timeline for doing changes like the above would probably be sometime in the next few months rather than the next few days or weeks. In other words, they're something that I want rather than something that is keeping me from having a working system. -- Devin Reade <[EMAIL PROTECTED]> -- GnuDIP Mailing List http://gnudip2.sourceforge.net/#mailinglist