DNS lookup failure MX for yandex.com

[girish]

@d19dotca In the logs, I see dnssec status: not expected. Can you try disabling DNSSEC?

https://www.nlnetlabs.nl/documentation/unbound/howto-turnoff-dnssec/ . Can just add val-permissive-mode: yes in the unbound config.

https://dnssec-analyzer.verisignlabs.com/gov.bc.ca confirms the domain has some DNSSEC errors.

[d19dotca]

@girish I tried this, restarted the unbound server after adding that parameter to /etc/unbound/unbound.conf.d/cloudron-network.conf, but my host commands still fail with the exact same thing.

Current config values:

server:
        port: 53
        interface: 127.0.0.1
        interface: 172.18.0.1
        do-ip6: no
        access-control: 127.0.0.1 allow
        access-control: 172.18.0.1/16 allow
        cache-max-negative-ttl: 30
        cache-max-ttl: 300
        val-permissive-mode: yes

Ran the restart command, but still seems to fail.

[girish]

@d19dotca I am afraid I have to debug on your server to help further then. Can you drop a mail to support?

[d19dotca]

@girish Sent the email from the server's support page and allowed remote access for you. Thank you so much in advance, Girish! Very odd issue, I'd love to know what's going on there.

For what it's worth, I tried changing verbosity to 2 and logging the queries, and it seems my host commands now come back with SERVFAIL error, where-as before it came back with nothing outside of what's noted earlier. Not sure if that's progress or not, haha. I've gone ahead and set it back, so it's not verbose right now.

Here's what I got recently though after making that change for the verbosity to 2:

host -t NS gov.bc.ca 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

Host gov.bc.ca not found: 2(SERVFAIL)

[girish]

Trying to debug this further now. I cannot make much sense of the unbound logs. So, I wrote a simple node script to do DNS queries:

#!/usr/bin/env node

'use strict';

const { Resolver } = require('dns').promises;
const resolver = new Resolver();

(async function () {
    try {
        const nameservers = await resolver.resolveMx('the.domain');
        console.log(nameservers);
    } catch (e) {
        console.log('Exception when looking up name server: ', e);
    }
})();

I get:

Exception when looking up name server:  Error: queryMx ESERVFAIL the.domain
    at QueryReqWrap.onresolve [as oncomplete] (internal/dns/promises.js:169:17) {
  errno: undefined,
  code: 'ESERVFAIL',
  syscall: 'queryMx',
  hostname: 'the.domain'
}

So, it's not an unbound issue but a general network issue. Trying to see what else we can try here. Of course, replacing the.domain with something like cloudron.io works. So, it's the network connectivity between the nameservers of this specific domain.

[girish]

Turns out the above is not a good way to test recursive resolve because internally it uses nsswitch.conf and resolv. So, bns module:

const bns = require('bns');
const {RecursiveResolver} = bns;

const resolver = new RecursiveResolver({
  tcp: false,
  inet6: true,
  edns: true,
  dnssec: true
});

// Use default root hints and trust
// anchors (see lib/hints.js).
resolver.hints.setDefault();

resolver.on('log', (...args) => console.log(...args));

(async function () {
await resolver.open();

const res = await resolver.lookup('the.domain.', 'MX');
console.log(res.toString());
})();

This fails because there is no UDP response from the name severs. I am creating a server in OVH canada to see if this some networking issue with that server or some general OVH issue.

[girish]

Can confirm that it works on a OVH sever in BHS5 region. I think the best bet is to change the server IP.

[d19dotca]

@girish Ah that's fair enough. Thanks Girish. I will try to make that move as soon as I can.

I will likely move away from the OVH VPS to the OVH Public Cloud instances instead (I used to have those but found the VPS's a bit more performant but only slightly and now I'm running into some unforeseen extra costs for the VPS which makes me think the Public Cloud was actually the better option for me).

So I'll make that change as soon as tonight or else later this weekend and will let you know. Thanks so much for the hard work!

[d19dotca]

I migrated my server tonight to BHS5 region in OVH and it worked successfully sending mail to that domain now. So I suppose that issue is resolved and was more of a general network issue at OVH. Thanks for the guidance, Girish.

[scooke]

@d19dotca What a read!