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

Geoff Huston wrote: 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? I thi

Re: [DNSOP] Request for Adoption: draft-larson-dnsop-trust-anchor-02.txt

7;t seem to hurt though. Scott > The deadline is Friday, DEC 14. > > -Peter > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www1.ietf.org/mailman/listinfo/dnsop > -- Scott RoseComputer Sci

Re: [DNSOP] I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-01.txt

or WGLC, please send in comments. > > thanks > Matt & Olafur > > ___ > DNSOP mailing list > DNSOP@ietf.org > http://www.ietf.org/mailman/listinfo/dnsop > -- S

[DNSOP] draft-dnsop-dnssec-trust-anchor-01 comments

I remembered that I was one of the folk volunteering to review this draft. I support this draft with some general comments below- 1. Introduction A resolver might want to maintain a zone's key as a trust anchor even if the zone has a signed delegation. Likewise a zone may wish to distribute it's

Re: [DNSOP] Revising RFC 4641 on DNSSEC Operational Practices

@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- ---- Scott RoseComputer Scientist NIST ph: +1 301-975-8439 [EMAIL PROTECTED] http://www-x.antd.nist.gov/dnssec http:/

Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section

> removed > in step 4, and after the cache data has expired, the signatures can be > removed in step 5. > > The above steps ensure that during the rollover to a new algorithm, > the integrity of the zone is never broken. > > ___ >

[DNSOP] question on nameserver management reqs draft

can envision a role that would need to view configuration options, but would not be allowed to modify, add or delete (e.g. some security auditor). Scott === Scott Rose NIST [EMAIL PROTECTED] ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec h

Re: [DNSOP] Proposed changes to RFC 4641: rollovers

Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ======= Scott

Re: [DNSOP] Proposed changes to RFC 4641: rollovers

ailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop === Scott Rose NIST [EMAIL PROTECTED] ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ === ___

Re: [DNSOP] dns data exchanged between host and local dns-sever

re >> someone having a certain solution, more exactly a software >> implementation on host, to protect against such attack? >> >> 2009-04-23 >> m...@cnnic.cn > > _______ > DNSOP mailing list > DNSOP@ietf.org >

Re: [DNSOP] dns data exchanged between host and local dns-sever

. Scott Stephane Bortzmeyer wrote: > On Thu, Apr 23, 2009 at 07:10:13AM -0400, > Scott Rose wrote > a message of 65 lines which said: > >> Those are the DNS protocol mechanisms in place. There is also lower >> level security technologies such as IPsec that could be used bet

Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance

, but they must have the zone signing bit set either way. Then have RFC 4641 as a ref. Although with RFC4641-bis being worked on, that may quickly become dated... Also, as Paul pointed out, it looks like Paul and I are one person with a long name. :) Scott -- ---

Re: [DNSOP] RFC4641bis Section 4.4.5 proposed new text

Antoin Verschuren wrote: > Hi All, > > I have drafted some new proposed text for section 4.4.5 of RFC4641bis. > I tried to bring some more structure to the section while maintaining most of > the text from the current iteration of the document. > It now clearly separates: > -Definition of terms >

Re: [DNSOP] WGLC: draft-ietf-dnsop-dnssec-dps-framework-04.txt

nk it's the best idea. Scott > Olafur > > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop === Scott Rose NIST sco

Re: [DNSOP] identitytheft.gov DNSSEC Issue

r those who can’t see pictures, it’s identitytheft.gov. Looks like it’s >> been this way for about a week. >> >> >> >> Todd Szymanski| Data Network Administration >> Sprint | Service Management > ===

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

> DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop === Scott Rose NIST scott.r...@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ === ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-rfc5933-bis-12

Reviewer: Scott Rose Review result: Ready with Nits This Internet-Draft assigns a code point to a cryptographic algorithm for use in DNSSEC and obsoletes a preceding algorithm. The DNS and DNSSEC protocols are not changed in any way and in that sense of review the I-D is Ready. The nits listed

[DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-bootstrapping-04

Reviewer: Scott Rose Review result: Ready with Issues Review of dnssec-bootstrapping The draft is likely OK to proceed as there are only a few nits that do not change the overall contents. I am confused about if it adds to methods in RFC 8078 or replaces methods in RFC 8078. 1. Abstract: The

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-dnssec-bootstrapping-08

Reviewer: Scott Rose Review result: Ready I believe the draft is ready, with a minor typo/nit that don't change the document: In Section 5.1 second paragraph has "Signaling Zone" while other instances are "signaling zone". Scott