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

[Petr Špaček]

On 24.7.2017 15:43, Tony Finch wrote:
> Peter van Dijk  wrote:
>>
>> 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.
> 
> 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 agree that a BULK version simplified to bare bones (auth side only)
might closer to acceptable. Still, it will not solve interoperability
problem because we would need a mechanism to transfer signing keys along
the BULK RR.

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

Yes please, use-cases would be very welcome.


Right now it seems like *a lot* of complexity which is in my eyes not
justified. Thank you for understanding.

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Woodworth, John R]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Vernon Schryver
>
> > From: "Woodworth, John R" 
>
> > > One could make $GENERATE more efficient without actually
> > > implementing the BULK RR, by taking your pattern matching logic and
> > > implementing it
> > ...
>
> > This would still be a vendor-hack (bind) and not a standard.
>

Hi Vernon,

Thank you for your question.

>
> 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/
>

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
>
> 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 Schryverv...@rhyolite.com
>
-- 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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

Tony Finch wrote:

Peter van Dijk  wrote:

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.


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 think there's only an advantage if zone slaves, and not just 
multi-masters, can generate responses from the BULK record.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Woodworth, John R  wrote:
>
> 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.

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

> Not to mention, wildcards will severely fragment the namespace once
> 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.

> 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.

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    http://dotat.at/  -  I xn--zr8h punycode
Dover: Northwest 4 or 5, occasionally 6 at first. Slight. Rain. Moderate or
good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

> From: "Woodworth, John R" 

> > One could make $GENERATE more efficient without actually implementing
> > the BULK RR, by taking your pattern matching logic and implementing it
> ...

> 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 Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Woodworth, John R]

> From: Jim Reid [mailto:j...@rfc1035.com]
>
> > On 20 Jul 2017, at 02:17, Woodworth, John R 
> >  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.
>

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
-- 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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Woodworth, John R]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] 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,

Thanks for your comments.

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.

>
> > 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.
>
> 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.
>

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

>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
-- 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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Woodworth, John R]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] 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)
> >
> > The document is available at
> > 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),
>

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, …"
>
> Section 3.2.3 "longer values MUST be truncated to the width"
> Left-truncated or right-truncated?
>

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


Thanks,
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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 20 Jul 2017, at 02:17, Woodworth, John R  
> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

Hello John,

On 20 Jul 2017, at 3:17, Woodworth, John R wrote:


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.


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



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.


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,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Tue, Jul 18, 2017 at 01:24:33PM -0700,
 IETF Secretariat <ietf-secretariat-re...@ietf.org> wrote 
 a message of 11 lines which said:

> 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/

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?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

sth...@nethelp.no wrote:

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.


Much the same here. The only IPv6 addresses getting reverse DNS will
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[sthaug]

> 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.

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

Steinar Haug, AS2116

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 19 Jul 2017, at 11:34, Woodworth, John R  
> wrote:
> 
> 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.

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Woodworth, John R  wrote:

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

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.

> 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.

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    http://dotat.at/  -  I xn--zr8h punycode
South Fitzroy: Northwesterly 4 or 5. Moderate or rough. Showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Woodworth, John R]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] 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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 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.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 19 Jul 2017, at 10:37, Tony Finch  wrote:
> 
> BULK seems like far too much cleverness applied to far too small a problem.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Paul Wouters  wrote:
>
> 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.

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    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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Wed, 19 Jul 2017, George Michaelson wrote:


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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

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
<ietf-secretariat-re...@ietf.org> wrote:
>
> 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/
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop