Subject: [DNSOP] BULK RR as optional feature

From: "John Levine" <[email-masked]>
Date: 28 Mar 2017 18:31:56 -0000

At yesterday's session, Tale confirmed that since BULK adds so much
new special purpose complexity to DNS servers, the plan is that
support for it will be optional.

An optional RRTYPE with extra semantics introduces some new
compatibility problems.  What happens if a server that doesn't support
BULK tries to load a local zone file with a BULK record.  Does it
reject the whole file, ignore the record, or something else?  What if
such a server receives BULK by AXFR?  By IXFR?  What if one shows up
in a cache from a buggy authoritative server?  In all of these cases,
the current RFC 3597 behavior will just return the BULK record which
seems wrong.

I continue to think that this kind of feature belongs in special
purpose DNS servers, not in the core DNS.

R's,
John

---

From: Evan Hunt <[email-masked]>
Date: Tue, 28 Mar 2017 20:51:51 +0000

On Tue, Mar 28, 2017 at 06:31:56PM -0000, John Levine wrote:
> What if such a server receives BULK by AXFR?  By IXFR?

I agree these scenarios in particular need to be specified.

One possible solution would be an EDNS signal indicating whether or not the
secondary server implements BULK. If not, the primary would have to expand
the BULK data during transfer, same as BIND expands $GENERATE.  (I proposed
a similar sort of EDNS signaling mechanism in draft-hunt-note-rr-01 a few
years back.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "John R Levine" <[email-masked]>
Date: 28 Mar 2017 15:55:31 -0500

> the BULK data during transfer, same as BIND expands $GENERATE.

That doesn't work -- this is intended to generate rDNS for IPv6 and other 
places where you can't possibly store the full expansion.

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

---

From: Evan Hunt <[email-masked]>
Date: Tue, 28 Mar 2017 21:05:48 +0000

> places where you can't possibly store the full expansion.

It doesn't work for that particular use case, no, but there are other
benefits to BULK (the draft specifically mentions "the ability to transfer
BULK RR intentions from primary to secondary nameservers with minimal
bandwidth and memory requirements"), and a transition mechanism for
secondaries that don't implement BULK would be a useful addition.

---

From: "John R Levine" <[email-masked]>
Date: 28 Mar 2017 16:23:13 -0500

> secondaries that don't implement BULK would be a useful addition.

I don't see how it's a very useful transition mechanism.  The bit about 
transferring intentions from primary to secondary assumes the secondary 
understands the RR.  The use cases all seem to me to be stuff too big to 
do statically with generate.

Regards,

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 28 Mar 2017 20:25:22 -0400

Wouldn't a BULK RR ignorant DNS server just store the BULK RR as opaque data?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Tue, Mar 28, 2017 at 2:31 PM, John Levine <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 29 Mar 2017 00:26:16 +0000

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of John Levine
>
> compatibility problems.  What happens if a server that doesn't
> support BULK tries to load a local zone file with a BULK record.
>

Hi John,

Thanks for your beautiful question.  If a server doesn't support BULK
the RR will simply sit there like any other unrecognized RR type.

>
> Does it reject the whole file, ignore the record, or something else?
> What if such a server receives BULK by AXFR?  By IXFR?  What if one
> shows up in a cache from a buggy authoritative server?  In all of
> these cases, the current RFC 3597 behavior will just return the
> BULK record which seems wrong.
>

The BULK RR simply transfers "intent" or a "recipe" for other records.
As you indicate, it would be displayed as TYPEXX and "\#" RDATA
encoding but would not interfere with transfers.  Since this RFC3597
behavior is expected behavior, these zones could even be housed in a
nameserver without support and transferred to one with, again with
no impact to the transfer.

One thing I feel I must point out is no one other than the zone admin
really cares about the recipe just the cupcakes.  If your nameserver
can't (or won't) make cupcakes then the cupcakes just don't exist.

Not understanding the recipe is really no different than not using it.

> purpose DNS servers, not in the core DNS.

I wouldn't want to force any customers to use "XYZ" just to be able
to send us their recipes.  They probably already have tools and people
in place for managing their current "ABC" nameservers.

I would also just love for a $GENERATE to make it across the wire
intact (assuming both ends are on bind).

Thanks again,
John

> John
-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Mar 2017 17:31:44 -0700

generally, we have not worried about versioning or capability
negotiation among axfr/ixfr partners. a zone administrator can simply
choose primary and secondary servers on the basis of advertised
capabilities, and remove any who can't conform.

last time we had this discussion, it emerged that many secondary and
primary name service providers had their own private protocol and either
did not support ixfr/axfr at all, or did not support any of their
competitive extensions (like apex cname) over ixfr/axfr.

it's my view that BULK is better than $GENERATE and i would have
proposed the former rather than the latter had i known then what i know
now. i further believe that it need not be a negotiated capability
between ixfr/axfr partners.

vixie

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 29 Mar 2017 00:41:26 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Evan Hunt
>

Hi Evan,

Thanks for your comments.

>
> One possible solution would be an EDNS signal indicating whether or
> not the secondary server implements BULK. If not, the primary would
> have to expand the BULK data during transfer, same as BIND expands
> $GENERATE.  (I proposed a similar sort of EDNS signaling mechanism
> in draft-hunt-note-rr-01 a few years back.)
>

I believe this would ultimately be less efficient than generating
the records on the fly.

Assuming a relatively small range, say an IPv4 /16.  You would
need to sweep through similar logic and load _every_single_answer_
into memory rather than just the ones which are asked for.

I see no reason caching couldn't be used to hold the more commonly
requested records in order to save on CPU. (apologies for double-neg)

Additionally, the patterns could (and most likely should) be pre-
parsed for simpler/ lower calorie processing.

Thanks,
John

---

From: Evan Hunt <[email-masked]>
Date: Wed, 29 Mar 2017 02:19:35 +0000

> I believe this would ultimately be less efficient than generating

Unquestionably. This clearly wouldn't be the preferred behavior.
If the slave does understand BULK records, you'd just transfer
those.

> into memory rather than just the ones which are asked for.

Sure, that's what $GENERATE does. The generated records are then transfered
normally. You con't end up with one auth server that has generated records
and another that doesn't.

> parsed for simpler/ lower calorie processing.

But if you have a primary that supports BULK and a secondary that doesn't,
then you have two authoritative servers for the same domain with the same
serial number but one of is saying NXDOMAIN when the other one returns a
positive answer.  This is a significant problem, and the draft ought to
address it.  (Or have I misunderstood something?)

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 29 Mar 2017 03:40:32 +0000

> From: Evan Hunt [mailto:[email-masked]]
>
> If the slave does understand BULK records, you'd just transfer those.
>
> Sure, that's what $GENERATE does. The generated records are then
> transfered normally. You con't end up with one auth server that
> has generated records and another that doesn't.
>
> > I see no reason caching couldn't be used to hold the more
> > commonly requested records in order to save on CPU. (apologies
> > for double-neg)
> >
> But if you have a primary that supports BULK and a secondary that
> doesn't, then you have two authoritative servers for the same domain
> with the same serial number but one of is saying NXDOMAIN when the
> other one returns a positive answer.  This is a significant problem,
> and the draft ought to address it.  (Or have I misunderstood
> something?)
>

Hi Evan,

Thanks again for your continued feedback.  A reasonable amount of
inconsistency is expected and even tolerated in the wild today.  As
far as BULK RRs are concerned, we do touch on it in section 6.2.

   "Prior to widespread adoption on the authoritative side all generated
   records would be invisible if served on nameservers lacking support.
   Since generated records are generally NOT service impacting records
   this should be understood but not of great concern."

Should BULK RRs gain wider adoption more quickly than expected perhaps
this would not be a prolonged condition.

Making support optional, while I do not strongly oppose, would
definitely exacerbate the issue of consistency to some extent.

Thanks,
John

---

From: "John R Levine" <[email-masked]>
Date: 28 Mar 2017 22:47:02 -0500

> address it.  (Or have I misunderstood something?)

That's exactly the problem -- a server that doesn't handle BULK will 
return the wrong answer.  It might return the BULK record itself or 
NXDOMAIN for an address that BULK would synthesize.

Regards,

---

From: Evan Hunt <[email-masked]>
Date: Wed, 29 Mar 2017 04:03:41 +0000

> NXDOMAIN for an address that BULK would synthesize.

And, if the zone is signed, it'll be provably wrong.  I don't think it's
enough to handwave the problem as "not of great concern". At least,
please add some operational advice that BULK is not to be deployed in
any domain unless all auth servers for that domain fully implement it.

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 29 Mar 2017 04:24:01 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of John R Levine
>
> > But if you have a primary that supports BULK and a secondary
> > that doesn't, then you have two authoritative servers for the same
> > domain with the same serial number but one of is saying NXDOMAIN
> > when the other one returns a positive answer.  This is a significant
> > problem, and the draft ought to address it.  (Or have I
> > misunderstood something?)
>

Hi John,

Thanks again for your comment.

I am curious why you feel a nameserver unaware of a new record type
would ever return it instead of the known type it queried?

It should either exist (i.e. be BULK aware and synthesized) or
not exist (which it does not) and return NXDOMAIN.

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 29 Mar 2017 05:01:26 +0000

> And, if the zone is signed, it'll be provably wrong.  I don't think
> it's enough to handwave the problem as "not of great concern". At
> least, please add some operational advice that BULK is not to be
> deployed in any domain unless all auth servers for that domain
> fully implement it.
>

Evan,

Again, thank you.

I can see your point where more guidance could be needed here.

As far as BULK RRs in this scenario are concerned, there would still be
two provably valid states as seen from the perspective of a validating
resolver.

Either -

1) *No* BULK support on this auth NS:
   Queried RR does not exist (and actually does not exist)
   NSEC/NSEC3/etc. proves it does not exist.

