Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt

From: "John Levine" <[email-masked]>
Date: 3 Apr 2019 13:58:19 -0400

In article <[email-masked]> you write:
>Comments eagerly sought, of course.

This seems sorta kinda like my dbound draft, only with _tagged TXT
records rather than a new rrtype, and (unless I missed something) a
hope that somehow you can use a yet to be invented cache to avoid
walking up the tree, where mine used wildcards to do one lookup per
boundary regardless of the tree depth.

I can see that the tradeoffs are different but I don't see why they're better.

R's,
John

>A new version of I-D, draft-dcrocker-dns-perimeter-00.txt
>has been successfully submitted by D. Crocker and posted to the
>IETF repository.
>
>Name:		draft-dcrocker-dns-perimeter
>Revision:	00
>Title:		DNS Perimeter Overlay
>Document date:	2019-04-02
>Group:		Individual Submission
>Pages:		20
>URL: 
>https://www.ietf.org/internet-drafts/draft-dcrocker-dns-perimeter-00.txt

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 11:22:50 -0700

> boundary regardless of the tree depth.

Section 7's suggestion for using Additional information does not rely on 
caching.

Reliance on existing wildcard depends on propagation of a new RR, which 
continues to be problematic.  There's a reason the Attrleaf table has so 
many entries...

And while there is certainly conceptual overlap with your earlier 
proposal, the current one has differences I'd class as significant.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 3 Apr 2019 14:45:01 -0400

On Wed, 3 Apr 2019, Dave Crocker wrote:
> continues to be problematic.  There's a reason the Attrleaf table has so many entries...

Now we're having a discussion about which is the frying pan and which is 
the fire.

In my experience, these days getting a new rrtype that doesn't have extra 
semantics into DNS servers happens pretty quickly.  It's an entry in a 
table or a new short stylized parse/unparse routine.  DNS caches don't 
have to change at all. The problem is the web provisioning crudware, which 
is what I have tried with limited success to address with my DNS extension 
language work.  My dbound draft has no new DNS semantics, just ordinary 
wildcards and an ordinary rrtype.

To put anything into the additional section, you're asking the DNS servers 
to treat a _perim name specially if there are TXT records under the name 
and to go search through the zone to find the extra stuff and put it in 
the additional section.  DNS caches have to change too, to treat the 
additional stuff as non-hostile and pass it through, since caches throw 
away unrecongnized additional sections to prevent cache poisoning (the 
Kashpureff bug.)

You should run this by dnsop where I expect you'll get a great deal of 
pushback and references to the DNS Camel for anything with new semantics.

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 11:51:48 -0700

On 4/3/2019 11:45 AM, John R Levine wrote:
> In my experience, these days getting a new rrtype that doesn't have 
> extra semantics into DNS servers happens pretty quickly. 

Now, about /end to end/ support, not just publishing...

Please provide some examples comparable to your proposed use case.  That 
is, what are new RRs that are getting well-scaled, on-going use, defined 
in say the last 5 years?

>   My dbound draft has no new DNS 
> semantics, just ordinary wildcards and an ordinary rrtype.

I noted that.

> To put anything into the additional section, you're asking the DNS 
> servers to treat a _perim name specially if there are TXT records under 

I noted that.

d/

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 3 Apr 2019 11:52:31 -0700

I appreciate the time you invested in this Dave.   I definitely like
that we're thinking in terms of how to leverage DNS and its
distributed model vs emulating the hosts.txt situation, and PSL is
essentially a hosts.txt situation.

Some assert there is a benefit to being able to contain some form of
static list locally for speed.  This happens at the trade-off of
potentially stale data, which we experience as maintainers receiving
energy from expressive TLD admins describing their grief over their
domains being directed at search instead of resolving in DNS because
their pc, tablet or mobile device runs a browser software that did not
contain their TLD.

So in those cases (and potentially others) getting things into DNS
_might_ be better.  I think that a TLD administrator being able to
make direct updates in their own zones is vastly better because it
would both alleviate the arduous process of validating authority of
requests, and streamline the requesting process to near zero on their
updates, and enable more direct and exacting control by the registry
operators.

That said, we fail the community unless the potential replacements
take into consideration the many constituent / subjective uses of PSL
that have evolved across the years before we tick the box next to any
particular solution meeting the diverse needs.

We have to tread carefully here.  I have great respect for the IETF
and the many wise and noble experts that have donated their
experience, time and wisdom towards solutions and standards.  It is a
process that requires patience and I have been told by many in the
developer community that it is not always one that is inclusive or
able to meet the pace of some development cycles and product or
service evolution.

The PSL basically came into existence outside of the IETF process,
borne of real practical needs, and those needs have forked and
matured.

There is a 'lenticular' / perspective issue in how different
stakeholders are using the PSL.   PSL is included in software
libraries, which incorporate it without prescribing how a developer
might use it.  Some care only about the private section of the list,
some only about the "ICANN" section.  Some integrators of the PSL omit
certain elements, or even maintain their own supplementary sections
for their project or service needs.

Think it is safe to assert variety is present - each have an entirely
different need and application of some or all of the PSL's contents
than a browser program, search engine, security professional,
anti-spam, reporting, SSL Cert, or other use.

We (maintainers) don't prescribe specifically how it gets used as
volunteer community maintainers, we just try to guide community
entries and validate them (and focus on ICP-3 or other I* integrity).

PSL is expanding - which grows the file size each time.  As potential
solutions are presented from web developers or even the IETF (or both)
that might help to organize or better architect solutions that could
help PSL from heading towards something that emulates the transition
from the SRI hosts.txt challenges, I fear that unless we can ensure
that some of the dependencies are met by those proposals, the
proposals will not endure, and we'll remain using the PSL in a status
quo manner.

-Jothan
Jothan Frakes

On Wed, Apr 3, 2019 at 10:58 AM John Levine <[email-masked]> wrote:
> _______________________________________________
> dbound mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dbound

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 12:02:44 -0700

On 4/3/2019 11:52 AM, Jothan Frakes wrote:
> I fear that unless we can ensure

Jothan,

Thanks for adding comments so quickly after the draft was released.

As the draft notes, it attempts to cover PSL use cases but needs far 
more experienced eyes and minds to find where the PSL emulation needs 
more work.

To that end, anything that documents the dependencies you cite is sure 
to help.

d/

---

From: "John R Levine" <[email-masked]>
Date: 3 Apr 2019 15:06:02 -0400

On Wed, 3 Apr 2019, Dave Crocker wrote:
> Please provide some examples comparable to your proposed use case.  That is, 
> what are new RRs that are getting well-scaled, on-going use, defined in say 
> the last 5 years?

There aren't many other than maybe CDS and CDSKEY.  TLSA was defined in 
2012 and Viktor says it's getting pretty wide use now, particularly 
considering that it needs DNSSEC.

On the other hand, there hasn't been anything with new server semantics 
since NSEC3 in 2008.

This is really an argument for dnsop, not dmarc or dbound.

Regards,

---

From: tjw ietf <[email-masked]>
Date: Wed, 3 Apr 2019 20:19:41 +0100

I was going to say CAA but that’s 6 years old. 

From my high tech gadget

> On Apr 3, 2019, at 20:06, John R Levine <[email-masked]> wrote:
> 
>> Please provide some examples comparable to your proposed use case.  That is, what are new RRs that are getting well-scaled, on-going use, defined in say the last 5 years?
> 
> There aren't many other than maybe CDS and CDSKEY.  TLSA was defined in 2012 and Viktor says it's getting pretty wide use now, particularly considering that it needs DNSSEC.
> 
> On the other hand, there hasn't been anything with new server semantics since NSEC3 in 2008.
> 
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Apr 2019 20:49:12 +0100

Far from widely deployed, but the latest ESNI draft introduced a
new RRTYPE from an experimental range, and it "just worked," which
was a pleasant surprise for me. (And is partly why I am happy to
try that route for RDBD.)

