DNSintegration5 01

Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use
Title: Synopsis:
Client Site DNS Integration Guide This document describes the possible DNS configurations that may be implemented on a client site connected to the Thomson Reuters Delivery Service (BT Global MPLS) or legacy RadianzNet (RXN). This document was written for Thomson Reuters internal staff but this version may be given to customers as required. Released 5.01 Solos ARTHACHINDA
Status: Version: Approved:
Author:
Solos ARTHACHINDA Worport Sinsukthavorn Nachanont Jaijamnong
Date: Filename:
01 June 2009 DNSintegration5_01.doc
CONFIDENTIAL INFORMATION OF THOMSON REUTERS This document contains information proprietary to Thomson Reuters and may not be reproduced, disclosed or used in whole or in part without the express written permission of Thomson Reuters. Copyright Thomson Reuters 2009
Version 5.01
Page 1
Table of References Reference

RFC1034 RFC1035 BCP16 RFC1918 DNS & BIND
Name
Domain Names Concepts Domain Names Implementation Secondary DNS Servers Address Allocation for Private Internets DNS and BIND (5th Edition) Cricket Liu & Paul Albitz
Location
www.isi.edu/in-notes/rfc-index.txt www.isi.edu/in-notes/rfc-index.txt www.isi.edu/in-notes/bcp-index.txt http://www.isi.edu/in-notes/rfc1918.txt
Version 5.01
Page 2
Document History
Version 0.1 0.2 1.0 1.1 2.0 Date 22 Aug 2000 25 Sept 2000 02 Oct 2000 06 Oct 2000 22/04/02 Author A Batten, C Warr T Chen T Chen T Chen J Hayward Changes First draft for comment and input Amended draft for approval Release for comment Incorporated feedback from field Microsoft DNS + Proxy server integration solution, EXTRANET DNS to resolve session.rservices.com queries, new RadianzNet DNS to resolve new Reuters Messaging and Gazelle domains. Customer RadianzNet Migration statement, further DNS integration configuration options. Customer DNS matrices table updated Customer DNS matrices table updated & Reuters fully qualified domain name statement added. Further update to customer DNS matrices table. Incorporate feedback from RAM & UKI Formatting Changes Further new product domains included Extra solution for customers with no local DNS server. ILA resolution recommendation amended to include global DNS integration solution. Additional Reuters Product Domains FQDN for the RadianzNet DNS servers added plus delegation example for Windows 2000 DNS server. Barraone product DNS Domain added Customer zone domain, Windows .NET selective forwarding and EMT product integration example RT lookup modified & Customer zone domain use clarified Nighthawk and other Customer Zone domains added Barraone domain modified CME domain added Market Place data domain added Keystation Internet Browser and Client Proxy server section corrected for Market Place Data domain -Use xtraserv.session.rservices.com as an example instead of www.session.rservices.com -Add rds.rservices.com, knowledge.reuters.net, and extranet.reuters.biz domains Add Reuters Failover Services section Add logingabout.reuters.com domain Add rtextrading.reuters.com domain Add configuration example for client ILA resolution via Windows Server 2003 DNS server Generalize the documentation for both RXN and BT Radianz Infrastructure. Remove Obsolete Domains Add RTNS domain Add Internet domain Correct DNS IP in section 2.1.3 Add RK domain as part of 3000Xtra product suite in section 3.1, 4.2.2, 6.6.2 Update URL for HTA 5.0.1 in section 3.1, 4.2.2, 6.6.2 Remove URL for HTA 4.5.2 in section 3.1, 4.2.2, 6.6.2 Correct Domain for HTA 5.0.1 in section 3.1, 4.2.2, 6.6.2 Update Domain for 3000Xtra in section 3.1, 4.2.2, 6.6.2 Add EDNS GSLB Modify page 25, section 4.1.2 Replace from EXTRANET to Extranet Add customersa.reuters.com
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.95 2.96 2.97 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7
01/05/02 09/05/20 17/05/02 17/05/02 21/05/02 22/05/02 17/06/02 04/09/02 13/02/03 11/08/03 14/08//03 07/01/04 09/03/04 08/04/04 27/08/04 08/11/04 24/01/05 20/02/05 19/04/05 10/08/05
J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward J Hayward
C HATHAISUTTHI
3.8 3.9 3.10 3.11 4.00 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22
18/11/05 10/02/06 25/08/06 07/09/06 13MAR2007 16AUG2007 30AUG2007 06SEP2007 26DEC2007 23JAN2008 24JAN2008 25JAN2008 29JAN2008 13FEB2008 2JUNE2008 27JUNE2008 29JULY2008 28AUGUST2008
C HATHAISUTTHI C HATHAISUTTHI C HATHAISUTTHI C HATHAISUTTHI S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA S ARTHACHINDA W SINSUKTHAVORN W SINSUKTHAVORN W SINSUKTHAVORN W SINSUKTHAVORN
Version 5.01
Page 3
4.23 4.24 29SEP2008 27OCT2008
W SINSUKTHAVORN N JAIJAMNONG
4.25 4.26 4.27
20NOV2008 11DEC2008 16DEC2008
N JAIJAMNONG N JAIJAMNONG N JAIJAMNONG
4.28 4.29 4.30 4.31 5.00 5.0.1
15JAN09 24FEB09 27FEB09 27FEB09 27APR09 01JUN2009
N JAIJAMNONG W SINSUKTHAVORN S ARTHACHINDA S ARTHACHINDA G LEES S ARTHACHINDA
Add RTNF (rtnfblue.demo.fx.com) Add thomsomreuters domain (thomsonreuters.com, extranet.thomsonreuters.biz, cp.thomsonreuters.net, trading.thomsonreuters.net) Replace from EXTRABET to Extranet Add data.nordic.extranet.reuters.biz - Update product type for thomsonreuters.com, extranet.thomsonreuters.biz from All product to Future Extranet products - Update product type for cp.thomsonreuters.net from For common plat form to future product - Update sip.reuters.net to forward only - Add collab.thomsonreuters.net Change Authoritative DNS Server From Extranet DNS to Extranet DNS. Add *.rtlh.reuters.com on section 4.1.2 Correction pdf.reuters.com Correction *.sip.reuters.com Update pdf.reuters.com Change Authoritative DNS for all domains to EDNS, and remove obsolete appendix sections. Update the domain require for RM in 3.1, 4.2 Update the DNS-2003 capture screen.
Version 5.01
Page 4
Contents
1. 1.1 1.2 1.3 1.4 1.5 1.6 2. INTRODUCTION .......................................................................................................... 7 Choice of Domain Name ..........................................................................................................7 DNS Services on the Distribution Extranets ..........................................................................7 Client DNS Name Resolution on the Distribution Extranets................................................9 Recommended Client Sited DNS Implementation ..............................................................10 Other DNS Configurations....................................................................................................10 Thomson Reuters Failover Services .....................................................................................10 CLIENT WORKSTATION RESOLVER (NO CLIENT DNS SERVER) ...................... 11
2.1 Configuration Workstation ................................................................................................11 2.1.1 Known Problem and Solutions ............................................................................................12 3. SELECTIVE FORWARDING NAME RESOLUTION ................................................. 13
3.1 Thomson Reuters Domain Names that require Selective Forwarding ..............................13 3.2 Selective Forwarding Example .............................................................................................15 3.2.1 Session.rservices.com Resolution using EDNS Example ...................................................16 3.2.2 Commerce.reuters.com Resolution using EDNS Example .................................................16 3.2.3 Commerce.reuters.com Resolution using BT DNS Example..............................................16 3.2.4 Internet Name Resolution Example.....................................................................................16 3.2.5 Known Problem and Solutions ............................................................................................16 3.2.6 Configuring BIND 8.2.3 or later for Selective Forwarding.................................................17 3.2.7 Configuring Microsoft Windows 2003 Server DNS for Selective Forwarding...................18 4. NON-SELECTIVE FORWARDING NAME RESOLUTION........................................ 20
4.1 Scenario A - Client DNS Forwards to the Delivery Extranet Servers ...............................20 4.1.1 Client DNS Server Configuration........................................................................................21 4.1.2 Keystation Internet Browser Configuration.........................................................................21 4.1.3 Client Proxy Server DNS configuration ..............................................................................21 4.1.4 Session.rservices.com Resolution Example ........................................................................21 4.1.5 Commerce.reuters.com Resolution Example ......................................................................21 4.1.6 Internet Name Resolution Example.....................................................................................22 4.1.7 Known Problems and Solutions ..........................................................................................22 4.2 Scenario B Client DNS Forwards to an Internet DNS Server.........................................23 4.2.1 session.rservices.com Method - Delegation ........................................................................23 4.2.2 Microsoft Windows 2000 DNS Server Method Delegation .............................................23 4.2.3 Client Proxy Server & Keystation Browser Settings...........................................................25 4.2.4 Microsoft Windows 2000 DNS - Delegation Example .......................................................25 4.2.5 Non Windows 2000 Pre BIND 8.2.3 local Client DNS.......................................................25 5. CLIENT ILA RESOLUTION ....................................................................................... 26
5.1 Local Client DNS Configuration...........................................................................................26 5.1.1 Configuration example for BIND DNS server ....................................................................26 5.1.1.1 named.conf............................................................................................................ 26 5.1.1.2 Zone File ...............................................................................................................27 5.1.2 Configuration example for Windows Server 2003 DNS server ..........................................27 6. APPENDIX A.............................................................................................................. 32
6.1 Reuters EMT Product DNS Integration...............................................................................32 6.1.1 DNS Servers ........................................................................................................................32 6.1.2 Reuters Trader .....................................................................................................................32 6.1.2.1 No local DNS ........................................................................................................32
Version 5.01
Page 5
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use 6.1.2.2 Local Client DNS..................................................................................................32 6.1.2.3 Reuters Trader desktop and the RMCD ................................................................ 32 6.2 Reuters DNS Domain .............................................................................................................36 6.2.1 By Product Family...............................................................................................................36 6.2.2 By Domain ..........................................................................................................................38 7. APPENDIX B.............................................................................................................. 41
7.1 EDNS GSLB ...........................................................................................................................41 7.1.1 What is GSLB?....................................................................................................................41 7.1.2 How do the EDNS and GSLB work together? ....................................................................41
Version 5.01
Page 6
1. Introduction
This document describes the supported DNS configurations that may be implemented on a client site connected to Thomson Reuters Delivery Service (BT Global MPLS) or legacy RadianzNet (RXN). These range from simple client resolver to ISP DNS configurations. For the remainder of the document, the Thomson Reuters Delivery Service (BT Global MPLS) and legacy RadianzNet (RXN) will be referred to as the Distribution Extranets
1.1 Choice of Domain Name

