Subject: [DNSOP] Tell me about tree walks

From: "John Levine" <[email-masked]>
Date: 11 Nov 2020 13:14:23 -0500

Over in the DMARC working group we have this DNS application.

If someone sends you a messsage from, say, [email-masked].
your mail system looks for a policy record at
_dmarc.sales.east.bigcorp.com. If it doesn't find one, it looks for
one in the "organizational domain", in this case _dmarc.bigcorp.com.

The way we currently find the organizational domain is straight out of
HOSTS.TXT. Everyone in the world periodically downloads a public
suffix list from https://publicsuffix.org/list/public_suffix_list.dat
and the organizational domain is one label below the longest public
suffix of the name. You don't have to tell us this is ridiculous. The
DBOUND WG tried to create a way to put the info in the DNS but failed
for various non-technical reasons.

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 don't do
them.  Is that still true?

As I understand it, the main problem with tree walks is that a malicious
sender could send long non-existent names and cause floods of queries,
but RFC 8020 lets DNS caches dispose of those cheaply.  We know they're
ugly, but in a situation like this where none of the options are great,
why not?

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 21:39:38 +0000

> them.  Is that still true?

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 how they discover
domain-wide policies.

CAA records are perhaps less of a target for query amplification abuse
than DMARC records :-)

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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Southerly 6 to gale 8, occasionally severe gale 9 at first in North
Channel, veering westerly 4 or 5 for a time. Moderate or rough, becoming
slight or moderate for a time. Rain at first, then fair, occasional rain
later. Moderate or good, occasionally poor.

---

From: "John R Levine" <[email-masked]>
Date: 11 Nov 2020 17:07:31 -0500

>> work better than the current hack.

> CAA records are perhaps less of a target for query amplification abuse

I dunno, seems to me the stakes are higher for CAA but the number of 
requests per domain are far lower.

> the last result you find.

I wouldn't want to skip the cache.  In most settings there's a whole lot 
of mail from the same place and most of the answers are likely to be 
cached.  Perhaps just note that if you're worried about this, use a cache 
the does RFC 8020.

There's also the practical fact that the amount of real mail from domains 
with more than 5 or 6 labels rounds to zero and you could limit the tree 
walk to 10 labels without losing anything.  If there's no DMARC record at 
the name itself, and you walk up 10 labels without finding anything, 
pretend you found one says to reject everything.  People who really REALLY 
want 37 label names need to put DMARC records every 10 levels.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Nov 2020 22:08:22 +0000

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 got that money, or whether either of them
wishes to remain anonymous.

icann will likely never require it, but hopefully ietf can specify
it, after which the invisible hand of the market can decide it.

-- 
Paul Vixie

---

From: "John R Levine" <[email-masked]>
Date: 11 Nov 2020 17:17:54 -0500

> functionality, ...

Not a chance.

> it, after which the invisible hand of the market can decide it.

Doubly not a chance.  Having been hanging around the "expedited" process 
at ICANN I can assure you that the registries will voluntarily provide no 
WHOIS data at all.  The business plan, you know.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Nov 2020 22:23:04 +0000

> > if you guys are going to automate and secure the public suffix list

seems like we're passing like ships in the night here.

> Doubly not a chance.  Having been hanging around the "expedited" process at
> ICANN I can assure you that the registries will voluntarily provide no WHOIS
> data at all.  The business plan, you know.

