Re: Last WG call for draft-ietf-dnsop-root-opreq-02.txt.

[Mark_Andrews@iengines.com]

> >> i probably am forgetting something significant in some relevant document,
> >> but how is end of line encoded in a zone file?  if one is to compare hashe
> s,
> >> either the hash must ignore line ends (which might offer a security
> >> vulnerability) or there must be a common understanding of the value of a
> >> line end.
> > If using email, I'd suggest sending a complete zone file and signing it.
> > Sidesteps the issue by pushing it down to the MIME level.
> 
> the problem is that i am comparing the hash of the emailed zone file with
> the hash of the zone file as stored on my system.
> 
> > Apart from that, see the Content-MD5 RFC (RFC 1864) for some discussion
> > and a possible way to do it (mandate CRLF *for calculating the checksum*).
> 
> this is what i expected to find, a canonic representation of line ends in a
> zone file in an axfr, in 1034-5.  i did not find it.
> 
> randy

	The master file format doesn't need to know how end of line is
	represented.  It just needs to know where it is.

	All this however is irrelevent to verifing you have a valid root
	zone, specially when it has been AXFR'd.  

	Comparing straight md5 checksums of what BIND has written to disk
	with the original master zone file will never work.  What is
	needed is a tool that takes a master zone file, make it cannonical
	and then produces (several different) checksums.

	What we care about is that the data had remained in tact.  Not
	whether we used one or two spaces between fields, or whether 
	case has been preserved in domainnames.

	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@iengines.com