RE: Allowing DNS servers to operate behind NetScreen 500

[David Klein <dklein () netscreen com>]

> From: Ben Nagy [mailto:ben () iagu net] 
>
> Sorry, argumentative this morning...

Sorry, I'm not.  But I will try to at least clarify below ...

 
> ----- Original Message -----
> From: "David Klein" <dklein () netscreen com>
> [...]> > ... Ideally I'd like
> > > something akin to UDP connection tracking, where an outgoing
> > > DNS request installs a time-limited rule which allows the
> > > reply to traverse the firewall in the opposite direction.
> >
> > By default, Netscreens implement a DNS ALG (Appl Level 
> Gateway) to do just
> > this.  However, it will only allow one UDP packet (DNS 
> response) to the
> > original DNS request that went out.  I've seen problems 
> when multiple UDP
> > packets come back to the same DNS request.  Or if the DNS 
> server sends
> > multiple DNS requests to the same IP address without 
> changing the source
> > port for each query.  This will also confuse the DNS ALG.
>
> That doesn't make sense. A proxy doesn't let responses 
> through at all -  it
> "proxies" the connection, maintaining a UDP "connection" 
> itself with the
> "outside" DNS server and another with the DNS "client", using a giant
> "laser". The classic DNS ALG is, in fact, a caching DNS server.


I didn't say it was a "proxy" nor did I say it was a "classic DNS ALG or
caching server".  Without launching into a semantics debate, Netscreen
devices have an internal construct we call a "gate".  This is basically
special code that gets executed when we need to do more then layer 4
stateful tracking.  We call these ALG's (not proxies).  Examples include:

- FTP (e.g., watch the control channel to look for commands opening up data
channels);  
- ping (e.g., match inbound ICMP echo responses to ICMP echo requests that
went out);
- DNS (e.g., match the single UDP response to the UDP-based DNS query); 
- H.323 (a big ugly one);
- etc.

These are not proxies in the classical sense.  You don't program the client
to connect directly to the firewall ala a web proxy or socks paradigm.  We
don't terminate the client connection acting as the server and we don't open
a session to the real server acting as the client.  


> So, is this a real ALG, or is it some UDP plug proxy that knows a few
> state-like rules to deal with packets that look like DNS? (or 
> is it not a proxy at all?)

We would call it a real ALG, however, based on your parlance it's probably
more closer to a UDP plug proxy that knows a few state-like rules.


> > There are a couple of things to try:
> >     set flow allow-dns-reply
> >     save
> > This will allow a dns reply pkt without a matching request.
>
> Is that the equivalent of allowing any incoming UDP from port 53?

Yes, so I don't recommend using it.  It would be better to use the following
...

> > You may also want to try the command:
> >     set dns udp-session-normal
> >     save
> > which should allow for normal UDP handling of DNS packets 
> (i.e., more then
> > one inbound reply packet can match the session setup by the 
> outbound query
> > packet).

Actually, the best thing would be to do some packet captures and
characterize their particular DNS traffic.  Something doesn't sound right.


> We've been over DNS so many times on this list, I really 
> should have it
> burned into my brain, but responses that don't fit into one 
> 512 byte UDP
> packet are supposed to be transmitted with TCP, not 
> transmitted in multiple
> UDP packets, yes? ...

I'm not a DNS expert in the latest server implementation details but if a
DNS system queries another on UDP dest port 53 then I'm not sure how that
server is supposed to respond with TCP.  Is the queried system supposed to
respond with some error message from the original UDP port 53 socket causing
the querying system to re-query on TCP dest port 53?  If so, then our DNS
Gate will function properly.


> ...  Also, I was under the impression that 53 is 
> a legal source
> port for server-to-server queries, whether TCP or UDP. This 
> would mean that
> you would often see packets from the same port to the same 
> external IP. Of
> course a true proxy would have no trouble keeping state in 
> that situation,
> since every request is different...
>
> In any case, it's the responsibility of the proxy to get a 
> response and pass
> that to the client, and if the "only the first packet gets 
> through" theory
> were true then DNS should work, since all the info should be 
> in the first
> packet.


Exactly.


> > Dave Klein
>
> Something don't add up.
>
> ben

Which is why a capture of packets related to this DNS would be good and why
Glenn may want to deal with TAC on this.

Dave Klein
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards