Re: [DNSOP] Multi Provider DNSSEC Models

Hi Shumon, Thank you for starting good document. I think this document is also useful for DNS provider transfer (or Registrar transfer) without causing DNSSEC insecure state. Good thing is that this document doesn't depend on EPP (can be used with TLDs who doesn't employing EPP). -- Yoshiro

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

On 29 Feb 2016, at 14:27, John R Levine wrote: > The existing port and service registry already has all of the _service names, > and is updated as people invent new services. What's the benefit of > duplicating it rather than just pointing to it? I agree. Where possible, it’s

[DNSOP] DNSOP Minutes IETF101

Hi I uploaded the minutes the other day and failed to send the email Big props to Paul Hoffman on taking notes. Take a look and make sure you were quoted fairly https://datatracker.ietf.org/meeting/101/materials/minutes-101-dnsop-00 I left a copy here for the git-inclined

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

Apologies for the top post. Thanks for the commentary.  My guess is that we're starting from different assumptions. There are three questions I have about your solution - 1) Do you expect it to be usable each time a device boots?  2) If (1), how long in years to you expect it to be usable? 

[DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-00.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 : Algorithm Implementation Requirements and Usage Guidance for DNSSEC Authors : Paul Wouters

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 3/29/2018 3:38 PM, Adam Roach wrote: I still don't fully understand the nature of the objections I cite above or the assertions that having separate tables for different RRTYPEs is somehow broken. Based on my (admittedly lay) understanding of how DNS is used by other protocols, I agree with

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari wrote: > On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker > wrote: >> On 3/29/2018 1:45 PM, Warren Kumari wrote: >>> >>> I don't want to get into if this is the*right* behavior or >>> not, but it

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

On 3/29/2018 10:30 AM, Paul Vixie wrote: since the _ was chosen as nonconflicting, and since you desire to explain what it is we aren't conflicting with, and since the RFC 1035 language is both non-normative and archaic by inspection, i really think that 952 is the correct, and only correct,

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

you do not need to document what won't work. underscored names don't match the syntax for host names. that's deliberate. that's why they were created. most dns servers will allow you to associate A or rrsets with underscored names, though some might warn you about it when parsing the zone

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker wrote: > On 3/29/2018 1:45 PM, Warren Kumari wrote: >> >> I don't want to get into if this is the*right* behavior or not, but >> it seems like worth mentioning in the draft as it has much background >> already... >> I can find

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf wrote: > > Should we refuse to document such things because they’re not in well-known > open source codebases, or have otherwise not passed tests of goodness? > > It’s not a rhetorical question. Given that people are

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

On 3/29/2018 1:45 PM, Warren Kumari wrote: I don't want to get into if this is the*right* behavior or not, but it seems like worth mentioning in the draft as it has much background already... I can find nothing which states that A / cannot be associated with underscore names, but they sure

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

On Mon, Mar 26, 2018 at 9:21 PM, John C Klensin wrote: > (top post) > > Dave, > > I identified that issue as a nit deliberately. This is a WG > document and I believe the document would be improved if a less > strong assertion were made, just because the issues of what, >

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote: > > On Mar 28, 2018, at 11:19 AM, 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

Re: [DNSOP] raising the bar: requiring implementations

On Mar 28, 2018, at 11:19 AM, 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

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 2:45 PM, Paul Vixie wrote: > > i'm in general agreement with each of the assertions made at each layer of > quoting above, but i have two quibbles. > > first, they aren't reference implementations. not even BIND, which for > many years i called a

[DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

I was looking at our server to evaluate the MIXFR implementation and it seams to me that the current text covering dnssec aware client logic don't take in account that a posterior record at the addition section, by an MIXFR DNSSEC aware server, will implicitly replace the RRSIG RRset. Logic could

Re: [DNSOP] raising the bar: requiring implementations

Cisco On 3/29/18, 8:12 AM, "DNSOP on behalf of Tony Finch" wrote: Frederico A C Neves wrote: > On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote: > > > > ... I have probably missed several ...

Re: [DNSOP] A new version of mixfr

On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote: > > > 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: > >>>

Re: [DNSOP] A new version of mixfr

On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote: > > One comment, > > > > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text > > regarding NSEC3PARAM update as well. > > > > For that I suggest to change 3.1 section name and include an extra > > paragraph. > >

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

Dave Crocker wrote: The text in RFC 1035 I have in mind is: > 2.3.1. Preferred name syntax So, no, it doesn't explicitly cite the RFC number, but I read it as citing the substance. i think it's non-normative and should not be referenced in your document. this text: However, when

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

Paul, On 3/29/2018 9:31 AM, Paul Vixie wrote: in: 1.1. _Underscore Scoping ... s/[RFC1035]/[RFC952]/ (first occurrence) hmmm. I suggest listing both, since RFC1035 both cites the precedence of RFC952 as well as supplying an (apparently redundant) formal syntax specification for host name.

[DNSOP] Request for guidance on SIN

Strong Internet Names is a concept that I have been developing for about 4 years now. It is an extension of concepts that Brian LaMachia and team applied to the design of dotNET security with great success and I think it has value applied at the network level. The current draft can be found in

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

Dave Crocker wrote: On 3/28/2018 11:41 AM, Paul Vixie wrote: dave, HEREIS. --paul Cool. Thanks! ... Inline questions/comments/concerns... ... in: 1.1. _Underscore Scoping ... s/[RFC1035]/[RFC952]/ (first occurrence) hmmm. I suggest listing both, since RFC1035 both cites the

[DNSOP] Fwd: Delivery Status Notification (Failure)

Oh and if you are going to be on a mailing list, then configure your mail server so it does not spam people with reject notices. -- Forwarded message -- From: Mail Delivery Subsystem Date: Thu, Mar 29, 2018 at 11:43 AM Subject: Delivery Status

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

A bit of context here, this is probably a document you have seen before and it is one of those cleanup documents that tends to languish. The reason I asked Dave to restart work on this draft is that I was reviewing another draft (SMTPRPT) that clearly needs to register a new prefix and indeed

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

On Wed, Mar 28, 2018 at 1:12 PM, ​​ 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

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

On 3/28/2018 11:41 AM, Paul Vixie wrote: dave, HEREIS. --paul Cool. Thanks! (Sorry for the sloppy vocabulary usage. By way of an empathy signal cf, common use of 'header' in email when it should be 'header field'...) I've gone through the entire document and reviewed all occurrences RR

Re: [DNSOP] raising the bar: requiring implementations

Arsen STASIC wrote: > > Quad9 is using powerdns dnsdist as loadbalancer and powerdns recursor and > unbound [0], [1] > > [0] https://www.makeuseof.com/tag/quad9-dns-overview/ > [1] >

Re: [DNSOP] raising the bar: requiring implementations

Frederico A C Neves wrote: > On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote: > > > > ... I have probably missed several ... > > MS D'oh! Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet: Cyclonic 4 or 5.

[DNSOP] Hello, and welcome to DNS

Hi everyone, [tl;dr: check out https://powerdns.org/hello-dns/ and https://powerdns.org/hello-dns/meta.md.html ] As part of looking into the complexity of the current DNS specification, I have been pointed at earlier efforts to improve the situation, both for DNS and for other protocols.

Re: [DNSOP] raising the bar: requiring implementations

* Tony Finch [2018-03-28 16:46 (+0100)]: 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

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

my mailbox is not filled with crap from spammers, if that is what you mean. it's not empty either. :) if you want to kill off NSAP-PTR, I'd support that. /Wm On Mon, Mar 26, 2018 at 11:44 AM, Dick Franks wrote: > > On 26 March 2018 at 16:42, Paul Vixie

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

concur with Pauls assertions wrt "long tail". Picking on specific RR types to remove is a high maintenance method to put the camel on a diet. Laudable but maybe not worth the efforts needed to clean up the installed base. Perhaps these two ideas might be a better way to simplify things. 1)