Internet Engineering Task Force T. Pusateri
Internet-Draft Seeking affiliation
Intended status: Standards Track April 1, 2015
Expires: October 3, 2015

DNS-SD Hybrid Proxy Implementation Advice
draft-pusateri-hybridproxy-impl-00

Abstract

This document provides advice on the implementation of a DNS Service Discovery Hybrid Proxy Server. It describes the configuration parameters at the delegating DNS server, the hybrid proxy itself, and the client. It also describes the resource records required of the delegating DNS server and the hybrid proxy.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 3, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

A hybrid proxy [I-D.ietf-dnssd-hybrid] 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.

2. Delegating DNS Server

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.

2.1. @delegating_server.subdomain_ns

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.

Example NS Records
Delegation Class Type Hybrid Proxy
subdomain1.example.com. IN NS foo.example.com.
subdomain1.example.com. IN NS bar.example.com.
subdomain2.example.com. IN NS hba.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.

2.2. @delegating_server.subdomain_browse_ptr

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.

Example PTR Records
Browse Service Class Type Delegation
b._dns-sd._udp IN PTR subdomain1.example.com.
b._dns-sd._udp IN PTR subdomain2.example.com.

3. Hybrid Proxy Configuration

3.1. @hybrid_proxy.subdomain

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.

  1. The subdomain name can be configured manually or distributed by an out of band method.
  2. 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.
  3. 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.

3.2. @hybrid_proxy.ns_delegation_name

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.

3.3. @hybrid_proxy.ns_delegation_name_address_records

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.

3.4. Hybrid Proxy Records

The hybrid proxy must answer the following resource records when queried:

  1. SOA record - SOA for <subdomain>.<zone> with MNAME the same as the NS delegation name.
  2. Browse domain record - PTR b._dns-sd._udp.<subdomain>.<zone> with NAME pointing to the fully qualified <subdomain>.<zone>.
  3. Legacy browse domain record - PTR lb._dns-sd._udp.<subdomain>.<zone> with NAME pointing to the fully qualified <subdomain>.<zone>.

Additionally, if LLQ [I-D.sekar-dns-llq] and/or DNS Push [I-D.ietf-dnssd-push] is supported, the hybrid proxy must answer to these additional records:

  1. LLQ over UDP - SRV _dns-llq._udp.<subdomain>.<zone> with target as NS delegation name
  2. LLQ over TCP - SRV _dns-llq._tcp.<subdomain>.<zone> with target as NS delegation name
  3. 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.

3.5. @hybrid_proxy.udp_port

Port 53, forwarded to by delegating DNS server

3.6. @hybrid_proxy.udp_llq_port

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

3.7. @hybrid_proxy.tcp_llq_port

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

3.8. @hybrid_proxy.tcp_push_port

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

4. Client Configuration

4.1. @unicast_client.search_domains

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.

5. Hybrid Proxy Startup

Can we auto-configure?

  1. query PTR for each local interface address looking for name
  2. 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?

  1. query through a local resolver for PTR records for b._dns-sd._udp.<zone>, noting connected subdomains
  2. 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.
  3. 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.
  4. ensure that one and only one hybrid proxy on the IP subnet responds as the SOA for the subdomain. (TBD)
  5. 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>.
  6. 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>.
  7. If DNS Push is supported, install _dns-push._tcp.<subdomain>.<zone> SRV and advertise _dns-push._tcp.local on IP subnet corresponding to <subdomain>.
  8. 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.

6. IANA Considerations

This document has no IANA considerations.

7. Security Considerations

There are no security considerations at this time.

8. References

8.1. Normative References

[I-D.ietf-dnssd-hybrid] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service Discovery", Internet-Draft draft-ietf-dnssd-hybrid-00, November 2014.

8.2. Informative References

[I-D.ietf-dnssd-push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", Internet-Draft draft-ietf-dnssd-push-00, March 2015.
[I-D.sekar-dns-llq] Sekar, K., "DNS Long-Lived Queries", Internet-Draft draft-sekar-dns-llq-01, August 2006.

Author's Address

Tom Pusateri Seeking affiliation Hilton Head Island, SC USA Phone: +1 843 473 7394 EMail: pusateri@bangj.com