Previously, Thomson Reuters policy was to use the same Fully Qualified Domain Names (FQDN) for services that are available on both the Internet and the Distribution Extranets. The benefit of this approach was to simplify the product design and deployment by customers. For example, a user could seamlessly access Reuters Messaging in the office over the Distribution Extranet and at home over the Internet, communicating with other users irrespective of their network connection. More recently, with the formation of Thomson Reuters, this policy has changed slightly. Going forwards, the high level domain naming policy is to use: thomsonreuters.com for products delivered over the Internet extranet.thomsonreuters.biz for products delivered over the Distribution Extranets. thomsonreuters.net for products available over both the Internet and Distribution Extranets.
New products will be launched under one or more of the thomsonreuters domains. Over time, the legacy products should migrate to across to the new naming structure. As clients start to take the these services, those with local DNS servers may need to make DNS configuration changes to be able to resolve the new domains correctly.
1.2 DNS Services on the Distribution Extranets

There are two DNS services which serve clients on the Distribution Extranets: The Extranet DNS (or EDNS) - which is owned and maintained by Thomson Reuters. The BT DNS - which is owned and maintained by BT.
Previously, there was an overlap between the two DNS services and neither the EDNS or the BT DNS was authoritative for all of the Thomson Reuters or legacy Reuters zones. This left clients having to use a combination both DNS services to resolve different combinations of Thomson Reuters products. Going forwards 1, the EDNS is the authoritative DNS for all new Thomson Reuters and legacy Reuters domains. The BT DNS remains in place, but as a non-authoritative caching DNS for the new Thomson Reuters and legacy Reuters domains. Both the EDNS and BT DNS will accept recursive and iterative (non-recursive) queries from any Distribution Extranet client. From a clients perspective, the main differences between the two DNS services are: For a valid DNS request, the EDNS will always return an authoritative answer; the BT DNS will always return a non-authoritative answer For a request for a host in an invalid domain (e.g. update.microsoft.com), the EDNS will always return a non-authoritative NXDOMAIN answer; the BT DNS will always return a nonauthoritative SERVFAIL answer. For a request for an invalid host in a valid domain (e.g. foobar.extranet.reuters.biz), the EDNS and BT DNS will always return a non-authoritative NXDOMAIN answer.
The recommended DNS servers to use for the various different configurations are as follows:1
This change will take place on 25 April 2009 Page 7
Version 5.01
Client Configuration Client workstation resolver only (No Client Site DNS)
Recommended DNS BT DNS
Alternative DNS EDNS
Comments Many smaller clients use local resolver fall-through. This relies on SERVFAIL answer from BT DNS for invalid domains. Clients with dedicated Extranet workstations can use the EDNS to take advantage of faster response BT DNS response time will be slower unless record is already in its cache Delegating to the BT DNS is not recommended in this instance. Doing so will result in a lame delegation because the BT DNS is nonauthoritative
Client sited DNS using selective forwarding (or conditional forwarding) Client site DNS using zone delegation
EDNS
BT DNS
EDNS
Whichever DNS service is chosen, the client DNS request must be able to reach the target DNS server. It is not unusual for client sited firewalls to restrict access to DNS and so connectivity should be checked before making any DNS changes. The EDNS and BT DNS services each consists of three geographically diverse physical servers as detailed below.
EDNS London New York Singapore
IP Address 155.195.64.4 155.195.84.4 155.195.76.4
FQDN edns02.uk.extranet.reuters.biz edns02.us.extranet.reuters.biz edns02.sg.extranet.reuters.biz
BT DNS London New York Singapore
IP Address 155.195.48.4 155.195.48.36 155.195.48.68
FQDN londnsaa001a.radianz.net hpggnsba001a.radianz.net sinsnsba001a.radianz.net
The order that these addresses are referenced can be important depending upon the client DNS resolution option chosen. The recommended order is given for each scenario. Region EMEA Americas Asia First DNS Server London New York Singapore Second DNS Server New York London New York Third DNS Server Singapore Singapore London
Version 5.01
Page 8
1.3 Client DNS Name Resolution on the Distribution Extranets

For the Distribution Extranet, there are two recommended options for hostname to IP address resolution. Using the client workstation resolver (i.e. no client sited DNS server) Implementing a client sited DNS server
Client Workstation Resolver This configuration is used where the client connects to the Distribution Extranet only and has no need to resolve Internet or local domain names. The client simply enters the EDNS or BT DNS server addresses into the DNS network options in each client workstation Client Sited DNS The various possible client DNS name resolution options are shown in the following table:Local Client DNS Server Selective Forwarding Capability Typical Client DNS Scenario Client action required Thomson Reuters legacy services on rservices.com accessible on the Distribution Extranets? Thomson Reuters services on reuters.com and reuters.net accessible on the Distribution Extranets? Clients can resolve www.reuters.c om , reuters.com mail (MX) records and all other hosts in the domain reuters.com Yes When selective forwarding capable local DNS is deployed. Yes Residual impact on client
None
Not until a Selective Forwarding Capable DNS server is deployed. Yes
Migrated from a Session server previously used as a proxy DNS server for Internet name resolution N/A
To resolve Internet hostnames a local DNS server should be deployed.
Yes
Yes
Administration of new local DNS.
BIND 8.2.3 or Later
Add appropriate selective forwarding statement(s) to client DNS server Add appropriate conditional forwarding configuration to client DNS Use forwarding to resolve all Reuters services on BT Radianz Infrastructure or RadianzNet (RXN).
Yes
Yes
None
Microsoft Windows 2003 DNS Server
Yes (called conditional forwarding)
N/A
Yes
Yes
Yes
None
BIND version earlier than 8.2.3 (including Microsoft NT and Windows 2000 server solutions) Microsoft Windows 2000 Server DNS
No
Client DNS server is not already using forwarding, and uses a local proxy server for access to the Internet Client DNS server is using forwarding to an ISP DNS server for Internet hostname resolution
Yes
Yes
Yes Reuters web site via proxy server DNS. Reuters Internet Mail (MX) records via same or ISP DNS. No To resolve www.reuters.c om the client should use a web proxy server. To resolve Reuters Internet mail records the client should use a different local (or ISP) DNS
Only client forwarder should be the BT DNS. Client mail server should use a different (local) DNS to resolve reuters.com mail (MX) records. Reuters products located within reuters.com eg www.reuters.com, city.reuters.com and reuters.com MX records will not be accessible via this DNS server. To access them a client would need to implement a proxy server solution using and a different local (or ISP) DNS to resolve reuters.com Internet mail or MX records. Client will not be able to resolve or connect to new Reuters products that are only available on the Extranets eg Reuters Dealing Link (RDL).
No
Use delegation to resolve Reuters legacy services on rservices.com and newer services on reuters.com and reuters.net
Yes
Yes
Pre BIND 8.2.3 servers including Microsoft Windows NT 4.0 but not including Microsoft Windows 2000 Server.
No
Client DNS server is using forwarding to an ISP DNS server for Internet hostname resolution
Use delegation to resolve Reuters legacy services on rservices.com and forwarding to resolve Internet resolution
Yes
No Using delegation for reuters.com as in the example above will not work. The default behaviour for these BIND implementations is to forward first before contacting the delegated name servers. Newer Reuters products will be resolved and accessed via the Internet. Eg Reuters Messaging.
Yes
Version 5.01
Page 9
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use Note: Clients that previously used a Sessionserver for Internet and Thomson Reuters hostname resolution will need to install a local DNS server to maintain this level of functionality.
1.4 Recommended Client Sited DNS Implementation

The recommended client site DNS implementation is either: BIND 8.2.3 or later with Selective Forwarding configured for the Thomson Reuters and legacy Reuters domains, forwarding to the EDNS, or Windows 2003 or later with Conditional Forwarding configured for the Thomson Reuters and legacy Reuters domains forwarding to the EDNS
1.5 Other DNS Configurations

