[DNSOP] Re: DNS traceroute - in-person discussion after dnsop WG on Thursday (today)

> On 8 Nov 2024, at 6:47 AM, John Kristoff wrote: > > On Thu, 7 Nov 2024 17:42:04 + > Petr Špaček wrote: > >> This is a very high-level description of the problem space. Let's >> discuss! Preferably in person for initial high bandwidth discussion >> and then we can continue on the mailin

[DNSOP] Re: [EXTERNAL] Re: New Version Notification for draft-momoka-dnsop-3901bis-06.txt

Hi Tobias, I'll continue with the threading of this conversation, though it may be getting challenging to follow! :-) > On 22 Oct 2024, at 6:40 PM, Tobias Fiebig wrote: > > >> I'm sorry but I don;t understand the point you are making here. > > - A DNS query for an FQDN with a length of 255

[DNSOP] Re: [EXTERNAL] Re: New Version Notification for draft-momoka-dnsop-3901bis-06.txt

> On 22 Oct 2024, at 5:18 PM, Tobias Fiebig wrote: > >> >> it seems odd to me to recommend that auth DNS servers should take >> steps to avoid fragmentation of responses (sec 4.1) while no such >> recommendation exists for recursive resolvers (sec 4.2). To avoid the >> issues with fragmentatio

[DNSOP] Re: [EXTERNAL] Re: New Version Notification for draft-momoka-dnsop-3901bis-06.txt

> On 22 Oct 2024, at 4:10 AM, Tommy Jensen > wrote: > > I'm happy to see 3901 being updated and this draft getting updated from list > discussion. Having read through the previous list discussion, I don't have > additional feedback of substance other than "this is worth working on and I > w

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

> On 10 Jul 2024, at 9:23 AM, Ben Schwartz > wrote: > > I see several different directions this could go that might be useful. > > 1. "DNS at the 99th percentile" > ... > 2. "DNS Lower Limits" > > ... > 3. "DNS Intrinsic Limits" > > ... > 4. "DNS Proof of Work" > ... The 99th percent

[DNSOP] Re: [v6ops] Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

> On 5 Jul 2024, at 10:37 AM, Tim Wicinski wrote: > > Paul > > On Thu, Jul 4, 2024 at 6:41 PM Paul Vixie > wrote: > On Thursday, July 4, 2024 7:05:22 AM PDT Tim Wicinski wrote: > > On Tue, Jul 2, 2024 at 9:26 PM David Farmer wrote: > > > 2. Also, maybe R5 should have text similar to R3 with

[DNSOP] Re: [Ext] To sign root-servers.net or not?

Thanks for the pointer! g > On 18 Jun 2024, at 7:17 AM, Paul Hoffman wrote: > > On Jun 17, 2024, at 13:33, Geoff Huston wrote: >> >> [change of topic] >> >> " things that the IETF may not have the final say on." >> >> Possibly

[DNSOP] To sign root-servers.net or not?

[change of topic] " things that the IETF may not have the final say on." Possibly true in this case, but not having the final say is very different to "having a say" I would find it interesting to understand the current state of thinking in DNSOP as to whether to DNSSEC-sign the root-servers.

[DNSOP]Re: Fwd: New Version Notification for draft-momoka-dnsop-3901bis-05.txt

