> 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
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] 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
> 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 John Levine
>
> Speaking of nsec-aggressiveuse, while staring out the window of
> the train this morning it occurred to me that BULK breaks
> NXDOMAIN synthesis, too, both the NSEC kind and the RFC 8020 kind.
>
> -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
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Matthew Pounsett
>
> > On 20 July 2017 at 17:53, John R Levine wrote:
> > 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
> -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)
> >
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of John R Levine
>
> On Thu, 20 Jul 2017, Tony Finch wrote:
> > John R Levine wrote:
> >>
> >> BULK absolutely requires online DNSSEC signing,
> >
> > This basically means that BULK is a
> On 20 Jul 2017, at 16:25, Stephane Bortzmeyer wrote:
>
> 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
BULK would be
> 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)
Speaking of nsec-aggressiveuse, while staring out the window of the
train this morning it occurred to me that BULK breaks NXDOMAIN
synthesis, too, both the NSEC kind and the RFC 8020 kind.
The RFC 8020 problem is familiar, since rbldnsd, a stunt DNS server
that does sort of the same thing BULK
+1
Avoid UDP fragmentations (big response packet) on protocol level could
reduce DDoS defense cost.
Similar to the DNS ANY qtype deprecation.
Ondřej Surý 于2017年7月21日周五 上午12:41写道:
> multi-qtypes Security Considerations says:
> >The method documented here does not change
Having said that, just what level of significance would it take
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.
...BULK absolutely requires online DNSSEC signing,
13 matches
Mail list logo