2) BULK support on this auth NS:
   Queried RR does exist (is actually synthesized)
   RRSIG exists (online) proves it does exist
     - Or -
   RRSIG and NPN exist (offline)
     - proves it does exist (requires NPN aware resolver for validation)

Other options are available (e.g. insecure delegation for these RRs, etc.)

Thanks,
John

---

From: Evan Hunt <[email-masked]>
Date: Wed, 29 Mar 2017 05:42:01 +0000

> two provably valid states as seen from the perspective of a validating

But one is "this record exists" and the other is "this record does
not exist" (and a whole range of other records, if the validator implements
aggressive negative caching).  Both of these states would be provably
true at the same time, in the same domain, with the same serial number,
depending on which server you queried first and what records you have in
the cache.  I'm nervous about this.

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Mar 2017 11:56:27 +0100

Evan Hunt <[email-masked]> wrote:
>
> At least, please add some operational advice that BULK is not to be
> deployed in any domain unless all auth servers for that domain fully
> implement it.

Yes.

This is fairly similar to the requirement for DNSSEC support on auth
servers, and there wasn't any explicit signalling in the xfer protocol
in that case.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Biscay: Easterly or southeasterly 3 or 4. Slight or moderate,
becoming moderate or rough. Fair. Good.

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Mar 2017 12:46:23 +0100

Another possibly-crazy thought ...

Should BULK be allocated from the metatype range, 128-255? The idea being
that this would cause the zone xfer to be rejected by servers that don't
understand it.

... but, from looking at BIND's code (I didn't test it) I think this idea
wouldn't actually work in practice because BIND only rejects xfers
containing explicitly-known metatypes - it treats most of 128-255 as
unknown.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Viking, North Utsire, South Utsire: Cyclonic 4 or 5, becoming
southeasterly 5 to 7, perhaps gale 8 later. Moderate or rough. Rain later.
Good, becoming moderate or poor later.

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2017 08:32:55 -0500

> servers, and there wasn't any explicit signalling in the xfer protocol

I think there's a meaningful difference that we expected everyone to 
upgrade to DNSSEC eventually, while I expect I am far from the only person 
with no plans to implement this one.

As I keep saying, it's an enormous amount of new and different mechanism 
for a very narrow use case.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2017 08:34:34 -0500

> would ever return it instead of the known type it queried?

No, you're right, you'd only get the BULK if you queried for it, and you'd 
get NXDOMAIN or more likely NODATA for records that might have been 
synthesized.

As Evan points out, this leads to chronically inconsistent DNSSEC.

Regards,

---

From: "Woodworth, John R" <[email-masked]>
Date: Thu, 30 Mar 2017 18:25:28 +0000

> From: John R Levine [mailto:[email-masked]]
>
> > I am curious why you feel a nameserver unaware of a new record
> > type would ever return it instead of the known type it queried?
>
> No, you're right, you'd only get the BULK if you queried for it,
> and you'd get NXDOMAIN or more likely NODATA for records that
> might have been synthesized.
>

Hi John,

Thanks again for your feedback.

I was under the impression DNSSEC fixed problems with integrity,
not inconsistency.

While we too would prefer a more uniform rollout of BULK RR, we
also have to face the harsh reality these things will take time.

We can definitely make recommendations to lessen the impact for
early adopters but if one thing is consistent it's 'lack of
consistency'.

Thanks,
John

---

From: Evan Hunt <[email-masked]>
Date: Thu, 30 Mar 2017 18:49:14 +0000

> I was under the impression DNSSEC fixed problems with integrity,

There's an expectation that the DNS will only be loosely coherent, but the
same serial number should have the same answers, and an NSEC/NSEC3 proving
nonexistence of an answer at one auth server is going be problematic if
there is a positive answer from another.

---

From: "Woodworth, John R" <[email-masked]>
Date: Thu, 30 Mar 2017 19:05:05 +0000

> There's an expectation that the DNS will only be loosely coherent,
> but the same serial number should have the same answers, and an
>

Hi Evan,

>
> NSEC/NSEC3 proving nonexistence of an answer at one auth server
> is going be problematic if there is a positive answer from another.
>

Agreed but I feel the degree of "problematic" may be being overstated.

"If" a zone admin is aware of this limitation and "if" that zone
admin chooses to move forward with deployment to a set of
nameservers with a mix of capabilities despite the "ifs" where
is the problem?

A majority of early adopters will likely either be comfortable with
this limitation or ensure it will not impact them.

Thanks,
John

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2017 14:28:45 -0500

On Thu, 30 Mar 2017, Woodworth, John R wrote:
> "If" a zone admin is aware of this limitation and "if" that zone admin 
> chooses to move forward with deployment to a set of nameservers with a 
> mix of capabilities despite the "ifs" where is the problem?

That's a lot of "if"s.  It is quite common for primary and secondary 
providers to have only a loose relationship, and they do not know or care 
about their detailed capabilities.  I swap secondary service with a bunch 
of other people I rarely talk to (no need) and if they started sending me 
BULK records, the results would not be good.

It seems like you are assuming that everyone will eventually support BULK. 
I see no reason to assume that -- for those of us with small systems, and 
who do not want to do generic 6 rDNS (see draft-ietf-dnsop-isp-ip6rdns) 
it's just bloat.  This means it'll always be optional, and optional DNS 
features present new operational issues that we haven't begun to address.

Regards,

---

From: Bob Harold <[email-masked]>
Date: Thu, 30 Mar 2017 15:41:16 -0400

> servers, and there wasn't any explicit signalling in the xfer protocol

I agree that those choosing to use BULK would need to choose their
secondaries accordingly, similar to DNSSEC, or live with the effects of
inconsistency.

-- 
Bob Harold

---

From: "Woodworth, John R" <[email-masked]>
Date: Thu, 30 Mar 2017 20:48:57 +0000

> providers to have only a loose relationship, and they do not know or
> care about their detailed capabilities.  I swap secondary service
> with a bunch of other people I rarely talk to (no need) and if they
> started sending me BULK records, the results would not be good.
>

Hi John,

Thanks again for your time.

This seems to me more a problem of demand vs. capabilities.

If my secondary provider didn't offer a feature that was important
to me, say DKIM, I would _have_to_ contact them and request they
upgrade stressing its importance to me and my business.  If there
was no chance of support within a reasonable time-frame I would
have no choice but to move.  If enough requests were made to support
DKIM, it may justify an upgrade to that provider.  This is really no
different, if there is no demand then support is always optional.

  Not to pick on DKIM, this could really be anything, DNSSEC,
  dual-stack support, etc.

> It seems like you are assuming that everyone will eventually support

More blind optimism than an assumption :)

I would hope at least NPN validation support would be eventually
included nearly everywhere but understand even if this should turn out
to be true it will likely take many years.

>
> I see no reason to assume that -- for those of us with small systems,
> and who do not want to do generic 6 rDNS (see
> draft-ietf-dnsop-isp-ip6rdns) it's just bloat.  This means it'll
> always be optional, and optional DNS features present new
> operational issues that we haven't begun to address.
>

Agreed and if it were important to hypothetical me, hypothetical I
might hypothetically say "We're gonna need a bigger boat" :)

Thanks,
John