Pat Lashley wrote:
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 ha
>> 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)
> be
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 LA
> What makes you think that there even IS a unicast DNS server for the
> (sub)domain in question?
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 (o
Pat Lashley wrote:
> No, I don't think that there's any good reason to restrict mDNS service
> discovery to .local; when you're using some other domain on the LAN,
you
> still want to easily do the dynamic service advertisement, even if
the A
> records are being handled by a traditional unicast
> Apple's primary consumer base for Zeroconf systems doesn't normally
> have to deal with multi-homed systems; so it probably isn't much of
> a priority for them.
Um, Pat...?
All of the laptops Apple sells have ethernet & 802.11 wireless built in and
thus are multihomed from day one; all of the
On Aug 25, 2006, at 12:24 PM, Pat Lashley wrote:
I would be entirely happy if FreeBSD could do better than MacOS
with regard to
this matter, but my observation suggests that the dudes working
on this at
Apple have a working implementation which is becoming widely used
in userland
applicat
On Fri, Aug 25, 2006 at 10:35:03AM +0900, JINMEI Tatuya / [EMAIL
PROTECTED]@C#:H wrote:
> > On Thu, 24 Aug 2006 13:42:29 -0500,
> > Brooks Davis <[EMAIL PROTECTED]> said:
>
> >> Um...I'm not sure if this is even possible. Let's forget mDNS and
> >> go back to basic IP.
> >> Say a multi-h
I believe Apple creates /32 host-specific routes for Zeroconf traffic on the
other interfaces, if seen. That may actually just be the normal ARP-handling
code in operation rather than Zeroconf, per se, although Apple's
implementation of ARP is Zeroconf-compliant in terms of timing, setting
"s
On Aug 24, 2006, at 6:29 PM, Pat Lashley wrote:
Mac OS X implements media sense where the hardware and driver
support
it. When the network media indicates that it has been connected,
the
autoconfiguration process begins again, and attempts to re-use the
previously assigned Link-Local addre
> No, I don't think that there's any good reason to restrict mDNS service
> discovery to .local; when you're using some other domain on the LAN, you
> still want to easily do the dynamic service advertisement, even if the A
> records are being handled by a traditional unicast DNS server and static
PM Lashley wrote:
> But service discovery will often have a non-.local domain; so I
think we
> need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything
> outside in-addr.arpa. Given the existence of the .local domain, I don't
> see any utility in advertising a service in an in-ad
Brooks Davis wrote:
On Fri, Aug 25, 2006 at 12:06:31AM +0200, Fredrik Lindberg wrote:
Brooks Davis wrote:
It just occured to me that the daemon could handle this without any
interaction with dhclient or the static interface configuration. In the
mode where you only want an LLA if there isn't a
>> The nsswitch.conf should IHMO be :files dns mdns,
>
>> and the mdns nss module should ship with a default to only allow
>> queries to
>>.local
>>.168.254.in-addr.arpa
>
> I think you meant .254.168.in-addr.arpa here.
Actually .254.169.in-addr.arpa :)
Err, yes. I knew that... :-)
>>
> I think this all means that for a multi-homed host, we should not
> automatically add a route for the 169.254/16 network. Instead, we
> should just add specific /32s as discovered; and use ARP when we
> need to find a new 169.254.x.y -> MAC translation.
MacOS X has the notion of interface prio
> Except in the case where multiple interfaces are on the same segment for
> redundancy. But in general, I suspect that you are right that using a
> %interface notation is the way to go.
If you actually want redundancy then you don't want multiple IP
addresses since you'll lose all your connecti
> On Thu, 24 Aug 2006 13:42:29 -0500,
> Brooks Davis <[EMAIL PROTECTED]> said:
>> Um...I'm not sure if this is even possible. Let's forget mDNS and
>> go back to basic IP.
>> Say a multi-homed host has two interfaces both configured with an
>> address in the rage 169.254/16, say 169.254.1
On Thu, Aug 24, 2006 at 03:21:41PM -0700, Chuck Swiger wrote:
> On Aug 24, 2006, at 3:10 PM, Fredrik Lindberg wrote:
> >>Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3,
> >>to choose a non-BIND specific term).
> >
> >We're talking about mDNS here, not DNS. I would argue that bec
On Fri, Aug 25, 2006 at 12:06:31AM +0200, Fredrik Lindberg wrote:
> Brooks Davis wrote:
> >
> >It just occured to me that the daemon could handle this without any
> >interaction with dhclient or the static interface configuration. In the
> >mode where you only want an LLA if there isn't another ad
On Aug 24, 2006, at 3:10 PM, Fredrik Lindberg wrote:
Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3,
to choose a non-BIND specific term).
We're talking about mDNS here, not DNS. I would argue that because
mDNS is link-local it makes perfect sense to be able to resolve
254.169
Chuck Swiger wrote:
On Aug 24, 2006, at 2:46 PM, Fredrik Lindberg wrote:
The nsswitch.conf should IHMO be :files dns mdns,
and the mdns nss module should ship with a default to only allow
queries to
.local
.168.254.in-addr.arpa
I think you meant .254.168.in-addr.arpa here.
Actually .2
Brooks Davis wrote:
It just occured to me that the daemon could handle this without any
interaction with dhclient or the static interface configuration. In the
mode where you only want an LLA if there isn't another address it's a
simple matter of watching the routing socket for messages and a)
On Aug 24, 2006, at 2:46 PM, Fredrik Lindberg wrote:
The nsswitch.conf should IHMO be :files dns mdns,
and the mdns nss module should ship with a default to only allow
queries to
.local
.168.254.in-addr.arpa
I think you meant .254.168.in-addr.arpa here.
Actually .254.169.in-addr.arpa
On Thu, Aug 24, 2006 at 11:51:55PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >
> >The problem with that is that we want to support the use of both on the
> >same link. So we'd either need to allow more than one keyword, or have
> >'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is ve
On Aug 24, 2006, at 9:20 AM, Pat Lashley wrote:
Unless we modify the IPv4 routing code to actually know that
different
interfaces with LLAs are on different subnets, we will need to insure
that there is only one interface with an LLA on it at once. The
modification probably makes sense, but I
Pat Lashley wrote:
The problem with that is that we want to support the use of both on the
same link. So we'd either need to allow more than one keyword, or have
'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is very attractive. I
think it would be cleaner to have something like:
The magi
On Thu, Aug 24, 2006 at 02:36:58PM -0400, Pat Lashley wrote:
> >> We also need to be able to handle the case where they are on physically
> >> different links; but the host is acting as a bridge between them to make
> >> one logical link sharing a single LLA subnet. (We don't need to
> >explicitl
On Thu, Aug 24, 2006 at 10:00:08PM +0200, Fredrik Lindberg wrote:
> Brooks Davis wrote:
> >
> >The right way to deal with this is almost certainly to adopt the KAME
> >%interface decoration for link local addresses. LLAs are meaningless
> >outside the context of an interface. Unless you only have
First, I'd like to correct something that slipped by earlier. Service Discovery
via DNS does -NOT depend on mDNS; it may be implemented using traditional
unicast DNS. (And to a pure client, there should be no detectable difference.)
> In general, I agree with, and have been known to strongly
> I think that I'd reverse the default on that. There should normally be
> no harm in having an LLA address, as long as we've got the non-LLA
> preference stuff working correctly. It is quite likely that the LLA
> address would never actually be used; but so what?
>
I've been thinking about that
Me too. :) The chief objection to mDNS (and other p2p types of dns
services) is the possibility of making it easier to hijack "real" websites.
I do not object (off hand) to a mechanism to define additional hostnames to
announce other than your own, but I think that we should do something like
unc
Brooks Davis wrote:
The right way to deal with this is almost certainly to adopt the KAME
%interface decoration for link local addresses. LLAs are meaningless
outside the context of an interface. Unless you only have one interface
with an LLA, you must know which interface you are addressing t
Pat Lashley wrote:
First, I'd like to correct something that slipped by earlier. Service
Discovery via DNS does -NOT depend on mDNS; it may be implemented using
traditional unicast DNS. (And to a pure client, there should be no
detectable difference.)
Yes this is correct (if I've implied ot
> Actually, it is quite possible for multiple interfaces to be on the same
> LLA link/subnet; so we can't make any assumptions either way. We -do- need
> to be able to handle the case where they are on different links. That
> really isn't an 'unless', it's a 'when'.
I can't see how it's worth w
On Thu, Aug 24, 2006 at 12:20:39PM -0400, Pat Lashley wrote:
> >> > There is also an option to force it to assign
> >> >(as an alias) a LLA address even if the interface is already is
> >> >configured with another address.
> >>
> >> I think that I'd reverse the default on that. There sh
> > There is also an option to force it to assign
> >(as an alias) a LLA address even if the interface is already is
> >configured with another address.
>
> I think that I'd reverse the default on that. There should normally be no
> harm in having an LLA address, as long as we've got t
Doug Barton wrote:
Fredrik Lindberg wrote:
I've been thinking about that too, but I'm still not sure. The RFC
says . . .
Which RFC(s)? :) My read is that there are several that are relevant,
generally, to LLA and mDNS, so it would be useful to know precisely what
we're discussing.
Sorry, we
Brooks Davis wrote:
> On Thu, Aug 24, 2006 at 08:33:58PM +0200, Fredrik Lindberg wrote:
>> The nsswitch.conf should IHMO be :files dns mdns, and the mdns nss
>> module should ship with a default to only allow queries to
>> .local
>> .168.254.in-addr.arpa
>> .168.192.in-addr.arpa
>> .16.172
Fredrik Lindberg wrote:
> I've been thinking about that too, but I'm still not sure. The RFC
> says . . .
Which RFC(s)? :) My read is that there are several that are relevant,
generally, to LLA and mDNS, so it would be useful to know precisely what
we're discussing.
Which reminds me, that's some
On Thu, Aug 24, 2006 at 08:40:09PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >
> >I think that I'd reverse the default on that. There should normally be
> >no harm in having an LLA address, as long as we've got the non-LLA
> >preference stuff working correctly. It is quite likely that
On Thu, Aug 24, 2006 at 08:33:58PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >>> Things get a bit more complex for multi-homed hosts; especially if they
> >>> are connected to more than one local link using IPv4 Link Local
> >>> Addressing...
> >>
> >>Well, I already have a proof-of-con
Pat Lashley wrote:
I think that I'd reverse the default on that. There should normally be
no harm in having an LLA address, as long as we've got the non-LLA
preference stuff working correctly. It is quite likely that the LLA
address would never actually be used; but so what?
I've been thi
Pat Lashley wrote:
I guess it's just my nature, I really don't want to restrict end users
ability to do stuff when there is no TECHNICAL limitation of doing so.
It's the classical policy versus mechanism scenario, imho policy should
be left to the user, of course provided with sane default values
On Thu, Aug 24, 2006 at 10:46:50AM -0400, Pat Lashley wrote:
> >> As I mentioned in an earlier posting, I would really like to see it
> >> support multiple TLDs for a single host. In particular, if I'm using
> >> example.com, then mumble.local and mumble.example.com should both
> >> resolve via mDN
On Thu, Aug 24, 2006 at 10:55:15AM -0400, Pat Lashley wrote:
> >If you want to communicate with an LLA host, fine, obtain an LLA
> >address otherwise take a hike.
>
> I'd make that '..., obtain an LLA address, or figure out how to do it via
> ARP, otherwise...'
>
> >My LLA implementation already
If you want to communicate with an LLA host, fine, obtain an LLA
address otherwise take a hike.
I'd make that '..., obtain an LLA address, or figure out how to do it via ARP,
otherwise...'
My LLA implementation already does this..it never removes an address
from a interface it didn't set its
I guess it's just my nature, I really don't want to restrict end users
ability to do stuff when there is no TECHNICAL limitation of doing so.
It's the classical policy versus mechanism scenario, imho policy should
be left to the user, of course provided with sane default values that
can be used ou
Pat Lashley wrote:
But the whole 'direct communication between LLA and non-LLA on the same
link' discussion is really a side issue. It should only come up for us
in a scenario where we want to have a completely zeroconf FreeBSD
machine (using LLA) in an environment with non-LLA machines. If t
>> Howevery, your statement above brings up a question, do you assume
>> that a system configured with lla should be able to communicate
>> with a system configured via dhcp?
>
> Yes, of course. The question is basically the same as whether hosts on
> the same link but different IP (sub)net ranges
Pat Lashley wrote:
Let us for a second pretend that SD doesn't exist but mDNS does, mDNS
without SD is still a very valuable protocol.
No argument there.
The specs. says that each host should claim a unique host and also
advertise a HINFO record, but this in my opinion a policy decision
and
I should probably explain better what I mean with this mdns.conf file,
as I think there might be a misunderstanding about it.
Let us for a second pretend that SD doesn't exist but mDNS does, mDNS
without SD is still a very valuable protocol.
No argument there.
The specs. says that each host s
On Thu, Aug 24, 2006 at 04:55:12PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >>I treat LLA and mDNS as separate things. They can be used individually
> >>or together. I see LLA as a way of configuring an IP-address while
> >>mDNS is a way of resolving DNS-like hostnames.
> >
> >Don't fo
Pat Lashley wrote:
I treat LLA and mDNS as separate things. They can be used individually
or together. I see LLA as a way of configuring an IP-address while
mDNS is a way of resolving DNS-like hostnames.
Don't forget service discovery. That's an important part of zeroconf,
implemented via mDNS
I treat LLA and mDNS as separate things. They can be used individually
or together. I see LLA as a way of configuring an IP-address while
mDNS is a way of resolving DNS-like hostnames.
Don't forget service discovery. That's an important part of zeroconf,
implemented via mDNS.
Howevery, your
I've been watching this thread with great interest, having recently been
introduced to the possibilities of OLSR (net/olsrd) for local (and
beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in.
Some refs: My discovery point, a great (online) book found from a review
by Geoff Huston
Pat Lashley wrote:
Um..wouldn't the routing code handle this?
If you set a lla address and some other address on a interface like
192.168.0.2
or something and then a default route of 192.168.0.1, I
would assume that an application without specific knowledge that tries
to contact an external ad
Um..wouldn't the routing code handle this?
If you set a lla address and some other address on a interface like
192.168.0.2
or something and then a default route of 192.168.0.1, I
would assume that an application without specific knowledge that tries
to contact an external address would get 192.
Pat Lashley wrote:
As for mDNS/SD I think a generic responderd.conf/mdns.conf file should
be available where you can configure "static" dns records.
I would really rather see the service advertisement done in each
service's rc.d script. That has the advantage of not requiring the
mdns.conf fi
I've been watching this thread with great interest, having recently been
introduced to the possibilities of OLSR (net/olsrd) for local (and
beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in.
Some refs: My discovery point, a great (online) book found from a review
by Geoff Huston
Pat Lashley wrote:
The one thing
I'd be worried about is how the socket code handles connect() requests.
My hope would be that it would pick the address that goes with the
router to be used and thus the LLA would never be the source of a packet
going to a non-LLA address in normal circumstanc
DHCP+static is rather weird, but common enough that we do support it. I
suspect LLA with other address types is also of use at least some
of the time so we should ideally support it. Actually if we don't mind
always configuring a LLA I think we might support be OK right now as
long as the LLA da
On Wed, Aug 23, 2006 at 03:07:32PM -0400, Pat Lashley wrote:
> >> I would agree that LLA is part of the minimal set; and as I mentioned
> >> before, it is the only part for which there is currently no FreeBSD
> >> solution. It should be possible to enable LLA on a per-NIC basis in
> >> rc.conf; and
> I would agree that LLA is part of the minimal set; and as I mentioned
> before, it is the only part for which there is currently no FreeBSD
> solution. It should be possible to enable LLA on a per-NIC basis in
> rc.conf; and it should be possible to have both LLA and non-LLA addresses
> on the s
> 2. What are the linux flavors doing?
It appears that the Avahi (http://avahi.org/) responder is the
current leader, it's API compatible (client wise) with mDNSResponder.
It is my impression that the mDNSResponder API compatibility lib/shim is a
build-time option and not actually used by the
On Wed, Aug 23, 2006 at 02:12:20PM -0400, Pat Lashley wrote:
> >If no one else steps forward, I will be glad to lead the charge to get an
> >implementation of this committed. Before I do though, we'll need to get
> >some
> >basic questions answered (some of which have already been discussed here).
If no one else steps forward, I will be glad to lead the charge to get an
implementation of this committed. Before I do though, we'll need to get some
basic questions answered (some of which have already been discussed here).
1. What are the other *BSDs doing in this area?
2. What are the linux f
Doug Barton wrote:
I find it very interesting. :) One of my side projects at the moment is to
come further up to speed on the subject of multicast DNS in general, so I'm
following this discussion with a great deal of interest. I'd really like to
see FreeBSD take a lead in this area, since the mo
On Wed, Aug 23, 2006 at 12:48:02PM -0700, Doug Barton wrote:
> Brooks, if you're reading this, can I count on you to broach the question
> about the Apache license in [EMAIL PROTECTED]
Will do.
-- Brooks
pgpxSVsk16XB7.pgp
Description: PGP signature
Fredrik Lindberg wrote:
> The thing is that I would like to see mDNS in base (and the other
> zeroconfig utilities).
...
> However that doesn't have a chance of happening unless a committer finds
> it interesting.
I find it very interesting. :) One of my side projects at the moment is to
come
Bruce Walker wrote:
Fredrik Lindberg wrote:
mDNSResponder-108 appears to still be under APSL 2, I don't
know if that license is acceptable for base utilities, if it is, it
might be a viable alternative.
It should be under the Apache 2.0 license now.
Yes, you are correct. I just grabbed the
On Wed, Aug 23, 2006 at 01:45:10PM -0400, Bruce Walker wrote:
> Fredrik Lindberg wrote:
> >mDNSResponder-108 appears to still be under APSL 2, I don't
> >know if that license is acceptable for base utilities, if it is, it
> >might be a viable alternative.
>
> It should be under the Apache 2.0 lice
Fredrik Lindberg wrote:
mDNSResponder-108 appears to still be under APSL 2, I don't
know if that license is acceptable for base utilities, if it is, it
might be a viable alternative.
It should be under the Apache 2.0 license now.
Here's the announcement from the bonjour-dev list ...
Pat Lashley wrote:
As I investigate further, it appears that avahi is the most mature,
feature-rich, and widely supported and adopted mDNS implementation. The
only potential drawback would be the GPL.
I've also discovered that Apple are moving the iCal server, Bonjour, and
launchd to the A
My responder does one thing (ok it's many things but anyway), it
responds to queries and it makes queries. A mDNS record is always
a mDNS record (shared or unique), at this point SD records are
treated as any other record.
Long-term records can be configured with responderd.conf, it
supports dyna
Pat Lashley wrote:
Is your library API fairly close to the one in mDNSResponder or gmdns?
If so, it should be fairly easy to make your apps work with whichever
library is installed. (I'm just thinking ahead to the point where
projects like Apache, Firefox, and various GNOME apps have added se
On 8/21/06, Pat Lashley <[EMAIL PROTECTED]> wrote:
> > Actually, that is IPv4 Link Local Addressing. Zeroconfig includes
that,
> > Multicast DNS, Service Discovery and anything else that removes the
need
> > for manual configuration.
>
> Yeah, I actually know that. It's just that I've developed
> Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that,
> Multicast DNS, Service Discovery and anything else that removes the need
> for manual configuration.
Yeah, I actually know that. It's just that I've developed a bad habit of
calling it zeroconfig in the absence of a short
Pat Lashley wrote:
In short, zeroconfig allows a host to automatically negotiate
a collision free ip-address with other hosts on the network in the
absence of a DHCP-server. It's suitable for small ad-hoc networks,
or in embedded solutions.
Actually, that is IPv4 Link Local Addressing. Zeroconf
In short, zeroconfig allows a host to automatically negotiate
a collision free ip-address with other hosts on the network in the
absence of a DHCP-server. It's suitable for small ad-hoc networks,
or in embedded solutions.
Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that,
M
Hi all,
A while ago I started hacking on a zeroconfig and multicast DNS
implementation for FreeBSD.
In short, zeroconfig allows a host to automatically negotiate
a collision free ip-address with other hosts on the network in the
absence of a DHCP-server. It's suitable for small ad-hoc net
80 matches
Mail list logo
