Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
On 31 May 2012, at 22:51, Joseph Gersch wrote: Ray and Ondrej, Dan Massey and I have been busy putting together a presentation for NANOG which is in Vancouver next week. We plan on having many discussions with operators and designers there. After we get enough feedback, we will get back to you. I know this is later than you wanted, but we want to get good discussion first. Joe, Firstly thanks for getting back to me. I think there is still a serious design flaw which in practise will make the scheme unusable for your BGP work. You explicitly call out the need for the CIDR hierarchy and DNS hierarchy to align (Coverage Authority) in §3 and §4.2 of your draft and claim that your scheme provides this, but it's easy to construct examples where that's not true. Hence my concern is that the DNS scheme you have proposed _simply doesn't work_. IMHO, it would be premature to enter into detailed discussion with the operational community until this hierarchy problem is resolved. kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
Ray and Ondrej, Dan Massey and I have been busy putting together a presentation for NANOG which is in Vancouver next week. We plan on having many discussions with operators and designers there. After we get enough feedback, we will get back to you. I know this is later than you wanted, but we want to get good discussion first. - Joe On Mar 30, 2012, at 4:19 AM, Ray Bellis wrote: On 30 Mar 2012, at 12:09, Ondřej Surý wrote: Hi Joseph, since I am not sure if you understood my point (I am not sure if I was able to understand it myself :), I am summarizing it to the mailing list. I like the direction of your work, but I miss a way how to put more stuff under the named prefix. I would like you to update RFC2317 together with your document, so the end customers don't have two distinct trees in their DNS infrastructure. +1 F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have delegate it to the customer, how do I put my PTRs in? The block owner would still have to delegate another dummy prefix with CNAMEs and you have to handle it in separate zone. BTW one more observation. Since you don't have to do any zone cuts in the binary part, why not merge them into just one label? E.g. something like 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: 192.168.64/18 is 1.0.m.168.192 but 192.168.64/24 is 64.168.192 which is not a sub-domain of the enclosing /18 representation. This way lies dragons, I think... Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop Joseph Gersch Chief Operating Officer Secure64 Software Corporation ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
Hi Joseph, since I am not sure if you understood my point (I am not sure if I was able to understand it myself :), I am summarizing it to the mailing list. I like the direction of your work, but I miss a way how to put more stuff under the named prefix. I would like you to update RFC2317 together with your document, so the end customers don't have two distinct trees in their DNS infrastructure. F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have delegate it to the customer, how do I put my PTRs in? The block owner would still have to delegate another dummy prefix with CNAMEs and you have to handle it in separate zone. BTW one more observation. Since you don't have to do any zone cuts in the binary part, why not merge them into just one label? E.g. something like 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. O. On 20. 2. 2012, at 23:33, Joseph Gersch wrote: Hello Marco, Thanks for reading and commenting on our draft. We have a couple of weeks to make corrections to draft-00 before they get frozen for the IETF meeting. We appreciate your pointing out the typos (we found the ipv6 one ourselves, oops.) and the suggestions for clarification. This draft on CIDR naming is mainly focused on proposing a simple, direct way to name CIDR addresses and eliminates the need for CNAME indirection. It can be used for a number of purposes. Regarding the intro on pre-populating the reverse-DNS... you are correct, this is a draft on CIDR naming, not on fixing that particular IPv6 issue. We will make that clarification in our next draft. The ipv6 issue might be able to be addressed with this approach, but more thought needs to be put in to it before a complete solution could be proposed. We were mentioning this issue in order to give multiple examples of the reasons why CIDR naming is a useful concept. Again, thanks, - Joe Gersch and Dan Massey On Feb 20, 2012, at 6:41 AM, Marc Lampo wrote: Hello, (sorry – previously sent email was not finished …) Some “typographic” remarks : 1) 5.2 IPv4 Address Block Naming → IPv6 Address Block Naming 2) In 5.2 there are 2 examples that have missing “::”, (2607:fa88:8000:/33 → 2607:fa88:8000::/33 and 2607:fa88:8000:/35 → 2607:fa88:8000::/35) in 5.3 there is 1 example with missing “::”. (2607:fa88:8000:/36 → 2607:fa88:8000::/36) About “content” : 1) 3. Design Requirement → 2. Coverage Authority. “Any … with a data record or NXDOMAIN …” to be completed with : NODATA → “Any … with a data record or NODATA or NXDOMAIN …” 2) In 5.2 IPv6 Address Block Naming Why not add some examples to show conversion from a reverse-DNS name back to CIDR ? (just like in 5.1) Globally : 1) It is implied by the content of the present draft, but should it be stated (in Design Requirements) that the proposal should be valid for both IPv4 and IPv6 addresses ? 2) In the Introduction, where you correctly state that ISP’s pre-populate reverse DNS, the problem is stated that the approach of pre-populating does not scale for IPv6. However, by itself, this draft does not solve that problem, does it ? (needs programmatic support) (this example in the Introduction made me think/assume that this draft also applies to “simple” reverse mapping. In which case I wondered how this draft does away with CNAME (a la RFC 2317). But then, after rereading it occurred to me that this draft is about storing CIDR info in revdns. → isn’t it confusing to give, in the intro, an example that does not apply to CIDR info ? (it got at least me confused, not that I’d want to be taken as a reference ;-) Kind regards, Marc Lampo Security Officer EURid From: Joseph Gersch [mailto:joe.ger...@secure64.com] Sent: 17 February 2012 06:17 PM To: dnsop@ietf.org Subject: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt All, we have submitted a new draft that will be presented at the Paris IETF meeting. Please take the time to send any comments and suggestions regarding this idea on naming CIDR address blocks in the Reverse DNS. Best regards, - Joe Gersch and Dan Massey Begin forwarded message: From: internet-dra...@ietf.org Date: February 16, 2012 5:09:18 PM MST To: joe.ger...@secure64.com Cc: joe.ger...@secure64.com, mas...@cs.colostate.edu Subject: New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt A new version of I-D, draft-gersch-dnsop-revdns-cidr-00.txt has been successfully submitted by Joe Gersch and posted to the IETF repository. Filename: draft-gersch-dnsop-revdns-cidr Revision: 00 Title:Reverse DNS Naming Convention for CIDR Address Blocks Creation date:2012-02-14 WG ID:Individual Submission Number of pages: 19 Abstract: The current reverse DNS naming method is used to specify a complete IP address. It has not been used to handle
Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
On 30 Mar 2012, at 12:09, Ondřej Surý wrote: Hi Joseph, since I am not sure if you understood my point (I am not sure if I was able to understand it myself :), I am summarizing it to the mailing list. I like the direction of your work, but I miss a way how to put more stuff under the named prefix. I would like you to update RFC2317 together with your document, so the end customers don't have two distinct trees in their DNS infrastructure. +1 F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have delegate it to the customer, how do I put my PTRs in? The block owner would still have to delegate another dummy prefix with CNAMEs and you have to handle it in separate zone. BTW one more observation. Since you don't have to do any zone cuts in the binary part, why not merge them into just one label? E.g. something like 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: 192.168.64/18 is 1.0.m.168.192 but 192.168.64/24 is 64.168.192 which is not a sub-domain of the enclosing /18 representation. This way lies dragons, I think... Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
On Fri, Mar 30, 2012 at 10:19:43AM +, Ray Bellis wrote: On 30 Mar 2012, at 12:09, Ond??ej Surý wrote: Hi Joseph, since I am not sure if you understood my point (I am not sure if I was able to understand it myself :), I am summarizing it to the mailing list. I like the direction of your work, but I miss a way how to put more stuff under the named prefix. I would like you to update RFC2317 together with your document, so the end customers don't have two distinct trees in their DNS infrastructure. +1 I'm not quite sure 2317 can be used for shorter prefixes but it's actually only seen in the wild for /25 onwards. The proposed idea works for any prefix outside the 8 or 4 bit boundary depending on what family we are talking. F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have delegate it to the customer, how do I put my PTRs in? The block owner would still have to delegate another dummy prefix with CNAMEs and you have to handle it in separate zone. BTW one more observation. Since you don't have to do any zone cuts in the binary part, why not merge them into just one label? E.g. something like 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: 192.168.64/18 is 1.0.m.168.192 but 192.168.64/24 is 64.168.192 which is not a sub-domain of the enclosing /18 representation. This way lies dragons, I think... If your parent have't made their mind I agree with you, but this is very unlekely. Ray Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
On 3/30/2012 10:19 AM, Ray Bellis wrote: With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: 192.168.64/18 is 1.0.m.168.192 but 192.168.64/24 is 64.168.192 which is not a sub-domain of the enclosing /18 representation. This way lies dragons, I think... +1. thus my earlier observation: RFC 1101 supports classless networks even though it didn't mean to. RFC 2317 is entirely compatible with RFC 1101 (there's only one delegation tree covering both.) if there's a need for a new netblock-specific DNS schema like the one in the gersch draft, then i recommend learning from what we did in RPZ, where the prefix size is _always_ given as are all octets of the mantissa except the :: longest-zero string which is given as .zz.. more information about RPZ can be had from: https://deepthought.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html and specifically from: https://deepthought.isc.org/article/AA-00512/0 which has the actual spec, in .txt and .pdf format. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
