Subject: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

From: IETF Secretariat <[email-masked]>
Date: Tue, 18 Jul 2017 13:24:33 -0700

The DNSOP WG has placed draft-woodworth-bulk-rr in state
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Jul 2017 09:03:17 +0200

Read, support. This is a useful addition to document how to do something.

Now, the 'outer' question of the value of reverse-DNS label binding,
thats a different conversation. I can well imagine a bunch of
bikeshed-painting, but lets focus on this as a technique for
specifying programmatic population of a zone? I like it.

So yea. I think we should have this.

G

On Tue, Jul 18, 2017 at 10:24 PM, IETF Secretariat
<[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 Jul 2017 03:58:38 -0400 (EDT)

> specifying programmatic population of a zone? I like it.

I kind of disagree.

We are adding something to DNS that's not just a new RRTYPE. It requires
code changes and has a deployment and long tail. If the only result is
that anti-spammers are no longer checking reverse PTR records, we end
up with a feature in DNS that has no use, and the anti-spammers using
another method to determine "inferior" IP addresses. DNS will be the
only party left with some legacy complication.

I would feel much better if there would be some real use csases to
justify adding special code to DNS that will instantly become obsolete.

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Jul 2017 10:37:16 +0100

> justify adding special code to DNS that will instantly become obsolete.

Yes.

For IPv4 I can't see what advantage BULK has over $GENERATE or similar
back-end provisioning scripts.

For IPv6, if we have any reverse DNS at all for end-user devices it'll
probably be just a wildcard pointing to a placeholder record identifying
the VLAN.

BULK seems like far too much cleverness applied to far too small a problem.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: Southeast, becoming cyclonic, 5 to 7, perhaps gale 8 later.
Moderate or rough, occasionally very rough later. Rain or showers. Good,
occasionally poor.

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 Jul 2017 10:40:08 +0100

> On 19 Jul 2017, at 10:37, Tony Finch <[email-masked]> wrote:
> 

+1. I'm not convinced there is a problem here that needs fixing.

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 19 Jul 2017 10:15:50 +0000

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Paul Wouters
>
> I kind of disagree.
>

Hi Paul,

Thanks for the feedback!

>
> We are adding something to DNS that's not just a new RRTYPE. It
> requires code changes and has a deployment and long tail. If the
> only result is that anti-spammers are no longer checking reverse
> PTR records, we end up with a feature in DNS that has no use, and
> the anti-spammers using another method to determine "inferior"
> IP addresses. DNS will be the only party left with some legacy
> complication.
>

I don't believe the need for this has anything to do with anti-
spammers.  We've had several requests for this feature
(as I have to believe have other ISP's).

>
> I would feel much better if there would be some real use csases
> to justify adding special code to DNS that will instantly become
> obsolete.
>

Just think of all the scripts out there today for IPv4 alone
which expand and work around the limitations of $GENERATE
(or equivalent), why not standardize this in an AXFR-able manner?

Thanks,
John

> Paul
-- 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: "Woodworth, John R" <[email-masked]>
Date: Wed, 19 Jul 2017 10:34:19 +0000

> > I would feel much better if there would be some real use
> > csases to justify adding special code to DNS that will
> > instantly become obsolete.
>
> Yes.
>

Hi Tony,

Thanks for the feedback!

>
> For IPv4 I can't see what advantage BULK has over $GENERATE
> or similar back-end provisioning scripts.
>

Really?

>
> For IPv6, if we have any reverse DNS at all for end-user devices
> it'll probably be just a wildcard pointing to a placeholder
> record identifying the VLAN.
>

In the IPv6 world, the smallest significant network is 18
and some odd quintillion (18,000,000,000,000,000,000)
addresses.

Think of this as your property (e.g. your yard).  Each IP address
in itself is small but without the sum of each, what do you have?

Suddenly, each blade of grass has value.

This is how a customer feels when they are given (sold) address space.

Thanks,
John

>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -
> I xn--zr8h punycode Hebrides, Bailey: Southeast, becoming
> cyclonic, 5 to 7, perhaps gale 8 later.
> Moderate or rough, occasionally very rough later. Rain or
> showers. Good, occasionally poor.
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Jul 2017 11:49:15 +0100

> > or similar back-end provisioning scripts.

If you're proposing a forklift upgrade of the DNS then I think you need to
make the advantages clear, rather than expecting me to guess.

> This is how a customer feels when they are given (sold) address space.

I hate mowing the grass.

Can you provide a technical reason for per-address IPv6 reverse DNS?

Where I work, we bulk populate reverse v4 DHCP pools just so we know that
they are pools. We aren't going to bother doing that with v6 because
everything is a pool, except for a relatively small number of statically
configured switches and servers and suchlike.

The other use for reverse DNS is to get a quick idea of which institution
has been allocated an address, at a finer granularity than whois can, and
without having to dig through our more detailed databases. A wildcard PTR
can do this job for v6 just fine. You can even put an APL record at the
PTR target to get the forward and reverse to match.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Fitzroy: Northwesterly 4 or 5. Moderate or rough. Showers. Good.

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 Jul 2017 12:03:58 +0100

> On 19 Jul 2017, at 11:34, Woodworth, John R <[email-masked]> wrote:
> 

What value has each IPv6 address? Or a name like host-2001-67c-1232-144-21f-5bff-fec3-ab9d.example.com? Please enlighten me.

If you have a need to generate PTRs on the fly for IPv6 addresses in your network, fine. However that doesn't seem to be a compelling reason to modify the DNS protocol and change every DNS server on the planet.

The cost/benefit optics of this draft are unclear.

---

From: [email-masked]
Date: Wed, 19 Jul 2017 13:11:59 +0200 (CEST)

> configured switches and servers and suchlike.

Much the same here. The only IPv6 addresses getting reverse DNS will
be statically configured addresses.

Steinar Haug, AS2116

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Jul 2017 10:39:22 -0700

> be statically configured addresses.

ty, ty, ty!

see also this, from 2011:

http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/

-- 
P Vixie

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2017 21:57:49 -0000

In article <[email-masked]> you write:
>code changes and has a deployment and long tail. ...

I realize that my biggest problem with this draft is not that I don't
think that it's useful -- we have lots of RFCs that turned out to be
useless but harmless.  It's that it breaks the DNS by being
egregiously not backward compatible.

I would strongly prefer if we defer consideration of this draft until
we figure out how to do DNS versioning, some way to say that this
record type (and consequently, the zone returned to this AXFR or IXFR)
requires special processing, and if you don't know how to do the
processing, don't guess.  This would update or perhaps even replace
RFC 3597.

We did this in a horrible ad-hoc way with DNSSEC, and even with DNSSEC
there's the fallback that the unsigned answers you get from a server
that doesn't understand RRSIG et al. are for many purposes adequate.
But with BULK, if a secondary doesn't understand it, the answers will
just be wrong.

This might be something like an EDNS item which includes the
need-to-understand rrtypes, but I'd prefer to do it in a way that will
make the AXFR or IXFR result invalid to an old server that doesn't
understand it.

R's,
John

PS: h/t to Andrew Sullivan who replied to my suggestion that people do
BULK in a stunt server by noting that we're here to make things
interoperate.

---

From: "Woodworth, John R" <[email-masked]>
Date: Thu, 20 Jul 2017 00:44:09 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Tony Finch
>

Hi Tony,

The main reason I can think of is compatibility.

This (BULK-like functionality) is actually happening today.  In fact
several vendors have been offering this very feature in various
incompatible ways simply because of the demand for it.

Why not offer it in a way everyone can benefit?  We continue to receive
requests for this feature and it just made sense to offer it in
a way that zones could be AXFR'd back and forth regardless of vendor
and interoperate in a compatible manner.

>
> Where I work, we bulk populate reverse v4 DHCP pools just so we know
> that they are pools. We aren't going to bother doing that with v6
> because everything is a pool, except for a relatively small number
> of statically configured switches and servers and suchlike.
>

When we came up with the concept, it was to solve a v4 problem
and in a way naively believed the basic concept of a minor paradigm
shift from an already existing feature ($GENERATE) would be happily
accepted by the community.

We have literally millions of $GENERATE-based synthesized records
on the IPv4 side of the house.  We see a variety of uses, sure
a majority are pools and rfc2317 delegations but they are all still
there eating memory whether used or not.

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Thu, 20 Jul 2017 01:17:34 +0000

> From: Jim Reid [mailto:[email-masked]]
>
> What value has each IPv6 address? Or a name like
> host-2001-67c-1232-144-21f-5bff-fec3-ab9d.example.com? Please
> enlighten me.
>

Hi Jim,

I guess beauty (or value) is in the eye of the beholder :)

Although in practice the name would likely be shorter and potentially
include other customer attributes,
say acmewabbit-21f-5bff-fec3-ab9d.example.com

   1. This shows the owner is example.com, customer acmewabbit
   2. Reverse lookups are helpful for tools (e.g. traceroute)
      and logs.
   3. Fulfills customer demand
      (not sure all their use cases but this topic shows up
       often enough to be important to them.)

>
> If you have a need to generate PTRs on the fly for IPv6 addresses
> in your network, fine. However that doesn't seem to be a
> compelling reason to modify the DNS protocol and change every
> DNS server on the planet.
>

Forget for a moment about IPv6.  This draft makes $GENERATE more
memory efficient, scales bigger, stays intact through AXFR's
and yes -it makes some nameservers (authoritative) work a bit more
as a trade-off.

The fact that IPv6 is a drastically bigger namespace and would
benefit more is simply a bonus, this is just a next-gen $GENERATE.

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Thu, 20 Jul 2017 02:12:38 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of John Levine
>
> I realize that my biggest problem with this draft is not that
> I don't think that it's useful -- we have lots of RFCs that
> turned out to be useless but harmless.  It's that it breaks the
> DNS by being egregiously not backward compatible.
>

Hi John,

As always, we welcome your comments.

Agreed, BULK is not 100% backward compatible.  Unfortunately,
we are not coming into a greenfield situation and are forced
work within the confines of where we are.

Sometimes an idea like this is better discussed over a cold beer
or N-A beverage and my next opportunity, I hope to sit with you
and others on this list.

For now, I think we've narrowed the draft opposition to two camps:

Camp#1) Don't force me to use IPv6 reverse, I simply will never

and

Camp#2) Don't break DNS, even for a second

I feel I hear and understand the concerns of both camps but believe
the problems may be being over stated.

If you choose to not use BULK for IPv6, fine.  Perhaps you may see
the benefit of $GENERATE-like synthesis that can be easily AXFR'd?

>
> I would strongly prefer if we defer consideration of this draft
> until we figure out how to do DNS versioning, some way to say
> that this record type (and consequently, the zone returned to
> this AXFR or IXFR) requires special processing, and if you don't
> know how to do the processing, don't guess.  This would update or
> perhaps even replace RFC 3597.
>
...
>
> But with BULK, if a secondary doesn't understand it, the answers
> will just be wrong.
>

If you choose a secondary, that is unaware of BULK, you will get
NXDOMAIN's when they are hit.  If BULK makes it into the top-5
DNS nameserver implementations, it's only a matter of time before
the next security concern will get the secondary back in sync and
in the meantime, maybe you can choose a compatible one.

Early adopters will see hiccups, not sure this can be avoided,
but how would delaying BULK until versioning is in place be able to
prevent it?  Wouldn't a secondary just have stale data or some
other data inconsistency based on version incompatibility?

Thanks again,
John

---

From: "John R Levine" <[email-masked]>
Date: 20 Jul 2017 10:33:48 +0200

> Camp#2) Don't break DNS, even for a second

Well, yeah, except that there's no such thing as breaking the DNS for a 
second.  If we look at the history of DNSSEC, we'd break the DNS for 
somewhere between a decade and forever.  We have tried very hard for three 
decades to avoid breaking backward compatibility, and it's hard to believe 
that this is the reason to do it.

> in the meantime, maybe you can choose a compatible one.

If only it were that simple.  BULK absolutely requires online DNSSEC 
signing, and there is no even halfway standard to distribute signing keys 
to secondary servers.  I think it would be a good thing to figure out how 
to do DNSSEC key distribution, but we are a long way away from that.  I 
think we can assume that "BULK works if you don't sign" is not a winning 
argument.

Without versioning, BULK will be endlessly flaky.  With versioning that 
keeps broken mirrors from serving it, it'd work a lot better.

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 20 Jul 2017 12:36:38 +0100

> On 20 Jul 2017, at 03:12, Woodworth, John R <[email-masked]> wrote:
> 

Well I don't recognise either of these camps.

What was it you were saying about beauty being in the eye of the beholder? :-)

I'm in Camp N (for some definition of N): where's the use case/justification for BULK and is it worth the effort?

It's not clear if the WG has fully considered the impact of BULK on signed reverse zones. Doing something to the DNS that further hinders uptake of DNSSEC is probably a bad idea IMO. YMMV. Proposed protocol changes which do that need to come with compelling benefits that outweigh this drawback.

---

From: tjw ietf <[email-masked]>
Date: Thu, 20 Jul 2017 14:09:31 +0200

Another Data Point:

One of the Apps Area ADs stopped by to tell the chairs that 1) they like
the general idea; 2) their employer has a need for this *outside of the PTR
space*; and 3) would be willing to shepherd the work through.   Now, they
also the first to admit that the Application people do the most abuse to
DNS standards (hence the need for the attrleaf document).

In fact, my employer, who is quite abusive in how they deploy CNAMEs could
very easily work up a very legitimate use case for using BULK for deploying
some of our larger zones.   Add that to the fact that my employer insists
on deploying DNS between multiple vendors - whether it is DNS software or
managed DNS services.

So while it's great to trash IPv6 rDNS (and count me first in line to trash
IPv6 anything), there are actual other reasons why this would be useful.
Just keep that in mind.

tim

On Thu, Jul 20, 2017 at 1:36 PM, Jim Reid <[email-masked]> wrote:

> I'm in Camp N (for some definition of N): where's the use
> case/justification for BULK and is it worth the effort?
>
> It's not clear if the WG has fully considered the impact of BULK on signed
> reverse zones. Doing something to the DNS that further hinders uptake of
> DNSSEC is probably a bad idea IMO. YMMV. Proposed protocol changes which do
> that need to come with compelling benefits that outweigh this drawback.
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Jul 2017 14:34:48 +0100

John R Levine <[email-masked]> wrote:
>
> BULK absolutely requires online DNSSEC signing,

This basically means that BULK is a master-only feature, which implies
that there's no need for BULK to work across zone transfers, which implies
the need to standardize it for interop is almost nonexistent.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet, Irish Sea: South or southwest becoming cyclonic, 5 to 7,
perhaps gale 8 later. Moderate or rough, becoming rough or very rough later in
Fastnet and west Lundy. Rain or thundery showers. Good, occasionally poor.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Jul 2017 10:21:22 -0400

> the need to standardize it for interop is almost nonexistent.

I don't think that follows.

The DNS market is, like the mail market did some while ago, undergoing
a period of consolidation in which a fairly small number of people
have a very large number of dependent customers.  Unfortuantely,
whereas mail is asynchronous, DNS is effectively synchronous: if the
provder has a bad day and you can't get an answer the site is down.
This means that customers want to have multiple different vendors as
their master, and they want the secondaries of those sources to offer
as much as possible the same features, even when various DNS Tricks
are in use; and they want the downstreams to be using standard
protocols.  The more we can make interoperate to support that, the
better off those users are.

