New DNS records not resolving and I have no idea why


#1

Brand new install since the weekend, starting over fresh. Version 11 on Ubuntu 14.04 since 18.04 is not ready yet.
tail -n 10000 -f /var/log/syslog |grep named

Trying to get new records to propagate again but having zero luck. I’ve created about 4 new DNS records in the last 24 hours with no luck getting them to be queryable. What can I do?

Dec 25 01:18:40 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:40 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:44 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:44 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:45 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:45 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:49 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:50 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:50 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:51 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:54 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:54 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:55 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:55 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:58 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:58 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:18:59 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:18:59 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:19:03 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:19:03 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:19:04 box named[2304]: error (unexpected RCODE REFUSED) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.1#53
Dec 25 01:19:04 box named[2304]: error (host unreachable) resolving '87.10.243.171.in-addr.arpa/PTR/IN': 203.113.131.2#53
Dec 25 01:48:45 box named[2304]: received control channel command 'flush'
Dec 25 01:48:45 box named[2304]: flushing caches in all views succeeded
Dec 25 01:48:59 box named[2304]: received control channel command 'flush'
Dec 25 01:48:59 box named[2304]: flushing caches in all views succeeded
Dec 25 01:49:12 box named[2304]: received control channel command 'flush'
Dec 25 01:49:12 box named[2304]: flushing caches in all views succeeded
Dec 25 01:52:03 box named[2304]: received control channel command 'flush'
Dec 25 01:52:03 box named[2304]: flushing caches in all views succeeded
Dec 25 01:52:13 box named[2304]: received control channel command 'flush'
Dec 25 01:52:13 box named[2304]: flushing caches in all views succeeded
Dec 25 01:57:22 box named[2304]: lame server resolving '134.214.226.124.in-addr.arpa' (in '214.226.124.in-addr.arpa'?): 202.103.225.70#53
Dec 25 01:57:22 box named[2304]: lame server resolving '134.214.226.124.in-addr.arpa' (in '214.226.124.in-addr.arpa'?): 202.103.224.70#53
Dec 25 02:00:15 box named[2304]: received control channel command 'flush'
Dec 25 02:00:15 box named[2304]: flushing caches in all views succeeded
Dec 25 02:00:22 box named[2304]: received control channel command 'flush'
Dec 25 02:00:22 box named[2304]: flushing caches in all views succeeded
Dec 25 02:30:11 box named[2304]: received control channel command 'flush'
Dec 25 02:30:11 box named[2304]: flushing caches in all views succeeded
Dec 25 02:34:55 box named[2304]: received control channel command 'flush'
Dec 25 02:34:55 box named[2304]: flushing caches in all views succeeded

#2

I’m not totally certain what the issue is, but I recommend to people that they use their registrar’s provided DNS service, if their registrar provides one. Which registrar do you have your domain with? Do they provide free DNS services with it? If so, do you have any particular need to self-host your own DNS services?


#3

I would disagree with making this as a blanket statement. There ARE times when it is appropriate to use the registrars DNS and there are times not to. It is highly dependent upon several factors. Please keep in mind that without knowing more about the specific situation this could be bad advice.


#4

I am sorry but I do not understand what you mean by this … the current version of MiaB is v 0.29.

“Created 4 new DNS records” meaning custom DNS entries?

I am sorry, but I just do not quite understand the issue from what you have posted. Could you perhaps reword it in another way or provide more information. Disclosing your MiaB hostname always is helpful.

Have you researched those entries in your logs? You may wish to do so to get a better idea of when the errors are. They may be in relation to spam attempts towards your box. Or to a misconfiguration in the named.conf file. Or …
Have you changed any of the MiaB conf file settings manually?


#5
root@box:~|⇒  cd /home/user-data
root@box:/home/user-data|⇒  ls
backup  dns  mail  mailinabox.version  owncloud  settings.yaml  ssl  www
root@box:/home/user-data|⇒  cat mailinabox.version
11

Yes, I’m not sure what else it would mean, are there other MIAB controlled entries that I can create if there are I’d love to see a tutorial.

