1 |
On 1/15/22 3:33 AM, Peter Humphrey wrote: |
2 |
> Hello list, |
3 |
|
4 |
Hi. |
5 |
|
6 |
> Rich F said recently, "I'd avoid using the .local TLD due to RFC 6762." |
7 |
|
8 |
Ya.... |
9 |
|
10 |
I've read RFC 6762 in the past and I just skimmed part of it again. I |
11 |
didn't find anything that prohibited the use of the local top level |
12 |
domain for things other than mDNS et al. |
13 |
|
14 |
The only hard requirement that I did see is that if mDNS is used, that |
15 |
queries for <anything>.local /MUST/ be sent to mDNS. |
16 |
|
17 |
N.B. that does not preclude /also/ sending queries for <anything>.local |
18 |
to other name resolution systems like traditional unicast DNS. |
19 |
|
20 |
Ergo, RFC 6762 does not preclude the use of the local top level domain |
21 |
in traditional unicast DNS. |
22 |
|
23 |
> That brings me back to a thorny problem: what should I call my local network? |
24 |
|
25 |
Maybe it's just me, I'm weird like that, but I vehemently believe that |
26 |
*I* am the authority for the names of *MY* network(s). As such, |
27 |
whatever name /I/ choose is the name that /my/ network(s) will use. |
28 |
|
29 |
I don't care that a cable internet provider wants my router to be called |
30 |
<client-ID>.<city>.<state>.<customers>.<cable company>.<tld>. |
31 |
|
32 |
What's more is that I don't fathom, much less allow, the cable company's |
33 |
-- let's go with -- questionable naming have any influence on what my |
34 |
internal network is called. |
35 |
|
36 |
> It used to be .prhnet, but then a program I tried a few years ago |
37 |
> insisted on a two-component name, so I changed it to .prhnet.local. |
38 |
|
39 |
There are /some/ complications that may have some influence on what |
40 |
names are chosen. |
41 |
|
42 |
But I point out that your network quite likely did exactly what you |
43 |
wanted to do up until that point. |
44 |
|
45 |
Q: Did you continue to use the software that you tried? Or did you end |
46 |
up renaming your network for something that you are no longer using? }:-) |
47 |
|
48 |
> Now I've read that RFC - well, Appendix G to it - and I'm scratching |
49 |
> my head. |
50 |
|
51 |
I note the distinct absence of the quintessential SHOULD or MUST that |
52 |
RFCs are notorious for in RFC 6762 Appendix G. So ... I don't give the |
53 |
recommendation there in much credence. |
54 |
|
55 |
What's more is that RFC 6762 Appendix G fails to take into account |
56 |
gateways that bridge mDNS into Unicast DNS. E.g. they receive an mDNS |
57 |
query and gateway it to the configured uDNS. Thereby (mostly |
58 |
seamlessly) tying the mDNS and uDNS name space together. |
59 |
|
60 |
I really feel like RFC 6762 is a "you might want to consider not using |
61 |
the .local top level domain on the off hand chance that you ever have |
62 |
something that can't / won't work with it." |
63 |
|
64 |
> I suppose it's possible that someone may want to connect an Apple |
65 |
> device to my network, so perhaps I should clear the way for that |
66 |
> eventuality. |
67 |
|
68 |
Is that possibility significant enough to influence how /you/ run /your/ |
69 |
network? |
70 |
|
71 |
/me puts his hand up to block glare looking out over the horizon looking |
72 |
for the SHOULD and MUST statements again, still not finding them. |
73 |
|
74 |
I can tell you that I have first hand experience with using Apple |
75 |
devices on a network that used the local top level domain without problems. |
76 |
|
77 |
> So, what TLD should I use? Should I use .home, or just go back to |
78 |
> .prhnet? It isn't going to be visible to the Big Bad World, so does |
79 |
> it even matter? |
80 |
|
81 |
Use whatever TLD you want to use. Be aware of any potential gotchas and |
82 |
decide if they are worth avoiding or not. |
83 |
|
84 |
The old fable of "The Miller, his son, and the donkey" comes to mind. |
85 |
-- Make yourself happy. |
86 |
|
87 |
|
88 |
|
89 |
-- |
90 |
Grant. . . . |
91 |
unix || die |