From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 17:30:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDCE916A52F; Sat, 26 Aug 2006 17:30:25 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F435446A5; Sat, 26 Aug 2006 17:08:23 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[172.19.1.101]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GH1gj-000OvN-Io; Sat, 26 Aug 2006 10:11:46 -0700 Date: Sat, 26 Aug 2006 13:07:02 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: In-Reply-To: <44F068FD.1080408@shapeshifter.se> References: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> <44F068FD.1080408@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: cce6216813dd75456e75c7a28f1042d10685cd2f X-Spam-User: nobody X-Spam-Score: -1.6 (-) X-Spam-Score-Int: -15 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-1.6 points total, 5.0 required) 2.2 DOMAIN_BODY BODY: Domain registration spam body 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.9 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 17:30:26 -0000 > >> 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