Olaf Kolkman | 1 Jun 08:35 2005
Picon
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 | 1 Jun 11:49 2005
Picon
Picon

RFC2538bis, an update.


Dear colleagues,

The last call on RFC2538bis has concluded[1], there were a few issues that
have been addressed in version 2 in the document.

There were some questions on the IANA considerations (see thread starting
at [2]), since nobody identified possible interoperability problems if we
leave the text as is we'll leave the text as is.

No volunteers have stepped forward for interoperability testing. If
nobody steps forward before the end of the week I'll be forwarding
this document to obsolete RFC2538 as a proposed standard. There is no
reason to stall any longer.

--Olaf

Also see
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-02.txt
and http://josefsson.org/rfc2538bis/

[1] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00740.html
[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00273.html

--

-- 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

--
(Continue reading)

Simon Leinen | 1 Jun 14:28 2005
X-Face
Picon

Fwd: [Announcing the 2005 SIGCOMM Award Winner: Paul Mockapetris]

I hope you find this relevant for namedroppers-- Simon.

Picon
From: Erich Nahum <nahum <at> turing.acm.org>
Subject: Announcing the 2005 SIGCOMM Award Winner: Paul Mockapetris
Date: 2005-06-01 02:14:00 GMT
PAUL V. MOCKAPETRIS WINS 2005 ACM SIGCOMM AWARD

Paul V. Mockapetris, Chairman and Chief Scientist at Nominum Inc., is the
winner of the 2005 ACM SIGCOMM Award. 

The SIGCOMM Award is widely recognized as the highest honor in computer
networking.  The Award recognizes lifetime achievement in and
contributions to the field.  It is awarded annually to a person whose
work, over the course of his or her career, represents a significant
contribution to the field and a substantial influence on the work and
perceptions of others in the field.

The SIGCOMM Award is presented to Dr. Mockapetris "in recognition of his
foundational work in designing, developing and deploying the Domain Name
System, and his sustained leadership in overall Internet architecture
development."

Paul Mockapetris created the original DNS protocol, wrote its first
(Continue reading)

Olaf M. Kolkman | 1 Jun 16:29 2005
Picon
Picon

Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07


Dear Colleagues,

This is the second WGLC for the "Wildcard clarification document"

   
                       The Role of Wildcards
                    in the Domain Name System
              draft-ietf-dnsext-wcard-clarify-07.txt

Abstract:

    This is an update to the wildcard definition of RFC 1034.  The
    interaction with wildcards and CNAME is changed, an error
    condition removed, and the words defining some concepts central
    to wildcards are changed.  The overall goal is not to change
    wildcards, but to refine the definition of RFC 1034.

     
The first WGLC of this document was in September 2003 [1] and raised
the issue of wildcard synthesis. That last call concluded [2] with
overall consensus of the working-group is that clarification of
wildcard behavior is necessary and that the document is to proceed on
the standard track.

A number of open issues were identified at that time and while
clarifying these new issues came up.  The main topics were the
handling of NS, SOA, CNAME and DNAME types owned by a "*-labels".

Hereby we start a last call that will end Sunday June 19. 
(Continue reading)

DNSEXT WGLC LLMNR-40 (Link-Local Multicast Name Resolution)

This message starts a WGLC for LLMNR ending on June 17'th.

Short history: The working group issued a Last call on this document[1]
(version -22) in August 2003, after major changes version (34) was
advanced[2] to the IESG in August 2004. The AD raised issues of
omission in the design of the protocol.
This resulted in a number of significant changes in the document.
The current version (40) has addressed all the issued raised by the
AD and subsequently by others.
As the changes to the protocol document and protocol itself are significant
the AD asked the working group to review the document again.

Current version of the draft is at:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-40.txt

This document has an issues tracker at:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

Summary of changes since version 33:
  - How names are determined to be unique and conflict resolution.
  - Coexistence of LLMNR, DNS and multiple transport protocols, this
    relates to if/when LLMNR is used and over what transport.
  - Editorial and clarifications of text.

The document is on standards track.

Please reply either to working group mailing list or both chairs with
comments, or acknowledgement that you have no issues with the document.

	Olafur & Olaf
(Continue reading)

Ralph Droms | 1 Jun 21:26 2005
Picon

dhc WG last call on <draft-ietf-dhc-ddns-resolution-08.txt>

(Cross-posted to namedroppers; see http://www1.ietf.org/mail-
archive/web/dhcwg/current/msg05005.html for earlier discussion of this
document)

This message announces a WG last call on "Resolution of DNS Name
Conflicts among DHCP Clients" <draft-ietf-dhc-ddns-resolution-08.txt>.
The last call will conclude at 1700 EST (USA) on 2005-06-08.

Please respond to this WG last call.  Note that this is the *second*
last call for this document.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

If you commented about this document between the first last call and
this new last call, please repost your comment so we can be sure to
assess all support for the document.

Summary:

There are options in DHCP that can be used for transmitting
information about updating DNS. However, these do not explicitly
control updating the name to address and address to name mappings
maintained in the DNS, as performed by hosts acting as DHCP clients
and servers. draft-ietf-dhc-ddns-resolution-08.txt describes
techniques for the resolution of DNS name conflicts among DHCP clients
and servers.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-
(Continue reading)

Samuel Weiler | 3 Jun 14:47 2005

Re: Glue (was Re: validating a qtype=* response)

On Tue, 24 May 2005, Edward Lewis wrote:

> So - in summary, what I am saying is that you should only return
> NOERROR/NODATA for a qtype=* when the name is a previously sought
> empty non-terminal, in the negative cache.  The existence of names
> ought never be inferred by a cache, if a name is not explicitly in
> local information, and recursion is permitted, the server ought to
> recurse.

I think I agree with Ed here.

Would you gentlemen take a look at the new bis-updates doc and see if
Section 2.3 is adequate?  I know it doesn't capture all of the
subtlety discussed in this thread, but I'm thinking it still might be
adequate for most readers.  Here it is, for ease of reference:

2.3  Validating Responses to an ANY Query

   RFC4035 does not address now to validate responses when QTYPE=*.  As
   described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
   may include a subset of the RRsets at a given name -- it is not
   necessary to include all RRsets at the QNAME in the response.

   When validating a response to QTYPE=*, validate all received RRsets
   that match QNAME and QCLASS.  If any of those RRsets fail validation,
   treat the answer as Bogus.  If there are no RRsets matching QNAME and
   QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
   clarified in this document).  To be clear, a validator must not
   insist on receiving all records at the QNAME in response to QTYPE=*.

(Continue reading)

Roy Arends | 3 Jun 15:33 2005
Picon

where did all them bits go ?

I guess 4034 and 4035 are missing information on where exactly the CD and
AD bits reside in the DNS header. Its specified in rfc2535, but omitted in
the current drafts, which obsolete 2535.

I'll send text.

Roy

--
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 | 3 Jun 15:57 2005

RE: Glue (was Re: validating a qtype=* response)

So to summarize:  if one RRSIG covering one RRset in a response for
QTYPE="*" fails to validate, then the whole response is marked Bogus.  I can
accept that.  However, that might lead to a weird situation where a cache
would have the same RRset in the BAD cache and the "good" cache for the same
QNAME, but with one stored as a part of a QTYPE="*" query.  This assumes the
cache is storing responses as a single atomic unit based on
qname/qclass/qtype (which may not be the case for some).  Not sure how that
would affect things.

I would suggest changing the wording of the last sentence to state:

"To be clear, a validator must not expect to receive all records at the
QNAME in response to QTYPE=* if the query is sent to a cache and not an
authoritative server."

This would bring it in line with what RFC 1034 has in the examples for
QTYPE="*" (Section 6.2.2).

Scott

> -----Original Message-----
> From: owner-namedroppers <at> ops.ietf.org
> [mailto:owner-namedroppers <at> ops.ietf.org]On Behalf Of Samuel Weiler
>
> On Tue, 24 May 2005, Edward Lewis wrote:
>
> > So - in summary, what I am saying is that you should only return
> > NOERROR/NODATA for a qtype=* when the name is a previously sought
> > empty non-terminal, in the negative cache.  The existence of names
> > ought never be inferred by a cache, if a name is not explicitly in
(Continue reading)

Scott Rose | 3 Jun 15:57 2005

RE: where did all them bits go ?

Yeah, I think Sam W mentioned this to me at some point as well.  I remember
earlier versions of the text had them included, but disappeared in the
rewrites.  I think because it was in the records draft, and we forgot to
move it, but I'm not sure.

The IANA registry for DNS header bits does include the CD and AD positions,
but an implementor would only know that if they consulted the IANA registry
as well as the spec.

Also, the IANA reference for the bits is still given as the dnssec-protocol
draft and not the RFC... oops.

> -----Original Message-----
> From: owner-namedroppers <at> ops.ietf.org
> [mailto:owner-namedroppers <at> ops.ietf.org]On Behalf Of Roy Arends
> Sent: Friday, June 03, 2005 9:34 AM
> To: namedroppers <at> ops.ietf.org
> Subject: where did all them bits go ?
>
>
> I guess 4034 and 4035 are missing information on where exactly the CD and
> AD bits reside in the DNS header. Its specified in rfc2535, but omitted in
> the current drafts, which obsolete 2535.
>
> I'll send text.
>
> Roy
>
> --
> to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
(Continue reading)


Gmane