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
> 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
> |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 |
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
Before ending, I'd like to state the I'm very happy with all the
other functions of delegate. Works very well for me.
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"