Versions of BIND prior to 8.2.3, Microsoft NT4 or Windows 2000 DNS implementations do not support selective forwarding (or conditional forwarding) and so the recommended action for clients is to upgrade to later versions and implement Selective Forwarding. However, for clients that do not wish to upgrade their BIND DNS server to BIND 8.2.3 or later there is an integration solution referenced within this document involving the local client DNS and a local proxy server. This solution requires that the only forwarder in the clients DNS forwarding list be set to the appropriate EDNS (preferred option) or BT DNS server.IP addresses For clients that do not wish to upgrade their Microsoft DNS server there is an integration solution referenced within this document involving the local client DNS and a local proxy server. This solution requires that the only forwarder in the clients DNS forwarding list be set to the the appropriate EDNS (preferred option) or BT DNS server IP addresses. Microsoft Windows 2003 server supports conditional forwarding and so presents a Microsoft supported Microsoft DNS server upgrade path. There is a further DNS integration solution referenced within this document that involves a Pre BIND 8.2.3 client DNS server (or Microsoft Windows 2000 DNS) using delegation to resolve Reuters hosts and forwarding to resolve Internet hosts. This solution is dependent upon the fact that the local client DNS server sends appropriate hostname requests to the delegated DNS servers before sending hostname requests to the DNS servers in the forwarding list. Some implementations of BIND (both 4 and 8) default to sending all non local queries to their forwarders before their delegated DNS servers this solution will not work for these BIND DNS server implementations.
1.6 Thomson Reuters Failover Services

To take advantage of Thomson Reuters Failover Services which redirect traffic from a failed host to a backup host, customers should utilise the DNS TTL values returned from the EDNS or BT DNS servers. Thomson Reuters will periodically change the active host from the Live to a Backup server and will manage the change within the Central DNS Administration System. Customers that modify the TTL values returned from the DNS servers may lose connectivity by attempting to connect to a server that is offline
Version 5.01
Page 10
2. Client Workstation Resolver (No Client DNS server)

In this scenario, the configuration of the resolver on the client workstation is modified. There is no client DNS server present and the client does not connect to the Internet. To resolve Internet as well as Delivery Extranet hostnames, the client will need to deploy a local DNS server.
xtraserv.session.rservices.com 155.195.88.161
www.commerce.reuters.com
155.195.82.29
BT Radianz Infrastructure or RXN
IRG DNS 155.195.64.4
RXN DNS 155.195.48.4
CE Router
Client LAN
10.6.0.0 /16
Client PC
Client PC
Client PC
The client has a choice of using either the BT DNS or EDNS. .Either DNS will respond and provide the client with the same record.. Refer to Section 2.1.1 below for further guidance on which DNS to use. The BT servers are entered in the DNS section of the TCP/IP properties of each client workstation.
2.1 Configuration Workstation

Assuming the workstation is running Windows NT 4: In Control Panel/Network/Protocols/TCP-IP Protocol/Properties/DNS enter the RXN DNS(s) in DNS Service Search Order.
IP Address 155.195.48.4 155.195.48.36 155.195.48.68
Version 5.01
Page 11
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use EDNS London New York Singapore IP Address 155.195.64.4 155.195.84.4 155.195.76.4 FQDN edns02.uk.extranet.reuters.biz edns02.us.extranet.reuters.biz edns02.sg.extranet.reuters.biz
For workstations, the order that these addresses are referenced is important and varies depending upon the clients geographical location. The table below describes the correct DNS service search order. Region EMEA Americas Asia First DNS Server London New York Singapore Second DNS Server New York London New York Third DNS Server Singapore Singapore London
2.1.1 Known Problem and Solutions There are no known problems with this configuration since the EDNS (or BT DNS if preferred) is the only DNS on the client network. For resilience, multiple EDNS servers are configured. At present there are three EDNS servers globally; the client will be given at least two of these. When an EDNS server is down and cannot respond, a DNS time-out will occur and the client workstation will use the next EDNS server it finds in the list. If a client wishes use the BT DNS in preference to the EDNS, the DNS response will be the same. Any client changing from the BT DNS to EDNS (or vice versa) should check that there are no client site firewalls blocking access to their chosen DNS servers. Many smaller clients may have dual connected (Delivery Extranet and Internet/local) workstations and have added a Delivery Extranet DNS as well as either their Internet DNS, or local corporate DNS to their list of resolvers. If this is the case, the client may well be relying on resolver fall-through and will expect a SERVFAIL response from the Delivery Extranet DNS for any non Thomson Reuters or legacy Reuters domain. In this case, the EDNS should not be used and the BT DNS should be chosen in preference. The EDNS will return a non-authoritative NXDOMAIN answer in response to any DNS request for any host in a non Thomson Reuters or legacy Reuters domain (e.g. mylocalprinter.mylocaldomain.com).
Comment [G1]: Ive added this as further guidance. It would be preferable to say use the EDNS, but there are many clients who simply stick the BT DNS and their own corporate or Internet DNS in the list of resolvers. This is why more than 85% of our queries are for bogus domains.
Version 5.01
Page 12
3. Selective Forwarding Name Resolution

This is the recommended implementation for a client sited DNS server. To selectively forward DNS requests, the clients local DNS server should either be: Running BIND 8.2.3 or later Windows 2003
A selectively forwarded request is one which is redirected from the default name resolution process to a different name server dependent upon the domain name in the request. In the example below a name resolution request for an rservices.com host is forwarded to a different name server to that for a cisco.com host. When a DNS selectively forwards a request, it makes a recursive DNS query and expects an answer from the queried DNS and not a referral to another DNS. The answer can be either authoritative or non-authoritative. Note: Microsoft use the term conditional forwarding to describe selective forwarding.
3.1 Thomson Reuters Domain Names that require Selective Forwarding

The following table lists the zones that require selective forwarding. Whilst the authoritative DNS for the Thomson Reuters and legacy Reuters domains on the Extranet is the EDNS, the BT DNS will also serve records for the same domains, albeit non-authoritatively. The recommendation is to use the EDNS in preference to the BT DNS for selective forwarding to reduce latency. DNS Domain about.reuters.com customers.reuters.com extranet.reuters.biz session.rservices.com thomsonreuters.com extranet.thomsonreuters.biz cp.thomsonreuters.net trading.thomsonreuters.net 3000ip.rservices.com rds.rservices.com commerce.reuters.com dlinezrh.radianz.net fitrading.reuters.com fxtrading.reuters.com rtextrading.reuters.com rtextrading.integration.reuters.com Authoritative DNS Server EDNS EDNS EDNS EDNS Internet EDNS EDNS / Internet EDNS / Internet EDNS EDNS EDNS /Internet BT DNS EDNS /Internet EDNS /Internet EDNS /Internet Internet Thomson Reuters Product All products All products; Xtra Help & FAQ All products 3000Xtra, Legacy 3000 Series (e.g. Securities 3000), EMT Products Future Internet products Future Extranet products Future Internet/Extranet products Future Reuters Trading 3000Xtra (US Only) Insert Link, Market Link Reuters Trader, Reuters Messaging, RDL Hosted Citrix (Zurich); 3000Xtra (EMEA customer via Direct Line Infrastructure) Reuters Trading for Fixed Income Reuters Trading for FX Reuters Trading for Exchanges Reuters Trading for Exchanges Certification Page 13
Comment [G2]: The BT DNS is the authoritative DNS for all radianznet hosts
Version 5.01
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use EDNS /Internet EDNS /Internet EDNS EDNS /Internet Internet EDNS Internet EDNS / Internet BT DNS EDNS /Internet EDNS /Internet EDNS / Internet EDNS / Internet EDNS / Internet EDNS / Internet EDNS / Internet EDNS Internet Internet Internet Internet Internet Internet Internet Internet Internet Internet EDNS /Internet Internet BT DNS
rtextrading.demo.reuters.com fxmarketspace.reuters.com futurestrading.reuters.com markets.reuters.com global.reuters.com ukb.reuters.com rtnfradianz.reuters.com Rtnfinternet.reuters.com rtnfblue.demo.fx.com
Reuters Trading for Exchanges Demo FX Market Space Reuters Trading for Futures - CME Reuters Dealing Link, 3000Xtra (IOI Plug-in), Reuters Messaging 3000Xtra HTA (v5.0.1) Reuters Trade Notification Service (RTNS) Reuters Trade Notification Service (RTNS) Demo Reuters Trade Notification Service (RTNS) Global Press Watch, Factiva News Watch Reuters Trader (EMT-Based), Reuters Wealth Manager Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging Reuters Knowledge, 3000Xtra Reuters Knowledge EcoWin Pro Reuters Data Scope Tick History Reuters News Scope Archive Lipper Product 3000Xtra (Re-direct to about.reuters.com) 3000Xtra (Loan Connector) 3000Xtra (First Know it) 3000Xtra (Scanrate) 3000Xtra (Europrospectus) Reuters Trading 3.1 3000Xtra Any FCE services or other non-Thomson Reuters services which are hosted on the BT Extranet
radianz.factiva.com rapid.reuters.com sip.reuters.net collab.thomsonreuters.net collab.reuters.net space.reuters.com chat.reuters.com rmcm.reuters.net knowledge.reuters.net knowledge.reuters.com ecowin.com datascope.reuters.com newsscope.reuters.com emaxx.reuters.com kalends.com loanconnector.com firstknow.it rts.scanrate.dk europrospectus.com data.nordic.extranet.reuters.biz pdf.reuters.com radianz.net
Comment [G3]: Ive added this as a catch all.
Domain available on Internet customersa.reuters.com customers.reuters.com
Internet DNS Internet DNS
RWS Reuters Trader and RM
Version 5.01
Page 14
3.2 Selective Forwarding Example

The example below requires either BIND 8.2.3 or later, or Windows 2003 DNS or later
Client DNS name resolution within BT Radianz Infrastructure or Radianznet and the Internet
www.commerce.reuters.com 155.195.82.29
www.cisco.com 198.133.219.25
RXN DNS 155.195.48.4

IRG DNS 155.195.64.4 Internet Root DNS(s)
INTERNET
CE Router
ISP Router
Client LAN
10.6.0.0 /16
Client PC
Client PC
Client PC
LOCAL DNS 10.6.10.1
In this scenario the local client DNS server is entered in the DNS section of the TCP/IP properties of each client workstation.
Version 5.01
Page 15
3.2.1 Session.rservices.com Resolution using EDNS Example The client PC name resolution request for xtraserv.session.rservices.com is sent to the local DNS server which selectively forwards the request to the EDNS server. The EDNS server resolves the request and sends the authoritative answer (155.195.88.161) back to the local DNS server which in turn sends the answer to the client PC.
3.2.2 Commerce.reuters.com Resolution using EDNS Example The client PC name resolution request for for www.commerce.reuters.com is sent to the local DNS server which selectively forwards the request to the EDNS server. The EDNS server resolves the request and sends the authoritative answer (155.195.82.29) back to the local DNS server which in turn sends the answer to the client PC.
3.2.3 Commerce.reuters.com Resolution using BT DNS Example The client PC name resolution request for for www.commerce.reuters.com is sent to the local DNS server which selectively forwards the request to the BT DNS server. The BT DNS server either responds with a previously cached answer, or queries the EDNS to get the answer. Finally, the answer (155.195.82.29) is sent back to the local DNS server which in turn sends the answer to the client PC. 3.2.4 Internet Name Resolution Example The client PC name resolution request for www.cisco.com is sent to the local DNS server which will check its local cache to see if it already knows the answer. If not the local DNS server will send an iterative name resolution query to one of the Internet Root Name Servers. This server will refer the local DNS server to another name server that is authoritative for a zone further down in the name space and closer to the domain name sought. Finally the Local DNS will query the authoritative server for www.cisco.com which returns an answer (198.133.219.25) and will then pass this on the client PC. 3.2.5 Known Problem and Solutions There are no known problems with this DNS configuration. The Thomson Reuters or legacy Reuters host name resolution requests are serviced by the EDNS or BT DNS servers (contained within the forwarding list in named.conf). The recommended option is to use the EDNS as this is the authoritative DNS server. The BT DNS will return a slower response unless it has the record in its local cache. Local client name resolution are serviced by the client DNS server (host listing within db.matrix.service in our example) Internet name resolution requests are resolved by the local client DNS server querying the Internet root name servers (contained within root.hints file).
Version 5.01
Page 16
3.2.6 Configuring BIND 8.2.3 or later for Selective Forwarding Each Thomson Reuters or legacy Reuters DNS domain needs to be separately Selectively Forwarded by the client DNS server for successful name resolution. An excerpt from a named.conf file (the BIND configuration file that controls selective forwarding) section of this document is seen below. Each Zone section requires that the client DNS server forward the request to the relevant EDNS or BT DNS server. The choice of EDNS or BT DNS is down to the client. The preference is to use the EDNS to reduce latency. London is the first DNS Server in the list and will be used when the server is first started but BIND will work out which of the three is the fastest responding DNS server and then query that one first.
zone "session.rservices.com" { type forward; forwarders {155.195.64.4; 155.195.84.4;155.195.76.4;}; forward only }; zone "markets.reuters.com" { type forward; forwarders {155.195.64.4; 155.195.84.4;155.195.76.4;}; forward only }; zone "commerce.reuters.com" { type forward; forwarders {155.195.64.4; 155.195.84.4;155.195.76.4;}; forward only }; zone "sip.reuters.net" { type forward; forwarders };
{155.195.64.4; 155.195.84.4;155.195.76.4;}; forward only
IP Address 155.195.64.4 155.195.84.4 155.195.76.4
The recommended order for the DNS configuration is given below. In reality, the client DNS will work out which DNS responds quickest and continue to use that one unless it fails to respond. Region EMEA Americas Asia First DNS Server London New York Singapore Second DNS Server New York London New York Third DNS Server Singapore Singapore London
Version 5.01
Page 17
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use 3.2.7 Configuring Microsoft Windows 2003 Server DNS for Selective Forwarding Note: Microsoft refer to this as Conditional Forwarding
Right click the server and go to Properties
Click on the Forwarders tab
Click New
Version 5.01
Page 18
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use Type in the domain name that is being selectively forwarded
Click OK Add in the IP addresses of the DNS servers to be selectively forwarded to (See previous table for Reuters domains and the authoritative DNS server). Click Apply Repeat for all required domains
IP Address 155.195.64.4 155.195.84.4 155.195.76.4
The recommended order for the DNS configuration is given below. In reality, the client DNS will work out which DNS responds quickest and continue to use that one unless it fails to respond. Region EMEA Americas Asia First DNS Server London New York Singapore Second DNS Server New York London New York Page 19 Third DNS Server Singapore Singapore London
Version 5.01
4. Non-Selective Forwarding Name Resolution

Clients with a local DNS server that is running BIND pre- 8.2.3 cannot configure their DNS server to selectively forward name resolution requests. At the time of writing this document, Microsoft NT4.0 and Windows 2000 DNS implementations cannot perform selective forwarding and so also fall into this category. The following scenarios describe the configuration(s) necessary for a clients DNS server, keystation Internet browser and Proxy server for complete Extranet DNS integration.
4.1 Scenario A - Client DNS Forwards to the Delivery Extranet Servers
Client DNS name resolution within BT Radianz Infrastructure or Radianznet and the Internet
www.commerce.reuters.com 155.195.82.29
www.cisco.com 198.133.219.25
RXN DNS 155.195.48.4

IRG DNS 155.195.64.4 Internet Root DNS(s)
INTERNET
CE Router
ISP Router
Client LAN
10.6.0.0 /16
Client PC
Client PC
Local Proxy Server 10.6.10.2
LOCAL DNS 10.6.10.1
In this scenario the local client DNS server is entered in the DNS section of the TCP/IP properties of each client workstation.
Version 5.01
Page 20
4.1.1 Client DNS Server Configuration The local client DNS should be configured with the only forwarder in its forwarding list to be the appropriate EDNS (recommended) or BT DNS server. 4.1.2 Keystation Internet Browser Configuration Each client keystation Internet browser should be configured to use the client Proxy server for Internet access. The option for bypassing the Proxy server for local addresses should be enabled and the box Exceptions Do not use proxy server for addresses beginning with: configured with the following exceptions:*.rservices.com;*.about.reuters.com;*.customers.reuters.com; *.fitrading.reuters.com;*.fxtrading.reuters.com; *.futurestrading.reuters.com;*.markets.reuters.com;*.commerce.reuters.com; *.osn.reuters.com; *.sip.reuters.net; *.dlinezrh.radianz.net; *.glbl1.reuters.com; *.radianz.factiva.com; *.rapid.reuters.com; *.knowledge.reuters.net; *.extranet.reuters.biz; *.infra.reuters.biz; *.rtextrading.reuters.com; *.rtlh.reuters.com; NOTE: *.osn.reuters.com, *.test.reuters.com, and *.infra.reuters.biz are mainly used by RDF/RWS/DOIP MOIP service, is an additional option for bypassing the proxy server. 4.1.3 Client Proxy Server DNS configuration The client Proxy server should be configured to use an ISPs DNS server or a different local client DNS server that forwards DNS queries to the Internet. 4.1.4 Session.rservices.com Resolution Example The client PC name resolution request for xtraserv.session.rservices.com is sent to the local DNS server, which then sends the request to the EDNS or BT DNS Server (whichever has been configured). In the case of the EDNS, the EDNS will simply resolve the request and send the answer (155.195.88.161) back to the client DNS server which then sends the answer back to the original querying client PC. In the case of the BT DNS, the BT DNS server proxies the requests and forwards it to the EDNS server. The EDNS server responds with the answer (155.195.88.161) to the BT DNS server, which sends the response to the local client DNS server. This then sends the answer to the original querying client PC. 4.1.5 Commerce.reuters.com Resolution Example The client PC name resolution request for for www.commerce.reuters.com is sent to the local DNS server, which forwards the request to the EDNS or BT DNS server (whichever has been configured). In the case of the EDNS, the EDNS will simply resolve the request and send the answer (155.195.82.29) back to the client DNS server which then sends the answer back to the original querying client PC. In the case of the BT DNS, the BT DNS server proxies the requests and forwards it to the EDNS server. The EDNS server responds with the answer (155.195.82.29) to the BT DNS server, which sends the response to the local client DNS server. This then sends the answer to the original querying client PC.
Version 5.01
Page 21
4.1.6 Internet Name Resolution Example The client PC name resolution request for www.cisco.com is sent by the client Proxy server to either an ISPs DNS or an internal DNS server (different to that configured in the TCP/IP properties of the client keystation) configured to forward DNS queries to the Internet. This DNS server will send an iterative name resolution query to one of the Internet Root Name Servers. This will refer the DNS server to another name server that is authoritative for a zone further down in the name space and closer to the domain name sought. Finally this DNS server will query the authoritative server for www.cisco.com which returns an answer (198.133.219.25) and will then pass this on the client Proxy server. The key to this resolution example is that it is the Proxy server initiating the name resolution request (due to the keystation Internet browser settings) and that the Proxy server is configured with a different DNS server than that of the client keystation. Had the Proxy server sent the request to the same local DNS server that the keystation is configured with, and then the resolution request would have failed because the first configured forwarder for the local keystation client DNS server is the EDNS server (or BT DNS) which does not resolve Internet domain name queries.
4.1.7 Known Problems and Solutions There is a problem with this solution if the client requires an entry in the forwarders list of the local DNS server other than the forwarding entry of the EDNS (or BT DNS) servers. The preferred solution would be to upgrade the clients local DNS server to a BIND version that supported selective forwarding and then to configure that BIND DNS server as per the selective forwarding sections within this document. However the following section of this document presents workaround scenarios that address this problem. Although not a recommended solution, some clients may have a dual connected DNS and have added both the Internet DNS and an Extranet DNS in their list of forwarders. If this is the case, the EDNS should not be used and the BT DNS should be chosen in preference.
Version 5.01
Page 22
4.2 Scenario B Client DNS Forwards to an Internet DNS Server

4.2.1 session.rservices.com Method - Delegation Clients that have Internet forwarders configured in their DNS server can configure their name server to be authoritative for the rservices.com domain and then delegate authority for the session.rservices.com domain to the EDNS servers. This will enable hostname to IP address resolution across the Distribution Extranets for all the hosts within the session.rservices.com domain. There are no problems with this delegation scenario. It is not recommended that clients delegate to the BT DNS servers. Doing this creates a lame delegation because the BT DNS is non-authoritative DNS. 4.2.2 Microsoft Windows 2000 DNS Server Method Delegation Windows 2000 DNS Configuration Clients that have Internet forwarders configured in their DNS server can configure their Windows 2000 DNS server to be authoritative for e.g. the reuters.com domain and then delegate authority for the newdomain.reuters.com domain to the EDNS servers. This will enable Reuters hostname to IP address resolution across Distribution Extranets for all the hosts within the newdomain.reuters.com domain. It is not recommended that clients delegate to the BT DNS servers. Doing this creates a lame delegation because the BT DNS is non-authoritative DNS. Depending upon which products are taken, there are several domains that require delegating. These are:DNS Domain about.reuters.com customers.reuters.com extranet.reuters.biz session.rservices.com thomsonreuters.com extranet.thomsonreuters.biz cp.thomsonreuters.net trading.thomsonreuters.net 3000ip.rservices.com rds.rservices.com commerce.reuters.com dlinezrh.radianz.net fitrading.reuters.com fxtrading.reuters.com rtextrading.reuters.com rtextrading.integration.reuters.com rtextrading.demo.reuters.com fxmarketspace.reuters.com Authoritative DNS Server EDNS EDNS EDNS EDNS Internet EDNS EDNS / Internet EDNS / Internet EDNS EDNS EDNS /Internet BT DNS EDNS /Internet EDNS /Internet EDNS /Internet Internet EDNS /Internet EDNS Thomson Reuters Product All products All products; Xtra Help & FAQ All products 3000Xtra, Legacy 3000 Series (e.g. Securities 3000), EMT Products Future Internet products Future Extranet products Future Internet/Extranet products Reuters Trading 3000Xtra (US Only) Insert Link, Market Link Reuters Trader, Reuters Messaging, RDL Hosted Citrix (Zurich); 3000Xtra (EMEA customer via Direct Line Infrastructure) Reuters Trading for Fixed Income Reuters Trading for FX Reuters Trading for Exchanges Reuters Trading for Exchanges Certification Reuters Trading for Exchanges Demo FX Market Space Page 23
Version 5.01
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use /Internet EDNS EDNS /Internet Internet EDNS Internet EDNS / Internet BT DNS EDNS /Internet EDNS /Internet EDNS / Internet EDNS / Internet EDNS / Internet EDNS / Internet EDNS / Internet EDNS Internet Internet Internet Internet Internet Internet Internet Internet Internet Internet EDNS /Internet EDNS / Internet Internet BT DNS
futurestrading.reuters.com markets.reuters.com global.reuters.com ukb.reuters.com rtnfradianz.reuters.com Rtnfinternet.reuters.com rtnfblue.demo.fx.com
Reuters Trading for Futures - CME Reuters Dealing Link, 3000Xtra (IOI Plug-in), Reuters Messaging 3000Xtra HTA (v5.0.1) Reuters Trade Notification Service (RTNS) Reuters Trade Notification Service (RTNS) Demo Reuters Trade Notification Service (RTNS) Global Press Watch, Factiva News Watch Reuters Trader (EMT-Based), Reuters Wealth Manager Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging Reuters Knowledge, 3000Xtra Reuters Knowledge EcoWin Pro Reuters Data Scope Tick History Reuters News Scope Archive Lipper Product 3000Xtra (Re-direct to about.reuters.com) 3000Xtra (Loan Connector) 3000Xtra (First Know it) 3000Xtra (Scanrate) 3000Xtra (Europrospectus) Reuters Trading 3.1 Collaboration service 3000Xtra Any FCE services or other non-Thomson Reuters services which are hosted on the BT Extranet
radianz.factiva.com rapid.reuters.com sip.reuters.net collab.thomsonreuters.net collab.reuters.net space.reuters.com chat.reuters.com rmcm.reuters.net knowledge.reuters.net knowledge.reuters.com ecowin.com datascope.reuters.com newsscope.reuters.com emaxx.reuters.com kalends.com loanconnector.com firstknow.it rts.scanrate.dk europrospectus.com data.nordic.extranet.reuters.biz collab.thomsonreuters.net pdf.reuters.com radianz.net
Comment [G4]: Ive added this as a catch all.
Domain available on Internet customersa.reuters.com customers.reuters.com
Internet DNS Internet DNS
RWS Reuters Trader and RM
Without a proxy server, a client would not be able to access hosts in the domains reuters.com or reuters.net on the Internet. MX records for the reuters.com domain would also be inaccessible from this DNS server.
Version 5.01
Page 24
4.2.3 Client Proxy Server & Keystation Browser Settings If a client has a local Proxy server then each client keystation Internet browser should be configured to use the client Proxy server for Internet access. The option for bypassing the Proxy server for local addresses should be enabled and the box Exceptions Do not use proxy server for addresses beginning with: configured with the following exceptions:*.rservices.com;*.about.reuters.com;*.customers.reuters.com;*.fitrading.reuters.com;*.fxtrading.reuter s.com; *.futurestrading.reuters.com;*.markets.reuters.com;*.commerce.reuters.com; *.sip.reuters.net; *.dlinezrh.radianz.net; *.glbl1.reuters.com; *.radianz.factiva.com; *.rapid.reuters.com; *.knowledge.reuters.net; *.extranet.reuters.biz; *.rtextrading.reuters.com, *.thomsonreuter.com, *.extranet.thomsonreuters.biz, *.cp.thomsonreuters.net, *.trading.thomsonreuters.net, *.data.nordic.extranet.reuters.biz, *. collab.thomsonreuters.net The client Proxy server should be configured to use an ISPs DNS server or a different local client DNS server that forwards DNS queries to the Internet. This combination of the Windows 2000 delegation example, the local client Proxy server scenario, and the session.rservices.com delegation method described above, facilitates hostname resolution across all Thomson Reuters domains located on Distribution Extranets and Thomson Reuters hosts located on the Internet. These configurations have been successfully laboratory tested with a MS Proxy Server 2.0 and a Windows 2000 DNS server (local client DNS) configured with the delegation scenarios above and set to forward all other non-local queries to a set of Internet (ISP supplied) DNS servers.
4.2.4 Microsoft Windows 2000 DNS - Delegation Example The Microsoft DNS help files that come with the DNS server explain delegation & Microsoft W2K DNS server in detail and should be read and understood before setting up a new delegation. session.rservices.com delegation example: To Delegate this domain create a new Forward Lookup Zone (standard primary) called rservices.com. Once done - right click this new zone and choose "new delegation", the domain is called session Add the FQDN of the nearest EDNS server followed by the IP address & OK the selection. Windows 2K give you the option of having more than 1 DNS server per delegated domain so repeat the process for the other EDNS servers.
4.2.5 Non Windows 2000 Pre BIND 8.2.3 local Client DNS There are known issues with some earlier versions of BIND (both 8 and 4) DNS servers, including Microsoft Windows NT4 DNS, configured with a combination of delegation and forwarding. The issues arise because these servers forward the queries before delegating them, in this case forwarding to an Internet DNS before the delegated EEDNS. The Thomson Reuters products dual hosted across the Internet and Distribution Extranets will be resolved and accessible via the Internet. Thomson Reuters hosts in the reuters.com and reuters.net domains that are not available on the Internet ie only available on the Distribution Extranets will not be accessible. Name resolution within the session.rservices.com domain is retained because the Thomson Reuters maintained DNS servers on the Internet that are authoritative for the rservices.com domain are set to return a server failure error. This should then result in the local client DNS server sending the query to the appropriate delegated DNS server (In this case the EDNS Servers).
Version 5.01
Page 25
5. Client ILA Resolution