"just worked" here meaning: no registrar web-GUI involved, but
whacking the ascii hex encoding of binary RR values into a zonefile
on a hidden master, having that transferred to the visible NS's and
accessing it from elsewhere using dig with and without DNS/TLS (DoT-
flavoured via stubby) all did really just work. Only hard thing was
finding the docs to say how to refer to the new RRTYPE in zonefile
and dig command line. (I added some notes on that in a readme for my
ESNI code - go to [1] and search down for RRTYPE if you're curious.)

I think that tends to back up John's argument that today, registrar
GUIs are perhaps the main barrier for new RRTYPEs that don't change
the DNS semantically. But there may also be development environment
issues, e.g. I don't know if you can easily query for new RRTYPEs
from e.g. PHP or python code.

Lastly, on Dave's draft itself, I'd be happy if something like that
were deployed, and don't think it overlaps much with or competes
with RDBD. (At least I hope these aren't seen as competing ideas.)

In early chats about RDBD Alex and I did think about the PSL, but we
ended up deliberately not trying to aim for a DNS equivalent. Without
trying to speak for Alex, personally I think emulating the PSL in DNS
is too big a leap to attempt in one step and isn't likely to succeed,
despite it being an outcome that'd be good to (eventually) see.

That's partly how we ended up with (what I'd claim) is the more modest
initial goal of RDBD.

Cheers,
S

[1] https://github.com/sftcd/openssl/tree/master/esnistuff

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 3 Apr 2019 13:19:47 -0700

> ... registrar
> GUIs are perhaps the main barrier for new RRTYPEs ...

s/registrar/DNS Management/

these are often not one in the same - and the only reason I make that
pedantic distinction is that the frequent situation where
DNS Management != registrar
heavily impedes DNSSEC end-to-end configuration, because it needs
config harmony within the registration path (registrar) and the
resolution path (DNS)

Hope that made sense.  Just want to ensure these are not conflated to
avoid drag on efforts

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Apr 2019 21:30:42 +0100

> Hope that made sense.  Just want to ensure these are not conflated to

Fair point.

Ta,
S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 14:07:12 -0700

> I was going to say CAA but that’s 6 years old.

5 was a random number.  I was merely meaning 'recent'.

But suggesting CAA in response to my query means that you think RFC 6844 
has received widespread -- ie, at scale -- end to end adoption and use.

Yes?

Please forgive my skepticism.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 14:09:02 -0700

May we quickly settle on a single mailing list for discussing this draft?

I assume dbound is the right choice but don't really care, as long as it 
is only one.

Absent objection, I propose that this note be the last one cross-posted.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 3 Apr 2019 21:00:46 -0400

On Wed, 3 Apr 2019, Dave Crocker wrote:
> But suggesting CAA in response to my query means that you think RFC 6844 has 
> received widespread -- ie, at scale -- end to end adoption and use.

Every CA is supposed to check CAA records before issuing a cert to see if 
they're allowed to issue it.  I know Let's Encrypt does and I suppose I 
can ask them how many CAA records they see.

> Please forgive my skepticism.

Well, OK, here's a question for you: when's the last time an RFC added a 
feature to the DNS that puts records in the additional section triggered 
by a specific label in the query?  I'm reasonably sure the answer is 
"never" but you might ask dnsop to be sure.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 18:23:58 -0700

> "never" but you might ask dnsop to be sure.

my proposal does not 'add a feature to the DNS'.  It uses existing DNS 
mechanisms and does not change the DNS protocol or its formats.

Your original phrasing was better, because it was in terms of requiring 
a 'modification' to the server.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 18:25:04 -0700

Your original phrasing was better, because it was in terms of requiring 
a 'modification' to the server, which of course, my proposal does do, as 
an optimization.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 3 Apr 2019 21:27:53 -0400

> mechanisms and does not change the DNS protocol or its formats.

New additional section processing would absolutely be a new feature in the 
DNS, one that would require potentially significant code changes to every 
DNS server and cache.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 18:36:06 -0700

>> mechanisms and does not change the DNS protocol or its formats.

People often confuse additions to /use/ of a service with changes /to/ 
the service.  This would be the former, not the latter.

Or perhaps you can point to the DNS specs and registries, showing where 
they specify the constrained set of Additional responses that I'm 
calling for modifying?  I'm not finding such a list.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 3 Apr 2019 22:14:48 -0400

> Or perhaps you can point to the DNS specs and registries, showing where they 
> specify the constrained set of Additional responses that I'm calling for 
> modifying?  I'm not finding such a list.

This is getting very strange.

Your draft says:

    Another approach is use of the DNS Additional section in the server
    response.  When there is a query for a Perimeter node, the server
    would include the associated Perimeter BEGIN record from earlier in
    the hierarchy, if the queried node is within that hierarchy -- that
    is, is above the actual or virtual END record.  (As for any
    information supplied through the Additional section, the responding
    server will need to be modified to provide this enhanced information
    for specific kinds of queries.)

That bit in the parentheses, who does the modifying, and how does it get 
into the running versions of BIND and NSD and PowerDNS and all the other 
DNS servers and caches that people use?

Although now that I think about it, it won't work anyway.  For one thing, 
if you ask for _perim.a.b.c.tld, and there is only _perim.c.tld, the DNS 
response will be an NXDOMAIN and I don't think that DNS clients expect to 
find additional records in an NXDOMAIN response.  Or if we wave our hands 
some more and somehow make it a NODATA (positive response with no 
records), the fact that there's _perim.c.tld in the additional section 
doesn't mean that there wouldn't also be _perim.b.c.tld if you asked for 
it.  There's another whole set of failures if there's a zone cut between 
the name you ask for and the _perim above it.

So you're back to a tree walk, which is poor form in the DNS.

Don't take my word for it, ask in dnsop.  Or perhaps Tim has some 
opinions.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Apr 2019 19:54:12 -0700

> DNS servers and caches that people use?

You appear to be confusing 'adding to an implementation' with 'changing 
the protocol'.  Modifying the protocol is changing DNS.  Adding code 
might or might not be and in this case, it isn't.  It is adding a /use/ 
of /existing/ DNS mechanisms.  That's not 'changing the DNS'.

> Although now that I think about it, it won't work anyway.  For one 
> thing, if you ask for _perim.a.b.c.tld, and there is only _perim.c.tld, 
> the DNS response will be an NXDOMAIN and I don't think that DNS clients 
> expect to find additional records in an NXDOMAIN response.  Or if we 
> wave our hands some more and somehow make it a NODATA (positive response 
> with no records), the fact that there's _perim.c.tld in the additional 
> section doesn't mean that there wouldn't also be _perim.b.c.tld if you 
> asked for it.  There's another whole set of failures if there's a zone 
> cut between the name you ask for and the _perim above it.

The NXDomain looks like an interesting bit of inconvenience.  Have to 
think about it some more.

And yes, zone boundaries are always fun.  But since these are names that 
are, by definition, within a single administrative scope, I suspect 
that's solvable too.

> Don't take my word for it, ask in dnsop.  Or perhaps Tim has some opinions.
I already sent a note to dnsop, inviting them to dbound for this discussion.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 4 Apr 2019 09:43:47 -0400

I just reread my draft draft-levine-dbound-dns-01 and see that I'd 
forgotten that it says that the design would work the same with TXT 
records as with a new rrtype, since the nodes are all under prefixed 
_bound names.  See section 9 on page 8.

If you want to compare apples to apples, you might want to adjust the 
draft to compare your prefixed TXT records to my prefixed TXT records.

R's,
John

On Wed, 3 Apr 2019, John R. Levine wrote:
> they're allowed to issue it.  I know Let's Encrypt does and I suppose I can 
> ask them how many CAA records they see.
>
> feature to the DNS that puts records in the additional section triggered by a 
> specific label in the query?  I'm reasonably sure the answer is "never" but 
> you might ask dnsop to be sure.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Apr 2019 07:14:09 -0700

> draft to compare your prefixed TXT records to my prefixed TXT records.

What specific wording changes to the draft are you suggesting?

d/

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2019 12:00:47 -0400

>What specific wording changes to the draft are you suggesting?

Honestly, now that I look at it again, it's clear that none of the
proposed hacks to avoid tree walks will work, and anything that needs
tree walks is dead on arrival, so there's not much point.

If you want to keep at it, as far as I can tell, the main differences
between my 2016 proposal and this one is that I use code numbers to
identify different kinds of boundaries and you use strings, easy
enough to change either way, and yours requires walking up the tree
one level at a time which can be a lot of lookups if people send
hostile requests while mine does one lookup per defined boundary.

You might check and see if I missed anything.

R's,
John

---

From: Jothan Frakes <[email-masked]>
Date: Thu, 4 Apr 2019 13:49:01 -0700

Setting aside tree walks for holistic solutions, I see per zone utillity in
a structured format that could be implemented by a zone operator...

Us PSL volunteers often require a custom txt record as a validation of
authenticity/authority of requestor on patches that get submitted.

Not saying it swaps right in to place, but (just theorizing here) one could
enhance the integrity of sections being from an authoritative administeator
AND validate the patch by matching requests against these entries within a
zone as part of the process to tighten up a match.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 6 Apr 2019 05:36:40 -0700

>      if you ask for _perim.a.b.c.tld, and there is only _perim.c.tld,
> expect to find additional records in an NXDOMAIN response.

So indeed, this was an interesting point.

However from what I can tell, including Additional information in an 
NXDomain response is entirely legal, albeit certainly unusual.

My understanding is that it's likely careful use of a resolver library 
can retrieve the Additional information.  Some calls won't get it; 
others probably will.

The guidance for making this work is that it's seeking to emulate DNS 
wildcard behavior, through cooperative behavior by both the resolver and 
the authoritative server.

d/

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2019 11:09:17 -0400

>NXDomain response is entirely legal, albeit certainly unusual.

No argument there.

>can retrieve the Additional information.  Some calls won't get it; 

As I may have said one or two times before, this hack will require
changes to DNS servers to return additional information that they
don't return now, changes to DNS caches to store and pass through
additional information that they don't store or pass through now, and
changes to DNS client libraries to retrieve the additional information
that they don't retrieve now.  I will cheerfully bet any amount of
money that none of these changes ever happen.

>the authoritative server.

Don't forget the caches which also will need to be changed.

Once again, please compare this proposal to my 2016 proposal that uses
normal DNS wildcards and works right now with no changes to any DNS
server, cache, or client.  Using TXT records, a fair amount of DNS
crudware can probably provision it, too.  I'm not saying it's perfect,
but it's at least plausible.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 6 Apr 2019 14:14:51 -0700

On 4/6/2019 8:09 AM, John Levine wrote:
> don't return now, 

Since that statement is in the current draft, I'm not clear what insight 
is intended by your multiple repetitions of it here.

> changes to DNS caches to store and pass through

Oh?  You are saying that caches do not cache an entire response.   I did 
not find references that support that. Please document.

> money that none of these changes ever happen.

That does not match my understanding.  My understanding from a 
knowledgeable source is: "APIs such as those in libresolv that deal in 
raw packets do tend to make the entire packet available.  Others such as 
`getaddrinfo` do not."

Since you appear to be claiming otherwise, please explain.

Worse, I even found an RFC with multiple examples of Additional 
information in an NXDomain response:

    Negative Caching of DNS Queries (DNS NCACHE)

    https://tools.ietf.org/html/rfc2308

> Once again, please compare this proposal to my 2016 proposal that uses

If you wish to do the work of a careful audit of the differences and 
similarities, and pursue a pointed review of the similarities and 
differences, perhaps that will facilitate conversation.  It would 
certainly improve the tone.

d/

d/