Re: [DNSOP] Notice to dnsop: doh @ IETF 101

[Tim Wicinski]

On 3/9/18 16:57, Paul Vixie wrote:

so, this leaves out the proxy case described by

https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/

it would be great if one document could describe both use cases.



I would agree.  The DNSOP chairs wanted to progress this document but 
were advised not to.


tim

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

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

[Paul Vixie]

if anybody wants to work on metazones, i encourage it, and would be 
happy to remain involved if desired.


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

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

[tjw ietf]

(speaking not as chair but DNS operator)

At the last OARC, my co-worker did a lightning talk on his deployment of
MetaZones
(
https://indico.dns-oarc.net/event/27/session/7/contribution/39/material/slides/0.pdf
)

He attempted to contact the authors of the catalog-zones draft (as did I)
to talk about why this draft has some
deficiencies. but never heard back.   I felt this metazone work (which we
are efforting to open source through our employer)
should be given a deeper look.

The main problem I see is your exmaples always talk of "1 Primary DNS
Server and 1 (or more) DNS Secondary servers"
I would argue this is a severely outdated operational view, and to me feels
that you are out of touch with what
operators are actually deploying these days.

Tim
(again as myself)

On Sat, Mar 10, 2018 at 1:46 PM, Tony Finch  wrote:

> Mukund Sivaraman  wrote:
>
> > We settled on using a zone representation as it used existing zone
> > transfer protocol (and authorizations) and would involve minimal changes
> > for both implementations and operations vs. inventing a new protocol.
>
> I want to emphasize this point.
>
> In my previous job running MXs it was amazingly easy to do in-band SMTP
> call-forward address verification - one configuration was able to verify
> addresses at dozens of departmental mail servers with all sorts of
> different configurations. Trying to talk to each department's LDAP service
> (if they had one) would have been a nightmare.
>
> In my current job, I can provide a catalog zone and a bit of configuration
> advice to make it much simpler for my colleagues to run stealth
> secondaries - no need for them to adjust firewalls or scripts etc.
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Fair Isle, Faeroes, Southeast Iceland: Easterly or northeasterly 5 to 7,
> occasionally gale 8 in Fair Isle. 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

[Tony Finch]

Mukund Sivaraman  wrote:

> We settled on using a zone representation as it used existing zone
> transfer protocol (and authorizations) and would involve minimal changes
> for both implementations and operations vs. inventing a new protocol.

I want to emphasize this point.

In my previous job running MXs it was amazingly easy to do in-band SMTP
call-forward address verification - one configuration was able to verify
addresses at dozens of departmental mail servers with all sorts of
different configurations. Trying to talk to each department's LDAP service
(if they had one) would have been a nightmare.

In my current job, I can provide a catalog zone and a bit of configuration
advice to make it much simpler for my colleagues to run stealth
secondaries - no need for them to adjust firewalls or scripts etc.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fair Isle, Faeroes, Southeast Iceland: Easterly or northeasterly 5 to 7,
occasionally gale 8 in Fair Isle. 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] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

[Mukund Sivaraman]

Hi Jinmei

On Thu, Mar 08, 2018 at 11:08:37AM -0800, 神明達哉 wrote:
> At Sat, 3 Mar 2018 22:07:57 +,
> Ray Bellis  wrote:
> 
> > > Abstract: This document describes a method for automatic DNS zone
> > > provisioning among DNS primary and secondary nameservers by storing
> > > and transferring the catalog of zones to be provisioned as one or
> > > more regular DNS zones.
> >
> > This version of the Catalog Zones draft has undergone significant
> > restructuring, in particular to separate out the mechanism by which
> > single-valued and multi-valued properties are specified.
> 
> I've read draft-muks-dnsop-dns-catalog-zones-04.  I see the motivation
> of automating the synchronization of primary/secondary configurations.
> Personally, however, I'm not (yet?) convinced that this should be
> "standardized" in the form of an RFC or that this should be done
> through another tricky use of DNS.  One big reason for standardization
> is to have a unified way that is interoperable with multiple different
> vendors.  But when it comes to configuration, difference on
> vendor-specific options often matters, and unless the common basic set
> of configuration is sufficiently common, a generic and interoperable
> mechanism will be useless.  I'm not yet convinced about it regarding

Some background of how/why catalog zones feature in BIND 9.11 and the
draft came to be is that we often got feedback about requiring better
ways to provision zones and content on multiple nameservers, and
different operators had different ideas about it. They wanted to improve
performance, reduce the scope for mistakes, and have a method that
worked across implementations.

BIND 9.11 shipped with some features for different types of
requirements:

- dyndb support (not possible to update catalog, but it allows an operator to 
serve shared DB based answers, and dynamic answers)
- improvements to rndc delzone, addzone, modzone, etc. for dynamic zone 
additions/removals
- catalog zones

Catalog zones emerged after a lot of argum^wdiscussions on how to
simplify provisioning. The primary focus at the start was providing a
way to update the zone catalog (~RFC 1035 "catalog" from where catalog
zones gets its name) on primary and automatically on secondary
nameservers. It was obvious that nameservers were distributed across
organization boundaries with different administrative controls. We
settled on using a zone representation as it used existing zone transfer
protocol (and authorizations) and would involve minimal changes for both
implementations and operations vs. inventing a new protocol. The idea
has been done before as metazones by Vixie. Indeed, interoperability was
on our minds and we took care to ensure that walking zone data
structures used by existing implementations would not be sub-optimial
for this use.

The point about configuration provisioning is well put. Zone config is
also something that an operator wants to provision, but here it gets
dirty because config feature availability differs greatly among
implementations. Some operators have told us that they would like a way
for various DNS implementations to support a common config format
directly or indirectly, but doing this is easier said than done. I have
heard that there have been previous efforts for common nameserver
configuration that were abandoned.

(Without my ISC hat on, I initially imagined that the config provisoning
would be out-of-band using locally installed template config, where the
zones in the catalog would pick a template by name. For operators with a
very large number of zones (the typical use-case for catalog zones), the
same zone config is typically shared, so this would have fit in.)

The draft as it stands provides a way to specify config options within
the zone, but does not specify an explicit list of options. There is no
enthusiasm among the authors to do so in this draft.

Some people already want catalog zones draft to include a lot more
things which would further complicate it. IMO we should not attempt to
solve every possible use-case and simplify as much as possible.

> this proposal.  (in that sense, I'm curious: is there other DNS
> developer than ISC that is interested in implementing this proposal?)

So far: I was told that PowerDNS has implemented a plug-in/script that
provides support for catalog zones.

Mukund

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