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 /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users