r good
old DNS. 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
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
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
son, T.
> Lemon, T. Pusateri
> Category: PROPOSED STANDARD
> Source : Domain Name System Operations
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
John Dickinson
https://sinodun.com
Sinodun Inter
although 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 OX
ment.
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
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
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
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
e of
"views" to allow the recursor 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 mai
iginal
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
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.org
https
LS
profile 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.
___
DNS
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 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
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 Robinson Avenue
Oxford OX4 4GA
U.K.
___
DN
Capture Format
> Authors : John Dickinson
> Jim Hague
> Sara Dickinson
> Terry Manderson
> John Bond
> Filename: draft-ietf-dnsop-dns-capture-format-03
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 word
nternet-Drafts 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 Dickins
, 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
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
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
s 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
> DNSOP@i
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 pe
On 14/07/2015 17:26, Casey Deccio wrote:
On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman mailto:paul.hoff...@vpnc.org>> wrote:
On 13 Jul 2015, at 14:20, Casey Deccio wrote:
4. In the definition of RRset, the bit about TTLs needing to be
the same
seems out of place
On 14/07/2015 18:15, Tim Wicinski wrote:
On 7/14/15 12:26 PM, Tony Finch wrote:
Paul Hoffman 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 last few months there
Hi,
On 07/07/2015 12:29, Tony Finch wrote:
John Dickinson 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-case them or
Requirements
Authors : John Dickinson
Sara Dickinson
Ray Bellis
Allison Mankin
Duane Wessels
Filename: draft-ietf-dnsop-5966bis-02.txt
Pages
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: Indi
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,
On 05/06/2015 17:50, Paul Hoffman wrote:
Thanks again for the in-depth review. A few comments below.
On Jun 4, 2015, at 5:35 PM, Tony Finch wrote:
The definition of "authoritative data" is still wrong.
We have done the best we can with this, given that RFC 1034's definition is in
dispute.
> On Thursday, January 15, 2015, Matthijs Mekking
> 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.
>
> http://www.ietf.org/internet-drafts/draf
On 9 Mar 2015, at 16:32, Stephane Bortzmeyer wrote:
>
> I re-send here two questions that have apparently not been addressed
> in -01
Hi Stephane,
Sorry, this was my oversight. I have added them to the issue tracker at
https://github.com/DNSOP/draft-5966-bis. I will make sure they are addresse
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, et
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:
On 8 Jul 2013, at 18:03, Olafur Gudmundsson 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 I wan
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 part
Yuri,
Thanks for the feedback.
On 14 Aug 2012, at 09:54, Yuri Schaeffer 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 these are co
On Feb 1, 2012, at 12:11 PM, bmann...@vacation.karoshi.com wrote:
>
> The Root Server System Advisory Committee of ICANN has been working on a
> revision to RFC 2870.
> It is currently posted as:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directori
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 clau
@sinodun.com, step...@isc.org, roy.are...@nominet.org.uk
> Subject: New Version Notification for
> draft-dickinson-dnsop-nameserver-control-02
>
>
> A new version of I-D, draft-dickinson-dnsop-nameserver-control-02.txt has
> been successfully submitted by John Dickinson and po
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 su
documentation providing advice to
registrants would be useful? I am not sure at what level this would
work. I suspect TLD operators might be best positioned to write this
kind of advice for registrants using their TLD.
John Dickinson
Sinodun Internet Technologies Ltd.
Stables 4, Suite 11
c/o HR
Hi,
It might also be worth adding a line at the start reminding of the need for
NSEC and NSEC3 - namely that the signing and serving of the zone are separate
operations and that it is therefore necessry to create records that cover the
very large number of non-existent names that lie between th
uld have and what RRSets
they actually sign.
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
.
John
Begin forwarded message:
A new version of I-D, draft-dickinson-dnsop-nameserver-
control-00.txt has been successfuly submitted by John Dickinson and
posted to the IETF repository.
Filename:draft-dickinson-dnsop-nameserver-control
Revision:00
Title: Design for a
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".
46 matches
Mail list logo
