Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

From: tjw ietf <[email-masked]>
Date: Thu, 9 Mar 2017 12:54:25 -0500

All

The Call for Adoption on draft-vixie-dns-rpz ended some time ago, and the
results were a solid in favor of adoption.  However, the legitmacy of the
argument in opposition to adopting seems fairly significant about certain
parts of the draft.

In discussing this with our AD, the opinion is that if this same
opposition  manifests in the IETF last call there would have
reservations about advancing it.

So if we consider this rough consensus for  the purposes of adoption
it means we believe we will be better off with an improved, working-
group-owned document then this one.

We’re going to go ahead and adopt it for DNSOP, with the intention of
resolving the concerns people expressed by keeping the status as
informational (not standards track) and making sure the cautions and
limitations the WG discussed on the use of RPZ are clear in the document.

thanks
tim
suzanne

On Tue, Dec 20, 2016 at 10:16 AM, tjw ietf <[email-masked]> wrote:

> Why not just wade into this discussion...
>
> The draft is being present as "Informational", and the point here is to
> document current working behavior in the DNS (for the past several years).
>   It is obvious that some feel this draft is a large mistake, but like
> edns-client-subnet, more operators are deploying this than one is aware of.
>
> This starts a Call for Adoption for draft-vixie-dns-rpz
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> With the holiday period upon us, we'll make this a three week call for
> adoption. This call for adoption ends on 10 January 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Mar 2017 21:27:42 +0100

> On Mar 9, 2017, at 18:54, tjw ietf <[email-masked]> wrote:

> limitations the WG discussed on the use of RPZ are clear in the document.

I don't understand how this works. 

The authors clearly stated the document will describe only what is currently implemented and they were
not willing to make changes. How can this ever turn into a real WG document?

Paul

---

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Mar 2017 08:07:57 -0500

Once a document becomes a WG document the authors are required to
incorporate WG consensus.

If this does not / is not happening, the chairs have the option /
responsibility to replace the authors with ones that do...

W

On Thu, Mar 9, 2017 at 3:27 PM, Paul Wouters <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Mar 2017 08:00:29 -0800

> On Thu, Mar 9, 2017 at 3:27 PM, Paul Wouters <[email-masked]> wrote:
...
>> The authors clearly stated the document will describe only what is
>> currently implemented and they were not willing to make changes.
>> How can this ever turn into a real WG document?

While of course Warren's caution, above to authors and the wg, is always
valid, I think this misses an important point of confusion in this 
thread and in the specified adoption of this draft:

While yes, Vernon said the goal was documenting the current
implementation, so did the wg chair:

On 12/20/2016 7:16 AM, tjw ietf wrote:
> The draft is being present as "Informational", and the point here is
> to document current working behavior in the DNS (for the past
> severalyears).

When existing work is brought into the IETF, there is always a choice 
about how the current work should related to the existing effort.  For 
anything with a significant installed base, it is common -- and 
extremely helpful -- to first issue an RFC that details current practice.

The goal of the wg, then, is to ensure that the document is clear and 
accurate and useful... in terms of the established practice.  Again, 
this is an extremely common goal for an initial effort.

It is increasingly common for such existing work to have made 
engineering choices that sit poorly with some wg participants.  While 
there can be some academic satisfaction in debating superior 
alternatives, it isn't useful when documenting existing practice.

Or are folks now seeking to have the IETF eschew running code?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: joel jaeggli <[email-masked]>
Date: Sun, 12 Mar 2017 15:52:20 -0700

> responsibility to replace the authors with ones that do...

If there's no consensus for advancing an altered or unaltered document
then that's a problem; but not one that hasn't happened before. Consent
is pert of concensus.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Mar 2017 19:23:49 -0400 (EDT)

> then that's a problem; but not one that hasn't happened before. Consent

The problem is on how to answer the call for adoption.