It is possible this is not a case that will work for that (see John
L's note), but I think the argument that master-only features don't
need to surive zone transfers is mistaken.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 20 Jul 2017 16:31:45 +0200

On Thu, 20 Jul 2017, Tony Finch wrote:
> that there's no need for BULK to work across zone transfers, which 
> implies the need to standardize it for interop is almost nonexistent.

I can't speak for the draft's authors, but in previous correspondence I've 
gotten the impression that they believe that slaves that serve BULK can 
stay in sync via AXFR and IXFR.  Perhaps they can clarify how this is 
supposed to work.

I could sort of imagine a DNAME like scheme where the server returns the 
signed BULK and the generated record and the RRSIGs and NSECs to show that 
the name for which it was generated doesn't exist, so the cache that 
receives it can unscramble the mess, but wow, would that ever be a poster 
child for why this needs DNS versioning.

Regards,

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Jul 2017 17:15:34 +0200

On Wed, Jul 19, 2017 at 12:03:58PM +0100,
 Jim Reid <[email-masked]> wrote 
 a message of 18 lines which said:

> However that doesn't seem to be a compelling reason to modify the
> DNS protocol and change every DNS server on the planet.

No. Only the authoritative servers, and not even all of them (this
BULK feature can be made optional.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Jul 2017 17:13:25 +0200

On Tue, Jul 18, 2017 at 01:24:33PM -0700,
 IETF Secretariat <[email-masked]> wrote 

> https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/

I've read it and, while I'm not convinced it can be implemented
properly (I would like to see running code), I think there is a clear
demand for that and that the solution is reasonable. I therefore
support its adoption. (Of course, as always, it does not mean I will
support the result at the end.)

I'm still hesitant with the NPN feature.

I would like the draft to be modified to make clearer that it is
non-mandatory to support BULK. For instance, setcion 3's "When an
authoritative nameserver receives a query for which it does not have a
matching name or a covering wildcard, it MUST then look for BULK RRs"
should be replaced by "When a *BULK-aware* authoritative nameserver
receives a query for which it does not have a matching name or a
covering wildcard, …"

Section 3.2.3 "longer values MUST be truncated to the width"
Left-truncated or right-truncated?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Jul 2017 17:25:59 +0200

On Wed, Jul 19, 2017 at 09:57:49PM -0000,
 John Levine <[email-masked]> wrote 
 a message of 38 lines which said:

> We did this in a horrible ad-hoc way with DNSSEC, and even with
> DNSSEC there's the fallback that the unsigned answers you get from a
> server that doesn't understand RRSIG et al. are for many purposes
> adequate.

I do not understand. If you sign on the master and forget to check the
slaves (for instance if they are BIND with dnssec-enable no), the
results are catastrophic for validating resolvers. You HAVE TO know
and check your secondaries. It is the same with BULK as it is with
DNSSEC.

And DNSSEC is not the only case where we introduced RRtypes where you
have to check your slaves to be sure they support it. There was also
DNAME.

That's why I don't share the fears about BULK: you cannot easily
deploy a new feature that will require a change in the resolvers,
because you don't know all the resolvers, and cannot change them even
if you know they are too old. But your secondaries are only a small
set of carefully chosen servers, and you have your say.

---

From: "John R Levine" <[email-masked]>
Date: 20 Jul 2017 17:53:46 +0200

> set of carefully chosen servers, and you have your say.

I hear otherwise from people who run big DNS farms.  It's common to use 
multiple secondary providers, and it's hard to tell who's running what 
server software.  I also note that it took about a decade before people 
felt comfortable using DNAMEs.

Regards,

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 21 Jul 2017 21:19:14 +0200

> felt comfortable using DNAMEs.

Dear $VENDOR.

I'm a customer who is considering deploying the BULK RR type into my zone,
and I would like to know whether your systems support it.

Thank you,
$CUSTOMER.

That said.. there is still an issue with key distribution for online
signing which is required to make this work.   I see the utility in BULK,
but I'm persuaded that there needs to be more work before it's deployable
in an environment where *XFR is required.

---

From: "Peter van Dijk" <[email-masked]>
Date: Sat, 22 Jul 2017 01:55:58 +0200

Tim,

> on deploying DNS between multiple vendors - whether it is DNS software 

It would be very helpful if the mentioned AD, or your employer, could 
elaborate on these use cases. As it stands we (PowerDNS) do not see the 
point of BULK (even though we are capable of online signing and thus 
have it easier than some of the other name servers), but we could 
certainly be convinced otherwise.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Peter van Dijk" <[email-masked]>
Date: Sat, 22 Jul 2017 01:58:59 +0200

Hello John,

>    2. Reverse lookups are helpful for tools (e.g. traceroute)

1 and 2 could be covered with a wildcard PTR, as I think Tony Finch 
pointed out.

> and yes -it makes some nameservers (authoritative) work a bit more

One could make $GENERATE more efficient without actually implementing 
the BULK RR, by taking your pattern matching logic and implementing it 
inside the name server. Of course, this makes generating the NSEC/NSEC3 
chain much harder than it is with today’s $GENERATE implementations 
that actually generate all the names.

A very interesting puzzle would be implementing BULK support, based on 
the pattern matching in the draft, -without- doing NSEC(3) white/black 
lies - i.e. generating the widest possible NSEC instead of the narrowest 
one. For NSEC3 I suspect this is not feasible.

Kind regards,

---

From: "John R Levine" <[email-masked]>
Date: 22 Jul 2017 06:06:44 +0200

> and I would like to know whether your systems support it.

Dear $CUSTOMER,

Thank you for your question.  Here at $VENDOR we take pride in our 
six-sigma state of the art customer focused service.  We use industry 
standard Apache and BIND software on most of our systems, and nginx and 
NSD on the rest.  Thank you for the opportunity to be of service,

Sincerely,
"Bob", $VENDOR associate customer specialist

I think you overestimate how much a typical non-specialist DNS provider 
knows about their software.  If you don't believe me, write to a few and 
ask whether they need DS or DNSKEY to make a secure delegation.

> in an environment where *XFR is required.

No kidding.

Regards,

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 04:49:27 +0000

> From: John R Levine [mailto:[email-masked]]
>

Hi John,

Thanks again for your feedback.

> Well, yeah, except that there's no such thing as breaking the
> DNS for a second.  If we look at the history of DNSSEC, we'd
> break the DNS for somewhere between a decade and forever.
> We have tried very hard for three decades to avoid breaking
> backward compatibility, and it's hard to believe that this is
> the reason to do it.
>

This is a very noble endeavor indeed, I both applaud and respect it.

Having said that, just what level of significance would it take
for us to bend in this respect?  What type of feature, etc.?

>
> ...BULK absolutely requires online DNSSEC signing,
>

Unfortunately, I respectfully reject this as a statement of fact.

There's even a provision (NPN) in the draft which offers a
reasonable method designed specifically for offline signatures.
While the NPN documentation is imperfect, we've still seen a lot
of interest it, and with the help of the WG, we feel it could
prove very useful.

Thanks,
John

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

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 05:06:51 +0000

> From: Tony Finch [mailto:[email-masked]]
>

Hi Tony,

Thanks for the feedback.

> This basically means that BULK is a master-only feature, which
> implies that there's no need for BULK to work across zone
> transfers, which implies the need to standardize it for
> interop is almost nonexistent.
>

Although BULK does actually offer an offline DNSSEC signing
solution, no such solution is required for unsigned zones which
today is where all the implementations I am aware of live anyway.

Thanks,
John

>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I
> xn--zr8h punycode Lundy, Fastnet, Irish Sea: South or southwest
> becoming cyclonic, 5 to 7, perhaps gale 8 later. Moderate or
> rough, becoming rough or very rough later in Fastnet and west
> Lundy. Rain or thundery showers. Good, occasionally poor.

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 05:13:10 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Andrew Sullivan
>
> The DNS market is, like the mail market did some while ago,
> undergoing a period of consolidation in which a fairly small number
> of people have a very large number of dependent customers.
> Unfortuantely, whereas mail is asynchronous, DNS is effectively
> synchronous: if the provder has a bad day and you can't get an
> answer the site is down.
> This means that customers want to have multiple different vendors
> as their master, and they want the secondaries of those sources to
> offer as much as possible the same features, even when various DNS
> Tricks are in use; and they want the downstreams to be using
> standard protocols.  The more we can make interoperate to support
> that, the better off those users are.
>

Hi Andrew,

Thanks for the feedback and support!

Thanks,
John

---

From: "John R Levine" <[email-masked]>
Date: 22 Jul 2017 08:33:30 +0200

> for us to bend in this respect?  What type of feature, etc.?

For DNSSEC the issue was the fundamental integrity of the DNS.  I 
think it's fair to say that this isn't that.

> There's even a provision (NPN) ...

  ... which only works if you upgrade every validating resolver.  If you 
get to do that, you might as well just send the signed BULK record, the 
NSEC and RRSIG that show there's nothing at the name, and let the resolver 
figure it out.  Given how slowly people update their client DNS libraries, 
NPN would be a recipe for decades of DNS flakiness, as some resolvers 
accept the generated records and some don't.

As I said a few messages ago, this really needs to wait until we figure 
out how to signal DNS versioning, and if we don't want to wait for every 
resolver in the world to be updated, how to distribute signing keys along 
with AXFR/IXFR to allow online signing to work portably.

I'm not opposed to BULK because I don't think it's useful -- there are 
plenty of RRs that are useless but harmless.  But I really don't want to 
break the DNS, particularly for something that is at most arguably useful.

R's,
John

PS: I hope it's self evident why "it doesn't matter because hardly anyone 
uses DNSSEC" is not a persuasive argument.

---

From: Jim Reid <[email-masked]>
Date: Sat, 22 Jul 2017 19:05:58 +0100

> On 20 Jul 2017, at 02:17, Woodworth, John R <[email-masked]> wrote:
> 
> this is just a next-gen $GENERATE

Indeed. We all get that. However $GENERATE is a BIND-ism, like views. It’s not part of the DNS protocol. I’m not yet convinced $GENERATE (albeit with a BULK makeover) needs to be.

The use case for BULK still hasn’t been made IMO.

---

From: Jim Reid <[email-masked]>
Date: Sat, 22 Jul 2017 19:59:32 +0100

> On 20 Jul 2017, at 16:25, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> That's why I don't share the fears about BULK

BULK would be an RRtype which *by design* prevents another part of the DNS from working. That’s just wrong. Behaviour like that might be acceptable for a non-trivial protocol change like a new header bit or EDNS option (say). But a new RRtype? Really?

BTW, if there are cases where an ISP’s customers care about reverse DNS for their IPv6 addresses, what’s stopping those customer devices using dynamic update to provision their names or have the DHCP server do that for them? Why can’t the ISP's provisioning systems and tools spit out PTR records for the IP addresses which need this secret sauce?

It’s still not clear to me what problem is actually being fixed by BULK and why no other provisioning mechanism is applicable.

If the WG is to adopt this draft, I think there first has to be a clear problem statement backed by use cases. [Prettier log files doesn’t do it for me. YMMV.] That way, the WG will be able to decide how well the final version of the document addresses these requirement if/when it gets to WGLC.

Apologies for introducing a meaningful and relevant Subject: header.

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 21:23:24 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of John R Levine
>
> I can't speak for the draft's authors, but in previous correspondence
> I've gotten the impression that they believe that slaves that serve
> BULK can stay in sync via AXFR and IXFR.  Perhaps they can clarify
> how this is supposed to work.
>

Hi John,

First, let me state *I LOVE DNSSEC* but this was definitely not
always the case.  In fact it took nearly a decade for me to go
from: "Why are they solving for a nuclear meltdown of SSl/TLS/PKI?"
to:   "Why isn't this everywhere already?!"

Wherever I was on this path, DNSSEC's eventual ubiquitousness was
always assumed.

However, even now while my group is actively promoting DNSSEC
adoption, from where I sit, I see roughly 1/10 of 1% authoritative
zones with DNSSEC enabled and believe me, most of those 0.1% were
by mandate and not choice.

I write this not as discouragement, reason to dismiss or to
point out failure, as this is *my* community and *my* responsibility
to see it succeed and thrive.  Rather, this is to point out
opportunity where it can be seen.

Dean (co-author) and I believe the success of DNSSEC is
vital to the future of the Internet and hope to play active
roles in its future.  However, as stated its low adoption rate
offers an opportunity to make changes before critical mass makes
it much more complicated.

I see no reason to delay technology like NSEC5 and BULK out of
fear it will slow the adoption of DNSSEC but rather see this as
an opportunity to move forward in parallel and meet this new
landscape we are all building.

As this progress is made, I would like to propose a phased-in
approach for BULK which can be added to the draft a la IPv6.

  Phase-1) BULK only assumed to work on *own* authoritative
           nameservers with insecure zones

  Phase-2) BULK only assumed to work with *some* external
           backup nameservers with insecure zones

  Phase-3) BULK only assumed to work with *most* external
           backup nameservers with insecure zones

  Phase-4) BULK only assumed to work on with *some*
           validating nameservers

  Phase-5) BULK works on all authoritative nameservers
           and validating nameservers

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 21:30:50 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Stephane Bortzmeyer
>

Hi Stéphane,

Thanks again for your comments and encouragement.

>
> > The DNSOP WG has placed draft-woodworth-bulk-rr in state Candidate for
> > WG Adoption (entered by Tim Wicinski)
> >
> properly (I would like to see running code),
>

We are working on this at the moment.

>
> I think there is a clear demand for that and that the solution
> is reasonable. I therefore support its adoption. (Of course,
> as always, it does not mean I will support the result at the end.)
>

Thanks.

> I'm still hesitant with the NPN feature.

Understood.

>
> I would like the draft to be modified to make clearer that it
> is non-mandatory to support BULK. For instance, setcion 3's
> "When an authoritative nameserver receives a query for which
> it does not have a matching name or a covering wildcard, it
> MUST then look for BULK RRs"
> should be replaced by "When a *BULK-aware* authoritative
> nameserver receives a query for which it does not have a
> matching name or a covering wildcard, …"
>

I would like to have a discussion with you sometime about this.

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 21:40:08 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Matthew Pounsett
>
> I hear otherwise from people who run big DNS farms.  It's common to
> use multiple secondary providers, and it's hard to tell who's running
> what server software.  I also note that it took about a decade before
> people felt comfortable using DNAMEs.
>

Hi Matthew,

Thanks for your comments.

I hear and understand your concerns.  We have similar concerns but
*I* feel we could offer a phased-in approach to set everyone's
expectations appropriately.  If one chooses to step ahead of the phase
at least they'd have an idea what troubles await them.

>
> Dear $VENDOR.
>
> I'm a customer who is considering deploying the BULK RR type into my
> zone, and I would like to know whether your systems support it.
>
> Thank you,
> $CUSTOMER.
>
>
> signing which is required to make this work.   I see the utility in
> BULK, but I'm persuaded that there needs to be more work before it's
> deployable in an environment where *XFR is required.
>

Online signing in this environment will not be possible until this
is solved but I believe the phased in approach would give us the time
to solve for it without delaying insecure deployment (phase1).

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 22:20:09 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Peter van Dijk
>
> Hello John,
>
> 1 and 2 could be covered with a wildcard PTR, as I think Tony Finch pointed out.
>

Hi Peter,

Wildcards are a good start, or at least they appear so on the surface.

Unfortunately, the vagueness of their definition and various
implementations of wildcards would make this a poor choice.

Not to mention, wildcards will severely fragment the namespace once
real PTRs are introduced creating a rather fine mess.

This would also add another level of complication and restrict the
layering capabilities we are attempting to introduce and would
inevitably prove far more problematic and resource intensive than
you might expect, simply to compensate for all the fragmentation.

> > memory efficient, scales bigger, stays intact through AXFR's and yes
> > -it makes some nameservers (authoritative) work a bit more as a
> > trade-off.
>

