headers
Olaf Kolkman | 1 Nov 2006 08:35
Picon
Favicon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward Lewis | 1 Nov 2006 16:53
Favicon

Re: NSEC3 Issue 27: creating a flag octet.

At 10:14 AM -0400 10/19/06, David Blacka wrote:

>not be the default position.  A more reasonable default position would
>be the original proposal: one flag octet, 2 iterations octets. Or even
>the alternate original proposal: one flag octet, 3 iterations octets.

Why not 2 flag octets and and 2 iterations octets?

As in - if the current iterations is 4 octets and you want to carve 
out a flag octet, meaning that you have 4 octets to play with - I 
would think a three-octet field would be quite odd and confusing. 
Even if you don't need 16 flags, why not do that just to preserve 
alignment to 16 and 32 bit boundaries?

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

--
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/>
Permalink | Reply | 0 comments |
headers
Edward Lewis | 1 Nov 2006 17:30
Favicon

Re: NSEC3 and dynamic update issues.

At 9:35 AM -0500 10/30/06, Ólafur Guðmundsson /DNSEXT co-chair wrote:

Okay, I'll bite...

>#5 This is per se is NOT a NSEC3 issue BUT a dynamic update issue.
>    Some of the issues above apply to any DNSSEC signed zone
>    when signing keys are changed.

Perhaps this is true.  Then my consternation is 
focused on dynamic update's inadequacies or 
perhaps on that the implications of dynamic 
update haven't been fully addressed.

>Recommendation:
>The sense-of-the-room at the workshop was that dynamic update of
>the NSEC3PARAM RR should be discouraged.

From this summary, I'm not convinced that 
NSEC3PARAM shouldn't be dynamically updated. 
Assuming that only after seeing an updated 
NSEC3PARAM will an authoritative server generate 
all of the new NSEC3 records, sure.  But what is 
lost on me is why a slaving server can not be 
pre-fed the records before the NSEC3PARAM 
"switches" them on?

>The sense-of-the-room was that this issue could be overcome with
>careful engineering. It is important that the dynamic update client and
>server know each others expectations and policies, these can be
>communicated in-band using (currently unspecified) flag fields
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eastlake III Donald-LDE008 | 1 Nov 2006 18:34

DNSEXT WGLC: RFC2929bis - templates and guidelines

Hi,

A number of messages have bee posted concerning the RR Type Code
template and guidelines in the current 2929bis draft. While I have my
opinions, I will be happy to modify the draft to whatever the
Solomon-like judgment of our co-chairs says is the WG consensus.

As to my opinions:

I think the current template is about right. 
	Perhaps adding a question as to whether an RR re-uses or
requires the creation of any IANA registry might be added. But I do not
think we should require all the documentation of a new RR to be stuffed
into the template. Making the description available via some other
accessible public document seems fine. We want to keep down the burden
on applicants. Also, keep in mind that once someone has an RR Type Code,
if they make some change or extension in its use, it is not clear that
they have much incentive to update an IETF template but they will likely
update their own documentation. So a pointer to such documentation may
be more valuable and current than the original template.
 	Finally, to the complaint that the template requires applicants
to make judgments about their proposed RR that they may have difficulty
in doing, I would point out that the 2929bis specifically encourages the
early posting of partial or draft templates for the purpose of
soliciting comments and feedback. If some applicant doesn't feel that
they can answer one the judgmental questions, they should just post a
partial draft template and see what comments/feedback they get from
namedroppers.

While some template and its prior posting to the mailing list seem like
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Koch | 1 Nov 2006 19:48
Picon
Favicon

Re: DNSEXT WGLC: RFC2929bis

On Wed, Jul 19, 2006 I wrote:

> as agreed upon in Montreal I'd like to re-insert my comments expressed in
> <http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00936.html>
> into the WGLC. Modulo those I support this document.

I'd like to add one issue that came up during the work on NSEC3 (so credit
is really due to the nsec3 draft authors, but I'll take the blame):

{warning: the following text may contain adult protocol matter, reader
 descretion is advised.}

While both 1034 and 1035 currently say that the mnemonics for CLASS and TYPE
have to be disjoint, there is no guidance what character set (see warning
above) they ought to use.  Traditionally, it has been [A-Z0-9] with the
only exception being "-" in the now deprecated NSAP-PTR. Can we just hardcode
this, please?

-Peter

--
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/>
Permalink | Reply | 5 comments |
headers
Eastlake III Donald-LDE008 | 1 Nov 2006 21:15

RE: DNSEXT WGLC: RFC2929bis

Sounds like a reasonable idea to me as regards character set.
	Does 2929bis need to say something about who specifies the
mnemonic? Presumably the mnemonic should be included in the Standards
Action RFC for RR Types allocated that way, perhaps there should be a
"Suggested mnemonic (optional):" entry on the template, and the
Designated Expert would get to specify if they didn't like one provided
by the applicant...

Donald 

-----Original Message-----
From: owner-namedroppers <at> ops.ietf.org
[mailto:owner-namedroppers <at> ops.ietf.org] On Behalf Of Peter Koch
Sent: Wednesday, November 01, 2006 1:48 PM
To: IETF DNSEXT WG
Subject: Re: DNSEXT WGLC: RFC2929bis

