DA license issue

pixGT

Verified User
Joined
Feb 3, 2020
Messages
149
1729609267484.png


I'm getting this error. Please give me a solution for this.
 
I'm getting this error. Please give me a solution for this.
Use the suggestions in the notice.
So check your /etc/resolv.conf because licensing servers are multiple with other ip's.

And see what the "dig" command provided will give as result.
 
[root@ds ~]# dig

; <<>> DiG 9.11.36-RedHat-9.11.36-16.el8_10.2 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 44968
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2c162b998db2a47a60bd029f671863efac93223c051f3006 (good)
;; QUESTION SECTION:
;. IN NS

;; Query time: 1 msec
;; SERVER: 124.43.76.178#53(124.43.76.178)
;; WHEN: Wed Oct 23 08:18:15 +0530 2024
;; MSG SIZE rcvd: 56

[root@ds ~]#
 
# Generated by NetworkManager
search ds.xxxx.us
nameserver 124.43.XX.XXX

My Correct IP is there.
 
[root@ds ~]# dig
That was not the command suggested. Use the command from the error notice. That is the way to see if the licensing servers are correctly reachable from your server.

If 124.43.xx.xx is your ip, then your /etc/resolv.conf is a bit off. If you want to use your own server ip then use 127.0.0.1 instead. Als I would suggest to add an external resolver like cloudflare, I would suggest to do it like this if 124.43 is your server ip.

Code:
search ds.xxx.us (or just leave out this line)
nameserver 127.0.0.1
nameserver 1.1.1.1
nameserver 8.8.8.8

Also.... you blocked your lookup requests. Seems you're not using the default Directadmin named.conf file.
;; WARNING: recursion requested but not available
Fix it by adding this line to your named.conf file under the "options" tag.
allow-recursion { localhost; localnets; };

Then try again the correct full dig command from the error, not just dig.
 
I would strongly recommend against using Bind on your localhost as a resolver, unless it is in fact *only* a resolver (i.e. not the master for any zones). You might end up in a situation where your local Bind returns the wrong lookup information for a zone that you are not authoritative for (e.g. domain moved away but not yet deleted from your server).
 
(e.g. domain moved away but not yet deleted from your server).
That might be the only downside of it, if you could call that a downside. And in fact, if that happens, I always verify with both server and a home isp nslookup. It doesn't matter a lot since mostly you don't use your customers company's. And if you do, at least you will fix your mistake.

Benefit of using localhost as a resolver is that you do not run into issues like with Spamhaus which now tend to block open resolvers like Google and Cloudflare. Especially since a lot of vps providers do not provide a decent resolver.

Other benefit is that you are independent of external DNS, so lookups mostly go faster and you can see in your own logs what happens.

So there are pro's and con's for both methods. I worked with localhost resolves since I started my company and never had issues with it, except once on trying Debian 11 on a VPS which for some reason did not like 127.0.0.1, had to do something to fix that.
But on all RH alike never a problem.

So I would strongly recommend to check pro's and cons and everybody make a decision for themselves.
 
@Richard G

The issued will cause when customer using external dns manager like cloudflare and you have PHP Code curl to some .... subdomain to manage secret api request.

When subdomain record exists in both local and external dns manager, the dns resolver will get information from local server instead of external server.
This could cause confuse to the customer.
 
Last edited:
@Ohm J True. I didn't think of that. Our customers do not use external dns managers and we always run our own DNS servers. So hence I didn't think of that possibility.
 
I use external DNS, as long as you change the nameservers in Bind (DA) to the external provider, you should be good to go..... That said, I don't curl any of my own domains, it's always external APIs I fetch.
 
Back
Top