Hi,
Please find my comments on draft-pauly-ipsecme-split-dns-02.
Yours,
Daniel
3. Protocol Exchange
3.1. Configuration Request
An initiator MAY convey its current DNSSEC trust anchors for the
domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does
not wish to convey this information, it MUST use a length of 0.
MGLT: I think a high level explanation may be needed for the reader to
understand why the initiator provides the trust anchor but maybe that is
the responder and not the initiator.
3.2. Configuration Reply
For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
one or more INTERNAL_DNSSEC_TA attributes MAY be included by the
responder. This attribute lists the corresponding DSSNEC
MGLT: DNSSEC
trust
anchor in the DNS wire format of a DS record as specified in
[RFC4034].
MGLT: I think that is te first time in the draft that mentions the TA is in
fact the hash of it. That is fine, but maybe that could be mentioned
earlier in the introduction for example. In case that storing TA as DS is
defined somewhere a reference to that document might be useful. Otherwise,
maybe we should mention that is a common practice. What I would like to
point is that we may have to re-read the draft with that in mind.
3.4. Example Exchanges
3.4.2. Requesting Limited Domains
In this example exchange, the initiator requests INTERNAL_IP4_DNS and
INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, specifically
requesting only "example.com" and "other.com". The responder replies
with two DNS server addresses, 198.51.100.2 and 198.51.100.4, and two
domains, "example.com" and "city.other.com". Note that one of the
domains in the CFG_REPLY, "city.other.com", is a subset of the
requested domain, "other.com". This indicates that hosts within
"other.com" that are not within "city.other.com" should be resolved
using an external DNS server.
MGLT: I migth be wrong but can *.other.com stands for example.other.com as
well as example.city.other.com. If so how wildcard is handled. Maybe the
wildcard use case should be explained.
5. Split DNS Usage Guidelines
An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing
domains that are designated Special Use Domain Names in [RFC6761],
such as "local", "localhost", "invalid", etc. Although it may
explicitly wish to support some Special Use Domain Names.
MGLT: It sounds to me that deciding how to handle the .local is part of
the initiator policy. I would propose something around.
Handling domains that are designated Special Use Domain Names in
[RFC6761], such as "local", "localhost", "invalid", etc. with the
INTERNAL_DNS_DOMAIN is part of the initiator's policy. Unless the initiator
explicitly wish to support some Special Use Domain Names, it SHOULD ignore
INTERNAL_DNS_DOMAIN attributes containing Special Use Domain Names.
I think there is a "dommain" somewhere in the text....
On Mon, Oct 17, 2016 at 6:33 PM, Tommy Pauly <tpa...@apple.com> wrote:
> Hello,
>
> I’d like to see if there were any further comments on this draft. We
> incorporated the feedback we got from Paul H, Tero, and Daniel—can you
> review the recent version and see if the changes look good?
>
> Thanks,
> Tommy
>
>
> On Sep 21, 2016, at 2:23 PM, Tommy Pauly <tpa...@apple.com> wrote:
>
> Hello all,
>
> We've posted a new version of draft-pauly-ipsecme-split-dns (
> https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02).
>
> The changes in this version include:
>
> - Textual clarification based on input from Daniel and Tero
> - Clarification of DNSSEC payload types
> - Update on the content and structure of the INTERNAL_DNSSEC_TA attribute
> - How to associate DNSSEC values with specific domains
> - Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS)
>
> We believe this should be ready for adoption and moving forward, to follow
> the charter. Please review and provide your input!
>
> Thanks,
> Tommy
>
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **New Version Notification for
> draft-pauly-ipsecme-split-dns-02.txt*
> *Date: *September 21, 2016 at 1:27:23 PM PDT
> *To: *Tommy Pauly <tpa...@apple.com>, Paul Wouters <pwout...@redhat.com>
>
>
> A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
>
> Name: draft-pauly-ipsecme-split-dns
> Revision: 02
> Title: Split DNS Configuration for IKEv2
> Document date: 2016-09-21
> Group: Individual Submission
> Pages: 12
> URL: https://www.ietf.org/internet-drafts/draft-
> pauly-ipsecme-split-dns-02.txt
> Status: https://datatracker.ietf.org/doc/draft-pauly-
> ipsecme-split-dns/
> Htmlized: https://tools.ietf.org/html/draft-pauly-ipsecme-
> split-dns-02
> Diff: https://www.ietf.org/rfcdiff?url2=draft-pauly-
> ipsecme-split-dns-02
>
> Abstract:
> This document defines two Configuration Payload Attribute Types for
> the IKEv2 protocol that add support for private DNS domains. These
> domains should be resolved using DNS servers reachable through an
> IPsec connection, while leaving all other DNS resolution unchanged.
> This approach of resolving a subset of domains using non-public DNS
> servers is referred to as "Split DNS".
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
