On Jul 30, 2012, at 16:28 , Michael Richardson <[email protected]> wrote:
>
> I think you that the answer should come from the Bonjour cache.
>
> james> For examples,
> james> 3a. dig -x fd35:5a4b:92a9:fb::1 -> fd35-5a4b-92a9-fb--1.local.
I chose a ULA address instead of a LL address because mDNS doesn't handle
reverse mappings for the "d.f.ip6.arpa." domain, c.f. section 4 of
I-D.cheshire-dnsext-multicastdns-15:
>> Likewise, any DNS query for a name within the reverse mapping
>> domains for IPv6 Link-Local addresses ("8.e.f.ip6.arpa.",
>> "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST
>> be sent to the IPv6 mDNS link-local multicast address FF02::FB or
>> the IPv4 mDNS multicast address 224.0.0.251.
> okay, so here I think that I disagree. Is that name valid in the forward?
I could accept a standard that required every reverse mapped name to be
resolvable in the forward over unicast DNS, but I would say that's a separable
problem from the one I'm suggesting could be taken up now. One step at a
time...
-----
Perhaps my choice of "local." as the default zone for RFC 6106 ULA prefix
addresses is unwise as it could be confusing in the presence of mDNS on the
same segment as the unicast DNS service.
Suppose a host named "zardoz" is attached to the link at several interface
addresses:
fd35:5a4b:92a9:fb::1001
2001:5a8:4:2290::1001
2001:5a8:4:2290:a95f:dd2e:3201:eafc
fe80::0200:ff:fe00:1
All those addresses will be reverse mapped over mDNS to "zardoz.local." under
every implementation that I know about today. Which makes sense if you think
about it. Every mDNS responder host is responsible for knowing its own name
and answering to it.
In the unicast DNS case, the content server probably does not know-- and
arguably should not know-- the name of every host in the zone, so that's why
it's wise to expect it will be synthesizing host names. Whether the default
zone for ULA reverse mapping names over unicast DNS is "local." or "homenet."
or something else is only tangentially relevant here. It's the same problem no
matter what TLD we allocate for this purpose.
--
james woodyatt <[email protected]>
member of technical staff, core os networking
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
