Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS

[Loganaden Velvindron]

I would support adoption of this document and will send my feedback as
soon as i can.

On Mon, 23 Jan 2023 at 00:36, Tim Wicinski  wrote:
>
>
> All
>
> The chairs have received feedback for DNSOP to adopt this document, and I've
> wrestled with this document.We have received feedback when presented
> to adopt this work.  We've also had some conversations with folks who
> offer DNS services to enterprises they have had some customer interest.
> I will say personally that I am sure I can find some individuals at my
> current employer who would get very interested in this also.
> So the best thing to do is - see what the Working Group says.
>
> If you work for someone who is interested in this, please let us know.
> If you work for someone who has customers interested in this, please let us 
> know.
> If you plan on implementing this (or not!), please let us know.
>
> If you feel less comfortable speaking publicly, please reach out to the 
> chairs.
>
>
> This starts a Call for Adoption for draft-wing-dnsop-structured-dns-error-page
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wing-dnsop-structured-dns-error-page/
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: February 5th, 2023
>
> Thanks,
> tim wicinski
> For DNSOP co-chairs
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

[Loganaden Velvindron]

I also support adoption of this document.

On Sat, May 22, 2021 at 3:06 AM Puneet Sood
 wrote:
>
> 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
>> meeting, we want to start a call for adoption of
>> draft-hardaker-dnsop-nsec3-guidance on the mailing list.
>>
>> With the presentation at the DNSOP meeting on IETF 110, there was a
>> sufficient general support in the (virtual) room to adopt the draft as a
>> working group document.
>>
>> Now we will start a period of two weeks for the call for adoption of
>> draft-hardaker-dnsop-nsec3-guidance on the mailing list.
>>
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
>>
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and comments to the list, clearly stating your view.
>>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> This call for adoption ends: 24 May 2021
>>
>>
>> Thanks,
>>
>> -- Benno
>>
>> DNSOP co-chair
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[Loganaden Velvindron]

On Wed, Apr 14, 2021 at 4:48 PM Stephane Bortzmeyer  wrote:
>
> On Wed, Apr 14, 2021 at 11:01:42AM +0200,
>  Stephane Bortzmeyer  wrote
>  a message of 10 lines which said:
>
> > The Name:Wreck compression pointer issue
>
> Also
> 
> talks about what IETF should do. (The article contains several errors
> about the RFC process.)
>
> > “I mean I don’t want to be the one telling the [Internet Engineering
> > Task Force] how to do their work. Things have worked for more than
> > 40 years on the internet because of the RFC systems,” he said. “But
> > indeed, I do believe that it’s time that we think of an
> > alternative.”

I think that the authors of the draft could consult this ?
https://www.ietf.org/standards/rfcs/vulnerabilities/


>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-ns-revalidation

[Loganaden Velvindron]

On Tue, Jun 2, 2020 at 8:20 PM Shumon Huque  wrote:
>
> On Tue, Jun 2, 2020 at 12:09 PM Daniel Migault  wrote:
>>
>> Hi,
>>
>> I support the adoption of the document. 
>> draft-ietf-dnsop-dnssec-validator-requirements-00 [1] references this 
>> document and would like it to become a standard.
>>
>> I suspect that many felt that [2] had a flavor of call for adoption. I was 
>> myself surprised to see the call for adoption.
>>
I support adoption of the draft and i'm willing to review.


>> Yours,
>> Daniel
>>
>>
>> [1] https://mailarchive.ietf.org/arch/msg/dnsop/fXmzHFzh153OO01hA5Oq8-T-fO8/
>> [2] 
>> https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-validator-requirements-00
>>
>
> With the disclaimer that I'm a co-author, I also support adoption of 
> draft-huque-dnsop-ns-revalidation.
>
> To answer Daniel's question, the first thread was where I introduced the 
> draft on the mailing list. Although the DNSOP chairs chimed in and asked for 
> general review there, it was not an official call for adoption. Tim's message 
> that we are responding to now is the adoption call.
>
> Shumon.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Loganaden Velvindron]

On Tue, May 12, 2020 at 4:50 PM Willem Toorop  wrote:
>
> Op 11-05-2020 om 21:38 schreef Bob Harold:
> > On Mon, May 11, 2020 at 1:42 PM Tim Wicinski  > > wrote:
> >
> >
> > All,
> >
> > As we stated in the meeting and in our chairs actions, we're going
> > to run
> > regular call for adoptions over next few months.
> > We are looking for *explicit* support for adoption.
> >
> >
> > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
> >
> > Please review this draft to see if you think it is suitable for adoption
> > by DNSOP, and comments to the list, clearly stating your view.
> >
> > Please also indicate if you are willing to contribute text, review, etc.
> >
> > This call for adoption ends: 25 May 2020
> >
I support Adoption of the document and I'm willing to review it.

> > Thanks,
> > tim wicinski
> > DNSOP co-chair
> >
> >
> > I support adoption and will review.
> >
> > "3.  Description
> > An implementation of catalog zones MAY allow the catalog to contain
> >other catalog zones as member zones."
> >
> > It seems ok to me to allow catalog zones to include other catalog zones
> > as future feature, although I cannot figure out yet how that would work,
> > but it might conflict with:
> >
> > "6.1.  Implementation Notes
> >Catalog zones on secondary nameservers would have to be setup
> >manually"
>
> Thanks Bob,
>
> The secondary has to be "setup manually",
> - to regard the zone to be a catalog zone
> - but also, optionally, to associate a set of configuration which are
>   applied to the zones generated from the catalog.
>
> One of the things in the associated set of configuration could be that
> zones from a certain catalog, are catalog zones themselves, however with
> which set of configuration the zones added from those catalog are
> associated, also needs to be configured manually on the secondaries.
>
> -- Willem
>
> >
> > --
> > Bob Harold
> >
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Loganaden Velvindron]

On Mon, May 4, 2020 at 11:10 PM Tim Wicinski  wrote:
>
>
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for 
> draft-mglt-dnsop-dnssec-validator-requirements
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
>
I support adoption of the draft and i'm willing to review it.
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 18 May 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-fujiwara-dnsop-avoid-fragmentation

[Loganaden Velvindron]

On Tue, Apr 14, 2020 at 11:23 PM Joe Abley  wrote:
>
> Hi Tim, esteemed fellow chairs,
>
> On 14 Apr 2020, at 11:47, Tim Wicinski  wrote:
>
> This starts a Call for Adoption for draft-fujiwara-dnsop-avoid-fragmentation
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> We are looking for *explicit* support for adoption.
>
>
> I support adoption.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
I support adoption. I'm aware that at least one implementation already
implements this.

Happy to review/contribute text.

>
> I am willing to contribute text, review, etc.
>
> This call for adoption ends: 28 April 2020
>
>
>
> Joe
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-nygren-dnsop-svcb-httpssvc

[Loganaden Velvindron]

On Mon, Oct 7, 2019 at 6:37 PM Tim Wicinski  wrote:
>
>
> All
>
> We want to thank the authors for working on this.  The chairs
> feel that part of the discussion around this document would be to
> resolve:
>   - ANAME/HTTPSSVC possible overlaps
>   - The RR Type Name (no one seems to be in love with current names)
>
> This starts a Call for Adoption for draft-nygren-dnsop-svcb-httpssvc
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/
>
I support adoption of this document.

> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 21 October 2019
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Loganaden Velvindron]

On Thursday, September 12, 2019, Tim Wicinski  wrote:

> All
>
> We had such great comments the first time we did a Working Group
> Last Call for draft-ietf-dnsop-extended-error, that the chairs decided
> a second one would be even better.
>
> Before we start, a few comments:
>
> - Viktor's comments from 11 September will be rolled into the WGLC
>   comments, which means I'll be tracking them with the authors.
>
> - The chairs are not doing to add more codes to the IANA registry
>   in the document.  However, the process is laid out in section 5.2,
>   with three different ranges (Expert Review; First Come, First Serve;
>   and Experimental).
>
> - We're pretty sure all comments have been addressed one way or another,
>   but we still may have missed some.  Please speak up if that is the case.
>
> I'm ok with the latest revision. Just a small request: John Todd from
quad9 sent his feedback, so it's fair to credit him in the next revision of
the draft.



>
> This starts a Working Group Last Call for draft-ietf-dnsop-extended-error
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
>
> The Current Intended Status of this document is: Standards Track
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  26
> September 2019.
>
> thanks
> tim
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-07.txt

[Loganaden Velvindron]

On Wed, Sep 11, 2019 at 7:42 AM Wes Hardaker  wrote:
>
> Loganaden Velvindron  writes:
>
> Hi Loganaden,
>
> Thanks for the comments about the EDE draft.  I've marked up your
> comments with responses and actions below.  Let us know if you have any
> questions.
Hi Wes,

One small note: This reply was from John Todd from Quad9. I asked him to review
the draft, and he sent me his comments which I then forwarded to the
dnsop wg mailing list.


