No valid IP address found

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: mail.callahtech.com

I ran this command: N/A

It produced this output: No valid IP addresses found for mail.callahtech.com, url: Certificate generation failed.

My web server is (include version): Apache

The operating system my web server runs on is (include version): Not sure (3rd party mail service)

My hosting provider, if applicable, is: mxroute

I can login to a root shell on my machine (yes or no, or I don't know): no

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): DirectAdmin (not sure the version, 3rd party mail service)

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): I believe they are using certbot but not sure.

Ok so a brief description of the problem, I am trying to generate certs for my mail subdomain that has a CNAME record pointed to a 3rd party mail service (mxroute). I use Let's Encrypt for all of my other domains and have for a couple of years with no issues. Every time I attempt to generate certs through mxroute, it fails "no valid IP addresses found". They say it isn't an issue on their end. I also attempted with https://greenlock.domains and encountered the same error which verifies that it can't be an mxroute problem.

Any help would be appreciated.

1 Like
2

What command are you running to get that error? Is it something inside your control panel? Can you maybe include a screenshot of what you're running, if it's not a command-line thing?

1 Like
3

There's something odd happening with your DNS delegations and servers, which I'm guessing is related:

https://dnsviz.net/d/mail.callahtech.com/dnssec/

Errors

  • callahtech.com to mail.callahtech.com: No SOA RR was returned with the NODATA response. (35.231.196.113, 98.213.184.202, UDP_-_EDNS0_4096_D_KN)
  • callahtech.com zone: The server(s) were not responsive to queries over TCP. (35.231.196.113, 98.213.184.202)
  • mail.callahtech.com zone: The server(s) were not responsive to queries over TCP. (35.231.196.113, 98.213.184.202)
  • mail.callahtech.com/SOA: No response was received from the server over TCP (tried 3 times). (35.231.196.113, 98.213.184.202, TCP_-_EDNS0_4096_D_N)

Warnings

  • callahtech.com to mail.callahtech.com: The server responded with no OPT record, rather than with RCODE FORMERR. (35.231.196.113, 98.213.184.202, UDP_-_EDNS0_4096_D_KN)
  • mail.callahtech.com/CNAME: The server responded with no OPT record, rather than with RCODE FORMERR. (35.231.196.113, 98.213.184.202, UDP_-_EDNS0_4096_D_KN)
  • mail.callahtech.com/CNAME: The server returned CNAME for mail.callahtech.com, but records of other types exist at that name.
  • mail.callahtech.com/NS: The server responded with no OPT record, rather than with RCODE FORMERR. (35.231.196.113, 98.213.184.202, UDP_-_EDNS0_4096_D_KN)
  • mail.callahtech.com/SOA: The server responded with no OPT record, rather than with RCODE FORMERR. (35.231.196.113, 98.213.184.202, UDP_-EDNS0_4096_D_KN, UDP-_EDNS0_4096_D_KN_0x20)
2 Likes
4

Most of the errors on that page look to be caused by my name servers not listening on TCP ports (is that even required).

I can use Let's Encrypt for my other domains that run on the same name servers. The only problem is this one specifically.

Edit: Just trying to understand what the problem is here. I'm not 100% sure what you are saying that I should change.

5

Well, listening on TCP is certainly a good idea, though I agree it's probably not the problem here.

"The server returned CNAME for mail.callahtech.com, but records of other types exist at that name." seems really suspect to me, though.

See also the results of Unboundtest, which is configured similarly to Let's Encrypt's own servers:

https://unboundtest.com/m/A/mail.callahtech.com/3X2B2TED

I'm no expert at reading it, but i think it says that your DNS servers are giving no result when queried for your name:

Apr 15 13:30:57 unbound[1289031:0] info: reply from <callahtech.com.> 35.231.196.113#53
Apr 15 13:30:57 unbound[1289031:0] info: query response was nodata ANSWER

I'm hoping that somebody more versed in the intricacies of DNS can step in. The name mail.callahtech.com returns NS records if queried for those, and a CNAME if queried for A/AAAA, and I think that's weird but I may be barking up the wrong tree.

1 Like
6

Hi @johndc7

that's

fatal.

And that's

https://unboundtest.com/m/A/mail.callahtech.com/3X2B2TED

the fatal result.

If you have a CNAME defined, an A-query must return that CNAME, not NoError/NoData.

NoError - all is ok.
NoData - no A record -> Letsencrypt fails.

So your name server software is too old / fatal buggy. Both is bad.

That may not happen, if you don't use CNAME (your other domains). But with CNAME, such a result is wrong.

PS: If a domain name has a CNAME, no other record is allowed (RRSIG and NSEC/3 is possible, but that's not your configuration). So CNAME + other records is always wrong.

3 Likes
7

Ok name servers should be fixed now. I still see no IP address on unboundtest.com. Maybe I need to wait more than 30 seconds after fixing the problem lol

I've been testing with Network Tools: DNS,IP,Email and shows only CNAME records returning for that domain now.

8

That result is buggy, may be a wrong cache of that tool.

Unboundtest doesn't see the CNAME, so Letsencrypt will fail.

1 Like
9

Do you mean unboundtest or mxtoolbox (the one I linked to)? mxtoolbox doesn't cache anything and it queries name servers directly every time.

Is this still an issue on my end? Is there something else that I need to change?

1 Like
10

It doesn't help if you check the MX record, there you see the CNAME.

But checking A or AAAA, the result is empty, that's wrong, if a CNAME exists.

As written: Your name server software is buggy. May be you have edited the zone file manual. The result is fatal.

Compare the output with the unboundtest of my subdomain - A-query with a CNAME-result - https://unboundtest.com/m/A/check-your-website.server-daten.de/A7EM3O2L

;; ANSWER SECTION:
check-your-website.server-daten.de. 0 IN CNAME server-daten.de.
server-daten.de. 0 IN A 85.215.2.226

Same with AAAA.

1 Like
11

If I query the A or AAAA records, I get a CNAME record for every DNS resolver I have tested with except for unboundtest.

Everything should be fine now. I rolled out an update to my name servers that should have fixed this around an hour ago. If I compare the behavior of my name servers to someone else's on cloudflare DNS, it is identical.

1 Like
12

What name server software are you running, and is it up-to-date? I'm still seeing warnings on DNSViz

https://dnsviz.net/d/mail.callahtech.com/dnssec/

mail.callahtech.com/CNAME: The server responded with no OPT record, rather than with RCODE FORMERR. (35.231.196.113, 98.213.184.202, UDP_-_EDNS0_4096_D_KN)

Which makes me think there's some EDNS0 option not working right.

1 Like
13

Tested with unboundtest: No CNAME.

Tested with my local unbound: CNAME.

Tested via nslookup querying your name servers:

D:\temp>nslookup -type=A mail.callahtech.com. ns1.callahtech.com.
Server: ns1.callahtech.com
Address: 98.213.184.202

Name: mail.callahtech.com

D:\temp>nslookup -type=A mail.callahtech.com. ns2.callahtech.com.
Server: ns2.callahtech.com
Address: 35.231.196.113

Name: mail.callahtech.com

D:\temp>nslookup -type=A check-your-website.server-daten.de. ns.inwx.de.
Server: UnKnown
Address: 2001:67c:1bc::104

Name: server-daten.de
Address: 85.215.2.226
Aliases: check-your-website.server-daten.de

Compare it with the last result (CNAME definition of the subdomain, A query, CNAME + ip as result).

Checked with the internal tool of "check-your-website" -> CNAME.

Normally, that ( https://check-your-website.server-daten.de/?q=mail.callahtech.com#comments )

X Fatal error: Nameserver doesn't support EDNS with max. 512 Byte Udp payload or sends more then 512 Bytes: ns1.callahtech.com
X Fatal error: Nameserver doesn't support EDNS with max. 512 Byte Udp payload or sends more then 512 Bytes: ns2.callahtech.com

could be critical. But then Unboundtest would report a ServFail, not an empty result.

So I don't really understand that answer via nslookup and unboundtest.

1 Like
14

My name servers are custom and I use this: GitHub - lsongdev/node-dns: 🌐 DNS Server and Client Implementation in Pure JavaScript with no dependencies.
It is entirely possible that I'm missing something with OPT records. I will check it but I don't think that is what is causing the problem here.

Correct me if I'm wrong but, this is expected since I am using a 3rd party mail service. Authoritative name servers only respond to queries for local zones (my own sites). Since the 3rd party mail service is not one of my servers, I would have to query a resolver to get the IP address which is not the function of an authoritative name server.

C:\Users\John>nslookup mail.callahtech.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    safari.mxrouting.net
Addresses:  2a01:4f8:231:44d7::2
          116.202.117.40
Aliases:  mail.callahtech.com


C:\Users\John>nslookup mail.callahtech.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    safari.mxrouting.net
Addresses:  2a01:4f8:231:44d7::2
          116.202.117.40
Aliases:  mail.callahtech.com


C:\Users\John>nslookup mail.callahtech.com 4.2.2.2
Server:  b.resolvers.Level3.net
Address:  4.2.2.2

Non-authoritative answer:
Name:    safari.mxrouting.net
Addresses:  2a01:4f8:231:44d7::2
          116.202.117.40
Aliases:  mail.callahtech.com


C:\Users\John>nslookup mail.callahtech.com 75.75.75.75
Server:  cdns01.comcast.net
Address:  75.75.75.75

Non-authoritative answer:
Name:    safari.mxrouting.net
Addresses:  2a01:4f8:231:44d7::2
          116.202.117.40
Aliases:  mail.callahtech.com

These are just the ones I could quickly think of.

1 Like
15

The mail.callahtech.com is part of your local zone, your local zone has the definition

mail.callahtech.com CNAME otherdomain.

And if a CNAME exists, every query with mail.callahtech.com must return that CNAME.

Second step: Find the A record of that other domain (or the AAAA / CAA / TXT etc.) if that RR exists.

1 Like
16

That is currently how it works. nslookup just filters that out CNAME records with no resolvable A records unless you use the debug option. It will try to query the value of the CNAME but my name server returns nothing (not a local zone). That second parameter forces nslookup to only use my name server (no recursion like a normal resolver would) which is why it gives you nothing.

C:\Users\John>nslookup
Default Server:  UnKnown
Address:  10.1.2.4

> set debug=true
> mail.callahtech.com ns1.callahtech.com
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        ns1.callahtech.com, type = A, class = IN
    ANSWERS:
    ->  ns1.callahtech.com
        internet address = 98.213.184.202
        ttl = 298 (4 mins 58 secs)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        ns1.callahtech.com, type = AAAA, class = IN

------------
Server:  ns1.callahtech.com
Address:  98.213.184.202

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        mail.callahtech.com, type = A, class = IN
    ANSWERS:
    ->  mail.callahtech.com
        canonical name = safari.mxrouting.net
        ttl = 300 (5 mins)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        mail.callahtech.com, type = AAAA, class = IN
    ANSWERS:
    ->  mail.callahtech.com
        canonical name = safari.mxrouting.net
        ttl = 300 (5 mins)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 6, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        mail.callahtech.com, type = A, class = IN
    ANSWERS:
    ->  mail.callahtech.com
        canonical name = safari.mxrouting.net
        ttl = 300 (5 mins)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 7, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        mail.callahtech.com, type = AAAA, class = IN
    ANSWERS:
    ->  mail.callahtech.com
        canonical name = safari.mxrouting.net
        ttl = 300 (5 mins)

------------
Name:    mail.callahtech.com
1 Like
17

FWIW, this is what Google sees:

Screenshot_20210415-124522_Samsung Internet
Screenshot_20210415-124522_Samsung Internet1440×1111 138 KB

Screenshot_20210415-124535_Samsung Internet
Screenshot_20210415-124535_Samsung Internet1440×1111 143 KB

2 Likes
18

Ok I have been doing some research on this and it does not look like this is mandatory. It seems like many DNS servers support it (like 85%) so it's probably a good thing to have but not required. It also does not seem like the absence of this should cause any problems in this case.

1 Like
19

Maybe, but I think it may be related. The unbound config used by unboundtest as well as Let's Encrypt sets the EDNS Buffer Size to 512.

If I run a "normal" dig trace I get the CNAME back,

$ dig +trace mail.callahtech.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.4 <<>> +trace mail.callahtech.com

[…snip…]

mail.callahtech.com.    300     IN      CNAME   safari.mxrouting.net.
;; Received 90 bytes from 35.231.196.113#53(ns2.callahtech.com) in 14 ms

but if I run a trace with a 512-byte EDNS buffer size I get a timeout:

$ dig +trace +bufsize=512 mail.callahtech.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.4 <<>> +trace +bufsize=512 mail.callahtech.com

[…snip…]

;; Connection to 35.231.196.113#53(35.231.196.113) for mail.callahtech.com failed: timed out.
;; Connection to 35.231.196.113#53(35.231.196.113) for mail.callahtech.com failed: timed out.
;; Connection to 35.231.196.113#53(35.231.196.113) for mail.callahtech.com failed: timed out.
;; Connection to 35.231.196.113#53(35.231.196.113) for mail.callahtech.com failed: timed out.
;; Connection to 35.231.196.113#53(35.231.196.113) for mail.callahtech.com failed: timed out.
;; connection timed out; no servers could be reached
;; Connection to 35.231.196.113#53(35.231.196.113) for mail.callahtech.com failed: timed out.
2 Likes
20

From the link in my last post of why Let's Encrypt uses this setting,

"Authoritative resolvers that return large responses but don’t support TCP would stop working."

I think this describes what's going on for your case.

Taking a quick look at the page you linked of the DNS server you used, there's an issue for improving their documentation of how to run a server that does both UDP & TCP.

So you might want to see if you can configure it to serve on TCP as well as UDP, and you're much less likely for systems to have trouble resolving your name. (Or you may want to switch DNS software entirely, to something more popular for authoritative DNS serving, though I certainly understand that might not be what you're looking to do at this time.)

1 Like