Re: [DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

[神明達哉]

At Tue, 10 Apr 2018 14:56:53 -0400,
tjw ietf  wrote:

> This draft was widely accepted in Singapore, and the chairs were waiting for
> a revision before starting a call for adoption. That revision took a few
> months
> but it has been done and DNSOP is ready to start a call for adoption.
>
> This draft addresess the bug found in the existing RFC.
>
> This starts a Call for Adoption for draft-dupont-dnsop-rfc2845bis
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.

I support the adoption.  I've already reviewed the draft and provided
(minor) feedback:
https://www.ietf.org/mail-archive/web/dnsop/current/msg22063.html

--
JINMEI, Tatuya

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

[DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

[tjw ietf]

This draft was widely accepted in Singapore, and the chairs were waiting for
a revision before starting a call for adoption. That revision took a few
months
but it has been done and DNSOP is ready to start a call for adoption.

This draft addresess the bug found in the existing RFC.

This starts a Call for Adoption for draft-dupont-dnsop-rfc2845bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 23:59 24 April 2018

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-squash-01.txt

[Paul Vixie]

Tony Finch wrote:


To be truly pedantic it should mention that some protocols (mail at least)
forbid a trailing dot :-)


agree. no :-).

--
P Vixie

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

Re: [DNSOP] DNSSEC localized validation

[Evan Hunt]

On Tue, Apr 10, 2018 at 11:32:18AM +0100, Tony Finch wrote:
> Before the root zone was signed, [isc.org](https://www.isc.org)
> created a mechanism called "DNSSEC lookaside validation", which
> allowed "islands of trust" to publish their trust anchors in a special
> `dlv.isc.org` zone, in a way that made it easy for third parties to use
> them.

To be clear, the zone didn't have to be dlv.isc.org. That was the DLV zone
ISC provided, and there was a configuration short cut to make it easy to
use, but it's always been possible to configure BIND to use a different
DLV zone, including a local one.

> Now that the root is signed and support for DNSSEC is widespread, DLV
> has been decommissioned. But if we tweak it a bit, maybe it will gain
> a new lease of life...?

To be pedantic again, dlv.isc.org is decommissioned. DLV the protocol
is still alive and well (for now). However...

> I mentioned my localized DLV idea to Evan Hunt at IETF 101. I feared he
> would think it is too horrible to contemplate :-) but in fact he thought
> the use case is quite reasonable.

I must confess I don't remember the conversation clearly (I may have been a
jetlag zombie at the time), but I hope I warned you that in the interest of
reducing code complexity, we've been talking about refactoring the BIND
validator and stripping out the DLV code in a future release.

Use cases like the one you're describing are the reason we've been
uncertain about whether to proceed with that. I'd been assuming such use
cases would be vanishingly rare. I may have been mistaken about that.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-squash-01.txt

[Bob Harold]

On Tue, Apr 10, 2018 at 6:11 AM, Tony Finch  wrote:

> Darcy Kevin (FCA)  wrote:
> >
> > Having said that, even RFC 1034 admits that the non-dot-terminated form
> > “is often one where the trailing dot has been omitted to save typing”,
> > so if the document wants to give a nod to how DNS names are typically
> > represented in practice, that would also be fine, albeit slightly less
> > pedantic.
>
> To be truly pedantic it should mention that some protocols (mail at least)
> forbid a trailing dot :-)
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/
>
>
And web browsers, in my experience.

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

[DNSOP] DNSSEC localized validation

[Tony Finch]

I posted the following on my blog yesterday evening, but I'm posting a
tweaked copy here since this WG is the main target audience.

In order to improve the robustness of Cambridge's DNSSEC setup, I want a
revamped, localized DLV to act as an enterprise trust anchor distribution
mechanism.

Kind-of related (for resons explained below) I would also like better
support for stealth secondary servers around our campus:

* Support for DNS zone transfers over TLS

* Validation of zone contents after transfer, and automatic retransfer
  to recover from corrupted zones

A lot of this is almost there - there are RFCs and I-Ds - so most of this
message is about my use cases and how I would like to deploy these specs.

Stealth secondaries
---

