Could not determine the nameserver IP addresses for domain
When attempting to add an addon or alias domain to cpanel our customers have started getting this error only in the last 24 hours. Nothing has changed apart from cpanel updates. I wonder if any others are experiencing this same issue?
Could not determine the nameserver IP addresses for "domain". Please make sure that the domain is registered with a valid domain registrar.
-
Hello, What is set in in WHM>>Server Configuration>>Tweak Settings -> Allow Remote Domains Allow unregistered domains 0 -
In Tweak settings we have the "Allow remote domains" option enabled but "Allow unregistered domains" disabled. Enabling "Allow unregistered domains" is a temporary workaround to this issue but we don't want to enable this permanently. The issue is happening on all our servers suddenly since yesterday. They are on v84.0.16 I assume that cpanel performs some sort of whois lookup to determine the nameservers. I'm guessing that is broken since yesterdays cpanel update. I have checked the cpanel logs and there is nothing related to this issue in there. 0 -
I have the same problem sinse a couple of days, worked fine before but now getting this error message. and I agree: In Tweak settings we have the "Allow remote domains" option enabled but "Allow unregistered domains" disabled. Enabling "Allow unregistered domains" is a temporary workaround to this issue but we don't want to enable this permanently. 0 -
"Allow unregistered domains" is a temporary workaround to this issue but we don't want to enable this permanently.
Are the domains in fact registered? If they are, then yes it is indicative of a bigger issue, if they're not this would be the only way to add the domains.0 -
Are the domains in fact registered? If they are, then yes it is indicative of a bigger issue, if they're not this would be the only way to add the domains.
Of course they are registered.0 -
Of course they are registered.
I wouldn't have a way to know this, and as such have to ask. From your server when you run the following what is the response?/scripts/cpdig domain.tld A --verbose
Are you using NAT routing?0 -
I received 4 reports today with the exact same problem. I tried any other usual ways that is mentioned in the documentation but no luck. Before anything ensure that jwhois is installed by: rpm -qa|grep jwhois
If not, then install it via:yum install jwhois
In my case, it was installed, so I ran a force update on cPanel and everything started working automagically:/scripts/upcp "force
running this command is harmless on production servers.0 -
I have the same problem. changing unregistered domains worked around the problem I installed jwhois. it works. I forced the update. it still did not fix the problem solved it using the workaround, but it's not good to have remote and unregistered domains ON 0 -
I took into account info in this thread and tested one this morning. Jwhois was not installed - I suggest that there is no requirement for this otherwise cpanel updates would install and maintain it. Anyway I installed Jwhois - no difference. I ran /scripts/upcp --force - no difference. This is clearly a bug. It's happening on all our cpanel servers. 0 -
While jwhois may be a solution for some, this isn't a bug per say, right now it looks like some differences in the way the dns resolution works with unbound as opposed to our prior implementation. Can you answer the questions i had asked previously? From your server when you run the following what is the response?
/scripts/cpdig domain.tld A --verbose
Are you using NAT routing?0 -
New Cpanel update v84.0.17 fixt the problem for me! :) Fixed case CPANEL-30549: Fix an issue where nameserver IPs for a zone could not be determined when the namerservers were a on different gTLD from the zone under consideration. so looks like a bug to me 0 -
New Cpanel update v84.0.17 fixt the problem for me! :) Fixed case CPANEL-30549: Fix an issue where nameserver IPs for a zone could not be determined when the namerservers were a on different gTLD from the zone under consideration. so looks like a bug to me
What a puzzling description that is. I wonder why they made changes that would only allow a lookup if the nameservers were on the same domain? It doesn't make much sense. This actually reminds me of another thread I started recently....0 -
some differences in the way the dns resolution works with unbound as opposed to our prior implementation.
What does this mean? Can you elaborate?0 -
New Cpanel update v84.0.17 fixt the problem for me! :) Fixed case CPANEL-30549: Fix an issue where nameserver IPs for a zone could not be determined when the namerservers were a on different gTLD from the zone under consideration. so looks like a bug to me
What does this mean? Can you elaborate?
As I said, there are differences in the way the new DNS resolution library functions (libunbound) as opposed to the custom method we were using before. Any time you use functions like add an addon domain, or run autossl we run DNS resolution with the Perl module DNSRoots - to determine if this is the case I provided that /scripts/cpdig command and requested it be run to determine if there was a response (in the event there is no response there is either a networking or DNS resolution issue) - In the event that it's a DNS resolution issue, then yes, that case would have been referenced. Unfortunately, I didn't have the data provided that had been requested, in order to determine if it's related. libunbound is less tolerant than the previous method we were using but has some added features/capabilities that we were missing previously (a big push was for better recursion) - we discuss this in v84's release notes: Unbound-1.9.5It looks like cpanel started to assume that the server hosting the domain would also be the authoritative nameserver - which is almost never as far as I know.
It's very likely for that one it's related to the same changes - what version of cPanel are you on? What if anything is output when querying using /scripts/cpdig as requested earlier?0 -
There I was thinking a DNS lookup was just a DNS lookup. Who knew it could be so complicated? I'm unable to work out from your reply Lauren, what exactly you're saying here. Is the problem we have been experiencing related to the following case or not? [QUOTE]Fixed case CPANEL-30549: Fix an issue where nameserver IPs for a zone could not be determined when the nameservers were a on different gTLD from the zone under consideration.
I'm sorry that your response isn't clear at all. I think you are saying that you've been using some new functions to perform DNS lookups - and those were not "tolerant" of certain network configurations in use - and so in the latest cpanel update you've tweaked the new functions to be more tolerant of certain configurations? is that right? Can you provide more info about what sort of configurations would be affected by this? As far as I'm aware, for our cpanel servers we are just using stock centos / cloudlinux with no complicated network configuration, along with a standard implementation of your DNS clustering. We've used the same config for over a decade. Can you confirm that this new update will also fix the issue I mentioned in my other thread? I'm sorry I can't provide any details of using the cpdig script and I would advise you not to ask for that sort of information on a public forum.0 -
There I was thinking a DNS lookup was just a DNS lookup. Who knew it could be so complicated?
A lot more goes on behind the scenes when a DNS lookup is performed. I'd implore you to read the libunbound documentation if you want more information on thatI'm unable to work out from your reply Lauren, what exactly you're saying here. Is the problem we have been experiencing related to the following case or not?
As I stated in my last response, as of right now, there has been no way for me to determine that. I've requested you provide the output of a specific command multiple times - based on the output there, I can move in a couple of other directions. While it's possible it's related, I can't tell you that without any knowledge of the system, or the ability to look further into it. There are a large number of issues that could affect the behavior of your server, both related and unrelated to cPanel/WHM and in order to make a determination on we request specific information.I think you are saying that you've been using some new functions to perform DNS lookups - and those were not "tolerant" of certain network configurations in use - and so in the latest cpanel update you've tweaked the new functions to be more tolerant of certain configurations? is that right?
We're using an entirely new library for this which I provided in my last response.Can you provide more info about what sort of configurations would be affected by this? As far as I'm aware, for our cpanel servers we are just using stock centos / cloudlinux with no complicated network configuration, along with a standard implementation of your DNS clustering. We've used the same config for over a decade.
I don't have all of those details. What I am aware of now, by looking at the internal cases is that nameservers existing only in the DNS cluster were experiencing issues, this should have been resolved on the 26th of November, in version 84.0.16, There's an additional case where misconfigured SOA, or NS entries are no longer being tolerated and thus unable to be added, which was resolved in 84.0.16 and the final one that was resolved in 84.0.17 was in relation to addon domains where the nameservers being children of a different gTLD were not able to be added due to the nameservers not being recognized.Can you confirm that this new update will also fix the issue I mentioned in my other thread?
I cannot as of right now, as soon as I'm able to address the other thread I will let you know.I'm sorry I can't provide any details of using the cpdig script and I would advise you not to ask for that sort of information on a public forum.
Thank you for that advice, I stand by being cautious of that information as well, but as stated in our0 -
A lot more goes on behind the scenes when a DNS lookup is performed.
I'd say that the actual lookup process is very simple. It's whatever you are doing "behind the scenes" to apply those lookups to the various cpanel functions that makes the process more complicated. Let me just clarify that the problem here was that the cpanel server was unable to determine the nameservers for any domains during the addon / park process - and that it wasn't in any way specific to our servers. As you can see by this thread alone, others were having the same issue. I think its fair to say this probably affected a lot of your customers. Which is why I was surprised to hear you keep asking me the same irrelevant question...I've requested you provide the output of a specific command multiple times - based on the output there, I can move in a couple of other directions.
According to you, this was to determine whether or not every one of our servers was having a "a networking or DNS resolution issue ". So apart from the question being inappropriate to this thread, you asked me to provide output that would contain sensitive information. I find it rather patronising that you would suggest I wouldn't be aware of a sudden networking or DNS resolution problem across our entire bank of cpanel servers. Don't you think if there was a network issue, we might be aware of that? It certainly wouldn't just affect your software being able to determine nameserver info! I wouldn't post on this forum until I'd exhausted all of our own resources in trying to resolve a problem like this. We maintain our network and our servers very carefully and we only have cause to ask around in various places if an "anomaly" such as this occurs. You could see that suddenly several people were having the same issue, so it's a bit naive of you to suggest were were all having sudden network issues at the same time. It can only have been an issue with your software - and it was. You stated that this problem only affected certain configurations, so I asked you for more information. You said...I don't have all of those details. What I am aware of now, by looking at the internal cases is that nameservers existing only in the DNS cluster were experiencing issues
Can you clarify that? Are you saying that the lookup would fail, when the domain being looked up was within the DNS cluster only - rather than if it was using external nameservers? I don't know if it's just your choice of words above, but you seem to be indicating that the cluster nameservers were the problem (experiencing issues) rather than it being a problem with the lookup process. Surely it would be the other way around? Before you seemed to be trying to suggest that the new software you're using for this was working perfectly but the issue was with the server configuration - so you had to make changes to the software to accommodate (tolerate) those configuration issues. I don't believe there is anything different or unusual about our cluster configuration or our network - so I find what you are saying difficult to believe. This entire problem looks to me like just another oversight during your implementation. You've used new software to perform these lookups differently to before - and you hadn't got it right - mistakes were made (many people like to call these bugs) and then the issues were rectified - problem solved right? You seem to be quite insistent that there were no issues at all with your changes and the problem was in fact related to the way in which we and others have implemented our DNS cluster / cpanel servers. So if you are sticking to that standpoint, I think it's only fair that you provide some insight into exactly what kind of setup might cause this problem? I'd really like to know what we could change or implement differently to make sure we don't have any further losses in service to our customers like this. Obviously it's important to us that we are running our servers within cpanel guidelines to make sure everything runs smoothly. As you seem to be indicating that you had to make specific changes to your software to "tolerate" the way in which we have configured our servers, I think it's vital that you share with us your findings about what circumstances would have caused this problem.0 -
As you can see by this thread alone, others were having the same issue. I think its fair to say this probably affected a lot of your customers. Which is why I was surprised to hear you keep asking me the same irrelevant question...
The question was not irrelevant and I'm sorry that you feel it was, I can assure you, I wouldn't waste either of our time requesting information that was irrelevant if I thought it was. Furthermore, as you can see from the responses in this thread there was more than one cause for the issue.I find it rather patronising that you would suggest I wouldn't be aware of a sudden networking or DNS resolution problem across our entire bank of cpanel servers. Don't you think if there was a network issue, we might be aware of that? It certainly wouldn't just affect your software being able to determine nameserver info!
I sincerely apologize that my response came through to you as being patronizing, I can assure you that it was not my intention. Unfortunately, there are a number of network-related issues that have recently been causing issues, namely with hairpinning (NAT Loopback), this being a case in point that a misconfiguration could go undetected for a long time and suddenly begin to cause issues. My job is to determine the cause of the issue and in order to do that, I need all the relevant information. I hope that you would trust that we have the best interests of our users in mind and might be privy to a wide array of information that is not necessarily available or relevant to you, and in order to determine if it is or not relevant to your situation, we ask the specific questions we do.I wouldn't post on this forum until I'd exhausted all of our own resources in trying to resolve a problem like this. We maintain our network and our servers very carefully and we only have cause to ask around in various places if an "anomaly" such as this occurs. You could see that suddenly several people were having the same issue, so it's a bit naive of you to suggest were were all having sudden network issues at the same time. It can only have been an issue with your software - and it was.
We have no way to know the depth of the investigation you had performed or your level of expertise. I've attempted to approach this issue as we do with all issues in the forums, attempting to gather all relevant and necessary information before we make a determination that the problem is or is not caused by the current suggested issue. I've also provided the
I believe the direction in which you've taken my statements and the direction I've meant them is being confused and I apologize for that if it's on my behalf. Here is what I said:As I stated in my last response, as of right now, there has been no way for me to determine that. I've requested you provide the output of a specific command multiple times - based on the output there, I can move in a couple of other directions. While it's possible it's related, I can't tell you that without any knowledge of the system, or the ability to look further into it. There are a large number of issues that could affect the behavior of your server, both related and unrelated to cPanel/WHM and in order to make a determination on we request specific information.
My intention here is not to tell you that it's your issue or to pass blame, it is to reiterate that I don't feel comfortable telling you the problem you're experiencing is a result of this issue without more information.So apart from the question being inappropriate to this thread, you asked me to provide output that would contain sensitive information.
Again, I'll reiterate my previous statement:Thank you for that advice, I stand by being cautious of that information as well, but as stated in our as follows:
- Fixed case CPANEL-30549: Fix an issue where nameserver IPs for a zone could not be determined when the nameservers were on different gTLD from the zone under consideration.
0
Please sign in to leave a comment.
Comments
18 comments