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:
>>
>>
>> Part of the problem is that we ha
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
O
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
wrote:
> Output edited f
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:
> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
>
> Snippet
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 invali
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 o
l DHCP
authentication happens, but 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, 20
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.
Mare
ndle.
At the very least, if my ISP or office network advertises resolvers on
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 dr
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
>>
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.
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:
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
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 w
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 yo
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 webserve
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 the
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
use
On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters 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
>> them as authorit
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 r
ility (even more if
we ever have a newer address record) and more code exceptions.
Marek
On Tue, Mar 22, 2016 at 8:55 AM, Shumon Huque wrote:
> On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch wrote:
>
>> Marek Vavruša wrote:
>> >
>> > there was an interest in reduc
On Tue, Mar 22, 2016 at 1:20 PM, Mark Andrews wrote:
>
> In message tb11orh1myro+ccemjwy67nyhdcrgwvhe+jm568o2cl7...@mail.gmail.com>,
> =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
> >
> > Thanks everybody for comments! It's a lot so I'll try to rephrase and
> > answer the questions below.
> >
> > 1. N
On Tue, Mar 22, 2016 at 2:03 PM, Shane Kerr
wrote:
> Marek,
>
> At 2016-03-22 12:12:08 -0700
> Marek Vavruša wrote:
>
> > 2. Behavior of stubs is not explicit in the draft
> >
> > I should have stated this explicitly, the draft doesn't update behaviour
Hi Andrew, first of all - thanks for being constructive.
On Wed, Mar 23, 2016 at 6:07 AM, Andrew Sullivan
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 answers and
> > treating
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 certain kind of c
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
> https://datatracker.ietf.org/doc/dr
This affects several major DNS providers currently. I've heard Akamai
is rolling out update, but it's still returning NXDOMAIN for ENTs.
While deploying the draft in the current state of Internet is not
really viable and pointing out various broken implementations is fun,
I think it's good to have
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
On Wed, Jun 22, 2016 at 1:52 AM, Mark Andrews wrote:
>
> In message
> ,
> =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
>>
>> This affects several major DNS providers currently. I've heard Akamai
>> is rolling out update, but it's still returning NXDOMAIN for ENTs.
>> While deploying the draft in the c
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 you get this automa
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:
>>> Don't you get
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 order) replies?
>
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 DNS transport, si
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 only sending
>>> o
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 all.
>
> * We should restrict
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 configuration."
>>
>> T
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 w
On Thu, Aug 18, 2016 at 12:52 PM, Paul Hoffman 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 for the information that c
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 impleme
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 valid response is silence.
>> >
>> > I think it is important for people producing and deploying DNS se
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 Abrah
41 matches
Mail list logo