>
> 11 Loganaden Velvindron
> ==
>
> 11.1 NOCHANGE pass-through
> ~~
>
>   1) I see at least one more model that needs to be supported, which is
>   how to handle edns extended codes that are generated by a remote
>   server, i.e. passthrough. Layering multiple forwarding resolvers
>   behind each other is common, and some way to notify the end user that
>   the originating message was not generated by the first resolver would
>   be important.  I don't know if there needs to be some way to indicate
>   how "deep" the error was away from the end user; it seems just two
>   levels (locally generated or non-locally generated) would be
>   sufficient with only minor thought on it.
>
>   Re: 1) This is a good point, but implementation will likely run afoul
>   of existing standards or else require duplicative response codes or
>   use of an additional flag in the INFO-CODES section.  Perhaps a new
>   flag type, similar to AA, which can be used to say that this recursor
>   will return this result reliably/deterministically.  Attempting to
>   provide depth is perhaps unlikely, but flags for
>   stub/forwarder/recursive/intermediate recursive or a subset of those
>   might make sense.  Perhaps a non-descript flag such as 'DR' for
>   Deterministic Response.  Obviously INFO-CODES can support many
>   different flags, of which IR (Intermediate Resolver) or such could be
>   included at the point of response generation, with the last server
>   providing actual data in the chain being the one to authoritatively
>   set the flag, which then must not be modified by further downstream
>   resolvers in the process of returning the response.
>
>   + Response: this has been discussed a few times, and the current view
> (that at least I hold, and likely others based on past discussions)
> is that it would be best to get this out as is, without a
> pass-through model while we deploy it and get operational experience
> with its use.  Pass-through is complex for a bunch of reasons (NAT
> alone, eg), and it's unclear we can come up with a solution for all
> the likely corner cases to appear.
>
> TL;DR: we should definitely work on it, but in the future.
>
>
> 11.2 DONE network error code needed beyond timeout
> ~~
>
>   1) SERVFAIL needs another error code to indicate the difference
>   between a network error (unexpected network response like ICMP, or TCP
>   error such as connection refused) versus timeout of the remote auth
>   server, as that is often a confusing issue.
>
>   + Response: looks like a reasonable idea, so it has been added to the
> latest draft.  thank you!
>
>   Re: 2) Specifics as an item in the below list.
>
>
> 11.3 NOCHANGE
> ~~
>
>   1) Really, I'd like to see a definition of some of the EXTRA TEXT
>   strings here, since that will be almost immediately an issue that
>   would need to be sorted out before this could be useful. There have
>   been some discussions (sorry, don't know if it's a draft or just
>   talking) about browsers consuming "extra" data in DNS responses that
>   can do a number of things.  As an example that is important to Quad9
>   (or any blocking-based DNS service) it might be the case that upon
>   receiving a request for a "blocked" qname/qtype, we would hand back a
>   forged answer that leads to a splash page as the default result.
>   However, if the request was made from a resolver stack that had the
>   EDNS extensions, we might include the "real" result in the EXTRA TEXT
>   field, as well as a URL that points the user to an explanation of why
>   that particular qname/qtype was blocked.  Or we might add a risk
>   factor, or type of risk ("risk=100, risktype=phishing") or the like.
>   This allows a single query to be digestable by "dumb" stacks that we
>   want to have do the most safe thing, but also allow "smart" resolver
>   stacks to present a set of options to the end user.
>
>   + Again, I suspect that the complexity associated with standardizing
> on exactly a structure (including interna

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-07.txt

[Loganaden Velvindron]

On Sat, Aug 10, 2019 at 9:14 AM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>
> Title   : Extended DNS Errors
> Authors : Warren Kumari
>   Evan Hunt
>   Roy Arends
>   Wes Hardaker
>   David C Lawrence
> Filename: draft-ietf-dnsop-extended-error-07.txt
> Pages   : 13
> Date: 2019-08-09
>
> Abstract:
>This document defines an extensible method to return additional
>information about the cause of DNS errors.  Though created primarily
>to extend SERVFAIL to provide additional information about the cause
>of DNS and DNSSEC failures, the Extended DNS Errors option defined in
>this document allows all response types to contain extended error
>information.
>
>
I went to talk to quad9. Here is the reply they sent.

Fwd:

1) I see at least one more model that needs to be supported, which is
how to handle edns extended codes that are generated by a remote
server, i.e. passthrough. Layering multiple forwarding resolvers
behind each other is common, and some way to notify the end user that
the originating message was not generated by the first resolver would
be important.  I don't know if there needs to be some way to indicate
how "deep" the error was away from the end user; it seems just two
levels (locally generated or non-locally generated) would be
sufficient with only minor thought on it.


Re: 1) This is a good point, but implementation will likely run afoul
of existing standards or else require duplicative response codes or
use of an additional flag in the INFO-CODES section.
Perhaps a new flag type, similar to AA, which can be used to say that
this recursor will return this result reliably/deterministically.
Attempting to provide depth is perhaps unlikely, but flags for
stub/forwarder/recursive/intermediate recursive or a subset of those
might make sense.
Perhaps a non-descript flag such as 'DR' for Deterministic Response.
Obviously INFO-CODES can support many different flags, of which IR
(Intermediate Resolver) or such could be included
at the point of response generation, with the last server providing
actual data in the chain being the one to authoritatively set the
flag, which then must not be modified by further
downstream resolvers in the process of returning the response.

2) SERVFAIL needs another error code to indicate the difference
between a network error (unexpected network response like ICMP, or TCP
error such as connection refused) versus timeout of the remote auth
server, as that is often a confusing issue.

Re: 2)  Specifics as an item in the below list.

3) Really, I'd like to see a definition of some of the EXTRA TEXT
strings here, since that will be almost immediately an issue that
would need to be sorted out before this could be useful. There have
been some discussions (sorry, don't know if it's a draft or just
talking) about browsers consuming "extra" data in DNS responses that
can do a number of things.  As an example that is important to Quad9
(or any blocking-based DNS service) it might be the case that upon
receiving a request for a "blocked" qname/qtype, we would hand back a
forged answer that leads to a splash page as the default result.
However, if the request was made from a resolver stack that had the
EDNS extensions, we might include the "real" result in the EXTRA TEXT
field, as well as a URL that points the user to an explanation of why
that particular qname/qtype was blocked.  Or we might add a risk
factor, or type of risk ("risk=100, risktype=phishing")  or the like.
This allows a single query to be digestable by "dumb" stacks that we
want to have do the most safe thing, but also allow "smart" resolver
stacks to present a set of options to the end user.

Re: 3) Seems reasonable.

4) I'm confused as to why a "blocked" or "censored" result would have
a retry as mandatory.   The resolver gave a canonical answer from the
point of policy.

Re: 4) See below notes.

Potential inclusions/Adjustments:

4.1.3.1: A use case exists where a stale answer should attempt a
retry. A declarative setting for the Retry bit should not be specified
here, but instead guidance on whether or not the R bit should be set
should be included. For example, when using a front-end load balancer,
if the recursive backends are temporarily inaccessible but are
expected to recover in time to handle a subsequent query, it would be
prudent to include the R bit. No additional load would be generated
towards the Authoritatives in this case, and the Intermediate Recursor
may choose to set the R bit or not based on whether the failure mode
appears to be temporary.

4.1.5: Another area where guidance should be provided. Some recursive
resolvers process requests out of order, asynchronou

Re: [DNSOP] Call for Adoption: draft-sury-toorop-dnsop-server-cookies

[Loganaden Velvindron]

On Sunday, July 7, 2019, Tim Wicinski  wrote:

> All
>
> This draft was presented at our previous meeting, and there was
> positive feedback on document DNS cookie interoperability.
> The chairs have been waiting for the draft to be updated to
> beging the call for adoption.
>
>
> This starts a Call for Adoption for draft-sury-toorop-dnsop-server-cookies
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-sury-toorop-dnsop-server-cookies/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
I support adoption.


>
> This call for adoption ends: 20 July 2019
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The DNSOP WG has placed draft-sury-toorop-dnsop-server-cookies in state "Candidate for WG Adoption"

[Loganaden Velvindron]

On Sun, Jul 7, 2019 at 10:35 AM IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> The DNSOP WG has placed draft-sury-toorop-dnsop-server-cookies in state
> Candidate for WG Adoption (entered by Tim Wicinski)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-sury-toorop-dnsop-server-cookies/
>
> I support adoption of this draft as a wg document.


> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Loganaden Velvindron]

On Tue, Jul 2, 2019 at 10:13 PM Matthijs Mekking 
wrote:

> Hi,
>
>
> A while back I was asked why BIND 9 still had code to do DLV. Good
> question, and we asked our users if they would mind if we remove the
> code. Almost everyone was okay with that.
>
> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
> time to move the protocol to Historic status as a clear signal to
> everyone that it should no longer be implemented or deployed.
>
> Dan Mahoney cleared the only well-known DLV registry almost two years
> ago. Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.
>
> I think that it's worth going forward.

