[DNSOP] [Zonemaster] DNS zone/service checking tool features survey

Hi All, Thanks for responding one response per user. Apologies for cross-posting. *Access*: All *Close date*: 03/04/2015 *Survey*: https://fr.surveymonkey.com/r/zonemaster *Background*: "Afnic" and "IIS.SE" are currently in th

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-02.txt

Paul Wouters wrote: > On Mon, 9 Mar 2015, Tony Finch wrote: > > > > Without this extension the typical number of RTTs required is 1, so this > > isn't a reduction. > > When you have nothing of nohats.ca in your cache, and you ask for the > A record of www.nohats.ca, you will normally get back the

[DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt

Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse. If you have interests, please comment. Subject: New Version Notification for draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt From: internet-dra...@ietf.org Date: Mon, 09 Mar 2015 10:20:47 -0700 A new version of I-D, draft-fuj

Re: [DNSOP] Suggestion for "any" - TCP only

+1 (privacy response is with all, and this specific issue is not an amplification one) Hugo Connery, Technical University of Denmark From: DNSOP [dnsop-boun...@ietf.org] on behalf of Paul Vixie [p...@redbarn.org] Sent: Tuesday, 10 March 2015 01:35 To: Pau

Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Shumon, On 09/03/15 21:17, Shumon Huque wrote: > On Mon, Mar 9, 2015 at 2:55 PM, Shumon Huque > wrote: > > On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds > wrote: > > Shumon Huque wrote: >> PS

Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

On Tue, Mar 10, 2015 at 7:37 AM, W.C.A. Wijngaards wrote: > > Unbound varies its answers depending on what the authority server is > doing. If the authority server inserts such an A or record in > the additional section, unbound has code for this case (an > inserted for an A query, or

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-02.txt

On Tue, 10 Mar 2015, Tony Finch wrote: Tony, Without this extension the typical number of RTTs required is 1, so this isn't a reduction. When you have nothing of nohats.ca in your cache, and you ask for the A record of www.nohats.ca, you will normally get back the A record and the RRSIG. Then

Re: [DNSOP] [TCP] Review of draft-ietf-dnsop-5966bis-00.txt

On 9 Mar 2015, at 16:32, Stephane Bortzmeyer wrote: > > I re-send here two questions that have apparently not been addressed > in -01 Hi Stephane, Sorry, this was my oversight. I have added them to the issue tracker at https://github.com/DNSOP/draft-5966-bis. I will make sure they are addresse

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

On 3/9/15, 19:18, "D. J. Bernstein" wrote: I had a longer response (no surprise) but I'll boil it to this: >a large operator is using its market position to violate the standards >and _create_ interoperability failures as a tool to enforce a protocol >change that it wants. When you describe it

[DNSOP] CloudFlare policy on ANY records changing

On Mar 10, 2015, at 9:34 AM, Paul Hoffman wrote: > On Mar 10, 2015, at 8:46 AM, David C Lawrence wrote: >> >> Paul Hoffman writes: >>> On Mar 10, 2015, at 6:25 AM, Yunhong Gu wrote: So the problem is, why NOTIMP? REFUSED sounds like a better choice. >>> >>> +1. "REFUSED" exactly descri

Re: [DNSOP] CloudFlare policy on ANY records changing

> Wessels, Duane > Wednesday, March 11, 2015 6:19 AM > > > As Paul suggests, I'll attempt to redirect the conversation to dnsop. > > Does it make sense to define an Extended RCODE for additional signaling? > e.g. "REFUSED_BECAUSE_QTYPE_ANY" no, because the problem

Re: [DNSOP] I-D Action: draft-chapin-additional-reserved-tlds-02.txt

Hi, >> What was the motivation for removing .lan from the list? >> >> I can see where .localdomain and .domain indeed won't cause any >> problems, but I think .lan is still a pretty common one in use. > > It is a common fake TLD used by home gateways for their internal networks. Yeah, so I've r

Re: [DNSOP] I-D Action: draft-chapin-additional-reserved-tlds-02.txt

I suspect as we get more validating resolvers / clients the entire use of squatted tld zones will go away. DNSSEC breaks the use of squatted TLDs without doing lots of extra fragile steps to make it work again. The standard response to bug reports about this is to say that such usage was never g

Re: [DNSOP] I-D Action: draft-chapin-additional-reserved-tlds-02.txt

On 11 Mar 2015, at 00:08, David Conrad wrote: > While true, these values will vary over time, location of collection, and > myriad other reasons, probably including phase of moon. If we're going to > reserve strings from ever being delegated, I believe we need to come up with > some rationale

Re: [DNSOP] CloudFlare policy on ANY records changing

On Wed, Mar 11, 2015 at 08:05:31AM +0800, Paul Vixie wrote: > if we're serious about redefining ANY as a meta-query, then answering > with RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries > against an RA=1 server.) I'm concerned that a NOERROR/NODATA for qtype=ANY, once cached, would

Re: [DNSOP] I-D Action: draft-chapin-additional-reserved-tlds-02.txt

On Mar 10, 2015, at 6:33 PM, Jim Reid wrote: > On 11 Mar 2015, at 00:08, David Conrad wrote: > >> While true, these values will vary over time, location of collection, and >> myriad other reasons, probably including phase of moon. If we're going to >> reserve strings from ever being delegated,

[DNSOP] Another suggestion for "any"

On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson wrote: > Hey, everyone, > [snip] > "dig"-friendly. > Okay, thinking about this a bit more... Recursive vs authoritative, RD=0 vs RD=1. In all combinations of the above, do the "new thing", except for one corner case: if(RD==1 && I_AM_AUTHORITY) the

[DNSOP] comments on dnsop-qname-minimisation-02

Hi Stephane, Some comments on this draft: > DNS query name minimisation to improve privacy > draft-ietf-dnsop-qname-minimisation-02 > > Abstract > >This document describes one of the techniques that could be used to >improve DNS privacy (see [[17]I-D.ietf-dpr