This would still be a vendor-hack (bind) and not a standard.  We are
looking for a vendor agnostic solution and feel a standards body is
ultimately right choice.  Additionally, this does not address the
ability to AXFR the 'intent' ($GENERATE).

>
> A very interesting puzzle would be implementing BULK support, based
> on the pattern matching in the draft, -without- doing NSEC(3)
> white/black lies - i.e. generating the widest possible NSEC instead
> of the narrowest one. For NSEC3 I suspect this is not feasible.
>

Unfortunately, there are lots of ways DNS is abused to provide an
undue prejudice against huge swaths of mild-mannered, legitimate IPs.

While our solution (NPN) offers the same opportunity for abuse, it
doesn't preemptively defeat other options, such as online signing
where BULK generated records are *exactly* like any other record.

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 22:37:51 +0000

> Indeed. We all get that. However $GENERATE is a BIND-ism, like
> views. It’s not part of the DNS protocol. I’m not yet
> convinced $GENERATE (albeit with a BULK makeover) needs to be.
>

Hi Jim,

Thanks again for your comments.

Wow, tough crowd...  glad I wasn't in the WG to see all the
"Just use [Del] key!" comments when SPF floated in.  ;{>

Thanks,
John

---

From: "Woodworth, John R" <[email-masked]>
Date: Sat, 22 Jul 2017 22:58:11 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Jim Reid
>
> BTW, if there are cases where an ISP’s customers care about
> reverse DNS for their IPv6 addresses, what’s stopping those
> customer devices using dynamic update to provision their names
> or have the DHCP server do that for them? Why can’t the ISP's
> provisioning systems and tools spit out PTR records for the IP
> addresses which need this secret sauce?
>

Hi Jim,

How exactly does a hide-the-body scheme solve the issue?  Do we
really want a /64 to be dynamically updated because we shift the
problem back to them?

We've actually had requests narrowed to a simple /96 to help with
their problem, as if shrinking their request to simply the equivalent
of the IPv4 Internet would help :) .

Other providers are more than willing to bestow a solution to
our customers today, *actually* polluting DNS with all the doomsday
fears you're touting becoming fulfilled.

Why wouldn't we want to take the opportunity to take this on as a
community and guide it the way we want, within the boundaries we set,
and with the standards support (DNSSEC, etc.) we want to promote?

