Re: [DNSOP] draft-dnsop-deleg-00

. The important thing is that you get the same final DNS records whatever path leads you to them. This is why I think that DNSSEC should be required. John -- John Dickinson Sinodun Internet Technologies Ltd. ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt

What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}. However, earlier incarnations of DNSSEC were thinly deployed and significantly less visible than the current DNSSEC specification. Works for me. regards John

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt

On 05/10/2022 15:52, 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 : DNS Security Extensions (DNSSEC) Author

Re: [DNSOP] [Editorial Errata Reported] RFC8490 (5804)

y: PROPOSED STANDARD > Source : Domain Name System Operations > Area: Operations and Management > Stream : IETF > Verifying Party : IESG John Dickinson https://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford

Re: [DNSOP] draft-sah-resolver-information (revised)

ugh I don’t like text that says “if it is using DoT it will know if the communication is authenticated (DoH is always authenticated)” regards John John Dickinson https://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA

Re: [DNSOP] Deprecating the status opcode

document. The source is at https://github.com/Sinodun/deprecating-status-opcode PRs are welcome if someone wants to make this doc bigger. I have corrected the spelling (thanks Baden). regards John John Dickinson https://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Pa

Re: [DNSOP] Deprecating the status opcode

On 15 May 2019, at 13:01, Joe Abley wrote: > On 15 May 2019, at 07:55, Shane Kerr wrote: > >> 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 seem

[DNSOP] Deprecating the status opcode

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

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

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

Re: [DNSOP] Adding more example configurations to draft-ietf-dnsop-7706bis

ecursor to perform DNSSEC validation. I agree, there is no need to restrict the document to loopback and we should not be using examples that require non-standardised features like views. John Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.iet

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

l context? -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robi

Re: [DNSOP] New draft for helping browsers use the DoH server associated with a resolver

P@ietf.org https://www.ietf.org/mailman/listinfo/dnsop John Dickinson http://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://ww

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

described in Section 9. I think that should go in the terminology doc. regards John John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K. ___ DNSOP mailing

Re: [DNSOP] Updated KSK Sentinel document

On 18 Feb 2018, at 20:21, Geoff Huston wrote: Hi John, thanks for the review of this draft On 17 Feb 2018, at 4:35 am, John Dickinson <j...@sinodun.com> 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

Re: [DNSOP] Updated KSK Sentinel document

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

Capture Format > Authors : John Dickinson > Jim Hague > Sara Dickinson > Terry Manderson > John Bond > Filename: draft-ietf-dnsop-dns-capture-format-03

Re: [DNSOP] Fwd: New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

On Tue, 2017-03-14 at 09:04 +0100, Jakob Schlyter wrote: > This draft should be of interest to this WG, providing an alternative > to  > draft-wouters-sury-dnsop-algorithm-update. > > jakob I like this simple short draft. I prefer its terminology. The only tiny issue I have is with the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-02.txt

are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop John Dickinson http://sino

[DNSOP] https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-02

, how should a caching recursive server behave in this case? Query again for the missing QTYPES or switch to TCP? I am also wondering how this interacts with https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-03? regards John John Dickinson http://sinodun.com Sinodun Internet

[DNSOP] draft-wkumari-dnsop-multiple-responses-03

be removed as it is tending towards saying how item 3 should be implemented. regards John John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K. signature.asc Description: OpenPGP digital signature

[DNSOP] draft-ietf-dnsop-terminology-bis-00

Hi, A couple of thoughts as I diligently read all the WG meeting material… s/gotten/acquired/ Because of its unusual nature I think a definition for the NSEC3PARAM RR would be useful. Also I guess we need to add catalog zones. regards John John Dickinson http://sinodun.com Sinodun

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

s feels like an unfortunate > decision if the first step is to publish something that looks like a > perfectly valid spec and then the spec that does things the right way comes > possibly much later on. > > _______ > DNSOP mailing list >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

On 14/07/2015 11:31, Shane Kerr wrote: John, Looks pretty good, although I have a couple of comments. First, does it make sense to discuss blocking of network prefixes rather than IP addresses? This is mentioned a couple of times in the text, but blocking an IPv6 address is like throwing a

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

On 14/07/2015 18:15, Tim Wicinski wrote: On 7/14/15 12:26 PM, Tony Finch wrote: Paul Hoffman paul.hoff...@vpnc.org wrote: This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. As far as I can tell from the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

Hi, On 07/07/2015 12:29, Tony Finch wrote: John Dickinson j...@sinodun.com wrote: We have just submitted a -02 update to the 5966bis draft. I have read through this draft. It looks in good shape to me. A general comment: can you please grep for lower-case RFC 2119 keywords and either upper

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

Requirements Authors : John Dickinson Sara Dickinson Ray Bellis Allison Mankin Duane Wessels Filename: draft-ietf-dnsop-5966bis-02.txt Pages

Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

On 29/06/2015 21:48, Warren Kumari wrote: I'd appreciate any feedback, the draft announcment is here: Name: draft-wkumari-dnsop-trust-management Revision: 00 Title: Simplified Updates of DNS Security (DNSSEC) Trust Anchors Document date: 2015-06-29 Group:

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt

On 15/06/2015 22:35, Paul Hoffman wrote: NSEC3: whether not NSEC3 is quite different from NSEC depends on your context. Functionally, in the narrow sense of allows verifiable denial of existence, they are identical. I think it would be clearer to focus on their functional similarities, and

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

On Thursday, January 15, 2015, Matthijs Mekking matth...@pletterpet.nl wrote: Hi wg, IXFR with DNSSEC is suddenly not so small anymore. Do you recognize this? Olafur and I have some ideas on keeping those zone transfers small. Your feedback is appreciated.

Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

Hi, I have been reading this draft with a view to designing an implementation. In an attempt to understand section 6 I tried to pull it apart in to more sections. I have attempted to describe the behaviour of each possible type of name server (e.g., auth, recursive, caching, forwarding, stub,

[DNSOP] Fwd: New Version Notification for draft-dickinson-dnsop-5966-bis-00.txt

Hi, Begin forwarded message: A new version of I-D, draft-dickinson-dnsop-5966-bis-00.txt has been successfully submitted by John Dickinson and posted to the IETF repository. Name: draft-dickinson-dnsop-5966-bis Revision: 00 Title:DNS Transport over TCP

Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

On 8 Jul 2013, at 18:03, Olafur Gudmundsson o...@ogud.com wrote: John, Thanks for a excellent and timely review we just about pushing out a new version when it arrived. We have accepted most of your edits and suggestions except when the text was already removed/reworded. Instead

Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

Hi, I have read draft draft-kumari-ogud-dnsop-cds-02. (Unfortunately, I have not had time to read all the on list discussion, so apologies if I duplicate comments) IMHO: Section 1.2 and 2.2.1 (Highlighted roles) should be combined and used consistently through-out. Section 2.1 refers to

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt

Yuri, Thanks for the feedback. On 14 Aug 2012, at 09:54, Yuri Schaeffer y...@nlnetlabs.nl wrote: I reviewed the DNSSEC Key Timing Considerations draft-ietf-dnsop-dnssec-key-timing-03.txt document rather extensively with emphasis on verifying correctness of the rollover timelines. I believe

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-08.txt

Hi, I realise that the focus of the document is on serving authoritative DNS information. However, could it say a bit more about validator operators. In particular, is there any good reason why validators should ever have their TA configured in a non-RFC5011 state (i.e. using trusted-keys

[DNSOP] RFC4641bis - http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration

Hi, Sorry for the very late reply to this issue. http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration Paul asked for proper use of 5011 to be added to 4641bis. I agree, In fact could we go further and give implementation advice? These are some thoughts on the

Re: [DNSOP] comments about draft-morris-dnsop-dnssec-key-timing

. John --- John Dickinson http://www.jadickinson.co.uk I am riding from Lands end to John O'Groats to raise money for Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009 ___ DNSOP mailing list DNSOP

Re: [DNSOP] reverse-mapping-considerations proposed text change

Andrew Sullivan [EMAIL PROTECTED] wrote on 25/07/2007 03:21:22: While we were talking about this issue again this evening, Stephane also kindly pointed out to me that the document uses the expression reverse query when a more appropriate expression would be query for reverse data. So the