Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček wrote: > On 21.8.2018 04:38, Tom Pusateri wrote: >> Come to think of it, DNSSEC validation in the stub resolver or browser >> is really a place DoH could shine. Instead of all the round trips >> required for validating up (down) the chain, the

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Mon, Aug 20, 2018 at 7:31 PM, Ted Lemon wrote: > This is why we need to actually think about trust and not just handwave. > There are a number of serious misconceptions in what you've said, Paul. I'm still not sure that IETF should define the provider of trust, as the trust is relative. But

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Mon, Aug 20, 2018 at 6:58 PM, Paul Vixie wrote: > > > Tom Pusateri wrote: > >> >> One more point (from the Android crowd) was that they are going to try >> to connect to the DNS server’s IP address using port 853 using DoT at >> the same time they are trying to resolve names over port 53

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Interesting. This approach is similar to the lists curated by Frank and people from dnscrypt-proxy: https://dnscrypt.info/public-servers Assuming that separating protocol change from trust model change is a no-go, then the trust would need to go both ways - the network operator would need to push

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Thanks Tom, this is what I was asking for. I'll take a look! On Sat, Aug 18, 2018 at 6:09 PM, Tom Pusateri wrote: > > > On Aug 18, 2018, at 8:53 PM, Marek Vavruša > wrote: > > On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon wrote: > > On Sat, Aug 18, 2018 at 8:33 PM

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon wrote: > On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša > wrote: >> >> > You say that your proposal does not impact DoT's ability to address the >> > threat model or use case that is the reason it is being used. But

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Sat, Aug 18, 2018 at 5:33 PM, Paul Vixie wrote: > > > Marek Vavruša wrote: >> >> Hi, >> >> thanks for comments. This draft has little to do with DoH (the primary >> focus is DoT), and its comparison to other technologies. It's about >> netw

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

n port 853, using those is arguably better than the same resolver on port 53. > On Sat, Aug 18, 2018 at 5:58 PM, Marek Vavruša > wrote: >> >> Hi Ted, >> >> thanks for comments. As said, the draft doesn't try to change the >> trust model or fix DHCP authenticati

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Hi, thanks for comments. This draft has little to do with DoH (the primary focus is DoT), and its comparison to other technologies. It's about network operator being able to advertise that its recursive server supports DNS on more than just port 53. Please let's stay at least a bit on topic.

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

the query stream is hidden from other devices on the same network. Either way, the benefit is that stub resolver can make a decision based on a multitude of factors. Is there a merit in this, or am I perhaps missing something? Marek > > On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša >

[DNSOP] Draft for dynamic discovery of secure resolvers

Hi, this is a bit off topic, but I figured it would be useful to solicit some early feedback. The current status is that for secure (as in RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism, and it's also out of scope for [0]. At the same time we're seeing real world deployment

Re: [DNSOP] QNAME minimisation on the standards track?

I'd like to see this on the standards track as well. Cloudflare has some operational experience with it (it's enabled by default on 1.1.1.1). It mostly works, but still has to be turned off on several delegations that either don't respond to non-terminals, respond with positive answer that's

Re: [DNSOP] Blog Post: DNS over TLS support in Android P Developer Preview

This is great, well done. On Fri, Apr 13, 2018 at 12:49 PM, Warren Kumari wrote: > Hi all, > > As Erik Kline and Ben Schwartz seem to be too modest to toot their own > horn, I'll do it for them: >

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

That's a good point. Personally, I'd favour a referral response since it saves resolver a round trip (at least for resolvers not doing QNAME minimisation), it seems in conflict with 3.1.4.1 though as you pointed here. Marek On Wed, Jan 3, 2018 at 10:31 AM, Peter van Dijk

Re: [DNSOP] draft-ietf-dnsop-dns-rpz

Hi Vernon, There's a functionality [1] to do all these things (and more), you just can't read/write complicated rules from RPC compatible format (DNS zone files). Feel free to contribute of course. Marek [1]: http://knot-resolver.readthedocs.io/en/stable/modules.html#dns-application-firewall

Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

I support the adoption of this document. Was there a discussion of any actual downsides besides "I'd like to know if it's stale" and monitoring? On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold wrote: > > On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews wrote: >> >>

Re: [DNSOP] ECDSA woes

Hi, not sure if it's exactly what you're looking for, but there's https://github.com/CZ-NIC/deckard for (generic) resolver testing. It mocks the environment for the tested binary, so you'll have to provide a configuration template for dnsmasq. Marek On Fri, Oct 14, 2016 at 11:22 PM, Mikael

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

