[HN Gopher] Protect domains that do not send email
___________________________________________________________________
Protect domains that do not send email
Author : zinekeller
Score : 198 points
Date : 2022-04-11 13:27 UTC (9 hours ago)
(HTM) web link (www.gov.uk)
(TXT) w3m dump (www.gov.uk)
| judge2020 wrote:
| Previously (2020): https://news.ycombinator.com/item?id=25210245
| brightball wrote:
| Yes! I've been begging for this for years. It's IMO the biggest
| enabler of phishing out there.
|
| Every time I give a talk on DMARC, SPF and DKIM people seem
| generally unaware that any IP address can send email claiming
| it's from your domain until you have explicitly turned it off.
|
| By default all domains should come with a strict reject policy on
| email until you intentionally turn it on. I usually go through
| this example with my fictional pirate themed gym, Slimmer Ye
| Timbers.
|
| Go turn off email for all of your currently unused domains. If
| you don't, odds are high that phish are using them.
|
| Just go set an SPF and a DMARC entry. You can look at
| slimmeryetimbers.com for an example.
|
| _dmarc.slimmeryetimbers.com. 5 IN TXT "v=DMARC1; p=reject;
| aspf=s; adkim=s;"
|
| slimmeryetimbers.com. 5 IN TXT "v=spf1 -all"
|
| Looks like the article goes even further, but I'm not sure the
| extra steps they are taking are necessary.
| eslaught wrote:
| It's great to have the two-liner, but can someone explain what
| these settings actually mean?
|
| Edit: Also, if I have a domain that currently does not send
| email but may in the future, am I hurting my future self by
| setting any of these?
| jabroni_salad wrote:
| Whether or not DMARC approves a message is based on
| both/either DKIM and SPF also approving. That string says
| that both SPF and DKIM must align and to Reject any message
| that fails either.
|
| The SPF record has "-all" which means to fail any message
| that is not from the designated approved mailserver. Since
| there isn't one defined, all messages will be failed.
|
| Having these will not impact your domain's reputation, but
| not having them can if you become party to spoofing. The only
| catch is that it will take as long as your record's TTL to
| make the domain sendable again, and even longer for some
| webmail providers who like to hang on to cached records past
| their expiry.
|
| If you are at a larger company you will want to look up the
| rua/ruf tags and set up an aggregator because one of your
| other business units will totally try to send a newsletter
| from the domain and instruct their business partners to
| manually whitelist it >_>
| brightball wrote:
| Sure!
|
| First off, no you are not hurting yourself. If anything,
| you're helping because you're making it harder for your
| domain to be flagged by spam filters for things you haven't
| done.
|
| Here's a quick explanation of SPF, DKIM and DMARC.
|
| SPF
|
| - It's a simple record in your DNS that let's you list IP
| addresses authorized to send email from your domain. 3rd
| party senders will often ask you to include them in your spf
| record. With nothing in the record and the "-all" meaning
| strictly enforced, you've not authorized any senders at all
| with SPF.
|
| DKIM
|
| - DKIM has to be setup for every sending mail server with a
| configuration mapped to a key located in your DNS config. If
| a receiving mail server gets a message without a DKIM
| signature, it has no way of knowing it should be there.
|
| DMARC
|
| - When you enforce a dmarc policy, you tell a server that
| receives email saying it is from your domain to only accept
| it if the message passes either an SPF or DKIM check that
| "aligns" with the domain. It's possible to send a message
| saying it's from slimmeryetimbers.com with a DKIM check that
| passes for "myphishdomain.com" and DMARC will not accept it.
|
| So has to be from one of your allowed IP addresses in the SPF
| record or must include a DKIM signature from your specific
| domain. With SPF essentially empty of options, this will mean
| that an aligned DKIM signature must present the for it to
| pass.
|
| The dmarc policy is the "p=". A "p=none" is just for show.
| Doesn't enforce anything. "p=quarantine" asks the receiving
| mail server to put messages that fail into spam while
| "p=reject" tells it to not deliver them at all.
|
| -------
|
| So summarizing all of that...the SPF record above says that
| no IP addresses are allowed to send mail on your behalf and
| the DMARC record tells the receiving mail server not to allow
| any messages saying they are from your domain unless they
| pass the SPF check (which they can't, because nothing is
| allowed) or they pass the DKIM check (which they can't,
| because you haven't set any up).
|
| Hope that helps and I'm happy to clarify anything that needs
| it.
| ResNet wrote:
| Thank you for this answer!
|
| A few more questions:
|
| 1. Would there be any issues receiving emails with these
| policies set?
|
| 2. Quoting OP's edit:
|
| > Edit: Also, if I have a domain that currently does not
| send email but may in the future, am I hurting my future
| self by setting any of these?
| [deleted]
| brightball wrote:
| None. SPF, DKIM and DMARC only affect outgoing mail.
|
| Incoming mail is handled entirely by your mail server
| which is pointed to by your MX record.
|
| This is actually where a lot of the confusion comes from.
| When you buy a domain, it doesn't go anywhere until you
| point it to specific web servers by adding A or CNAME
| records in your DNS. Same thing with your incoming email,
| nobody knows where to send a message until you setup your
| MX records. You can setup a web server that will serve
| any domain you want, but until the DNS points to it
| there's not an easy way for people to find it.
|
| Outgoing mail had no such check though. Any server could
| send a message claiming it was from your domain unless
| you took the time to specify where your mail is coming
| from.
|
| And no, this won't hurt you at all. All it does is tell
| the receiving mail servers that for an email from the
| domain to be valid, it must pass a DMARC check. If you
| subsequently setup something like Google for your
| domain's email, you'd just update the record by following
| the instructions Google will give you. For example:
|
| "v=spf1 include:_spf.google.com ~all"
|
| This let's Google manage the set of IP addresses. Google
| will likely also give you instructions to setup DKIM by
| adding a couple of additional records. This will ensure
| anything sent by Google for you domain will pass both SPF
| and DKIM, allowing it to be properly validated and
| delivered.
|
| You'll notice that "~all" instead of "-all" as well. When
| you're actually sending email from the domain, it's best
| to use "~all" instead of "-all". The "-all" can sometimes
| be over zealously strict and by using "~all" instead it
| will be enforced but let you defer to the DMARC policy
| for the enforcement of failures (such as forwarding or
| list serves that DKIM would still survive but SPF
| wouldn't).
| kmfrk wrote:
| It sure would be nice if companies like Cloudflare would help
| offer something to this effect.
| jabroni_salad wrote:
| cloudflare has a point & click wizard that does exactly this,
| and a suggestion to use it at the top of your dns control
| panel.
| creeble wrote:
| Thanks for this!
| AviationAtom wrote:
| Many folks like to outsource DNS hosting for smaller sites,
| which doesn't afford logging capabilities. Out of curiosity I
| chose to self-host DNS on one of my domains. I noticed many
| queries for MX records, and naturally assumed it was spammers
| looking for domains to send mail to. Looking at it again, I
| could see where maybe they were ultimately looking for which
| domains lack SPF and DKIM, perhaps checking MX first.
| zinekeller wrote:
| Null MX is for positive signalling: https://www.rfc-
| editor.org/rfc/rfc7505.txt
|
| For domains previously sending mail but no longer
| (transitioning to a new domain name), DKIM selector revocation
| is basically a cleaning-up (hinted at "Revoke all existing DKIM
| selectors in both TXT and CNAME records."). This prevents abuse
| at servers who don't understand DMARC but might be fooled by an
| errant DKIM-signed message (especially old 512-bit keys, I know
| key rotation but considering this is intended for government
| consumption there will be old systems still using a 512-bit RSA
| DKIM keys). This is just brownie points however if the domain
| never sent a valid mail at all.
| brightball wrote:
| That makes sense.
| ancientsofmumu wrote:
| Here are 4 tarpit MX services which can complement the solution
| to absorb spam being directed at/into the no-email domain,
| depending on needs: #
| https://wiki.junkemailfilter.com/index.php/Project_Tar
| tar.junkemailfilter.com ##
| https://abusix.com/blackhole-mx/ void.blackhole.mx
| ## https://www.dnswl.org/?page_id=17 mail-
| in.verboten.net ## https://fakemx.org/
| mx.fakemx.net
| justin_oaks wrote:
| I understand doing this for all of your domains, but what about
| subdomains? I can understand the value of doing this for
| subdomains that were used for email in the past, but otherwise
| I would think setting DMARC and SPF records for every subdomain
| would be a real pain.
| brightball wrote:
| If you set them at the top level, they should carry across
| the subdomains unless you configure them differently or
| override them with a subdomain specific record.
|
| You may want to verify that directly though. I haven't looked
| at the subdomain settings in a couple of years.
| dundarious wrote:
| What if you _do_ receive email for your domain but never
| for your subdomains, and therefore have necessary and non-
| "null" MX, etc., set up on the domain? Is there any point
| in having "null" records for the subdomains, and if so, is
| there any non-verbose way to do this?
|
| e.g., receiving emails at me@example.com, but never
| anything @sub1.example.com, @sub2.example.com, etc.
| zinekeller wrote:
| Use wildcard reject SPF for nameserver entries, for
| example: example.net TXT "v=spf1
| include:spf.yourmailprovider.example -all"
| *.example.net TXT "v=spf1 -all"
|
| and use strict DMARC policies. Unfortunately due to how
| DNS was defined, wildcard entries are not used whenever a
| subdomain is defined - even if its an A entry, so if you
| use an active subdomain (www is used most of the time)
| you unfortunately need to add them manually*. Also
| depending on your specific provider you may not be able
| to add them (unfortunately that's on them).
|
| * Except on, rather surprisingly, Microsoft's DNS servers
| (you can tick a box to force an wildcard entry to show up
| even if there are records already defined).
| dundarious wrote:
| Thanks, I do have several subdomain A records, but not a
| ton. I should get around to explicitly adding at least
| the SPF rejects for them.
| zinekeller wrote:
| I do hope that an SPF2 will allow defining subdomains.
| Until then, this is the best defence.
| mprovost wrote:
| When I worked as a sysadmin at Warner Bros back around 2001 our
| corporate mail was name@warnerbros.com which went to an AOL inbox
| (they made everyone eat the AOL dogfood). We realised that we
| owned a ton of domains including wb.com that didn't use email, so
| we set up some MX records and pointed them at a Solaris box
| running qmail and had our own wb.com addresses. I think I checked
| my official account maybe a handful of times the entire time I
| worked there.
| [deleted]
| rafaelturk wrote:
| I'm puzzled that it's not the other way. Domains without MX, SPF,
| DMARC should not be trusted..
| AviationAtom wrote:
| Reading DMARC reports it's pretty interesting to see just how
| often spammers attempt to use others' domains. The forensic
| reports should show the full contents of what they attempted to
| send, IIRC.
| benmanns wrote:
| Doing some reading, it looks like configuring RUA will send an
| aggregate like you mention, while configuring RUF (F for
| forensic) will give more granular details.
| sdflhasjd wrote:
| ... in theory. In practice, I don't think any major provider
| actually sends RUF reports.
| scblzn wrote:
| Forensics reports would be nice indeed, but even Google
| doesn't send them to the RUF address. Never got one report in
| 4 years of DMARC. Only RUA. Maybe one day..
| boomer918 wrote:
| Can the registrars do this for me? I have no idea what half of
| those records do.
| Zababa wrote:
| I really like how they do their cookie banner. It's visible, very
| clear, but not too distracting, and if you just scroll down it
| disappears.
| hoosieree wrote:
| I wouldn't say I _like_ it, but I _dislike it much less_ than
| the typical cookie banner. In a perfect world, there would be
| no cookies, and no banner.
| layer8 wrote:
| You mean there would be no tracking, because you don't need
| banners for cookies used only for non-tracking purposes.
| ChrisArchitect wrote:
| (2021)
___________________________________________________________________
(page generated 2022-04-11 23:02 UTC)