Re: RRTYPE love, was Re: [dnsext] RRTYPE request: template for ZS record

>I guess the IETF does not want to support standards that it does not
>consider "good". However, in the past this has led to people simply
>ignoring the IETF and doing things their own way, in an undocumented and
>non-interoperable way. Why yes, I *am* thinking of NAT and Skype and P2P
>and SPF and plenty of other things I use daily...
>
>IIRC, the SPF folks put records into TXT records because they had no
>other way to do it. In the midst of the nuclear-hot flames that were
>directed their way when they entered the IETF arena were complaints that
>they were putting structured data into an unstructured field. So, now we
>have the SPF record. (I may not be remembering this perfectly, so
>someone involved with the effort feel free to correct me.)
>
>Based on that history, I think Jim is Doing the Right Thing by trying to
>get the NINFO RR assigned.
>
>
>Regarding whether or not we want DNS to allow "gunk" or "clutter", I
>have to admit I don't share the DNS religion about wanting to keep stuff
>*out* of the DNS. I think there are huge classes of problems that share
>similar properties to things that do work well with DNS-style lookups,
>and given that DNS is arguably the most successful distributed database
>it makes sense that these will appear.

I am generally in favor of getting folks to register new RRs, rather than
simply re-using TXT.  The problem here is that this RR doesn't
actually create an RRTYPE that can be re-used successfully within
the distributed database system you so feelingly describe above.  It has
no structure whatever and it will evidently vary in what sort of content it
contains, potentially from node to node (and realistically from zone to zone).

[dnsext] DNS RR (RFC 4701) impacts from draft-arkko-arp-iana-rules

Folks,

I recently wrote a draft about the IANA rules regarding ARP, as no such
rules were defined before.

During last call, it became apparent that there are a few other
protocols that use the same numbers. For instance, specialized forms of
ARP for certain link layers or DHCPv4/6. Having realized this, we did a
more thorough search of the RFC series to attempt to find all such uses.
The new version of my draft lists all these uses and updates the RFCs in
question.

I would like to ask for your review to make sure (a) that the ARP rule
change is OK from the perspective of your protocol and (b) we have found
all uses of the ARP numbers. Here's what the draft says:

"The change is also applicable to extensions of ARP that use the same
message format, such as [RFC0903], [RFC1931], and [RFC2390].

The change also affects other protocols that employ values from the ARP
name spaces.  For instance, the ARP hardware address type (ar$hrd)
number space is also used in the "htype" (hardware address type) fields
in Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration
Protocol (DHCP) [RFC2131], as well as in the "hardware type" field in
the DHCP Unique Identifiers in DHCPv6 [RFC3315]. These protocols are
therefore affected by the update in the IANA rules.  Other affected
specifications include the specialized address resolution mechanisms in
HYPERchannel [RFC1044], DHCP options [RFC2132], [RFC4361], ATM
(Asynchronous Transfer Mode) ARP [RFC2225], HARP (High-Performance

[dnsext] RRTYPE request for NINFO

In some off-line discussions with Jim, I noted that I do believe
that the primary purpose of registration in this space is to avoid
code point collision.  Based on that criterion, the request for NINFO
should probably go forward; it is clear that .tel plans to deploy this
RRType and allocating a code point to distinguish their use from
what would happen with a simple grab has value for the community.

I have asked Jim to consider some changes to his registration
which would, I believe, help establish at least the charset of the
text and potentially the media type of the NINFO (e.g. distinguishing
html-formatted text from plain text).  Those changes would, in my
opinion, make this more useful to a broader range of folks, but they
don't change the value of avoiding collision.

			regards,
				Ted Hardie

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Re: [dnsext] DNS RR (RFC 4701) impacts from draft-arkko-arp-iana-rules

At Mon, 01 Dec 2008 23:31:38 +0200 , Jari Arkko wrote:

> Folks,
>
> I recently wrote a draft about the IANA rules regarding ARP, as no
> such rules were defined before.
>
> During last call, it became apparent that there are a few other
> protocols that use the same numbers. For instance, specialized
> forms of ARP for certain link layers or DHCPv4/6. Having realized
> this, we did a more thorough search of the RFC series to attempt
> to find all such uses. The new version of my draft lists all these
> uses and updates the RFCs in question.
>
> I would like to ask for your review to make sure
> (a) that the ARP rule change is OK from the perspective of your
>     protocol and
> (b) we have found all uses of the ARP numbers.
>
> Here's what the draft says:
>
> "...
>                                         [...]. These protocols are
> therefore affected by the update in the IANA rules.  Other affected
> specifications include ...
> ...
>                                                  , and DNS Resource
> Records [RFC4701]."

As one of the culprits for the broadening of scope for

Re: [dnsext] RRTYPE request for NINFO

--On 2 December 2008 09:52:18 -0800 Ted Hardie <hardie <at> qualcomm.com> wrote:

> In some off-line discussions with Jim, I noted that I do believe
> that the primary purpose of registration in this space is to avoid
> code point collision.

Without prejudice to the particular application in question, would
it make sense to have a means of assigning private RRTYPEs
even if we limited the RRTYPEs to ones whose records "looked just
like TXT RRs"?

Alex

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Re: [dnsext] DNS RR (RFC 4701) impacts from draft-arkko-arp-iana-rules

Alfred,

> IMO, listing RFC 4701 as a Normative Reference and even in the
> metadata as being "Updated" is a bit of overstressing.
>   

Perhaps. I struggled with the question of what to do for these cases. 
But for the record, here's the rationale that I used. I wanted to make 
sure that whoever used protocol X would easily find what the IANA rules 
are for that protocol. The updates relationship helps at least me in 
searching such things.

Also, if we had a standalone protocol RFC that had originally been 
published without IANA rules, when a new RFC defines these rules I would 
probably use the update relationship to note this.

However, I do not want to claim that this is the only possible way of 
doing it -- simply noting that the protocols are affected and listing 
the references in the informative references section would also be fine. 
I also note that IETF's practices for IANA guideline documents have been 
varied: some have become PS RFCs, some BCPs, sometimes there is an 
Update and sometimes there isn't.

There are also differences between the RFCs that my draft updates. For 
instance, the RFC 4701 speaks about values defined by DHCP and refers to 
RFC 2131, so you could argue that the necessary reference is already in 
place. RFC 2131 on the other hand does not even refer to RFC 826 and 
speaks only of the "ARP section in the Assigned Numbers RFC".

>           ...,  and DNS Resource Records [RFC4701].

[dnsext] Minutes from IETF73 uploaded

Dear colleagues,

Draft minutes from our meeting in Minneapolis are now available from
http://www.ietf.org/proceedings/08nov/minutes/dnsext.txt.  If you have
additions or corrections, please let the Chairs know as soon as
possible.  We're <dnsext-chairs <at> tools.ietf.org>.  Thanks.

Best regards,

Andrew (for the Chairs)

--

-- 
Andrew Sullivan
ajs <at> shinkuro.com
Shinkuro, Inc.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

I-D Action:draft-ietf-dnsext-dnssec-rsasha256-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
	Author(s)       : J. Jansen
	Filename        : draft-ietf-dnsext-dnssec-rsasha256-07.txt
	Pages           : 9
	Date            : 2008-12-03

This document describes how to produce RSA/SHA-256 and RSA/SHA-512
DNSKEY and RRSIG resource records for use in the Domain Name System
Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html

Re: [dnsext] RRTYPE request for NINFO

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

This request fully satisfies the criteria we agreed on in (the shiny 
new) RFC5395 section 3.1.2 and, accordingly, should be granted.

That said, using unstructured text is ill-advised, and I hope Jim 
resubmits the request, adding meta-data for character set at the very 
least.

I also encourage not using "zone" in the name or mnemonic of the RR -- 
it appears that this RR is more tied to domains than zones, and it 
would be better to avoid the confusion.

-- Sam

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Re: [dnsext] RRTYPE request: template for proposed RKEY RRtype

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

First, I think this template is adequate for the purpose of an RFC5395 
assignment.

That said, the idea as presented seems very flawed.

Without addressing the merits of providing confidentiality for DNS 
data: why use public key cryptography here at all?  It seems that 
symmetric cryptography with shared keys more closely matches the need. 
Thierry makes a good point in that the DNSSEC algorithms are for 
signatures.  It happens that some can also be used for encryption, but 
that's not generally the case, and reusing the registry is of dubious 
value.

>> If clients retrieve keys to *decode* encrypted data from the public DNS, 
>> then what prevents unauthorized parties from doing the same?
>
> Because only authorised clients will have the corresponding private key(s). 
> Since there may be many keys in use an RKEY RRtype tells the client which (if 
> any) of the private keys it holds can be used to do the decoding.

The draft isn't clear that the primary point of publishing the keys is 
to allow identification of which non-published keys should be used to 
decrypt the content -- that could be clarified.  As it is, I see much 
confusion arising.