On 13/09/2012 21:15, David R Oran wrote:
On Sep 13, 2012, at 1:12 PM, Michael Thomas m...@mtcc.com wrote:
On 09/12/2012 06:57 PM, Ted Lemon wrote:
On Sep 12, 2012, at 9:02 PM, Mark Andrews ma...@isc.org wrote:
My machines have names. Those names don't change as I move around
the world.
On Sep 11, 2012, at 4:53 PM, Curtis Villamizar wrote:
We had a similar discussion before and I pointed out that for security
some form of exchange of keys or certificates was needed.
Having a factory configured root DNSSEC certificate gets one form of
trust anchor. The browser
On Sep 12, 2012, at 11:54 PM, Mark Andrews ma...@isc.org wrote:
MacOS already supports this so clearly someone at Apple thinks
there is a need.
No, MacOS doesn't support this. MacOS supports DynDNS-like functionality, not
roaming via DNS. And it supports it in the sense that geeks can
On 9/12/12 10:35 PM, Ray Hunter wrote:
Fair counter point to my suggestion. Enterprises don't generally put
laptops in public viewable DNS.
Isn't your requirement to support highly mobile devices a good reason
to avoid mDNS wherever possible?
MDNS has a purpose, which is to locate on-link
Sure, but the scope of this discussion is name resolution in Homenet,
where there is always at least 1 router present.
So these two devices could always use unicast to reach a rendezvous point.
What devices do on other ephemeral ad hoc networks is out of scope.
joel jaeggli
On Sep 13, 2012, at 1:12 PM, Michael Thomas m...@mtcc.com wrote:
On 09/12/2012 06:57 PM, Ted Lemon wrote:
On Sep 12, 2012, at 9:02 PM, Mark Andrews ma...@isc.org wrote:
My machines have names. Those names don't change as I move around
the world. Random DHCP servers at coffee shops DO NOT
In message f5927c12-fe26-470f-82ae-f4387d30d...@fugue.com
Ted Lemon writes:
On Sep 12, 2012, at 2:41 AM, Ray Hunter v6...@globis.net wrote:
Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server
anyway in Homenet, why don't we go for the classic enterprise set up
that has
In message 7e23e81a-9daa-45ac-a577-3b0574e1d...@fugue.com
Ted Lemon writes:
On Sep 12, 2012, at 9:02 PM, Mark Andrews ma...@isc.org wrote:
My machines have names. Those names don't change as I move around
the world. Random DHCP servers at coffee shops DO NOT have the
ability to update
Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server
anyway in Homenet, why don't we go for the classic enterprise set up
that has run for years for IPv4, rather than trying to shoe horn locally
assigned SLAAC addresses into global DNS?
It's not as though you can buy any piece
On Sep 12, 2012, at 10:28 PM, Mark Andrews ma...@isc.org wrote:
Which is a UI / product support problem. The Mac has DNS registration
under Sharing. It requires manual entry of the TSIG key which
currently has to be entered into the nameserver for each device.
It could be made as simple as
In message 279cabeb-4dee-45c7-8cf2-8c34eac3c...@fugue.com, Ted Lemon writes:
On Sep 12, 2012, at 10:28 PM, Mark Andrews ma...@isc.org wrote:
Which is a UI / product support problem. The Mac has DNS registration
under Sharing. It requires manual entry of the TSIG key which
currently has
Fair counter point to my suggestion. Enterprises don't generally put
laptops in public viewable DNS.
Isn't your requirement to support highly mobile devices a good reason to
avoid mDNS wherever possible?
[mDNS being link local specific, and any extensions/gateways from mDNS
to unicast DNS
On 11 Sep 2012, at 02:41, james woodyatt j...@apple.com wrote:
Really? How has the architecture team managed to overlook the obvious
problem that homenets with interior routing domains comprising multiple
networks cannot use either mDNS or LLMNR, which are confined to link-local
On 11/09/2012 08:19, Ray Bellis wrote:
...
So the point of the original email was to test that first assumption - i.e.
what services don't (or can't) work in-home without a local unicast DNS zone.
Excuse my ignorance, but if a LAN has both mDNS and DNS available,
what happens when an app calls
On 11/09/2012 14:11, Simon Perreault wrote:
Le 2012-09-11 05:17, Brian E Carpenter a écrit :
Excuse my ignorance, but if a LAN has both mDNS and DNS available,
what happens when an app calls getnameinfo() ?
Current situation is: implementation-dependant.
In fact, getnameinfo() is not
On 09/11/2012 12:19 AM, Ray Bellis wrote:
I shall attempt to clarify.
Iff all in-home services can be reached (whilst in-home) by mDNS-like protocols then we
do not need an in-home unicast DNS zone.
To reach those same services from _outside_ the home does of course need them
to exist in the
On 09/11/2012 09:01 AM, Ted Lemon wrote:
There are a couple of options being pursued in the DHC working group; the DHCP
address registration process would be an obvious mechanism for leveraging DHCP
to populate the DNS. The idea here is that you do RA+SLAAC, or RA+CGA, and
then you contact
On Sep 11, 2012, at 12:24 PM, Michael Thomas m...@mtcc.com wrote:
Maybe somebody can educated me, but isn't it a bit dangerous to use
an auto-configured address as a way to contact a host? If I change out my
ethernet hardware, for example, my auto-conf address would normally
change too, right?
On Tue, Sep 11, 2012 at 06:52:16AM -0700, Michael Thomas wrote:
So no, let's not start from an assumption that it's an mDNS world in the
home. I'd say let's start from the opposite assumption that it's a normal
DNS world inside the home where mDNS is a way to auto-populate a
DNS repository in
On Tue, Sep 11, 2012 at 12:37:30PM -0400, Ted Lemon wrote:
No. Things change. All that's required to deal with this is that the
underlying protocol support it. The DHCP DUID identification system
does support this kind of change, as long as the actual device doesn't
change. If the
On Sep 11, 2012, at 11:07 , Evan Hunt e...@isc.org wrote:
This does raise a point, though: Dynamic DNS doesn't have an expiration
mechanism. [...] My home zone is cluttered up with the names of a couple of
dozen laptops and ipods belonging to neighbors and visitors over the past
year.
I recommend reading section 5 of Understanding Apple's Back-to-My-Mac
Service [RFC
6281], which gives a brief summary of how this problem is effectively and
reliably
managed in that system. There you will find references to the following truly
under-loved technical specifications:
In message 504f65c7.4010...@mtcc.com
Michael Thomas writes:
On 09/11/2012 09:01 AM, Ted Lemon wrote:
There are a couple of options being pursued in the DHC working
group; the DHCP address registration process would be an obvious
mechanism for leveraging DHCP to populate the DNS. The
In message 20120911180743.gd15...@isc.org
Evan Hunt writes:
On Tue, Sep 11, 2012 at 12:37:30PM -0400, Ted Lemon wrote:
No. Things change. All that's required to deal with this is that the
underlying protocol support it. The DHCP DUID identification system
does support this kind of
FYI !! All of D-Link home routers now support NetBIOS name, mDNS and LLMNR.
We removed 192.168.0.1 from device label and Quick Installation Guide already.
Best regards,
Hans
On Sep 10, 2012, at 8:34 PM, Ray Bellis ray.bel...@nominet.org.uk
wrote:
An interesting question has come up during
On 10/09/2012 13:34, Ray Bellis wrote:
An interesting question has come up during the Arch Doc team's discussions
around naming and service discovery:
What in-home services actually require Unicast DNS lookup? [*]
Well, that isn't the right question IMNSHO.
The one obvious case is in-home
On 10 Sep 2012, at 13:58, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Using literal addresses is evil for many reasons - surely we don't need to
discuss that ancient question again?
I wasn't promoting it, just noting that this is the current position, with
Bonjour et al becoming the
On Mon, Sep 10, 2012 at 01:58:46PM +0100, Brian E Carpenter wrote:
The right question is whether DNS is the appropriate solution for converting
local devices names to addresses, or whether there is some other naming
service that
should be the standard. Since DNS is the IETF standard for
Don,
Yes, based on, and it will be good to see those RFCs out.
What I'm basically worried about here is ending up with one
toolset for homenets and a different toolset for small enterprise
networks, which seem much more likely to go the DNS way than anything
else. In practice there's no hard and
Hi Brian,
Totally agree with you. In fact, I think Ray asked about the use case for
unicast DNS within Homenet. I think locating service names in a small
business, dormitory, etc. is that use case where mDNS does not scale well
and where a globally unique name is maybe not necessary...
Don
What I'm concerned about is using one protocol for internal name resolution
and another for external.
Bonjour, mDNS and multicast DNS are synonymous. mDNS is based
on DNS-SD, which is a conventional use of *existing* DNS RR types for
service discovery. mDNS uses DNS-like messages. I'm OK with
In message 47437c06-fb3d-41ab-adb9-01a409164...@nominet.org.uk
Ray Bellis writes:
An interesting question has come up during the Arch Doc team's
discussions around naming and service discovery:
What in-home services actually require Unicast DNS lookup? [*]
The one obvious case is
On Sep 10, 2012, at 05:34 , Ray Bellis ray.bel...@nominet.org.uk wrote:
An interesting question has come up during the Arch Doc team's discussions
around naming and service discovery:
What in-home services actually require Unicast DNS lookup? [*]
Really? How has the architecture team
On 9/10/12 6:41 PM, james woodyatt wrote:
On Sep 10, 2012, at 05:34 , Ray Bellis ray.bel...@nominet.org.uk wrote:
An interesting question has come up during the Arch Doc team's discussions
around naming and service discovery:
What in-home services actually require Unicast DNS lookup? [*]
34 matches
Mail list logo
