- rssac-caucus - lists.icann.org

Re: [RSSAC Caucus] [Non-DoD Source] Re: Work Party [Rogue RSO]: Thoughts on a definition of "Rogue Operator"
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 11, 2020

May 11, 2020

I like this approach, and I think your list is comprehensive. Comments here do not provide clarity, but maybe more questions for discussion. For cases 1, 2 [7706-style or non-IANA configuration of a recursive]: As an Internet user, am I misplacing trust in my recursive resolver (or DHCP response) ? There is no agreement (that I know of) between a user and an ISP that defines the accuracy requirements for DNS service. We know that deception (resolving non-existent domains to web advertisements) has been practiced by ISPs. Again, we have a tough problem of discerning a mistake from an intentional act. For the cases 3, 4, and 6: [route hijack, on-path attacker, off-path attacker] : Should we consider these improper, even if the response is correct? That sure would be hard to detect. With an incorrect response, I certainly feel this is improper. For a correct response, I still feel it is improper, but more-so from the traffic tampering perspective. For case 5: [incorrect from an RSO]: This definitely falls in to the 'improper' category, but is it intentional incorrectness? Old data (beyond grace period) would fall in to this category. Is there something that can discern a temporary mistake versus an intentional act? Thanks, Duane! Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr(a)mail.mil On 5/5/20, 7:36 PM, "Wessels, Duane" <dwessels(a)verisign.com> wrote: All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ---- Thanks for starting the discussion Ken. I've been looking at this at doodling on paper and sort of come to the conclusion that we should not be focusing on the *types* of rogue/fake/bad operators, but rather on the various ways that a DNS client can get anything other than a correct response from an IANA recognized root server. I apologize in advance if this takes us in the wrong direction, but it feels right to me so I figured I'd share it. Thinking about a DNS query from a recursive resolver (client) to a root server, a number of things can happen that prevents it from getting correct response from a real root server: 1) The recursive resolver might be configured for RFC7706-style operation, which is to say that the query is answered locally, without leaving the recursive resolver itself or the local network. I'm not saying this is bad/wrong, but we may want to describe the risks around it. 2) Does the recursive resolver have non-IANA root NS RRset and associated addresses? This is like your "non-sanctioned operator" case, and also like the Yeti DNS project. In this case queries do not (always) reach real RSOs. Probably two sub-cases here where one is opt-in/intentional and the other is not. 3) Route hijacks. Even though a DNS query has a proper RSO destination IP address, it may be routed to another entity. I would include here both BGP hijacks and static routes to serve RSO addresses locally, which is also covered in your non-sanctioned operator case. 4) On-path attacker. Although the query is on its way towards a proper RSO, an on-path device or attacker may interfere. Think "great firewall" style. 5) Incorrect or unexpected data served by an RSO. The query was delivered to a proper RSO, but the response was incorrect somehow, either due to compromise, software bug, misconfiguration, or intentional interference. We've seen an example of a software bug like this just recently. A long time ago (probably 2008?) I remember there was a root server that was serving "localhost," I'm guessing because about that time it came as part of the default BIND configuration. 6) Off-path attacker? Not sure this is in scope, but perhaps. Of all these different possibilities, I think the likelihood that a client gets bad data because of an RSO's intentional actions is quite low. Nonetheless we could describe these various scenarios and the extent that mitigations are needed and effective. DW > On May 5, 2020, at 1:11 PM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus <rssac-caucus(a)icann.org> wrote: > > Throwing out some ideas on terminology for the rogue operator work party. Please feel free to share your thoughts on these. > > -Ken > > > Non-sanctioned Operator: This could be an enterprise that serves the root zone [possibly with modifications] to its internal users, fully within their authority. This purposefully avoids the term "rogue" and its negative implications. This could be done via recursive resolvers configuring non-standard root servers, or by impersonating RSO address space only within the domain of their authority. Do we need a separate term for cases where they do this outside of their authority? > > Impersonating Operator: An authoritative server, serving the Root Zone publicly, that is run by someone other than the 12 Root Server Organizations, responding to one or more the 26 root server addresses. These organizations do not necessarily uphold the guiding principles of the root server operators. Correctness of the served zone is irrelevant? This also purposefully avoids the term "rogue" and its negative implications. (Impersonating Operator, Imposter Operator, Fake Operator, … word-smithing encouraged) > > Rogue Operator: A legitimate Root Server Operator that decided to do "bad things". A starting point for defining "bad things" would be a violation of some set of the 11 principals defined in Section 3 of RSSAC037. Specifically: > > • Guiding Principal #2: IANA is the source of DNS root data -- If an RSO serves a non-IANA root zone or a modified IANA root zone, they are in violation of this principal > • Guiding Principal #6: The IETF defines technical operation of the DNS -- If an RSO does not support the protocols as defined by the IETF, they are in violation of this principal. Serving protocols in addition to IETF protocols should not be considered in violation (flame away, here) > • Guiding Principal #7: RSOs must operate with integrity and an ethos demonstrating a commitment to the common good of the Internet -- this one is pretty open-ended. > • Guiding Principal #11: RSOs must be neutral and impartial -- serving data with intentional bias of query source/content (e.g. serving slow or incorrect data to market competitors or governments) Lots of room for discussion here > • More ideas welcome > > > There could be more definitions and we can certainly refine these. > > > Ken Renard > S&TCD Contractor – ICF > Sustaining Base Network Assurance Branch > C5ISR Center, Space and Terrestrial Communications Directorate > Office: 443-395-7809 > kenneth.d.renard.ctr(a)mail.mil > > _______________________________________________ > rssac-caucus mailing list > rssac-caucus(a)icann.org > Caution-https://secure-web.cisco.com/1exAFAzXHjmETsRjUrrDmy0r0Cv7oMt1WXxIx4… > > _______________________________________________ > By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (Caution-https://secure-web.cisco.com/1aef_Y0-7xwmr_Q-eoPH1VxGyE_5wLxRL-oQkh…) and the website Terms of Service (Caution-https://secure-web.cisco.com/17fOdMyxlceIQHihFHIvLaUBKkF7_CDaE2Qv8M…) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