ISC BIND commit:
https://github.com/isc-projects/bind9/commit/f29359299aaab519f39b090cd83de85cd2fc3820



> Best regards,
>
> Matthijs
>
>
>  Forwarded Message 
> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
> has been successfully submitted by Matthijs Mekking and posted to the
> IETF repository.
>
> Name: draft-mekking-dnsop-obsolete-dlv
> Revision: 00
> Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> Pages:5
> Status:
>
>   https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/
>
> Abstract:
>This document obsoletes DNSSEC lookaside validation (DLV) and
>reclassifies RFCs 4431 and 5074 as Historic.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-sury-toorop-dns-cookies-algorithms-00.txt

[Loganaden Velvindron]

On Tue, Mar 12, 2019 at 3:29 PM Willem Toorop  wrote:

> Dear DNSOP,
>
> A new draft has been submitted addressing the issue of DNS Cookies in
> multi-vendor anycast deployments.
>
> DNS Cookies are currently impractical in such deployments, because one
> implementation - even though it shares its secret with another
> implementation - cannot validate the Server Cookies constructed by that
> other implementation, because their methods for constructing Server
> Cookies differ.
>
> This draft provides precise directions for creating Server Cookies to
> align the implementations.  In doing so, this draft introduces a
> registry for functions suitable for Cookie construction.  More
> specifically, FNV and HMAC-SHA-256-64 are obsoleted and SipHash-2.4 is
> introduced as a suitable function.
>
> Willem
>
>  Forwarded Message 
> Subject: New Version Notification for
> draft-sury-toorop-dns-cookies-algorithms-00.txt
> Date: Mon, 11 Mar 2019 09:12:24 -0700
> From: internet-dra...@ietf.org
> To: Willem Toorop , Ondrej Sury 
>
>
> A new version of I-D, draft-sury-toorop-dns-cookies-algorithms-00.txt
> has been successfully submitted by Willem Toorop and posted to the
> IETF repository.
>
> Name:   draft-sury-toorop-dns-cookies-algorithms
> Revision:   00
> Title:  Algorithms for Domain Name System (DNS) Cookies
> construction
> Document date:  2019-03-11
> Group:  Individual Submission
> Pages:  7
> URL:
>
> https://www.ietf.org/internet-drafts/draft-sury-toorop-dns-cookies-algorithms-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-sury-toorop-dns-cookies-algorithms/
> Htmlized:
> https://tools.ietf.org/html/draft-sury-toorop-dns-cookies-algorithms-00
> Htmlized:
>
> https://datatracker.ietf.org/doc/html/draft-sury-toorop-dns-cookies-algorithms
>
>
> Abstract:
>[RFC7873] left the construction of Server Cookies to the discretion
>of the DNS Server (implementer) which has resulted in a gallimaufry
>of different implementations.  As a result, DNS Cookies are
>impractical to deploy on multi-vendor anycast networks, because the
>Server Cookie constructed by one implementation cannot be validated
>by another.
>
>This document provides precise directions for creating Server Cookies
>to address this issue.  Furthermore, [FNV] is obsoleted as a suitable
>Hash function for calculating DNS Cookies.  [SipHash-2.4] is
>introduced as a new REQUIRED Hash function for calculating DNS
>Cookies.
>
>This document updates [RFC7873]
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
Small typo:
I would suggest this:
Section 4 4th paragraph:
"implement only a pseudorandom functions for DNS Cookies"
 to
"implement only a pseudorandom function for DNS Cookies"

  [SipHash-2.4] is a pseudorandom function suitable as message
   authentication code, and this document REQUIRES compliant DNS Server
   to use SipHash24 as a mandatory and default algorithm for DNS Cookies
   to ensure interoperability between the DNS Implementations.

Also, I would suggest explaining a little bit the advantages of SipHas-2.4:

fast computation + quite secure up to now.





___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Deprecating the status opcode

[Loganaden Velvindron]

On Wed, May 15, 2019 at 2:06 PM John Dickinson  wrote:

> Hi,
>
> In the spirit of deprecating things I have submitted a draft to deprecate
> the status opcode.
>
> A new version of I-D,
> draft-dickinson-dnsop-deprecating-status-opcode-00.txt
> has been successfully submitted by John Dickinson and posted to the
> IETF repository.
>
> Name:   draft-dickinson-dnsop-deprecating-status-opcode
> Revision:   00
> Title:  Depreciating the DNS Status OpCode
> Document date:  2019-05-13
> Group:  Individual Submission
> Pages:  4
> URL:
> https://www.ietf.org/internet-drafts/draft-dickinson-dnsop-deprecating-status-opcode-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-dickinson-dnsop-deprecating-status-opcode/
> Htmlized:
> https://tools.ietf.org/html/draft-dickinson-dnsop-deprecating-status-opcode-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-dickinson-dnsop-deprecating-status-opcode
>
>
> Abstract:
>This document updates RFC1035 to depreciate the Status DNS OpCode.
>
>
This looks reasonable to me.


>
> John Dickinson
>
> https://sinodun.com
>
> Sinodun Internet Technologies Ltd.
> Magdalen Centre
> Oxford Science Park
> Robert Robinson Avenue
> Oxford OX4 4GA
> U.K.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Root zone KSK-2010 is now revoked

[Loganaden Velvindron]

Dear Matt,

Thank you and your team for the hard work to make this possible.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] FOSDEM 2019 DNS devroom CfP

[Loganaden Velvindron]

It would be nice if fosdem could allow remote participation, similar to how
the ietf is doing.


On Saturday, November 24, 2018, Tim Wicinski  wrote:

> FYI, this will be +1 UTC for those keeping track of the time
>
> While I don't receive the travel approval to attend this, I have in the
> past woken early to listen to many of these talks.
> This is useful to operators as well as developers.
>
> Tim
>
>
> On Thu, Nov 15, 2018 at 4:09 PM Peter van Dijk <
> peter.van.d...@powerdns.com> wrote:
>
>> Hello DNSOP!
>>
>> tl;dr Please consider submitting a presentation for the DNS devroom at
>> FOSDEM 2019.
>>
>> More details:
>>
>> Every year, developers from all over Europe (and some from farther away)
>> meet in Brussels to discuss Open Source software and many other topics.
>> After a successful and packed DNS devroom (track) last year, we are happy
>> to announce a full-day DNS devroom at FOSDEM 2019.
>>
>> As with last year, we hope to host talks anywhere from hardcore protocol
>> stuff to practical sessions for programmers that are not directly involved
>> with DNS - but may have to deal with DNS in their day to day coding - or
>> for system administrators responsible for DNS infrastructure.
>>
>> The standardisation community needs developers; this is your chance to
>> reach out to them, tell them what you are up to, and perhaps even get a
>> couple of them on board to implement your ideas!
>>
>> We have been allotted a room on Sunday, 3 February 2019. We expect to
>> schedule 30 minutes per talk, including questions, but we have some
>> flexibility if you need more or less time.
>>
>> If you have something you’d like to share with (your fellow) developers,
>> please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM19..
>> Examples of topics are measuring, monitoring, DNS libraries, anecdotes on
>> how you’ve (ab)used the DNS, and of course any (upcoming) RFCs that have
>> your interest. Here’s the 2018 schedule, for your inspiration:
>> https://archive.fosdem.org/2018/schedule/track/dns/ .
>>
>> The deadline for submission is Saturday, 1 December 2018. If you have a
>> FOSDEM pentabarf account from a previous year, please use that account.
>> Reach out to dns-devroom-mana...@fosdem.org if you run into any trouble.
>>
>> See you there!
>>
>> Cheers,
>> Peter van Dijk, Shane Kerr, Pieter Lexis, and Kees
>> Monshouwer___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update

[Loganaden Velvindron]

On Tue, Oct 2, 2018 at 4:51 PM Tim Wicinski  wrote:
>
>
> The chairs and the authors of this document feel that the
> document is in solid shape to proceed to WGLC.
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-algorithm-update
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
>

Section 3.1.

"
 RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones
   deploying it are recommended to switch to ECDSAP256SHA256 as there is
   an industry-wide trend to move to elliptic curve cryptography.
"

And also this paragraph:
"

RSASHA256 is in wide use and considered strong.

"

My suggestion would be to include figures or at minimum a reference.
There is a document from ISOC with 3 tables where there is an analysis
of deployment DNSSEC worldwide.

https://www.internetsociety.org/wp-content/uploads/2017/08/ISOC-State-of-DNSSEC-Deployment-2016-v1.pdf,
Page 23 & Page 24.


> The Current Intended Status of this document is: Proposed Standard
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak 
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  16 
> October 2018
>
> thanks
> tim
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop