Subject: Re: [dnsop] paragraph 4.4.2 in dnssec-operational-practices-03

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 1 Apr 2005 08:49:53 +0200

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 1 Apr 2005 10:09:43 +0200

> 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.

> 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
still not be able to generate a DS set. These registrants will always
have access to the DNSKEY so I think it is fair to suggest to
registries to allow for the keys travel to the registries. (I could
see the registrars having a system where the DS set is generated for
the registrant through a web interface. That webinterface fetches the
DNSKEYs from the currently running zone. It selects the SEP keys,
allow the user to select one of those keys -- but has a sensible
default based on the currently configured DS RR -- and has a button to
select the hash. After the interaction with the custommer is finished
the EPP protocol takes over from there and signals the information to
the registry.)

Anyway, back to the matter at hand:

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 :-) .

Suggestions:

> 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.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Miek Gieben <[email-masked]>
Date: Fri, 1 Apr 2005 10:49:03 +0200

[On 01 Apr, @ 10:09, Olaf wrote in "Re: [dnsop] paragraph 4.4.2 in ..."]
> >   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:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 1 Apr 2005 11:29:31 +0200

Olaf,

> 4.4.2  Storing Keys or Hashes?

Much better.

> that is published in the DNS; NS and DS RRs.

Fine for me!

Best regards,
Marcos
.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 1 Apr 2005 07:19:37 -0500

> 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-

.

---

From: jing shen <[email-masked]>
Date: Mon, 4 Apr 2005 18:52:39 +0800

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

.