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] missing use case and problem statement for draft-woodworth-bulk-rr

[Woodworth, John R]

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

Thanks for your comments.

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

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

> 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] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse

[Woodworth, John R]

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

Hi John,

Thanks again for your comments.

I'm confused, wouldn't a simple NS record solve this?


Thanks,
John

>
>
> R's,
> 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] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Woodworth, John R]

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

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
>
-- 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] DNS versioning, was 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 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 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.
>
> 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,

Thanks again for your feedback.

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

>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> https://jl.ly
-- 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

[DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr

[Jim Reid]

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

___
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

[DNSOP] BULK vs. draft-ietf-dnsop-nsec-aggressiveuse

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

The RFC 8020 problem is familiar, since rbldnsd, a stunt DNS server
that does sort of the same thing BULK does, taking CIDR ranges and
turning them on the fly into DNSBL entries, gets NXDOMAIN wrong,a too.
It's been on my list of things to fix for ages.  (It doesn't even try
to do DNSSEC.)

The RFC 8020 fix is tedious but I think straightforward -- identify
every interior node in the zone that might have a BULK match below it
and return NODATA rather than NXDOMAIN.  Since the set of interior
nodes can be gargantuan this means that you have to do a tail match as
well as an exact match on BULK patterns on every query.

The aggressive NSEC problem is much uglier.  If the server does online
signing, it can return RFC 4470 white lies for names within a span
which might have BULK matches.  It's a QoI issue whether a server does
that for every NXDOMAIN in a zone that contains a BULK record, or
tries to figure out which spans could contain a match and which don't.

For offline signed zones, we're back to putting hacks in the recursive
resolvers.  Today's hack is a new flag (perhaps an EDNS0 one) that says
pretend this was a white lie, i.e., don't use this result to synthsize
NXDOMAINs.

While all this is nominally possible, I remain unconvinced that BULK
is worth all of this violence to the DNS.

By the way, is this the first time this issue has come up with BULK?
I don't see anything about it in the draft, and I don't recall it
being discussed before.  If we're still finding new incompatibilities
between BULK and the DNS, how confident are we that there aren't more
we haven't found yet?

R's,
John

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

Re: [DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes

[Lanlan Pan]

+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 any of the security
> >properties of the DNS protocol itself.
>
> I don't think this statement is true.  Why?
>
> a) DNS DDoS threats are real and there was a shift towards minimizing
>answers.  This goes in the reverse direction.  But you address this
>in both security considerations.
>
> multiple-responses Security Considerations says:
> >
> >Additional records will make DNS responses even larger than they are
> >currently, leading to larger records that can be used in DNS
> >reflection attacks.  One could mitigate this by only serving
> >responses to EXTRA requests over TCP or when using Cookies [RFC5395],
> >although there is no easy way to signal this to a client other than
> >through the use of the truncate bit.
>
> multi-qtypes Security Considerations says:
> >It should however be noted that this method does increase the
> >potential amplification factor when the DNS protocol is used as a
> >vector for a denial of service attack.
>
>
> b) UDP fragmentations - it strongly increases the risk of UDP fragmentation
>which is strongly discouraged (SHOULD NOT) in BCP 145.
>
> also multiple-responses Security Considerations says:
>
> >A malicious authoritative server could include a large number of
> >extra records (and associated DNSSEC information) and attempt to DoS
> >the recursive by making it do lots of DNSSEC validation.  However,
> >this is not considered a realistic threat; CPU for validation is
> >cheap compared to bandwidth.  This can be mitigated by allowing the
> >recursive resolver to ignore Additional records whenever it considers
> >itself under attack or its CPU resources are otherwise over-
> >committed.
>
> It should be noted, that ECC validation is more CPU intensive than RSA, as
> as such I find "CPU for validation is cheap compared to bandwidth" quite
> bold claim that should come with some data.
>
> 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:ondrej.s...@nic.czhttps://nic.cz/
>  
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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,

Unfortunately, I respectfully reject this as a statement of fact.
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.


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