Date: Mon, 25 Mar 2002 02:41:20 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brad Knowles <brad.knowles@skynet.be> Cc: Tim <tim@sleepy.wojomedia.com>, Taylor Dondich <thexder@lvcm.com>, chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <3C9EFED0.DB176CB8@mindspring.com> References: <F61GQUEYvZmDvHbYxPo0000a6bd@hotmail.com><20020323002608.B20699@ra <p05101505b8c430e28572@[10.0.1.9]> <000c01c1d3ab$6d2c6960$6600a8c0@penguin> <p05101509b8c47b17d088@[10.0.1.8]> <20020325015236.A97552@futuresouth.com> <p0510150eb8c48ba6b1f4@[10.0.1.8]>
next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote: > Try that with tinydns or dnscache. I was talking about a general > philosophy that Dan applies, not necessarily the specific > implementation found in qmail. Moreover, you still haven't answered > the issue of the size of the configuration file, or the number of > lines required. Can you actually do anything useful with any program > written by Dan in two lines of configuration file? Actually, the IETF group DNSEXT went the rounds with Dan bringing up old issues that had been settled in a way which did not agree with the philosophy of tinydns or dnscache, while I was a member of that working group. The position Dan maintained was that: 1) All DNS servers should be primary (no such thing as a secondary which replicated information off a primary in this philosophy). 2) DNSUPDAT was a nad idea because it required that the DNS server permit updates over the wire. 3) Replication of data between the most primary primary and the other "primaries" was an exercise for the student, and should be handled out of band. The general consensus of the working group was that: 1) DNSUPDAT was needed for certain applications, and in the non-DNSUDAT world, these applications were not possible. 2) Primary and secondary relationships between DNS servers is a good thing, in general, and very useful. 3) The proper way to maintain stores of DNS data is to use the DNS protocol. Lest it be said that I'm also "prejudiced", I strongly disagreed with the workgroup when it came to reverse records for IPv6 stateless autoconfiguration; I felt that it was enough for the normal getpeername/gethostbyaddr & gethostbyname/compare crosscheck to check for spoofed DNS addresses, if one were to permit a local zone update for a foreign machine reverse record, if the forward record matched the local stateless addresss assignment from which the update was coming. In other words, ther are disagreements in any IETF group, but the disagreements between the group and Dan were almost never resolved via compromise (I persoanlly can't think of one case, actually). > With regards to being a general-purpose MTA, sendmail is at the > top of that list, especially with recent improvements that allow it > to be as fast or faster than anything else on the planet. I have to agree. I did the NOC design for the IBM Web Connections product, which was deployed at the IBM hosting facility in Rochester, New York, and sendmail was my first choice, after minor modifications (David Wolfskill was very involved in this as well). Postfix was a second choice, and it's queueing structure was really not amenable to being able to host 50,000 virtual domains on two mail servers, but sendmail could handle it. > With regards to nameservers, there simply is nothing else > publicly available to compare with BIND. I agree again. While we didn't end up using the DNSUPDAT facility, since zone creation in a secondary required mode work than we were willing to spend at the time (zone creation in the primary is a matter of removing a single "if" test; in a secondary, it requires verification of an established security association on the transfer connection, which is a pain in the butt, but doable), we did use bind. It was not a problem to do the updates of the primary and secondary seperately, following an update of the database from which the domain data placed in the configuration files was derived, since there is implicit fail-over support based on having a hierarchical relationship between servers. With Dan's arrangement, the secondary answering in the negative is cached as authoritative, and the dmaon is off the air for at least another 300 seconds (if not longer), as that's the minimum default cache expiration time that most ISPs run on their caching name servers. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C9EFED0.DB176CB8>