Hi everyone, Stuart and I have a draft that attempts to address these issues, please let us know if you think it does or doesn't.
https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa <https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa> Thanks, David Schinazi > On Jun 12, 2018, at 18:29, Mark Andrews <[email protected]> wrote: > > The Domain Name Reservation Considerations in RFC 7050 do not cover whether > a delegation should be signed or not. Due to that omission in constructing > the set > of questions to be asked RFC 7050 fails when the client is behind a > validating resolver > that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA. > > There are 2 pieces of work that are required. > 1) update the list of questions that need to be asked needs to include > whether a delegation > needs to be signed or not. > 2) update RFC 7050 to include explicit instructions to say DO NOT sign > IPV4ONLY.ARPA. > > Item 1 is dnsop work as far as I can see. Item 2, I think, should be v6ops > work. > > HOME.ARPA is a example of a unsigned delegation. > 10.IN-ADDR.ARPA is a example of a unsigned delegation. > > There is zero benefit in IPV4ONLY.ARPA being signed. Its contents on the > Internet > are well known. The contents with NAT64 in using are well known except for > the > AAAA query. The answer to that query is *expected to change*. That answer > cannot > be validated. > > Mark > >> Begin forwarded message: >> >> From: "Michelle Cotton via RT" <[email protected] >> <mailto:[email protected]>> >> Subject: [IANA #989438] ipv4only.arpa's delegation should be insecure. >> Date: 6 January 2018 at 8:45:10 am AEDT >> To: [email protected] <mailto:[email protected]> >> Reply-To: [email protected] <mailto:[email protected]> >> >> Hello, >> >> Following up on a thread from the end of the year. Who will bring this to >> the DNSOps working group? Will someone notify us if there is an consensus >> on a conclusion of what needs to be done? >> >> Thanks in advance. >> >> --Michelle Cotton >> >> >> On Sun Dec 10 22:40:29 2017, [email protected] <mailto:[email protected]> >> wrote: >>> I had replied to the errata. I agree it warrants additional >>> discussion, and had also suggested same. Dnsops seems appropriate. >>> >>> >>> >>> The question is not to much where the attacker is, but what DNSSEC >>> guarantee is provided. DNS64 imagines the client could do its own >>> validation — if it wanted. To date, effectively zero clients seem to >>> want to do their own DNSSEC validation. >>> >>> -d >>> >>>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere) >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>> Dan Wing seem to have moved to VMWare, but cc'ing him now with an >>>> email address I found from an I-D.. >>>> >>>> I'm not really following IETF nowadays, so I don't know if this has >>>> been discussed. >>>> >>>> Also I'm not sure why ISPs couldn’t first verify the A response's >>>> validity and then generate AAAA response to the client as document... >>>> but I suppose it could be considered to be more proper action to >>>> modify insecure responses than secure responses. I'm just worried >>>> what happens if there's attacker between ISP and root, in which case >>>> the IPv4 address part of the response could be modified by attacker >>>> and then delivered to client in the ISP's synthetic AAAA record.. >>>> >>>> So I cannot accept the errata straight away, but it should be >>>> discussed with people who are more experts on this than I am. >>>> >>>> Best regards, >>>> >>>> Teemu >>>> >>>> >>>> -----Original Message----- >>>> From: Michelle Cotton via RT [mailto:iana-questions- >>>> [email protected] <mailto:[email protected]>] >>>> Sent: 9. joulukuuta 2017 1:22 >>>> Cc: [email protected] <mailto:[email protected]>; >>>> [email protected] <mailto:[email protected]>; >>>> [email protected] <mailto:[email protected]>; Savolainen, Teemu >>>> (Nokia-TECH/Tampere) >>>> <[email protected] <mailto:[email protected]>> >>>> Subject: [IANA #989438] ipv4only.arpa's delegation should be >>>> insecure. >>>> >>>> Hello, >>>> >>>> Just checking to see if anyone had a chance to look at this. >>>> Dan Wing's email addressed bounced ([email protected] >>>> <mailto:[email protected]>). >>>> >>>> Thanks, >>>> Michelle >>>> >>>> >>>> >>>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote: >>>>> Hello Authors and Area Directors, >>>>> >>>>> We have received a message pointing out an errata report that would >>>>> modify the actions that were performed for RFC7050. >>>>> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-> >>>>> 2Deditor.org_errata_eid5152&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=hjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=uCKCSggUUCCU7iPuRs- >>>>> usGcL3T69Fia9gTOy4UQwhLk&e= >>>>> >>>>> Has this report been discussed? Will the result be an approved >>>>> errata >>>>> report or a new RFC? >>>>> >>>>> Thanks in advance. >>>>> >>>>> Michelle Cotton >>>>> Protocol Parameters Engagement Sr. Manager >>>> >>>> >>>> >> >> >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > <mailto:[email protected]> > _______________________________________________ > v6ops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