Hi a few comments opjn this draft 1. RFC7766 ("All general-purpose DNS implementations MUST support both UDP and TCP transport." should also be noted at this point in the document, as avoiding fragmentation relies on a working TCP fallback 2. (minor) change "Guidelines for Authoritative D

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

> On 18 Mar 2024, at 9:32 AM, Dave Lawrence wrote: > > Shumon Huque writes: >> The draft allows (but does not proscribe) NXDOMAIN to be inserted >> into the Rcode for non DNSSEC enabled responses. I guess the main >> reason for not being proscriptive was what I mentioned - there were >> deploym

Re: [DNSOP] Notification Call for Adoption: draft-bash-rfc7958bis

I am in support of adoption by the Working Group. The process of peer review has proved to be highly valuable over the years and the result is generally a more robust framework for critical elements of the DNS infrastructure. regards, Geoff > On 17 Dec 2023, at 1:55 am, Tim Wicinski wrote: >

Re: [DNSOP] DNS IPv6 Transport Operational Guidelines (draft-momoka-dnsop-3901bis-00)

Nov 2023, at 4:43 pm, Ralf Weber wrote: > > Moin! > > On 10 Nov 2023, at 13:33, Geoff Huston wrote: > >> Here’s an analysis of measurement of issues with IPv6 and DNS resolvers from >> a few years >> ago...https://www.potaroo.net/presentations/2017-09-29-xtn-hdr

Re: [DNSOP] DNS IPv6 Transport Operational Guidelines (draft-momoka-dnsop-3901bis-00)

Here’s an analysis of measurement of issues with IPv6 and DNS resolvers from a few years ago...https://www.potaroo.net/presentations/2017-09-29-xtn-hdrs-dns.pdf I have not returned to this measurement for some years as there appeared to be little interest in the results right up until now! If

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

> On 14 Sep 2023, at 6:33 am, Tim Wicinski wrote: > > > Geoff > > We had a DNS directorate review done > https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc8109bis-00-dnsdir-early-ma-2023-08-29/ > And perhaps I was basing my vibes off of the review plus the authors. That is > on me. But

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

> On 14 Sep 2023, at 6:25 am, Tim Wicinski wrote: > > > > On Wed, Sep 13, 2023 at 5:20 PM Joe Abley wrote: > Hi Tim, > > Op 13 sep. 2023 om 23:06 heeft Tim Wicinski het volgende > geschreven: >  >> >> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis >> "Initializing

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

> On 14 Sep 2023, at 6:20 am, Joe Abley wrote: > > Hi Tim, > > Op 13 sep. 2023 om 23:06 heeft Tim Wicinski het volgende > geschreven: >  >> >> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis >> "Initializing a DNS Resolver with Priming Queries" >> >> Current versions

[DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

> > This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency > > The draft is available here: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ > > > Please review this draft to s

Re: [DNSOP] Updated: Compact Denial of Existence

> On 6 Mar 2023, at 4:20 am, Peter Thomassen wrote: > > Hi, > > I like this draft. Some thoughts: > > > 1.) Maybe it's worth pointing out that zones using compact denial SHOULD > (MUST?) use NSEC, not NSEC3. > Could you please explain your thinking here? In the same way that the ‘compact'

Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC

for what its worth I would like to chime in and support George’s view. The technique is NOT a lie per se. It's a stretch (well its the opposite of “stretch” - its a “compression”) of the intended contents of the denial of existence response, but it is not a lie as I see it. I would be far more co

Re: [DNSOP] [BEHAVE] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

> On 17 Oct 2022, at 10:58 am, Michael Richardson wrote: > > > Geoff Huston wrote: >>> On 17 Oct 2022, at 7:53 am, Michael Richardson >>> wrote: >>> I think that's because >>> recursive nameserves effectively have always done an e

Re: [DNSOP] [BEHAVE] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

> On 17 Oct 2022, at 7:53 am, Michael Richardson wrote: > I think that's because > recursive nameserves effectively have always done an equivalent to "happy > eyeballs", so the risk is low. > That certainly was not the case in 2015: https://www.potaroo.net/presentations/2015-10-04-dns-dua

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

> On 2 Aug 2022, at 2:15 am, Independent Submissions Editor (Eliot Lear) > wrote: > > > On 02.08.22 10:35, Joe Abley wrote: >> >>> Had I wanted to do so, I would not have approached dnsop in the first place. >> Had you wanted to which? I'm confused. > > I came to this group because of conc

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

> On 22 Feb 2022, at 10:29 pm, Vladimír Čunát > wrote: > > On 09/02/2022 22.41, Wes Hardaker wrote: >> So I've re-arranged things a bit to hopefully address the flow better. >> Let em know if you think further improvements are warranted. >> > I'd still probably suggest at least a minimalist cha

Re: [DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

> On 30 Oct 2021, at 10:31 am, Wessels, Duane > wrote: > > Francesca, thank you for the review. > >> On Oct 28, 2021, at 2:43 AM, Francesca Palombini via Datatracker >> wrote: >> >> >> >> I only have one very minor comments, to take or leave as you please: >> >> headers are 40 bytes (v

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

> On 29 Jul 2021, at 10:33 am, Mark Delany wrote: > > On 29Jul21, Geoff Huston allegedly wrote: > >> For me it appears to depend on the actions of the resolver as to whether >> this would be faster >> or not. If all resolvers blindly re-query using TCP for all U

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

> On 29 Jul 2021, at 10:12 am, Mark Andrews wrote: > > > >> On 29 Jul 2021, at 09:58, Geoff Huston wrote: >> >> Hi Paul, >> >>> On 29 Jul 2021, at 2:10 am, Paul Wouters wrote: >>> >>> On Wed, 28 Jul 2021, Geoff Huston

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

Hi Paul, > On 29 Jul 2021, at 2:10 am, Paul Wouters wrote: > > On Wed, 28 Jul 2021, Geoff Huston wrote: > >> i.e. amend section 3 to read:... >> >> 3. Recommendations >> >> This document clarifies RFC1034 in that in-bailiwick [RFC8499] glue (being

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

tldr - suggest cutting sections 4 and 5 completely and advancing with what’s left! > On 28 Jul 2021, at 9:25 am, Shumon Huque wrote: > > > For sibling glue, part of our rationale was indeed to cover the cases where > it is required for resolution (and not just an optimization). Those configs

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

> On 16 Jun 2020, at 8:12 am, Paul Wouters wrote: > > On Mon, 15 Jun 2020, Suzanne Woolf wrote: > >> 1. This draft as written takes no formal action to reserve anything for any >> particular purpose. It makes some observations about the administration >> of ISO 3166 and its use in the ICANN c

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

This is likely to be a Fine Proposal, worthy of serious consideration, but the venue where such topics should be considered is elsewhere, in my view. I realise that explicitly opposing such WG calls for adoption is tantamount to heresy in today’s IETF, but nevertheless I must record my oppositio

Re: [DNSOP] Creating a registry for reserved labels.

fwiw I agree with Warren’s proposal and Paul’s observation that such a registry is a good idea and it need not reflect only left-most labels. However, I worry that this approach does not generalise and scale well and the registry maintenance guidelines should reflect an appropriately rigorous an

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-kskroll-sentinel-15

Hi Jari, thanks for spending the time and doing this review. in response to the points you raise: 1. Jargon is just a constant factor in this space, and yes, the use of “CD bit” snuck in with either a reference to an explanation. I’ll uzse a reference to section 3.2.2 of RFC4035 2. your secon

Re: [DNSOP] kskroll-sentinel and unclear results

> On 1 Jun 2018, at 10:05 am, Paul Hoffman wrote: > > On 31 May 2018, at 16:49, Geoff Huston wrote: > >> Warren’s analysis indicates that when we apply the proposed tests to a >> user’s collection of resolvers (as distinct from a single resolver) the >> propo

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

> On 4 May 2018, at 3:06 am, Paul Vixie wrote: > > what are the implications for older (pre-KSKROLL) validators when icann > eventually rolls the key? I assume that you are referring to security-aware resolvers that do not perform the actions specified in this draft. There are no implication

[DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Hi WG Chairs (and WG) We have submitted -12 of this draft which we believe incorperates the substantive review comments made during the WG Last Call period that were posted to the WG Mailing List. > > Editors: Please take “concern about a description of current implementation > status” as WGLC

[DNSOP] Request to DNSOP chairs for a WGLC on draft-ietf-dnsop-kskroll-sentinel-11.txt

A Root Key Trust Anchor Sentinel for DNSSEC > Authors : Geoff Huston > Joao Silva Damas > Warren Kumari > Filename: draft-ietf-dnsop-kskroll-sentinel-11.txt > Pages :

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

>> >> >> All of the following conditions must be met to trigger special >> processing inside resolver code: >> >> o The DNS response is DNSSEC validated >> >> o The result of validation is “Secure”. >> >> o The Checking Disabled (CD) bit in the query is not set. >> >> o The QTYPE is eithe

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

> > No. Below is self contradictory. Condition 1 requires that > CD=1 be turned into CD=0 and condition 3 requires that no special > processing happens for CD=1. > > How CD is handled determines what you are testing when you have > resolvers in series. > > Do you want CD=1 to disable special

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

> On 4 Apr 2018, at 10:59 am, Mark Andrews wrote: > > >> On 4 Apr 2018, at 10:28 am, Geoff Huston wrote: >> >> I thought that if the query contained CD = 1 then the DNS response >> would not be validated, > > This ONLY applies if the answer is

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

ly saying that the resolver MUST ignore CD=1 for these > queries. > >> On 4 Apr 2018, at 7:36 am, Geoff Huston wrote: >> >> >> >>> On 4 Apr 2018, at 7:11 am, Paul Hoffman wrote: >>> >>> On 3 Apr 2018, at 13:45, Geoff Huston wrote: >&

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

> On 4 Apr 2018, at 7:11 am, Paul Hoffman wrote: > > On 3 Apr 2018, at 13:45, Geoff Huston wrote: > >> Is the wording “that the resolver has to do DNSSEC validation on what it >> gets back from the authoritative server *regardless* of whether the >> orig

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

> On 3 Apr 2018, at 11:42 pm, Paul Hoffman wrote: > > > On 3 Apr 2018, at 1:34, Geoff Huston wrote: > >> I’ll remove the condition then. > > Will you re-instate what Petr asked for, namely some wording that indicates > that the resolver has to do DNSSEC valida

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

> On 3 Apr 2018, at 5:38 pm, Mark Andrews wrote: > > AD is only set or potentially set in the response if DO or AD is set on the > query. > > The condition boils down to testing for AD or DO in the query because the > answer needs to be secure and there can’t be a CNAME or DNAME pointing to

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

> On 3 Apr 2018, at 4:39 pm, Geoff Huston wrote: > > > >> On 3 Apr 2018, at 1:10 pm, Mark Andrews wrote: >> >> Do we really want to test for AD? How many stub resolvers set DO or AD to >> elicit a AD response? >> > > I’m not sure that w

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

> On 3 Apr 2018, at 1:10 pm, Mark Andrews wrote: > > Do we really want to test for AD? How many stub resolvers set DO or AD to > elicit a AD response? > I’m not sure that we are on the same page here. The precondition is: "The AD bit is to be set in the response” i.e. it is not a test on

Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

>> >> The current text in -09 reads: >> >> The DNS response is DNSSEC validated, regardless of whether >> DNSSSEC validation was requested, and result of validation is >> “Secure” >> After discussing this with Warren and Joao I’d like to propose a slightly different wording to the

Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

> > I was VERY surprised to see the opposite text sneak its way into > a pull request, and equally surprised that a co-author of the draft > approved the request and pushed the -09 version without raising this > on the mailing list, particularly as it directly contradicts your > message here. >

[DNSOP] further problems with draft-ietf-dnsop-kskroll-sentinel-09

While I am reviewing this version of the draft, the other problem I see is a block of text that reads: "RFC 8145 relies on resolvers reporting the list of keys that they have to root servers.” The grammatical construction is ambiguous - I suspect that whoever originally submitted this tect bac

Re: [DNSOP] dnssec-kskroll-sentinel-06 clarifications

> > > 3rd proposal > > We have one more thing which needs more manpower to be verified. Right > now, the section 3.1. Preconditions is: > >> 3.1. Preconditions >> >> All of the following conditions must be met to trigger special >> processing inside resolver code: >> >> o

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07

> On 23 Mar 2018, at 12:55 am, Mark Andrews wrote: > > This title of this document DOES NOT match reality. > > "A Sentinel for Detecting Trusted Keys in DNSSEC” should be > replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. > > kskroll-sentinel-- really needs something other > than “k

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

> On 6 Mar 2018, at 9:31 am, Wessels, Duane wrote: > > >> On Mar 3, 2018, at 2:32 PM, Geoff Huston wrote: >> >> I guess that the knowledge that resolver X trusts a key with a hash value of >> Y does not leave me much the wiser in terms of exploitable knowle

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

Hi Duane, > On 1 Mar 2018, at 9:45 am, Wessels, Duane wrote: > > Thanks for the update. > > IMO this document really needs a Privacy Considerations section and maybe > also some additions to the Security Considerations. Whereas the signals in > 8145 are between the validator and the zone own

Re: [DNSOP] Updated KSK Sentinel document

Hi John, thanks for the review of this draft > On 17 Feb 2018, at 4:35 am, John Dickinson wrote: > > Hi, > > I like what this draft is trying to do. > > I am a bit concerned about adding a invalid RR in to a otherwise correctly > signed zone. It suspect that there may be a variation in how

Re: [DNSOP] sentinel and timing?

> On 8 Feb 2018, at 5:02 pm, Paul Wouters wrote: > > On Wed, 7 Feb 2018, Robert Story wrote: > >> On Wed 2018-02-07 10:43:16-0500 Paul wrote: >>> How about using this query to also encode an >>> uptime-processstartedtime value? Maybe with accurancy reduced to >>> minutes. I think that would re

Re: [DNSOP] A conversational description of sentinel.

> > Fine. Now we need to have something actionable, e.g. set of names for > Geoff to test. The first test I’ve undertaken is to test two name forms in an ad campaign over the past few days: heres an example of the test: xm--u82aa292f-c13-s1518066940-i _xm_-u82aa292f-c13-s1518066940-i0

Re: [DNSOP] A conversational description of sentinel.

> On 5 Feb 2018, at 11:47 pm, Tony Finch wrote: > > Geoff Huston wrote: >> >> if not underscores and IF “xm—“ as a leading substring is not acceptable for >> some reason, then what label format would be acceptable for this >> measure? > > Maybe put

Re: [DNSOP] A conversational description of sentinel.

> > Now when I see that this kind of problems is real, it is probably the > right time to ask Geoff to use his tools and get some data from large > scale measurement... > > Underscore is now out of the question because we know about the > Android/Chrome problem se might test alternative labels.

Re: [DNSOP] A conversational description of sentinel.

> On 2 Feb 2018, at 7:56 am, Paul Hoffman wrote: > > On 1 Feb 2018, at 12:20, Geoff Huston wrote: > >> What about if the sentinel spec proposes to use a left-most label of the >> form(s): >> >>xm—-is-ta-[key] >> >> and >> >>

Re: [DNSOP] A conversational description of sentinel.

> On 26 Jan 2018, at 3:17 am, Paul Hoffman wrote: > > On 25 Jan 2018, at 7:36, Warren Kumari wrote: > >> On Thu, Jan 25, 2018 at 10:10 AM, Tony Finch wrote: >>> Isn't this going to cause problems with software that checks hostname >>> syntax? > > Yes. However, that software will only be on t

Re: [DNSOP] kskroll-sentinel responses

> On 3 Jan 2018, at 1:33 pm, Geoff Huston wrote: > >> This answer doesn't seem to fully address Robert's and Ray's questions. Why >> use an A/ query if you aren't going to do anything with the result? If >> you are going to use A/, you have

Re: [DNSOP] kskroll-sentinel responses

> This answer doesn't seem to fully address Robert's and Ray's questions. Why > use an A/ query if you aren't going to do anything with the result? If > you are going to use A/, you have to tell resolvers what to return in the > results. Using a new RRtype would have clearer semantics.

Re: [DNSOP] kskroll-sentinel responses

> On 22 Dec 2017, at 8:44 am, Ray Bellis wrote: > > > > On 21/12/2017 15:36, Robert Story wrote: >> I reread the draft today, and noticed that two things aren't specified. >> The first is the contents of the A/ RRSET returned, and the second >> is the TTL for the records. >> >> Maybe the

Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones

> On 16 Dec 2017, at 2:31 am, Paul Hoffman wrote: > > On 14 Dec 2017, at 21:45, Geoff Huston wrote: > >>> Please see <https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/1>. >>> This is a small set of changes that make the draft not treat the root

Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones

> On 16 Dec 2017, at 2:37 am, Joe Abley wrote: > > On 15 Dec 2017, at 10:31, Paul Hoffman wrote: > >> On 14 Dec 2017, at 21:45, Geoff Huston wrote: >> >>> I agree the mechanics of the change in the text, and even in the code for >>> support this a

Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones

Hi Paul, > On 15 Dec 2017, at 12:51 pm, Paul Hoffman wrote: > > Please see . > This is a small set of changes that make the draft not treat the root zone as > special. It allows the labels to be used for any zone, not just the root.

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-00.txt

Name System Operations WG of the IETF. > > Title : A Sentinel for Detecting Trusted Keys in DNSSEC > Authors : Geoff Huston > Joao Silva Damas > Warren Kumari > Filename: draft

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

> On 14 Nov 2017, at 8:19 am, Joe Abley wrote: > > Hi Geoff, > > I think the number 4 on the slide was different from the one in the mail. I thought so too, but I wasn’t sure if it was me not paying attention in the WG meeting or not! > > The option on the slide that I mentioned I liked th

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

> On 13 Nov 2017, at 9:43 pm, tjw ietf wrote: > > To follow up from the meeting this morning, it sounded from the room that in > the case of these > four options, #4 was the one which makes the most sense. > > ….. > > 4. 32 bit code field, repeating rcode from elsewhere in the packet

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

> On 31 Oct 2017, at 6:34 pm, Tony Finch wrote: > > Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >> >>> IIRC we discussed it, and were concerned that _ta. could be cached as >>> nonexistent by servers implementing QNAME minimization. >> >> How would that happen, at least so long

Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

> On 31 Oct 2017, at 6:34 pm, Tony Finch wrote: > > Ray Bellis wrote: >> On 30/10/2017 17:40, Evan Hunt wrote: >> >>> IIRC we discussed it, and were concerned that _ta. could be cached as >>> nonexistent by servers implementing QNAME minimization. >> >> How would that happen, at least so long

Re: [DNSOP] FYI - Added note about ECDSA resolver issue in Sweden - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt

feels like a huge > impediment to technology: The use of the new algorithm is now gated by > the ability of registrars to adopt it, rather than the rate of > deployment by the actual zone holders. > > -G > > On Tue, Nov 1, 2016 at 10:15 AM, Geoff Huston wrote: >>

Re: [DNSOP] FYI - Added note about ECDSA resolver issue in Sweden - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt

> On 1 Nov. 2016, at 3:37 am, Matthew Pounsett wrote: > > > > On 31 October 2016 at 00:22, George Michaelson wrote: > It is only my personal opinion, but I believe registrars are incorrect > in performing crypto alg checks on proffered DS, and this is an > entirely unwarranted, and incorrect

Re: [DNSOP] ECDSA woes

> On 16 Oct. 2016, at 2:53 am, Mikael Abrahamsson wrote: > > On Sat, 15 Oct 2016, Ralf Weber wrote: > >> Geoff Houston did some research here some years ago and just did an update >> to his findings. You might want to look at: >> http://www.potaroo.net/ispcol/2016-10/ecdsa-v2.html > > Do

Re: [DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

> On 24 Feb 2016, at 1:51 AM, Paul Wouters wrote: > > On Tue, 23 Feb 2016, Ólafur Guðmundsson wrote: > >> RFC6761 in the context of root zone was a huge MISTAKE, > >> We have wasted enough time on 6761 fallouts, it is time for the misery to >> end. > > I dont think anyone disagrees. But wi

Re: [DNSOP] another AS112 document question

On 23 May 2014, at 3:05 am, Joe Abley wrote: > So, same basic question as before: given that rfc6304bis is already in wglc, > do we think it's worthwhile adding a sentence to the text to request the IANA > to add 112 to the "Special-Purpose AS Numbers" registry? yes _

Re: [DNSOP] another AS112 document question

On 23 May 2014, at 3:05 am, Joe Abley wrote: > So, same basic question as before: given that rfc6304bis is already in wglc, > do we think it's worthwhile adding a sentence to the text to request the IANA > to add 112 to the "Special-Purpose AS Numbers" registry? yes _

Re: [DNSOP] AS112 LOA?

I can't help thinking that resource certification might help here - but thats a "tomorrow" response rather than a "today" solution (see page 23 of http://www.potaroo.net/presentations/2006-10-12-certs.pdf) for this concept of a digitally signed LOA) Geoff Florian Weimer wrote: * Joe A

Re: [DNSOP] (fwd) I-D ACTION:draft-larson-dnsop-trust-anchor-00.txt

http://www.ietf.org/internet-drafts/draft-larson-dnsop-trust-anchor-00.txt What is a trust anchor? Is it a domain name or is it a specific key at a domain name? The question comes up when you mention that it should be a DR RR. Or should that be an RR set? The wording in section 2 is v