Using TCP for checking

[Mark Elkins]

I'm involved in the CO.ZA Registry. In the process of registering a
domain name in the co.za zone - we do a bunch of DNS checks using
'dig'. 

for each nameserver, 
  a) check that the zone exists (fetch the SOA), 
  b) fetch the NS RRSet count and compare entries.
  c) if Nameserver inside the domain being registered (glue needed)
    i) check the reverse glue (can be multiple v4 + v6 addresses)
    ii) check each reverse has a forward


Currently - many of these (dig-9.4.1) checks include the flags +time=9
+retry=5..

..the assumption being that for any 'dig' action - try, timeout 9
seconds - repeat another 5 times... - so a totally failed lookup would
take 54 seconds... however - an ethernet trace/dump seems to indicate
queries go out one after the other - with little inter-query delay..

If we do a lookup with UDP - a low but significant number of 'digs' fail
- which results in our checks failing - and the registration checking
process delaying that particular registration for a few hours.

If we switch to using TCP for 'dig' lookups  - the failure rate
basically disappears to Zero. This would result in happier customers
(less registration delays).

I've always been taught (and teach others) to use UDP and not TCP for
DNS queries - but in the case of a registry checking for info like we do
- would it not be politically correct to instead do TCP checks?

What does the net-dns wisdom say?

My current thought is to do a UDP check (don't change timeout/retry from
default) and only if that fails - retry immediately with a TCP Check.
Others in my group are for using TCP immediately.

-- 
  .  .     ___. .__      Posix Systems - Sth Africa.  e.164 VOIP ready
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496