Reviewing the zone records created by MIAB, I’m a little confused.
I’m trying to use a secondary DNS which puts a limit on the number of records I can have. With just three subdomains, I now have 55 DNS records for this zone.
It seems every subdomain (including ns1/2) are getting assigned _dmarc and TXT records. While I can understand some people may want to have authoritative email sending on subdomains, I would have to imagine the vast majority of records should not have this.
Is there a way to curb this behavior? And for future use, perhaps have a checkbox in the dashboard to state whether you intend to send email from those subdomains?
NS1’s free plan supports unlimited zones, but only 50 total records. Their paid tiers seem to be astronomical, so I’ll likely end up backing out of this and maybe going with ClouDNS who also supports DNSSEC, so I’m hoping they’ll support TSIG.
After more research, it does seem that MIAB could potentially do this for users who don’t want subdomains to send email by using the sp flag in the root DMARC record.
This could mitigate the need to add explicit DMARC A and TXT records for each subdomain, if you truly don’t intend on sending mail from subdomains.
The DNS records mark those subdomains as not sending mail, which protects you from other people sending spoofed email from those domains (to the extent receivers check SPF/DMARC).
TXT v=spf1 -all
TXT v=DMARC1; p=reject
I’m not sure whether it has any meaningful impact in practice. The DMARC sp tag could be used instead, but we don’t know that the user is not using subdomains for mail via another service, so we can’t assume it would be correct.
Right; that’s what I mentioned before, having some sort of configuration option that adjusts the behavior. But looks like this theoretical setting would only cover DMARC; apparently SPF does not have a mechanism to apply to subdomains.
Having said that, I wonder if a wildcard would be a good compromise: * IN TXT v=spf1 -all. Any subdomains that need SPF acceptance would already need to add an explicit TXT record, which would be read instead of the wildcard. …at least, I think. I need to test that out.
I’ve used ClouDNS in the past and really liked them a lot. But be aware that their free plan also has a limit on the number of DNS records and also might not support DNSSEC (don’t remember). Their paid plans are much cheaper than someone like NS1 though, just a couple of dollars a month for what you need.
@S4_Hosting, since you said you liked ClouDNS, maybe you can answer a question, since their support is not exactly being helpful.
The number of records in my quota at ClouDNS is 3x what MIAB is using. They claimed it’s because of “SOA records”, but there should only be one SOA record per zone.
Did you have this experience of them tripling the record count?
I haven’t used them for a while, but never had that problem when we did.
You can see the SOA records somewhere in the control panel (don’t remember where) so you can check how many of them there are, but it sounds odd.
Unless they have changed something drastically then I always found the live chat support to be fast and pretty helpful, it depends a little on who you get but most of them seemed to know what they were talking about.
Of course, I can’t see any records in my ClouDNS control panel. Their support said “You can see them on the master [sic] server where they are hosted”.
Maybe I just need to engage live chat instead of their email support.
You were correct, chat was much better. They were able to send me a text file of the records that they’re receiving.
Looks like DNSSEC creates a ton more records than I was expecting. One of my domains with 24 normal records balloons to 80 on ClouDNS’ side because of the DNSSEC-related entries.
I still think it would be nice to be able to turn off Service Discovery records like caldav, autodiscover, etc, but at least knowing why this happens is useful.