Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

i am restricting my CC to "dnsop@", for reasons previously given. Colm MacCárthaigh wrote: > On Thu, Mar 12, 2015 at 4:09 PM, Mark Andrews wrote: >> ... >> > >> > If one really wants to reduce the number of packets required with >> > SMTP processibg just write a RFC that says A and records

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On Thu, Mar 12, 2015 at 4:09 PM, Mark Andrews wrote: > > In message <3d558422-d5da-4434-bded-e752ba353...@flame.org>, Michael Graff > writes: >> What problem are we specifically trying to solve here again? > > A non-problem for most of us. > >> Michael > > If one really wants to reduce the number

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

> Nicholas Weaver > Saturday, March 14, 2015 5:07 AM > > ... > > Overall, unless you are validating on the end host rather than the > recursive resolver, DNSSEC does a lot of harm from > misconfiguration-DOS, but almost no good. several of us jumped for joy in

Re: [DNSOP] DNS Terminology: Glue

On Fri, Mar 13, 2015 at 7:00 PM, Paul Hoffman wrote: > Casey noticing the updated, wider definition in 2181 kinda throws a wrench > into the "what is not glue" discussion. Here is a proposed update to the > draft that includes both definitions and discusses the ramifications of the > update. > >

[DNSOP] qmail misuses the DNS standards

TL;DR: I've read DJB's messages about qmail's clever design. IMHO, qmail's use of DNS has always optimized for the wrong thing. What it should be optimizing, is client queries to the recursive server. Fixing that should be relatively simple, and would happen to make the CloudFlare deprecation of

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

I remain puzzled at the entire technological motivation that CloudFlare claims for this deliberate creation of interoperability problems. In particular, what exactly is the programming difficulty that they claim they're encountering in implementing QTYPE=*? Are they also having trouble implementin

Re: [DNSOP] DNS Terminology: Glue

Casey noticing the updated, wider definition in 2181 kinda throws a wrench into the "what is not glue" discussion. Here is a proposed update to the draft that includes both definitions and discusses the ramifications of the update. Glue records -- Resource records which are not part of the

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

According to their own statement, Cloudflare perceived the "problem" to be the code-complexity of their DNS implementation -- in particular, they characterized the complexity of their (former) QTYPE=*-handling code as "enormous". Their "fix" was to feign ignorance (RCODE=NOTIMP) of QTYPE=* and

Re: [DNSOP] DNS Terminology: Glue

On Fri, Mar 13, 2015 at 5:32 PM, Tony Finch wrote: > Casey Deccio wrote: > > > > It seems like a reference to delegation NS records is also in order, > based > > on previous discussion: > > > > From: > > "... the authoritative delegation (NS)..." > > > > To: > > "... delegation or authoritative

Re: [DNSOP] DNS Terminology: Glue

On Fri, Mar 13, 2015 at 4:13 PM, Casey Deccio wrote: > > I use the same terminology also (i.e., "delegation NS records" vs. "glue > records"). > > But it should be noted that within existing RFCs the terminology differs: > > RFC 1034 4.2.1: > > ..."glue" RRs which are not > part of the au

Re: [DNSOP] DNS Terminology: Glue

Casey Deccio wrote: > > It seems like a reference to delegation NS records is also in order, based > on previous discussion: > > From: > "... the authoritative delegation (NS)..." > > To: > "... delegation or authoritative name server (NS) records (i.e., above or > below the zone cut)..." I prefe

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

In message <968c470dac25fb419e0159952f28f0c06df65...@mem0200cp3xf04.ds.irsnet.gov>, Morizot Timothy S writes: > > DNSSEC validation is not a panacea, but if you refuse to implement it you > are denying your users one layer of protection you could pretty easily > provide. And given that in the US

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Nonsense. I'm not sure exactly what sort of attack profile you have in mind at the registrar with a, but given that the TTL for DS records is generally 24 hours, most attacks at that level will create pretty widespread DNSSEC validation errors for at least that initial day. DNSSEC validation he

Re: [DNSOP] DNS Terminology: Glue

On Fri, Mar 13, 2015 at 12:55 PM, Paul Hoffman wrote: > On Mar 13, 2015, at 9:33 AM, Evan Hunt wrote: > > Given the amount of discussion this topic has generated, and the number > of > > ways I've seen the word used in the past (and, in fact, have used it > myself > > when speaking imprecisely),

[DNSOP] A short note on the DNSOP agenda....

All We've been hammering out the agenda, and we've got more requests than we have time. We're focusing on working group items; heavy discussion items on the mailing list; and other specific items we feel need pointing out. We'll have a draft one out this this weekend. thanks for your patie

[DNSOP] RFC 7477 on Child-to-Parent Synchronization in DNS

A new Request for Comments is now available in online RFC libraries. RFC 7477 Title: Child-to-Parent Synchronization in DNS Author: W. Hardaker Status: Standards Track Stream: IETF Date: March 2015 Mailbox:

