Internet DRAFT - draft-pusateri-hybridproxy-impl
draft-pusateri-hybridproxy-impl
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.
Pusateri Expires October 3, 2015 [Page 1]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Delegating DNS Server . . . . . . . . . . . . . . . . . . . . 3
2.1. @delegating_server.subdomain_ns . . . . . . . . . . . . . 3
2.2. @delegating_server.subdomain_browse_ptr . . . . . . . . . 3
3. Hybrid Proxy Configuration . . . . . . . . . . . . . . . . . 4
3.1. @hybrid_proxy.subdomain . . . . . . . . . . . . . . . . . 4
3.2. @hybrid_proxy.ns_delegation_name . . . . . . . . . . . . 5
3.3. @hybrid_proxy.ns_delegation_name_address_records . . . . 5
3.4. Hybrid Proxy Records . . . . . . . . . . . . . . . . . . 5
3.5. @hybrid_proxy.udp_port . . . . . . . . . . . . . . . . . 6
3.6. @hybrid_proxy.udp_llq_port . . . . . . . . . . . . . . . 6
3.7. @hybrid_proxy.tcp_llq_port . . . . . . . . . . . . . . . 6
3.8. @hybrid_proxy.tcp_push_port . . . . . . . . . . . . . . . 6
4. Client Configuration . . . . . . . . . . . . . . . . . . . . 7
4.1. @unicast_client.search_domains . . . . . . . . . . . . . 7
5. Hybrid Proxy Startup . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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.
Pusateri Expires October 3, 2015 [Page 2]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
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.
+-------------------------+-------+------+------------------+
| 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. |
+-------------------------+-------+------+------------------+
Table 1: Example NS Records
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.
+----------------+-------+------+-------------------------+
| Browse Service | Class | Type | Delegation |
+----------------+-------+------+-------------------------+
| b._dns-sd._udp | IN | PTR | subdomain1.example.com. |
| b._dns-sd._udp | IN | PTR | subdomain2.example.com. |
+----------------+-------+------+-------------------------+
Table 2: Example PTR Records
Pusateri Expires October 3, 2015 [Page 3]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
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
Pusateri Expires October 3, 2015 [Page 4]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
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:
Pusateri Expires October 3, 2015 [Page 5]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
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
Pusateri Expires October 3, 2015 [Page 6]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
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.
Pusateri Expires October 3, 2015 [Page 7]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
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", draft-ietf-dnssd-hybrid-00 (work in progress),
November 2014.
8.2. Informative References
[I-D.ietf-dnssd-push]
Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-00 (work in progress), March 2015.
Pusateri Expires October 3, 2015 [Page 8]
Internet-Draft DNSSD-HybridProxy-Impl April 2015
[I-D.sekar-dns-llq]
Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
llq-01 (work in progress), August 2006.
Author's Address
Tom Pusateri
Seeking affiliation
Hilton Head Island, SC
USA
Phone: +1 843 473 7394
Email: pusateri@bangj.com
Pusateri Expires October 3, 2015 [Page 9]