2 1

Fwd: OARC Online 32a Workshop, June 9th, Call for contributions
by Joe Abley May 7, 2020

May 7, 2020

[forwarded by request --jabley] Hi all, OARC is hosting an online meeting on June 9th, 17:00-19:00 UTC. The Programme Committee are seeking contributions from the community. All DNS-related subjects are welcome, but we're particularly interested in content which is timely and operationally relevant in light of the COVID-19 pandemic. Suggestions for discussion topics would also be good. As the session is limited to 2 hours we'd like to encourage brevity, presentations ought to be no longer than 20 minutes, not including time for questions. Subject areas we are looking for include the following, but not limited to: * data on traffic growthx * operational scaling and availability challenges * infrastructure and skills bottlenecks * supply chain challenges * personnel & infrastructure protection * security/disinformation threats, public education * ideas that are helping * lessons learned * information from official channels * universal access inequities **Workshop Milestones:** * 7 May 2020 - Submissions open via Indico * 21 May 2020 - Deadline for submission (23:59 UTC) * 28 May 2020 - Initial Contribution list published * 02 Jun 2020 - Full agenda published * 04 Jun 2020 - Deadline for slideset submission * 09 Jun 2020 - OARC (online) 32a Workshop Details for presentation submission are published at: <https://www.dns-oarc.net/oarc32a> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARC (online) 32a: * your talk will be live broadcast and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Dave Knight, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.

1 0

RSSAC Meeting Minutes | 7 April 2020 Meeting
by Ozan Sahin May 6, 2020

May 6, 2020

Dear RSSAC Caucus Members, The meeting minutes from 7 April 2020 RSSAC Meeting have been approved during the RSSAC Meeting on Tuesday, 5 May 2020. The meeting minutes have been posted on the RSSAC Meetings page https://www.icann.org/resources/pages/rssac-meetings-2014-05-06-en. You may also find the meeting minutes attached to this note. Best, Ozan Sahin Policy Specialist Internet Corporation for Assigned Names and Numbers (ICANN) Telephone: +90 212 999 6218 Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org<applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org>

1 0

Work Party [Rogue RSO]: Thoughts on a definition of "Rogue Operator"
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 5, 2020

May 5, 2020

