headers
David Fort | 2 Apr 2004 15:37
Picon
Favicon

KROd 1.0rc2

The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the
second release candidate for KROd 1.0. KROd is a daemon that automate the
keyrollover in DNSSEC. KROd can also be used to "DNSSECify" normal DNS
zones. KROd is still an experimental product and as such shouldn't be used
in production environment.

More informations/downloads can be found here:
    http://idsa.irisa.fr/index.php?page=kro&lang=en

--

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
Rob Austein | 3 Apr 2004 01:20

Please advance draft-ietf-dnsop-ipv6-transport-guidelines-02.txt

David,

On behalf of the DNSOP WG, we'd like to request publication of
draft-ietf-dnsop-ipv6-transport-guidelines-02.txt as a BCP.

WG last call for this document completed in December with no expressed
opposition to progressing this document, and a number of WG
participants have expressed a belief that the subject discussed in
this document is fairly important to operational stability of the DNS
on a dual-protocol (IPv4 and IPv6) Internet.

--Rob and Dave
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
David Fort | 5 Apr 2004 18:23
Picon
Favicon

Re: KROd 1.0rc2

bmanning <at> vacation.karoshi.com wrote:

>On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote:
>  
>
>>KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be
>>    
>>
>  
>
[...]

>-rw-r--r--   1 4779     29016     176701 Feb 16 12:49 KROd-1.0rc1.tar.gz
>-rw-r-----   1 4779     29016     129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2
>226 Transfer complete.
>ftp> get KROd-1.0rc2.tar.bz2
>local: KROd-1.0rc2.tar.bz2 remote: KROd-1.0rc2.tar.bz2
>227 Entering Passive Mode (131,254,254,10,112,150)
>550 KROd-1.0rc2.tar.bz2: Permission denied.
>  
>
Corrected

--

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33

.
dnsop resources:_____________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
JINMEI Tatuya / 神明達哉 | 6 Apr 2004 16:49
Picon

Re: WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt

>>>>> On Tue, 06 Apr 2004 23:05:31 +0900, 
>>>>> JINMEI Tatuya <jinmei <at> isl.rdc.toshiba.co.jp> said:

> Editorial comments:

(Sorry, I missed one more comment in Appendix)

4. Appendix A. (Site-local Addressing Considerations for DNS)

(last paragraph)
   ... Note that the
   experience private addresses in IPv4 has shown that the root servers
   get loaded for requests for private address lookups in any.

s/experience private addresses/experience of private addresses/ ?

(if "experience private addresses" was really the phrase intended,
then "has shown" should be "have shown")

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei <at> isl.rdc.toshiba.co.jp
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
JINMEI Tatuya / 神明達哉 | 6 Apr 2004 16:05
Picon

Re: WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt

>>>>> On Thu, 25 Mar 2004 17:18:33 +0200 (EET), 
>>>>> Pekka Savola <pekkas <at> netcore.fi> said:

> For up-to-date copies, see:
> http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt
> http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html

I'm going to make comments on the 05pre revision to avoid making
duplicate comments.  (I still must admit I may not have been careful
about the last call thread and can make duplicates.  Please just
ignore duplicate ones if any).

Overall, I think this documetn is accurate and very useful.  Some
relatively minor comments below:

Substantial (or not-so-editorial) comments:

1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records)

   In particular one should note that the use of A6 records, DNAME
   records in the reverse tree, or Bitlabels in the reverse tree is not
   recommended [2].

I think this is an overstatement about DNAME.  The text looks meaning
DNAME is not recommended *in any way* in the IPv6 reverse tree.  For
example, people would read this to mean it is discouraged to use DNAME
to manage both ip6.arpa and ip6.int zones as described in
http://www.isc.org/pubs/tn/isc-tn-2002-1.html

But, in my understanding, the sense of the discussion in RFC3363 ([2])
(Continue reading)

Permalink | Reply | 42 comments |
headers
Gilles Guette | 7 Apr 2004 08:29
Picon
Favicon

draft-ietf-dnsop-key-rollover-requirements-00

Hello,

We have published work about the requirements for automated key rollover
in DNSSEC in the draft draft-guette-dnsop-key-rollover-requirements-00
during the 58th IETF meeting (november 2003, Minneapolis).

This draft has been adopted by the working group and has turned into
draft-ietf-dnsop-key-rollover-requirements-00.

It seems that this change hadn't been taken into account by the wg and 
Mohsen Souissi (AFNIC) pointed out this change at IETF Seoul dnsop session.

This draft presents the communication between parent and child zones
during an automated key rollover, the data exchanged and the security
services needed.

We (co-authors) would much appreciate your feedback and comments
on this draft.

Regards

--
Gilles Guette
Ph.D. Student
IRISA/INRIA France

Olivier Courtay
Research Engineer
IRISA France
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 7 Apr 2004 09:01
Picon

additional data [Re: WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt]

Note: I did not see a clear resolution to this thread, so I did not 
reflect it in the document.  However, I'd be glad to make some changes 
if there was agreement on the wording.  Please continue.. :)

However, I made a few more editorial fixups from you Peter to the 
section:
 - clarified the difference of glue/additional data
 - added clarification on TC use

The revised paragraph is below.

4.5  Behaviour of Glue in Mixed IPv4/IPv6 Environments

   In the previous section, we discussed the effect of impartial data
   returned from the caches when the TTLs are not kept the same.  Now,
   we present another problem highlighted in the mixed IPv4/IPv6
   environments.

   Consider the case where the query is so long or the number of the
   additional records (originated from "glue") is so high that the
   response must either be truncated (leading to a retry with TCP) or
   some of the additional data removed from the reply.  However, note
   that if too much additional information that is not strictly
   necessary would be added, one should remove unnecessary information
   instead of setting TC bit for this "courtesy" information [17].
   Further, resource record sets are never "broken up", so if a name has
   4 A records and 5 AAAA records, you can either return all 9, all 4 A
   records, all 5 AAAA records or nothing.

   In the case of too much additional data, it might be tempting to not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 7 Apr 2004 10:38
Picon

Re: WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt

Thanks a lot for good comments.  (I also took your additional 
message into account.)

I think this causes us to re-think the TTL/impartial additional-data
parts and how it's supposed to operate a bit -- so I'd welcome the 
others to look at this as well..

I've also updated the temporary copies at:

http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html
 (There is no diff between these two pre-versions though.)

Inline..

On Tue, 6 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B? <at> L <at> C#:H(B wrote:
> 
> 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records)
> 
>    In particular one should note that the use of A6 records, DNAME
>    records in the reverse tree, or Bitlabels in the reverse tree is not
>    recommended [2].
> 
> I think this is an overstatement about DNAME.  The text looks meaning
> DNAME is not recommended *in any way* in the IPv6 reverse tree.  For
> example, people would read this to mean it is discouraged to use DNAME
> to manage both ip6.arpa and ip6.int zones as described in
> http://www.isc.org/pubs/tn/isc-tn-2002-1.html
[...]
(Continue reading)

Permalink | Reply | 40 comments |
headers
Pekka Savola | 7 Apr 2004 11:49
Picon

DNAME and non-fragmented, non-A6 reverses [Re: WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt]

I'm particularly interested in hearing what kind of opinions the WG 
has on this particular problem..

On Wed, 7 Apr 2004, Mark Andrews wrote:
> > Substantial (or not-so-editorial) comments:
> > 
> > 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records)
> > 
> >    In particular one should note that the use of A6 records, DNAME
> >    records in the reverse tree, or Bitlabels in the reverse tree is not
> >    recommended [2].
> > 
> > I think this is an overstatement about DNAME.  The text looks meaning
> > DNAME is not recommended *in any way* in the IPv6 reverse tree.  For
> > example, people would read this to mean it is discouraged to use DNAME
> > to manage both ip6.arpa and ip6.int zones as described in
> > http://www.isc.org/pubs/tn/isc-tn-2002-1.html

Yes.

> > But, in my understanding, the sense of the discussion in RFC3363 ([2])
> > is that DNAME in the reverse tree is deprecated for the reverse side
> > of the A6 usage.  That is, the usage for constructing multi-level,
> > hierarchal reverse trees, particularly with bitstring labels.

Chaining was indeed one important argument in the discussions.  I do 
not remember them in detail to be able to comment whether it was 
intentional to deprecate DNAME for all reverse usage or just with A6.  
IMHO, the document language:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jim Reid | 7 Apr 2004 13:04

Re: DNAME and non-fragmented, non-A6 reverses [Re: WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt]

>>>>> "Masataka" == Masataka Ohta <mohta <at> necom830.hpcl.titech.ac.jp> writes:

    Masataka> I think DNAME and bit labels MUST be obsoleted for
    Masataka> obvious reasons that they are useless and harmful.

I strongly disgaree with both your statement and the justification for
it. Please demonstrate how DNAME and bit labels are "useless and
harmful". DNAME has applications outside the reverse resolution of
IPv6 addresses: for instance in migrating old-domain-name to
new-domain-name. Bit labels are awful and very hard to use or
understand, but that's not an excuse to kill them. [DNSSEC is also
awful and hard to use or understand but nobody seems to want to kill
that.] IMO the status quo for DNAME and bit labels is just fine. IIRC
bit labels are now considered EXPERIMENTAL and so far a compelling
case hasn't been made to change that status.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 1 comment |

Gmane