Re: [DNSOP] DNS Terminology: Glue

On Thu, Mar 12, 2015 at 2:10 PM, Paul Hoffman wrote: > On Mar 12, 2015, at 10:59 AM, Tony Finch wrote: > > > > Patrik Wallström wrote: > >> > >> Glue Name Records are defined as all NS records pertaining to the child > >> domain that are delivered by the nameservers for the parent domain. > >>

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

> On Mar 13, 2015, at 10:21 AM, Morizot Timothy S > wrote: > It’s been steadily increasing for years now and gives me an idea what > percentage of the US public is protected against certain types of attacks > involving our zones. DNSSEC validation is not a panacea, but in a layered > approach

Re: [DNSOP] Call for Adoption: draft-ogud-dnsop-acl-metaqueries

On Mar 13, 2015, at 10:25 AM, Tim Wicinski wrote: > This starts a Call for Adoption for draft-ogud-dnsop-acl-metaqueries > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ogud-dnsop-acl-metaqueries/ > > Please review this draft to see if you think it is suitable for adop

Re: [DNSOP] DNS Terminology: Glue

On Mar 13, 2015, at 11:12 AM, Edward Lewis wrote: > One of my rules about definitions is to start with a positive and not a > negative statement. Noted, but the higher-order rule we are using for this document is "quote the RFCs where possible". In fact, this particular thread was caused by us b

Re: [DNSOP] DNS Terminology: Glue

On 3/13/15, 12:55, "Paul Hoffman" wrote: > >This seems like a good addition. We would like the terminology draft to >be both definitions of terms and common mis-definitions. Do others have >thoughts on Evan's proposed addition? Much more useful that (Evan's) way. smime.p7s Description: S/MIME c

[DNSOP] quoting : was Re: [dns-operations] dnsop-any-notimp violates the DNS standards

Why I prefer to top post. ;) On 3/13/15, 13:59, "Morizot Timothy S" wrote: > >...my work email system does not make it easy to quote intelligently... smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://w

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Paul Wouters wrote: > I bet most qmail installs run from distributions that have included the > CNAME patch. I'm not sure if this is going to break more than 1 server. > > All debian qmail packages come with: > > http://ftp.de.debian.org/debian/pool/non-free/q/qmail/qmail_1.03-49.2.diff.gz This

Re: [DNSOP] DNS Terminology: Glue

On 3/13/15, 12:00, "Paul Hoffman" wrote: > >FWIW, what we tentatively have for the next draft is: > > Glue records -- Resource records which are not part of the > authoritative data [for a zone], and are address resource records for > the servers [in a subzone]. These RRs are only necessa

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

> -Original Message- > From: Paul Wouters [mailto:p...@nohats.ca] > > > On Fri, 13 Mar 2015, Paul Vixie or Morizot Timothy S wrote: > > [not sure of the quoting in this message] > The comments you referenced were all Paul's. I tried to make that clear in the structure of the email eve

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On Mar 13, 2015, at 10:54 AM, Paul Wouters wrote: > >> DNSSEC is [...] even less finished and less deployed than IPv6. > > I have to disagree with this continued claim by opponents of DNSSEC > that it is not widely deployed. I believe this was Paul Vixie quoting himself from 10 years ago. Rega

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On Fri, 13 Mar 2015, Paul Vixie or Morizot Timothy S wrote: [not sure of the quoting in this message] DNSSEC is [...] even less finished and less deployed than IPv6. I have to disagree with this continued claim by opponents of DNSSEC that it is not widely deployed. The fact that Apple had an

[DNSOP] Call for Adoption: draft-ogud-dnsop-acl-metaqueries

All, This starts a Call for Adoption for draft-ogud-dnsop-acl-metaqueries The draft is available here: https://datatracker.ietf.org/doc/draft-ogud-dnsop-acl-metaqueries/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stati

Re: [DNSOP] CloudFlare policy on ANY records changing

On Fri, Mar 13, 2015 at 05:10:43PM +, Tony Finch wrote: > Maybe this could be a use for the NULL RRtype? :-) I'd completely forgotten its existence. But yes, that makes plenty of sense. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _

Re: [DNSOP] DNS Terminology: Glue

On 3/13/15 4:55 PM, Paul Hoffman wrote: On Mar 13, 2015, at 9:33 AM, Evan Hunt wrote: Given the amount of discussion this topic has generated, and the number of ways I've seen the word used in the past (and, in fact, have used it myself when speaking imprecisely), a discursive paragraph about

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

From: Paul Vixie ultimately what matters is whatever works. if cloudflare decides to stop answering QTYPE=ANY then it would take all million or so qmail customers complaining to cloudflare's NOC to get cloudflare to change its mind. i don't think that's going to happen, for a number of reason

Re: [DNSOP] CloudFlare policy on ANY records changing

