[dns-wg] lameness and unreachability

On Wed, May 21, 2003 at 09:39:54AM -0400, Edward Lewis wrote:
> On the APNIC mailing list (sig-dns) a discussion has been begun to 
> try and define the problem needing to be solved (assuming there is 
> one).  I'm not sure that the discussion should be mirrored here, but 
> I wanted to call attention to those interested.
> 
> List info -
>    List-Id: APNIC SIG on DNS issues <sig-dns.lists.apnic.net>
>    List-Archive: <http://www.apnic.net/mailing-lists/sig-dns/>
> 
> Before spouting too much on my own here, what is the topic that needs 
> to be discussed(on this mailing list)?
> 
>    ...what RIPE defines (or should define) as a problem delegation?
>    ...a means to measure the health of the DNS delegations?
>    ...how ccTLDs go about testing delegations?
>    ...what responsibility a registry has in publicizing their test criteria?
> 

Here is the list of tests available in the ZoneCheck v2 tool,
with the severity (Fatal/Warning) that are used in the configuration
file to check domain in .fr before accepting the delegation.

Severity             Test
Fatal/warning
        zone transfer possible
 	zone transfer contains data
 	zone transfer contains valid labels
F	check if server is really recursive
F	double dash in domain name (pre-IDN)
F	dash ('-') at start or beginning of domain name
F	illegal symbols in domain name (RFC1034)
F	correctness of given nameserver list
F	given primary nameserver is primary
W	ICMP answer
W	nameserver addresses are all on the same subnet (RFC2182)
W	address shouldn't be part of a bogon prefix
F	identical addresses
F	address in a private network (RFC1918)
W	nameserver's addresses on same subnet (RFC2182)
W	loopback delegation (RFC1537)
F	loopback is resolvable (RFC1537)
F	hostmaster email address is valid
F	hostmaster MX is not an alias (RFC974)
W	delegated domain is not an openrelay
W	domain of the hostmaster email is not an openrelay
F	'postmaster' email address is valid (RFC1123)
F	MX record present (RFC1912)
F	MX authoritative answer
F	MX is not an alias (RFC1912)
F	MX can be resolved
 	absence of wildcard MX
F	MX syntax is valid for an hostname
F	coherence between MX and ANY records
F	NS record present
F	NS authoritative answer
F	NS is not an alias (RFC1912)
F	NS can be resolved
W	Nameserver IP reverse
F	NS name has a valid domain/hostname syntax
F	coherence between NS and ANY records
F	one nameserver for the domain (RFC2182)
F	root servers list present
W	root servers addresses identical to ICANN (RFC2870)
F	root servers list identical to ICANN (RFC2870)
F	at least two nameservers for the domain (RFC2182)
F	SOA record present
F	SOA authoritative answer
F	coherence of master with primary nameserver
F	coherence of serial number with primary nameserver
F	illegal characters in SOA contact name (RFC1034)
F	missused '@' characters in SOA contact name (RFC1034)
F	SOA 'expire' at least 7 days (RFC1912)
F	SOA 'expire' at least 7 times 'refresh'
W	fully qualified master nameserver in SOA
F	illegal characters in SOA master nameserver
W	SOA 'minimum' less than 3 hours
F	SOA master is not an alias (RFC1912)
W	SOA 'refresh' at least 6 hours
W	SOA 'retry' at least 1 hour
F	SOA 'retry' lower than 'refresh' (RFC1912)
W	serial number of the form YYYYMMDDnn (RFC1912)
F	coherence between SOA and ANY records
F	TCP connectivity (RFC1035)
F	UDP connectivity (RFC1035)


Now if we could create such kind of list, to check the "good
health" of a domain and have people using it as a reference
(ie: RIR, TLD, and implemented in the various zone checking tools),
it would be a major step forward.

Several list should be created as you don't perform the same 
check for arpa, tld and other domains.

Also you certainly want to have some control on the level
of checking that should be performed from an
"authoritative answer for SOA and NS records" to a full checking
including tests of mail delivery for hostmaster, postmaster, ...
This could lead to the creation of sublists.

Perhaps in a first time could we try to agree on a minimal list
of items to check for a domain.

-- 
Stephane D'Alu -- AFNIC
http://zonecheck.nic.fr/v2/          The zone checking tool