[DNSOP] Extended errors draft

I asked on the Unbound mailing list if there were any ways to differentiate between DNSSEC-related SERVFAILs and other types of SERVFAILs, and was referred to the extended error draft: https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02. I can't speak to the implementation detail, bu

Re: [DNSOP] EDNS0 clientID is a wider-internet question

I agree: The EDN0 Client ID draft seems quite bad from a privacy perspective, and I believe it should not be adopted. More broadly, enforcing content blocks with DNS is an anti-pattern. If we're assuming that the entity doing the content blocking has administrative access to DNS clients, they can

Re: [DNSOP] EDNS0 clientID is a wider-internet question

On 07/25/2017 01:07 AM, Paul Vixie wrote: > i think content blocking is a reach -- in your interpretation. > > this is about CDN. as in, how to decide which address record set to > give a dns client, given that all you know is the recursive server > address, yet you're trying to implement policy fo

[DNSOP] Status of "let localhost be localhost"?

Hi, I'm interested in seeing https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03 move from draft status to become a standard. In particular, it would allow browsers to start treating "localhost" as a secure context, which would reduce attempts by application developers to abuse th

Re: [DNSOP] Status of "let localhost be localhost"?

On 08/01/2017 03:48 AM, Mike West wrote: > The only open issue I know of is some discussion in the thread at > https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I > need help synthesizing into the draft. I don't know enough about the > subtleties here to have a strong opinion,

Re: [DNSOP] Status of "let localhost be localhost"?

On 08/01/2017 06:23 PM, Mark Andrews wrote: > The query for foo.localhost doesn't need to hit-the-wire for this > to be a issue. Ask your self why RFC 6303, Security section has > >As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA >namespaces, the zones listed above will need to

Re: [DNSOP] Status of "let localhost be localhost"?

On 08/02/2017 12:09 PM, Matthew Pounsett wrote: > In the case where 'localhost' is being passed to DNS resolution > software, a validating stub (for example inside a web browser) Ah, this may be where we are finding a disconnect. I believe web browsers never operate validating stub resolvers, but g

Re: [DNSOP] Status of "let localhost be localhost"?

On 08/12/2017 12:35 PM, Ted Lemon wrote: > The document does the right thing on that front, as far as that goes, > but if this is to be effective I think that it shouldn't be an aside, > but should be the main point of the document. That is, the title of > the document should be "DNS servers shou

Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

I support adopting this draft. On 09/06/2017 07:00 AM, tjw ietf wrote: > When the idea of having a Call for Adoption for this document came up, > we thought long and hard about this one. However, the comments from > the working group focused this document to address the specific issue > of the lo

Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

On 10/09/2017 01:16 PM, Warren Kumari wrote: > So, that's my (new) views, and the thread seemed to have stalled. I > believe that the security implications of having localhost queries > leak into the DNS is bad, and there is significant evidence that this > is happening. I get that there is no ans

[DNSOP] Error handling in CAA

In the SPASM group, we are refining CAA (RFC 6844) based on the changes that were needed in order to get it passed at the CA/Browser Forum. There's one sticky bit in particular I'd like input on. Here's the current language in the BRs: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.

Re: [DNSOP] `localhost` and DNS.

Looks good to me. On 11/27/2017 03:54 AM, Mike West wrote: > Post-{IETF,Thanksgiving} ping. Feedback (or further +1's!) would be > appreciated. :) > > -mike > > On Thu, Nov 16, 2017 at 1:01 AM, Richard Barnes > wrote: > > > > On Thu, Nov 16, 2017 at 5:05 AM, Ted Lemon