Re: DNS ports...

[Jim Dennis <jimd@starshine.org>]

DNS Ports: A bit about Name Resolution Protocols
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> is the following true or false?
 
> a client talks to a nameserver on port 53/tcp.  the nameserver
> answers back on a random udp port greater than 1023.

	It is false.  An FAQ that will answer your question 
	is at:

		http://www.intac.com/~cdp/cptd-faq/section2.html#ports

	... However, I'll also add some detail here.

	First point: normal DNS resolution occurs over UDP.

	The usual sequence for a UNIX client is something like
	this:

	The application executes a call to "gethostbyname()"
	(a standard library function, which is linked into 
	the libc on almost any UNIX platform).  gethostbyname()
	in glibc (Linux libc version 6.x) is implemented to
	look at the contents of your /etc/nsswitch.conf file,
	and apply a set of rules from that to load NSS (name
	services systems) libraries.  Most Linux systems are 
	configured to use libnsscompat.so --- which uses
	NIS/NIS+, DNS and traditional UNIX files (/etc/hosts,
	/etc/networks).  You can see all of the NSS libraries
	on most Linux systems using the command:

		ls /lib/libnss*

	... although you might have to look at the contents of
	/etc/ld.so.conf for a list of other directories in 
	which other libnss libraries might exist.  

	Entries in /etc/nsswitch.conf will refer to these 
	libraries (take the basename of the library file and
	trim off the "libnss" prefix to relate library name 
	to the nsswitch.conf keyword).

	Before I get back to describing the DNS IP protocols
	(you question) I'll mention that all this complexity and
	redirection is actually useful since it allows an admin
	to configure his Linux (or other GNU system) to use
	files, DNS, NIS, NIS+, as well as more obscure Hesiod,
	and new LDAP and NDS naming/directory services without
	having to recompiling any of the standard utilities on
	any system.

	It's also important to realize that the Linux and UNIX
	doesn't have any sort of "resolver daemon" nor is this
	a function of the kernel (a system call or device driver
	or anything like that).  This is just a set of libraries
	to which almost all other applications are linked.
 
	When the system is configured to use DNS (as they
	almost all are) then the library functions open and
	read the /etc/resolv.conf file.  This gives a list
	of DNS servers to which the resolver will direct its
	initial queries.

	The query will by over UDP, with an arbitrary unprivileged
	source port and a destination port of 53 (which is the
	DNS query port listed in your /etc/services file).  

	The initial response should come from one of the DNS servers 
	as listed in /etc/resolv.conf, and be directed back to 
	(have a destination port equal to) the source of the query.
	The source of the response should also be port 53.

	Notice that I mentioned "initial" queries and responses.
	That's because the DNS protocol allows a server to 
	refer the client to some other DNS server.  Thus there
	may be an initial response that amounts to: "I don't
	know, go ask ..."

	Thus the standard packet filtering rules that you're 
	thinking about require one to allow UDP traffic from
	port 53 to any unprivileged port in your domain.

	Naturally this seems a bit too loose.  One approach is
	to have the firewall track outstanding DNS requests
	maintaining a context state and only permitting responses
	back to host/port pairs that have outstanding DNS queries.
	This is call "stateful" packet inspection and it is one
	of the features that distinguishes a "firewall" from a 
	simple "packet filter."

	(Actually I hate to use the term "firewall" because it
	is so nebulous.  However, I have to simplify a bit or
	I can't say anything).

	A better approach is to configure your caching name
	server(s) so they never forward clients to other name
	servers.  Thus you can have one or more "sacrificial" 
	caching nameservers on your perimeter network, allow 
	all DNS traffic to those, and have a set of rules on
	the interior router/packet filters that allows all 
	DNS traffic from those to your hosts.

	This is the architecture I recommend.
	
> i can't seem to find the answer in various o'reilly books.  of
> course, someone walked off with the DNS one.
 
> the reason i ask is that i'm trying to write a cisco access list
> which blocks all traffic to my subnet.  i still want to talk to
> the nameservers though, which are on another subnet.  note: i
> don't even have access to the router.  i'm just trying to make it
> easy for the overworked network guys to put this filter in place.
 
> DNS only seems to work if the following line is in place...
 
> access-list ### permit udp host ip.of.name.server any gt 1023
 
> ---matt

	You could restrict this to require that the packets
	come *from* port 53.

	Implicitly you are trying to use the architecture that 
	I've recommended above.  You're trying to limit the
	DNS traffic that comes into your subnet so that it 
	all comes from a particular name server. 

	Note that this requires that you configure your caching
	name server so that it never "forwards" DNS requests 
	(tells the client to go ask a different server).  This
	is done by configuring the caching name server with
	it's own "forwarders" directive (providing it with a 
	list of some nearby "better connected" nameservers), and
	by using the "slave" directive in BIND 8.x.


	Hope that explains it O.K.  If not you might consider
	posting a more detailed question to "Ask Mr. DNS" at
	Acme Byte and Wire (http://www.acmebw.com/askmr.htm).


--
Jim Dennis,		                  The Linux Gazette "Answer Guy"
Linux Gazette is Published under the GPL     http://www.linuxgazette.com
			    answerguy@ssc.com