I appreciate your help on this.
I have visited http://dnsviz.net, rerun the analysis, and followed the
DNS tree from root to leaf. I see this:
DNSKEYalg=8, id=203262048 bit
DNSKEYalg=8, id=21342048 bits (secure)
DSdigest alg=2 (secure)
DNSKEYalg=8, id=21342048 bits (secure)
DNSKEYalg=8, id=354331024 bits (secure)
DNSKEYalg=8, id=378522048 bits (secure)
DNSKEYalg=8, id=206491280 bits (secure)
mx31.harte-lyne.ca/A (secure)
Responses for mx31.harte-lyne.ca/MX
Name TTL Type Data Status Returned by
dns01 dns02 dns03 dns04
RR count (Answer/Authority/Additional) OK 0/4/1 0/4/1
Response size (bytes) OK 606 606
Response time (ms) OK 22 37
To me it seems that DNSSEC is working for us. What is it in the
report that tells you it is not?
We are changing our nameserver IP addresses at our remote location
(DNS02 [216.185.71.133] and DNS04 [216.185.71.134]). We are at the
same time reconfiguring the services themselves. I do not know if
this is having any impact on these problems but if it is then it is
not likely that this will be resolved today.
Thank you for your assistance. I am clearly missing something that is
obvious to you and I would appreciate it very much to find out what
that is.
On Thu, November 8, 2018 10:17, Viktor Dukhovni wrote:
>
>> On Nov 8, 2018, at 10:01 AM, Viktor Dukhovni
>> <postfix-us...@dukhovni.org> wrote:
>>
>> My analysis is that some of upstream providers have broken DNSSEC
>> implementations that don't handle NSEC3 properly or at all, and
>> therefore "authenticated denial of existence" is not working for
>> your domain.
>>
>> If the problem is still unresolved your choices are:
>>
>> * Try switching to NSEC. Delete "NSEC3PARAM" and re-sign
>> the zone.
>>
>> * Find a more competent DNS provider
>>
>> * Temporarily disable DNSSEC (remove the DS records at .CA)
>> until the problems with denial of existence are resolved.
>>
>> If DNSSEC is desired, but not critical, I'd do the last first,
>> then try either or both of the first two, until the nameservers
>> respond correctly with appropriately signed NSEC or NSEC3
>> records for queries that return NoData and NXDdomain.
>
> And the problem does appear unresolved (link is to analysis at a
> specific time, so won't change when the issue is actually resolved):
>
> http://dnsviz.net/d/mx31.harte-lyne.ca/W-RStQ/dnssec/?rr=15&a=all&ds=all&doe=on&ta=.&tk=
>
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
Do NOT open attachments nor follow links sent by e-Mail
James B. Byrne mailto:byrn...@harte-lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