I am in favour of adopting it if we can update it with some of the
changes I've suggested earlier on. I do not want to adopt it unmodified
as informational RFC for running existing code.

Paul

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Mar 2017 16:38:20 -0700

On 3/12/2017 4:23 PM, Paul Wouters wrote:
> I do not want to adopt it unmodified

You do not want the IETF to document existing practice?

Really?

d/

---

From: william manning <[email-masked]>
Date: Sun, 12 Mar 2017 22:35:19 -0700

Joel,

I'd be happy to see the document proceed under two conditions:  1) it
becomes a WG document, subject to IETF change control, and 2) that the
disclaimer requested back on 20170103 be added to the document. To refresh
the collective mind, here is the missing text:

applicability statement.

This draft is documents a process and method for intercepting DNS queries
and fabricating responses to redirect the querier into a walled garden or
enclave that is NOT part of the open Internet. Adoption and acceptance of
this draft is an acknowledgement that the IETF, the IAB and ISOC reject the
principles espoused at https://open-stand.org/about-us/principles/, in
particular article 3.  Collective Empowerment insofar as the evolution of
the DNS is concerned.

On Sun, Mar 12, 2017 at 3:52 PM, joel jaeggli <[email-masked]> wrote:

> currently implemented and they were

---

From: Ray Bellis <[email-masked]>
Date: Mon, 13 Mar 2017 07:46:50 +0000

On 13/03/2017 05:35, william manning wrote:
> disclaimer requested back on 20170103 be added to the document. To
> refresh the collective mind, here is the missing text:
> 
> applicability statement.
> 
> This draft is documents a process and method for intercepting DNS
> queries and fabricating responses to redirect the querier into a walled
> garden or enclave that is NOT part of the open Internet. Adoption and
> acceptance of this draft is an acknowledgement that the IETF, the IAB
> and ISOC reject the principles espoused
> at https://open-stand.org/about-us/principles/
> <https://open-stand.org/about-us/principles/>, in particular article 3. 
> Collective Empowerment insofar as the evolution of the DNS is concerned.

Very strong -1 against that text, here!

RPZ is already in very widespread use on the open Internet, especially
as a means to protect end users against botnet C&C hosts.

Ray

ob. disclaimer - I work for a DNS vendor that implements RPZ

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Mar 2017 04:37:21 -0400

Hi,

On Sun, Mar 12, 2017 at 10:35:19PM -0700, william manning wrote:
> becomes a WG document, subject to IETF change control

Without my IAB hat on, I should think that is self-evident.  If a WG
adopts a document, it's a WG product and the WG (and thereby IETF)
gets change control of the document.  This is why the WG editors
(called "authors") of the document can be replaced at the pleasure of
the WG chairs.

> this draft is an acknowledgement that the IETF, the IAB and ISOC reject the

With my IAB hat on, this WG is not in a position to make any claims
about what the IAB does or does not reject.  IAB positions are not
subject to IETF consensus; the IETF is able to remove IAB members if
it wishes using the recall procedures, but it cannot decide what the
IAB is or is not going to say.  (I suspect the IETF is not in a
position to make claims about ISOC's views, either, but I will allow
ISOC to speak for itself.)

Therefore, even if I supported the disclaimer, which I do not, the WG
could not add it to the document.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Mar 2017 07:11:46 -0400 (EDT)

> You do not want the IETF to document existing practice?

There is a fine line between "bringing existing things to IETF to
standardize" and "bringing existing things to IETF to document".

The draft breaks DNSSEC. In its current form it would not have moved
forward if this work had been done from the start at the IETF. We would
have asked the authors to come up with a modified solution that does
not break DNSSEC. So documenting it now after the fact as RFC basically
bypasses the IETF purposefully.

I have proposed a method that would not change the RPZ response for a
non-DNSSEC client, but would add data for DNSSEC capable clients to be
notified the DNSSEC data was modified (and possibly state why) giving
DNSSEC capable clients a method to act differently, knowing the data was
changed for a reason and is not simply a DNS spoofing attack. It can be
added without breaking existing deployments. If the authors aren't willing
to do this, why should IETF rubberstamp a DNS protocol that breaks DNSSEC?

Paul

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 13 Mar 2017 09:51:43 -0400

Hi,

Per assorted comments in this thread….a couple of observations from one WG chair.

It’s my sense at least that the WG was clear that there’s some interest in publishing an informational document about RPZ, given that it’s widely deployed and considered useful by certain admins in certain situations, but that such a potential RFC should have more detailed discussion than the initial draft of drawbacks and cautions regarding the use of this technology.

It also seemed to me that the usual rules apply: authors on a WG document are committed to working through WG discussion to consensus. If that doesn’t work out, the authors can be replaced or the document abandoned.

I still think there’s a possible consensus view that will allow a version of this document to proceed, if it meets the constraints we’ve discussed. If not, we will not have consensus to advance it, and an eventual WGLC will tell us so. As our AD pointed out, that’s awkward but hardly unprecedented.

Finally, folks should feel free to offer the cautions they think the document should include, but as Andrew already noted, text that claims to speak for the IAB or ISOC or other organizations is out of scope for us as an IETF WG and will not be added to the document.

thanks,
Suzanne

> On Mar 13, 2017, at 3:46 AM, Ray Bellis <[email-masked]> wrote:
>

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 13 Mar 2017 20:06:25 +0530

Disclaimer: As a BIND developer, I've been co-maintaining RPZ for a few
years now (and have exposure to how it's used/deployed in various
places). I don't like these DNS tricks (ECS, RPZ, etc.) at all; they
reduce the elegance of DNS, but I've learned over the years that some
things are a practical necessity. They are a double-edged sword.. good
things and bad things can be done with them.

The RPZ feature was first documented as a technote by ISC. The same
authors (Vixie and Vernon Schryver) as the current draft were involved
in that effort:

https://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt

This feature is deployed out of necessity at several ISPs. Two popular
classes of deployments are:

* Preventing non-computer-savvy ("laymen") users from self-harm that may
  be caused by visiting a malware website or connecting to a rogue
  service, and collective harm to the service/global internet. For the
  RPZ illiterate among us, there are feeds available of bad domains and
  subnets that can be transferred as DNS zones into a resolver from
  providers like Spamhaus. This is similar to spam filtering by ISPs
  using DNSBLs.

* Preventing a user from visiting a blocked/restricted website as per
  that country's local laws without which a service provider cannot
  operate. E.g., to block child pornography.

It can be said that the second kind could be used as an attack on
free-speech (as it can be used to block any website), but in practice,
current deployments at ISPs are for preventing harm and it is deployed
in this way. RPZ is popular, no doubt about it.

In our world, things are not as clear as black and white. We have to
accomodate a lot of the grey area, protocols that can be used for good
and mis-used for bad.

The ISC technote linked above is now obsolete, but the derived protocol
being followed currently is loosely established among vendors (producers
and consumers of the RPZs) and uses the BIND implementation and
behaviour as a (moving) reference.

(1) Regardless of the WG adopting the current document or not, it is
    very unlikely that RPZ deployment will change due to this.

(2) As there is no standard and vendors guess or may extend the protocol
    as they wish, there is the chance of incompatibilities and more harm
    than good because there is no standard.

The WG should consider (2) more than (1). Those who want to deploy RPZ
already know how to find it, it is implemented in current DNS products
and current operator deployment is not going away because the IETF
didn't rubberstamp it.

There is no need for anyone to use a provider's resolver (implementing
RPZ lies) if they do not want their responses to be affected by RPZ. Run
your own resolver. Is there a requirement that an ISP's resolver doesn't
lie? Currently, resolvers may refuse to provide answers to queries for
practical reasons. This is only growing.. a TTL stretching draft is
being worked on by Warren and Tale that will cause resolvers to lie that
RDATA has not expired. It is a practical necessity in some
situations. (Bad things can also be done due to some ideas.)

