2.4.4 Domain Name System Operations (dnsop)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-11-08

Chair(s):

Rob Austein <sra@hactrn.net>
Peter Koch <pk@isoc.de>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Mailing Lists:

General Discussion: dnsop@lists.uoregon.edu
To Subscribe: majordomo@lists.uoregon.edu
In Body: subscribe dnsop
Archive: http://darkwing.uoregon.edu/~llynch/dnsop/

Description of Working Group:

The DNS Operations Working Group will develop guidelines for the
operation of DNS software servers and the administration of DNS zone
files. These guidelines will provide technical information
relating to the implementation of the DNS protocol by the
operators and administrators of DNS zones. The group will
perform the following activities:

1. Define the processes by which Domain Name System (DNS) software
      may be efficiently and correctly administered, configured, and
      operated on Internet networks. This will include root zone
      name servers, gTLD name servers, name servers for other DNS
      zones, iterative DNS resolvers, and recursive DNS resolvers.
      As part of this effort, the group will produce documents
      explaining to the general Internet community what processes
      and mechanisms should be employed for the effective management
      and operation of DNS software.

2. Publish documents concerning DNSSEC operational procedures.

3. Publish documents concerning the IPv6 DNS operational
      procedures and DNS-related IPv6 transition and coexistence
      issues.

4. Publish documents concerning the operations of the root and
      TLD services, and DNS resolvers.

Goals and Milestones:

Done  Submit I-D: revised Root Server Requirements.
Done  Submit I-D: revised version of Key Handling.
Done  Submit I-D: first version of Servers Sharing IP#.
Done  Submit I-D: first version of Performance and Measuring.
Done  Submit I-D: revised version of Key Handling.
Done  Submit I-D: revised version of Servers Sharing IP#.
Done  Submit Root Server Requirements to the IESG for consideration as Informational (BCP?).
Done  Submit I-D: 2nd revised version of Servers Sharing IP#.
Done  Distributing Authoritative Name Servers via Shared Unicast Addresses to the IESG for Informational
Done  Submit Observed DNS Resolution Misbehavior to the IESG for Informational
Jun 2004  Submit Identifying an Authoritative Name Server to IESG for Informational
Jun 2004  Submit Requiring DNS IN-ADDR Mapping to IESG for BCP
Done  Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational.
Sep 2004  Submit Requirements for Automated Key Rollover in DNSsec to IESG for Informational
Done  Submit DNS Response Size Issues to IESG for Informational
Done  Submit Operational Guidelines for 'local' zones in the DNS to IESG. Category to be determined.
Oct 2004  Submit Operational Considerations and Issues with IPv6 DNS to the IESG for Informational
Done  Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational
Jan 2005  Submit DNSSEC Operational Procedures to IESG for BCP

Internet-Drafts:

  • draft-ietf-dnsop-inaddr-required-07.txt
  • draft-ietf-dnsop-bad-dns-res-04.txt
  • draft-ietf-dnsop-serverid-05.txt
  • draft-ietf-dnsop-ipv6-dns-issues-12.txt
  • draft-ietf-dnsop-respsize-02.txt
  • draft-ietf-dnsop-dnssec-operational-practices-06.txt
  • draft-ietf-dnsop-ipv6-dns-configuration-06.txt

    Request For Comments:

    RFCStatusTitle
    RFC2870 BCP Root Name Server Operational Requirements
    RFC3258 I Distributing Authorittative Name Servers via Shared Unicast Addresses
    RFC3901 BCP DNS IPv6 transport operational guidelines
    RFC4074 I Common Misbehavior against DNS Queries for IPv6 Addresses

    Current Meeting Report

    -----------------------------------------------------------------------------
    DNSOP WG IETF64 Meeting Minutes (draft)
    Date: 8 November 2005, 15:10-17:10 [PST]
    Scribe: Sam Weiler
    Jabber Scribe: George Michaelson
    Chairs: Rob Austein & Peter Koch
    -----------------------------------------------------------------------------
    
    Process changes
    
       The chairs asked for agreement on a temporary moratorium on new
       work items until items on current agendas are gone, either through
       publication or killing documents.  Before the next IETF, they hope
       to go through each of the current work items and kill those that
       the WG won't commit to reviewing (approx. five individuals).  Then,
       for new work, if the WG can't get N (5?) people to review an item,
       we don't take it on.
    
       While agreeing that a simple "hummm" should not be sufficient for
       taking on new work, Olaf Kolkman expressed the concern that requiring an
       empty stack before taking on new work may be bad. He asked that if
       new items are useful we go ahead and accept them (after applying
       the gating function based on number of reviewers).  The chairs
       agreed to this modification
    
       Two other suggestions were made: Pekka Savola suggested that every
       author proposing a draft should publicly review 5 other docs.
       And Liman suggested assigning small teams to shepherd (new) docs,
       rather than a single editor.
    
       No objections were raised to the chairs' proposal.
    
    
    Documents past last WG
    
       The chairs listed the docs beyond WG last call, per the agenda.
    
       The chairs called for a show of hands for those who had read
       draft-ietf-dnsop-dnssec-operational-practices and think we
       should advance it.
    
       David Kessens explained that ipv6-dns-issues passed IESG except for one
       AD.  The doc will be on next IESG telechat agenda to try to clear
       that Discuss.
    
       Mohsen Souissi asked for clarification about the state of
       ipv6-dns-configuration, and the chair confirmed that this WG is
       done with it -- the IESG just wanted it as input for chartering
       decisions.
    
    
    Active drafts
    
    draft-ietf-dnsop-serverid-05.txt
    
       There was a WGLC on the serverid draft and the editor believes all
       substantive comments have been addressed in current draft.  The
       draft is waiting for the chairs to advance it; no further work is
       needed in the WG at this time.  Olaf raised the question of whether
       this work is still needed since the NSID draft in DNSEXT has now
       progressed.  The chairs asked if any in the room thought the draft
       was not needed (no hands), who supported publications (modest
       humm), who opposed (silence), and who had read it (some hands).
    
    draft-ietf-dnsop-inaddr-required-07.txt
    
       For inaddr-required, less than a handful of those present
       acknowledged having read the CURRENT version of the draft.  There
       were 4-6 people willing to commit to reading the draft, though some
       of those specifically declined to agree that the draft was worth
       advancing.  The chairs will take the decision of what to do with
       the draft to the list.
    
    draft-ietf-dnsop-respsize-02.txt
    
       The chairs called for a show of hands for those who had read the
       LATEST version of the respsize draft and thought it was ready for
       last call.  They asked those uncomfortable with advancing it to
       send comments to the list.
    
    
    Expired drafts
    
    draft-huston-6to4-reverse-dns-03.txt
    
       This was a product of an IAB IPv6 ad hoc group that suggested this WG
       review it and publish it as informational.  This has not been
       published elsewhere, but it has gotten substantial review, and the
       service it describes is now up and running.
    
       Pekka Savola expressed concerns about whether this document
       accurately describes the service as it's running and will continue
       to run.  Geoff Huston assured us that this does accurately describe the
       current service, but that there are no reassurances the service
       won't change in the future.  The service is in the last stages of
       testing, not productions, so issues that arise during WGLC can
       still be considered.  Ed Lewis also expressed concerns that we were
       being asked to rubber stamp others' work.  David Kessens reassured
       the WG that we can indeed make changes to the document -- this
       isn't a request for rubber stamping.
    
       Sam Weiler and Lars-Johan Liman asked why DNSOP was being asked to
       review this, rather than the IAB publishing it directly or the
       editor sending it in as an individual submission.  It was explained
       that the IAB has asked us to take this on -- they'd rather see us
       publish it.  David Kessens expressed a preference against
       individual submissions, in part because of the RFC Editor's ISR
       delays.
    
       The chairs called for reviewers and some committed.
    
    draft-fujiwara-dnsop-dns-transport-issue-00.txt
    
       The editor is withdrawing the draft.
    
    
    Potential new items.
    
    draft-andrews-full-service-resolvers-01.txt
    
       Mark Andrews gave a brief presentation (see slides in the proceedings)
       arguing that having an RFC will help encourage some vendors to do
       this.  The chairs asked that the detailed discussion of the names
       on the list be deferred.  They clarified that this is NOT a
       protocol change and offered an alternate explanation: it's like
       replicating AS112 on all recursive resolvers.
    
       Olaf pointed out that the registry lacks an allocation policy
       and as asked to send text fixing that.
    
       Peter Lothberg started a brief discussion of alternatives to
       NXDOMAIN answers (such as answering the queries) and Bill Manning
       told of his experiences doing that.  When he first proposed
       standing up dedicated servers for this, the IANA said this was
       ludicrous -- these queries would never make it out onto the live
       net.  This was a safety net.  When they actually tried it, there
       was a huge number of queries and Bill got an "exorbitant" number of
       threats from important people.
    
       There was some discussion of whether this "blacklist" needs to be
       updated regularly, and Mark explained that one must be careful
       about what names are added -- removal from the list is difficult.
    
       Olafur Gudmundsson and David Hankins spoke up in support of the draft and
       committed to review it.  The chairs called for other reviewers.
    
    draft-minda-dnsop-using-in-bailiwick-nameservers-01.txt
    draft-morishita-dnsop-anycast-node-requirements-01.txt
    
       The editors of these documents weren't present; discussion should
       go to the list.
    
    draft-durand-dnsop-dont-publish-01.txt
    
       Very few comments have been made about it on the list and it's not
       clear how interested the WG is.  There was discussion of whether to
       mention split-brain configuration in the draft -- consensus seems
       to be strongly in favor of doing so, recognizing that split brain
       is a fact of life.  The chairs encouraged the editor to submit a
       new version within 8-10 weeks, which should be about the time that the WG
       has finished its review of existing items and is ready to consider
       new work.
    
    draft-kurtis-tld-ops-00.txt
    
       The editor didn't get a revision in by the draft cutoff and
       promised to do better next time.
    
    draft-krishnaswamy-dnsop-dnssec-split-view-01.txt
    
       This draft has gotten very few comments on the list (there were no
       responses to a query from Ed Lewis in August).  The chairs called
       for reviewers, and 5-6 people volunteered.
    
    draft-pappas-dnsop-long-ttl-00.txt
    
       The chairs pointed out this document, which will be discussed on
       the list later.  They're particularly concerned with how this
       interacts with DNSSEC and would especially appreciate review by TLD
       operators and registries.
    
    
    Charter and direction
    
    The chairs pointed out that the previous charter focuses on work in
    three areas:
    
      1) IPv4/v6 coexistence
      2) DNSSEC
      3) general DNS operations
    
    The chairs asked if there are any other big areas that need to be
    included, and Ed Lewis mentioned the resolver and measurement of the
    effects of DNS operational changes.
    
    
    Any other business
    
    draft-kato-dnsop-local-zones-00.txt
    
       There was a brief discussion of whether Kato-san's local zones
       draft should be merged into Andrews' draft.  Liman spoke up for
       keeping them separate.
    
    draft-conroy-enum-edns0-01.txt
    
       The question was raised of how to support other working groups, in
       particular reviewing this draft.  Patrik Faltstrom, as an ENUM chair,
       asked if we need a doc saying "you should do EDNS0" (some phone handsets
       aren't.) and, if so, should we do that in DNSOP, in ENUM, or in
       ENUM reviewed in DNSOP?  Rob thinks DNSOP should go ahead and
       review it, to save the IESG the hassle of sending it to us later in
       the process.
    
       Patrik asked for a coeditor and Liman volunteered.
    
       There was discussion of the scope of the document: whether it
       should include both operational and implementation requirements
       and, since this touches clients, servers, and middleboxes, whether
       the doc would grow unwieldy.  It was suggested that a big doc would
       do ENUM a disservice -- they need a short, terse doc with lots of
       requirements to use to beat implementers.  ENUM and other WGs that
       need such a document should write it themselves, with our review,
       and if we want a bigger, more comprehensive document, we can reuse
       text from their documents.  (Mark Andrews volunteered to review a
       DNS firewalls rules document.)
    
    Following up on the discussion of draft-andrews-full-service-resolvers
    and Bill Manning's stories, Dave Hankins mentioned that as a
    contact for AS112 advertised address space, he regularly gets
    phone calls from folks who think they're under attack.  Sundry
    suggestions were offered for mitigating this lack of clue, including
    changing the WHOIS records or advertising a special phone number which
    is answered only by a machine.
    -----------------------------------------------------------------------------
    

    Slides

    Local Authority in Resolvers ("AS112 in a box")