RE: DNS Records

• Previous message: Burton M. Strauss III: "RE: network segment range which NIDS can detect?"
• In reply to: Anders Reed Mohn: "Re: DNS Records"
• Next in thread: Alberto Cozer: "Re: DNS Records"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "'Anders Reed Mohn'" <anders_rm@utepils.com>, <security-basics@securityfocus.com>, <CharlieW@netarch.com>
Date: Thu, 19 Jun 2003 20:35:00 -0400

  Prot Src Dst Use
  udp 53 53 Queries between servers (eg, recursive queries)
                                  Replies to above
  tcp 53 53 Queries with long replies between servers, zone
                                  transfers Replies to above
  udp >1023 53 Client queries (sendmail, nslookup, etc ...)
  udp 53 >1023 Replies to above
  tcp >1023 53 Client queries with long replies
  tcp 53 >1023 Replies to above

Note: >1023 is for non-priv ports on Unix clients. On other client types,
the limit may be more or less. In other words, if you lock down all but port
53 TCP/UDP you will find that the DNS server is speaking just fine to
everyone, but your DNS clients cannot hear answers even though the query has
been sent out on 53, the answer has come back somewhere above 1023. BIND 8.x
no longer uses port 53 as the source port for recursive queries, nor uses it
as the destination port for corresponding replies. By default it uses a
random port >1023, although you can configure a specific port (and it be
port 53 if you want).
Another point to keep in mind when designing filters for DNS is that a DNS
server uses port 53 both as the source and destination for its queries. So,
a client queries an initial server from an unreserved port number to UDP
port 53. If the server needs to query another server to get the required
info, it sends a UDP query to that server with both source and destination
ports set to 53. The response is then sent with the same src=53 dest=53 to
the first server which then responds to the original client from port 53 to
the original source port number.

The point of all this is that putting in filters to only allow UDP between a
high port and port 53 will not work correctly, you must also allow the port
53 to port 53 UDP to get through.

Also, ALL versions of BIND use TCP for queries in some cases. The original
query is tried using UDP. If the response is longer than the allocated
buffer, the resolver will retry the query using a TCP connection. If you
block access to TCP port 53 as suggested above, you may find that some
things don't work.

Newer version of BIND allow you to configure a list of IP addresses from
which to allow zone transfers. This mechanism can be used to prevent people
from outside downloading your entire namespace.

http://screamer.mobrien.com/Manuals/MPRM_Group/dns_notes.html

http://lyris.iislists.com/articles/dns_for_iis.htm

http://www.microsoft.com/windows2000/techinfo/howitworks/communications/name
adrmgmt/w2kdns.asp

 
_____________________
Dave Kleiman
dave@netmedic.net
www.netmedic.net

"High achievement always takes place in the framework of high expectation."
Jack Kinder

>Yes it is possible if you allow any host(ip address) to do zone
>transfers. Most name server daemons allow you to specify what hosts you
>want to allow to request transfers, and block all others. You can also
>block TCP port 53, and only allowing UDP port 53 with an ACL or
>Firewall ruleset. I do both.

Careful.. blocking TCP 53 might break certain Microsoft-sw DNS lookups.
Apparently, Exchange, IIS and other MS software has a tendency of using TCP
53 for their DNS queries. (Requests too large for a UDP packet)

You're also breaking the RFC (1035), which specifies that both TCP and UDP
should be left open.

Cheers,
Anders :)

---------------------------------------------------------------------------
Evaluating SSL VPNs' Consider NEOTERIS, chosen as leader by top analysts!
The Gartner Group just put Neoteris in the top of its Magic Quadrant,
while InStat has confirmed Neoteris as the leader in marketshare.
     
Find out why, and see how you can get plug-n-play secure remote access in
about an hour, with no client, server changes, or ongoing maintenance.
          
Visit us at: http://www.neoteris.com/promos/sf-6-9.htm
----------------------------------------------------------------------------

• Previous message: Burton M. Strauss III: "RE: network segment range which NIDS can detect?"
• In reply to: Anders Reed Mohn: "Re: DNS Records"
• Next in thread: Alberto Cozer: "Re: DNS Records"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]