I like to self host because thats kind of the drive here self hosting is my preference these days and until now just after rebuilding my MIAB install from scratch because of some latent host issues. The other side is MIAB comes with a nice API and I don’t see any other DNS hosting options that I’m comfortable with I don’t really like the idea of letting CloudFlare or NameCheap handle my DNS records.


#6

For the last 6+ months MIAB has been a total joy to use with its DNS and all but on occasion I’ll add a new domain or DNS record and magically it falls flat serving any records that are created after that event I’m not sure what’s happening in this case but it’s happened more than once and I’d love to get it fixed up.

The main point of support for self hosting in my case is the simplicity I don’t want to have to be involved in doing the Mail records when MIAB can do them. Although there are many other great benefits like not centralizing the responsibility for doing things like DNSSEC etc. Which I’ve enabled everything in my MIAB status page says that it’s functional and aside from using external web hosting for things it’s all checkmarks everywhere.


#7

I have to be completely honest here, I have no idea what that number is supposed to represent. It is NOT however the version number of the current install. To find your current version number sign in to your admin pages and check the status page. The version number will be about the 4th entry on the ‘System Status Checks’ page.


#8

What exactly do you mean by the quote above? Maybe I have had too much Egg-Nog but I still am at a loss as to what exactly is happening / not happening. The errors you posted have nothing to do with dns hosting - they are dns lookup errors being done by the box that are failing, likely because they are being caused by spam emails being sent to your box.
Again, if you’d share your hostname, I could get a slightly better idea of what is or is not working … you can PM it if you’d prefer.


#9

It must be a version for backups or something to make sure that backups are done correctly.


#10

@alento sorry I thought that I’d included it I was trying to create additional records such as grey.nixc.us to no avail I’ve also tried creating SPF override records for nixc.us and that has also failed to work.

Thank you very much for your time and attention to this its really greatly appreciated.
Records that just do not resolve when I dig them from my local machine or via various different DNS resolvers 1.1.1.1, 9.9.9.9, and 8.8.8.8


#11

Just a note to set to the side … custom DNS entries are accomplished by entering them to the System>Custom DNS page in the admin area. Please confirm that is where you are trying to make entries. I am taking this to PM for now. :slight_smile:


Custom DNS seems to stop serving records when you have more than a certain number of records
#12

Sure PM’s are fine, I do want to let other people know what the solution was if we find it eventually. I did create the records in System>Custom DNS


#13

The first thing I note is that these custom entries are an attempt to replace existing entries in most cases and I think that is where you are going wrong.

For one thing the TXT record is clearly an SPF record (and a bad one at that) yet if you do a DIG you’ll find that you already have one.

C:\Users\timdu>dig txt nixc.us

; <<>> DiG 9.10.6-P1 <<>> txt nixc.us
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40846
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nixc.us.                       IN      TXT

;; ANSWER SECTION:
nixc.us.                1799    IN      TXT     "v=spf1 mx -all"

;; Query time: 118 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 29 10:17:34 GMT Standard Time 2018
;; MSG SIZE  rcvd: 63

You can’t use a custom record to override this AFAIK
Likewise your Custom CNAME entry for nixc.us which points to box.p.nixc.us is also superfluous to requirements.

Assuming that you are trying to use a CNAME to point to the A record for box.p.nixc.us there’s already this A record on the bare domain.

C:\Users\timdu>dig a nixc.us

; <<>> DiG 9.10.6-P1 <<>> a nixc.us
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24235
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nixc.us.                       IN      A

;; ANSWER SECTION:
nixc.us.                1799    IN      A       158.69.222.58

;; Query time: 127 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 29 10:27:45 GMT Standard Time 2018
;; MSG SIZE  rcvd: 52

This is also the same as the IP address for box.p.nixc.us

So that’s at least two custom entries you shouldn’t be using.


#14

Custom DNS records will override the automatically generated ones in some cases.


#15

Are you able to clarify which cases?

Thank you for the correction BTW


#16

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.