Utilising private EDE error codes to provide finer granularity to DNS UPDATE responses

[johanix]

• Add support for private EDE codes to the code base
• Set a suitable EDE code on select error responses in parent (for delegation synchronization case).
• Set a suitable EDE code on select error responses in auth server (for updates to auth zone data).
• Check for EDE messages in UPDATE responses and sore them in a suitable structure
• Present EDE data when relevant.

[johanix]

This mostly works fine. However there is presently a strange problem where adding an EDE in the failure path of zd.TrustUpdate(). This code (in tdns/updateresponder.go) works fine:

if zd.Options["frozen"] {
	log.Printf("UpdateResponder: zone %s is frozen (i.e. updates not possible). Ignoring update.",
		zd.ZoneName, qname)
	m.SetRcode(r, dns.RcodeRefused)
	AttachEDEToResponse(m, EDEZoneFrozen)
	w.WriteMsg(m)
	return nil
}

But this code (later in the same function) cause a FORMERR in the receiving client end:

err = zd.TrustUpdate(r, dur.Status)
if err != nil {
	zd.Logger.Printf("Error from TrustUpdate(): %v", err)
	m.SetRcode(m, int(dur.Status.ValidationRcode))
	AttachEDEToResponse(m, EDESig0KeyKnownButNotTrusted)
	w.WriteMsg(m)
	return err
}

[johanix]

The FORMERR is apparently a result of having more than one OPT in the additional section. Not yet clear how that happens.