Re: Bogus nic.fr behavior

[Bill Manning <bmanning@zed.isi.edu>]

% > 	One finds that UDP is insufficent when dealing with 
% > 	some of the newer, standards track RR types. Prudent
% > 	SOP would ensure that TCP is mandatory ..for operations..
% > 	even though the specifications lag.
% > 
% > --bill
% 
% 	It may be prudent, should be warned about, but should not
% 	stop a delegation proceeding.
% 
% 	Mark
% --
% Mark Andrews, Nominum Inc.

	So..  I should encourage you to support TCP, warn you that
	I'm going to use standards track RR's that have known UDP
	problems and instead of making it a mandatory component of
	the delegation process, I should let the delegation proceed
	and then I'll spend -weeks- debugging the problems that 
	will occur.  No thank you.  Nip that problem in the bud
	before it eats my spare time.  
	
For a real life example...


Feb  7 01:51:11 flag named[16246]: refresh_callback: zone cairn.net/IN: truncated UDP answer, initiating TCP zone xfer 38.245.76.15#53

	Now what happens if I turn off TCP on flag?  No zone, I'm lame,
	and I claim its not my fault since TCP was not made mandatory
	at the time of delegation.  Granted, this is a research project
	but if, say Microsoft did not mandate its slaves supported TCP
	and it started using RRs that exhibit the same bahaviour as the
	cairn.net domain, then its slaves would all go "deaf" and it
	might want to seek some remedy.

	Operationally, I'm with FR nic on this. TCP is a mandatory
	precondition before I'll delegate.

--bill