To speak my mind, even though the current authors of this draft are the
original authors of RPZ, in the future I'd rather that the WG is able to
influence its direction and what goes into it for the same reasons that
there are objections. I don't want just the authors to decide this
outside a WG process. Towards this, I appreciate that the authors have
brought it to the IETF.

On Mon, Mar 13, 2017 at 07:11:46AM -0400, Paul Wouters wrote:
> DNSSEC capable clients a method to act differently, knowing the data
> was changed for a reason and is not simply a DNS spoofing attack. It
> can be added without breaking existing deployments. If the authors
> aren't willing to do this, why should IETF rubberstamp a DNS protocol
> that breaks DNSSEC?

In what I understood from Vixie, the authors want the current behavior
to be captured initially (so that any DNS implementation which wants to
implement the current behavior may do so in conformance, and providers
of RPZ feeds may provide them in conformance - today), and then
immediately afterwards, extended as bis within the WG. If we call the
current protocol as version 1, it has to be set in stone for what's
there today. A future version can modify it, but this version 1 cannot
be defined as anything else or current deployments will break (there are
producer and consumer sides to RPZ deployments).

I have a couple of extensions (features users want) sitting in branches
that cannot be merged into BIND master or provided to any customers
because it will implicitly extend RPZ for everybody (as BIND behavior is
more or less looked at as the reference right now).

This case of making it an informational RFC seems very similar to
CLIENT-SUBNET. RFC 7871 sucks (having co-developed the resolver
CLIENT-SUBNET implementation in BIND, I think the protocol design per
RFC 7871 is poor, not to mention the general idea), but it needed to be
done to document what's being used. I dislike the idea but several
operators desire it. Until ECS became RFC, what was documented in
various revisions of the draft changed and there were differences among
implementations. Now, if somebody comes to us and says "resolver ECS
support is broken in BIND", we can check it against RFC 7871 or point
the reporter to the RFC to demonstrate it isn't broken. Right now
there's no way for DNS RPZ implementations to check for conformance. An
ECS bis was expected but I don't want to hold my breath.

If the WG is opposed to the idea of RPZ on ethical grounds, then it is
doubtful RPZ (the idea) can be improved in any way that makes it become
any more ethical for adoption.

If the WG is not opposed to the idea of RPZ on ethical grounds, it isn't
a bad move to support adoption of this first version so that current
deployments can synchronize and the WG can take its time to revise it in
the future.

		Mukund

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Mar 2017 07:44:18 -0700

On 3/13/2017 4:11 AM, Paul Wouters wrote:
> The draft breaks DNSSEC.
...
> non-DNSSEC client, but would add data for DNSSEC capable clients to be

That sounds like an excellent bit of technical enhancement to 
consider... /after/ documenting /existing/ practice.

d/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Mar 2017 15:58:32 +0100

> On Mar 13, 2017, at 15:44, Dave Crocker <[email-masked]> wrote:
> 
> That sounds like an excellent bit of technical enhancement to consider... /after/ documenting /existing/ practice.

I would have agreed if the feature didn't break my DNS. 

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 13 Mar 2017 08:07:19 -0700

> consider... /after/ documenting /existing/ practice.

Why "after" and not "during"? That is, if the WG document tells how this 
one method of achieving a set of goals works, why not also document 
other options that could have, and might in the future, be adopted? That 
would certainly give the reader more context.

--Paul Hoffman

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Mar 2017 08:12:36 -0700

On 3/13/2017 8:07 AM, Paul Hoffman wrote:
> Why "after" and not "during"?That is, if the WG document tells how this

They are fundamentally different exercises.

A baseline document for /existing/ practice is extremely common for the 
IETF to start with.  It provides clarity to the community and a stable 
platform for enhancement work.