i know about the business plans. so icann will never require it. but if
there's an ietf specified way for a registrar to signal their role in all
their domains, it'll be seen by at least one of them as a market
differentiator. (i know the ones i'll be proposing this to.)

that's all we need.

so instead of debating whether icann is or is not a regulator and whether they
have or have not been captured by their industry and whether they can or
cannot require anything controversial, can we debate instead whether the
ietf, being above the fray, can possibly specify a scalable ("not in whois")
method of automatic identification of a domain's registrar?

i brought this up because this marker's presence would also help with the
kinds of tree walking and public-suffix-list functionalities we use today.
so, there's technical merit here, it's not strictly a defense budget play.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 22:23:03 +0000

John R Levine <[email-masked]> wrote:
> I wouldn't want to skip the cache.  In most settings there's a whole lot of
> mail from the same place and most of the answers are likely to be cached.
> Perhaps just note that if you're worried about this, use a cache the does RFC
> 8020.

Ah oops, I was too terse: I meant, use the recursive server as usual, but
don't assume it implements RFC 8020: instead (re-)do the NXDOMAIN logic in
the application.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: In southeast, easterly 4 to 6. In northwest, southwesterly 5 to 7,
becoming cyclonic 4 or 5 later. In southeast, moderate. in northwest, moderate
becoming rough. In southeast, fair. In northwest, showers. Good.

---

From: "John R Levine" <[email-masked]>
Date: 11 Nov 2020 17:31:01 -0500

> 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 someone up 
the tree has a default policy.

> differentiator. (i know the ones i'll be proposing this to.)

Um, perhaps talk to them and let us know what they say?  The registrars I 
know are all using GDPR are an excuse to publish nothing at all.

Regards,

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 22:38:12 +0000

> wishes to remain anonymous.

The crucial difference is that CAA/DMARC are consensual: the publisher and
the checker both want to use the protocol to stop baddies doing bad
things. But your situation is more adversarial: you (the checker) want to
find out if the publisher is good or bad. There's not much chance of
success trying to use a protocol designed for friendlies in situations of
distrust, let alone active combat!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Variable 4, becoming southeasterly 5 or 6, increasing 7 to
severe gale 9 later. Rough, occasionally very rough later. Showers, rain
later. Good, occasionally poor.

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Nov 2020 17:45:52 -0500

> in whois") identification of the domain's registrar and registrant.

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?

Joe

---

From: Paul Vixie <[email-masked]>
Date: Thu, 12 Nov 2020 05:10:06 +0000

On Wed, Nov 11, 2020 at 10:38:12PM +0000, Tony Finch wrote:
> find out if the publisher is good or bad.

did you see army of darkness? do you remember what Ash said about good/bad?

> There's not much chance of success trying to use a protocol designed for
> friendlies in situations of distrust, let alone active combat!

i guess i'll go another couple of rounds with this, even if it means
answering what i haven't said after somebody ignores what i did say.

forget about why i want it, if that helps. or, if you're willing, imagine
a world where registrars who want to be associated with the domains they
sell clearly mark those domains with their identifier, and others, not so.

* * *

here's what i know. there are registrars who are proud of their business
practices and policies, who despise their race-to-the-bottom competitors
as much as anybody could. but they have no way to differentiate themselves
since the third parties who are satisfied by a takedown never tell anybody.

the ietf has offered these registrars no in-band at-scale on-the-wire method
to demonstrate greater care in their output. i'm not sure why we would
expect an industry to improve itself without metrics supporting
differentiation.

same goes for registrants. if we want differentiated acceptance levels for
new domains based on whether the registrar and registrant are willing to
self-identify to an authentic reputation, we have to make it possible.

if social networks could put new account requests in a delay queue whenever
they can't identify the registrar or registrant, or if e-mail servers
could do likewise with arriving e-mail, then the cream would float to the
top, and everything else could be made to cost more and take longer. right
now reputation is only a bad thing, and accountability is _not_ improving.

but none of that matters for the purpose of extending the protocol. what
matters is just that there is no way for a registrar and/or registrant to
mark their domain with an identity. perhaps for registrants it's just RP?
perhaps for registrars it's a new schema for RP, appearing above the zone
cut or at some cousin name to avoid the DS problem?

i'm not asking that you adopt my economic vision, nor split any bosons.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Thu, 12 Nov 2020 05:29:07 +0000

On Wed, Nov 11, 2020 at 05:45:52PM -0500, Joe Abley wrote:
> 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. otherwise i'll just be sheltering in place.

what the public suffix list does is keep track of a set of labels under
which responsibility has almost always shifted. for example, under COM,
unless it's verisign.com, the "." between example and com in example.com
represents a change-of-party. knowing when this happens is necessary for
a lot of security-related purposes, for example, same-origin web policies
where labs.fsi.io may want to emit a cookie for fsi.io or www.fsi.io but
should be prevented from emitting one for gandi.io ("won't be believed").

doing this syntactically failed, because of co.uk and a lot of other
things that aren't TLD's but act like them (subdomains belong to someone
other than the delegator.) the public suffix list avoids syntax limits
by simply listing all the domains whose subdomains belong to others.
this comes up in dynamic dns providers also; it's not just a TLD thing
or an "effective TLD" thing. however, the public suffix list should
remind us all of HOSTS.TXT, and we should remember why DNS was invented.

so, some signal pattern (e.g., an RRset) that was in-band (not in a file)
and available at-scale (subject to DNS caching) could at a minimum solve
the problem john brought up, asserting for example that "subdomains of COM
are different parties".

what i'm asking is that if we're going that far we overload this signal
pattern slightly by letting it assert that "the registrar for fsi.io is
gandi" or even "the registrant for fsi.io is farsight". an RP RR could
be used. if you find an RP at some dns vertex you can assume it's only
there because it differs from the parent, or you can tree walk to be
sure, if you care.

but where to find that RP isn't obvious. fsi.io may be a criminal who
does not want anyone to know who its registrar (or registrant) was. so
a cousin domain such as should have been used for DS might be specified:
look in at fsi._registrar._meta.io and fsi._registrant._meta.io for them.

this is many orders of magnitude more state mass than would be required
just for io (and com and co.uk and so on) to say "my subdomains belong
to other parties") but would provide a useful metric for service quality
differentiation among registrars, and would also solve for john's need.

people you (joe) know personally would love to be able to tell potential
customers that if they don't want their domains marked in this way, they
should find some registrar who cares less.

-- 
Paul Vixie

---

From: "John R Levine" <[email-masked]>
Date: 12 Nov 2020 10:15:27 -0500

> i'm happy to try. otherwise i'll just be sheltering in place.

I read all your stuff and it's clear to me that it has nothing to do with 
my question about DNS tree walks.

R's,
John

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 12 Nov 2020 17:26:02 +0000

John,

If the concern is a string of period-separated gibberish, why not create some artificial/sane limit where the receivers stop at N steps?

I can't say I'm personally a huge fan of tree-walks, only because I feel like the responsible party should have the ability to manage their DMARC properly through TXT or CNAME records, though, I do understand it makes many things easier in DMARC.  I would like to suggest also suggest that if the tree-walk becomes the method that it should include a method by which a receiver can be told that it should stop.  Message arrives from a.b.c.d.example.com, and at d.example.com, there would be a record like "v=DMARCv2 tw=0".

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: DNSOP <[email-masked]> On Behalf Of John R Levine
> Sent: Thursday, November 12, 2020 10:15 AM
> To: Paul Vixie <[email-masked]>; Joe Abley <[email-masked]>
> Cc: [email-masked]
> 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 don't understand the overlap between this problem and the problem
> >> that John is trying to solve, though. Could you explain?
> >
> I read all your stuff and it's clear to me that it has nothing to do with my
> question about DNS tree walks.
>
> R's,
> John
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!
> CQl3mcHX2A!VakA9j7sulgmHrfAPEgF4lehHbylfRiLw1UIVO-
> f38uYVtIx70hYga8j4P2AxpNk296BNdY$

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 22 Nov 2020 08:41:25 +0100

On Wed, Nov 11, 2020 at 09:39:38PM +0000,
 Tony Finch <[email-masked]> 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 how they
> discover domain-wide policies.

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 CAA. It seems bad.

---

From: "John R Levine" <[email-masked]>
Date: 22 Nov 2020 10:56:58 -0500

> .fr domains which do not have an explicit CAA. It seems bad.

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.  If the registrants 
object, that's between them and Afnic.

Over in DMARC land we have a proposal called PSD which specifically sets 
a default policy for the whole TLD, since .BANK and .INSURANCE want to do 
that for their registrants.

Regards,

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 22 Nov 2020 17:35:16 +0100

On Sun, Nov 22, 2020 at 10:56:58AM -0500,
 John R Levine <[email-masked]> 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
to this subtle detail, so I still believe it is bad practice to climb
the tree looking for such data.