It was suggested that some additional context may help the conversation a bit.
In the email world, typically a valid A/MX for the 5321.From Domain is required
for delivery (the envelope sender). Typically, you'll see these as
"alex_brot...@comcast.com" in a valid/good message. There have been two
instances lately where using a wildcard has led to abuse.
First example:
thisisawildcardresponse.ph. 3600 IN A 45.79.222.138
As you may imagine, you can create an innumerable number of domains with a
wildcard at the TLD. They also attempted to leverage *.co.com and *.br.com,
and I'm sure others.
Some time ago, there was also an attempt to leverage this with SPF records.
With SPF records, you can create a macro, and using metadata about the
connection/message, attempt to understand if the IP is permitted to send on
behalf of a given domain. If the A record response is 127.0.0.2 (or any A
record), it's considered a permitted IP.
example.com TXT "v=spf1 exists:%{i}.spf.example.com -all"
Which is great until a wildcard is deployed at the *.spf.example.com, which
leads to
1.2.3.4.spf.example.com A 127.0.0.2
alsoValid.spf.example.com A 127.0.0.2
Coding can be done to discover these, but thought I'd ask if there were
something inherent in the protocol that could disclose when a wildcard match
was responsible for the result. Seems like in most cases, there is no such
mechanism.
Thanks
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -----Original Message-----
> From: Brotman, Alex <alex_brot...@comcast.com>
> Sent: Monday, January 6, 2025 4:46 PM
> To: Mark Andrews <ma...@isc.org>
> Cc: dnsop@ietf.org
> Subject: RE: [DNSOP] Flag for Wildcard Responses
>
> These are zones I do not control. I assume the recursive I'm using (which
> does
> support DNSSEC) is of no help here.
>
> I'd be happier if everyone would sign, for a bunch of reasons. I'm sure many
> would be.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
>
>
> > -----Original Message-----
> > From: Mark Andrews <ma...@isc.org>
> > Sent: Monday, January 6, 2025 4:43 PM
> > To: Brotman, Alex <alex_brot...@comcast.com>
> > Cc: dnsop@ietf.org
> > Subject: Re: [DNSOP] Flag for Wildcard Responses
> >
> > Sign the zone. Wildcard responses are visible in the DNSSEC records. The
> > RRSIG
> > label count is different and there will be NSEC/NSEC3 records that show
> whether
> > the wild card response is valid or not.
> > --
> > Mark Andrews
> >
> > > On 7 Jan 2025, at 08:04, Brotman, Alex
> > <Alex_Brotman=40comcast....@dmarc.ietf.org> wrote:
> > >
> > > Looking at something relating to the day job, and I'm curious if there's
> > > any
> > method declared in the IETF world where the query side of the interaction
> > can
> > understand that the response was fulfilled by a wildcard record. I've
> > asked a
> few
> > folks, and I haven't gotten anything that suggests as though this is
> > possible. No
> > one knew of any RFC or similar document that suggested this was an option.
> > I
> > was curious if we're all missing something that could indicate this type of
> > response. If not, is it something that should exist?
> > >
> > > (and if I'm in the wrong place, please be gentle)
> > >
> > > --
> > > Alex Brotman
> > > Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> > >
> > >
> > > _______________________________________________
> > > DNSOP mailing list -- dnsop@ietf.org
> > > To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
