On Sun, Nov 22, 2020 at 10:56:58AM -0500,
John R Levine wrote
a message of 17 lines which said:
> I don't see why, since it only acts as a default. Any registrant
> that cares which CA they use can publish their own CAA.
Yes but many registrants don't know about CAA or did not pay attention
On Sun, 22 Nov 2020, Stephane Bortzmeyer wrote:
IMHO, the CAA algorithm is bad because it crosses administrative
boundaries. RFC 8659 at least excludes the root but it still allows,
for instance, AFNIC to put a CAA record in .fr which will apply to all
.fr domains which do not have an explicit
On Wed, Nov 11, 2020 at 09:39:38PM +,
Tony Finch wrote
a message of 34 lines which said:
> Well, the other Very Prominent example is CAA records, which also
> involve walking up the tree to discover policy. It would be nice if
> things like CAA and DMARC could agree with each other about
ul Vixie ; Joe Abley
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] Tell me about tree walks
>
> >> I understand the reason why being able to identify the registrar for
> >> a particular domain is useful (or "necessary" depending on your
> >> perspective).
I understand the reason why being able to identify the registrar for a
particular domain is useful (or "necessary" depending on your perspective).
I don't understand the overlap between this problem and the problem that
John is trying to solve, though. Could you explain?
i'm happy to try.
On Wed, Nov 11, 2020 at 05:45:52PM -0500, Joe Abley wrote:
> On 11 Nov 2020, at 17:08, Paul Vixie wrote:
>
> > if you guys are going to automate and secure the public suffix list
> > functionality, please spare a thought for automated / at-scale ("not
> > in whois") identification of the
On Wed, Nov 11, 2020 at 10:38:12PM +, Tony Finch wrote:
> Paul Vixie wrote:
> >
> > i'd like to be able to filter inbound traffic based on who paid the
> > money for a domain, who got that money, or whether either of them
> > wishes to remain anonymous.
>
> The crucial difference is that
On 11 Nov 2020, at 17:08, Paul Vixie wrote:
> if you guys are going to automate and secure the public suffix list
> functionality, please spare a thought for automated / at-scale ("not
> in whois") identification of the domain's registrar and registrant.
I understand the reason why being able
Paul Vixie wrote:
>
> i'd like to be able to filter inbound traffic based on who paid the
> money for a domain, who got that money, or whether either of them
> wishes to remain anonymous.
The crucial difference is that CAA/DMARC are consensual: the publisher and
the checker both want to use the
if you guys are going to automate and secure the public suffix list
functionality, ...
Not a chance.
seems like we're passing like ships in the night here.
We had a DBOUND working group that tried and failed to do that. For
DMARC, we don't really care where the boundaries are, only if
John R Levine wrote:
>
> > One possible way for DMARC to mitigate it would be to walk *down* instead
> > of up, and (in the application, not relying on the recursive server) stop
> > on NXDOMAIN because RFC 8020 tells you this is sensible, otherwise take
> > the last result you find.
>
> I
On Wed, Nov 11, 2020 at 05:17:54PM -0500, John R Levine wrote:
> > if you guys are going to automate and secure the public suffix list
> > functionality, ...
>
> Not a chance.
seems like we're passing like ships in the night here.
> > icann will likely never require it, but hopefully ietf can
if you guys are going to automate and secure the public suffix list
functionality, ...
Not a chance.
icann will likely never require it, but hopefully ietf can specify
it, after which the invisible hand of the market can decide it.
Doubly not a chance. Having been hanging around the
if you guys are going to automate and secure the public suffix list
functionality, please spare a thought for automated / at-scale ("not
in whois") identification of the domain's registrar and registrant.
i'd like to be able to filter inbound traffic based on who paid the
money for a domain, who
It occurs to me that for DMARC's purposes, walking up the tree would
work better than the current hack.
CAA records are perhaps less of a target for query amplification abuse
than DMARC records :-)
I dunno, seems to me the stakes are higher for CAA but the number of
requests per domain are
John Levine wrote:
>
> It occurs to me that for DMARC's purposes, walking up the tree would
> work better than the current hack. I know it would sometimes find a
> different answer from what it gets now, which is OK. When this came up
> before, the advice was that DNS tree walks are very bad, so
16 matches
Mail list logo
