Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

Michael StJohns wrote: > Interesting thoughts, thanks. I have a slightly different starting point, which doesn't disagree with your argument, but leads to somewhat different consequences. > Proposition 1 (P1):  The initial selection of a root of trust (ROT) on behalf >

Re: [DNSOP] avoiding fragmented DNS-over-UDP

ietf-dns...@johnbond.org wrote: > > https://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01 is > worth a mention specifically in relation to PMTUD Thanks for the pointer! Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Northeast Viking, North

Re: [DNSOP] Current DNS standards, drafts & charter

I have looked at the same problem Bert has, but he did present it much better than I could.  When I started thinking about this, I approached it from the point of view of "If I have to give a co-worker a document on how to build a DNS Server (Authoritative or Resolver), what would I need to

[DNSOP] Additional uses of underscore labels (was: Another look - draft-ietf-dnsop-attrleaf-05.txt)

Hi, should probably do this more systematically, but I just stumbled over another underscore label in the ACME draft: draft-ietf-acme-acme defines _acme-challenge for TXT records. The draft seems to be in Last Call right now, so it might be an RFC before the registry is established. Kind

[DNSOP] New WG for document/protocol cleanup? Re: Current DNS standards, drafts & charter

Note this discussion has started to split into (at least) two: cleaning up the DNS standard (protocol, documents, or both), possibly in a new WG; and whether/how the existing DNSOP WG needs to adjust its efforts. > On Mar 27, 2018, at 3:49 AM, Ondřej Surý wrote: > > Hi

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 05:29:18PM +0200, Matthijs Mekking wrote: > As mentioned in the meeting, I am in favor of requiring implementations > before drafts become standards. > > However, I would be opposed to limit acceptable implementations to the few > major open source DNS implementations

Re: [DNSOP] raising the bar: requiring implementations

Matthijs Mekking wrote: On 03/28/2018 05:19 PM, Mukund Sivaraman wrote: On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: I would say that most things we have adopted in the past few years do have some implementations to reference. Not when drafts are adopted, but generally before

Re: [DNSOP] New WG for document/protocol cleanup?

> On 28 Mar 2018, at 18:02, Phillip Hallam-Baker wrote: > ... long rant snipped ... > Well that is how I plan to go forward at any rate. Good for you. Please come back to the IETF once you've figured it all out and have running, interoperable code.

Re: [DNSOP] New WG for document/protocol cleanup?

open letter. Jim Reid wrote: On 28 Mar 2018, at 18:02, Phillip Hallam-Baker wrote: ... long rant snipped ... Well that is how I plan to go forward at any rate. Good for you. Please come back to the IETF once you've figured it all out and have running, interoperable

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 01:18:36AM +0530, Mukund Sivaraman wrote: > it applies. If it is nameserver territory, I absolutely want to see an > implementation in *any* of the major DNS implementations. By major, I > mean the popular ones (e.g., PowerDNS, NSD, Unbound, Knot, etc.) This is Sorry, that

Re: [DNSOP] raising the bar: requiring implementations

Also, this "Camel" in the presentation may have been a mythological beast, but the real and existing DNS Camels that struggle with their backs breaking under the weight of DNS are the DNS implementations, especially the open source ones that are underfunded and understaffed. If someone wants to

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

dave, HEREIS. --paul internet-dra...@ietf.org wrote: ... https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-06 ... in: 1. Introduction s/resource records/resource record types/ (two occurrences) in: 1.1. _Underscore Scoping s/existing resource record/existing resource record type/

Re: [DNSOP] New WG for document/protocol cleanup? Re: Current DNS standards, drafts & charter

On Wed, Mar 28, 2018 at 2:41 PM, Suzanne Woolf wrote: > Note this discussion has started to split into (at least) two: cleaning up > the DNS standard (protocol, documents, or both), possibly in a new WG; and > whether/how the existing DNSOP WG needs to adjust its

Re: [DNSOP] A new version of mixfr

No. You can have multiple nsec3 chains in a zone at the same time. Only one is active. Some may be incomplete. Named builds and destroys chains incrementally to avoid large changes. Timely ness of changes is more important than volume of changes. -- Mark Andrews > On 29 Mar 2018, at

Re: [DNSOP] Current DNS standards, drafts & charter

tjw ietf wrote: I should qualify my comments on Route 53 - I don't think they are something we should emulate, more of an example of how 3rd party vendors get away with an overly-minimal set of resource records. The words I have to describe them are generally not polite. i remember being

Re: [DNSOP] Current DNS standards, drafts & charter

matt, the rfc document set is innately time-series. this was seen as a strength compared to some "document set in the sky" that would be updated periodically with lineouts and additions, like for example legal codes or the ARIN PPML. i think you're very close to saying we need the latter in

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

> On Mar 24, 2018, at 10:57 PM, Ondřej Surý wrote: > > It’s interesting that there’s some NULL RR Type usage in your zones, I > suppose that some experiments. Or, maybe everyone's recent favorite, RFC 8145: 5.1. Query Format A Key Tag query consists of a standard DNS

Re: [DNSOP] A new version of mixfr

Tony Finch wrote: ... I still prefer the name "UXFR (update-style IXFR)" :-) :-). +1, if we're voting. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote: > bert hubert wrote: > > > > Well to allow the one remaining closed source DNS implementation some room, > > authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign > recursive services: Google

Re: [DNSOP] A new version of mixfr

> On 29 Mar 2018, at 9:05 am, Frederico A C Neves wrote: > > On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote: >> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote: >>> No. You can have multiple nsec3 chains in a zone at the same time. Only one

Re: [DNSOP] A new version of mixfr

On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote: > No. You can have multiple nsec3 chains in a zone at the same time. Only one > is active. Some may be incomplete. > > Named builds and destroys chains incrementally to avoid large changes. > > Timely ness of changes is more

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Ondřej Surý wrote: > It’s interesting that there’s some NULL RR Type usage in your zones, I > suppose that some experiments. Whatever the long gone original experiments that NULL was intended for that are alluded to in STD 13, NULL has some present day operational utility in that it's explicitly

Re: [DNSOP] A new version of mixfr

On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote: > On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote: > > No. You can have multiple nsec3 chains in a zone at the same time. Only one > > is active. Some may be incomplete. > > > > Named builds and destroys chains

Re: [DNSOP] A new version of mixfr

Hi Matthijs, On Wed, 28 Mar 2018 15:31:57 +0200 Matthijs Mekking wrote: > It's been a while, but I have put up a new version of the MIXFR draft: > > https://tools.ietf.org/html/draft-mekking-mixfr-02 The draft speaks of an OPCode in the IANA section and of a meta

Re: [DNSOP] A new version of mixfr

I really like this document, especially the changes to version 02. One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH must be non-zero" _and_ that "The same syntax is used to delete an RRset and to replace an RRset with an RR whose RDLENGTH is zero". I think the former

Re: [DNSOP] raising the bar: requiring implementations

I would say that most things we have adopted in the past few years do have some implementations to reference. Not when drafts are adopted, but generally before we head to WGLC I've always wanted to see someone who implemented the option in some manner. But yes, agree. On Wed, Mar 28, 2018 at

Re: [DNSOP] Current DNS standards, drafts & charter

I should qualify my comments on Route 53 - I don't think they are something we should emulate, more of an example of how 3rd party vendors get away with an overly-minimal set of resource records. The words I have to describe them are generally not polite. Tim On Wed, Mar 28, 2018 at 4:38 AM,

Re: [DNSOP] A new version of mixfr

Matthijs Mekking wrote: > > It's been a while, but I have put up a new version of the MIXFR draft: > > https://tools.ietf.org/html/draft-mekking-mixfr-02 I've had a quick skim and it looks nice. Suggestions for 2nd paragraph of intro: To keep the deltas small in

Re: [DNSOP] A new version of mixfr

On Wed, Mar 28, 2018 at 04:43:53PM +0200, Pieter Lexis wrote: > Hi Matthijs, > > On Wed, 28 Mar 2018 15:31:57 +0200 > Matthijs Mekking wrote: > > > It's been a while, but I have put up a new version of the MIXFR draft: > > > >

Re: [DNSOP] raising the bar: requiring implementations

I would love to see a hard requirement for implementations & implementation reports (like IDR has) in the charter or in the working group house rules. Early implementations (perhaps even during the hackathon) can reveal implications that might have been missed while designing the draft. In

Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

On 28.3.2018 01:18, Geoff Huston wrote: >> 3rd proposal >> >> We have one more thing which needs more manpower to be verified. Right >> now, the section 3.1. Preconditions is: >> >>> 3.1. Preconditions >>> >>> All of the following conditions must be met to trigger special >>>

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 3:46 PM, Tony Finch wrote: > bert hubert wrote: >> >> Well to allow the one remaining closed source DNS implementation some room, > > authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign > recursive services: Google

Re: [DNSOP] implementations of CSYNC?