Groups that try to simultaneously document existing practice /and/ 
define modifications tend to produce a confused specification.

d/

---

From: Petr Špaček <[email-masked]>
Date: Mon, 13 Mar 2017 16:45:00 +0100

> define modifications tend to produce a confused specification.

I agree. Knot resolver team has some very limited implementation of RPZ
and it would be very beneficial to have a document describing current
status so we could be interoperable.

What is missing in the current draft is a versioning scheme. There
should be something which can be used to distinguish current version
from any future versions.

For this reason I propose to document current practice with exception of
adding *a minimal versioning scheme* to the draft.

When version 0 is published we can certainly work on improvements but
anything else is IMHO putting the cart before the horse.

-- 
Petr Špaček  @  CZ.NIC

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Mar 2017 09:12:08 -0700

> I would have agreed if the feature didn't break my DNS.

Actually, that's exactly the kind of reason to have existing practice 
documented inside a working group rather than outside.

Besides seeking to make such a document accurately specify the technical 
details, there is the need to document the implications.  That is 
benefits and problems.

This lays some foundation for future work, to fix problems, as well as 
add enhancements.

d/

---

From: Barry Raveendran Greene <[email-masked]>
Date: Mon, 13 Mar 2017 11:24:41 -0700

> On Mar 13, 2017, at 4:11 AM, Paul Wouters <[email-masked]> wrote:
> 
> The draft breaks DNSSEC

The draft does not break DNSSEC. How version of DNS software implement RPZ can have issues with DNSSEC. There are some software that can inject a RPZ feed and not break DNSSEC.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Mar 2017 20:28:11 +0000

> You do not want the IETF to document existing practice?

In general, yes.  However, in this case more is perhaps at stake
than documenting existing practice.  Whether we like it or not,
publication of said existing practice by the IETF will be seen as
an endorsement of that practice.  And, while the present RPZ provides
useful operational controls, there is real potential for mandated
abuse or collateral damage.

> Really?

Therefore, yes, really, it may be best to not document current
practice, and instead create a document that reduces the potential
for abuse and/or collateral damage.

If we're sending rockets up, we should care where they come down.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Mar 2017 15:07:13 -0800

> would certainly give the reader more context.

I have to say that I find it a little odd that a document
constrained to describing current practice or a currently deployed
protocol would be adopted by a working group - usually I'd
expect that to be an individual submission.  The benefits
brought by going through the working group process and developing
a working group consensus about the document seem pretty
limited in that context.

What were the authors hoping to get out of going through the
working group process?

Melinda

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Mar 2017 19:25:14 -0700

> a working group consensus about the document seem pretty

13 Mar 2017 09:12:08 -0700
https://www.ietf.org/mail-archive/web/dnsop/current/msg19545.html

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Mar 2017 19:28:19 -0700

On 3/13/2017 1:28 PM, Viktor Dukhovni wrote:
> Whether we like it or not,
> an endorsement of that practice.

This kind of assertion is frequently made, but never demonstrated with 
anything other than theory or anecdotes, the latter usually second-hand. 
  Fear of the hypothetical is an excuse for paralysis.  And it's always 
applied inconsistently.

Also it's premise is that the actual content of the document doesn't 
matter very much, since a it means that the presence of caveats will 
have no effect.

d/

---

From: Doug Barton <[email-masked]>
Date: Fri, 17 Mar 2017 00:48:05 -0700

> anything other than theory or anecdotes, the latter usually second-hand.

I agree with Viktor. If the world doesn't take what the IETF says 
seriously, why are we all wasting our time?

Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Mar 2017 19:18:27 +1100

In message <[email-masked]>, Doug Barton wr
> seriously, why are we all wasting our time?

I've had people claim that the IETF endorses NAT for IPv6 because
we published RFC6296, even citing the RFC, despite the specific
disendorcment of NAT at the beginning.

   For reasons discussed in [RFC2993] and Section 5, the IETF does not
   recommend the use of Network Address Translation technology for IPv6.
   Where translation is implemented, however, this specification
   provides a mechanism that has fewer architectural problems than
   merely implementing a traditional stateful Network Address Translator
   in an IPv6 environment.  It also provides a useful alternative to the
   complexities and costs imposed by multihoming using provider-
   independent addressing and the routing and network management issues
   of overlaid ISP address space.  Some problems remain, however.  The
   reader should consider the alternatives suggested in [RFC4864] and
   the considerations of [RFC5902] for improved approaches.

Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Barry Raveendran Greene <[email-masked]>
Date: Fri, 17 Mar 2017 06:36:07 -0700

Paul - changes to existing practice is a _new_ document. You take the existing, coded, and deployed specification in as an informational RFC. Then you start a new working group document for the full “IETF version.” 

We’ve done this for many other protocols over the last several decades. Why the push back?

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Mar 2017 15:31:15 GMT

> From: Barry Raveendran Greene <[email-masked]>
> To: Paul Wouters <[email-masked]>

> Paul - changes to existing practice is a _new_ document. You take the existing, coded, and deployed specification in as an informational RFC. Then you start a new working group document for the full "IETF version."
>
> We've done this for many other protocols over the last several decades. Why the push back?

indeed.

> > The draft breaks DNSSEC. ...

As stated, that could be seen as inaccurate.  The current de facto
standard RPZ produces modififed DNS responses that are unsigned and
so do not verify, just as if the DNS resolver were an old, pre-DNSSEC
installation.  For better or worse, DNS clients that care about DNSSEC
(i.e. that verify or just check the header bit) are not fooled by RPZ
and so in that sense the DNSSEC protocol is not broken by the draft.

The "break-dnssec" option was not in early RPZ implementations.  I
added it in response to popular demand, and I suspect it is present
in most RPZ installations.  I chose the phrase "break-dnssec" to suggest
that you should think twice before turning it on.

> > to do this, why should IETF rubberstamp a DNS protocol that breaks DNSSEC?

To somewhat mitigate rubberstamping, I'd be happy to add a simple
warning or prohibition on implementing or deploying RPZ, provided it
lacks political grandstanding and has working group consensus.

As for "fixing" RPZ+DNSSEC, the current draft specifies behavior only
for DNS recursive resolvers.  Nothing can be done in only the RPZ-using
DNS servers to securely notify clients about RPZ changes.  DNS clients
would need to be modified to look for the new signs of RPZ changes.
Exactly what those RPZ signs would be and what DNS clients should do
when they are present would have to be designed and documented.  The
scope of those client and server protocol changes would be much larger
than the scope of the current QTYPE=ANY proposal, and so more controversial
and time consuming, even if RPZ itself were not more controversial
than changing the de facto definition(s) of QTYPE=ANY.

Distinguishing a DNS spoofing attack pretending to be RPZ changes from
"honest" RPZ changes would require some sort of digital signatures,
but the trust anchor for those signatures could not be standard.  Those
non-DNSSEC-standard signatures might involve a DLV or maybe they could
use a key associated with the domain name in the RPZ SOA.  In cany
case, a complete design would be required.  That they would be
non-DNSSEC_standard implies that they could not be in the usual places,
lest pre-new-RPZ-but-verifying DNS clients see them...and those are
merely some problems that seem obvious for secure RPZ rewriting.

Note that RPZ changes are already signaled by the odd SOA specified
in draft, although it is intended only for human inspectors.  That SOA
is in the additional section, because putting it in the usual place
breaks some cases....which is another way of saying that merely adding
as yet unspecified RRSIGs to the authority section of RPZ modified DNS
responses is not something that should be without extended discussions,
plenty of real world testing, and more time than has been spent on the
QTYPE=ANY protosal.

Vernon Schryver    [email-masked]