> Evan Hunt wrote: > > > > This could be a pretty brilliant solution, actually: If you're > > authoritative for a signed zone and you receive a query of type ANY, > > return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize > > a response containing a single RR with a type from th

Re: [DNSOP] DNS Terminology: Glue

On Fri, Mar 13, 2015 at 12:55 PM, Paul Hoffman wrote: > On Mar 13, 2015, at 9:33 AM, Evan Hunt wrote: > > Given the amount of discussion this topic has generated, and the number > of > > ways I've seen the word used in the past (and, in fact, have used it > myself > > when speaking imprecisely),

Re: [DNSOP] DNS Terminology: Glue

On Mar 13, 2015, at 9:33 AM, Evan Hunt wrote: > Given the amount of discussion this topic has generated, and the number of > ways I've seen the word used in the past (and, in fact, have used it myself > when speaking imprecisely), a discursive paragraph about common misuses > might be helpful. Li

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On Sat, 14 Mar 2015, Paul Vixie wrote: ultimately what matters is whatever works. if cloudflare decides to stop answering QTYPE=ANY then it would take all million or so qmail customers complaining to cloudflare's NOC to get cloudflare to change its mind. i don't think that's going to happen, for

Re: [DNSOP] DNS Terminology: Glue

On Fri, Mar 13, 2015 at 09:00:34AM -0700, Paul Hoffman wrote: > If there is a well-accepted name for "address records that come with glue > records but are not actually glue records", we can add it, but I am > hesitant for this document becoming a list of things observed in the wild > that don't al

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

> Masataka Ohta > Saturday, March 14, 2015 1:02 AM > Randy Bush wrote: > >>> What problem are we specifically trying to solve here again? >> not break things that are working > > Yup. Qmail or any software produced by djb adhering the existing > standards

[DNSOP] Justifications in draft-ogud-dnsop-acl-metaqueries

Greetings again. The current draft has a few issues that should be resolved before the WG decides whether or not to take on this work. The following statement seems fundamental to creating the new mechanism in the draft: The ANY meta query was defined for debugging purposes mainly against

Re: [DNSOP] DNS Terminology: Glue

On Fri, Mar 13, 2015 at 12:05 PM, Tony Finch wrote: > Shumon Huque wrote: > > > > It might be worth also clarifying another thing. The definition states > > "These RRs are only necessary if", but doesn't clearly include or > > exclude the possibility that other address records for NS names that

Re: [DNSOP] DNS Terminology: Glue

Shumon Huque wrote: > > It might be worth also clarifying another thing. The definition states > "These RRs are only necessary if", but doesn't clearly include or > exclude the possibility that other address records for NS names that > don't sit below the zone cut, and were gratuitously provided i

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Randy Bush wrote: >> What problem are we specifically trying to solve here again? > > not break things that are working Yup. Qmail or any software produced by djb adhering the existing standards of the Internet. Paul Vixie wrote: > everything is broken, depending on whom you ask. The worst b

Re: [DNSOP] DNS Terminology: Glue

On Mar 13, 2015, at 8:39 AM, Shumon Huque wrote: > It might be worth also clarifying another thing. The definition states "These > RRs are only necessary if", but doesn't clearly include or exclude the > possibility > that other address records for NS names that don't sit below the zone cut, > a

Re: [DNSOP] DNS Terminology: Glue

On Thu, Mar 12, 2015 at 11:27 AM, Paul Hoffman wrote: > On Mar 12, 2015, at 5:07 AM, Niall O'Reilly wrote: > > In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt, > > "glue" is defined as follows. > > > > Glue records -- Resource records which are not part of the > > authoritat

Re: [DNSOP] DNS Terminology: Glue

On Thu, 12 Mar 2015 17:53:08 +, Patrik Wallström wrote: > > While working on the Zonemaster test specifications we decided to go > even further in order to differentiate between names and addresses, > calling those “glue address records” and “glue name records”: > > Glue Name Records are defi

Re: [DNSOP] DNS Terminology: Glue

On 3/12/15 3:21 PM, Paul Hoffman wrote: On Mar 12, 2015, at 7:47 AM, Phillip Hallam-Baker wrote: On Thu, Mar 12, 2015 at 10:42 AM, Paul Hoffman wrote: On Mar 12, 2015, at 6:53 AM, Phillip Hallam-Baker wrote: Its a bug in the spec. The terminology document is the wrong place to deal wi

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

> What problem are we specifically trying to solve here again? not break things that are working randy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CloudFlare policy on ANY records changing

Evan Hunt wrote: > > This could be a pretty brilliant solution, actually: If you're > authoritative for a signed zone and you receive a query of type ANY, > return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize > a response containing a single RR with a type from the "private u

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

note, i am limiting my reply to dnsop@ietf.org; it's my view that dns-operations@ and dnsop@ should each prohibit (by mail filter) any cc to any other list. Randy Bush wrote: >> > What problem are we specifically trying to solve here again? > > not break things that are working everything is brok