Hi! Sorry, took a while to answer your mail 'cause I caught the flu and was out of office for a few days. > |Zone transfers (AXFR's) become neccessary when you host your DNS > |master servers behind a Delegate proxy - which I intended to do. > |I ended up with doubling each proxy with a tcprelay for DNS. > |That worked (also I retreated from this configuration for other > |reasons inherent in the DNS protocol which ist *not* proxy > |friendly!). > > Could you show me the reason why tcprelay is not good for AXFR relay? > I personally have not encountered a situation where DNS over TCP is > necessary. It is the reason why it has not been implemented. Sure, tcprelay is all right for AXFR's, but this changes the proxy policy. When using DNS proxy, the traffic is forwarded at application level, while using tcprelay forward at transport level. Furthermore, yes I know of cases where regular DNS is run over TCP. Yes, its pathologic (overly large query) but a real world example. Caused a friend of mine to send a nice evening debuging the firewall rules ... > > |Second I would appreciate if Delegate could do name resolution by > |itself, so it could act as an outbound proxy without the help of > |another resolver. This would do away with the need of a separate > |bind instance (or alike) on the proxy or a separate host on the outside > |(or you would have to rely on you ISP dns ...). > > DNS-DeleGate can reads hosts file (or NIS hosts) to provide the data > to DNS clients. You can specify any hosts file other than /etc/hosts > as RESOLV="file:/path/of/hosts". Not only A record, also it can serve > MX record by defining "-MX.hostname xx.xx.xx.xx" in hosts file. I know, but this does not catch the problem. I have the following setup: +-------------+ | delegate | outside -----(hme1)-| based proxy |-(hme0)----- inside | host | +-------------+ ! (hme2) ! DMZ This is a Sun netra t1 running Solaris9 with SunScreen packet filter. Philosophy is that every service is proxied, if possible by delegate (to keep confiuration coherent). Thus if a bind is running in the DMZ as planed originaly, and it uses a dns-delegate to talk to the outside, this delegate either has to do name resolution itself or has to ask someone else. So I ended up running another bind on the proxy host, listening on the loopback address only and acting as a resolver for the dns-delegate. All this got just a little bit too complicated for debuging, so to catch my deadline I had to move the bind from the DMZ to the proxy host, which is clearly not a good choice. But it would have worked, as I learned later the problem was another. But following the original plan, I had delegate proxying on six (!!) ports (I have a seperate instance of delegate on each port for ease of maintenance, works well) one acting as DNS proxy and one as tcprelay on each interface plus the extra bind instance for resolution. > > So far, the policy of DNS-DeleGate is to be as simple as possible in > its implementation and configuration, while satisfying minimum > functionality for common usage. > I'm rather conservative about what should be extended to it because, > of course, there are complete implementations of DNS server in the > world if complete solution is necessary. While I hoope you will consider extending dns-delegate to service TCP for covering the pathological cases and AXFR's and the RFC, I admit that a full blown resolver adds quite a lot code. Perhaps it would be an option sein one of the available resolver libs with a litte adaption. Before ending, I'd like to state the I'm very happy with all the other functions of delegate. Works very well for me. Best regards Olaf -- Olaf Püschel, Softwaretechnik, OLMOS Workstations GmbH, Germany Wolfenbütteler Str. 31A, 38102 Braunschweig, Fon.: +40-000-00000-F Fax: -99 OLMOS supports signed and/or encrypted mail. Grab my key at www.keyserver..net "Unix *is* user friendly. It's just a bit picky about its friends"