- Original Message -
From: Chris Thompson c...@cam.ac.uk
To: George Barwood george.barw...@blueyonder.co.uk
Cc: dnsop@ietf.org
Sent: Tuesday, July 05, 2011 9:09 PM
Subject: Re: [DNSOP] CDS RRtype - automated KSK rollover
On Jun 12 2011, George Barwood wrote:
I have updated the draft
- Original Message -
From: Stephen Morris sa.morr...@googlemail.com
To: dnsop@ietf.org
Sent: Thursday, June 30, 2011 3:32 PM
Subject: Re: [DNSOP] CDS RRtype - automated KSK rollover
On 12/06/2011 20:50, George Barwood wrote:
I have updated the draft
http://www.ietf.org/id/draft
I have updated the draft
http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt
I have added an appendix with an exampler KSK rollover, and made
various generally minor changes.
IANA have now assigned type code 59 for the CDS RRtype.
I'd like to request that the WG adopt this document.
.
It is double-DS, but given that DS records are relatively small, this may be a
lesser consideration,
whereas the size of the DNSKEY response is most likely to be affected by
fragmentation/TCP fallback
considerations.
George Barwood
___
DNSOP mailing list
(4) Stop signing with DNS_K_2, start signing with DNS_K_1
Apologies, that should of course be
(4) Stop signing with DNS_K_1, start signing with DNS_K_2
George
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for
the com zone is only 900 seconds (the SOA TTL). This is probably appropriate
for a NameError
(NxDomain) response, but 1 day might be more appropriate for a negative DS
response, to improve
caching performance and reduce load on servers.
I support publication of this document.
Regards,
George
- Original Message -
From: Rickard Bellgrim rickard.bellg...@iis.se
To: dnsop@ietf.org
Sent: Wednesday, November 10, 2010 3:53 PM
Subject: [DNSOP] Comments on DS Publication draft
Hi
I have some comments on the document draft-barwood-dnsop-ds-publish-01:
1. Introduction (3rd
Joe,
Not directly related to this draft ( it's probably out of scope ), but is there
any guidance on the timing of rollover of the Trust Anchor for the Root Zone?
Specifically, how many days/months in advance will a replacement Trust Anchor
be published before the old Trust Anchor becomes
Sorry, the link was for the previous version. The new version is
http://tools.ietf.org/id/draft-barwood-dnsop-ds-publish-01.txt
- George
- Original Message -
From: George Barwood george.barw...@blueyonder.co.uk
To: dnsop@ietf.org
Sent: Saturday, July 03, 2010 10:42 AM
Subject: [DNSOP
- Original Message -
From: Wolfgang Nagele wnag...@ripe.net
To: George Barwood george.barw...@blueyonder.co.uk
Cc: Mark Andrews ma...@isc.org; dnsop@ietf.org
Sent: Friday, July 02, 2010 8:13 AM
Subject: Re: [DNSOP] Fwd: New Version
Notificationfordraft-mekking-dnsop-auto-cpsync-00
- Original Message -
From: Shane Kerr sh...@isc.org
To: Wolfgang Nagele wnag...@ripe.net
Cc: dnsop@ietf.org
Sent: Thursday, July 01, 2010 9:01 PM
Subject: Re: [DNSOP] Fwd: New Version Notification
fordraft-mekking-dnsop-auto-cpsync-00
I do think that George's approach only makes
I'd like to encourage some discussion of the relative merits of the UPDATE
approach
http://www.ietf.org/id/draft-mekking-dnsop-auto-cpsync-00.txt
compared to the publication approach outlined in the recent draft at
http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt
I haven't yet
- Original Message -
From: Stephan Lagerholm stephan.lagerh...@secure64.com
To: George Barwood george.barw...@blueyonder.co.uk; dnsop@ietf.org
Sent: Wednesday, June 30, 2010 2:25 PM
Subject: RE: [DNSOP] Fwd: New Version
Notificationfordraft-mekking-dnsop-auto-cpsync-00
I would
/2010 11:59 AM, George Barwood wrote:
It could also note that validators SHOULD NOT check the RRSIG for a DNSKEY
RRset
where all the keys are validated by DS records.
This is not possible, and Casey thought similarly, so here is text: The
RRSIG from a DNSKEY identified by a DS record must
Well, I have uploaded a draft :
http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt
Comments and/or indications of support are of course welome, on or off list.
George
- Original Message -
From: George Barwood george.barw...@blueyonder.co.uk
To: dnsop@ietf.org
Sent: Thursday
Chris,
Thanks for your comments.
- Original Message -
From: Chris Thompson c...@cam.ac.uk
To: George Barwood george.barw...@blueyonder.co.uk
Cc: dnsop@ietf.org
Sent: Saturday, May 22, 2010 8:07 PM
Subject: Re: [DNSOP] KSK rollover
On May 22 2010, George Barwood wrote:
Well, I have
/
but that's all I found.
Have I missed something? It seems to me that this is a rather vital component if
DNSSEC is to be widely deployed.
Are there any plans to revive and/or implement these requirements?
George Barwood
___
DNSOP mailing list
DNSOP@ietf.org
- Original Message -
From: Patrik Wallstrom pa...@blipp.com
To: George Barwood george.barw...@blueyonder.co.uk
Cc: dnsop@ietf.org
Sent: Thursday, May 13, 2010 9:06 AM
Subject: Re: [DNSOP] KSK rollover
On May 13, 2010, at 9:56 AM, George Barwood wrote:
I have been thinking about KSK
- Original Message -
From: Nicholas Weaver nwea...@icsi.berkeley.edu
To: George Barwood george.barw...@blueyonder.co.uk
Cc: Nicholas Weaver nwea...@icsi.berkeley.edu; dnsop@ietf.org
Sent: Saturday, March 20, 2010 2:26 PM
Subject: Re: [DNSOP] Should root-servers.net be signed
On Mar 20
:17 AM, Matt Larson wrote:
On Mon, 08 Mar 2010, George Barwood wrote:
It's interesting to note that currently
dig any . @a.root-servers.net +dnssec
truncates, leading to TCP fallback
but
dig any . @l.root-servers.net +dnssec
does not truncate ( response size is 1906 bytes
- Original Message -
From: Nicholas Weaver nwea...@icsi.berkeley.edu
To: George Barwood george.barw...@blueyonder.co.uk
Cc: Nicholas Weaver nwea...@icsi.berkeley.edu; Matt Larson
mlar...@verisign.com; dnsop@ietf.org
Sent: Friday, March 19, 2010 12:33 PM
Subject: Re: [DNSOP] Should root
It cuts the response from 4K to 1.5K, and I think fragmentation that
contributes
to these attacks being damaging.
All I need to do is find a set of open resolvers which don't have such limits
to do juuust fine.
Eventually the open resolvers will get updated, and thus these attacks will
It seems that
m.root-servers.net
is now serving DNSSEC, but does not have TCP, so the following queries all fail
dig any . @m.root-servers.net
dig rrsig . @m.root-serves.net
dig any . @m.root-servers.net +dnssec +bufsize=1400
None of these are normal queries, but seems a bit doubtful even
- Original Message -
From: Jim Reid j...@rfc1035.com
To: George Barwood george.barw...@blueyonder.co.uk
Cc: dnsop@ietf.org
Sent: Wednesday, March 17, 2010 12:23 PM
Subject: Re: [DNSOP] m.root-servers.net DNSSEC TCP failures
On 17 Mar 2010, at 11:28, George Barwood wrote:
It seems
- Original Message -
From: Joe Abley jab...@hopcount.ca
To: Tony Finch d...@dotat.at
Cc: George Barwood george.barw...@blueyonder.co.uk; dnsop@ietf.org
Sent: Monday, March 08, 2010 4:22 PM
Subject: Re: [DNSOP] Should root-servers.net be signed
On 2010-03-08, at 11:18, Tony Finch
I have been wondering about this.
For a resolver behind a NAT firewall that removes port randomization,
it is possible for an attacker to spoof the priming query ( only 16 bits of
ID protection ).
If root-servers.net is unsigned, it's not possible for the resolver to validate
the set of root IP
Any reaction to this CircleID article ?
http://www.circleid.com/posts/dns_resolvers_and_dnssec_roll_over_and_die/
It seems that BIND and Unbound can
enter a mode of sustained, repeated and very rapid querying of DNS servers
for DNSKEY and RRSIG Resource records, causing potential problems
Why would glue records be signed? That's not normal in DNSSEC, AFAIK.
To correct my statement, the following query shows that glue records may be
signed
dig soa se @a.ns.se + dnssec
wich has a response size of 2944 bytes. However, most of this is Additional
Section RRSIGS, and
dig soa se
- Original Message -
From: Jim Reid j...@rfc1035.com
To: George Barwood george.barw...@blueyonder.co.uk
Cc: IETF DNSOP WG dnsop@ietf.org
Sent: Saturday, January 16, 2010 1:25 PM
Subject: signing glue and additional data
On 16 Jan 2010, at 11:17, George Barwood wrote:
To correct my
- Original Message -
From: Olafur Gudmundsson o...@ogud.com
To: dnsop@ietf.org
Sent: Wednesday, January 13, 2010 6:19 PM
Subject: [DNSOP] Priming query transport selection
26 signed glue records will require about 5K answer if each RRSet is
signed by a single 1024 bit RSA key.
This
Ray,
I have read the draft, found no problems other than the missing security
considerations
( I don't see any particular security considerations ), and fully support it.
Did you consider a referral model using NS records?
LOCAL.ARPA.9000NSA.LOCAL.ARPA.
LOCAL.ARPA.9000NS
is fundamentally misconceived
and wrong.
I oppose it's adoption as a WG document.
You can put lipstick on a pig, but it's still a pig.
Best wishes,
George Barwood
UK
Kind regards,
Roy Arends
Nominet UK
___
DNSOP mailing list
DNSOP@ietf.org
https
I'm seeing a malformed response to EDNS options from the name servers for
atdmt.com, e.g.
dig +nsid clk.atdmt.com @glb04.aquantive.com
reports
;; Warning: Message parser reports malformed message packet.
;; WARNING: Messages has 95 extra bytes at end
The problem seems to be triggered by any
33 matches
Mail list logo