Thanks,
John

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 23 Jul 2017 00:27:38 GMT

> From: "Woodworth, John R" <[email-masked]>

> This would still be a vendor-hack (bind) and not a standard.

The examples I've noticed in this thread look similar to RPZ patterns,
although perhaps I've missed examples that do not fit the RPZ mold.

RPZ is not exactly a standard and certainly not without controversy,
but it is documented and available for more than BIND.
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/

RPZ is officially only for recursive resolvers, but that is because
superficially it makes little sense for an authority to rewrite its
own response.  However, RPZ works on authorities (masters) in at
least BIND.

Could RPZ be a partial solution to the problem that the BULK RR
would solve?

I agree that a statement of the problems solved by the BULK RR would
be good.

Vernon Schryver    [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Mon, 24 Jul 2017 09:29:59 +0100

> On 22 Jul 2017, at 23:58, Woodworth, John R <[email-masked]> wrote:
> 
> How exactly does a hide-the-body scheme solve the issue?

I don’t understand the question and have no information/contaxt that would allow me to give a meaningful answer.

What do you mean by “hide-the-body”? And what is “the issue”?

AFAICT you have still to define a use case or problem statement. Until this gets done, nobody can be really sure what problem is supposedly fixed by BULK.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 24 Jul 2017 14:55:19 +0200 (CEST)

----- Original Message -----
> From: "John R Levine" <[email-masked]>
> To: "Woodworth, John R" <[email-masked]>
> Cc: "dnsop" <[email-masked]>
> Sent: Saturday, 22 July, 2017 08:33:30
> Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG
> Adoption"

> accept the generated records and some don't.

+1

Personally, I think NPN should be just dropped as John L. is correct in his assessment here.

I still think BULK is too complicated[*], but I understand the value
of interoperability between DNS server vendors.

* - compare to our synthrecord plugin:
https://www.knot-dns.cz/docs/2.5/html/modules.html#synthrecord-automatic-forward-reverse-records

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 24 Jul 2017 09:02:05 -0400

> at least they'd have an idea what troubles await them.

Something's wrong with your email client.  Your quoted text above was not
me.

> What's your mechanism for enforcing (or even signalling) this phased
approach in the DNS?

---

From: Tony Finch <[email-masked]>
Date: Mon, 24 Jul 2017 14:43:58 +0100

Peter van Dijk <[email-masked]> wrote:
> inside the name server.

Andrew Sullivan was right to say that there is an advantage to having BULK
as an RR compared to the $GENERATE master file directive, because an RR
makes it easier to interoperate across multiple providers in a
multi-master DNS setup.

I guess a BULK that is just a standardized version of $GENERATE (with
multi-master-only online signing when there's an unfeasible number of
generated records) isn't a completely terrible idea, though it's a lot
less complicated than the current draft.

I'd still like to see lots more specific examples of how it could be used
other than for v6 reverse DNS.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fisher, German Bight: Northeast backing north 3 or 4, occasionally 5. Slight.
Showers. Good occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Mon, 24 Jul 2017 14:51:40 +0100

> implementations of wildcards would make this a poor choice.

Do you mean there are problems with RFC 4592? If so, what are they?
Can you give us details, please?

> real PTRs are introduced creating a rather fine mess.

In what way? What do you mean by "fragmented"?

A reverse lookup would get a generic wildcard PTR for unregistered
addresses and a specific PTR for registered hosts. If you choose the PTR
names sensibly then I don't think the namespace would be fragmented.

The main disadvantage (same as BULK) is that it would screw up mail server
anti-spam heuristics.

> you might expect, simply to compensate for all the fragmentation.

Can you unpack this in more detail please?

What are these layering capabilities you refer to?

Why do you think wildcards are more resource intensive than BULK?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Dover: Northwest 4 or 5, occasionally 6 at first. Slight. Rain. Moderate or
good.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Jul 2017 10:08:39 -0700

Tony Finch wrote:
> Peter van Dijk<[email-masked]>  wrote:

i think there's only an advantage if zone slaves, and not just 
multi-masters, can generate responses from the BULK record.

-- 
P Vixie

---

From: "Woodworth, John R" <[email-masked]>
Date: Mon, 31 Jul 2017 19:13:14 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Vernon Schryver
>
> > > One could make $GENERATE more efficient without actually
> > > implementing the BULK RR, by taking your pattern matching logic and
> > > implementing it
> > ...
>

Hi Vernon,

Thank you for your question.

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/

I'm no expert on RPZ (and am certainly not a coauthor for it ;) ) but
my understanding is it is a policy driven blackhole list.

After scanning through the link you provided I am now a true RPZ fan.

That said, I do not believe it will help solve our problem.

Our goal is to expand on $GENERATE and make its *intent* survive
AXFR's with the end result being indistinguishable from that of a
$GENERATE.

Thanks,
John
> I agree that a statement of the problems solved by the BULK RR
> would be good.
>
>