Pat Lashley wrote:
I would expect anyone using a real domain (as in using a real TLD,
and a name registered at a domain registrar) to have a unicast DNS
server.
But those servers are typically outside the firewall (or in a DMZ).
Their purpose is to advertise the publicly visible hosts. The LAN(s)
behind the firewall typically use a completely different DNS server. And
often one or more subdomains that are not normally exposed to the public.
Also, as is pointed out in draft-cheshire-dnsext-dns-sd.txt:
Note that the DNS-SD service does NOT have to be provided by the same
DNS server hardware that is currently providing an organization's
conventional host name lookup service (the service we traditionally
think of when we say "DNS"). By delegating the "_tcp" subdomain, all
the workload related to DNS-SD can be offloaded to a different
machine. This flexibility, to handle DNS-SD on the main DNS server,
or not, at the network administrator's discretion, is one of the
things that makes DNS-SD so compelling.
(I'm not sure why they don't mention the _udp subdomain here.)
Yes, what's your point? SD records are plain DNS records and should
be treated for exactly what they are. SD records in a unicast DNS
environment would of course obey the rules of unicast DNS (including
delegation to other servers).
And from draft-cheshire-dnsext-multicastdns.txt:
Multicast DNS Domains are not delegated from their parent domain via
use of NS records. There are no NS records anywhere in Multicast DNS
Domains. Instead, all Multicast DNS Domains are delegated to the IP
addresses 224.0.0.251 and FF02::FB by virtue of the individual
organizations producing DNS client software deciding how to handle
those names. It would be extremely valuable for the industry if this
special handling were ratified and recorded by IANA, since otherwise
the special handling provided by each vendor is likely to be
inconsistent.
The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
IPv6 name server for a Multicast DNS Domain is FF02::FB. These are
multicast addresses; therefore they identify not a single host but a
collection of hosts, working in cooperation to maintain some
reasonable facsimile of a competently managed DNS zone. Conceptually
a Multicast DNS Domain is a single DNS zone, however its server is
implemented as a distributed process running on a cluster of loosely
cooperating CPUs rather than as a single process running on a single
CPU.
Yes, I'm aware of this. And SD records in a multicast DNS environment
should obey the rules of mDNS.
The problem and thing we seem to disagree on is whether SD records
outside the .local domain should be allowed to be resolved using
mDNS by default.
Given that, in a situation where there is a unicast DNS server(*), the
standard nsswitch order should be 'files dns mdns', with the DNS server
containing records to delegate .local, .254.169.in-addr.arpa, and
._{tcp,udp}.$(local domain) to the mDNS IP address(es).
How are you going to delegate between protocols?, while DNS and
mDNS share the same PDU format, they should be treated as separate
protocols.
We may want to add those delegations to our default BIND configuration
files. Possibly commented-out with a 'Uncomment these if you want to use
mDNS or mDNS-SD on your LAN' comment.
Do you mean a NS record pointing to the mDNS multicast address?, that
doesn't seem right and will most likely confuse normal DNS clients
and servers.
For example the server would not be multicast aware, and if it does
get a reply to one of its queries it will originate from a different
ip than to which the query was sent.
Otherwise they have no "right" to use that name, even if
it is only in a local network.
WRONG! Once you register a name, you have the right to use it; you are
NOT required to provide ANY publicly available DNS records for it. Of
course, if you don't, it will only be useful internally; but there are
situations where that's desirable. (You also have the right to not use
it at all; in which case you are just preventing anyone else from using
it.)
I was referring to the use of a domain with a real TLD that you didn't
register at a domain registrar (and might belong to somebody else).
Of course if you own a domain you can use it as you like.
>> I don't say that we shouldn't support it, but it should not be on by
>> default. And it will actually boil down to what the mdns nss module
>> allows.
>
> I agree that it should not be on by default. But there should be one
> simple knob in rc.conf to cause service advertisements to be published
> for both .local and the host domain. Any thing more complex would
> require editing mdns.conf.
Publishing announcements is one thing, what the nss mdns module allows
a host to resolve is what will limit its initial usage.
It should allow clients to resolve -any- service-related records that
are available as defined in the protocol. BUT please note that service
browsers and clients will normally only -search- in one default domain
or in a list of domains provided by {b,db,r,dr,lb}._dns-sd._udp
services. And that clients will normally include domain information in
the list of choices presented to the user.
I agree that there should be a separate knob for whether to to try mDNS
for name resolution for names outside the .local domain. And I think
that the knob should have at least four states: ".local only", ".local
and this host's domain", ".local and .{_tcp,_udp}.*" and "anything".
We have been over this already and concluded that the mdns nss module
should only allow (in its default state) queries to a few selected
domains. SD records are just *plain* (m)dns records and will have to
obey the same rules as any other records. _tcp.local. would be allow
to be resolved via mDNS while _tcp.example.com would not.
However, we *might* ship with a default configuration to the mdns nss
module that would add {_tcp,_udp}.* to the set of domains that
the nss module would allow to be resolved.
A Service Discovery browser application that utilize the mDNS API
directly would of course be allowed to do any type of query.
But queries going through the more generalized NSS environment should
be restricted by default.
Fredrik Lindberg
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
