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
> -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
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
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
> 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
> 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
> -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
> -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
> 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)
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
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 av
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
> 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
>
> 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
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
> -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
> 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
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
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
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)
&
20 matches
Mail list logo