The ILA, or IDN Logical Address, contains a set of permissions that determine the Newsyear content that a user can view. These permissions determine access to certain News types as well as local language permissions. The ILA is a six digit hexadecimal number which is converted into IP Address format for resolution by the client PC. To do this the ILA is split into groups of 3 numbers with the first number in a dotted decimal notation (x.x.x.x) always 0 and the rest are the converted decimal figures from the hexadecimal figures of the original ILA. For example, an ILA of 023979 would have a dotted decimal notation of 0.2.57.121
The fully qualified domain name of the dotted decimal notation of the client ILA is ila.sserver.session.rservices.com. Non MDS sites typically would have this ILA entry stored locally on each keystation within the Hosts file. In the majority of MDS sites connected to Reuters Hosts via HPSN this ILA would have been located on the client session server. These MDS sites that are now connected to Reuters hosts via RadianzNet can locate the ILA on their DNS server. All keystations that query this DNS server will receive the same ILA and thus the same set of Historical News permissions. Clients that require a disparate set of ILA permissions across their offices, E.G. for local language permissioning, should implement the DNS solution on a regional, not global basis. The regional implementation will enable different permissions to be applied regionally. The Thomson Reuters Account Teams should carry out an assessment of the clients ILA permissions to determine the most appropriate solution. The following section describes the configuration required for a clients DNS server to respond to querying keystations with the dotted decimal notation of the ILA.
5.1 Local Client DNS Configuration

