react-native-zeroconf 0.13.8 → 0.15.0

package/android/src/main/jni/mdnsresponder/LICENSE

@@ -0,0 +1,13 @@
+The majority of the source code in the mDNSResponder project is licensed
+under the terms of the Apache License, Version 2.0, available from:
+   <http://www.apache.org/licenses/LICENSE-2.0>
+
+To accommodate license compatibility with the widest possible range
+of client code licenses, the shared library code, which is linked
+at runtime into the same address space as the client using it, is
+licensed under the terms of the "Three-Clause BSD License".
+
+The Linux Name Service Switch code, contributed by National ICT
+Australia Ltd (NICTA) is licensed under the terms of the NICTA Public
+Software Licence (which is substantially similar to the "Three-Clause
+BSD License", with some additional language pertaining to Australian law).

package/android/src/main/jni/mdnsresponder/Makefile

@@ -0,0 +1,41 @@
+#
+# Top level makefile for Build & Integration.
+# 
+# This file is used to facilitate checking the mDNSResponder project
+# directly out of CVS and submitting to B&I at Apple.
+#
+# The various platform directories contain makefiles or projects
+# specific to that platform.
+#
+#    B&I builds must respect the following target:
+#         install:
+#         installsrc:
+#         installhdrs:
+#         clean:
+#
+
+include /Developer/Makefiles/pb_makefiles/platform.make
+
+MVERS = "mDNSResponder-320.10.80"
+
+DDNSWRITECONFIG = "$(DSTROOT)/Library/Application Support/Bonjour/ddnswriteconfig"
+
+installSome:
+	cd "$(SRCROOT)/mDNSMacOSX"; xcodebuild install     OBJROOT=$(OBJROOT) SYMROOT=$(SYMROOT) DSTROOT=$(DSTROOT) MVERS=$(MVERS) SDKROOT=$(SDKROOT) -target Build\ Some
+
+SystemLibraries:
+	cd "$(SRCROOT)/mDNSMacOSX"; xcodebuild install     OBJROOT=$(OBJROOT) SYMROOT=$(SYMROOT) DSTROOT=$(DSTROOT) MVERS=$(MVERS) SDKROOT=$(SDKROOT) -target SystemLibraries
+
+install:
+	cd "$(SRCROOT)/mDNSMacOSX"; xcodebuild install     OBJROOT=$(OBJROOT) SYMROOT=$(SYMROOT) DSTROOT=$(DSTROOT) MVERS=$(MVERS) SDKROOT=$(SDKROOT)
+	# Make sure ddnswriteconfig is owned by root:wheel, then make it setuid root executable
+	if test -e $(DDNSWRITECONFIG) ; then chown 0:80 $(DDNSWRITECONFIG) ; chmod 4555 $(DDNSWRITECONFIG) ; fi
+
+installsrc:
+	ditto . "$(SRCROOT)"
+
+installhdrs::
+	cd "$(SRCROOT)/mDNSMacOSX"; xcodebuild installhdrs OBJROOT=$(OBJROOT) SYMROOT=$(SYMROOT) DSTROOT=$(DSTROOT) MVERS=$(MVERS) SDKROOT=$(SDKROOT)  -target SystemLibraries
+
+clean::
+	echo clean

package/android/src/main/jni/mdnsresponder/NOTICE

@@ -0,0 +1,13 @@
+The majority of the source code in the mDNSResponder project is licensed
+under the terms of the Apache License, Version 2.0, available from:
+   <http://www.apache.org/licenses/LICENSE-2.0>
+
+To accommodate license compatibility with the widest possible range
+of client code licenses, the shared library code, which is linked
+at runtime into the same address space as the client using it, is
+licensed under the terms of the "Three-Clause BSD License".
+
+The Linux Name Service Switch code, contributed by National ICT
+Australia Ltd (NICTA) is licensed under the terms of the NICTA Public
+Software Licence (which is substantially similar to the "Three-Clause
+BSD License", with some additional language pertaining to Australian law).

package/android/src/main/jni/mdnsresponder/PrivateDNS.txt

@@ -0,0 +1,275 @@
+Private DNS
+
+Summary
+
+Private DNS is an extension to standard Wide Area Bonjour that allows
+for secure, encrypted, and authorized communications. Private data sent
+from a client to a DNS server is encrypted using Transport Layer
+Security (TLS), ensuring that the data is hidden from prying eyes, and
+contains Transaction Signatures (TSIG), so the server can authorize the
+request. TSIGs are typically associated with Dynamic Updates; we are
+using them for standard and long-lived queries as well. Private DNS also
+protects Dynamic Updates from eavesdropping, by wrapping the update in a
+TLS communication channel if the server has been configured appropriately.
+
+Architectural Overview
+
+mDNSResponder has been modified to automatically issue a private query
+when necessary. After receiving an NXDOMAIN error, mDNSResponder checks
+in the system keychain to see if the user has a DNS query key (TSIG key)
+for the name in question, or for a parent of that name. If a suitable
+key is found, mDNSResponder looks up the zone data associated with the
+name of the question. After determining the correct name server,
+mDNSResponder looks up an additional SRV record "_dns-private._tcp". If
+it finds this record, mDNSResponder will re-issue the query privately.
+If either there is no _dns-private._tcp record, or there is no secret
+key, the call fails as it initially did, with an NXDOMAIN error.
+
+Once the secret key is found and the SRV record is looked up, mDNSResponder
+opens a TLS connection to the server on the port specified in the SRV
+record just looked up. After the connection succeeds, mDNSResponder
+can proceed to use that communication channel to make requests of
+the server. Every private packet must also have a TSIG record;
+the DNS server uses this TSIG record to allow access to its data.
+
+When setting up a long-lived query over TCP (with or without TLS)
+TCP's standard three-way handshake makes the full four-packet LLQ setup
+exchange described in <http://files.dns-sd.org/draft-sekar-dns-llq.txt>
+unnecessary. Instead, when connecting over TCP, the client simply sends
+a setup message and expects to receive ACK + Answers. The setup message
+sent is formatted as described in the LLQ document, however there is
+an additional TSIG' resource record added to the end of it. The TSIG
+resource records looks and acts exactly as it does in a secure update.
+So when the server receives an LLQ (or a standard query), it looks to
+see if the zone that is being referenced is public or private. If it's
+private, then it makes sure that the client is authorized to query that
+zone (by using the TSIG signature) and returns the appropriate data.
+When a zone is configured as private, the server will do this type of
+authorization checking for every query except those queries that are
+looking for SOA and NS records.
+
+Implementation Issues
+
+dnsextd
+
+dnsextd has been modified to behave much like a DNS firewall. The "real"
+DNS server is configured to listen on non-standard ports on the loopback
+interface. dnsextd then listens on the standard DNS ports (TCP/UDP port
+53) and intercepts all DNS traffic. It is responsible for determining
+what zone a DNS request is associated with, determining whether the
+client is allowed access to that zone, and returning the appropriate
+information back to the caller. If the packet is allowed access, dnsextd
+forwards the request to the "real" nameserver, and returns the result to
+the caller.
+
+It was tempting to use BIND9's facility for configuring TSIG enabled
+queries while doing this work. However after proceeding down that path,
+enough subtle interaction problems were found that it was not practical
+to pursue this direction, so instead dnsextd does all TSIG processing
+for queries itself. It does continue to use BIND9 for processing TSIG
+enabled dynamic updates, though one minor downside with this is that
+there are two configuration files (named.conf or dnsextd.conf) that have
+the same secret key information. That seems redundant and error-prone,
+and moving all TSIG processing for both queries and updates into dnsextd
+would fix this.
+
+All private LLQ operations are TSIG-enabled and sent over a secure
+encrypted TLS channel. To accommodate service providers who don't want
+to have to keep open a large number of TLS connections to a large number
+of client machines, the server has the option of dropping the TLS
+connection after initial LLQ setup and sending subsequent events and
+refreshes using unencrypted UDP packets. This results in less load on
+the server, at the cost of slightly lower security (LLQs can only be set
+up by an authorized client, but once set up, subsequent change event
+packets sent over unencrypted UDP could be observed by an eavesdropper).
+A potential solution to this deficiency might be in using DTLS, which is
+a protocol based on TLS that is capable of securing datagram traffic.
+More investigation needs to be done to see if DTLS is suitable for
+private DNS.
+
+It was necessary to relax one of the checks that dnsextd performs during
+processing of an LLQ refresh. Prior to these changes, dnsextd would
+verify that the refresh request came from the same entity that setup the
+LLQ by comparing both the IP Address and port number of the request
+packet with the IP Address and port number of the setup packet. Because
+of the preceding issue, a refresh request might be sent over two
+different sockets. While their IP addresses would be the same, their
+port numbers could potentially differ. This check has been modified to
+only check that the IP addresses match.
+
+When setting up a semi-private LLQ (where the request and initial answer
+set is sent over TLS/TCP, but subsequent change events are sent over
+unencrypted UDP), dnsextd uses the port number of the client's TCP
+socket to determine the UDP event port number. While this eliminates the
+need to pass the UDP event port number in the LLQ setup request
+(obviating a potential data mismatch error), I think it does more harm
+than good, for three reasons:
+
+1) We are relying that all the routers out there implement the Port
+   Mapping Protocol spec correctly.
+
+2) Upon setup every LLQ must NAT map two ports. Upon tear down every LLQ
+   must tear down two NAT mappings.
+
+3) Every LLQ opens up two sockets (TCP and UDP), rather than just the
+   one TCP socket.
+
+All of this just to avoid sending two bytes in the LLQ setup packet
+doesn't seem logical. The approach also necessitates creating an
+additional UDP socket for every private LLQ, port mapping both the TCP
+socket as well as the UDP socket, and moderately increasing the
+complexity and efficiency of the code. Because of this we plan to allow
+the LLQ setup packet to specify a different UDP port for change event
+packets. This will allow mDNSResponder to receive all UDP change event
+packets on a single UDP port, instead of a different one for each LLQ.
+
+Currently, dnsextd is buggy on multi-homed hosts. If it receives a
+packet on interface 2, it will reply on interface 1 causing an error in
+the client program.
+
+dnsextd doesn't fully process all of its option parameters.
+Specifically, it doesn't process the keywords: "listen-on",
+"nameserver", "private", and "llq". It defaults to expecting the "real"
+nameserver to be listening on 127.0.0.1:5030.
+
+
+mDNSResponder
+
+Currently, mDNSResponder attempts to issue private queries for all
+queries that initially result in an NXDOMAIN error. This behavior might
+be modified in future versions, however it seems patently incorrect to
+do this for reverse name lookups. The code that attempts to get the zone
+data associated with the name will never find the zone for a reverse
+name lookup, and so will issue a number of wasteful DNS queries.
+
+mDNSResponder doesn't handle SERV_FULL or STATIC return codes after
+setting up an LLQ over TCP. This isn't a terrible problem right now,
+because dnsextd doesn't ever return them, but this should be fixed so
+that mDNSResponder will work when talking to other servers that do
+return these error codes.
+
+
+Configuration:
+
+Sample named.conf:
+
+//
+// Include keys file
+//
+include "/etc/rndc.key";
+// Declares control channels to be used by the rndc utility.
+//
+// It is recommended that 127.0.0.1 be the only address used.
+// This also allows non-privileged users on the local host to manage
+// your name server.
+
+//
+// Default controls
+//
+controls
+	{
+	inet 127.0.0.1 port 54 allow { any; } keys { "rndc-key"; };
+	};
+
+options
+	{
+	directory "/var/named";
+	/*
+	 * If there is a firewall between you and nameservers you want
+	 * to talk to, you might need to uncomment the query-source
+	 * directive below. Previous versions of BIND always asked
+	 * questions using port 53, but BIND 8.1 uses an unprivileged
+	 * port by default.
+	 */
+	
+	forwarders
+			{
+			65.23.128.2;
+			65.23.128.3;
+			};
+	
+	listen-on port 5030 { 127.0.0.1; };
+	recursion true;
+	};
+
+// 
+// a caching only nameserver config
+// 
+zone "." IN
+	{
+	type hint;
+	file "named.ca";
+	};
+
+zone "localhost" IN
+	{
+	type master;
+	file "localhost.zone";
+	allow-update { none; };
+	};
+
+zone "0.0.127.in-addr.arpa" IN
+	{
+	type master;
+	file "named.local";
+	allow-update { none; };
+	};
+
+zone "hungrywolf.org." in
+	{
+	type master;
+	file "db.hungrywolf.org";
+	allow-update { key hungrywolf.org.; };
+	};
+
+zone "157.23.65.in-addr.arpa" IN
+	{
+	file "db.65.23.157";
+	type master;
+	};
+
+zone "100.255.17.in-addr.arpa" IN
+	{
+	file "db.17.255.100";
+	type master;
+	};
+
+zone "66.6.24.in-addr.arpa" IN
+	{
+	file "db.24.6.66";
+	type master;
+	};
+
+key hungrywolf.org.
+	{
+	algorithm hmac-md5;
+	secret "c8LWr16K6ju6KMO5zT6Tyg==";
+	};
+
+logging
+	{
+	category default { _default_log; };
+
+	channel _default_log
+		{
+		file "/Library/Logs/named.log";
+		severity info;
+		print-time yes;
+		};
+	};
+
+
+Sample dnsextd.conf:
+
+options { };
+
+key "hungrywolf.org."
+	{
+	secret "c8LWr16K6ju6KMO5zT6Tyg==";
+	};
+
+zone "hungrywolf.org."
+	{
+	type private;
+	allow-query { key hungrywolf.org.; };
+	};

package/android/src/main/jni/mdnsresponder/README.txt

@@ -0,0 +1,166 @@
+What is mDNSResponder?
+----------------------
+
+The mDNSResponder project is a component of Bonjour,
+Apple's ease-of-use IP networking initiative:
+<http://developer.apple.com/bonjour/>
+
+Apple's Bonjour software derives from the ongoing standardization
+work of the IETF Zero Configuration Networking Working Group:
+<http://zeroconf.org/>
+
+The Zeroconf Working Group has identified three requirements for Zero
+Configuration Networking:
+1. An IP address (even when there is no DHCP server to assign one)
+2. Name-to-address translation (even when there is no DNS server)
+3. Discovery of Services on the network (again, without infrastucture)
+
+Requirement 1 is met by self-assigned link-local addresses, as
+described in "Dynamic Configuration of IPv4 Link-Local Addresses"
+<http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt>
+
+Requirement 2 is met by sending DNS-like queries via Multicast (mDNS).
+
+Requirement 3 is met by DNS Service Dicsovery (DNS-SD).
+
+Self-assigned link-local address capability has been available since
+1998, when it first appeared in Windows '98 and in Mac OS 8.5.
+Implementations for other platforms also exist.
+
+The mDNSResponder project allows us to meet requirements 2 and 3.
+It provides the ability for the user to identify hosts using names
+instead of dotted-decimal IP addresses, even if the user doesn't have a
+conventional DNS server set up. It also provides the ability for the
+user to discover what services are being advertised on the network,
+without having to know about them in advance, or configure the machines.
+
+The name "mDNS" was chosen because this protocol is designed to be,
+as much as possible, similar to conventional DNS. The main difference is
+that queries are sent via multicast to all local hosts, instead of via
+unicast to a specific known server. Every host on the local link runs an
+mDNSResponder which is constantly listening for those multicast queries,
+and if the mDNSResponder receives a query for which it knows the answer,
+then it responds. The mDNS protocol uses the same packet format as
+unicast DNS, and the same name structure, and the same DNS record types.
+The main difference is that queries are sent to a different UDP port
+(5353 instead of 53) and they are sent via multicast to address
+224.0.0.251. Another important difference is that all "mDNS" names
+end in ".local." When a user types "yourcomputer.local." into their Web
+browser, the presence of ".local." on the end of the name tells the host
+OS that the name should be looked up using local multicast instead of by
+sending that name to the worldwide DNS service for resolution. This
+helps reduce potential user confusion about whether a particular name
+is globally unique (e.g. "www.apple.com.") or whether that name has only
+local significance (e.g. "yourcomputer.local.").
+
+
+About the mDNSResponder Code
+----------------------------
+
+Because Apple benefits more from widespread adoption of Bonjour than
+it would benefit from keeping Bonjour proprietary, Apple is making
+this code open so that other developers can use it too.
+
+Because Apple recognises that networks are hetrogenous environments
+where devices run many different kinds of OS, this code has been made
+as portable as possible.
+
+A typical mDNS program contains three components:
+
+    +------------------+
+    |   Application    |
+    +------------------+
+    |    mDNS Core     |
+    +------------------+
+    | Platform Support |
+    +------------------+
+
+The "mDNS Core" layer is absolutely identical for all applications and
+all Operating Systems.
+
+The "Platform Support" layer provides the necessary supporting routines
+that are specific to each platform -- what routine do you call to send
+a UDP packet, what routine do you call to join multicast group, etc.
+
+The "Application" layer does whatever that particular application wants
+to do. It calls routines provided by the "mDNS Core" layer to perform
+the functions it needs --
+ * advertise services,
+ * browse for named instances of a particular type of service
+ * resolve a named instance to a specific IP address and port number,
+ * etc.
+The "mDNS Core" layer in turn calls through to the "Platform Support"
+layer to send and receive the multicast UDP packets to do the actual work.
+
+Apple currently provides "Platform Support" layers for Mac OS 9, Mac OS X,
+Microsoft Windows, VxWorks, and for POSIX platforms like Linux, Solaris,
+FreeBSD, etc.
+
+Note: Developers writing applications for OS X do not need to incorporate
+this code into their applications, since OS X provides a system service to
+handle this for them. If every application developer were to link-in the
+mDNSResponder code into their application, then we would end up with a
+situation like the picture below:
+
+  +------------------+    +------------------+    +------------------+
+  |   Application 1  |    |   Application 2  |    |   Application 3  |
+  +------------------+    +------------------+    +------------------+
+  |    mDNS Core     |    |    mDNS Core     |    |    mDNS Core     |
+  +------------------+    +------------------+    +------------------+
+  | Platform Support |    | Platform Support |    | Platform Support |
+  +------------------+    +------------------+    +------------------+
+
+This would not be very efficient. Each separate application would be sending
+their own separate multicast UDP packets and maintaining their own list of
+answers. Because of this, OS X provides a common system service which client
+software should access through the "/usr/include/dns_sd.h" APIs.
+
+The situation on OS X looks more like the picture below:
+
+                                   -------------------
+                                  /                   \
+  +---------+    +------------------+    +---------+   \  +---------+
+  |  App 1  |<-->|    daemon.c      |<-->|  App 2  |    ->|  App 3  |
+  +---------+    +------------------+    +---------+      +---------+
+                 |    mDNS Core     |
+                 +------------------+
+                 | Platform Support |
+                 +------------------+
+
+Applications on OS X make calls to the single mDNSResponder daemon
+which implements the mDNS and DNS-SD protocols. 
+
+Vendors of products such as printers, which are closed environments not
+expecting to be running third-party application software, can reasonably
+implement a single monolithic mDNSResponder to advertise all the
+services of that device. Vendors of open systems which run third-party
+application software should implement a system service such as the one
+provided by the OS X mDNSResponder daemon, and application software on
+that platform should, where possible, make use of that system service
+instead of embedding their own mDNSResponder.
+
+See ReadMe.txt in the mDNSPosix directory for specific details of
+building an mDNSResponder on a POSIX Operating System.
+
+
+Compiling on Older C Compilers
+------------------------------
+
+We go to some lengths to make the code portable, but //-style comments
+are one of the modern conveniences we can't live without.
+
+If your C compiler doesn't understand these comments, you can transform
+them into classical K&R /* style */ comments with a quick GREP
+search-and-replace pattern.
+
+In BBEdit on the Mac:
+1. Open the "Find" dialog window and make sure "Use Grep" is selected
+2. Search For  : ([^:])//(.*)
+3. Replace With: \1/*\2 */
+4. Drag your mDNSResponder source code folder to the Multi-File search pane
+5. Click "Replace All"
+
+For the more command-line oriented, cd into your mDNSResponder source code
+directory and execute the following command (all one line):
+
+find mDNSResponder \( -name \*.c\* -or -name \*.h \) -exec sed -i .orig -e 's,^//\(.*\),/*\1 */,' -e '/\/\*/\!s,\([^:]\)//\(.*\),\1/*\2 */,' {} \;

package/android/src/main/jni/mdnsresponder/README.version

@@ -0,0 +1,3 @@
+URL: http://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-320.10.80.tar.gz
+Version: 320.10.80
+BugComponent: 31808

package/android/src/main/jni/mdnsresponder/android/caseMapping/Iphlpapi.h

@@ -0,0 +1 @@
+#include <iphlpapi.h>

package/android/src/main/jni/mdnsresponder/android/caseMapping/README

@@ -0,0 +1,3 @@
+Windows filesystems, and consequently Windows C include files, are
+case-insensitive. This folder provides alternately-cased versions of header
+files for cases where that becomes a problem.

package/android/src/main/jni/mdnsresponder/android/caseMapping/Resource.h

@@ -0,0 +1 @@
+#include <resource.h>

package/android/src/main/jni/mdnsresponder/android/caseMapping/Ws2tcpip.h

@@ -0,0 +1 @@
+#include <ws2tcpip.h>

package/android/src/main/jni/mdnsresponder/android/caseMapping/ipExport.h

@@ -0,0 +1 @@
+#include <ipexport.h>

package/android/src/main/jni/mdnsresponder/android/windows_firewall_dummy.c

@@ -0,0 +1,10 @@
+int mDNSIsFileAndPrintSharingEnabled(int *ignored) {
+  (void)ignored;
+  return 0;
+}
+
+int mDNSAddToFirewall(const char* ignored, const char* also_ignored) {
+  (void)ignored;
+  (void)also_ignored;
+  return 0;
+}