Skip to main content

Establishing Local DNS Authority in Validated Split-Horizon Environments
draft-ietf-add-split-horizon-authority-14

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, add-chairs@ietf.org, add@ietf.org, draft-ietf-add-split-horizon-authority@ietf.org, evyncke@cisco.com, mohamed.boucadair@orange.com, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Establishing Local DNS Authority in Validated Split-Horizon Environments' to Proposed Standard (draft-ietf-add-split-horizon-authority-14.txt)

The IESG has approved the following document:
- 'Establishing Local DNS Authority in Validated Split-Horizon
   Environments'
  (draft-ietf-add-split-horizon-authority-14.txt) as Proposed Standard

This document is the product of the Adaptive DNS Discovery Working Group.

The IESG contact persons are Erik Kline and Éric Vyncke.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-add-split-horizon-authority/


Ballot Text

Technical Summary

   When split-horizon DNS is deployed by a network, certain domain names
   can be resolved authoritatively by a network-provided DNS resolver.
   DNS clients that are not configured to use this resolver by default
   can use it for these specific domains only.  This specification
   defines a mechanism for domain owners to inform DNS clients about
   local resolvers that are authorized to answer authoritatively for
   certain subdomains.

Working Group Summary

The document succeeded to reach a broad agreement. The initial design was
challenged but less concerns were raised during the second WGLC. 
The document went two WGLCs with the design radically changed between
versions till -03 (1st WGLC) and the design in the document since -04

The shepherd's write-up contains nice explanations of the 2 WGLC too 
long to be repeated here.

Document Quality

There were 10 IETF Last Call reviews by directorates + IANA,
all issues were resolved.

No known implementations

Personnel

   The Document Shepherd for this document is Mohamed Boucadair. The
   Responsible Area Director is Éric Vyncke.

IANA Note

IANA actions are well defined in the section 13: mainly 2 new entries
in existing registries (DHCP & DNS for underscore prefixed names), 
plus creating a sub-registry under the existing PvD registry.

RFC Editor Note