Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

2017-02-10 Thread Woodworth, John R
Richard, Olafur; Just reread your draft and had a question. Would it be worthwhile to formalize a default result-set for an ANY query in your draft? Seems like there is a great disparity among implementations and as pointed out in your draft clients looking to save calories with a single query

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

2017-02-10 Thread Richard Gibson
Because without such a signal, humans using ANY for legitimate diagnostic purposes have no means of differentiating section 4.1/4.3 "subset" responses from conventional responses where there just happen to be only a small number of RRSets at the queried name, encouraging (or at least doing nothing

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

2017-02-10 Thread Ólafur Guðmundsson
Thank you for your comments Q: why do you think it is useful to complicate things with a EDNS0 flag ? Olafur On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson wrote: > With full realization that this is coming very late in the game, we had a > great deal of internal conversation within Dyn abou

Re: [DNSOP] solving a problem by creating a worse problem, ALT-TLD and (insecure) delgations.

2017-02-10 Thread Suzanne Woolf
Hi, The editors hold the token on text for this, but it seems to me that the discussion has started going in circles. A number of arguments have been made, and in some cases repeated. Let’s assume the editors have heard them and try to restrict followups to new observations, questions, or argu

Re: [DNSOP] solving a problem by creating a worse problem, ALT-TLD and (insecure) delgations.

2017-02-10 Thread John Levine
>> What I envision for the future is an insecure delegation of .alt, and an >> option in future cable modems to enable a local "homenet.alt" domain, which >> would just work, even if some stub resolvers in the house are validating. >> The cable modem is already a recursive resolver or forwarder, an

Re: [DNSOP] ALT-TLD and (insecure) delgations.

2017-02-10 Thread Andrew Sullivan
On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote: > What I envision for the future is an insecure delegation of .alt, and an > option in future cable modems to enable a local "homenet.alt" domain, which > would just work, even if some stub resolvers in the house are validating. > The cabl

Re: [DNSOP] ALT-TLD and (insecure) delgations.

2017-02-10 Thread Andrew Sullivan
On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote: > So, while technically the instruction (SHOULD NOT) applies to full .onion > names, > it is a SHOULD NOT, not a MUST NOT. Note also that the original request was that it be a MUST NOT, and some of us tried to explain that RFCs do not

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt

2017-02-10 Thread Peter van Dijk
Hello Ray, On 10 Feb 2017, at 14:12, Ray Bellis wrote: On 10/02/2017 12:52, Peter van Dijk wrote: Can you please consider adding a port number field? I see where you're coming from, but I'm not inclined to add it (yet) for a couple of reasons: 1. CGNAT is evil ;-) You have my full agr

Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis

2017-02-10 Thread Edward Lewis
On 2/8/17, 16:31, "DNSOP on behalf of Paul Hoffman" wrote: >The authors have tentatively made some substantial changes to the draft, to define "domain name" I have a fundamental problem with that, meaning that a document within DNSOP is defining domain names. Work I did to write (the

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt

2017-02-10 Thread Ray Bellis
On 10/02/2017 12:52, Peter van Dijk wrote: > However, both in ECS, and now in XPF, we do not get client’s port > number. With increasing CGNAT deployment, this makes it impossible to > distinguish clients once a request has passed through a proxy, like > dnsdist or a TLS frontend. > > Can you p

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt

2017-02-10 Thread Peter van Dijk
Hello Ray, On 6 Jan 2017, at 23:02, Ray Bellis wrote: On 06/01/2017 18:43, Wessels, Duane wrote: The idea of "X-Forwarded-For" for DNS makes me nervous, but it is probably inevitable. It is of course quite similar to EDNS client subnet, except that there is no masking and the client cannot o

Re: [DNSOP] ALT-TLD and (insecure) delgations.

2017-02-10 Thread Stephane Bortzmeyer
On Fri, Feb 10, 2017 at 12:57:25PM +1100, Mark Andrews wrote a message of 29 lines which said: > Even with everything working properly QNAME minimisation DOES NOT > STOP THE QUERIES. > > RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC > 4035) RFC 4035 (if more s

Re: [DNSOP] ALT-TLD and (insecure) delgations.

2017-02-10 Thread Stephane Bortzmeyer
On Thu, Feb 09, 2017 at 04:40:23PM -0800, Brian Dickson wrote a message of 78 lines which said: > If you really care about privacy, IMHO, the place to instantiate the > private namespace, is under one of the heavily used AS112 zones. [...] > even if a leak > occurs, it will be hiding among the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

2017-02-10 Thread Stephane Bortzmeyer
On Fri, Feb 10, 2017 at 11:48:01AM +1100, Mark Andrews wrote a message of 36 lines which said: > No, it will ask for foo.alt because: This is false (and Ted Lemon was correct in describing QNAME minimisation). Here, with a recent Unbound, when I ping foo.alt, I see only: 09:05:55.233366 IP6

Re: [DNSOP] ALT-TLD and (insecure) delgations.

2017-02-10 Thread Stephane Bortzmeyer
On Fri, Feb 10, 2017 at 09:48:51AM +1100, Mark Andrews wrote a message of 43 lines which said: > and has agressive negative caching (so the answer from the minimised > QNAME query get turned into a answer for *.alt). As I already said here, if by "agressive negative caching", you mean draft-i

Re: [DNSOP] ALT-TLD and (insecure) delgations.

2017-02-10 Thread Stephane Bortzmeyer
On Fri, Feb 10, 2017 at 06:57:22AM +1100, Mark Andrews wrote a message of 40 lines which said: > Only if you are willing to break lookups for names where there are > missing delegations in parent zone and the parent and child zones > share the same nameservers or the nameserver just misimpleme