>> 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).
My point is that it doesn't really matter whether anyone using a real domain
already has a unicast DNS server. That does not provide any impediment at all
if they wish to use mDNS for service discovery. Or even for link-local host
lookups in their domain. (By either delegating their domain if the request was
from within the LAN or creating a sub-domain that is always delegated.)
> 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.
I have no problem with having that off by default; as long as it can be turned
on through the use of a single simple knob in rc.conf. (And that all of the
rc.conf mDNS and LLA knobs be setable from the sysinstall menus.)
Just don't make it so that mDNS -only- works for .local and the link local
in-addr.arpa domains.
> 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.
The draft RFC indicates that those (sub)domains should be delegated. It does
not prohibit delegation of other (sub)domains.
> 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.
According to section 12, current implementations delegate .local,
.254.169.in-addr.arpa, and FF02::/16 via special-case code. If you're going to
do that, you may as well recognize explicit NS delegations to 224.0.0.251 and
FF02::FB
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.
That might be an argument against mixing them for host lookup; but for service
discovery, this is really only going to come up for clients that are using
DNS-SD; and there's absolutely no reason why the dns-sd library shouldn't
handle it properly.
I'm not familiar with the internals of the nsswitch and resolver code to
propose any particular solution; but there's no reason why it can't be made to
work cleanly. At worst case, you'd need a single nss module that could handle
both DNS and mDNS.
>> 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.
You might be able to get by with using 'example.com'; but I wouldn't advise
trying it.
In any case; I don't think that we need to worry about people trying to use
unregistered domains. My point is that just because a domain is registered
doesn't mean that there are any unicast DNS servers providing authoritative
records for it. (Admittedly, it's probably a very good idea to at least have
one; even if it only contains the SOA.)
People will have good reasons to want to use a domain other than .local with
mDNS; and to use both that domain and .local at the same time. And quite
possibly to use multiple domains in additional to .local. Let's not get in
their way.
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.
I think we need a third state where it only adds {_tcp,_udp}.$(domain) to the
list.
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.
Hmmm. Yes, I think that's a valid distinction. The nss_dns module and the
dns-sd library need not have the same set of default restrictions.
Applications using the nsswitch only are unlikely to be using DNS-SD at all;
and cannot be expected to be able to cope with delegation to a multicast
address. Those using libdns_sd are almost certain to be mDNS-aware; and the
library can handle the choice of mDNS -vs- unicast for particular queries (and
the potential recursion needed to resolve them.)
But that means that some of the configuration choices will need to be available
to the dns-sd library. (E.g., Whether to use mDNS only for .local, or also for
_{tcp,udp}.DOMAIN, _{tcp,udp}.*, or for everything.)
-Pat
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
