DNS Failures

[Mark_Andrews at iengines.com]

> I posted an article a while ago with regards to port 53 on our DNS hanging up
>  
> once or twice a week. Well I believe I have solved the problem, but I would 
> still like to know why? 
> 
> I traced 3 of the failures to a simple DNS request that was submitted using T
> CP 
> rather than UDP. Coincidently, all 3 requests were from different domains for
>  
> the same Domain Name that we host for a client. The requests were not for the
>  
> server itself, and received a negative response. After these requests, port 5
> 3 
> shut down and would not respond to any further requests. All other ports stil
> l 
> responded correctly.
> 
> We were using Version 2.1 of MetaInfo's port of BIND, and NT 3.51 SP5. MetaIn
> fo 
> was of no assistance what-so-ever. Since I had to upgrade the operating syste
> m 
> to be able to upgrade the DNS, I undertook that step first. It has been runni
> ng 
> on NT 4.0 SP3 now for almost 2 weeks and no failures. This is a relatively lo
> w 
> powered machine, and my concerns about resource utilzation proved to be 
> unfounded. Other when operating the server locally, resourse utilization is 
> actually better under 4.0.
> 
> But my real question is why did we suddenly start to have problems after 2 
> years of no problems at all? Why did we suddenly start to see simple DNS 
> requests using TCP? The RFC's strongly recommend using UDP because of the muc
> h 
> better efficiency. Is there some new function or feature that people have 
> started using?
> 
> Any light on the subject would be much appreciated.
> 
> J.A. Coutts
> Systems Engineer
> Edsonet/TravPro
> 
> 

	Because someone said that the UPDATE protocol was insecure,
	which it is without some sort if crypotograhic signatures,
	from there decided that we will try to forge updates and
	distributed a kiddy scripts to do this.

	This neglected the fact that UPDATES are disabled by default.
	So it won't be effective unless you happen to guess which
	addresses have been allowed to perform the update.  BIND 8.2.2
	supports cryptographic signatures for authentication as an
	alternative to IP address based acls.

	Now what happens is these forged updates are rejected and
	a REFUSED message is sent back.  Named then reads EOF on
	the socket and closes it.  However the socket also has a
	linger interval of 120 seconds on it so what is happening
	is that the close pauses for 120 seconds while it waits
	for the linger interval to expire trying to sent the REFUSED
	message.  This is not a problem with real tcp connections as
	the client will have read the answer prior to the close hence
	the linger interval does not come into play.

	Normal operation however does not need the linger interval
	so it has been removed in BIND 8.2.2.  The client is supposed
	to close the connection and it should have read everything
	by then. It was copied over from BIND 4 where is was needed
	for outgoing zone transfers. BIND 4 forks for outgoing zone
	transfers then closes the socket after the final SOA is
	written.  Without the linger outgoing zone transfers were
	being truncated.  

	For this to be a problem you need a IP stack where it is
	easy to forge a connection.

	Mark
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at iengines.com