On Thu, Aug 25, 2016 at 9:23 AM, Tony Finch wrote: > william manning wrote: > >> On Thursday, 25 August 2016, Tony Finch wrote: >> >> > william manning > wrote: >> > >> > > I'm with Ed here, A

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Very interesting, so BIND already pushes records for the obvious optimisation cases. Did you do any research on how many clients use these records (thus don't follow up with an extra query) ? Perhaps it would be helpful to look at the it from different perspectives. As an authoritative DNS

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

On Thu, Aug 18, 2016 at 12:52 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On 18 Aug 2016, at 11:29, Marek Vavruša wrote: > >> Or SRV. > > > I disagree that a user, when asking for a SRV record, doesn't know that it > is likely that they would want the results

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Or SRV. These are cases where authoritative/resolver adding interesting records as additionals works better. Authoritatives have been doing that with extra SOA/NS in authority for a while (for positive answers), but now resolvers can hardly use them if these records are not secure. Regardless of

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

On Sun, Aug 14, 2016 at 4:27 PM, Paul Hoffman wrote: > On 5 Aug 2016, at 2:45, Shane Kerr wrote: > >> First, we have: >> >> "If a priming query does not get a response within 2 seconds, the >> recursive resolver SHOULD retry with a different target address from >> the

Re: [DNSOP] Possible issues with DNS over HTTP wire format draft

Hi, On Mon, Aug 8, 2016 at 6:41 AM, Shane Kerr wrote: > Hello, > > There are a few suggestions about the DNS over HTTP draft made off-list, > which I will try to characterize here: > > * We should expand the motivations to explain why DNS over HTTP makes > sense at

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

On Tue, Jul 12, 2016 at 11:03 AM, John R Levine wrote: >>> The reason to use TCP framing is so that you can send multiple DNS >>> requests >>> in a single http request and get back multiple answers. Recent messages >>> here suggest that's of considerable interest, and if you're

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

On Tue, Jul 12, 2016 at 8:45 AM, John R Levine wrote: >>> My main suggestion is to lose the Proxy-DNS-Transport header and >>> always have the request and response in TCP format. >> >> >> The HTTP payload should always be unframed (like DNS over UDP) regardless >> of the upstream

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

On Mon, Jul 11, 2016 at 10:39 PM, John R Levine wrote: >> for a web to DNS proxy to decide to send a reply back, it would need to >> consider it complete? >> >> Or are you proposing that the http server would start streaming back the >> payload as it received the (possibly out of

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

RFC 7766 is about DNS/TCP not about DNS/HTTP, the order of processing has to be determined by the wrapping protocol. You would get it for free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but it's not. Marek On Mon, Jul 11, 2016 at 10:32 PM, John R Levine wrote:

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

On Mon, Jul 11, 2016 at 10:06 PM, John Levine wrote: >>So I suggest some thought should be given to reducing round-trips by >>allowing for multiple DNS request payloads in a single HTTP request >>message, and multiple DNS response payloads in an HTTP response message. > > Don't

Re: [DNSOP] Working Group Last Call: draft-ietf-dnsop-nxdomain-cut

On Wed, Jun 22, 2016 at 1:52 AM, Mark Andrews wrote: > > In message >

Re: [DNSOP] naming and shaming broken implementations

Naming and shaming is not the only mechanism for change, and it's not effective when things "work". Sunsetting and deprecating parts of protocols (like IQUERY or TYPE=ANY) is more important as it helps not only to keep the protocol concise, but also forces evolution of protocol implementations (or

Re: [DNSOP] Root server tar pitting? Is there a better way?

Why not run a local copy of the root? It should be a good practice for large recursives, plus you get better latency. Marek On Mon, May 16, 2016 at 2:34 PM, Wessels, Duane wrote: > Hi Brian, > > I think what you're suggesting has already been proposed. See >

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On Fri, Mar 25, 2016 at 7:51 PM, John Levine wrote: > >As I think many here know, I am not of the get-off-my-lawn persuasion > >for DNS innovations. I don't think it's a bad idea in principle. I'm > >just aware that we have this long history, and that history was based > >on a

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

Hi Andrew, first of all - thanks for being constructive. On Wed, Mar 23, 2016 at 6:07 AM, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > Hi, > > On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote: > > Me and Olafur wrote a draft on adding records to A ans

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On Tue, Mar 22, 2016 at 2:03 PM, Shane Kerr <sh...@time-travellers.org> wrote: > Marek, > > At 2016-03-22 12:12:08 -0700 > Marek Vavruša <mvavr...@cloudflare.com> wrote: > > > 2. Behavior of stubs is not explicit in the draft > > > > I should have sta

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On Tue, Mar 22, 2016 at 1:20 PM, Mark Andrews wrote: > > In message

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

more code exceptions. Marek On Tue, Mar 22, 2016 at 8:55 AM, Shumon Huque <shu...@gmail.com> wrote: > On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch <d...@dotat.at> wrote: > >> Marek Vavruša <mvavr...@cloudflare.com> wrote: >> > >> > there was

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

I see the point but I don't really want to go down the EDNS route. So presuming that this draft catches on and Alexa 1M NSs publish at least one record, there would be no need for two queries in most cases and no need for additional signalisation. If they don't publish records, then the

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters <p...@nohats.ca> wrote: > On Mon, 21 Mar 2016, Marek Vavruša wrote: > > there was an interest in reducing latency for address record lookups. Me >> and Olafur wrote a draft on adding records to A answers and treating >>

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

Who wants to get rid of A lookups? "A" is going to be here for a while and using it as a generic mean to get all addresses of given protocol (regardless of version) gives servers a way to smoothly transition over versions. If the A was updated to have a variable address length, then it could be

[DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

Hi, there was an interest in reducing latency for address record lookups. Me and Olafur wrote a draft on adding records to A answers and treating them as authoritative. This fixes latency issues with NS A/ discovery in resolvers and improves caching for clients ( already cached by