How to use CIRA Canadian Shield with a Pi-Hole and DoH

CIRA (Canadian Internet Registration Authority) has recently launched a new DNS service called the “Canadian Shield” which is basically a DNS service similar to OpenDNS or Cloudflares 1.1.1.1 for Canadians, by Canadians.

CIRA offers three levels of protection depending on how safe you want to be:

  • Private: DNS resolution service that keeps your DNS data private from third-parties.
  • Protected: Includes Private features and adds malware and phishing blocking.
  • Family: Includes Protected and Private features and blocks pornographic content.

We use the Enterprise version of this service at my place of work and based on how we use it I’d say we’re using the equivalent of their “Protected” offering. We’ve had zero issues with the service and defiantly feels like it adds an extra layer or protection to our users.

Alright, enough free advertising (I am not receiving compensation from CIRA for this post).

When this was first announced I was eager to try it at home. CIRA’s instructions are how to either configure DNS over HTTPS (DoH) on a per-browser basis (not ideal for me since I have many devices on my network and don’t only use Firefox/Chrome) or configure your outbound DNS to use their servers over traditional, un-encrypted, DNS queries.

What I really want is to configure my Pi-hole which is my DNS endpoint for anything on my network to use the new CIRA service. This would capture ALL outbound DNS traffic and send it to CIRA making it so I only have to configure things in one place.

My current setup is: Clients -> 1 of 2 Active Directory DNS Servers -> Pi-hole -> Cloudflare via DoH (1.1.1.1 / Cloudfared)

This will easily work on a more traditional deployment of: Clients -> Pi-hole -> Cloudflare via DoH (1.1.1.1 / Cloudfared)

My Pi-hole is a basic CentOS 8 VM with the Pi-hole software installed on it with cloudflared so I can take advantage of DoH for all of my outbound DNS traffic. This is the minimum you need to get this working, a functional Pi-hole that is already sending it’s outbound DNS queries to Cloudflare (or another DoH provider) via cloudflared.

The first thing I did was re-configure my cloudflared to simply try using the CIRA DoH:

# Edit the cloudflared configuration file
vim /etc/default/cloudflared

# Commandline args for cloudflared to use 1.1.1.1
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

# Changed the above to:
CLOUDFLARED_OPTS=--port 5053 --upstream https://private.canadianshield.cira.ca/dns-query

# Save and close the file

# Restart cloudflared
systemctl restart cloudflared

# Test DNS
nslookup google.ca

# This failed

 

This ended up not working and after I tried it I realized why. To be able to use private.canadianshield.cira.ca you have to have functioning DNS. Cloudflare has skirted this issue by using 1.1.1.1 and 1.0.0.1 for it’s service, they are IPs and do not need DNS to be working to function.

Fortunately the solution was very easy:

# I did a nslookup on the specific CIRA service I wanted to use (Private) via traditional DNS

nslookup private.canadianshield.cira.ca 1.1.1.1

Server:         192.168.0.4
Address:        192.168.0.4#53

Non-authoritative answer:
Name:   private.canadianshield.cira.ca
Address: 149.112.121.10
Name:   private.canadianshield.cira.ca
Address: 149.112.122.10
Name:   private.canadianshield.cira.ca
Address: 2620:10a:80bb::10
Name:   private.canadianshield.cira.ca
Address: 2620:10a:80bc::10

# If you want to use Protected or Family instead of private 
# do a nslookup on either protected.canadianshield.cira.ca
# or family.canadianshield.cira.ca instead and use those IPs

# I then edited my /etc/hosts file on my Pi-hole
vim /etc/hosts

# and added the following (I don't use IPv6 at this time):

# CloudA DNS
149.112.121.10 private.canadianshield.cira.ca
149.112.122.10 private.canadianshield.cira.ca

# Save and close the file

# Test DNS
nslookup cira.ca
Server:         192.168.0.4
Address:        192.168.0.4#53

Non-authoritative answer:
Name:   cira.ca
Address: 52.60.203.65

 

That’s it. I now have the CIRA Canadian Shield working on my Pi-hole using the cloudflared software.

Now for some DNS benchmarks, what’s faster? CIRA or 1.1.1.1?

I flushed the DNS cache on my Active Directory DNS servers and then restarted cloudflared on my Pi-hole before running these benchmarks:

1.1.1.1.1 / 1.0.0.1

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.009 | 0.052 | 0.196 | 0.043 | 100.0 |
  + DotCom Lookup | 0.009 | 0.013 | 0.027 | 0.004 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.009 | 0.051 | 0.195 | 0.044 | 100.0 |
  + DotCom Lookup | 0.010 | 0.014 | 0.028 | 0.003 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver

 

and here are the three CIRA services:

CIRA - Private

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.019 | 0.062 | 0.236 | 0.048 | 100.0 |
  + DotCom Lookup | 0.022 | 0.046 | 0.086 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.068 | 0.238 | 0.056 | 100.0 |
  + DotCom Lookup | 0.023 | 0.047 | 0.075 | 0.019 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver




CIRA - Protected

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.019 | 0.062 | 0.236 | 0.048 | 100.0 |
  + DotCom Lookup | 0.022 | 0.046 | 0.086 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.068 | 0.238 | 0.056 | 100.0 |
  + DotCom Lookup | 0.023 | 0.047 | 0.075 | 0.019 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver



CIRA - Family

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.064 | 0.246 | 0.053 | 100.0 |
  + DotCom Lookup | 0.022 | 0.039 | 0.080 | 0.018 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.073 | 0.248 | 0.062 | 100.0 |
  + DotCom Lookup | 0.024 | 0.049 | 0.082 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver

 

If I am interpreting this data correctly, CIRA is 0.010s-0.030s slower on average compared to 1.1.1.1. Hardly worth mentioning.

I’m happily switching over to a Canadian based DoH service (full disclosure, I’m Canadian). No offence Cloudflare, you still get to hold my DNS until CIRA starts offering their DNS Anycast Service for home users (hint hint).

Oh and just in case your curious, if you choose their ‘Family’ service and try and hit up Pornhub, you’re greeted with this:

DFS not working properly over VPN for personal computers

We recently switched to a new VPN server after Mac OS dropped support for PPTP and because we were way overdue to do it anyway. Since then personal computers were unable to access network shares via DFS.

They could go directly to the file server and that would work.

Users who connected to VPN with a organization owned laptops were able to use DFS.

After some digging it turned out the issue was our old VPN allowed for WINS (yes yes I know) and our new VPN has WINS disabled (by design, see… we’re trying)

The proper solution to this problem is to re-configure DFS to use DNS only: https://support.microsoft.com/en-us/help/244380/how-to-configure-dfs-to-use-fully-qualified-domain-names-in-referrals

Unfortunately I didn’t have the time to implement this.

What we ended up doing is re-configured the DHCP scope to set VPN users DNS Suffix to ‘vpn.mydomain.com’

I then added aliases for all of our file servers and DFS servers under ‘vpn.mydomain.com’. Example:

  • fileserver1.vpn.mydomain.com, CNAME, fileserver1.it.mydomain.com
  • dfsserver1.vpn.mydomain.com, CNAME, dfsserver1.it.mydomain.com

This is a crappy hacky work around that isn’t really sustainable but will work for now until we can sit down and plan changing our DFS over to use DNS only.

Domain Computers worked fine because we use group policy to push out multiple DNS search suffixes. DHCP doesn’t allow you to do this with Windows PCs so when they try to lookup ‘fileserver1’ they would try to hit WINS if implemented and then append their DNS suffix (vpn.mydomain.com) and then fail to find the file server resulting in a “Network Path Not Found” errors.

Powershell script to create reverse lookups (PTR) in Microsoft DNS

We’re switching IP spaces at work and need to create a large amount of reverse lookup PTR records for our PAT/NAT pools.

Microsoft only allows you to manually create one DNS entry at a time via the GUI so I wrote a simple Powershell script that lets you mass create sequential PTR records.

 

####################################
# Windows DNS Server Reverse Lookup Populator
# Created by: Eric Schewe
# Created on: 2014-09-18
####################################
# Summary:
#   Windows DNS doesn't allow for the mass creation of reverse lookup PTR records.
#   This script allows for creating large chunks of reverse lookups based on a
#   incrementing number and pattern.
#
#   In our case we create reverse lookups that follow a certain pattern where
#   ###### is an incrementing number.
#   
#   Example: public#######.site01.mydomain.com
#            |----||-----||------------------|
#            |     |      |
#            |     |      --Defined by $postName
#            |     --Defined by $incrementingName
#            -- Defined by $preName
#
####################################
# Instructions:
#   1. Set $zoneName to the name of the reverse lookup zone you want the DNS
#      created in. Example: "0.0.127.in-addr.arpa"
#   2. Set $startingIP to the first IP you want to create a DNS entry for.
#      Example: "0"
#   3. Set $endingIP to the last IP you want to create a DNS entry for.
#      Example: "126"
#   4. Set $incrementingName to an appropriate starting value if want to use
#      an incrementing number in your naming scheme. If not you can leave this
#      value blank and only $preName and $postName will be used when creating
#      DNS entries
#   5. Set $preName to what ever you'd like the start of the DNS entry to be.
#      This can be left blank.
#   6. Set $postName to what ever you'd like the start of the DNS entry to be.
#      This can be left blank.
#   
####################################

$zoneName="0.0.127.in-addr.arpa"
$startingIP=0
$endingIP=126
$incrementingName=0
$preName="public"
$postName=".site01.mydomain.com"

while ($startingIP -le $endingIP) {
    
    $significanDigit="{0:D4}" -f $incrementingName

    Add-DnsServerResourceRecordPtr -Name "$startingIP" -ZoneName "$zoneName" -PtrDomainName "$preName$significanDigit$postName"

    $startingIP++
    $incrementingName++

}