Throwing out some ideas on terminology for the rogue operator work party. Please feel free to share your thoughts on these. -Ken Non-sanctioned Operator: This could be an enterprise that serves the root zone [possibly with modifications] to its internal users, fully within their authority. This purposefully avoids the term "rogue" and its negative implications. This could be done via recursive resolvers configuring non-standard root servers, or by impersonating RSO address space only within the domain of their authority. Do we need a separate term for cases where they do this outside of their authority? Impersonating Operator: An authoritative server, serving the Root Zone publicly, that is run by someone other than the 12 Root Server Organizations, responding to one or more the 26 root server addresses. These organizations do not necessarily uphold the guiding principles of the root server operators. Correctness of the served zone is irrelevant? This also purposefully avoids the term "rogue" and its negative implications. (Impersonating Operator, Imposter Operator, Fake Operator, … word-smithing encouraged) Rogue Operator: A legitimate Root Server Operator that decided to do "bad things". A starting point for defining "bad things" would be a violation of some set of the 11 principals defined in Section 3 of RSSAC037. Specifically: Guiding Principal #2: IANA is the source of DNS root data -- If an RSO serves a non-IANA root zone or a modified IANA root zone, they are in violation of this principal Guiding Principal #6: The IETF defines technical operation of the DNS -- If an RSO does not support the protocols as defined by the IETF, they are in violation of this principal. Serving protocols in addition to IETF protocols should not be considered in violation (flame away, here) Guiding Principal #7: RSOs must operate with integrity and an ethos demonstrating a commitment to the common good of the Internet -- this one is pretty open-ended. Guiding Principal #11: RSOs must be neutral and impartial -- serving data with intentional bias of query source/content (e.g. serving slow or incorrect data to market competitors or governments) Lots of room for discussion here More ideas welcome There could be more definitions and we can certainly refine these. Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr(a)mail.mil

2 1

Study of the root zone management process
by Paul Hoffman May 5, 2020

May 5, 2020

Greetings. Recently, ICANN put out a request for proposals (RFP) for a study on the process that is used to manage the root zone. Please see: https://www.icann.org/news/announcement-2020-04-28-en Note that this study is part of the IANA transition; it was recommended by the group that created the transition process. I bring this up here because some of you might know people or organizations who are qualified to perform the study. If so, please pass this information to them. --Paul Hoffman

1 0

Re: [RSSAC Caucus] [Ext] TCP and TC (was Updating the RSSAC FAQ)
by Fred Baker May 5, 2020

May 5, 2020

Sending again using the right email address. > On May 4, 2020, at 9:01 AM, Fred Baker <fredbakersba(a)gmail.com> wrote: > > Stepping aside a bit from the question of the FAQ... Yes, this is a change of subject, which is why I changed the subject line. > > Does this become a requirement for resolvers using the RSS? RFCs 1034/1035 only hint at it (they define the bit without defining its use case). If, however, I look at RFC 2181, it says > > Where TC is set, the partial RRSet that would not completely fit may > be left in the response. When a DNS client receives a reply with TC > set, it should ignore that response, and query again, using a > mechanism, such as a TCP connection, that will permit larger replies. > > In the absence of any other alternative that reliably works (Geoff will argue from his data that IP fragmentation and reassembly is not a mechanism that works reliably to transport larger replies, and protocols like SCTP and QUIC are not generally used to communicate with the RSS), that reads to me as "responding with TC set means 'please ask again using TCP'". > > The interface between a host and its resolver is another question; I would argue wants gets the same answer, but that's perhaps secondary to a conversation about the RSS. > > So, is it reasonable to say that the ability to pose a DNS request and receive a response using TCP, and using TCP as the fallback transport when TC is invoked, is a requirement of a modern resolver? > >> On May 4, 2020, at 1:44 AM, Andrew McConachie <andrew.mcconachie(a)icann.org> wrote: >>> On May 1, 2020, at 22:22, Geoff Huston <gih(a)apnic.net> wrote: >>>> On 2 May 2020, at 1:25 am, Dave Lawrence <tale(a)dd.org> wrote: >>>> Geoff Huston writes: >>>>> "Finally, many more resolvers today are capable of falling back to >>>>> TCP when they receive a truncated response over UDP” >>>>> >>>>> really? Where is the study that publishes this finding? >>>> >>>> It could use clarification, certainly, beyond just the fuzziness of >>>> "many more". There are several metrics which could all claim to be >>>> relevant. A few of them seem like they are probably true in raw >>>> numbers if only because of overall growth over the past couple of >>>> decades (and yes, good measurement would confirm that). Like: >>>> >>>> * Total number of implementations >>>> * Total number of running servers >>>> * Total number of people served (not strictly a resolver, but still relevant) >>>> >>>> But, maybe that picture changes when you ask about the percent of the >>>> whole, and then "many more" might not apply. >>>> >>>> Measurement rules, for sure. I also don't think it is entirely out of >>>> place to make a qualified claim based on our cumulative anecdotal >>>> experience that overall the TCP fallback scenario is improved now vs >>>> the past, as long as it clear that it is supposition rather than data. >>>> >>> >>> My measurements of TCP use from time to time report that the relative number of >>> users that sit behind recursive resolvers that cannot perform TCP appear >>> to be unchanged for the 6 years that I’ve looked (from time tim time). Now >>> there are many ways of reporting DNS (resolvers, users, queries, … as well as >>> absolute numbers or relative numbers). >>> >>> Therefore I don't understand the basis of the TCP claim in that report - it seems >>> apocryphal to me >> >> I’ve deleted that sentence from the answer to question 1. The answer no longer makes any statements regarding how many resolvers can fallback to TCP if UDP comes back truncated. >> >> —Andrew >> >> _______________________________________________ >> rssac-caucus mailing list >> rssac-caucus(a)icann.org >> https://mm.icann.org/mailman/listinfo/rssac-caucus >> >> _______________________________________________ >> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. >