The local client DNS server should be made authoritative for the domain sserver.session.rservices.com and this domain to have a host record entry for the ila host. The IP address of this record entry is the client ILA in dotted decimal form. 5.1.1 Configuration example for BIND DNS server Although the following two sections describe this configuration example for a BIND 8.2.3 DNS server, the above concept should be equally valid for pre and post BIND 8.2.3 DNS servers.
5.1.1.1 named.conf The named.conf configuration file on the local BIND 8.2.3 DNS server should be updated with a new zone configured as follows:-
zone "sserver.session.rservices.com" IN {type master; file db.sserver.session.rservices"; notify yes;};
Version 5.01
Page 26
5.1.1.2 Zone File The db.sserver.session.rservices file configuration should match the following:sserver.session.rservices.com. IN ( 2 ; serial number 3600 ; refresh 600 ; retry 10086400 ; expire 3600 ) ; minimum TTL SOA morpheus.matrix.service.com. cypher.matrix.service.com
;Name Server Section for sserver.session.rservices.com sserver.session.rservices.com. IN NS morpheus.matrix.service.com. ; ;Host Addresses ; ila.sserver.session.rservices.com.
IN
x.x.x.x
Where x.x.x.x is the client ILA previously held within the site file on the session server, the server morpheus.matrix.service.com is the host name of the local client DNS server in this example
5.1.2 Configuration example for Windows Server 2003 DNS server Followings are steps to configure Windows Server 2003 DNS server to perform client ila resolution. 1. Go to Start => Administrative Tools => DNS
2.
Double click on Forward Lookup Zones
Version 5.01
Page 27
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use 3. Right click and select New Zone
4.
Windows will pop up a New Zone Wizard
5.
Click on Next
Version 5.01
Page 28
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use 6. By default, select the Primary zone and check Store the zone in Active Directory. Then, click on Next.
7. 8.
By default, select To all domain controllers in the Active Directory domain matrix.service.com In the Zone Name box, fill in sserver.session.rservices.com.
9.
Click on Next. Select Do not allow dynamic updates because we will update the records manually.
Version 5.01
Page 29
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use 10. Click on Next.
11. Click on Finish. The wizard box will disappear.
12. Double click on sserver.session.rservices.com.
13. Right click and select New Host (A)
Version 5.01
Page 30
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use 14. In the Name box, fill in ila. Then, fill in the client ILA in the IP Address box. Note that in this example, the client ILA is 0.68.3.25. Click on Add Host.
15. Windows will pop up a dialog informing that the host record ila.sserver.session.rservices.com was successfully created.
16. Click on Ok and Done
Version 5.01
Page 31
6. Appendix A
6.1 Reuters EMT Product DNS Integration
6.1.1 DNS Servers EDNS London New York Singapore IP Address 155.195.64.4 155.195.84.4 155.195.76.4 FQDN edns02.uk.extranet.reuters.biz edns02.us.extranet.reuters.biz edns02.sg.extranet.reuters.biz
IP Address 155.195.48.4 155.195.48.36 155.195.48.68
6.1.2 Reuters Trader Reuters Trader product needs to resolve two domain names. reuterstrader.session.rservices.com www4.commerce.reuters.com 6.1.2.1 No local DNS If the customer has no local DNS server then each RT keystation should be configured for DNS as described in the Client Workstation Resolver (No Customer DNS server) section of this document.
6.1.2.2 Local Client DNS If the customer has a local DNS server then each RT keystation should be configured with the local DNS server and this server should then be configured to integrate the above two domains. The ideal solution would be for the customer to selectively forward both of these two domains to the authoritative DNS servers. e.g. session.rservices.com and commerce.reuters.com queries should be selectively forwarded to the EDNS servers If the client does not have a DNS capable of selective forwarding then see integration examples in this document for non-selective forwarding capable DNS servers.
6.1.2.3 Reuters Trader desktop and the RMCD End User Workstations find out about the presence of an on-site RMCD, by a process known as P2PS discovery. There are three methods of P2PS discovery. In order of preference, they are: 1. Client DNS resourcename lookup Page 32
Version 5.01
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use 2. 3. Client DNS servicename lookup Local resourcename lookup
6.1.2.3.1 Client DNS resourcename lookup The client needs to add a host record entry for reuters-p2ps-pop into their local DNS server with the IP address of the RMCD server. The entry should be put in the same DNS domain as the default lookup domain of the RT keystations. E.g. If the default lookup domain of the client keystation is xxx.company.com where xxx is the host being resolved then the client needs the reuters-p2ps-pop host record entry added to the company.com domain. Thus the RT keystation will resolve IP address of the local RMCD server by doing a lookup of reuters-p2ps-pop.company.com upon RT startup. Note: If you are installing an in-house RMCD, then you must NOT place an entry into the IME DNS, you should use a local DNS, or use a local resourcename lookup Reuters Trader log entries are shown below 24/11/2003 12:04:12.906 PID=1752 TID=1592 0 Performing P2PS Discovery... 24/11/2003 12:04:12.906 PID=1752 TID=1592 0 P2PS Discovery enabled: true 24/11/2003 12:04:12.916 PID=1752 TID=1592 0 Resolving service _triarch_sink._tcp 24/11/2003 12:04:12.926 PID=1752 TID=1592 0 Resolving host reuters-p2ps-pop 24/11/2003 12:04:28.588 PID=1752 TID=1592 0 P2P hosts are 172.20.20.12
RTRUPS RTRUPS RTRUPS RTRUPS RTRUPS
CUpsUnique CUpsUnique CUpsUnique CUpsUnique CUpsUnique
6.1.2.3.2 Client DNS servicename lookup This works on the basis of performing a dnsapi.dll lookup. This process will involve making changes to a client's DNS. However, this dnsapi.dll function is not contained with NT4 so Reuters Trader on NT4 will not work with DNS servicename lookup. The end user workstation will do an SRV lookup to its primary client DNS. The SRV name is fixed and set to _triarch_sink._tcp . The dnsapi.dll API is used to perform this lookup. This means that the client must have the proper DNS domain name suffix configured on his PC and that the client DNS serving this domain name has the following SRV record: _triarch_sink._tcp As defined by RFC-2782. IN SRV 0 5 <pop_port> <pop_name>
Version 5.01
Page 33
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use To test whether or not the client PC is correctly configured (once the SRV record has been added to the DNS):
The above screenshot is from our test Reuters Trader workstation. You should achieve similar results (IP addresses will differ). The next page shows the SRV records as entered into our Win 2000 DNS. Note: Win 2003 DNS does not perform SRV lookups correctly, so Reuters Trader and RMCD with Win2003 DNS machines will not work.
The above screenshot shows that service _triarch_sink._tcp is port 8101 on machine stevea.dtclab.com.
Version 5.01
Page 34
The above screenshot shows that stevea.dtclab.com is IP address 172.20.20.12 please compare this with the nslookup screenshot earlier, and also the Reuters Trader log entry, shown below. 24/11/2003 12:04:12.906 PID=1752 TID=1592 0 Performing P2PS Discovery... 24/11/2003 12:04:12.906 PID=1752 TID=1592 0 P2PS Discovery enabled: true 24/11/2003 12:04:12.916 PID=1752 TID=1592 0 Resolving service _triarch_sink._tcp 24/11/2003 12:04:28.588 PID=1752 TID=1592 0 P2P hosts are 172.20.20.12 RTRUPS RTRUPS RTRUPS RTRUPS CUpsUnique CUpsUnique CUpsUnique CUpsUnique
6.1.2.3.3 Local resourcename lookup This is a standard entry into the hosts file of the Reuters Trader terminal that associates the name reuters-p2ps-pop with the IP address of the RMCD server. Reuters Trader log entries are shown below 24/11/2003 12:04:12.906 PID=1752 TID=1592 RTRUPS CUpsUnique 0 Performing P2PS Discovery... 24/11/2003 12:04:12.906 PID=1752 TID=1592 RTRUPS CUpsUnique 0 P2PS Discovery enabled: true 24/11/2003 12:04:12.916 PID=1752 TID=1592 RTRUPS CUpsUnique 0 Resolving service _triarch_sink._tcp 24/11/2003 12:04:12.926 PID=1752 TID=1592 RTRUPS CUpsUnique 0 Resolving host reuters-p2ps-pop 24/11/2003 12:04:28.588 PID=1752 TID=1592 RTRUPS CUpsUnique 0 P2P hosts are 172.20.20.12
Version 5.01
Page 35
6.2 Reuters DNS Domain

6.2.1 By Product Family Product Family All Products Product Domains about.reuters.com customers.reuters.com customersa.reuters.com customerst.reuters.com session.rservices.com extranet.reuters.biz 3000IP.rservices.com dlinezrh.radianz.net Emaxx.reuters.com Kalends.com Loanconnector.com firstknow.it rts.scanrate.dk europrospectus.com pdf.reuters.com global.reuters.com ukb.reuters.com No DNS Used No DNS Used As per 3000Xtra As per Reuters Station rapid.reuters.com commerce.reuters.com channel.reuters.com No DNS Used markets.reuters.com data.nordic.extranet.reuters.biz Comments Online Support and Customer Zone (note; Xtra customers have a alternate) Xtra Help & FAQ Are obsolete but customers may have them bookmarked All installations All installations US only. Customers supported via BladeRunner (i.e. hosted RMDS). European customers supported via Direct Line Infrastructure (i.e. hosted RMDS). Internet Only Internet Only Internet Only Internet Only Internet Only Internet Only Internet Only Internet Only (BT Radianz using extranet.reuters.biz) Applies if all data sourced from BDN
Reuters Xtra
Reuters 3000 Xtra
Reuters 3000 Xtra Hosted Terminal Access Reuters Station Reuters Dealing 3000 Reuters Trader (Kobra) Reuters Trader North America Reuters Trader (EMT) Reuters Trader (Bridge Channel) Reuters First (Nordic) Reuters Dealing Link Reuters Trader 3.1
Reuters Trader
Internet Only
Version 5.01
Page 36
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use Reuters Knowledge Wealth Management RKIM, RKIB, RKC Reuters Wealth Manager Reuters Plus Reuters Investor Future Products knowledge.reuters.net, knowledge.reuters.com -- Internet rapid.reuters.com commerce.reuters.com RXN DNS not used session.rservices.com thomsonreuters.com extranet.thomsonreuters.biz cp.thomsonreuters.net trading.thomsonreuters.net Domains No client-facing DNS required NO DNS Used extranet.reuters.biz datascope.reuters.com newsscope.reuters.com No client-facing DNS required session.rservices.com rds.rservices.com extranet.reuters.biz RXN DNS not used RXN DNS not used markets.reuters.com RXN DNS not used fitrading.reuters.com trading.thomsonreuters.net fxtrading.reuters.com rtextrading.reuters.com rtextrading.integration.reuters.com rtextrading.demo.reuters.com trading.thomsonreuters.net data.nordic.extranet.reuters.biz fxmarketspace.reuters.com Comments
Product Family Enterprise Information
Reuters Information Management
Reuters Enterprise Connectivity
Product Reuters Datascope Real-Time Datascope On-Site Datascope Select Reuters Data Scope Tick History Reuters News Scope Archive RMDS Contributions (Insertlink, Marketlink) Contributions (Insertlink, Marketlink) Inhibit Manager Reuters Order Routing for Commodities Reuters Order Routing for Equities Reuters IOI Reuters Order Management for Exchange Execution Reuters Trading for Fixed Income Reuters Trading for FX Reuters Electronic Trading for Exchange
Internet Only EDNS or BT DNS / Internet EDNS / Internet EDNS / Internet
Reuters FX Market Space
Version 5.01
Page 37
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use Reuters Trade Notification Service rtnfradianz.reuters.com Rtnfinternet.reuters.com rtnfblue.demo.fx.com sip.reuters.net commerce.reuters.com collab.thomsonreuters.net collab.reuters.net space.reuters.com chat.reuters.com rmcm.reuters.net
Reuters Messaging
6.2.2 By Domain
Customer Facing
Domain 3000ip.rservices.com session.rservices.com rds.rservices.com about.reuters.com commerce.reuters.com customers.reuters.com dlinezrh.radianz.net fitrading.reuters.com fxtrading.reuters.com trading.thomsonreuters.net rtextrading.reuters.com rtextrading.integration.reuters.com rtextrading.demo.reuters.com trading.thomsonreuters.net futurestrading.reuters.com rtnfradianz.reuters.com rtnfinternet.reuters.com rtnfblue.demo.fx.com Description 3000IP Session Based IP hosts. EMT Products RDS Online support services EMT Products, RM, Transactions Products Customerzone Hosted Citrix (Zurich) Reuters Trading for Fixed Income Reuters Trading for FX Reuters Trading for Exchanges Product(s) 3000Xtra 3000Xtra, Legacy 3000 series (e.g. Securities 3000) InsertLink, MarketLink All products Reuters Trader, Reuters Messaging, RDL All products 3000Xtra Reuters Trading Family Reuters Trading Family Reuters Trading Family Comments US only. Customers supported via BladeRunner (i.e. hosted RMDS)
Access to Restricted Data Set functionality
Xtra Help & FAQ EMEA customers via Direct Line Infrastructure.
Reuters Trading for Futures CME Reuters Trade Notification Service
Reuters Trading Family Reuters Trading Family
Version 5.01
Page 38
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use fxmarketspace.reuters.com data.nordic.extranet.reuters.biz global.reuters.com ukb.reuters.com markets.reuters.com radianz.factiva.com rapid.reuters.com sip.reuters.net knowledge.reuters.net knowledge.reuters.com ecowin.com datascope.reuters.com newsscope.reuters.com extranet.reuters.biz eemaxx.reuters.com kkalends.com Loanconnector.com firstknow.it rts.scanrate.dk europrospectus.com thomsonreuters.com extranet.thomsonreuters.biz cp.thomsonreuters.net collab.thomsonreuters.net pdf.reuters.com collab.reuters.net space.reuters.com chat.reuters.com rmcm.reuters.net FX Market Space Reuters Trading 3.1 Hosted Citrix Transactions (RDL) Factiva Rapid RM Reuters Knowledge EcoWin Pro Reuters Data Scope Tick History Reuters News Scope Archive All product Lipper Product 3000Xtra (Re-direct to about.reuters.com) 3000Xtra (Loan Connector) 3000Xtra (First Know it) 3000Xtra (Scanrate) 3000Xtra (Europrospectus) Internet-only service (strategic) Private extranet-only service (strategic) Common cross-network service (strategic) Cross-network collaboration service (strategic) ASX Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging Reuters Trading Family Reuters Trading Family 3000Xtra HTA (v5.0.1) Reuters Dealing Link 3000 Xtra (IOI Plug-In) Global Press Watch Factiva News Search Reuters Trader (EMT-Based) Reuters Messaging Reuters Knowledge, 3000Xtra Reuters Knowledge Reuters Datascope Reuters Datascope All Products (going forward) 3000Xtra 3000Xtra 3000Xtra 3000Xtra 3000Xtra 3000Xtra Future products Future products Future products Stand-alone collaboration product 3000Xtra Reuters Messaging Reuters Messaging Reuters Messaging Reuters Messaging
Internet
Direct access to Factiva (note, Xtra uses gpw.session.rservices.com)
Version 5.01
Page 39
Obsolete
Domain qtcl.reuters.com bex.reuters.com loginabout.reuters.com barraone.compelling-content.com customersa.reuters.com customerst.reuters.com nda.reuters.com xtra.reuters.com mpd.compelling-content.com iportal.reuters.com Description New Products Bex Login server for Customerzone Barraone Customerzone Customerzone Web Views Web Views Market Place Data Iportal Description Service Management Domain (Reuters Systems) Internal Reuters Testing New Products on BT Radianz Infrastructure or RXN Product(s) Bond Express Comments
Obsolete but customers may have it bookmarked Obsolete but customers may have it bookmarked
Replaced with credit-content.session.rservices.com
Internal Only
Domain osn.reuters.com test.reuters.com infra.reuters.biz Product(s) Management of Reuters ClientSited Equipment DataFeed to IDN Infrastructure Comments
Version 5.01
Page 40
7. Appendix B
7.1 EDNS GSLB
7.1.1 What is GSLB? The GSLB (Global Server Load Balancers), can balance content requests across two or more servers which hold the same content, but are in different locations on the Distribution Extranet (live/live services). In addition, to balancing the requests, the GSLB devices also health check all of the servers to ensure that clients are only directed to servers which are currently on-line. This increases service reliability and facilitates services running from live/standby data centres. Alongside each EDNS is a GSLB device (Cisco GSS), hence there are three GSLB devices serving the Distribution Extranets. 7.1.2 How do the EDNS and GSLB work together? A small number of load balanced domains are delegated to the GSLB devices from the EDNS (see below). For each load balanced hostname, there are multiple IP address records together with a health check metric (ICMP Ping) and a load balance metric (Round Robin). When clients make a DNS request for a load balanced hostname, the type of query sent and hence the subsequent response depends upon the client site DNS type. Client Sending Recursive Queries to EDNS For a Client Workstation Resolver, or from a client site DNS which is configured with selective forwarding (the recommended configuration), a recursive query is sent to the EDNS. If the requested hostname is one which is delegated to the GSLB devices, then the EDNS will either respond with a cached A-record answer, or will query the GSLB on the clients behalf and then return the A-record answer (non authoritative) to the client. Client Sending Iterative Queries to EDNS Clients with older DNS systems (BIND pre-8.2.3, or Microsoft DNS prior 2003) may be using delegation or those with BIND 8.2.3 or later, or Windows 2003 or later who are not following the recommendation and are also using delegation, will send an iterative DNS query to the EDNS. If the requested hostname is one which is delegated to the GSLB devices, then in most cases, the client making the iterative request will receive an A-record answer from the EDNS cache. Occasionally, the client may receive a referral to go and ask the GSLB rather than an A-record answer. When a client DNS queries the GSLB server, it will get an A-record answer (authoritative). If the clients DNS is unable to reach the GSLB devices due to strict outbound firewall rules, then the referral cannot be followed and the DNS resolution will fail. To be sure that a client DNS can reach the GSLB devices as well as the EDNS devices, it is recommended that the following IP address ranges are allowed through any client site firewalls.
Source Address Clients DNS server(s)
Destination Address 155.195.64.0/28 155.195.76.0/28 155.195.84.0/28
Port UDP 53
Note: This is not necessary for client site with workstation resolver only (no client DNS), or for client site DNS which is configured with selective forwarding (the recommended option).
Version 5.01
Page 41
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use Load Balanced Domains As stated above, a small number of domains (or hosts) are delegated to the GSLB devices. Load balanced hosts have multiple IP addresses associated with them. Each IP address is periodically health checked by the GSLB. When a GSLB device receives a DNS request, it only returns healthy addresses records. The order of the A-records returned is adjusted to balance the load across the multiple IP addresses (servers).
Load Balanced Domains armstrong.session.rservices.com haz01.cfi.session.rservices.com hkt01.cfi.session.rservices.com gtc01.cfi.session.rservices.com gtc02.cfi.session.rservices.com gtc03.cfi.session.rservices.com stc01.cfi.session.rservices.com htc01.cfi.session.rservices.com gva01.cfi.session.rservices.com gva02.cfi.session.rservices.com gva03.cfi.session.rservices.com
The table above includes all of the domains that are delegated to the GSLB devices.
Version 5.01
Page 42
Recursive Query for Load Balanced Host Example: In this example: The client DNS is BIND 8.2.3 or later using selective forwarding mode, or Microsoft Windows 2003 Server using conditional forwarding The client DNS is selective forwarding session.rservices.com domain to EDNS The client PC is trying to resolve armstrong.session.rservices.com
The client PC sends a (recursive) DNS query for armstrong.session.rservices.com to the clients local DNS server. The clients DNS server selectively forwards a recursive request to the EDNS. The EDNS server accepts the recursive query and either responds with an answer from its local cache, or queries the GSLB if the record is not cached. If queried, the GSLB will respond to the EDNS. Either way, the EDNS sends a response back to the client DNS, which in turn responds to the client PC.
Version 5.01
Page 43
Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use Iterative (non-recursive) Query for Load Balanced Host Example: In this example: The client DNS is WinNT or Windows 2000 DNS The client DNS is configured with Internet forwarders and is configured to be authoritative for rservices.com and delegate session.rservices.com to the EDNS servers. The client PC is trying to resolve armstrong.session.rservices.com
The client PC sends a (recursive) DNS query for armstrong.session.rservices.com to the clients local DNS server. The clients DNS is delegating session.rservices.com to the EDNS and so it sends an iterative request to the EDNS. The EDNS server accepts the iterative query and either responds with an answer from its local cache, or if the record is not cached, it sends a referral with the three GSLB name and IP addresses back to the client DNS. If the client DNS receives an answer then it is sent back to the client PC. If the client DNS receives a referral then it needs to follow the referral and query the GSLB (a new iterative query is sent). The GSLB will respond back to the client DNS which in turn responds to the client PC. Testing GSLB using NSLookup From a client site DNS or workstation that has access to the Distribution Extranets, it should be possible to test access to the GSLB devices. nslookup [RTN] server <IP of GSLB device> [RTN] armstrong.session.rservices.com [RTN] [should return the IP addresses of the Armstrong servers as below] Name: armstrong.session.rservices.com Address: 155.195.64.88 etc. Testing GSLB using dig dig @<IP of GSLB device > armstrong.session.rservices.com [RTN] [should return the IP addresses of the Armstrong servers as below] ;; ANSWER SECTION: armstrong.session.rservices.com. 30 IN A 155.195.64.88 etc. NOTE: The above test should be repeated for all the GSLB regions. (UK, NY, and Singapore).
Region London New York Singapore
EDNS edns02.uk.extranet.reuters.biz 155.195.64.4 edns02.us.extranet.reuters.biz 155.195.84.4 edns02.sg.extranet.reuters.biz 155.195.76.4
EDNS GSLB Device egslb01.uk.extranet.reuters.biz 155.195.64.12 egslb01.us.extranet.reuters.biz 155.195.84.12 egslb01.sg.extranet.reuters.biz 155.195.76.12
The table above shows the FQDN and IP address for the EDNS and GSLB devices.
End of Document
Version 5.01
Page 44

DNSintegration5 01

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

DNSintegration5 01

Încărcat de

Drepturi de autor:

Formate disponibile

Client Site DNS Integration Guide Thomson Reuters Customer and Internal Use

Status: Version: Approved:

Solos ARTHACHINDA Worport Sinsukthavorn Nachanont Jaijamnong

01 June 2009 DNSintegration5_01.doc

Table of References Reference

4.25 4.26 4.27

20NOV2008 11DEC2008 16DEC2008

N JAIJAMNONG N JAIJAMNONG N JAIJAMNONG

4.28 4.29 4.30 4.31 5.00 5.0.1

15JAN09 24FEB09 27FEB09 27FEB09 27APR09 01JUN2009

N JAIJAMNONG W SINSUKTHAVORN S ARTHACHINDA S ARTHACHINDA G LEES S ARTHACHINDA

1.1 Choice of Domain Name

1.2 DNS Services on the Distribution Extranets

This change will take place on 25 April 2009 Page 7

Recommended DNS BT DNS

Alternative DNS EDNS

EDNS London New York Singapore

IP Address 155.195.64.4 155.195.84.4 155.195.76.4

FQDN edns02.uk.extranet.reuters.biz edns02.us.extranet.reuters.biz edns02.sg.extranet.reuters.biz

BT DNS London New York Singapore

IP Address 155.195.48.4 155.195.48.36 155.195.48.68

FQDN londnsaa001a.radianz.net hpggnsba001a.radianz.net sinsnsba001a.radianz.net

1.3 Client DNS Name Resolution on the Distribution Extranets

Not until a Selective Forwarding Capable DNS server is deployed. Yes

To resolve Internet hostnames a local DNS server should be deployed.

Administration of new local DNS.

BIND 8.2.3 or Later

Microsoft Windows 2003 DNS Server

Yes (called conditional forwarding)

1.4 Recommended Client Sited DNS Implementation

1.5 Other DNS Configurations

1.6 Thomson Reuters Failover Services

2. Client Workstation Resolver (No Client DNS server)

BT Radianz Infrastructure or RXN

IRG DNS 155.195.64.4

RXN DNS 155.195.48.4

2.1 Configuration Workstation

BT DNS London New York Singapore

IP Address 155.195.48.4 155.195.48.36 155.195.48.68

FQDN londnsaa001a.radianz.net hpggnsba001a.radianz.net sinsnsba001a.radianz.net

3. Selective Forwarding Name Resolution

3.1 Thomson Reuters Domain Names that require Selective Forwarding

rtextrading.demo.reuters.com fxmarketspace.reuters.com futurestrading.reuters.com markets.reuters.com global.reuters.com ukb.reuters.com rtnfradianz.reuters.com Rtnfinternet.reuters.com rtnfblue.demo.fx.com

Comment [G3]: Ive added this as a catch all.

Domain available on Internet customersa.reuters.com customers.reuters.com

Internet DNS Internet DNS

RWS Reuters Trader and RM

3.2 Selective Forwarding Example

RXN DNS 155.195.48.4

BT Radianz Infrastructure or RXN

LOCAL DNS 10.6.10.1

{155.195.64.4; 155.195.84.4;155.195.76.4;}; forward only

EDNS London New York Singapore

IP Address 155.195.64.4 155.195.84.4 155.195.76.4

FQDN edns02.uk.extranet.reuters.biz edns02.us.extranet.reuters.biz edns02.sg.extranet.reuters.biz

Right click the server and go to Properties

Click on the Forwarders tab

EDNS London New York Singapore

IP Address 155.195.64.4 155.195.84.4 155.195.76.4

FQDN edns02.uk.extranet.reuters.biz edns02.us.extranet.reuters.biz edns02.sg.extranet.reuters.biz

4. Non-Selective Forwarding Name Resolution

4.1 Scenario A - Client DNS Forwards to the Delivery Extranet Servers