If there is no response policy configured, when the DNS server received a query for an A
record, it returns the exact record set queried. The following displays example
output:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.3.85 application01.example.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6380
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;application01.example.com. IN A
;; ANSWER SECTION:
application01.example.com. 10 IN A 172.20.3.51
;; AUTHORITY SECTION:
example.com. 86400 IN NS dns-primary-1.example.com.
;; ADDITIONAL SECTION:
dns-primary-1.example.com. 86400 IN A 192.168.3.85
;; Query time: 0 msec
;; SERVER: 192.168.3.85#53(192.168.3.85)
;; WHEN: Thu Apr 7 09:18:47 UTC 2024
;; MSG SIZE rcvd: 113
When an application is configured in GSS, the search order is written to DNS as SRV
records in the gss.bluecat zone. In each SRV record, the name of the record
identifies the application and the client region. The priority represents the priority
of an answer region and the target of the record is an A record set that represents
available answers. In the SRV record, the target name has a prefix "unlinked" that
prevents linking in Address Manager. The prefix should be removed to find the target
record as displayed in the following
example:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.3.86 singapore.host.application01.example.com.gss.bluecat. srv
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13617
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;singapore.host.application01.example.com.gss.bluecat. IN SRV
;; ANSWER SECTION:
singapore.host.application01.example.com.gss.bluecat. 10 IN SRV 1 0 0 unlinked.singapore.active.application01.example.com.gss.bluecat.
singapore.host.application01.example.com.gss.bluecat. 10 IN SRV 3 0 0 unlinked.london.active.application01.example.com.gss.bluecat.
singapore.host.application01.example.com.gss.bluecat. 10 IN SRV 2 0 0 unlinked.tokyo.active.application01.example.com.gss.bluecat.
;; AUTHORITY SECTION:
gss.bluecat. 86400 IN NS dns-primary-1.example.com.
;; ADDITIONAL SECTION:
dns-primary-1.example.com. 86400 IN A 192.168.3.85
;; Query time: 0 msec
;; SERVER: 192.168.3.86#53(192.168.3.86)
;; WHEN: Thu Apr 7 09:07:43 UTC 2024
;; MSG SIZE rcvd: 381
In this example, removing the prefix on the highest priority target makes Singapore the
target answer region. GSS uses the active answer in Singapore for this client region
when an answer is available. The following displays example
output:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.3.86 singapore.active.application01.example.com.gss.bluecat.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9468
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;singapore.active.application01.example.com.gss.bluecat. IN A
;; ANSWER SECTION:
singapore.active.application01.example.com.gss.bluecat. 10 IN A 192.168.4.51
;; AUTHORITY SECTION:
gss.bluecat. 86400 IN NS dns-primary-1.example.com.
;; ADDITIONAL SECTION:
dns-primary-1.example.com. 86400 IN A 192.168.3.85
;; Query time: 0 msec
;; SERVER: 192.168.3.86#53(192.168.3.86)
;; WHEN: Thu Apr 7 09:10:28 UTC 2024
;; MSG SIZE rcvd: 154
The answer is then added to the RPZ zone for clients in Singapore as displayed in the
following
example:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.3.86 application01.example.com.singapore.rpz.gss.bluecat.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65189
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;application01.example.com.singapore.rpz.gss.bluecat. IN A
;; ANSWER SECTION:
application01.example.com.singapore.rpz.gss.bluecat. 10 IN A 192.168.4.51
;; AUTHORITY SECTION:
singapore.rpz.gss.bluecat. 86400 IN NS dns-primary-1.example.com.
;; ADDITIONAL SECTION:
dns-primary-1.example.com. 86400 IN A 192.168.3.85
;; Query time: 0 msec
;; SERVER: 192.168.3.86#53(192.168.3.86)
;; WHEN: Thu Apr 7 09:16:24 UTC 2024
;; MSG SIZE rcvd: 151
In the example, the Singapore DNS server has this zone configured as a RPZ zone. Although
the IP address of
application01.example.com is 172.20.3.51, when
querying the Singapore DNS server, it returns the answer from the Singapore RPZ zone.
The authority section in the following reply identifies the RPZ zone that provided the
response:; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.3.87 application01.example.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37497
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;application01.example.com. IN A
;; ANSWER SECTION:
application01.example.com. 10 IN A 192.168.4.51
;; AUTHORITY SECTION:
singapore.rpz.gss.bluecat. 86400 IN NS dns-primary-1.example.com.
;; ADDITIONAL SECTION:
dns-primary-1.example.com. 86400 IN A 192.168.3.85
;; Query time: 1 msec
;; SERVER: 192.168.3.87#53(192.168.3.87)
;; WHEN: Thu Apr 7 09:22:39 UTC 2024
;; MSG SIZE rcvd: 139