RE: IPv6 automatic reverse DNS
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of White, Andrew
There are two competing drafts for synthetic rule-based PTR responses for IPv6 rDNS:
Howard Lee, Time Warner Cable (now Charter) https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
J. Woodworth, CenturyLink https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
Nominum and Xerocole/Akamai also have proprietary solutions to this in their Vantio AuthServ and AuthX products, respectively.
It seems to me that it is still an open question whether the recommendations in RFC-1912 that any IP address that accesses the Internet should have a PTR and matching forward record. My personal thoughts are that the best solution would be an OPTIONAL standards-based method of generating DNS responses based on a ruleset if a specific zone record is not present, and that implementation of that requirement should be left to the developers of the auth nameserver software.
Greetings Andrew, I am new to the group but one of the authors referenced above. My colleagues and I are glad to see the discussion around this issue see some recent movement. As indicated by one of our esteemed WG chairs elsewhere in this thread, I am currently working to provide additional clarity for some of the more difficult concepts in the draft and have not yet requested the next step. Once these changes are complete we will enthusiastically move forward with this request. As I am new to this forum, for the moment I wanted to simply state: synthesized records based on the proposed "bulk rr" method can _only_exist_where_zone_records_do_not_already_. One critical goal of the draft is to make the "intent" of synthesized records easy to transfer between nameservers in authoritative roles. Examples for implementing the draft using fairly straightforward regex manipulation are included but are more of a guideline for making the pattern substitution easier for the implementor and provide a reference for the accompanying examples. Ultimately, as you recommend, the auth nameserver software vendor would be free to provide their own pattern substitution logic (so long as the intent is not lost). DNSSEC for synthesized records also poses its own obvious set of… complications for which we've outlined a number of solutions to help satisfy this challenge. Admittedly, it is a bit of a hefty read but we would love the feedback (directly or in the IETF DNSOP mailing list of course). Thanks, John Woodworth
Andrew
Caveat: These thoughts are mine personally and do not represent any official position of Charter Communications.
Ληdrеw Whiте Charter Network Operations - DAS DNS Desk: 314-394-9594 ? Cell: 314-452-4386 andrew.white2@charter.com
-- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
Hi John, Thanks for the info and background. One operational suggestion I have is … why link synthesis rules to a specific DNS zone? Most larger operators of auth DNS use an IP management tool, like BT Diamond IPAM, BlueCat, or Infoblox. Oftentimes, allocations of IP space will not be on classful boundaries, yet most often reverse DNS zones are on classful boundaries. What may be more operationally useful would be an (optional) feature in auth DNS software that would process an incoming PTR request as follows: 1. Answer the PTR with an entry in the corresponding ip6.arpa or in-addr.arpa zone file if the PTR exists 2. Otherwise, examine a rule set of synthetic PTR responses and answer by the rule set (e.g. 10.0.0.128 matches rule for “10.0.0.128/27” and returns PTR of 10-0-0-128.dhcp.example.com.) 3. Otherwise, return NXDOMAIN or NOANSWER/NOERROR as appropriate Such a ruleset could apply to forward zones as well to create the matching forward lookup. Just my two cents! Caveat: personal opinion and not the official position of Charter. Andrew Ληdrеw Whiте Charter Network Operations - DAS DNS Desk: 314-394-9594 - Cell: 314-452-4386 andrew.white2@charter.com<mailto:andrew.white2@charter.com> From: Woodworth, John R [mailto:John.Woodworth@CenturyLink.com] Sent: Monday, October 31, 2016 11:04 PM To: White, Andrew; 'nanog@nanog.org' Cc: Ballew, Dean; Woodworth, John R Subject: RE: IPv6 automatic reverse DNS -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of White, Andrew
There are two competing drafts for synthetic rule-based PTR responses for IPv6 rDNS:
Howard Lee, Time Warner Cable (now Charter) https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
J. Woodworth, CenturyLink https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
Nominum and Xerocole/Akamai also have proprietary solutions to this in their Vantio AuthServ and AuthX products, respectively.
It seems to me that it is still an open question whether the recommendations in RFC-1912 that any IP address that accesses the Internet should have a PTR and matching forward record. My personal thoughts are that the best solution would be an OPTIONAL standards-based method of generating DNS responses based on a ruleset if a specific zone record is not present, and that implementation of that requirement should be left to the developers of the auth nameserver software.
Greetings Andrew, I am new to the group but one of the authors referenced above. My colleagues and I are glad to see the discussion around this issue see some recent movement. As indicated by one of our esteemed WG chairs elsewhere in this thread, I am currently working to provide additional clarity for some of the more difficult concepts in the draft and have not yet requested the next step. Once these changes are complete we will enthusiastically move forward with this request. As I am new to this forum, for the moment I wanted to simply state: synthesized records based on the proposed "bulk rr" method can _only_exist_where_zone_records_do_not_already_. One critical goal of the draft is to make the "intent" of synthesized records easy to transfer between nameservers in authoritative roles. Examples for implementing the draft using fairly straightforward regex manipulation are included but are more of a guideline for making the pattern substitution easier for the implementor and provide a reference for the accompanying examples. Ultimately, as you recommend, the auth nameserver software vendor would be free to provide their own pattern substitution logic (so long as the intent is not lost). DNSSEC for synthesized records also poses its own obvious set of… complications for which we've outlined a number of solutions to help satisfy this challenge. Admittedly, it is a bit of a hefty read but we would love the feedback (directly or in the IETF DNSOP mailing list of course). Thanks, John Woodworth
Andrew
Caveat: These thoughts are mine personally and do not represent any official position of Charter Communications.
Ληdrеw Whiте Charter Network Operations - DAS DNS Desk: 314-394-9594 ? Cell: 314-452-4386 andrew.white2@charter.com<mailto:andrew.white2@charter.com>
-- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
Hi John,
Thanks for the info and background.
One operational suggestion I have is … why link synthesis rules to a specific DNS zone?
Most larger operators of auth DNS use an IP management tool, like BT Diamond IPAM, BlueCat, or Infoblox. Oftentimes, allocations of IP space will not be on classful boundaries, yet most often reverse DNS zones are on classful boundaries.
What may be more operationally useful would be an (optional) feature in auth DNS software that would process an incoming PTR request as follows:
1. Answer the PTR with an entry in the corresponding ip6.arpa or in-addr.arpa zone file if the PTR exists 2. Otherwise, examine a rule set of synthetic PTR responses and answer by the rule set (e.g. 10.0.0.128 matches rule for “10.0.0.128/27” and returns PTR of 10-0-0-128.dhcp.example.com.) 3. Otherwise, return NXDOMAIN or NOANSWER/NOERROR as appropriate
Such a ruleset could apply to forward zones as well to create the matching forward lookup. Just my two cents! Caveat: personal opinion and not the official position of Charter.
Andrew, Excellent question. Out of necessity we have an in-house federated solution for DNS/DHCP/IP/etc. which solves part of the problem. However, not all data can be managed this way; some more tech-savvy customers expect to manage their own data and transfer it directly to our nameservers for the higher availability, lower latency, tighter security, etc. This then becomes a shared burden at the zone level where, from our perspective, the intent should be easily transferable. I suspect if/when the draft is adopted, other IP management tools may offer the capability of automatically generating the associated "BULK" resource records for the various DNS zones allowing for better interoperability (i.e. "transferability"). One of the draft's features I am most proud of is the concept of superimposed records. This can scale to really huge levels where for example: the RIR could provide patterns for all unclaimed records under "10.in-addr.arpa." which could be overridden by more specific patterns for records under "255.0.10.in-addr.arpa." The DNS ownership now follows the intent of the expected DNS zone owner. If one follows this logic through the ipv6 tree, this concept of ownership becomes even more pronounced. I guess in short, the answer is to maintain the concept of zone ownership :) Thanks, John Woodworth
Andrew
Ληdrеw Whiте Charter Network Operations - DAS DNS Desk: 314-394-9594 - Cell: 314-452-4386 andrew.white2@charter.com
-- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
participants (2)
-
White, Andrew -
Woodworth, John R