headers
Marcos Sanz/Denic | 1 Apr 2005 08:49
Picon
Favicon

Re: paragraph 4.4.2 in dnssec-operational-practices-03

Miek,

> Sam argues:
> Section 4.4.2 suggests storing DNSKEYs, not DSs.  I think this is bad
> advice -- DS message digest algorithms may be used for signaling (of,
> for example, use of NSEC3), so the child may want to choose the
> message digest algorithm.  Rather than require the parent to
> support them all, why not just let the child provide the hash?
>
> I argue:
> My opinion in this is that the DS is a parental record and as such a 
child may
> not even be aware that it exists.

This reminds me of the discussion had not a long time ago about the 
epp-dnssec documents. There, we achieved consensus about the child 
providing the DS record to the parent and *optionally* key information 
(and so reflects it epp-secdns-07). IMHO operational practices should be 
coherent with that (well, or the other way round).

Regards,
Marcos
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 5 comments |
headers
Olaf M. Kolkman | 1 Apr 2005 10:09
Picon
Favicon

Re: paragraph 4.4.2 in dnssec-operational-practices-03


Sam writes:

 > Section 4.4.2 suggests storing DNSKEYs, not DSs.  I think this is bad
 > advice -- DS message digest algorithms may be used for signaling (of,
 > for example, use of NSEC3), so the child may want to choose the
 > message digest algorithm.  Rather than require the parent to
 > support them all, why not just let the child provide the hash?

The text sais: Should considder if DNSKEY and/or DS are stored. It
gives a few argument for storing the DNSKEY and generating the DS. It
does not give arguments agains storing the DS.

I find it difficult to use your argument "DS message digest algorithms
may be used for signaling (of, for example, use of NSEC3)". This
signalling mechanism only exists on the drawing board and the draft
really describes the initial (testbed and workshop) experiences.

Marcos Sanz wrote:

> This reminds me of the discussion had not a long time ago about the 
> epp-dnssec documents. There, we achieved consensus about the child 
> providing the DS record to the parent and *optionally* key information 
> (and so reflects it epp-secdns-07). IMHO operational practices should be 
> coherent with that (well, or the other way round).

But that disscussion specifically pertained to the EPP protocol, which
is only used in a subset of the DNS operations. AFAIU EPP is mostly
used between registries and registrars. Although one of the signing
implementation will courteously spit out a DSset, the registrants may
(Continue reading)

Permalink | Reply | 4 comments |
headers
Miek Gieben | 1 Apr 2005 10:49

Re: paragraph 4.4.2 in dnssec-operational-practices-03

[On 01 Apr,  <at>  10:09, Olaf wrote in "Re: [dnsop] paragraph 4.4.2 in ..."]
> > 4.4.2  Storing Keys So Hashes Can Be Regenerated
> 
> Change of title:
>   4.4.2  Storing Keys or Hashes?
> 
> >   When designing a registry system one should consider if the DNSKEYs
> >   and/or the corresponding DSs are stored.  Storing DNSKEYs will help
> >   during troubleshooting while the overhead of calculating DS records
> >   from them is minimal.
> 
> Insert:
>     On the other hand registries may be hesitant to generate data for
>     custommers. That could be a reason to only accept what the data
>     that is published in the DNS; NS and DS RRs.
> 
> 
> >   Having an out-of-band mechanism, such as a Whois database, to find
> >   out which keys are used to generate DS Resource Records for specific
> >   owners and/or zones may also help with troubleshooting.

I, for one, have no trouble with this change,

--
grtz,
  - Miek

http://www.miek.nl                   http://www.nlnetlabs.nl
.
dnsop resources:_____________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Sanz/Denic | 1 Apr 2005 11:29
Picon
Favicon

Re: paragraph 4.4.2 in dnssec-operational-practices-03

Olaf,

> Suggestions:
> 
> > 4.4.2  Storing Keys So Hashes Can Be Regenerated
>
> Change of title:
> 4.4.2  Storing Keys or Hashes?

Much better.

> >   When designing a registry system one should consider if the DNSKEYs
> >   and/or the corresponding DSs are stored.  Storing DNSKEYs will help
> >   during troubleshooting while the overhead of calculating DS records
> >   from them is minimal.
>
> Insert:
> On the other hand registries may be hesitant to generate data for
> custommers. That could be a reason to only accept what the data
> that is published in the DNS; NS and DS RRs.

Fine for me!

Best regards,
Marcos
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Hollenbeck | 1 Apr 2005 14:19

RE: paragraph 4.4.2 in dnssec-operational-practices-03

> I'd be happy to extend paragraph 4.4.2 with the arguments from the EPP
> discussion to only store the DS RRs (I am hesitant to refer to the EPP
> document because that will keep the document waiting for the reference
> to become stable, besides I could not find the argumentation for the
> choice in the epp-secdns document itself -- I may have overlooked it)
> Below is a suggestion. Somebody who was really deeply involved in EPP
> may recall stronger, or even the real, argument :-) .

Olaf, I asked the IESG to review my document yesterday.  It's finished
(barring last call and IESG review issues) as far as I'm concerned.

The rationale is described in the archives of this mailing list.  However,
it's probably better that the material be included in your document since
yours is specifically focused on operational practices.

-Scott-

.
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
Samuel Weiler | 1 Apr 2005 20:24

Re: paragraph 4.4.2 in dnssec-operational-practices-03

How about something with a little more explanation and a slightly
stronger suggestion?

   When designing a registry system one should consider which of the
   DNSKEYs and/or the corresponding DSs to store [or accept from
   registrants?].  Since a child zone might wish to have a DS
   published using a message digest algorithm not yet understood by
   the registry, the registry can't count on being able to generate
   the DS record from a raw DNSKEY.  Thus, we recommend that registry
   system at least support storing [accepting] DS records.

   It may also be useful to store [accept] DNSKEYs, since having them
   may help during troubleshooting and, so long as the child's chosen
   message digest is supported, the overhead of generating DS records
   from them is minimal.  Having an out-of-band mechanism, such as a
   Whois database, to find out which keys are used to generate DS
   Resource Records for specific owners and/or zones may also help
   with troubleshooting.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 752 comments |
headers
David Meyer | 1 Apr 2005 22:23

WGLC for draft-ietf-dnsop-serverid-04.txt


	Folks

	This note starts the WG Last Call for comments on
	draft-ietf-dnsop-serverid-04.txt, "Identifying an
	Authoritative Name Server". It can be found on   
	
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-serverid-04.txt

	Please review the document carefully, and send your
	feedback to the list.  Please also indicate whether or
	not you believe that this document is ready to go to the
	IESG. 

	This Last Call will end on 15 Apr 2005 at 1400 PST (UTC/GMT-8).

	Thanks,

	Dave & Rob
Permalink | Reply | 3 comments |
headers
jing shen | 4 Apr 2005 12:52

Performance measurement data for queryperf

Hi,

I've set up a server group with anycast structure. Now, I want to
measure its performance by using queryperf(Nominum's version).
 I've got some log from my currernt servers, but I met problem with
 converting log file to queryperf input file.

 The record in log file looks like:

 Feb 11 20:38:12.143 queries: info: client 218.72.102.64#1098: query: www.pywg.3322.org IN A

 I use  "perl -n -e 'print "$1 $2 \n" if /query: ([^]+) IN ([A-Z]+)/'
 1.txt" to generate queryperf input file, but it only generate record
 with domain name, no record type is filtered in. Is there any problem
 with my regular expression?

 Secondly, is there any standard query data for server performance
 test?  Is there any tools to collect incoming query data and CPU,
 memory utilization with very short period? ( I tried top for that,
 but it only shows one CPU information while my server has two CPU
 installed)

 thanks

 Joe

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miek Gieben | 5 Apr 2005 10:53

Re: paragraph 4.4.2 in dnssec-operational-practices-03

[On 01 Apr,  <at>  20:24, Samuel wrote in "Re: [dnsop] paragraph 4.4.2 in ..."]
> How about something with a little more explanation and a slightly
> stronger suggestion?

to come back to this. I'd like Olaf's suggestion more, basicly because
it's just one extra (short) paragraph,

--
grtz,
  - Miek

http://www.miek.nl                   http://www.nlnetlabs.nl
.
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
Miek Gieben | 5 Apr 2005 11:42

draft serverid-04

Hello,

Just finished reading serverid-04.txt and I consider it a good
document. But one nagging question remains, as it does not specify
a new mechanism, but only lays down the requirements. Are there any
plans to create a followup draft which actually specifies a new
mechanism? 

--
grtz,
  - Miek

http://www.miek.nl                   http://www.nlnetlabs.nl
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 14 comments |

Gmane