Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures

Hi Tim On Sun, Jul 23, 2023 at 09:00:58PM -0700, Tim Wicinski wrote: > There was some operational feedback that suggests 1 second is also > a very reasonable value here. With some discussion, here is some > suggested text: > > Resolvers MUST cache resolution failures for at least 1 second.

[DNSOP] Review of draft-ietf-dnsop-structured-dns-error-03

We're implementing RFC 8914 for error reporting from NIOS's DNS features, and so I read this draft today: > DNS Operations Working Group D. Wing > Internet-DraftCitrix > Updates: 8914 (if approved)

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-11.txt

Fujiwara-san, Vixie-san, On Thu, Jan 19, 2023 at 12:13:02AM -0800, internet-dra...@ietf.org 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

Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation

On Tue, Aug 16, 2022 at 01:07:34PM +0900, Kazunori Fujiwara wrote: > Thanks very much for your review. > > > From: "to...@strayalpha.com" > > Some comments: > > > > The doc starts by grouping ICMP-based path MTU discovery (PMTUD) with > > in-band discovery (PLPMTUD), but asserts (in the > >

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Thu, Aug 04, 2022 at 03:49:48PM +0200, Joe Abley wrote: > Hi Andrew, > > On Aug 4, 2022, at 15:33, Andrew McConachie wrote: > > > I apologize for derailing this conversation by bringing up NAT. My point > > was that the document makes a claim that PMTUD ‘remains widely undeployed > > due

Re: [DNSOP] Quick review of draft-dwmtwc-dnsop-caching-resolution-failures-00

Hi Duane On Tue, Jul 12, 2022 at 09:41:45PM +, Wessels, Duane wrote: > >> 3.2. TTLs > > > >> Resolvers MUST cache resolution failures for at least 5 seconds. > >> Resolvers SHOULD employ an exponential backoff algorithm to increase > >> the amount of time for subsequent resolution

[DNSOP] Quick review of draft-dwmtwc-dnsop-caching-resolution-failures-00

Some comments quickly browsing this draft, as we're handling a quirky issue around NS timeouts and it looked relevant. Firstly, some resolver implementations do cache upstream NS timeouts in various non-standard ways. The resolver I work on has at least 3-4 different mechanisms within the same

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

Hi Brian On Sun, May 01, 2022 at 02:11:11PM +1200, Brian E Carpenter wrote: [snip] > > The copyright notice on the document says: > > > > Copyright (c) 2022 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > > > By way of this, by removing the

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

On Fri, Apr 29, 2022 at 10:54:13PM +0200, Benno Overeinder wrote: > Mukund, > > On 29/04/2022 22:27, Mukund Sivaraman wrote: > > > > > > This is indeed how the DNSOP chairs see it and have guided the (new set > > > of) > > > authors in this

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

On Fri, Apr 29, 2022 at 10:05:10PM +0200, Benno Overeinder wrote: > Hi Lars, WG, > > On 29/04/2022 12:54, Lars Eggert wrote: > > On 2022-4-29, at 0:30, Cindy Morgan wrote: > > > The rest of this is a bit of a tangle, and I've referred it to the IESG > > > for further guidance on what steps the

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

Hi Haisheng Yu / Johnson On Fri, Apr 29, 2022 at 11:05:34AM +0800, Haisheng Yu wrote: >Hi， Mukund, > This is Johnson， I'm very sorry to cause you so much trouble. > > I think the draft of draft-muks-dns-message-fragments that you >submitted to the IETF is quite

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

Hi Cindy On Thu, Apr 28, 2022 at 02:30:07PM -0700, Cindy Morgan wrote: > Hi Mukand, > > When the Secretariat got the request to review the replacement > relationship suggested by haisheng yu, I checked and saw that > "haisheng yu" was listed as an author on both > draft-hsyu-message-fragments

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

g 1460. Clients < that support DNS message fragments (and signal support using the < EDNS option) should adapt their UDP payload size discovery < algorithm to work with this feature, as the following splits on < sizes will assist PMTU discovery. < &

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

On Thu, Apr 28, 2022 at 09:33:08AM -0700, DraftTracker Mail System wrote: > > Please DO NOT reply to this email. > > I-D: > Datatracker URL: > https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/ > > This document now replaces draft-muks-dnsop-message-fragments >

Re: [DNSOP] DNSSEC as a Best Current Practice

On Thu, Apr 14, 2022 at 08:55:34PM +0900, Masataka Ohta wrote: > Paul Wouters wrote: > > > > I can't see any reason why you think the root zone is > > > more secure than TLDs, especially because, as I wrote: > > > > Because I am informed about their operational procedures and I > > contributed

Re: [DNSOP] Is DNSSEC a Best Current Practice?

On Fri, Mar 11, 2022 at 01:49:41AM -0800, Paul Vixie wrote: > Tim Wicinski wrote on 2022-03-11 01:38: > > ... for several years now I have > > felt those two need to be republished with all > > the updated text from the many updates (28 for 1035, 18 for 1034) in new > > documents.  This does not

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

On Wed, Dec 15, 2021 at 09:17:42PM +, Wessels, Duane wrote: > Despite what the subject line says, I’d like to follow up on the > discussion about glue from today’s interim meeting. > > First, I think the definition of glue given in RFC 2181 is problematic > in a number of ways. It is overly

[DNSOP] Review of draft-andrews-dnsop-defeat-frag-attack-00

Hi Mark After the paper from last week about a new variant of a Kaminsky style attack, I remembered seeing an email from you recently asking to adopt the well-known TSIG key idea. I looked for it but I'm not able to find such an email - did I imagine it? Anyway my review comments follow. There

Re: [DNSOP] DNS cache poisoning is back

On Fri, Nov 13, 2020 at 10:39:30PM -0500, John Levine wrote: > This paper from UC Riverside given at this week's ACM CCS '20 > conference describes a DNS cache poisoning attack that uses weaknesses > in UDP stacks. They say it works on real public caches including > Cloudflare, Google, and Quad 9,

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

On Wed, Jul 08, 2020 at 04:50:30PM +0200, Marek Majkowski wrote: > > The maximum buffer size offered by an EDNS0 initiator SHOULD be > > no larger than the estimated maximum DNS/UDP payload size... > > This seems to indicate that EDNS0 over TCP should have a small buffer > size as well. Consider

Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

On Fri, Jul 03, 2020 at 09:19:48PM -0400, John R Levine wrote: > > Uh, no. The TC flag means "something didn't fit". > > It is not restricted to glue, which is only in the additional section. > > TC can also be set if something from the authority section didn't fit, or > > if something didn't fit

Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

On Thu, Jul 02, 2020 at 03:29:01PM +, Paul Vixie wrote: > On Thursday, 2 July 2020 14:50:24 UTC John R Levine wrote: > > On Thu, 2 Jul 2020, Paul Vixie wrote: > > > ... but our goal should be to allow smart initiators to avoid > > > retrying with TCP out of reflex. my recommendation of TC=0 is

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.txt

On Fri, Jun 26, 2020 at 01:02:51AM +, Paul Vixie wrote: > On Thursday, 25 June 2020 18:29:03 UTC Paul Wouters wrote: > > On Thu, 25 Jun 2020, Mukund Sivaraman wrote: > > > For whoever is interested, this is a description of a pattern of queries > > > noticed at bus

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.txt

Hi Robert On Thu, Jun 25, 2020 at 04:07:25PM -0400, Robert Edmonds wrote: > This seems like a description of a resolver implementation vulnerable to > the infamous VU#457875. Perhaps an update to the standards track RFC > 5452 ("Measures for Making DNS More Resilient against Forged Answers") >

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.txt

Hi Paul On Thu, Jun 25, 2020 at 02:29:03PM -0400, Paul Wouters wrote: > On Thu, 25 Jun 2020, Mukund Sivaraman wrote: > > > For whoever is interested, this is a description of a pattern of queries > > noticed at busy public resolvers that has led to issues in at least 4 &

[DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.txt

On Thu, Jun 25, 2020 at 09:32:39AM -0700, internet-dra...@ietf.org wrote: > > A new version of I-D, draft-muks-dnsop-dns-thundering-herd-00.txt > has been successfully submitted by Mukund Sivaraman and posted to the > IETF repository. > > Name: draft-muks-dnsop-d

Re: [DNSOP] DNSSEC validates even if expired?

Hi Bob On Thu, May 14, 2020 at 10:02:45AM -0400, Bob Harold wrote: > I am preparing to enable DNSSEC validation, so I am working on alerts for > failed validations, so I can see whether they are user errors (that might > need negative trust anchors or other exceptions) or actual attacks. > > I

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

On Wed, Apr 15, 2020 at 05:11:46AM +0530, Mukund Sivaraman wrote: > One more question: > > > 3. Proposal to avoid IP fragmentation in DNS > > >o UDP requestors and responders SHOULD send DNS responses with > > IP_DONTFRAG / IPV6_DONTFRAG [RFC3542

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

One more question: > 3. Proposal to avoid IP fragmentation in DNS >o UDP requestors and responders SHOULD send DNS responses with > IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield > either a silent timeout, or a network (ICMP) error, if the path > MTU is

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

Hi Fujiwara san and Vixie san, On Tue, Apr 14, 2020 at 11:47:56AM -0400, 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

Re: [DNSOP] Specification of DNSKEY "Private-key-format"

Hi Evan On Thu, Aug 29, 2019 at 04:11:23PM +, Evan Hunt wrote: > On Thu, Aug 29, 2019 at 07:25:54PM +0530, Mukund Sivaraman wrote: > > I am asking about where this key format is specified - I want to extend > > it. > > There's never been a written specifica

Re: [DNSOP] Specification of DNSKEY "Private-key-format"

Hi Viktor On Thu, Aug 29, 2019 at 09:48:31AM -0400, Viktor Dukhovni wrote: > On Thu, Aug 29, 2019 at 06:25:02PM +0530, Mukund Sivaraman wrote: > > A tool such as BIND's dnssec-keygen generates the following formatted > > private keys: > > > > [muks@naina ~]$ cat Kexa

[DNSOP] Specification of DNSKEY "Private-key-format"

A tool such as BIND's dnssec-keygen generates the following formatted private keys: [muks@naina ~]$ cat Kexample.org.+008+10638.private Private-key-format: v1.3 Algorithm: 8 (RSASHA256) Modulus:

Re: [DNSOP] Why would a v4 client send AAAA query?

On Thu, Aug 29, 2019 at 03:13:45PM +0530, Naveen Kottapalli wrote: > My query was about the behavior we observed on a gateway where a pure v4 > subscriber (not dual-stack) has sent both A and query for the same > domain simultaneously. Just wanted to know why would a pure v4 subscriber >

Re: [DNSOP] FYI: draft-andrews-dnsop-defeat-frag-attack

On Wed, Jul 10, 2019 at 04:21:11PM +1000, Mark Andrews wrote: > I’ve written up a method to defeat UDP fragmentation attacks using TSIG. > > https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00 > > If we are going to discuss methods to defeat such attacks this should be >

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

On Tue, Mar 12, 2019 at 12:29:13PM +0100, Willem Toorop wrote: > Dear DNSOP, > > A new draft has been submitted addressing the issue of DNS Cookies in > multi-vendor anycast deployments. I came across this draft today in a thread on the dns-operations@ list. Here is a short review: * Any draft

[DNSOP] Updating draft-muks-dnsop-dnssec-sha3-01

Hi everyone Sometime ago, Jelte and I had submitted SHA-3 variants for existing DNSSEC algorithms along with working code (for BIND and ldns library). At that time, many of the reviewers felt that continuing to include use of RSA signatures (though it was upgraded to the PSS form) in new

Re: [DNSOP] Deprecating the status opcode

On Thu, May 16, 2019 at 12:23:12PM +0200, Petr Špaček wrote: > I would say that it is better to have one "cleanup" RFC instead of > one-off doc with one useful paragraph in it. With one bigger document we > could say to newcommers "this is list of things you can ignore when you > encounter them in

Re: [DNSOP] Deprecating the status opcode

Hi John On Wed, May 15, 2019 at 11:06:03AM +0100, John Dickinson wrote: > Hi, > > In the spirit of deprecating things I have submitted a draft to deprecate the > status opcode. In your support, there's atleast the "precedence" RFC deprecating IQUERY. :) Mukund

Re: [DNSOP] Deprecating the status opcode

On Wed, May 15, 2019 at 01:55:48PM +0200, Shane Kerr wrote: > John, > > On 15/05/2019 12.06, John Dickinson wrote: > > In the spirit of deprecating things I have submitted a draft to deprecate > > the status opcode. > > This seems like the most non-controversial document ever in the history of

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Thu, Feb 07, 2019 at 01:16:01PM +0100, Petr Špaček wrote: > Is it mandatory or not? Should I submit erratum for RFC 1035? Please do so. If something that's widely accepted is not clearly stated, documenting it would be helpful both to implementors and also to point as reference when checking

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Thu, Feb 07, 2019 at 09:40:24AM -0500, Ted Lemon wrote: > On Feb 7, 2019, at 9:16 AM, Tony Finch wrote: > > But in this scenario things soon go wrong, because RFC 2181 says the > > NODATA reply replaces the delegation records in the resolver's cache. This > > means that if a client explicitly

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

On Fri, Jan 18, 2019 at 06:55:16PM +0100, Benno Overeinder wrote: > 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. Considering that the method is implementable without any changes at a resolver, and that

[DNSOP] Sample experiments for resolver->auth privacy transport

Hi all Some ideas on how to practically test resolver->auth secure transport was asked during yesterday's dprive meeting. Here are some examples to test. Simulate the case of queries for names in the DNS that are hosted topologically farthest away from the tester. Assume the test is conducted in

Re: [DNSOP] RFC 2136 pre-requisite checks before client authorization checks

On Thu, Dec 06, 2018 at 04:29:13PM +0100, p vixie wrote: > It's an error in the specification. Thank you Paul. That clears it. I asked because BIND follows the RFC to the letter, and an admin may see some log messages that are unexpected for an address that's not in the update ACL.

[DNSOP] RFC 2136 pre-requisite checks before client authorization checks

Hi all Does anyone know why RFC 2136 sequences pre-requisite checks (section 3.2) to be performed before client permission checks (section 3.3)? It seems weird to sequence them in this way, especially as it is cheaper to perform client IP address checks (and some zone permission checks) earlier

Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt

On Mon, Nov 19, 2018 at 07:15:34PM +0530, Mukund Sivaraman wrote: > Hi Stephen, Francis > > On Mon, Nov 19, 2018 at 04:56:50AM -0800, internet-dra...@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. &g

Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt

Hi Mark On Wed, Nov 21, 2018 at 09:29:03AM +1100, Mark Andrews wrote: > > On 20 Nov 2018, at 12:45 am, Mukund Sivaraman wrote: > > Two points that I request this WG to discuss are: > > > > 1. Sparsely TSIG signed TCP continuation messages (section 6.4 in dr

[DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt

Hi Stephen, Francis On Mon, Nov 19, 2018 at 04:56:50AM -0800, internet-dra...@ietf.org 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 :

[DNSOP] On today's resolverless DNS meeting

Hi all It seemed that the objective (or an objective) of what is desired is for a webpage to have an and also push an address record for the hostname in the src URL. We talked about DNSSEC and certificate signing and such. If the host serving this webpage to the browser has control over the

[DNSOP] Review of draft-ietf-dnsop-7706bis-01.txt

Review comments follow: > Decreasing Access Time to Root Servers by Running One On The Same Server > draft-ietf-dnsop-7706bis-01 > Abstract >Some DNS recursive resolvers have longer-than-desired round-trip >times to the closest DNS root server. Some DNS recursive

Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

On Sat, Nov 03, 2018 at 03:12:28PM +0700, Mukund Sivaraman wrote: > The D flag seems unnecessary. Just the presence of the EDNS option in > query from the client should serve to indicate to a server that the > client explicitly does not want stale answers. I withdraw this comment. I

[DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

resolution times >during an attack. > 10. Security Considerations >The most obvious security issue is the increased likelihood of DNSSEC >validation failures when using stale data because signatures could be >returned outside their validity period. This woul

Re: [DNSOP] Waiting for DNSSEC...

On Fri, Nov 02, 2018 at 02:30:15PM -0400, Viktor Dukhovni wrote: > [ Was: Fundamental ANAME problems > Dropped In-Reply-To:, to ensure a new thread. ] > > On Fri, Nov 02, 2018 at 06:28:52PM +0100, Måns Nilsson wrote: > > > > I'll defer to other people, but it seems to me that anything that

Re: [DNSOP] Review of draft-wessels-dns-zone-digest-04.txt

Hi Duane On Mon, Oct 29, 2018 at 10:26:42PM +, Wessels, Duane wrote: > Mukund, > > Thanks for the comments. I have incorporated most of them. I will follow up > below on items I did not incorporate. > > > On Oct 29, 2018, at 8:55 AM, Mukund Sivaraman wrote: >

[DNSOP] Review of draft-wessels-dns-zone-digest-04.txt

ferent approaches. >The attacker might perform a downgrade attack to an unsigned zone. > This is why Section 4 RECOMMENDS that the verifier determine whether >or not to expect DNSSEC signatures for the zone in step 1. >The attacker might perform a downgrade atta

Re: [DNSOP] RFC7720 and AXFR

On Sun, Oct 28, 2018 at 01:32:51PM +0100, A. Schulze wrote: > Hello, > > RFC 2870 (Root Name Server Operational Requirements) say > > 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, > queries from clients other than other root servers. > > The update, RFC 7720

Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

On Wed, Oct 24, 2018 at 04:26:37PM -0400, Ted Lemon wrote: > The good news is that in a typical DNS message, N is pretty small. > Although I suppose in an internet-facing name server, pretty small is > still pretty big... In BIND, name compression is still one of the big consumers of CPU. It was

Re: [DNSOP] Minimum viable ANAME

Hi Tony On Wed, Sep 19, 2018 at 10:08:45PM +0100, Tony Finch wrote: > * minimal ANAME can be deployed unilaterally on the provisioning side > * 20 years ago and similar features are widely available (you are > * ahead of me on this one, John!); if resolvers implement it there > * will be useful

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Wed, Sep 19, 2018 at 09:48:18AM +0200, Petr Špaček wrote: > > > On 19/09/2018 09:31, Mukund Sivaraman wrote: > > On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote: > >> On 18/09/2018 22:02, JW wrote: > >>> > >>> Or

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote: > On 18/09/2018 22:02, JW wrote: > > > > Original message > > From: Mark Andrews > > > >> I would also expect a relatively large client population using SRV records > >> given the rate Firefox and Chrome browsers are

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Hi Evan On Mon, Sep 17, 2018 at 04:11:24PM +, Evan Hunt wrote: > On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote: > > Similar things can be said of other proposals. > > > > * If SRV for HTTP is brought into use, what about X% of user agents that >

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Hi Petr On Mon, Sep 17, 2018 at 12:29:13PM +0200, Petr Špaček wrote: > Originally I thought that current workarounds for CNAME at apex (which > are almost everywhere) deal with it in a more deterministic way. Do you mean the current workarounds in resolver implementations? These can be brought

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Hi Ray On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote: > On 17/09/2018 08:43, Mukund Sivaraman wrote: > > > The suggestion is only to require support in resolvers going forward for > > CNAME co-existing with other types for now. That should not break any > > d

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Hi Stephane On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote: > On Sun, Sep 16, 2018 at 03:26:56PM +0530, > Mukund Sivaraman wrote > a message of 66 lines which said: > > > Adding resolver support (to resolvers that don't have it, i.e., > > vs. R

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Hi Petr Apologies for the delayed reply. On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote: > Hello dnsop, > > beware, material in this e-mail might cause your head to explode :-) > > This proposal is based on following observations: > - It seems that DNS protocol police lost battle

Re: [DNSOP] DNSSEC threshold signatures idea

On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández wrote: > Hi Mukund. > I talked about this to Davey in Montreal. There's an implementation > in github[1] and presentations in OARC[2] and ICANN[3]. Aha so you're the original source :) > I'm not sure if its being used right now in

[DNSOP] DNSSEC threshold signatures idea

During a coversation about the Yeti project, Davey Song brought up an idea about using threshold signatures within DNSSEC. While he talked about it primarily for the root zone within the context of having multiple signers for it, I'm curious to know what operators think about the concept for other

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

On Fri, Jun 22, 2018 at 10:26:55PM -0400, Warren Kumari wrote: > I have not tried configuring cookie on Knot, but looking > in alg_containers.c, I can configure: > { 0, "FNV-64" }, > { 1, "HMAC-SHA256-64" } > > Under BIND: > cookie-algorithm: > Set the algorithm to be used when generating the

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote: > On Fri, Jun 22, 2018 at 8:57 AM Joe Abley wrote: > > > On 19 Jun 2018, at 17:03, Ray Bellis wrote: > > > > > On 19/06/2018 17:44, Tony Finch wrote: > > > > > >> SRV should have been part of the fix (and it was invented early > >

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

On Fri, Jun 22, 2018 at 01:09:14AM +1000, Mark Andrews wrote: > > So how should the DNS cookies be implemented? IMHO if one server uses > > https://tools.ietf.org/html/rfc7873#appendix-B.1 > > and another server uses https://tools.ietf.org/html/rfc7873#appendix-B.2, > > then it's not

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Wed, Jun 20, 2018 at 09:48:40AM +1000, Mark Andrews wrote: > Donald Eastlake’s early DNSSEC work had a working zone signature. It doesn’t > require signing each message. It’s just relatively expensive to compute for > large zones as it requires hashing the entire zone. > > RFC 2065 4.1.3

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Tue, Jun 19, 2018 at 04:31:55PM +0200, Petr Špaček wrote: > I wonder if this proposal is worth the complexity ... If we wanted plain > checksum we could use TSIG with built-in key (all zeroes or so) and to get > checksum for the network part with negligible implementation complexity. > (TSIG

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Tue, Jun 19, 2018 at 02:11:02PM -0400, Shumon Huque wrote: > On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote: > > > > > I think we need to first answer question why existing technologies do > > not fit the purpose. > > > > This is a reasonable question. > > I noticed that the draft

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

On Fri, Jun 15, 2018 at 04:17:00PM -0400, Erik Nygren wrote: > Software should have safe defaults that matches common expectations. > Those common expectations, as demonstrated by the configuration of all > of the large public resolvers I've tested, as well as by how common > software behaves, I

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote: > Round-robin is a documented feature that many applications use. Removing > it from DNS resolvers, and then having to add it to a much larger number of > applications, does not seem like a good trade-off. The _default_ in BIND 9.12 was

Re: [DNSOP] implementations of CSYNC?

On Wed, Mar 28, 2018 at 04:48:35PM +0100, Tony Finch wrote: > Related to the current discussion, does anyone have any links to > implementations of CSYNC? BIND implements the CSYNC rdata type but you are most likely asking about the "parental agent". If you don't find a CSYNC implementation,

Re: [DNSOP] Mis-spelled algorithm name in TSIG parameters page

On Mon, Jun 04, 2018 at 06:34:09PM +1000, Mark Andrews wrote: > Send to i...@iana.org Done Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Mis-spelled algorithm name in TSIG parameters page

"hamc-sha384" is mis-spelled on . Unlike the DNS parameters page, there's no "People" section on who maintains that list. The spelling mistake is not insignificant, as unlike with other DNS parameters, these

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Fri, Jun 01, 2018 at 10:51:00AM +, Shane Kerr wrote: > Wessels, Duane: > > > >> On May 25, 2018, at 11:33 AM, 神明達哉 wrote: > >> > >> At Wed, 23 May 2018 15:32:11 +, > >> "Weinberg, Matt" wrote: > >> > >>> We’ve posted a new version of draft-wessels-dns-zone-digest. Of note, > >> this

Re: [DNSOP] NXDOMAINs as in RFC 1034

Hi Shumon On Mon, May 28, 2018 at 09:46:08PM -0400, Shumon Huque wrote: > Yes, I agree with all of this. As you say, the tree structure of the domain > name > space implies the very interpretation of NXDOMAIN that RFC 8020 attempted > to clarify more explicitly. > > As for ambiguities in RFC

Re: [DNSOP] refer-down

Hi Andrew On Mon, May 28, 2018 at 01:22:12PM -0400, Andrew Sullivan wrote: > Dear colleagues, > > As a consequence of some of the discussion about clarifying the term > "referrals" in terminology-bis, it became clear that we didn't really > have a place that said not to do upward referrals. So,

[DNSOP] NXDOMAINs as in RFC 1034

Something that keeps coming up recently in private discussions is that there's supposedly an ambiguity in RFC 1034/1035 about NXDOMAINs, that is practically observed in broken authoritatives on the internet when implementing RFC 7816 (qname minimization), and that it was only clarified in RFC 8020

Re: [DNSOP] NXDOMAINs as in RFC 1034

On Mon, May 28, 2018 at 11:42:36PM +0530, Mukund Sivaraman wrote: > Something that keeps coming up recently in private discussions is that > there's supposedly an ambiguity in RFC 1034/1035 about NXDOMAINs, that > is practically observed in broken authoritatives on the internet when >

Re: [DNSOP] refer-down

Hi Andrew On Mon, May 28, 2018 at 02:14:51PM -0400, Andrew Sullivan wrote: > Hi, > > On Mon, May 28, 2018 at 11:17:33PM +0530, Mukund Sivaraman wrote: > > > > RFC 1034 mentions how to handle upward referrals - ignore them. > > Ok, I'll just let this expi

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

On Fri, Apr 13, 2018 at 05:35:14PM +, Evan Hunt wrote: > On Sat, Apr 14, 2018 at 01:13:30AM +0800, Mukund Sivaraman wrote: > > On Fri, Apr 13, 2018 at 04:31:35PM +, Evan Hunt wrote: > > > I could have sworn there was an RFC published several years ago concerning &g

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

On Fri, Apr 13, 2018 at 04:31:35PM +, Evan Hunt wrote: > I could have sworn there was an RFC published several years ago concerning > the prevention of cache poisoning, which specified that resolvers had to > ignore out of zone CNAMEs and re-query, but I can't find it now. Poor > google

[DNSOP] New Version Notification for draft-muks-dnsop-dns-squash-01.txt

On Mon, Apr 02, 2018 at 03:20:02AM -0700, internet-dra...@ietf.org wrote: > > A new version of I-D, draft-muks-dnsop-dns-squash-01.txt > has been successfully submitted by Mukund Sivaraman and posted to the > IETF repository. > > Name: draft-muks-dnsop-dns-squash

Re: [DNSOP] Verifying errata 5316 against RFC1034.

On Sun, Apr 01, 2018 at 01:33:17PM -0400, Warren Kumari wrote: > Can folk help me understand what should happen with this errata? > W To elaborate further: IMO there's no argument against caching if the cached record set (with wildcard owner name) was not used in synthesis of RRs. I suspect RFC

Re: [DNSOP] Current DNS standards, drafts & charter

On Sat, Mar 31, 2018 at 11:34:29PM +0200, bert hubert wrote: > On Sun, Apr 01, 2018 at 02:39:06AM +0530, Mukund Sivaraman wrote: > > Just a "guide to the RFCs" won't be sufficient. Language has to be > > corrected; large parts of RFC 1034 and 1035 have to be rewri

Re: [DNSOP] Current DNS standards, drafts & charter

On Wed, Mar 28, 2018 at 04:38:24AM -0400, Tim Wicinski wrote: > > I have looked at the same problem Bert has, but he did present it much > better than I could.  When I started thinking about this, I approached it > from the point of view of "If I have to give a co-worker a document on how > to

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote: > > On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman <m...@isc.org> wrote: > > > On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: > >> I would say that most things we have adopted in the pa

Re: [DNSOP] raising the bar: requiring implementations

Also, this "Camel" in the presentation may have been a mythological beast, but the real and existing DNS Camels that struggle with their backs breaking under the weight of DNS are the DNS implementations, especially the open source ones that are underfunded and understaffed. If someone wants to

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 01:18:36AM +0530, Mukund Sivaraman wrote: > it applies. If it is nameserver territory, I absolutely want to see an > implementation in *any* of the major DNS implementations. By major, I > mean the popular ones (e.g., PowerDNS, NSD, Unbound, Knot, etc.) This

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 05:29:18PM +0200, Matthijs Mekking wrote: > As mentioned in the meeting, I am in favor of requiring implementations > before drafts become standards. > > However, I would be opposed to limit acceptable implementations to the few > major open source DNS implementations

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: > I would say that most things we have adopted in the past few years do have > some implementations to reference. > Not when drafts are adopted, but generally before we head to WGLC I've > always wanted to see someone > who implemented the

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Hi Ondrej On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote: > > It might be a different story if one of those zombie RRtypes required > > additional processing. None spring to mind though. > > But (most of) those I picked actually *DO*: In the case of RR types, "additional

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On Fri, Mar 23, 2018 at 01:48:03PM +0100, Matthijs Mekking wrote: > Other candidates: MD, NXT, MAILA - They are obsolete too according to the > IANA DNS parameters. > > Also, if you want to deprecate MB, MG, you might want to consider > deprecating MAILB too. There are a few more that are/were

Re: [DNSOP] avoiding fragmented DNS-over-UDP

On Wed, Mar 21, 2018 at 04:10:15PM +, Tony Finch wrote: > In the intarea meeting, there was some discussion of > "IP fragmentation considered fragile" > https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile > > That draft correctly calls out the DNS as particularly problematic wrt >

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

Hi Jinmei On Mon, Mar 12, 2018 at 10:59:11AM -0700, 神明達哉 wrote: > > > this proposal. (in that sense, I'm curious: is there other DNS > > > developer than ISC that is interested in implementing this proposal?) > > > > So far: I was told that PowerDNS has implemented a plug-in/script that > >

  1   2   3   >