On Wed, Jul 19, 2006 I wrote:

> as agreed upon in Montreal I'd like to re-insert my comments expressed

> in 
> <http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00936.htm
> l> into the WGLC. Modulo those I support this document.

I'd like to add one issue that came up during the work on NSEC3 (so
credit is really due to the nsec3 draft authors, but I'll take the
blame):

{warning: the following text may contain adult protocol matter, reader
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Schmidt | 1 Nov 2006 21:32
Gravatar

Re: New working group document ?

On Mon, Oct 30, 2006 at 08:38:47PM +0100, Peter Koch wrote:
> after several reads of the document I think it's a good essay about DNS
> spoofing and "size" of the threat (given references to 2006's figures), but I'm
> not sure what purpose it should serve as a WG document.
> 
> Admitted, it collects some of the folklore or implementors wisdom (and might
> be the first document that says the query has to be sent back with the
> response), but what's the intended status?
> I don't see many interoperability issues, so Standards Track might be a tough
> road.  Should it be a BCP for implementors? Or is it meant only as an addendum
> to RFC 3833 (informational)?
...
> I'm willing to review but before I commit I'd like to know again what's
> the intended outcome?  Clarifications of the base spec, BCP for
> implementors, BCP for operators or just documentation?

I would say given the potential threat DNS spoofing attacks might have right
now if someone was to implement them we are obliged to take all feasible steps
to fight it.
As an operator of recursive DNS service for a large DSL broadband ISP i really
would like to see this document in the Standards Track for the threat is not
going to vanish by praying everybody will apply BCP38 to their border routers
someday - history has shown that there have been some black sheep in that field
ever since Cisco invented uRPF.

As Bert Huberts own creation (PowerDNS recursor[2]) as well as Dan Bernsteins
dnscache [1] already implement the mechanisms proposed by this document i must
say, yes there are no interoperability issues i know of but this should be a
good thing, right?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 2 Nov 2006 09:46

Re: DNSEXT WGLC: RFC2929bis

Peter Koch <pk <at> DENIC.DE> writes:

> While both 1034 and 1035 currently say that the mnemonics for CLASS and TYPE
> have to be disjoint, there is no guidance what character set (see warning
> above) they ought to use.  Traditionally, it has been [A-Z0-9] with the
> only exception being "-" in the now deprecated NSAP-PTR. Can we just hardcode
> this, please?

I suggest adding a requirement that class mnemonics MUST NOT consists
only of [0-9] characters.  How about adding this to section 3.2?

  New class mnemonics MUST consist of only ASCII characters 'A'...'Z',
  '0'...'9'.  Class mnemonics MUST contain at least one character from
  the set 'A'...'Z'.

And similarly to section 3.1:

  New type mnemonics MUST consist of only ASCII characters 'A'...'Z',
  '0'...'9'.  Type mnemonics MUST contain at least one character from
  the set 'A'...'Z'.

Maybe it makes sense to have even harder requirements, e.g., that
mnemonics MUST start with [A-Z] to simplify master file parsers?

/Simon

--
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/>
(Continue reading)

Permalink | Reply | 3 comments |
headers
bert hubert | 2 Nov 2006 10:32
Picon
Favicon
Gravatar

Re: New working group document ?

On Wed, Nov 01, 2006 at 09:32:47PM +0100, Stefan Schmidt wrote:

> would like to see this document in the Standards Track for the threat is not
> going to vanish by praying everybody will apply BCP38 to their border routers

Also, internet access providers can't assume the problem is only beyond
their borders. Your own users, or servers in the same LAN are in a very good
position to spoof you.

BCP 38 is a great thing, and the draft mentions it, but we're not there yet.

	Bert

--

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
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/>
Permalink | Reply | 0 comments |
headers
Eastlake III Donald-LDE008 | 2 Nov 2006 18:09

RE: DNSEXT WGLC: RFC2929bis

I believe that "-" should also be allowed. Requiring that mnemonics
start with a letter is reasonable to simplify parsing.

Donald 

-----Original Message-----
From: Simon Josefsson [mailto:jas <at> extundo.com] 
Sent: Thursday, November 02, 2006 3:46 AM
To: Peter Koch; Eastlake III Donald-LDE008
Cc: IETF DNSEXT WG
Subject: Re: DNSEXT WGLC: RFC2929bis

Peter Koch <pk <at> DENIC.DE> writes:

> While both 1034 and 1035 currently say that the mnemonics for CLASS 
> and TYPE have to be disjoint, there is no guidance what character set 
> (see warning
> above) they ought to use.  Traditionally, it has been [A-Z0-9] with 
> the only exception being "-" in the now deprecated NSAP-PTR. Can we 
> just hardcode this, please?

I suggest adding a requirement that class mnemonics MUST NOT consists
only of [0-9] characters.  How about adding this to section 3.2?

  New class mnemonics MUST consist of only ASCII characters 'A'...'Z',
  '0'...'9'.  Class mnemonics MUST contain at least one character from
  the set 'A'...'Z'.

And similarly to section 3.1:
(Continue reading)

Permalink | Reply | 2 comments |

Gmane