Olaf Kolkman | 1 Feb 08:35 2007
Picon

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)

Olaf M. Kolkman | 5 Feb 12:13 2007
Picon

Re: WGLC: draft-ietf-dnsext-nsec3-09


On 10Jan 2007, at 6:15 PM, Olaf M. Kolkman wrote:

> Dear Colleagues,
>
>
> You may well have seen the release of draft-ietf-dnsext-nsec3-09.

I have implemented the RRs in perl's Net::DNS::SEC library (not  
released yet) and note that the specification is clear enough to  
provide wire compatibility. Besides, the hashing algorithm, with its  
salt and iterations are clearly described.

I have not implemented validation algorithms or special processing  
for nameservers but in my opinion the document being clear enough to  
reach interoperability.

In the past I have repeatedly said that I am not happy with the way  
that OPT-OUT (then called OPT-IN) changes the security model away  
from the concept that a "zone" is secure. I continue to not be happy  
but consent with the argument that such feature is needed in specific  
operational environments.

namedropper, no hats,

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
(Continue reading)

Olaf M. Kolkman | 5 Feb 12:10 2007
Picon

Re: WGLC: draft-ietf-dnsext-nsec3-09


On 10Jan 2007, at 6:15 PM, Olaf M. Kolkman wrote:

> Dear Colleagues,
>
>
> You may well have seen the release of draft-ietf-dnsext-nsec3-09.
>
> With the release of this draft, so have the chairs been informed, the
> issue list is cleaned up and the work is seen as sufficient quality
> to be forwarded to the IESG. Hence, this message opens up a last call
> for "DNSSEC Hashed Authenticated Denial of Existence". The last call
> will terminate Sunday February 11 around 23:00 HST.

Folk, please review and go on record for doing so.

In particular those that implemented and participated in workshops  
are invited to do so.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

Scott Rose | 7 Feb 02:14 2007

draft-ietf-dnsext-rfc2672bis-dname issues status (resolved issues)

Resolved Issues in draft-ietf-dnsext-rfc2672bis-dname

The following issues were brought up in the previous version of DNAME 
clarification draft, and have been resolved and this has been
reflected in the latest version of the draft (currently -01)

The issues are numbered according to their previous numbering in 
namedropper threads.  If there are any further comments or 
one of these issues should be re-opened, please provide reasoning
and any text.

Issue 4.1  DNAME as delegation tool
	Text added to clarify that DNAME is not a tool to
	make delegations.  Please read and check.  If it 
	needs further clarification, please provide additional
	text.

Issue 4.2  DNAME does not re-direct name itself
	Text added to clarify that X DNAME Y does not 
	re-direct queries for QNAME X itself.

Issue 4.4 and 4.13  Target name in DNAME RDATA should be canonical?
	Added to -01 draft, the target name must be canonical,
	brining it in line with NS and MX RDATA target names.

Issue 4.5 DNSSEC and NSEC/NSEC3 bitmap
	Added text for validator behavior when checking responses
	with NSEC/NSEC3.  Validator should check RRType bitmap
	for presence of DNAME RR at ownername that may 
	indicate an incorrect response.
(Continue reading)

Scott Rose | 7 Feb 02:19 2007

DNAME Issue 4.10 (open) CNAME TTL value

Open Issue 4.10 TTL of Synthesized CNAME RRs

Original message:
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01340.html

Reply from Ed Lewis suggesting CNAME TTL = DNAME TTL
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01435.html

This issue is still open for discussion.  The current
version of the draft states the CNAME TTL is 0 but
MAY be set to the TTL of the original DNAME and that
resolvers could expect either TTL in a packet.

If there are strong opinions either way (or opinions in favor
of allowing both) please state the opinion.  

Scott & Wouter
DNAME clarify draft editors

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

Scott Rose | 7 Feb 02:18 2007

DNAME Issue 4.3 (open)

Issue 4.3 DNAME is always included in outgoing packets

This issue is still open

Original email 

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01333.html

follow ups:

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01367.html
and
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01366.html

A discussion about the algorithms in RFC 1034 and changes 
that may need to be made in this draft to accommodate DNAME

Additional topics

- Firewalls and middle boxes may not understand DNAME or
  the synthesized CNAMEs

- Microsoft Windows resolvers may reject responses 
  with DNAME RRs
  http://support.microsoft.com/kb/920162

So the formal issue of "what should be returned in the response
packet" is still open for discussion.  Please provide feedback, 
with text as appropriate.  

(Continue reading)

Mark Andrews | 7 Feb 03:32 2007

Re: DNAME Issue 4.3 (open)


> Issue 4.3 DNAME is always included in outgoing packets
> 
> This issue is still open
> 
> Original email 
> 
> http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01333.html
> 
> follow ups:
> 
> http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01367.html
> and
> http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01366.html
> 
> A discussion about the algorithms in RFC 1034 and changes 
> that may need to be made in this draft to accommodate DNAME
> 
> Additional topics
> 
> - Firewalls and middle boxes may not understand DNAME or
>   the synthesized CNAMEs

	I could believe old ones not understanding DNAME.  Mind you
	DNAME has been on standards track for 7 1/2 years now.  Any
	middlebox being released today should understand DNAME.  If
	it doesn't it is well and truely *broken*.

	I don't believe that any middlebox will have a problem with
	CNAME's unles they are trying to enforce a ttl of 0 based
(Continue reading)

Jelte Jansen | 7 Feb 09:48 2007
Picon

Re: WGLC: draft-ietf-dnsext-nsec3-09


Scott Rose wrote:
> I have read the draft, and I support it.
> 
> I sent the earlier comment to the authors/DNSEXT co-chairs:
> 
> ***
> Re: the NSEC3PARAM RDATA field section:
> 
> Would it be better to say that the values should be the same values as
> the corresponding values in the complete NSEC3 chain?  Just to press the
> notion that the NSEC3PARAM RR signals a complete chain.
> 
> And the flags field for the NSEC3PARAM RR is going to be different than
> the flags for the NSEC3 RR?  That's what it sounds like (in that the
> OPT-Out flag should never be set, and validators MUST ignore all
> non-zero flags in the NSEC3PARAM.
> ***
> 
> It is not a concern for me to warrant holding up the draft.  I just
> thought it sounded odd in the text.  Not sure what the solution is, or
> even if it requires a solution.
> 

Since the opt-out flag may differ between separate NSEC3 RRs, the same
flag in the NSEC3PARAM could only signify that 'some' NSEC3 RRs have the
opt-out bit set. This would be redundant and possibly even confusing.

Whether or not future flags in this field must match the complete chain
they refer to will depend on the meaning of those flags and their
(Continue reading)

Roy Arends | 7 Feb 12:00 2007
Picon

Re: WGLC: draft-ietf-dnsext-nsec3-09

> Olaf M. Kolkman wrote:
> 
> > 
> > Dear Colleagues,
> > 
> > 
> > You may well have seen the release of draft-ietf-dnsext-nsec3-09.
> > 
> > With the release of this draft, so have the chairs been informed, the
> > issue list is cleaned up and the work is seen as sufficient quality
> > to be forwarded to the IESG. Hence, this message opens up a last call
> > for "DNSSEC Hashed Authenticated Denial of Existence". The last call
> > will terminate Sunday February 11 around 23:00 HST.
> > 
> > Please review the draft and put that fact on record through a post to
> > the mailing-list. If there are any new issues please bring them
> > forward. If old issues have been closed unsatisfactory feel fee to
> > make note of those but do not expect old discussions to be rehashed.
> 
> I have reviewed the nsec3 draft and support it going forward. 

Thanks for the review John.

> I minor typo in addition to those raised by Wouter
> Page 47 B 6
> The query returned an NSEC3 RR that show that the requested was
> The query returned an NSEC3 RR showing that the request was

Thanks, I fixed those.

(Continue reading)

Roy Arends | 7 Feb 11:58 2007
Picon

Re: WGLC: draft-ietf-dnsext-nsec3-09

Scott Rose wrote on 01/30/2007 04:40:29 PM:

> I have read the draft, and I support it.
> 
> I sent the earlier comment to the authors/DNSEXT co-chairs:
> 
> ***
> Re: the NSEC3PARAM RDATA field section:
> 
> Would it be better to say that the values should be the same values as 
> the corresponding values in the complete NSEC3 chain?  Just to press the 

> notion that the NSEC3PARAM RR signals a complete chain.
> 
> And the flags field for the NSEC3PARAM RR is going to be different than 
> the flags for the NSEC3 RR?  That's what it sounds like (in that the 
> OPT-Out flag should never be set, and validators MUST ignore all 
> non-zero flags in the NSEC3PARAM.
> ***
> 
> It is not a concern for me to warrant holding up the draft.  I just 
> thought it sounded odd in the text.  Not sure what the solution is, or 
> even if it requires a solution.

Thanks for the review Scott, I'll take a look and try to figure out better 
wording.

Roy

--
(Continue reading)


Gmane