At Cambridge since approximately I don't know about 25 years ago or
more, we have encouraged sysadmins to set up
[stealth secondary DNS
servers](https://jackdaw.cam.ac.uk/ipreg/nsconfig/).
This has a couple of advantages:

* It distributes the DNS resolution load, so looking up names of
  on-site services is consistently fast.

* It has better failure isolation, so the local DNS still works even
  if the University or the department have connectivity problems.

It has a disadvantage too:

* It is complicated to configure, whereas a forwarding cache has
  nearly the same advantages and is a lot simpler to configure.

* Stealth secondaries don't have any good way to authenticate zone
  transfers - TSIG only provides mutual authentication by prior
  arrangement, and part of being stealthy is there's none of that.

DNSSEC and stealth servers
--

Disappointingly, DNSSEC does not help with this stealth secondary
setup, and in some ways hurts:

* Zone transfers do not validate DNSSEC signatures, so it doesn't
  provide a replacement for TSIG. You can sort-of implement a lash-up
  ([RFC 7706](https://tools.ietf.org/html/rfc7706#appendix-B.1) has
  examples for the root zone) but if the transfer gets corrupted your
  stealth secondary goes bogus without any attempt at automatic
  recovery.

* Validation requires chasing a chain of trust from the root, which
  requires external connectivity, even when you have a local copy of
  the data you are validating. So you lose much of the robustness.

* You could in theory mitigate this by distributing trust anchors,
  but that's an much bigger configuration maintenance burden.

Work in progress


We have been living with this unsatisfactory situation for nearly 10
years, but things are at last starting to look promising. Here are a
few technologies in the works that might address these problems.

DNS-over-TLS for zone transfers
---

To provide on-the-wire security for zone transfers, we need a
one-sided alternative to TSIG that authenticates the server while
allowing the client to remain anonymous. In theory SIG(0) could do
that, but it has never been widely implemented.

Instead, we have DNS-over-TLS which can do the job admirably.
The server side can be implemented now with
[a simple configuration for a proxy like NGINX][dnspriv];
the client side needs a little bit more work.

[dnspriv]:
https://gitlab.isc.org/isc-projects/bind9/tree/master/contrib/dnspriv

Built-in support for RFC 7706
-

Authenticating the server isn't quite enough, since it doesn't provide
end-to-end validation of the contents of the zone. It looks like there
is interest in adding native support for DNSSEC authenticated zone
transfers to the open source DNS servers, so they can support RFC 7706
without the lash-ups and bogosity pitfalls.

I would like to see this support in a generalized form, so it can be
used for any zones, not just the root.

Catalog zones
-

To simplify the setup of stealth secondaries, I provide
[a Cambridge catalog
zone](https://jackdaw.cam.ac.uk/ipreg/news.html#2017-09-06).
This makes the setup much easier, almost comparable to a forwarding
configuration. If only we could do this for trust anchors as well...

DLV delenda est
---

Before the root zone was signed, [isc.org](https://www.isc.org)
created a mechanism called "DNSSEC lookaside validation", which
allowed "islands of trust" to publish their trust anchors in a special
`dlv.isc.org` zone, in a way that made it easy for third parties to use
them.

Now that the root is signed and support for DNSSEC is widespread, DLV
has been decommissioned. But if we tweak it a bit, maybe it will gain
a new lease of life...?

DLV TNG
---

DLV acted as a fallback, to be used when the normal chain of trust
from the root was incomplete. I would like to be able to set up my own
local DLV, to be used as a replacement for the normal chain of trust,
not a fallback. The advantages would be:

* When we have connectivity problems, DNSSEC validators can still work
  for local names because they will not need to chase a validation
  chain off site.

* I can distribute just one trust 

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-squash-01.txt

[Tony Finch]

Darcy Kevin (FCA)  wrote:
>
> Having said that, even RFC 1034 admits that the non-dot-terminated form
> “is often one where the trailing dot has been omitted to save typing”,
> so if the document wants to give a nod to how DNS names are typically
> represented in practice, that would also be fine, albeit slightly less
> pedantic.

To be truly pedantic it should mention that some protocols (mail at least)
forbid a trailing dot :-)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Humber, Thames, Dover, Wight, Portland: East 4 or 5, occasionally 6 except in
Dover, becoming variable 4 at times. Slight or moderate, occasionally rough in
Humber and Portland. Rain or showers, thundery except in Humber, fog patches.
Moderate or good, occasionally very poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop