DNS-SD Hybrid Proxy Implementation Advice

A hybrid proxy dynamically maps between the multicast DNS link-local infrastructure and the wide-area unicast DNS infrastructure. Externally, it looks like a standard unicast DNS server. Internally, instead of static resource records, it builds a cache of resource records that it learns dynamically on an interface where mDNS is used. These resource records are mapped to a location in the unicast DNS hierarchy by associating a subdomain with each IP subnet. Responses to queries made for resource records in the subdomain are filled by a dynamic cache of records learned dynamically from the IP subnet. Unicast queries received by the hybrid proxy may trigger mDNS queries from the hybrid proxy to the IP subnet associated with the subdomain. If subscriptions are active for the record in a query, the hybrid proxy will already have an up to date cache and no mDNS queries are triggered.

The delegating DNS server requires configuration of the subdomain delegations and the browse PTR records for each subdomain. All configuration parameters are in the form '@entity.parameter' for easy identification.

This configuration item is for each hybrid proxy on each subdomain. The delegating DNS server will have NS records for each hybrid proxy for the subdomain on each IP subnet it is connected. There maybe multiple NS records for the same subdomain for each hybrid proxy. Delegation Class Type Hybrid Proxy subdomain1.example.com.INNSfoo.example.com. subdomain1.example.com.INNSbar.example.com. subdomain2.example.com.INNShba.example.com. If the DNS name of the hybrid proxy is within the delegating server's zone, it will also have address records for the hybrid proxy.

This configuration item is for each subdomain. In order for clients to learn about all of the subdomains it should browse for services, the delegating DNS server should have a browse PTR record for each subdomain. Browse Service Class Type Delegation b._dns-sd._udpINPTRsubdomain1.example.com. b._dns-sd._udpINPTRsubdomain2.example.com.

This configuration item is for each IP subnet. The hybrid proxy must determine which subdomain name to associate with each connected IP subnet. If multiple hybrid proxies exist on the same IP subnet, this subdomain name should be consistent across all hybrid proxies on that IP subnet. There are several different ways that a hybrid proxy can determine the subdomain name of it's connected IP subnets. The subdomain name can be configured manually or distributed by an out of band method. The hybrid proxy can query legacy browse domain PTR records for the network portion of the interface address. Suppose an interface on the hybrid proxy is configured with IP address 192.0.2.1/24. The network portion is 192.0.2.0/24. A query is made for lb._dns-sd._udp.0.2.0.192.in-addr.arpa. For IPv6, the extension for PTR address queries is ip6.arpa. All hybrid proxies on the IP subnet will make the same query since the network portion is the same for all of them. The returned name will be <subdomain>.<zone>, where <zone> is the delegating zone. As an example, this could be foo.example.com where example.com is the domain name distributed through DHCP or SLAAC and foo is the assigned subdomain. If the hybrid proxy does not know the base domain name or know which domain name from a list of search domains to respond to, the domain name returned from this query can be used as a indicator. The left most label is the subdomain and the remainder is the base domain name or zone. This domain name could be different on each connected IP subnet of a particular hybrid proxy, especially in a multi-tenant environment. The hybrid proxy can use a naming algorithm where each proxy will arrive at the same value using the supplied algorithm. The hybrid proxy will have to learn the zone through another means such as DHCP or SLAAC. No particular algorithm should be mandated but an example of such an algorithm would be to create a hexadecimal string based on the network portion of the interface IP address. For the example above with interface IP address 192.0.2.1/24, the hexadecimal string of the network portion would be C0000200. This string could be prefixed with ASCII characters if desired resulting in a subdomain of netc0000200.example.com. All hybrid proxies with an interface on the same subnet can independently compute the same subdomain name. This might be challenging in a multi-vendor environment.

This configuration item is for each IP subnet. In order for the hybrid to function as an authoritative server for a subdomain, the subdomain must be delegated by the DNS server responsible for the zone it is delegated from. The hybrid proxy must know the NS record delegation name and the address for which to listen for queries that are forwarded. Before the delegation server will forward queries to the delegated hybrid proxy for a subdomain, it will query the NS record for the subdomain from the hybrid proxy to ensure it will accept queries for the subdomain. In the case of multiple hybrid proxies, the delegating server will have multiple NS record delegations and will select one based on local policy to forward requests to.

This configuration item is for each @hybrid_proxy.ns_delegation_name The address records must refer to active addresses (IPv4 or IPv6) on the hybrid proxy.

The hybrid proxy must answer the following resource records when queried: SOA record - SOA for <subdomain>.<zone> with MNAME the same as the NS delegation name. Browse domain record - PTR b._dns-sd._udp.<subdomain>.<zone> with NAME pointing to the fully qualified <subdomain>.<zone>. Legacy browse domain record - PTR lb._dns-sd._udp.<subdomain>.<zone> with NAME pointing to the fully qualified <subdomain>.<zone>. Additionally, if LLQ and/or DNS Push is supported, the hybrid proxy must answer to these additional records: LLQ over UDP - SRV _dns-llq._udp.<subdomain>.<zone> with target as NS delegation name LLQ over TCP - SRV _dns-llq._tcp.<subdomain>.<zone> with target as NS delegation name DNS Push - SRV _dns-push._tcp.<subdomain>.<zone> with target as NS delegation name Since there may be multiple LLQ and/or DNS Push SRV records for each subdomain (one for each hybrid proxy), each hybrid proxy should return all of the SRV records from each hybrid proxy on the IP subnet. Otherwise only a subset of SRV records may be cached and load balancing may not be effective. In order for each hybrid proxy to learn about the other hybrid proxy's SRV records, each hybrid proxy should advertise its own SRV records for LLQ and/or DNS Push through mDNS on the shared IP subnet. Because there should only be one SOA record for the delegated subdomain, a mechanism is needed to ensure only one hybrid proxy advertises the SOA record for the delegated subdomain. (TBD) This satisfies the minimum configuration requirements but it is likely that additional parameters will be desired. Examples include the port numbers to listen for mandatory TLS or policy to determine which services get advertised to which unicast clients.

Port 53, forwarded to by delegating DNS server

Port 53, 5352, or custom, advertised in SRV record

Random port, advertised in SRV record, one will be assigned in DPRIVE for TLS/TCP

A unicast client will not necessarily need to know the name or IP address of the hybrid proxy. It can send unicast queries to the local resolver learned through DHCP or SLAAC. However, if long-lived queries (LLQ) or DNS Push Notifications are wanted, a direct connection from the client to the hybrid proxy is needed. This will require discovery of the name and IP address of a hybrid proxy for the subdomain. Based on the search domains learned (typically via DHCP or SLAAC), the client will want to query for the list of subdomains that are browseable. This is a PTR query for b._dns-sd._udp.<zone> for each search domain. This will return the list of subdomains to browse. The client can then make sure each subdomain is browseable with a PTR query to b._dns-sd._udp.<subdomain>.<zone>. Responses to this query will enable the client to then search for services in that subdomain using PTR queries for the service name. Clients may also query lb._dns-sd._udp.<subdomain>.<zone> for legacy browsing of the subdomain.

Can we auto-configure? query PTR for each local interface address looking for name query PTR for legacy browseable reverse network name looking for subdomain Otherwise, we receive local configuration by other means. Are the DNS records in the delegating zone setup correctly for the hybrid proxy to function? query through a local resolver for PTR records for b._dns-sd._udp.<zone>, noting connected subdomains query through a local resolver for NS record for each local subdomain that is connected and make sure the query arrives back to the hybrid proxy, send the response, and verify that the response is received. If these PTR and NS records are not in place, the hybrid proxy may wish to install the records through DNS Update if this option is available. The hybrid proxy may choose to not listen for queries until these records are present. query through a local resolver for PTR record for b._dns-sd._udp.<subdomain>.<zone> for each connected subdomain that passed the NS record test. This request will also be answered by the hybrid proxy. ensure that one and only one hybrid proxy on the IP subnet responds as the SOA for the subdomain. (TBD) If LLQ is supported over UDP, install _dns-llq._udp.<subdomain>.<zone> SRV and advertise _dns-llq._udp.local on IP subnet corresponding to <subdomain>. If LLQ is supported over TCP, install _dns-llq._tcp.<subdomain>.<zone> SRV and advertise _dns-llq._tcp.local on IP subnet corresponding to <subdomain>. If DNS Push is supported, install _dns-push._tcp.<subdomain>.<zone> SRV and advertise _dns-push._tcp.local on IP subnet corresponding to <subdomain>. Whether or not a hybrid proxy supports LLQ or DNS Push, the proxy must listen for other hybrid proxies on each IP subnet advertising the LLQ and DNS Push records and cache these for future SRV queries that may be forwarded to a hybrid proxy.

This document has no IANA considerations.

There are no security considerations at this time.