Add peering .service and .node DNS lookups.

[hashi-derek]

This PR improves support for DNS lookups on peered .service and .node queries. Prior to this PR, peered lookups were only supported for .virtual queries.

Node Lookups

For .node lookups, only A and AAAA queries are supported in Consul. New .peer and .dc qualifiers are introduced into OSS, similar to Enterprise, which allows users to specify between the two.

In OSS, existing node lookups had a format of mynode.node.dc1.some-domain.

Now they can also be queried with any of the following:

• mynode.node.dc1.some-domain
• mynode.node.dc1.dc.some-domain
• mynode.node.peer1.peer.some-domain

With peered nodes only being accessible via the .peer qualifier.

Service Lookups

For .service DNS lookups, SRV records are supported in addition to the standard A and AAAA that nodes have. Similar to nodes, they have been given extra qualifiers to indicate .peer and .dc lookups.

In OSS, existing service lookups had a format of mysvc.service.dc1.some-domain.

Now they can also be queried with any of the following:

• mysvc.service.dc1.some-domain
• mysvc.service.dc1.dc.some-domain
• mysvc.service.peer1.peer.some-domain

Since SRV records can return the FQDN of a node, the following outputs are now expected:

;; ANSWER SECTION:
mysvc.service.consul.	0	IN	SRV	1 1 9001 mylocalnode.node.dc1.some-domain.


;; ANSWER SECTION:
mysvc-peered.service.consul.	0	IN	SRV	1 1 9001 mypeernode.node.peer1.peer.some-domain.

With the local node response format being unchanged by this PR.

Addr Lookups

Consul supports the concept of an .addr lookup, which essentially provides an IP address in DNS form. They often look like c0a8017b.addr.dc1.some-domain where c0a8017b is a hex-encoded IP address. These are typically sent back as a response in an SRV record whenever there is no valid FQDN alternative to use.

These lookups technically do not query the state store at all, and are simply parsed and converted from hexadecimal format into a real IP address before responding.

For addr lookups, both of the following formats are equivalent and supported prior to this PR:

;; ANSWER SECTION:
c0a8017b.addr.dc1.some-domain. 0	IN	A	192.168.1.123

;; ANSWER SECTION:
c0a8017b.addr.some-domain. 0	IN	A	192.168.1.123

The .dc1 is effectively ignored since only basic text-parsing is performed.

For peering, whenever we respond in an SRV record with a .addr, we will emit it without the .dc1 component so that it is more clear that it is not an IP address that is part of the local DC. This is mostly a cosmetic change, but could provide value for some users that wish to distinguish the two apart.

;; ANSWER SECTION:
mysvc.service.some-domain.	0	IN	SRV	1 1 9001 c0a8017b.addr.dc1.some-domain.

;; ANSWER SECTION:
mysvc-peered.service.some-domain.	0	IN	SRV	1 1 9001 c0a8017b.addr.some-domain.

PTR Lookups

These are still unsupported for peering, as the format of 1.0.0.127.in-addr.arpa is fixed, and would introduce a potential breaking change if a peering connection was introduced into the existing list. IP addresses on peered services could potentially conflict with that of the local datacenter, and should therefore be excluded.

[DanStough]

LGTM 👍