And now… something completely different.
The other day I was “playing” with setting up Office 365 for one of our clients – they have Linux machines for their DNS servers, and BIND as their DNS solution. As this was my first encounter with configuring BIND by myself, I just wanted to share steps I’ve taken to make it work (in my lab environment) – maybe it will help someone…
DISCLAIMER: I’m not a Linux/UNIX expert! I try to figure out what I need, and then try to make this work… with the help of Internet resources (or experts), of course. There is plenty of resources on how to do this already, but I like to have things in one place if I need them again.
So, I’ve began my experiment with wondering which Linux distribution should I take. After some consulting (thanks, Ingrid ), the final choice was pretty easy – Fedora (criteria – had to be relatively easy to use (for non-Linux person like me), had to work in Hyper-V without much trouble, and there should be someone who can help if I got stuck).
After a pretty simple installation process (wizard, Next, …, Next, Finish), I’ve had my Fedora box up and running.
Now, the more complicated part – setup this box to be BIND server, and load the correct records in it, so that Office 365 can add and verify my domain.
Here are the high-level steps (I’ve used Terminal, with su rights):
1. install few packages to get things up and running:
|
yum -y install bind bind-utils bind-libs nano |
2. configure the BIND (DNS) server to run at startup:
3. query the firewall rules for UDP port 53 access:
4. open the required firewall ports (list of TCP and UDP ports):
|
iptables -I INPUT 3 --proto udp --dport 53 -j ACCEPT iptables -I INPUT 4 --proto tcp --dport 53 -j ACCEPT |
5. edit the /etc/named.conf file:
6. comment the lines that are preventing your BIND server from responding to “outside” requests:
|
... // listen-on port 53 { 127.0.0.1; }; // listen-on-v6 port 53 { ::1; }; ... |
7. add your local subnet to allowed list (and add some forwarders for resolving other domains and records):
|
... allow-query { 192.168.0.0/24; }; forwarders { 8.8.8.8; 8.8.4.4; }; ... |
8. enable recursion:
9. add your zone and a “pointer” to your zone file:
|
zone "o365.kaniski.eu" { type master; file "/var/named/o365.kaniski.eu.db"; }; |
10. create and edit the zone file specified:
|
nano /var/named/o365.kaniski.eu.db |
11. add the required records to your zone file (by the instructions that Office 365 gives you; sorry about the formatting):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
|
$TTL 7D $ORIGIN o365.kaniski.eu. @ IN SOA ns1.o365.kaniski.eu. hostmaster.o365.kaniski.eu. ( 2014071501 8H 2H 4W 1D ) ; @ IN NS ns1.o365.kaniski.eu. @ 3600 IN TXT "MS=ms10101010" @ 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all" @ 3600 IN MX 0 o365-kaniski-eu.mail.protection.outlook.com. autodiscover 3600 IN CNAME autodiscover.outlook.com. _sip._tls 3600 IN SRV 100 1 443 sipdir.online.lync.com. _sipfederationtls._tcp 3600 IN SRV 100 1 5061 sipfed.online.lync.com. sip 3600 IN CNAME sipdir.online.lync.com. lyncdiscover 3600 IN CNAME webdir.online.lync.com. msoid 3600 IN CNAME clientconfig.microsoftonline-p.net. |
12. save the files, and check the new zone:
|
named-checkzone o365.kaniski.eu. /var/named/o365.kaniski.eu.db |
13. restart the service and start using it:
And Office 365 response after this – success!
Things I’ve learned during this “adventure”:
- you should be careful about the trailing “.” (dot) in FQDN-s that you are using – if you miss it somewhere, you’ll get errors loading the zone
- there are great guides that can help you – one of them is BIND9 Server: How to (although I’ve seen it a bit too late )
- don’t be afraid to ask for help!
I cannot stress this enough – this recipe is not the secure way of doing things – it’s sole purpose is to make BIND work in my lab environment!
If I missed (or misunderstood) something, feel free to comment and correct me.
Cheers!
Updated (20160917): There was a tiny error in my zone file – switched priority and weight fields (thank you, Lenny, for pointing it out).