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 Apr 2
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 optio
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 https://datatracker.ietf.org/doc/draft-ietf
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
> m
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 talki
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 wit
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 recu
Dear dnsop members,
At this point we believe we have addressed all questions and comments
on the draft. Please let us know if there are any more comments.
Thanks,
Puneet
On Tue, Jul 2, 2019 at 3:41 PM Suzanne Woolf wrote:
>
>
>
> > On Jul 2, 2019, at 10:01 AM, Paul Hoffman wrote:
> >
> > On Ju
On Mon, Jul 22, 2019 at 8:38 PM Normen Kowalewski wrote:
>
> Daer Stephane, Paul and DNSOP WG,
>
> 1. it was noted in todays meeting that the the “add" is not based on any
> underlying rfc, and thus might be somewhat too vague.
> +1 on that
>
> draft-hoffman-dns-terminology-ter-01.txt says:
>
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 serv
an 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 would li
-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,
14 matches
Mail list logo
