[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    95.12.4 dnsind minutes - first draft
From:       randy () psg ! com (Randy Bush)
Date:       1995-12-06 21:48:00
[Download RAW message or body]

Agenda:
- Admin
- IXFR
- Notify
- Dynamic update

We will forward draft-degroot-classless-inaddr-00.txt, delegation of IN-ADDR
on a non-octet boundary, for BCP.  The authors are working on a new draft.

IXFR: ask author to consider issue of IXFR optionally condensing multiple
versions into one change.  Then send up for standard track.

Notify:
- Removed auto-discovery of "stealth servers" - instead, have a list.
- Default list of servers: set of NS records, minus MNAME, minus self
- Comment: leave issue of auto-discovery vs. list up to implementation.
  Disagreement: some servers might not be notified
  Make it a recommendation only?
- Question about primary having an "optional" NS RR, decided once again that
  NS RR for primary master is optional
- Add a new definition for "listed" name servers.
- What about lack of alternate implementations?  (Not an issue until
  it goes from Proposed Standard to Draft Standard).  Differing
  implementations of specific features, although all are in BIND, may be
  reasonable.
- ICMP network unreachables?  Ignore.  Same for host unreachable.

Dynamic update:
- Removed use of SIG RR to decouple from DNSSEC draft (authentication can be
    added later)
- To Protect against re-ordering:
    Could use SOA RR for protection against non-malicious reordering:
      but doesn't scale
    Could use non-wildcard DELETE as "weak" protection against non-malicious
      reordering
- SIG RRs would serve many other useful purposes: can age info in
    authoritative servers, authentication, replay protection
- NULL SIG RR type: need to keep it until we have a substitute
- Suggestion: a warning label saying ADD is dangerous.  not really.
- Suggestion: table for different RR types and what operation applies
- Should there be a limit on # of requests over TCP connection?
  Consensus was no.  It was felt that the draft should specify multiple
  (quite separate) updates in a single connection.
- Make ADDNAMENEW fail when on an empty nonterminal name (you can
    ADDNAMEEXIST though)
- Granularity of updates?  Single RRs, or a set?  Make it single.
- Not all RRs in a set must have same TTLs?
- Do changes, then issue last call

-30-

[prev in list] [next in list] [prev in thread] [next in thread]