headers
Olaf Kolkman | 1 May 2004 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 | 1 comment |
headers
Ólafur Gudmundsson/DNSEXT co-chair | 3 May 2004 19:53

Namedroppers Moderation policy change

At 02:35 2004-05-01, Olaf Kolkman wrote:

>- Moderation
>
>   Moderation is based on "subscriber-only with spam filter".

Effective now:
Posts over 20000 characters by subscribers will be moderated.

This is done to combat more intelligent virus mailers that forge
subscriber postings to the mailing list .
I apologize for the viruses that have made it out to the mailing
list over the weekend.

Effects on posting: since 2002/01/01 4915 messages have been posted,
a maximum[1] of 22 messages would have been affected by this policy
12 of them legitimate ones, 10 malware.

Send comments to chairs.
         thanks
         Ólafur (DNSEXT co-chair) (current Namedroppers moderator)

[1] Depends on how server counts size with or without headers.

--
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 | 0 comments |
headers
Pekka Savola | 5 May 2004 07:00
Picon

handling of additional data (fwd)


 [ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

FYI,

This issue was raised in DNSOP, but I was advised to also solicit 
opinions from here.

(I'm not subscribed so please keep in Cc:)

---------- Forwarded message ----------
Date: Tue, 4 May 2004 12:24:15 +0300 (EEST)
From: Pekka Savola <pekkas <at> netcore.fi>
To: dnsop <at> lists.uoregon.edu
Subject: handling of additional data [Re: [dnsop] WGLC for
    draft-ietf-dnsop-ipv6-dns-issues-06.txt]

Hi,

Let's take an issue separately from the rest.  Me and Jinmei discussed
this, but were OK with as it is.  However, if WG has clear opinions,
now might be time for modifying the text and/or recommiding changes to
the additional data processing.

As described by ipv6-dns-issues, section 4.4, there are two kinds of 
additional data:

   1.  "critical" additional data; this must be included (all the
(Continue reading)

Permalink | Reply | 8 comments |
headers
Robert Elz | 6 May 2004 13:57
Picon

Re: handling of additional data (fwd)

    Date:        Wed, 5 May 2004 08:00:58 +0300 (EEST)
    From:        Pekka Savola <pekkas <at> netcore.fi>
    Message-ID:  <Pine.LNX.4.44.0405050758170.15828-100000 <at> netcore.fi>

  | A)  Is there consensus that it's better to set TC bit than to return 
  |     only some RRsets of critical additional data?

I have no idea if there's consensus or not (consensus among whom?), but
assuming the question intended there was really "Is it better..." (as in
questions B & C) then I think the answer is probably yes, but I am not
certain that is necessarily true - it is certainly better to set TC than
to send no "critical" additional data, but if some is sent, and even better,
if which of it is sent can vary from one response to another, then I am
not certain that just sending it, without TC isn't the better solution
(I'd really like to see some performance measurements with things done both
ways).

  | B)  Is it better to omit all the courtesy addional data, rather than 
  |     omit some RRsets?

No.   Provided that only complete RRsets are omitted, not just parts of
RRsets, if a complete "courtesy" RRset will fit, and the server wants to
send it (ie: my answer isn't a demand upon servers to include such data),
include it, regardless of how many others won't fit (again, better if the
implementation doesn't have a fixation on which of the available RRsets
it should include when they won't all fit, but allows that to vary).

  | C)  (This is relevant if you answered "no" to B) Is it better to set
  |     TC bit rather than return only some RRsets with courtesy 
  |     additional data?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Masataka Ohta | 6 May 2004 23:11
Picon

Re: handling of additional data (fwd)

Kre;

> then I am
> not certain that just sending it, without TC isn't the better solution

The problem is that glues can be provided only with referral
and there is no way to separately ask glues.

By definition, glues are things which can not be asked without
the glues itself.

Worse, there is no way for the resolver know that some glues
are missing, unless glues are under the zone cut, which is
not always the case, even in which case, separate asking
causes the same referral still with missing glues.

						Masataka Ohta

--
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
Robert Elz | 7 May 2004 01:20
Picon

Re: handling of additional data (fwd)

    Date:        Fri, 07 May 2004 06:11:29 +0900
    From:        Masataka Ohta <mohta <at> necom830.hpcl.titech.ac.jp>
    Message-ID:  <409AAA01.5000607 <at> necom830.hpcl.titech.ac.jp>

  | The problem is that glues can be provided only with referral
  | and there is no way to separately ask glues.

Yes, true, but there should never be a need to ask specifically for glue,
asking for the data should return the same thing - if the glue has been
made different than the authoritative data, and something is depending upon
that, then I don't much care what happens.

  | By definition, glues are things which can not be asked without
  | the glues itself.

I'm not sure I quite agree with that definition, but nothing depends upon
it here, so it doesn't matter.

  | Worse, there is no way for the resolver know that some glues
  | are missing,

True, but does it really matter?

If all the glue is omitted, then, of course, there's a problem - that's
why I said ...

	it is certainly better to set TC than
	to send no "critical" additional data,

but if some glue is included, then the resolver has a path to the next set
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Vixie | 7 May 2004 02:47

Re: handling of additional data (fwd)

> I'd be hesitant about claiming that one is necessarily better than the other
> based upon no more than superstition and guesswork.

same here.  the definition of "helpful" vs. "necessary" glue is at best
subjective.  please just set TC if anything does not fit, and that you
truncate on rrset boundaries, just like 1035 recommends.

--
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 | 13 comments |
headers
Masataka Ohta | 7 May 2004 03:14
Picon

Re: handling of additional data (fwd)

Paul;

> the definition of "helpful" vs. "necessary" glue is at best
> subjective.

It is a problem of the definition of the draft.

However, "glue" is necessary while other additionals are
merely helpful.

						Masataka Ohta

--
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
Andreas Gustafsson | 7 May 2004 03:29

Re: handling of additional data (fwd)

Paul Vixie writes:
> same here.  the definition of "helpful" vs. "necessary" glue is at best
> subjective.  please just set TC if anything does not fit, and that you
> truncate on rrset boundaries, just like 1035 recommends.

While do I agree with your recommendation (for the specific case of
glue), I'm unable to find the RFC1035 text you refer to.  There's also
the following text in RFC2181 section 9 which seems to contradict it:

   Where TC is set, the partial RRSet that would not completely
   fit may be left in the response.

--

-- 
Andreas Gustafsson, gson <at> nominum.com

--
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 | 3 comments |
headers
Masataka Ohta | 7 May 2004 03:34
Picon

Re: handling of additional data (fwd)

kre;

>   | Worse, there is no way for the resolver know that some glues
>   | are missing,
> 
> True, but does it really matter?
> 
> If all the glue is omitted, then, of course, there's a problem - that's
> why I said ...
> 
> 	it is certainly better to set TC than
> 	to send no "critical" additional data,
> 
> but if some glue is included, then the resolver has a path to the next set
> of servers.   It doesn't have all the information, and may not be able to
> reach all of the servers, but it should be able to reach at least one.

Say "fault tolerance".

It is required that each zone has at least two name servers.

Moreover, administrators of a zone with more than three name
servers are doing so with *REASONS* that addresses of all of
them should be tried by the client.

So, it is still OK if a reply includes "at least one" address
of name servers chosen randomly for every query and clients
retry original query.

However, they are new requirements. Worse, because of cached referral,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane