Hi Daniel, Thanks for the review comments! Responses inline.
Tommy > On Dec 13, 2016, at 10:46 AM, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > 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. > Sure, we can add more discussion around this to explain it. > > 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 =) Good catch! > > 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. > Okay, we can also add more discussion around this in the next update. > > 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 <http://example.com/>" and "other.com > <http://other.com/>". The responder replies > with two DNS server addresses, 198.51.100.2 and 198.51.100.4, and two > domains, "example.com <http://example.com/>" and "city.other.com > <http://city.other.com/>". Note that one of the > domains in the CFG_REPLY, "city.other.com <http://city.other.com/>", is a > subset of the > requested domain, "other.com <http://other.com/>". This indicates that > hosts within > "other.com <http://other.com/>" that are not within "city.other.com > <http://city.other.com/>" should be resolved > using an external DNS server. > > MGLT: I migth be wrong but can *.other.com <http://other.com/> stands for > example.other.com <http://example.other.com/> as well as > example.city.other.com <http://example.city.other.com/>. If so how wildcard > is handled. Maybe the wildcard use case should be explained. > We have some text in section 5 around how the segments in the domain are complete segments. This covers part of the behavior. For example, if the INTERNAL_DNS_DOMAIN attribute specifies "example.com", then "example.com", "www.example.com" and "mail.eng.example.com" MUST be resolved using the internal DNS resolver(s), but "anotherexample.com" and "ample.com" MUST be resolved using the system's external DNS resolver(s). I don't want people to be using an actual * wildcard in the protocol, though. I'll probably add a mention in the text that * does not imply a wildcard and should not be used. > > 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. That's a better wording, yes. Will change. > > I think there is a "dommain" somewhere in the text.... Quite right. Again, thanks for catching! > > > > On Mon, Oct 17, 2016 at 6:33 PM, Tommy Pauly <tpa...@apple.com > <mailto: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 >> <mailto: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 >> <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 <mailto: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 <mailto:tpa...@apple.com>>, Paul Wouters >>> <pwout...@redhat.com <mailto: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 >>> <https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt> >>> Status: >>> https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ >>> <https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/> >>> Htmlized: >>> https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 >>> <https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02> >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-pauly-ipsecme-split-dns-02 >>> <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 >>> <http://tools.ietf.org/>. >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
