0

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:         127.0.0.1
Address:        127.0.0.1#53

** 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
OK

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
Jack Atlantic
  • 1
  • 4
  • 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
  • what does `sudo named-checkconf -z` say – Jacob Evans Dec 27 '17 at 21:05
  • I've included that output in the question, in case these comments are ever removed. – Jack Atlantic Dec 27 '17 at 21:12
  • I don't see anything wrong with what you have, I can only assume we're loosing details in obfuscation. – Jacob Evans Dec 27 '17 at 21:16
  • I'm assuming the records are actually terminated properly and `dig @::1 +short TXT 34783aoauth._domainkey.example.com.example.com.` does NOT work. – Jacob Evans Dec 27 '17 at 21:17
  • The warnings on SPF are harmless. Historically there was a true SPF record but then later it was decided to just use TXT records, and bind is letting you know that it will create the missing ones automatically for you. I see nothing wrong in your last 4 records in your zone so either the server is serving another version, or you are not using the correct server, or you have a problem elsewhere. – Patrick Mevzek Dec 28 '17 at 04:53

1 Answers1

0

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!

Jack Atlantic
  • 1
  • 4