Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12
Yup, Adam Roach caught that as well and the document will be updated with some new text: This section specifies considerations for systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.'. Each item in this section addresses some aspect of the DNS or the process of resolving domain names that would be affected by this special use allocation. Detailed explanations of these items can be found in , Section 5. On Wed, Aug 30, 2017 at 10:34 PM, Dale R. Worley wrote: > Ted Lemon writes: > > I've updated the document to separate this out into three lettered > > subheads. We can't change the numbering, because that's required by > > RFC 6761, but I agree that it's clearer if the three separate topics > > are split out. > > I hadn't realized from the draft that the items in section 4 are meant > to parallel the items in section 5 of RFC 6761, since the connecting > text is only "(as per [RFC 6761])". Perhaps it would help to amplify > that to "(per the template in [RFC 6761] section 5)". > > Dale > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12
Ted Lemon writes: > I've updated the document to separate this out into three lettered > subheads. We can't change the numbering, because that's required by > RFC 6761, but I agree that it's clearer if the three separate topics > are split out. I hadn't realized from the draft that the items in section 4 are meant to parallel the items in section 5 of RFC 6761, since the connecting text is only "(as per [RFC 6761])". Perhaps it would help to amplify that to "(per the template in [RFC 6761] section 5)". Dale ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12
In message <4b072264-2824-4433-a24d-df5d2fd5a...@fugue.com>, Ted Lemon writes: > El Aug 24, 2017, a les 7:20 AM, Dale Worley va > escriure: > > 4. Domain Name Reservation Considerations > > > > 3. Name resolution APIs MUST send queries for such > > names to a recursive DNS server that is configured to be > > authoritative for the 'home.arpa.' zone appropriate to the > > homenet. > > > > If I understand the terminology correctly, this rules out sending the > > query to a DNS server that recursively sends the query to a server > > that is authoritative for home.arpa. If that is intended and there > > are technical reasons for making this prescription, that's OK, but I > > want to check that that is intended, as this rule is stricter than the > > similar rule in the second paragraph of item 4, which is qualified > > "Unless configured otherwise". > > Wow. The text here is just flat wrong: recursive name servers aren't > authoritative. You can of course combine them, but this text doesn't > agree with some other text later in the document. What the text is > supposed to be saying is that the stub resolver has to use the recursive > resolver that was provided by the network; if it uses a manually > configured resolver, it may get the wrong answer. I will have to rework > this textâthanks so much for calling this to my attention, even though > what you noticed isn't exactly what's wrong! :) > > As for the discrepancy itself, the reason for this is that recursive > resolvers are supposed to stop home.arpa queries leaking to the root, > whereas stub resolvers can (must!) fob that responsibility off on the > recursive resolver. If they are configured to send these queries to, > e.g., 8.8.8.8, we just have to hope that google doesn't forward them to > the root (as would be consistent with the text in item 4). Or the recursive server has learnt that 8.8.8.8 is "special" and is the equivalent of the root servers in terms of keeping local traffic local. Maintaining the list of don't leak too recursive servers is a "interesting" problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12
El Aug 24, 2017, a les 7:20 AM, Dale Worley va escriure: > 4. Domain Name Reservation Considerations > > 3. Name resolution APIs MUST send queries for such > names to a recursive DNS server that is configured to be > authoritative for the 'home.arpa.' zone appropriate to the > homenet. > > If I understand the terminology correctly, this rules out sending the > query to a DNS server that recursively sends the query to a server > that is authoritative for home.arpa. If that is intended and there > are technical reasons for making this prescription, that's OK, but I > want to check that that is intended, as this rule is stricter than the > similar rule in the second paragraph of item 4, which is qualified > "Unless configured otherwise". Wow. The text here is just flat wrong: recursive name servers aren't authoritative. You can of course combine them, but this text doesn't agree with some other text later in the document. What the text is supposed to be saying is that the stub resolver has to use the recursive resolver that was provided by the network; if it uses a manually configured resolver, it may get the wrong answer. I will have to rework this text—thanks so much for calling this to my attention, even though what you noticed isn't exactly what's wrong! :) As for the discrepancy itself, the reason for this is that recursive resolvers are supposed to stop home.arpa queries leaking to the root, whereas stub resolvers can (must!) fob that responsibility off on the recursive resolver. If they are configured to send these queries to, e.g., 8.8.8.8, we just have to hope that google doesn't forward them to the root (as would be consistent with the text in item 4). > There are 5 paragraphs under item 4. It might be worth giving them > separate numbers, or if they truly form a unified topic, giving them > sub-numbers 4a, 4b, etc. I've updated the document to separate this out into three lettered subheads. We can't change the numbering, because that's required by RFC 6761, but I agree that it's clearer if the three separate topics are split out. > In context what this means is clear, but its literal meaning is > sufficiently incorrect that I think it could be clarified, perhaps to > > Therefore, the only delegation that will allow names under > 'home.arpa.' to be resolved by a validating resolver that is not > aware of the local meaning is an insecure delegation, as in > [RFC6303] section 7. I like the new text, and have copied it into the document. Thanks! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
