Also the following section (2.2.1 - Special Handling of No Data)
suggests sending type 2 instead of type 1 responses but is silent
about type 3 responses.
On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood wrote:
>
> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews wrote:
> >
> > RFC 203
3).
> I doubt saying
> don’t do those old forms will make any difference. Everything out there has
> had 25 years
> to comply.
I understand updating the specs by itself does not fix compliance.
However clarifying that "or" would be useful.
>
> > On 15 Ap
On the topic of authoritative server behavior as seen in the DNS
responses, a few areas for improvement below (not touching DNSSEC).
This is written from the perspective of a resolver using the auth
responses to answer user queries.
* responding correctly to requests with certain flags, EDNS
I wanted to respond to this thread earlier, so apologies in advance
for late posting and if this is a no-op at this point. Me getting
confused about the last call for this draft
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/)
and
I support adoption of this document to provide guidance for operators to
pick sensible NSEC3 parameters and for expected resolver behavior.
-Puneet
On Mon, May 10, 2021 at 4:56 AM Benno Overeinder wrote:
> Hi all,
>
> As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP
>
On Wed, Oct 2, 2019 at 2:43 AM Vladimír Čunát
wrote:
>
> On 9/30/19 11:47 PM, Warren Kumari wrote:
> > On Mon, Sep 30, 2019 at 7:54 AM Tony Finch wrote:
> >> Difficult. In general there will be multiple upstream servers, even in
> >> the simplest case of a stub talking to a recursive server
On Tue, Oct 22, 2019 at 6:49 AM Tony Finch wrote:
>
> Petr Špaček wrote:
> >
> > 2. Second problem is that it is uncelar if there is going to be a
> > consumer: Did *anyone* from stub resolvers said a word about this draft?
> > Is it useful as it is?
>
> I expect almost no-one can do anything
On Sat, Sep 14, 2019 at 8:46 AM Barry Leiba wrote:
>
> > > I wonder if it makes sense to be more explicit here that one isn’t
> > > meant to keep using expired data forever, but is expected to keep
> > > trying to refresh it. So, maybe?:
> > >
> > > NEW
> > > If the data is unable to be
>
Barry,
Thanks for the detailed review. The editorial comments and security
considerations comment will be addressed in a new draft I will be
pushing.
On Wed, Sep 11, 2019 at 12:06 PM Barry Leiba wrote:
>
> I am handling this document as responsible AD, as Warren is a
> co-author and so must
Thanks for sharing the results of your work. It will be great to have
the software available so others can run the experiments from other
locations.
When looking at the page load results the CDF graphs comparing the
various services are very useful to see the relative performance of
different
er than with a system that opts users into a
> centralized resolver.
>
> RB
>
> On Mar 22, 2019, at 4:08 PM, Puneet Sood
> wrote:
>
> Hello,
>
> There has been much discussion in the IETF lists over the impact of
> using DNS-over-HTTPS (DoH) in a network. We
-over-TLS and DNS-over-HTTPS that
provide privacy for the user’s communication with a DNS resolver.
-Puneet Sood
TL/Manager for the Google Public DNS team.
PS: I am attending IETF 104 and will be available for face-to-face discussion.
On Wed, Mar 20, 2019 at 2:40 PM 神明達哉 wrote:
>
> At Wed,
12 matches
Mail list logo
