is this "normal" if not what to do about it?

[Viktor Dukhovni]

On Mon, Jan 26, 2015 at 11:25:58PM -0500, John wrote:

> Thanks for the reassurance.  I was not sure whether there was a problem or
> not. Every test I ran indicated that there was no problem, but being new and
> nervous I thought I should ask.

My only comment on your settings:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45762
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ;klam.ca.               IN SOA
    klam.ca.                SOA     ns0.klam.ca. admin.klam.ca. 2015012610 14400 3600 1209600 3600
    klam.ca.                RRSIG   SOA 8 2 3600 20150226005819 20150126235819 849 klam.ca. <signature>

is that a 30 day signature is at the high end of the sensible range.

However, this is often reasonable for domains that don't have much
of value to protect.  For a domain with more at stake, and a
operations staff that ensures that all secondary servers are always
reasonably current, and signature updates always timely, one might
consider ~7-day signatures rather than 31-day signatures.

Bottom-line, you're fine, you even have working TLSA records:

    klam.ca. IN MX 10 smtp.klam.ca.
    _25._tcp.smtp.klam.ca. IN TLSA 3 0 1 5bf12300255d1475ae43677b7062ab8964ca097ee6096cd005115b8c974e83ab

that match your SMTP server's certificate.  Just don't forget to
add a TLSA record that matches your next certificate a few TTLs
*before* you deploy it.

    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4

After the new cert chain live, you can drop the original TLSA RR,
leaving only the new one in place.

-- 
	Viktor.