Subject: [weirds] DNSSEC

From: Ernie Dainow <[email-masked]>
Date: Wed, 8 May 2013 14:43:10 -0400

It was not easy to find the RDAP support for DNSSEC. A search for "DNSSEC"
in draft-ietf-weirds-json-response-03 does not find anything. Adding a
background note in 6.3 delegationKeys that this is for DNSSEC might help.
Also as noted for another document, references should be expanded to
include the RFC title. Instead of RFC 4034 [RFC4034], "Resource Records for
the DNS Security Extensions" [RFC4034].

It would be useful to have the following additional information:
1) Create Date - include an Events array
2) Max Signature Life -  validity period for the signature in seconds

You can't verify the digest in delegationKeys without the following:
3) Flags - identifies whether it is a zone key
4) Protocol - key protocol, currently must be 3
5) Public Key - required to decrypt DS records

While many providers may not have all of these, it is better for the
standard to specify them rather than ending up with various custom
extensions.

-Ernie

---

From: Arturo Servin <[email-masked]>
Date: Wed, 08 May 2013 15:44:03 -0500

Question, do we really want to publish all that information in RDAP?

	I do not have strong opinions, just query the group.

regards,
as

On 5/8/13 1:43 PM, Ernie Dainow wrote:
> It was not easy to find the RDAP support for DNSSEC. A search for
> "DNSSEC" in draft-ietf-weirds-json-response-03 does not find anything.
> Adding a background note in 6.3 delegationKeys that this is for DNSSEC
> might help. Also as noted for another document, references should be
> expanded to include the RFC title. Instead of RFC 4034 [RFC4034],
> "Resource Records for the DNS Security Extensions" [RFC4034].
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: "Carlos M. martinez" <[email-masked]>
Date: Wed, 08 May 2013 16:11:53 -0500

I'm basically fine with it.

However, I'm a bit worried that, given enough time, every different
stakeholder will find some attribute he/she might want to add.

I think we need to define how we are going extend rdap-response without
keeping it as a draft until the heat death of the Universe.

regards,

~Carlos

---

From: Andy Newton <[email-masked]>
Date: Thu, 9 May 2013 14:14:56 +0000

>I'm basically fine with it.

Ditto.

>keeping it as a draft until the heat death of the Universe.

Are you speaking of something other than the current ability to add
registry specific JSON attributes?

-andy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 May 2013 10:42:49 -0400

I'm pretty much a lazy lurker, but this subject caught my eye.

My opinion is against having the DNSSEC meta-data in "the WhoIs" (and by that I mean any form of Registry database content inspection mechanism).  Not strongly against as in I think it is wrong, but in the sense that you can get this data from "port 53" anyway.

The DNS is inherently a history-free protocol, so I question the value of knowing when a record appeared in the DNS when solving operational problems.  I do have a research project that does track DNSSEC record lifetimes, but that is research, not operations.  I do the work by remembering what I've seen in DNS responses over time.

I realize that today some registries do publish DNSSEC meta-data in port 43 WhoIs and some do not.  I think path a registry chooses ultimately doesn't matter - in the sense that I wouldn't tell anyone doing it that they shouldn't, even if I wouldn't add the information.  In that sense, if it is in RDAP, fine, make it optional and yes, one form for this is better than 12 (in the sense that it's one aspect).  But I would not have designed in to the response the DNSSEC meta-data.

Scratching the back of my head, I can't think of any reason why I'd ask "the WhoIs" for the DNSSEC meta-data for a domain object.  If I can't get it from the DNS itself, the DNSSEC stuff isn't going to help me in any way.  Even thinking for historical or escrow purposes, the DNS zone file is already an adequate vehicle for the DNSSEC meta-data.

>> standard to specify them rather than ending up with various custom

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: "John Levine" <[email-masked]>
Date: 9 May 2013 15:39:27 -0000

>I realize that today some registries do publish DNSSEC meta-data in port 43 WhoIs
>and some do not.

This seems like a bad idea.  If the results from port 43 and port 53 disagree,
who do you believe?

On the other hand, everyone's whois publishes the nameservers, same issue.

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 9 May 2013 12:57:08 -0300

Ed,

> My opinion is against having the DNSSEC meta-data in "the WhoIs" (and by that I mean any form of Registry database content inspection mechanism).  Not strongly against as in I think it is wrong, bu…

So why publish the NS set?  We've being arguing over the DS/KEY
publishing since crisp DREG2.

Some of us still think this is the only public OOB way of the DNS
publication of verifying the content of the registry. I do know that
some registries don't keep in-sync rdap but some does and this has
value. As almost all information on rdap is optional I would like to
keep this on the base spec. The ones that don't think this way have
the ability to simply omit this information.

Fred

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 May 2013 12:17:34 -0400

The value in the NS list...is that it contributes to reachability, albeit in oddball cases. (*)

Back in the days before ip6.int was erased from the DNS, there was a situation where all of the servers for ip6.int also hosted all of the children of ip6.int.  The reason I was debugging this was that I had a copy of ip6.int on a server I managed and none of the NS list matched the set of servers that held the data.  Because of the set up, no matter how anyone without administrative access tried to get the data in ip6.int, they could not get the NS set for the children of Ip6.int.

Any query that went to the ip6.int server would be responded to from the child zone, with the authoritative list and not the "glue" list registered with ip6.int.

The situation that caused this was one I'll tell you over beer sometime.

Oddly, it wasn't an operation issue because every query was answered.  The trouble was trying to move the server offering the slave service.  Had there been an ip6.int whois, I could have seen easily the what was supposed to be the "glue" set.

We don't have this problem with DNSSEC.  Do you recall "roll over and die?" (http://www.potaroo.net/ispcol/2010-02/rollover.html)  The root cause was that the "strategy for panicking" when you couldn't find a working NS did not translate to when you could not find a working DS/DNSKEY.  Although NS and DS are very analogous (delegation of name space versus delegation of security space), they are not completely the same.

Underscore this with - I don't see any "sin against humanity" in putting DNSSEC information into "the WhoIs", but I have my reasons why I wouldn't.

(*) In normal situations, there's not reason I consult the NS list in "the Whois."  I guess there are times when the authoritative list I get is a subset of the "glue version" and if this is due to an active persistent threat, having the NS in "the WhoIs" (which today is unprotected, so ...) is a good second path.  But once I can reach the NS that is listed, I can get everything else from there.  'Course, if the APT is hitting the routing substrate, all bets are off...even getting to "the WhoIs."

I suppose we ought to think of benign and malicious meltdowns, systemic and random no longer apply. ;)

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 09 May 2013 18:28:45 +0200

Ed,
    
    On Thu, May 09, 2013 at 10:42:49AM -0400, Edward Lewis wrote:
    > My opinion is against having the DNSSEC meta-data in "the WhoIs" (and bythat I mean any form of Registry database content inspection mechanism).  Not strongly against as in I think it is wrong, but in the sense that you can get this data from "port 53" anyway.
    > 

The NS in whois is the set the registry (Parent) has in their
database but the authoritative data is in the child. Their might
be differences between parent and child.

	jaap

---

From: "Carlos M. martinez" <[email-masked]>
Date: Thu, 09 May 2013 12:09:41 -0500

Hey,

> registry specific JSON attributes?

Well, maybe yes. The way I read the original post, I understood the
intent was to add attributes X or Y to the base spec.

While I agree that having the ability to extend the protocol in
registry-specific ways is all important, there may be cases where
someone will think that adding an attribute to the base spec is needed.

I'm not saying that DNSSEC is the case though, the more I think about it
I rather believe it should be a registry-specific thing.

regards

~Carlos

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 9 May 2013 10:56:58 -0700

The main question is whether we are proposing a data format with transport, or the specification for a service.

Some of this things will be mandatory by groups outside of the IETF, such as ICANN, and registry policy. Unfortunately not every single use case will fall under the same umbrella, and the fact that the protocol does not require any specific fields, generate a problem and a grey area with regards to functionality.

francisco

> I rather believe it should be a registry-specific thing.

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 14 May 2013 13:51:25 -0300

Francisco/All,

<change of mind warning>

I rather now believe this requirement would be better served by a
registry-specific extension.

However, in order to avoid the silly situation where every registry
requiring DNSSEC info for their RDAP output names the fields
differently, maybe a short I-D describing the names of the fields would
be useful.

If ICANN makes the use of these extensions a requirement, well, having a
uniform naming and field semantics would definitely help and can even be
referenced by ICANN.

However, as not everyone will need to implement it (for example, us in
the 'numbers' field are not very likely to use it), IMO, the correct
place for it is in a 'standardized extension field' set, if you catch my
drift :D

</change of mind warning>

cheers!

~C.

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 14 May 2013 09:58:37 -0700

We can do an extension,

However,

I do believe that Number registries will make use of this too, since you do manage "in-addr" zones, and people do use DNSSEC on them as well.

So is the rule of thumb is that everything that number registries are going to use go into the draft and the rest extensions?

Because if that's not it, we should probably then make clear distinctions of the content vs transport by presenting more 'response' documents and not attempting to have one type fits all type of solution.

Francisco

Francisco Obispo

---

From: Andy Newton <[email-masked]>
Date: Tue, 14 May 2013 17:08:56 +0000

>place for it is in a 'standardized extension field' set, if you catch my

There are a good number of parts in the current spec that number
registries will use which domain registries will not use. So I don't see
the logic here.

I think it is perfectly fine to try to define those JSON values now and
get it in the current spec. This is not an unknown area, and so should be
easy to accomplish. A standard extension would just result in all clients
trying to support it anyway.

Does anyone want to take a stab at the JSON for this?

-andy

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 15 May 2013 19:04:53 +0800

> However, in order to avoid the silly situation where every registry
requiring
> DNSSEC info for their RDAP output names the fields differently, maybe a
short
> I-D describing the names of the fields would be useful.
> 

I think this changed mind is better :)
I have a question that whether we would define the standardized extension in
the same response draft or a new I-D? Shall we first think about what are
the standardized extension for RDAP?

> However, as not everyone will need to implement it (for example, us in the
> 'numbers' field are not very likely to use it), IMO, the correct place for
it is in a
> 'standardized extension field' set, if you catch my drift :D
>

---

From: Ernie Dainow <[email-masked]>
Date: Mon, 27 May 2013 12:14:23 -0400

> Does anyone want to take a stab at the JSON for this?

Here is a draft for a DNSSEC section in draft-ietf-weirds-json-response.

This is based on what is in RFC5910, "Domain Name System (DNS) Security 
Extensions Mapping for the Extensible Provisioning Protocol (EPP)" and 
the following Whois requirement in ICANN's New gTLD Agreement, Sec 1.5 
http://newgtlds.icann.org/en/applicants/agb/base-agreement-specs-29apr13-en.pdf
   DNSSEC: signedDelegation
   DNSSEC: unsigned
__________________________________________________

DNS Security Extensions (DNSSEC)

DNSSEC provides data integrity for DNS through digital signing of 
resource records. To enable DNSSEC, the zone is signed by one or more 
private keys and the signatures stored as RRSIG records. To complete the 
chain of trust in the DNS zone hierarchy, a digest of each DNSKEY record 
(which contains the public key) must be loaded into the parent zone, 
stored as Delegation Signer (DS) records and signed by the parent's 
private key (RRSIG DS record), "Resource Records for the DNS Security 
Extensions" [RFC4034]. Creating the DS records in the parent zone can be 
done by the registration authority, "Domain Name System (DNS) Security 
Extensions Mapping for the Extensible Provisioning Protocol (EPP)" 
[RFC5910].

Only DS related information is provided by RDAP, since other information 
is not generally stored in the registration database. Other DNSSEC 
related information can be retrieved with other DNS tools such as dig.

The following is the "DS Data Interface" [RFC5910], where the 
registration data provides the information for one or more DS records.

"secDNS":
[
   "zoneSigned": true,
   "delegationSigned": true,
   "maxSigLife:" 604800,
   {
     "dsData":
     [
       {
         "keyTag": 12345,
         "algorithm": 3,
         "digestType": 1,
         "digest:": "49FD46E6C4B45C55D4AC",
         "events":
         [
           {
           "eventAction": "registration",
           "eventDate": "2011-07-26T16:25:08Z"
           }
         ]
       },
       ...
     ]
   }
]

The following is the "Key Data Interface" [RFC5910], where the 
registration data provides the actual key data from one or more DNSKEY 
records that are used to create the DS records.

"secDNS":
[
   "zoneSigned": true,
   "delegationSigned": true,
   "maxSigLife:" 604800,
   {
     "keyData":
     [
       {
         "flags": 257,
         "protocol": 3,
         "algorithm": 1,
         "publicKey": "AQPJ////4Q==",
         "events":
         [
           {
             "eventAction": "last changed",
             "eventDate": "2012-07-23T05:15:47Z"
           }
         ]
       },
       ...
     ]
   }
]

*  zoneSigned -- boolean true if the zone has been signed, false otherwise.
*  delegationSigned -- boolean true if there are DS records in the 
parent, false otherwise.
*  maxSigLife -- signature life time in seconds to be used when creating 
the RRSIG DS record in the parent zone [RFC5910].
*  keyTag -- an integer as specified by the key tag field of the DS 
record [RFC5910].
*  algorithm -- a DNSSEC algorithm type as specified in "DNS Security 
(DNSSEC) Algorithm Numbers" [IANA]
*  digestType -- an integer as specified by the digest type field of the 
DS record [RFC5910].
*  digest -- a hex-encoded binary string of the digest field of the DS 
record [RFC5910].
*  events -- see Section 5.5
*  flags -- the flags field value in the DNSKEY record [RFC5910].
*  protocol -- the protocol field value in the DNSKEY record [RFC5910].
*  publicKey -- the base64Binary encoded string of the public key in the 
DNSKEY record [RFC5910].
________________________________________________

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Mon, 27 May 2013 22:43:22 +0000

Terrific work, Ernie! I have two comments inline...

>Extensions Mapping for the Extensible Provisioning Protocol (EPP)"

That last sentence the reference to EPP is unnecessary and a little
misleading. Not all domains are maintained with EPP. For example, we put
DS records in the reverse but do not have an EPP interface.

>*  events -- see Section 5.5

Why is it necessary to have a separate events structure for the DNSSEC
data. Isn't 'secDNS' suppose to be part of the domain object class?

>*  publicKey -- the base64Binary encoded string of the public key in the

Again, excellent work. Thank you very much!

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 28 May 2013 11:56:53 -0400

Some replies to comments below ...

> DS records in the reverse but do not have an EPP interface.

I think the reference is important for DNRs as it provides the rationale 
for the small subset of DNSSEC information that is provided by RDAP. The 
structures defined here match what is in RFC5910. Can you add a sentence 
and reference if appropriate for RIRs?

> data. Isn't 'secDNS' suppose to be part of the domain object class?

Each key may be added or changed at different times (Sec 5.2.5 in 
RFC5910), so events are shown as a sub element of each key. As 
elsewhere, event information is optional. A provider could decide that 
the Domain event information was sufficient and not report detailed 
timestamps for DNSSEC data.

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Wed, 29 May 2013 14:47:14 +0000

>and reference if appropriate for RIRs?

Ok. I think we're fine so long as this is an informative reference.

>timestamps for DNSSEC data.

My concern is the consistency of the data model. We don't break out events
for other sub structures, such as remarks or status.

While the complexity is not great for the server implementation, it is
more complex for a general purpose client. I happen to be writing a
general purpose RDAP client and I don't see the utility in this but I do
see the complexity in conveying the information.

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 29 May 2013 14:01:06 -0400

> see the complexity in conveying the information.

I think the more important question is what is the value of this 
additional information to people using RDAP. I don't think timestamps of 
key creation are publicly available with other DNS tools. Would this be 
useful when investigating DNSSEC problems or discrepancies? Perhaps 
people with operational experience with DNSSEC could comment.

We currently do report this information in Whois for some TLDs:
$ whois pir.org
...
DNSSEC:Signed
DS Created 1:26-Mar-2010 16:52:50 UTC
DS Key Tag 1:54135
Algorithm 1:5
Digest Type 1:1
Digest 1:225F055ACB65C8B60AD18B3640062E8C23A5FD89
DS Maximum Signature Life 1:1814400 seconds

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Thu, 30 May 2013 11:05:53 +0000

>DS Maximum Signature Life 1:1814400 seconds

This trumps my argument about a pretty data model. :)

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 30 May 2013 15:52:18 -0400

A few syntax corrections for : inside the "

"secDNS":
[
   "zoneSigned": true,
   "delegationSigned": true,
   "maxSigLife": 604800,
   {
     "dsData":
     [
       {
         "keyTag": 12345,
         "algorithm": 3,
         "digestType": 1,
         "digest": "49FD46E6C4B45C55D4AC",
         "events":
         [
           {
           "eventAction": "registration",
           "eventDate": "2011-07-26T16:25:08Z"
           }
         ]
       },
       ...
     ]
   }
]

"secDNS":
[
   "zoneSigned": true,
   "maxSigLife": 604800,

-Ernie