On Wed, Mar 28, 2018 at 3:48 PM, Tony Finch wrote: > Related to the current discussion, does anyone have any links to > implementations of CSYNC? https://trac.ietf.org/trac/dnsop/wiki/implementation_reports I did the hard work and created an empty page ;-)

Re: [DNSOP] implementations of CSYNC?

Job Snijders wrote: > On Wed, Mar 28, 2018 at 3:48 PM, Tony Finch wrote: > > Related to the current discussion, does anyone have any links to > > implementations of CSYNC? > > https://trac.ietf.org/trac/dnsop/wiki/implementation_reports > > I did the hard work

Re: [DNSOP] A new version of mixfr

Tony, On 03/28/2018 04:08 PM, Tony Finch wrote: Matthijs Mekking wrote: It's been a while, but I have put up a new version of the MIXFR draft: https://tools.ietf.org/html/draft-mekking-mixfr-02 I've had a quick skim and it looks nice. Thanks. Suggestions

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: > I would say that most things we have adopted in the past few years do have > some implementations to reference. > Not when drafts are adopted, but generally before we head to WGLC I've > always wanted to see someone > who implemented the

Re: [DNSOP] A new version of mixfr

Pieter, On 03/28/2018 04:43 PM, Pieter Lexis wrote: Hi Matthijs, On Wed, 28 Mar 2018 15:31:57 +0200 Matthijs Mekking wrote: It's been a while, but I have put up a new version of the MIXFR draft: https://tools.ietf.org/html/draft-mekking-mixfr-02 The draft

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote: > I'd raise the bar even higher, to see complete implementation in a major > open source DNS implementation when it applies. Sometimes implementation > problems are very revealing (client-subnet should have gone through > this).

[DNSOP] End-to-end _underscore arguments (was: Re: [art] Another look - draft-ietf-dnsop-attrleaf-05.txt)

Folks, (long note. couldn't make it shorter...) This has been an unusually challenging journey. None of the recent comments in support of a 'simplifying' view for this registry resonated. Quite the opposite. In effect, it seemed to me as if RR type would be a lookup key, which frankly

Re: [DNSOP] A new version of mixfr

Richard, On 03/28/2018 04:44 PM, Richard Gibson wrote: I really like this document, especially the changes to version 02. Thanks:) One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH must be non-zero" _and_ that "The same syntax is used to delete an RRset and to replace an

Re: [DNSOP] raising the bar: requiring implementations

bert hubert wrote: > > Well to allow the one remaining closed source DNS implementation some room, authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign recursive services: Google OpenDNS Quad9 COTS: Nominum ... I have probably missed several ... Tony.

[DNSOP] implementations of CSYNC?

Related to the current discussion, does anyone have any links to implementations of CSYNC? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Southwest Forties, Cromarty, Forth, Tyne, West Dogger: Cyclonic becoming easterly later, 5 to 7. Rough or very rough.

Re: [DNSOP] A new version of mixfr

On 28/03/2018 15:43, Pieter Lexis wrote: > The draft speaks of an OPCode in the IANA section and of a meta > RRType in the examples and Introduction section, which is it? > > If it is an RRType, some words need to be added about the fact that > current resolvers will pass through the MIXFR query

Re: [DNSOP] A new version of mixfr

Hi Matthijs, On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote: > All, > > It's been a while, but I have put up a new version of the MIXFR draft: > > https://tools.ietf.org/html/draft-mekking-mixfr-02 > > The IETF 101 Hackathon lead to the revival of this draft. > >

Re: [DNSOP] Current DNS standards, drafts & charter

On 27 March 2018 at 20:17, Paul Vixie wrote: > I think we're discussing the same idea from different perspectives. >> > > i think so, yes. > > I think writing a new document that references other documents to say >> "here's the sections in each of these you need to implement"

Re: [DNSOP] raising the bar: requiring implementations

On 03/28/2018 05:19 PM, Mukund Sivaraman wrote: On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: I would say that most things we have adopted in the past few years do have some implementations to reference. Not when drafts are adopted, but generally before we head to WGLC I've always

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves Author : Dave Crocker

Re: [DNSOP] raising the bar: requiring implementations

An enterprise company with rather large zone which update often are "highly interested" in MIXFR. But we may be the exception rather than the rule. Tim On Wed, Mar 28, 2018 at 11:24 AM, bert hubert wrote: > On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman

Re: [DNSOP] A new version of mixfr

Frederico, On 03/28/2018 05:06 PM, Frederico A C Neves wrote: Hi Matthijs, On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote: All, It's been a while, but I have put up a new version of the MIXFR draft: https://tools.ietf.org/html/draft-mekking-mixfr-02 The IETF 101