ESA DKIM tempfail key query timeout hotmail/sharepointonline/outlook

[Beheer tno-netwerk]

Hi,

all mail from Microsoft cloud domain generate a DKIM error: tempfail key query timeout

It works fine for most other domains.

Errors for:

(d=hotmail.com s=selector1 i=@hotmail.com)

(d=sharepointonline.com s=selector1 i=@sharepointonline.com)

(d=outlook.com s=selector1 i=@outlook.com)

(d=live.com s=selector1 i=@live.com)

The TXT records all resolve via a CNAME to the same TXT record (selector1._domainkey.outbound.protection.outlook.com)

Key length is 2048 which is allowed in the verification profile

Anyone an idea why?

Thanks,

Jacco

[Beheer tno-netwerk]

It seems to be a DNS resolving issue.

On the ESA:

dig txt selector1._domainkey.outbound.protection.outlook.com

gives a SERVFAIL from local resolver (127.0.0.1)

dig txt selector1._domainkey.outbound.protection.outlook.com @x.x.x.x (the configured DNS resolver)

gives the correct response (NOERROR)

[Borje Bremnes]

Anyone have a solution for this problem? As far as I can see there is a bug in ESA when the DKIM key length is 2048. Seems to get a "DKIM: tempfail key query timeout". When key length is 1024 everything works. Tried dig on the ESA and it just times out when trying to resolve dns records with key length 2048. And the same records works perfectly in mxtoolbox.com

Best regards

Borje

[SriramV]

can you try using public DNS (e.g. 8.8.8.8) ?

[Borje Bremnes]

If i specify name server in with dig then it works. Also with the name servers in my list.

dig txt selector2._domainkey.domain.com --- connection timed out; no servers could be reached (when key=2048)
dig txt selector2._domainkey.domain.com - works (when key=1024)

dig @8.8.8.8 txt selector2._domainkey.domain.com - works

but
dig @original.dns.server txt selector2._domainkey.domain.com - works also

Best regards

Borje

[SriramV]

Looks like this is a issue from Gateway side, request to rise a TAC case for more investigation 

[Borje Bremnes]

Ok, thanks. Will do that.

Best regards

Borje

[heiko_]

Dear Borje,

did you receive feedback from Cisco TAC regarding this issue and what is the recommendation?

I am asking because I am facing the same issue with some domains (i.e. yahoo.com).

I raised a case at cisco TAC and they recommended to add alternate DNS server for the affected domains, which is not practicable in my opinion. I am wondering if it makes sense to use caching resolving server instead of DNS root server generally.

Best regard,

Heiko

[Borje Bremnes]

Hi

Yes, I had TAC look into it. The problem we had was that the firewall guys had only opened udp/53 and not tcp/53. For large keys the system will automatic switch to dns over tcp. Everything worked after the firewall guys also opened tcp/53 for dns.

Best regards

Borje