6 6

Work Party [Rogue RSO]: Summary of kickoff meeting
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 4, 2020

May 4, 2020

Summary The "Rogue Operator" Work party held its kickoff meeting on Friday, 1 May 2020. Participation was good with approximately 20 people. With only mild interest in volunteering for the role of Work Party Leader, it was decided to postpone the selection of a leader until the next meeting, allowing participants to learn more about the topic. The Statement of Work was presented and a few topics were discussed among the group. For future meetings, a doodle poll will be initiated to determine one or two standing times for monthly calls. Plans to hold a work party meeting as part of the ICANN 68 (Kuala Lumpur, virtual) meeting were dismissed as the work party preferred to decide on a time slot on their own versus being tied to local time in KL. Action Items 1. Staff will conduct a poll to determine a standing meeting time for monthly calls 2. Work Party members are encouraged to volunteer to act as work party leader 3. Work Party members are encouraged to continue discussions on the RSSAC Caucus mail list on new or existing topics related to this work party. 4. Ken Renard and staff will send out meeting summary to RSSAC Caucus mail list Topics discussed A good definition of “rogue” The original use of the term "rogue" came from RSSAC037 in reference to how an existing Root Server Operator could be removed from its duty. There are negative connotations of the term rogue (in US English), but the term seems to be fitting as long as we can define what it means in the perspective of an RSO. Some of the scenarios discussed were: "Unexpected behavior" Serving anything other than the true IANA root zone to users outside of your organization/scope-of-authority. This means that enterprises who extend the root zone _only_ for their internal users would _not_ be considered rogue. If such an enterprise serves users outside of their authority, then that would be considered rogue Restricting the term "rogue" to only legitimate RSOs versus non-RSOs acting as an RSO (answering queries on one or more of the 26 ‘official’ addresses) "Intention" - while the intention to deceive is an obvious indication of a rogue operator (or server), it is not up to this WP to determine intention. Organization / Government roles There may be cases where an organization or government requires (by law?) that the root zone must be modified. These are outside the scope of our determination of "rogue-ness" and are not true RSOs (what if they are responding on RSO IP addresses?) Are these "fake" instances (use term other than "rogue"). Other potential terms: "non-IANA", "non-standard", "non-sanctioned" RSOs serving zones other than '.', '.arpa', or '.root-servers.net’ It was brought up that some RSOs may serve zones other than these 3 on their Root Server IP addresses. This should not lead to any change in the root zone information served, but it could mean that some root servers return different results to the same query (such as additional records). A follow-on email from Wes indicated that no RSOs are actually doing this now. This might be an interesting hypothetical discussion for root ops. Agenda topics for next meeting Select a work party leader Document examples of changing the root zone that could cause problems Discussion of scenarios that would be considered rogue RSO-gone-bad (example, serving incorrect zone data) Non-sanctioned RSO (a recursive resolver that uses an alternate root server list) Practicality of detection strategies Discussion of damage that could be done by a rogue operator Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr(a)mail.mil

1 0

Work Party [Tool for Local Perspective]: Summary of kickoff meeting
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 4, 2020

May 4, 2020

Summary The "Local Perspective" Work party held its kickoff meeting on Thursday, 30 April 2020. Participation was good with approximately 20 people. There was interest in volunteering for the role of Work Party Leader, however, it was decided to postpone the selection of a leader until the next meeting, allowing participants to learn more about the topic. The Statement of Work was presented and a few topics were discussed among the group. For future meetings, a doodle poll will be initiated to determine one or two standing times for monthly calls. Plans to hold a work party meeting as part of the ICANN 68 (Kuala Lumpur, virtual) meeting were dismissed as the work party preferred to decide on a time slot on their own versus being tied to local time in KL. Action Items 1. Staff will conduct a poll to determine a standing meeting time for monthly calls 2. Work Party members are encouraged to volunteer to act as work party leader 3. Work Party members are encouraged to continue discussions on the RSSAC Caucus mail list on new or existing topics related to this work party. 4. Ken Renard and staff will send out meeting summary to RSSAC Caucus mail list Topics discussed Limiting scope Duane brought up the point that the work party might be attempting too much to come to a successful conclusion. While implementations of a full set of tools and a data collection infrastructure would be nice to have, these seem like goals that can be put off for future work. The work party should concentrate on defining metrics to achieve the goals of the intended audience. Other research Jaap contributed that CAIDA has been conducting similar research to date and we should reference that work and leverage its results as appropriate. A reference to any publications from this work would be useful for the group] Purpose of this work The purpose of this work is broken in to 2 categories: advising the RSS on placement of new instances and giving the end-user a measurement of their perspective of the RSS. Advising the RSS can only be successful if there are a large and "well-distributed" set of measurements. Measurement of endpoint to RSS versus via configured resolver The work party had a discussion on the desire for a tool to measure direct perspective of the RSS versus measuring perspective via a configured recursive resolver. The tool(s) may be run on a wide variety of platforms such as mobile devices, desktop hosts, data center servers, enterprise recursive resolvers, etc. Direct measurement to the RSS would be interesting for potential placement of new RSS instances, but location of the measurement (such as mobile endpoints) need to be considered. Measurement via the configured recursive resolver would be useful for anyone to get a perspective of their enterprise/ISP configuration. Agenda topics for next meeting Select a work party leader Enumerate end-user use cases: Researcher/curious user in a University or Enterprise network Enterprise IT staff (recursive resolver operators) Topologically-remote network. Well-connected data centers (Google/CloudFlare) good for comparison? Home users (testing ISP versus public DNS perspective of root) RSOs Discussion of CAIDA research What set of measurements would be useful for testing perspective directly to RSS? Let's get an initial list to ground general thoughts on the set. We will revisit this periodically. Local IP (ASN), geo-location?, RSS RTT (v4/v6/udp/tcp), RTT to first-hop router, RTT to well-known Internet infrastructure, traceroutes to RSS What set of measurements would be useful for testing perspective of the RSS via the local resolver? Let's get an initial list to ground general thoughts on the set. We will revisit this periodically. IP (ASN) of RR, RTT to RR, RSS RTT (v4/v6/udp/tcp), RTT to first-hop router, RTT to well-known Internet infrastructure, traceroute (from where?) Compare RTT for cache miss versus cache hit Compare RTT of configured RR versus well-established resolver (google/cloudflare/etc) Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr(a)mail.mil

1 0

Re: [RSSAC Caucus] Updating the RSSAC FAQ
by Geoff Huston May 2, 2020

May 2, 2020

What's not clear to me Fred is whether “many MORE” resolvers today are capable of falling back to TCP. > On 2 May 2020, at 9:20 am, Fred Baker <fredbakersba(a)gmail.com> wrote: > > Question: I understood the statement to be that *resolvers* could fall back to TCP, not that the universe behind solvers could. Which is it? > >> On May 1, 2020, at 1:22 PM, Geoff Huston <gih(a)apnic.net> wrote: >> >> >> >>> On 2 May 2020, at 1:25 am, Dave Lawrence <tale(a)dd.org> wrote: >>> >>> Geoff Huston writes: >>>> "Finally, many more resolvers today are capable of falling back to >>>> TCP when they receive a truncated response over UDP” >>>> >>>> really? Where is the study that publishes this finding? >>>

2 1

Re: [RSSAC Caucus] Checking whether current RSOs are authoritative for TLDs: nope
by Wessels, Duane May 1, 2020

May 1, 2020

> On May 1, 2020, at 12:04 PM, Fred Baker <fredbakersba(a)gmail.com> wrote: > > > >> On May 1, 2020, at 9:18 AM, Wessels, Duane via rssac-caucus <rssac-caucus(a)icann.org> wrote: >> >> Thanks Wes. I unfortunately had a lot of connectivity problems during today's meeting, so I missed some of the discussion towards the end. I think there was a question about the behavior of j.root-servers.netrelated to this topic? > > OK, The error came from me. A company in Saudi Arabia was asking about having an F instance, and told me that they wanted to have J but it didn't work out. The thing they found attractive was that having a J instance meant they also had service for the other Verisign TLDs. What you're telling me is that they must have *also* gotten a different server instance for those TLDs. Ah. Verisign has a thing called Regional Internet Resolution Service (RIRS). This is a single server that can be sent to qualifying IPSs etc that we then manage. The RIRS server has multiple VMs, one of which is for j.root-servers.net. Other VMs will serve other zones on other IP addresses. https://www.verisign.com/en_US/domain-names/internet-resolution/index.xhtml… DW

1 0