I apologize in advance for this newbie question. I've resorted to asking because I can't seem to find enough closely-related queries* on this network or elsewhere, and the BIND 9.9 ARM is not exactly newbie-friendly.

* I should say I found plenty of related queries, but their answers tended to involve syntax corrections and the like.

Anyway, my manager is trying to set up some marketing automation software for our website. He's asked me to add some CNAME, MX, and TXT records to the domain's zone file. We're using BIND 9 on a Debian 8 system.

I roughly understand the process of updating zone files. I know I must increment the file's serial number, and I know how to reload the zone, restart BIND, etc.

I also understand I can check the syntax of the zone file with named-checkzone.

To illustrate the situation, here's a close mock of our zone file:

$TTL    300

@       IN      SOA     ns1.example.com. 
jack.example.com. (
    2017122708      ; Serial
    10800   ; Refresh
    3600    ; Retry
    604800  ; Expire
    10800 ) ; Minimum

example.com.               IN NS   ns1.example.com.
example.com.               IN NS   ns2.example.com.
ns1.example.com.           IN A    199.195.xxx.yyy
ns2.example.com.           IN A    199.195.xxx.yyy
ipv4.example.com.          IN A    199.195.xxx.yyy
example.com.               IN A    199.195.xxx.yyy
remote.example.com.        IN A    173.9.zz.ccc
ftp.example.com.           IN CNAME        example.com.
www.example.com.           IN CNAME        example.com.
@                          IN MX   0 example-com.mail.protection.outlook.com.
autodiscover               IN CNAME        autodiscover.outlook.com.
sip                        IN CNAME        sipdir.online.lync.com.
lyncdiscover               IN CNAME        webdir.online.lync.com.
msoid                      IN CNAME        clientconfig.microsoftonline-p.net.
enterpriseregistration     IN CNAME        enterpriseregistration.windows.net.
enterpriseenrollment       IN CNAME        enterpriseenrollment.manage.microsoft.com.
_dmarc.example.com.        IN TXT  "v=DMARC1; p=none"
example.com.               IN TXT  "v=spf1 +a +mx +a:example.com include:spf.protection.outlook.com -all"

_sip._tls                  IN SRV  100 1 443 sipdir.online.lync.com.
_sipfederationtls._tcp     IN SRV  100 1 5061 sipfed.online.lync.com.

; I've been directed to add the records below:
34783aoauth._domainkey.example.com.        IN CNAME dkim.act-on.com.
mailer.example.com.        IN TXT "v=spf1 include:_spf.act-on.net -all"
mailer.example.com.        IN MX 10 est-mta.b2b-mail.net.
marketing.example.com.     IN CNAME example.actonservice.com.

I was directed to add the last four records. From my basic understanding of DNS, I suppose I'm trying to assign e.g. 34783aoauth._domainkey.example.com as an alias of dkim.act-on.com. So, I thought that, assuming I updated the zone correctly per my methods above, I could run an nslookup like so:

jack@example:~$ nslookup 34783aoauth._domainkey.example.com

** server can't find 34783aoauth._domainkey.example.com: NXDOMAIN

Instead, I get the NXDOMAIN error. I've assumed that that's not good.

So, I suppose you could sum up my question as how can I troubleshoot my configuration such that I can get that CNAME (plus those other 3 records) to resolve? Furthermore, how should I check that it resolves correctly? Was my nslookup approach appropriate? Would I be better served using dig, for example?

I realize the whole zone file is kind of a huge mess. I set it up myself originally, and being from a software development background I don't often dabble in this kind of systems administration, but it has worked well enough until now.

One thing that troubles me is the output of named-checkzone:

jack@example:~$ sudo named-checkzone example.com /etc/bind/zones/master/db.example.com
zone example.com/IN: 'example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: 'mailer.example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: loaded serial 2017122708

It seems to be complaining about the two SPF text records, but I'm not sure what it means when it says I need to add a matching SPF record. The BIND 9.9 ARM does not seem to mention this, and I'm not certain what the effects of having "unmatched" records are. Perhaps this is related to my question, but maybe it's coincidental in nature.

Jacob Evans asked what the output of sudo named-checkconf -z was. Here is that output (though note that I've edited the zone file and thus its serial number since the original post):

jack@example:~$ sudo named-checkconf -z
zone example.com/IN: 'example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: 'mailer.example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: loaded serial 2017122715
zone 0.168.192.in-addr.arpa/IN: loaded serial 1
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
  • did you increase 2017122708 to 2017122715 and rndc reload – Jacob Evans Dec 27 '17 at 20:37
  • zone example.com/IN: 'mailer.example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record is expected to be ignored, you do not need a SPF record, only the TXT record. – Jacob Evans Dec 27 '17 at 20:38
  • Thanks @JacobEvans, that's good to know about the SPF record. As for the serial number, I usually increment it by 1. So, it started the day at 2017122701, and I've edited it several times since then. I'll try it as you've suggested and run rndc reload again. – Jack Atlantic Dec 27 '17 at 20:46
  • also, DKIM records are also TXT records, so does dig @::1 +short TXT 34783aoauth._domainkey.example.com. work, or dig @::1 +short CNAME 34783aoauth._domainkey.example.com. – Jacob Evans Dec 27 '17 at 20:48
  • I'm afraid both of those dig commands yield no output. I've tried a few of the other CNAMEs in that zone file, however, and they've worked correctly. – Jack Atlantic Dec 27 '17 at 21:02

It turns out BIND had been setup to work with Plesk, and it was getting the zone files from a different location than I expected. When I made the changes to the proper zone file everything worked as expected.

Thank you to Jacob Evans and Patrick Mevzek for helping me work this out!

| improve this answer | |
  • Lol, You're welcome.... Please mark answered and/or close :) – Jacob Evans Dec 28 '17 at 21:29
  • Will do! Though it says I need to wait a day before I can accept my own answer. I've set a reminder for myself. – Jack Atlantic Dec 28 '17 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.