In message , Tony Finch
writes:
> Mark Andrews wrote:
> >
> > See https://tools.ietf.org/html/rfc6763 for details of how it is
> > designed to work. Section 11 shows how to go from IP address and
> > netmask to the forward domain where the _dns-sd._udp subdomains
> > reside.
> >
> > lb._dns-sd.
Mark Andrews wrote:
>
> See https://tools.ietf.org/html/rfc6763 for details of how it is
> designed to work. Section 11 shows how to go from IP address and
> netmask to the forward domain where the _dns-sd._udp subdomains
> reside.
>
> lb._dns-sd._udp.0.43.168.136.in-addr.arpa PTR
At Cambridge
There should be NO need for this if you setup service discovery
properly for the network. If done properly you go from IP address
and netmask to a delegated forward domain which accepts update
requests from the devices on the network. Unfortunately the Presto
documentation sucks when it comes to
On 6/27/17 12:13 PM, Michael W. Fleming wrote:
We're setting up a wireless printing service that uses
Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's
own dns server for a private, on-campus only zone (presto.). We're
running bind 9.9 with a master server, three slaves and tw
--
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Michael
W. Fleming
Sent: Tuesday, June 27, 2017 12:14 PM
To: bind-users@lists.isc.org
Subject: Problem w/ Forwarding Zone in Caching-Only Config
We're setting up a wireless printing service that uses
Zeroconf/bonjour/ren
We're setting up a wireless printing service that uses
Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's
own dns server for a private, on-campus only zone (presto.). We're
running bind 9.9 with a master server, three slaves and two caching-only
servers (anycasted to 136.168.255.
6 matches
Mail list logo