Hello,
as this is the first time I'm using Fedora, I noticed the following ...
(a) when open a SSH connection, it tells e.g. Last login: Mon Jun 5 20:14:37 2017 from 192.168.1.1 all other Linux VMs and/or the Router box show there Last login: Sat Jun 3 21:41:45 2017 from winpc.local
(b) when configuring Firefox using a proxy, this works only when entering a IP address; when entering a DNS name a 'Proxy server not found' error is the result ...
(c) when configuring a line printer I had to enter e.g. this lpd://192.168.1.11/CP1515N when entering a DNS name e.g. printer.local then this result in a 'printer.local' could not be found;
a nslookup shows the correct IP addresses this means the DNS server is working properly ...
Thanks for explanations, Walter
On 06/05/2017 11:25 AM, Walter H. wrote:
as this is the first time I'm using Fedora, I noticed the following ...
(a) when open a SSH connection, it tells e.g. Last login: Mon Jun 5 20:14:37 2017 from 192.168.1.1 all other Linux VMs and/or the Router box show there Last login: Sat Jun 3 21:41:45 2017 from winpc.local
(b) when configuring Firefox using a proxy, this works only when entering a IP address; when entering a DNS name a 'Proxy server not found' error is the result ...
(c) when configuring a line printer I had to enter e.g. this lpd://192.168.1.11/CP1515N when entering a DNS name e.g. printer.local then this result in a 'printer.local' could not be found;
a nslookup shows the correct IP addresses this means the DNS server is working properly ...
nslookup resolved the .local addresses? That's surprising and might be a problem.
For at least a and c, make sure you have nss-mdns installed.
On 06/05/2017 11:44 AM, Walter H. wrote:
On 05.06.2017 20:38, Samuel Sieb wrote:
nslookup resolved the .local addresses? That's surprising and might be a problem.
I'm using inside my network a .local domain which is defined in a ZONE on my DNS - so no problem ...
Actually, that *IS* a problem. You should not be doing that. That is quite likely the source of all your problems. That domain name is reserved for a specific purpose and putting it in DNS will cause conflicts.
On 06/05/2017 01:25 PM, Samuel Sieb wrote:
On 06/05/2017 11:44 AM, Walter H. wrote:
On 05.06.2017 20:38, Samuel Sieb wrote:
nslookup resolved the .local addresses? That's surprising and might be a problem.
I'm using inside my network a .local domain which is defined in a ZONE on my DNS - so no problem ...
Actually, that *IS* a problem. You should not be doing that. That is quite likely the source of all your problems. That domain name is reserved for a specific purpose and putting it in DNS will cause conflicts.
Sounds likely. In this case, you probably want to *remove* nss-mdns, and if that doesn't solve the problem, maybe also remove "mdns4_minimal [NOTFOUND=return]" from /etc/nsswitch.conf's "hosts:" line.
On Wed, June 7, 2017 22:08, Gordon Messmer wrote:
On 06/07/2017 12:05 PM, Walter H. wrote:
On 05.06.2017 22:44, Gordon Messmer wrote:
Sounds likely. In this case, you probably want to *remove* nss-mdns,
remove the whole X? :D
I don't really know what that means.
when you do yum remove nss-mdns and say yes, you will remove more than 150 MBytes including many packets which refernce to nss-mdns ... including X11
On 06/07/2017 10:53 PM, Walter H. wrote:
when you do yum remove nss-mdns and say yes, you will remove more than 150 MBytes including many packets which refernce to nss-mdns ... including X11
Not on my system. The only thing that appears to depend on nss-mdns is wine, here.
In any case, if that solution isn't workable for you, you can remove "mdns4_minimal [NOTFOUND=return]" from /etc/nsswitch.conf, and you should be able to look up .local hosts using DNS.
On Thu, 8 Jun 2017 10:08:54 -0700 Gordon Messmer wrote:
In any case, if that solution isn't workable for you, you can remove "mdns4_minimal [NOTFOUND=return]" from /etc/nsswitch.conf, and you should be able to look up .local hosts using DNS.
On every system I've ever tried *all* dns lookups always fail if that mdns junk is in nsswitch. I always have to remove it to get any dns to work.
Gordon Messmer wrote:
In any case, if that solution isn't workable for you, you can remove "mdns4_minimal [NOTFOUND=return]" from /etc/nsswitch.conf, and you should be able to look up .local hosts using DNS.
Tom Horsley:
On every system I've ever tried *all* dns lookups always fail if that mdns junk is in nsswitch. I always have to remove it to get any dns to work.
The converse, here. I've never had to mess around removing mdns from nsswitch.conf. And I don't recall having to do anything *like* that since I stopped using Samba years ago (removing lmhosts from the name resolution equation).
I run a local DNS server, that's integrated with my DHCP server (in that new hosts assigned an IP by the DHCP server get their data incorporated into the DNS server, so all clients on my LAN use my DNS server for *all* name resolution, local and WWW). I don't make use of the hosts file.
On Fri, June 9, 2017 22:33, Tim wrote:
I run a local DNS server, that's integrated with my DHCP server (in that new hosts assigned an IP by the DHCP server get their data incorporated into the DNS server, so all clients on my LAN use my DNS server for *all* name resolution, local and WWW). I don't make use of the hosts file.
The same here at my home, and which Domain do you use for local?
Tim:
I run a local DNS server, that's integrated with my DHCP server (in that new hosts assigned an IP by the DHCP server get their data incorporated into the DNS server, so all clients on my LAN use my DNS server for *all* name resolution, local and WWW). I don't make use of the hosts file.
Walter H.:
The same here at my home, and which Domain do you use for local?
I have a real domain name, which resolves to my externally hosted mail and website. Internally, I have a LAN sub-domain, of it, that my DNS and DHCP servers work with.
e.g. www.example.com vs lan.example.com
So, internally, you get local FQDNs like laserprinter.lan.example.com. Externally, you get the usual website domain names www.example.com, or just example.com. And mail is simple username@example.com.
My DNS server will directly answer LAN queries, for the lan subdomain, but refer the main domain name to the internet like any other query.
That kept things running pain-free, until mDNS reared it's ugly head on me when I tried to add a Canon Pixma printer to my LAN. The printer only wanted to use the zeroconf/bonjour scheme, ignoring my DNS and DHCP. It took me a while to figure out that it doesn't query normal DNS servers on port 53, at all. I can understand manufacturers adding zeroconf/bonjour functions to equipment, but I can't comprehend them taking away normal networking.
Many years ago, while playing with servers on my LAN, before setting up DNS and DHCP servers, I discovered an annoying issue with just using hostnames (in the hosts file), various servers insisted on having domain names with at least one dot in them. At that stage, I took my lead from the hosts file, did a bit of ferreting around to see what purpose it had, and I went with using .localdomain as my TLD.
Allegedly, on or about 12 June 2017, Walter H. sent:
which Domain do you use for local?
Back to the general question...
I'd certainly like to see .lan reserved as for use with private LANs, on normal DNS/DHCP that the user can control, as opposed to things like .local being under automatic machine control with auto random IP allocation (the two, zeroconf and DHCP, are not co-operative).
If ZeroConf, DHCP, and DNS could all be integrated, then it wouldn't be a problem. Your server would auto-reallocate the same names per device by set or rules, or randomly for new devices, and queries for either resolving system would work.
I've seen .home used by some domestic modem/routers. You can usually control them to some degree, or at least turn it off. I seem to recall that recent versions of Windows used it as a home domain, much the same ways as Linux uses .localdomain.
On 12.06.2017 16:35, Tim wrote:
Allegedly, on or about 12 June 2017, Walter H. sent:
which Domain do you use for local?
Back to the general question...
I'd certainly like to see .lan reserved as for use with private LANs,
just for this, there exists an I-D, which will become an RFC, and there .home.arpa is reserved as sepcial use-domain https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/
On Mon, June 5, 2017 22:25, Samuel Sieb wrote:
On 06/05/2017 11:44 AM, Walter H. wrote:
On 05.06.2017 20:38, Samuel Sieb wrote:
nslookup resolved the .local addresses? That's surprising and might be a problem.
I'm using inside my network a .local domain which is defined in a ZONE on my DNS - so no problem ...
Actually, that *IS* a problem. You should not be doing that. That is quite likely the source of all your problems. That domain name is reserved for a specific purpose and putting it in DNS will cause conflicts.
Sorry, you're telling *BULLSHIT*; the TLD .local is exactly reserved for this purpose ...
On 06/05/2017 09:13 PM, Walter H. wrote:
On Mon, June 5, 2017 22:25, Samuel Sieb wrote:
On 06/05/2017 11:44 AM, Walter H. wrote:
On 05.06.2017 20:38, Samuel Sieb wrote:
nslookup resolved the .local addresses? That's surprising and might be a problem.
I'm using inside my network a .local domain which is defined in a ZONE on my DNS - so no problem ...
Actually, that *IS* a problem. You should not be doing that. That is quite likely the source of all your problems. That domain name is reserved for a specific purpose and putting it in DNS will cause conflicts.
Sorry, you're telling *BULLSHIT*; the TLD .local is exactly reserved for this purpose ...
It is not! Try reading this: https://en.wikipedia.org/wiki/.local
Microsoft at one point suggested using it, but they have since recanted.
According to https://tools.ietf.org/html/rfc6762 .local is reserved for MDNS use and is not supposed to be DNS resolvable.
On Tue, June 6, 2017 06:29, Samuel Sieb wrote:
According to https://tools.ietf.org/html/rfc6762 .local is reserved for MDNS use and is not supposed to be DNS resolvable.
exact this RFC says in "Appendix G. Private DNS Namespaces"
"We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local."for this purpose:
.intranet. .internal. .private. .corp. .home. .lan."
and the TLD .home. is just in a pre-registration phase ...
tell me a TLD I can use instead, and which meets the following 3 criterias:
(1) it will never been used officially (2) it is not .test., .corp. (3) it is shorter that 5 characters (4 or less)
Thanks, Walter
p.s. in case the phenomenas of the OP won't change these are true bugs.
On 06/05/2017 10:19 PM, Walter H. wrote:
.intranet. .internal. .private. .corp. .home. .lan."
and the TLD .home. is just in a pre-registration phase ...
tell me a TLD I can use instead, and which meets the following 3 criterias:
(1) it will never been used officially (2) it is not .test., .corp. (3) it is shorter that 5 characters (4 or less)
.lan meets your requirements and I have seen that used. Or you could make up something random. Since it's just your private network, if the one you choose gets used later, you will have to change it again, but you'll have lots of warning.
p.s. in case the phenomenas of the OP won't change these are true bugs.
I don't understand what you're saying here.
On Tue, June 6, 2017 07:40, Samuel Sieb wrote:
On 06/05/2017 10:19 PM, Walter H. wrote:
.intranet. .internal. .private. .corp. .home. .lan."
and the TLD .home. is just in a pre-registration phase ...
tell me a TLD I can use instead, and which meets the following 3 criterias:
(1) it will never been used officially (2) it is not .test., .corp. (3) it is shorter that 5 characters (4 or less)
.lan meets your requirements and I have seen that used.
I had .home., but when I noticed that the pre-registration of .home. has started, I changed this to .local.; at work we have company.local.
Or you could make up something random. Since it's just your private network,
.local as something random :D
if the one you choose gets used later, you will have to change it again, but you'll have lots of warning.
p.s. in case the phenomenas of the OP won't change these are true bugs.
I don't understand what you're saying here.
the system/Firefox has to take e.g. proxy.my.lan as proxy server ... also the printer must work with e.g. lpd://printer.my.lan/CP1515N ... and not just with the IP address ...
On 06/05/2017 11:27 PM, Walter H. wrote:
On Tue, June 6, 2017 07:40, Samuel Sieb wrote:
On 06/05/2017 10:19 PM, Walter H. wrote:
p.s. in case the phenomenas of the OP won't change these are true bugs.
I don't understand what you're saying here.
the system/Firefox has to take e.g. proxy.my.lan as proxy server ... also the printer must work with e.g. lpd://printer.my.lan/CP1515N ... and not just with the IP address ...
That should all work. The problem you are having is that you are using .local in your DNS.
On 06.06.2017 20:13, Samuel Sieb wrote:
On 06/05/2017 11:27 PM, Walter H. wrote:
On Tue, June 6, 2017 07:40, Samuel Sieb wrote:
On 06/05/2017 10:19 PM, Walter H. wrote:
p.s. in case the phenomenas of the OP won't change these are true bugs.
I don't understand what you're saying here.
the system/Firefox has to take e.g. proxy.my.lan as proxy server ... also the printer must work with e.g. lpd://printer.my.lan/CP1515N ... and not just with the IP address ...
That should all work. The problem you are having is that you are using .local in your DNS.
this works on all systems I have even with .local in my DNS except with this Fedora; sounds strange ...
On 06/06/2017 11:22 AM, Walter H. wrote:
On 06.06.2017 20:13, Samuel Sieb wrote:
On 06/05/2017 11:27 PM, Walter H. wrote:
On Tue, June 6, 2017 07:40, Samuel Sieb wrote:
On 06/05/2017 10:19 PM, Walter H. wrote:
p.s. in case the phenomenas of the OP won't change these are true bugs.
I don't understand what you're saying here.
the system/Firefox has to take e.g. proxy.my.lan as proxy server ... also the printer must work with e.g. lpd://printer.my.lan/CP1515N ... and not just with the IP address ...
That should all work. The problem you are having is that you are using .local in your DNS.
this works on all systems I have even with .local in my DNS except with this Fedora; sounds strange ...
Either you've been lucky or those other systems don't support MDNS yet.
On 06.06.2017 20:27, Samuel Sieb wrote:
On 06/06/2017 11:22 AM, Walter H. wrote:
On 06.06.2017 20:13, Samuel Sieb wrote:
On 06/05/2017 11:27 PM, Walter H. wrote:
On Tue, June 6, 2017 07:40, Samuel Sieb wrote:
On 06/05/2017 10:19 PM, Walter H. wrote:
p.s. in case the phenomenas of the OP won't change these are true bugs.
I don't understand what you're saying here.
the system/Firefox has to take e.g. proxy.my.lan as proxy server ... also the printer must work with e.g. lpd://printer.my.lan/CP1515N ... and not just with the IP address ...
That should all work. The problem you are having is that you are using .local in your DNS.
this works on all systems I have even with .local in my DNS except with this Fedora; sounds strange ...
Either you've been lucky or those other systems don't support MDNS yet.
given the possibility that the strange phenomens mentioned in the OP are really caused by using .local as my intranet-TLD, then why doesn't nslookup of the Fedora box tell me errors or whatever, when doing just nslookup proxy.local?
so when renaming my local domain to something different, this must be sure, that not any other future bug makes me renaming it again ...
there is a definition for IP addresses inside a LAN (RFC1918) why isn't there any definition of a TLD for just this use case?
Greetings, Walter
On 06/06/2017 12:49 PM, Walter H. wrote:
On 06.06.2017 20:27, Samuel Sieb wrote:
Either you've been lucky or those other systems don't support MDNS yet.
given the possibility that the strange phenomens mentioned in the OP are really caused by using .local as my intranet-TLD, then why doesn't nslookup of the Fedora box tell me errors or whatever, when doing just nslookup proxy.local?
nslookup only does direct DNS, it doesn't use the system resolver.
so when renaming my local domain to something different, this must be sure, that not any other future bug makes me renaming it again ...
There are no guarantees, but at this point .lan is not likely to have any future purpose. Or if you use something unique like .waldi, you are really safe.
there is a definition for IP addresses inside a LAN (RFC1918) why isn't there any definition of a TLD for just this use case?
I suspect that the expectation was that everyone would just have their own domain. But the system is flexible enough that you can make up your own as long as you keep it private. You could even use someone else's domain as long as you won't ever want to communicate with them. :-)
On 06.06.2017 21:59, Samuel Sieb wrote:
On 06/06/2017 12:49 PM, Walter H. wrote:
so when renaming my local domain to something different, this must be sure, that not any other future bug makes me renaming it again ...
There are no guarantees, but at this point .lan is not likely to have any future purpose. Or if you use something unique like .waldi, you are really safe.
your words in gods ear ...
there is a definition for IP addresses inside a LAN (RFC1918) why isn't there any definition of a TLD for just this use case?
I suspect that the expectation was that everyone would just have their own domain.
yes and no, when I think of some very old browsers, there could only be entered TLDs with a maximum of 4 characters, so .home and .corp could have been defined in those days for just this use case; but it seems that the practical intelligence is somewhere else ...
But the system is flexible enough that you can make up your own as long as you keep it private.
of course
You could even use someone else's domain as long as you won't ever want to communicate with them. :-)
this would be a goog idea as I wanted .waldi.net :-) try waldi.net, I'm sure you don't really want communicate with them ...
by the way my DNS redefines e.g. the msftncsi.com in way that Windows boxes stays in LAN with these requests (my router box also supports these NCSI files)
On Tue, 6 Jun 2017 12:59:07 -0700 Samuel Sieb samuel@sieb.net wrote:
On 06/06/2017 12:49 PM, Walter H. wrote: [...] [...] [...]
[...]
[...] _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Empty mail again. What is going on?
Allegedly, on or about 06 June 2017, Bob Marcan sent:
[...] [...] [...]
[...]
[...]
Empty mail again. What is going on?
I suspect you've got an option set to mask/hide/mute/silence quotes in replies. Some mailers offer that as option to make it easier to see new content in messages that are bloated with unedited quotes of prior messages. But they can get confused when respondents do not put a *COMPLETELY* blank line between quotes and responses, and the mail client can end up muting the whole thing.
And that is what was done in the apparently blank message that you commented about. They left a ">" marker below the quotes, between the quote and their response, instead of removing it to leave a blank line between quote and response.
That kind of thing confuses various mail clients that colour or dim the quoted text, to make it easier to find new content. It isn't that easy to read messages splattered with messy quoting with comments jammed in bits. People really need to make it easier to read their responses.
On 06/07/2017 01:05 AM, Tim wrote:
I suspect you've got an option set to mask/hide/mute/silence quotes in replies. Some mailers offer that as option to make it easier to see new content in messages that are bloated with unedited quotes of prior messages. But they can get confused when respondents do not put a *COMPLETELY* blank line between quotes and responses, and the mail client can end up muting the whole thing.
And that is what was done in the apparently blank message that you commented about. They left a ">" marker below the quotes, between the quote and their response, instead of removing it to leave a blank line between quote and response.
I've always done that and almost did that again right here. :-) It's easier to just put a newline in instead of also deleting the extra ">" from the previous line.
That kind of thing confuses various mail clients that colour or dim the quoted text, to make it easier to find new content. It isn't that easy to read messages splattered with messy quoting with comments jammed in bits. People really need to make it easier to read their responses.
Most email clients have no trouble, but I have noticed that gmail and outlook sometimes mess up with it. I will try to leave a blank line in between quotes from now on.
Allegedly, on or about 07 June 2017, Samuel Sieb sent:
I've always done that and almost did that again right here. :-) It's easier to just put a newline in instead of also deleting the extra ">" from the previous line.
Just hitting enter twice would quickly break the quoting apart.
If you'd started out using mail clients that auto-rewrapped the quoted text, too, using a too-simple algorithm, you'd hate having to deal with poorly quoted text. The entire prior message turns into a blob of indistinguishable quotes of quotes and comments.
On 06/07/17 04:49, Bob Marcan wrote:
On Tue, 6 Jun 2017 12:59:07 -0700 Samuel Sieb samuel@sieb.net wrote:
On 06/06/2017 12:49 PM, Walter H. wrote: [...] [...] [...]
[...]
[...] _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Empty mail again. What is going on?
Well, it seems you are using Claws Mail 3.14.1 to access your mail.
Maybe you should use the Web interface of gmail to see if there is a difference. You seem to be the only one with the issue so I would expect the problem to be on your end. :-)
On Wed, 7 Jun 2017 17:39:20 +0800 Ed Greshko ed.greshko@greshko.com wrote:
On 06/07/17 04:49, Bob Marcan wrote:
Empty mail again. What is going on?
Well, it seems you are using Claws Mail 3.14.1 to access your mail.
Maybe you should use the Web interface of gmail to see if there is a difference. You seem to be the only one with the issue so I would expect the problem to be on your end. :-)
I use claws mail and had no problem seeing this message. I think Bob didn't see it because claws doesn't allow html messages unless asked to. There is an option to render them as text, which I have set, and is probably why I saw it. Also, it is possible to click the bottom icon on the right of the message, and if you have the html plugin for claws installed, it will display the html message.
On 06/07/17 22:07, stan wrote:
On Wed, 7 Jun 2017 17:39:20 +0800 Ed Greshko ed.greshko@greshko.com wrote:
On 06/07/17 04:49, Bob Marcan wrote:
Empty mail again. What is going on?
Well, it seems you are using Claws Mail 3.14.1 to access your mail.
Maybe you should use the Web interface of gmail to see if there is a difference. You seem to be the only one with the issue so I would expect the problem to be on your end. :-)
I use claws mail and had no problem seeing this message. I think Bob didn't see it because claws doesn't allow html messages unless asked to. There is an option to render them as text, which I have set, and is probably why I saw it. Also, it is possible to click the bottom icon on the right of the message, and if you have the html plugin for claws installed, it will display the html message.
Well, except that the "empty" messages from Samuel Sieb are tagged as...
Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: base64
So, I don't think the issue is related to html
On Wed, 7 Jun 2017 22:33:33 +0800 Ed Greshko ed.greshko@greshko.com wrote:
On 06/07/17 22:07, stan wrote:
I use claws mail and had no problem seeing this message. I think Bob didn't see it because claws doesn't allow html messages unless asked to. There is an option to render them as text, which I have set, and is probably why I saw it. Also, it is possible to click the bottom icon on the right of the message, and if you have the html plugin for claws installed, it will display the html message.
Well, except that the "empty" messages from Samuel Sieb are tagged as...
Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: base64
But the message that shows up as the empty dots in Samuel's message is from Walter and has the following encoding. Content-Type: multipart/mixed; boundary="===============7498209977189103805=="
So, I don't think the issue is related to html
I agree with you. I was looking for a way to explain how the same mail client could have very different user display outcomes. i.e. it worked for me, but not for Bob.
I think I'll drop this now. :-)
On 07.06.2017 17:40, stan wrote:
But the message that shows up as the empty dots in Samuel's message is from Walter and has the following encoding. Content-Type: multipart/mixed; boundary="===============7498209977189103805=="
this is because, my Thunderbird generates both variants, the text/plain and the text/html ... (don't ask me why)
On 06/07/2017 09:25 AM, Walter H. wrote:
On 07.06.2017 17:40, stan wrote:
But the message that shows up as the empty dots in Samuel's message is from Walter and has the following encoding. Content-Type: multipart/mixed; boundary="===============7498209977189103805=="
this is because, my Thunderbird generates both variants, the text/plain and the text/html ... (don't ask me why)
In Thunderbird's left column click one your account name, something like walt@yourdomain. On the right look for "View Settings for this Account". In the window that opens look for "Composition & Addressing". The top line of the window that opens offers, "Compose messages in HTML format". Uncheck that and you'll be on your way to list nirvana.
hth
On 06/08/17 00:25, Walter H. wrote:
On 07.06.2017 17:40, stan wrote:
But the message that shows up as the empty dots in Samuel's message is from Walter and has the following encoding. Content-Type: multipart/mixed; boundary="===============7498209977189103805=="
this is because, my Thunderbird generates both variants, the text/plain and the text/html ... (don't ask me why)
Well, according to the other MIME headers in the message appearing on the list it is not ending up with both variants. I see...
Content-Type: multipart/mixed; boundary="===============4901101950197799775=="
This is a cryptographically signed message in MIME format.
The next part...
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050801080503060907090608"
This is a cryptographically signed message in MIME format.
Followed by....
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable
The next being...
Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature
And lastly....
Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline
No, HTML....
FWIW, to ensure HTML is not sent to a mailing list I go to "Perferences--->Compositiong" on the General Tab I select "Send Options" and define a "Plain Text Domain".
On Wed, June 7, 2017 23:27, Ed Greshko wrote:
On 06/08/17 00:25, Walter H. wrote:
On 07.06.2017 17:40, stan wrote:
But the message that shows up as the empty dots in Samuel's message is from Walter and has the following encoding. Content-Type: multipart/mixed; boundary="===============7498209977189103805=="
this is because, my Thunderbird generates both variants, the text/plain and the text/html ... (don't ask me why)
Well, according to the other MIME headers in the message appearing on the list it is not ending up with both variants. I see...
Content-Type: multipart/mixed; boundary="===============4901101950197799775=="
yes this part is the same if its text/plain and text/html or
This is a cryptographically signed message in MIME format.
a s/mime signed email ...
The next being...
Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature
yes the s/mime signature ...
No, HTML....
right, I had once configured to only send HTML mail to specific domains, which means to any other it is plain-text
it seems that the mailinglist-mailman is broken ...
On 06/08/17 14:23, Walter H. wrote:
right, I had once configured to only send HTML mail to specific domains, which means to any other it is plain-text
it seems that the mailinglist-mailman is broken ...
So, how is it broken? I mean other than now forcing me to remember to hit "Reply List". :-)
Unless you're saying you know you are sending the body in both HTML and Plain-Text and that mailman is stripping out the HTML and only passing the Plain-Text? In that case I'd say it was a feature, not a bug. :-) :-)
On Thu, June 8, 2017 09:00, Ed Greshko wrote:
On 06/08/17 14:23, Walter H. wrote:
right, I had once configured to only send HTML mail to specific domains, which means to any other it is plain-text
it seems that the mailinglist-mailman is broken ...
So, how is it broken?
where is the digital signature (S/MIME) shown?
I mean other than now forcing me to remember to hit "Reply List". :-)
of course stripping off HTML is a feature, but ...
that I send both text/plain and text/html was a guess of mine, because of the lines inside the mail source you gave earlier;
I only send text/plain, and this signed ...
the mails, that I send are
e.g. multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090300020904060901010406"
and not
e.g. multipart/mixed; boundary="===============5882133914592620319=="
Walter
On 06/08/17 20:07, Walter H. wrote:
On Thu, June 8, 2017 09:00, Ed Greshko wrote:
On 06/08/17 14:23, Walter H. wrote:
right, I had once configured to only send HTML mail to specific domains, which means to any other it is plain-text
it seems that the mailinglist-mailman is broken ...
So, how is it broken?
where is the digital signature (S/MIME) shown?
I mean other than now forcing me to remember to hit "Reply List". :-)
of course stripping off HTML is a feature, but ...
that I send both text/plain and text/html was a guess of mine, because of the lines inside the mail source you gave earlier;
I don't recall putting out any headers that showed your message containing HTML.
Now, looking back in the list I do see messages with HTML formatting. In those cases, as per the RFC's, they do have an initial header of
Content-Type: multipart/mixed; boundary="===============6657248435458859845==
But then you have
Content-Type: multipart/alternative; boundary="f403045c3978a173c20550995890"
With the alternative forms of the same content bounded by what is specified in the "boundary"
I only send text/plain, and this signed ...
the mails, that I send are
e.g. multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090300020904060901010406"
and not
e.g. multipart/mixed; boundary="===============5882133914592620319=="
I do see what you mean about S/MIME. I've not used that in quite some time so I'd have to look to see how/why it gets broken. I've used PGP/MIME on this list before, and I will sign this message, and it didn't get broken. Guess I'll have to get a free S/MIME cert for testing at some point. :-) :-)
On 08.06.2017 15:44, Ed Greshko wrote:
I don't recall putting out any headers that showed your message containing HTML.
of copurse not, I guessed this from multipart/mixed ...
I do see what you mean about S/MIME. I've not used that in quite some time so I'd have to look to see how/why it gets broken. I've used PGP/MIME on this list before, and I will sign this message, and it didn't get broken.
this is embedded a little bit different to an e-mail ...
Guess I'll have to get a free S/MIME cert for testing at some point. :-) :-)
yes do this :-)
On 06/09/17 02:39, Walter H. wrote:
On 08.06.2017 15:44, Ed Greshko wrote:
I don't recall putting out any headers that showed your message containing HTML.
of copurse not, I guessed this from multipart/mixed ...
I do see what you mean about S/MIME. I've not used that in quite some time so I'd have to look to see how/why it gets broken. I've used PGP/MIME on this list before, and I will sign this message, and it didn't get broken.
this is embedded a little bit different to an e-mail ...
Guess I'll have to get a free S/MIME cert for testing at some point. :-) :-)
yes do this :-)
I think I see what is happening, at least for S/MIME.
Mailman is placing a footer at the end of the message to remind folks how to unsubscribe. This mean it must reformat the MIME headers and this seems to break SMIME. I don't recall it breaking PGP/MIME. Guess I will have to subscribe with another account and sign various replies just to see what goes on with both methods.
On Fri, 9 Jun 2017 05:41:21 +0800 Ed Greshko ed.greshko@greshko.com wrote:
On 06/09/17 02:39, Walter H. wrote:
On 08.06.2017 15:44, Ed Greshko wrote:
I don't recall putting out any headers that showed your message containing HTML.
of copurse not, I guessed this from multipart/mixed ...
I do see what you mean about S/MIME. I've not used that in quite some time so I'd have to look to see how/why it gets broken. I've used PGP/MIME on this list before, and I will sign this message, and it didn't get broken.
this is embedded a little bit different to an e-mail ...
Guess I'll have to get a free S/MIME cert for testing at some point. :-) :-)
yes do this :-)
I think I see what is happening, at least for S/MIME.
Mailman is placing a footer at the end of the message to remind folks how to unsubscribe. This mean it must reformat the MIME headers and this seems to break SMIME. I don't recall it breaking PGP/MIME. Guess I will have to subscribe with another account and sign various replies just to see what goes on with both methods.
wouldn't it be useful to post this on the mailman users list?
d
On 06/09/17 05:47, Dave Stevens wrote:
wouldn't it be useful to post this on the mailman users list?
Probably, eventually. After I study the differences between the headers of an S/MIME message to the list compared with the headers of a PGP/MIME message (which I have verified does survive) and determine if it is a case of real breakage or a case of Thunderbird not doing the right thing.
So, I need to know more about S/MIME, PGP/MIME, the abilities of Thunderbird, and then the mechanics of mailman before I can somewhat intelligently talk about it. :-)
(FWIW, this message is signed with S/MIME from within Thunderbird) and the message you replied to was signed with PGP/MIME.
On Fri, 9 Jun 2017 05:55:41 +0800 Ed Greshko ed.greshko@greshko.com wrote:
On 06/09/17 05:47, Dave Stevens wrote:
wouldn't it be useful to post this on the mailman users list?
Probably, eventually. After I study the differences between the headers of an S/MIME message to the list compared with the headers of a PGP/MIME message (which I have verified does survive) and determine if it is a case of real breakage or a case of Thunderbird not doing the right thing.
So, I need to know more about S/MIME, PGP/MIME, the abilities of Thunderbird, and then the mechanics of mailman before I can somewhat intelligently talk about it. :-)
(FWIW, this message is signed with S/MIME from within Thunderbird) and the message you replied to was signed with PGP/MIME.
ok. using claws on mint
d
On 06/09/17 06:12, Dave Stevens wrote:
On Fri, 9 Jun 2017 05:55:41 +0800 Ed Greshko ed.greshko@greshko.com wrote:
On 06/09/17 05:47, Dave Stevens wrote:
wouldn't it be useful to post this on the mailman users list?
Probably, eventually. After I study the differences between the headers of an S/MIME message to the list compared with the headers of a PGP/MIME message (which I have verified does survive) and determine if it is a case of real breakage or a case of Thunderbird not doing the right thing.
So, I need to know more about S/MIME, PGP/MIME, the abilities of Thunderbird, and then the mechanics of mailman before I can somewhat intelligently talk about it. :-)
(FWIW, this message is signed with S/MIME from within Thunderbird) and the message you replied to was signed with PGP/MIME.
ok. using claws on mint
OK... So, if you're seeing the S/MIME signed message in "claws on mint" and I'm not seeing it on T-Bird and neither is Walter (who is also using T-Bird) then it pretty much narrows it down to a User-Agent issue.
So, thanks much for letting me know and making things easier to nail down.
e.
So, thanks much for letting me know and making things easier to nail down.
de nada!
;-)
d
Allegedly, on or about 09 June 2017, Ed Greshko sent:
Probably, eventually. After I study the differences between the headers of an S/MIME message to the list compared with the headers of a PGP/MIME message (which I have verified does survive) and determine if it is a case of real breakage or a case of Thunderbird not doing the right thing.
So, I need to know more about S/MIME, PGP/MIME, the abilities of Thunderbird, and then the mechanics of mailman before I can somewhat intelligently talk about it. :-)
(FWIW, this message is signed with S/MIME from within Thunderbird) and the message you replied to was signed with PGP/MIME.
That one came through, okay. Having a look at the source of the message, the list added it's signature as another section to the mail. The different parts of the mail have individualised headers that tell each section apart, as well as which parts are associated with each other. And, by the converse, the boundary marker provides a division that is to be regarded separately.
The signed portion of the message, is just that: It's a *portion* of the message that's signed. It has to work that way, as the headers will change in transit. And, as we see on lists, footers can be added.
So a signed message doesn't authenticate the entire posting, just some portion of it. Unfortunately, the mail client doesn't indicate which parts are verified by the signature. Nor does mine indicate that only some portion of the message is verified. It's probably possible to forward someone's signed message, add stuff below the signed content, and fool people.
On 06/05/2017 11:27 PM, Walter H. wrote:
I had .home., but when I noticed that the pre-registration of .home. has started, I changed this to .local.;
And that's when your problems started.
at work we have company.local.
You should warn them that they are going to run into the same problem as you eventually.
On 06.06.2017 20:15, Samuel Sieb wrote:
On 06/05/2017 11:27 PM, Walter H. wrote:
I had .home., but when I noticed that the pre-registration of .home. has started, I changed this to .local.;
And that's when your problems started.
no. it startet with this Fedora box, or to say it differently I'm told that this is the cause for the phonomens listed in OP ... with all other Linux/Windows VMs I don't have these phonomens
at work we have company.local.
You should warn them that they are going to run into the same problem as you eventually.
renaming an AD domain?
On Tue, June 6, 2017 07:40, Samuel Sieb wrote:
.lan meets your requirements and I have seen that used. Or you could make up something random. Since it's just your private network, if the one you choose gets used later, you will have to change it again, but you'll have lots of warning.
I sent an email globalsupport@icann.org with the following question
"is there any TLD, I can use for private DNS¹? Thanks, Walter ¹ this is only inside my private LAN with RFC1918-IPv4 Adresses;"
the replied with the following:
Regarding your private network, if it will not be published on Internet, you can use whatever you want. You may avoid to uses existing TLD's and reserved ones (such as .test, .example, .lan etc.) just in case. You can use for example .#myname# or .mathemainzel, it has to be "unique" .
So .lan. can't be used.
Greetings, Walter
On 06/06/2017 04:56 AM, Walter H. wrote:
the replied with the following:
Regarding your private network, if it will not be published on Internet, you can use whatever you want. You may avoid to uses existing TLD's and reserved ones (such as .test, .example, .lan etc.) just in case. You can use for example .#myname# or .mathemainzel, it has to be "unique" .
"you can use whatever you want" "You *may* avoid"
So .lan. can't be used. It can be used, just be aware that maybe someday in the future it will
have a different meaning. Otherwise, just pick some random short selection of characters. It's really not that complicated.
On 06.06.2017 20:11, Samuel Sieb wrote:
On 06/06/2017 04:56 AM, Walter H. wrote:
the replied with the following:
Regarding your private network, if it will not be published on Internet, you can use whatever you want. You may avoid to uses existing TLD's and reserved ones (such as .test, .example, .lan etc.) just in case. You can use for example .#myname# or .mathemainzel, it has to be "unique" .
"you can use whatever you want" "You *may* avoid"
So .lan. can't be used.
It can be used, just be aware that maybe someday in the future it
will have a different meaning.
you're kidding; as it seems there is no defined TLD for exact this use ...
Otherwise, just pick some random short selection of characters. It's
really not that complicated.
I replied to this mail with:
if I interpret your reply correctly, I could also use just .waldi or .waldinet?
and their reply was:
If it's only for internal network, you can use .waldi or .waldinet.
On 06/06/2017 12:41 PM, Walter H. wrote:
On 06.06.2017 20:11, Samuel Sieb wrote:
On 06/06/2017 04:56 AM, Walter H. wrote:
So .lan. can't be used.
It can be used, just be aware that maybe someday in the future it
will have a different meaning.
you're kidding; as it seems there is no defined TLD for exact this use ...
I'm not kidding. Why is it a problem?
Otherwise, just pick some random short selection of characters. It's
really not that complicated.
I replied to this mail with:
if I interpret your reply correctly, I could also use just .waldi or .waldinet?
and their reply was:
If it's only for internal network, you can use .waldi or .waldinet.
Exactly. If you prefer that, then even better.
On Tue, 6 Jun 2017 12:47:49 -0700 Samuel Sieb samuel@sieb.net wrote:
On 06/06/2017 12:41 PM, Walter H. wrote: [...] [...] [...] [...] [...]
[...] [...] _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
What are you trying to tell with this empty mail?
On 06/06/2017 01:47 PM, Bob Marcan wrote:
On Tue, 6 Jun 2017 12:47:49 -0700 Samuel Sieb samuel@sieb.net wrote:
On 06/06/2017 12:41 PM, Walter H. wrote: [...] [...] [...] [...] [...]
[...] [...] _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
What are you trying to tell with this empty mail?
I don't know why you think it's empty, unless your email reader is doing something strange. Here's the mailing list archive page: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/...
On 06.06.2017 21:47, Samuel Sieb wrote:
On 06/06/2017 12:41 PM, Walter H. wrote:
On 06.06.2017 20:11, Samuel Sieb wrote:
On 06/06/2017 04:56 AM, Walter H. wrote:
So .lan. can't be used.
It can be used, just be aware that maybe someday in the future it
will have a different meaning.
you're kidding; as it seems there is no defined TLD for exact this use ...
I'm not kidding. Why is it a problem?
Otherwise, just pick some random short selection of characters.
It's really not that complicated.
I replied to this mail with:
if I interpret your reply correctly, I could also use just .waldi or .waldinet?
and their reply was:
If it's only for internal network, you can use .waldi or .waldinet.
Exactly. If you prefer that, then even better.
today I found this:
https://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/
as it seems, will .home declared as special domain for private use similar to RFC1918 IP addresses ...
I've the solution, or does anybody see a bug?
Thanks, Walter
On 06/07/2017 09:18 AM, Walter H. wrote:
today I found this:
https://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/
as it seems, will .home declared as special domain for private use similar to RFC1918 IP addresses ...
I've the solution, or does anybody see a bug?
That looks like a good solution.
On 07.06.2017 18:57, Samuel Sieb wrote:
On 06/07/2017 09:18 AM, Walter H. wrote:
today I found this:
https://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/
as it seems, will .home declared as special domain for private use similar to RFC1918 IP addresses ...
I've the solution, or does anybody see a bug?
That looks like a good solution.
Hello,
as I have got, that this draft I mentioned will never become an RFC .home is "dead", but this draft will become an RFC https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/
the domain is
.home.arpa.
On 06/07/2017 09:18 AM, Walter H. wrote:
On 06.06.2017 21:47, Samuel Sieb wrote:
On 06/06/2017 12:41 PM, Walter H. wrote:
On 06.06.2017 20:11, Samuel Sieb wrote:
On 06/06/2017 04:56 AM, Walter H. wrote:
So .lan. can't be used.
It can be used, just be aware that maybe someday in the future it
will have a different meaning.
you're kidding; as it seems there is no defined TLD for exact this use ...
I'm not kidding. Why is it a problem?
Otherwise, just pick some random short selection of characters.
It's really not that complicated.
I replied to this mail with:
if I interpret your reply correctly, I could also use just .waldi or .waldinet?
and their reply was:
If it's only for internal network, you can use .waldi or .waldinet.
Exactly. If you prefer that, then even better.
today I found this:
https://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/
as it seems, will .home declared as special domain for private use similar to RFC1918 IP addresses ...
I've the solution, or does anybody see a bug?
I don't see any reason that you couldn't use that. My only concern is that recursive/caching nameservers would 1) have to be configured not to "phone home" to the root-servers for .home or 2) resolvers of the future would have to be smart enough to not do that either.
Allegedly, on or about 07 June 2017, Mike Wright sent:
I don't see any reason that you couldn't use that. My only concern is that recursive/caching nameservers would 1) have to be configured not to "phone home" to the root-servers for .home or 2) resolvers of the future would have to be smart enough to not do that either.
I thought that was the whole point of that RFC? (Pointing out a purpose for home, so that future resolver programmers and network admins would ignore it.)
On 06/07/2017 10:17 AM, Mike Wright wrote:
I don't see any reason that you couldn't use that. My only concern is that recursive/caching nameservers would 1) have to be configured not to "phone home" to the root-servers for .home or 2) resolvers of the future would have to be smart enough to not do that either.
The point is that you would have your own name server that is authoritative for that domain. Then it won't try recursively resolving it.
On 06/07/2017 11:19 AM, Samuel Sieb wrote:
On 06/07/2017 10:17 AM, Mike Wright wrote:
I don't see any reason that you couldn't use that. My only concern is that recursive/caching nameservers would 1) have to be configured not to "phone home" to the root-servers for .home or 2) resolvers of the future would have to be smart enough to not do that either.
The point is that you would have your own name server that is authoritative for that domain. Then it won't try recursively resolving it.
Of course. You'd have to have an authority server. But at the same time you can't use your authority server for lookups where you are not the authority: hence, a resolver. And the resolver must be aware of which authority to contact for non-root TLDs.
On 06/07/2017 11:29 AM, Mike Wright wrote:
On 06/07/2017 11:19 AM, Samuel Sieb wrote:
On 06/07/2017 10:17 AM, Mike Wright wrote:
I don't see any reason that you couldn't use that. My only concern is that recursive/caching nameservers would 1) have to be configured not to "phone home" to the root-servers for .home or 2) resolvers of the future would have to be smart enough to not do that either.
The point is that you would have your own name server that is authoritative for that domain. Then it won't try recursively resolving it.
Of course. You'd have to have an authority server. But at the same time you can't use your authority server for lookups where you are not the authority: hence, a resolver. And the resolver must be aware of which authority to contact for non-root TLDs.
I'm not sure what you're trying to say here, this is the standard setup. The DNS server on the internal network is authoritative for a certain set of domains. Anything other than that is automatically resolved recursively. Why would it be any different for the .home domain?
On 07.06.2017 20:39, Samuel Sieb wrote:
On 06/07/2017 11:29 AM, Mike Wright wrote:
On 06/07/2017 11:19 AM, Samuel Sieb wrote:
On 06/07/2017 10:17 AM, Mike Wright wrote:
I don't see any reason that you couldn't use that. My only concern is that recursive/caching nameservers would 1) have to be configured not to "phone home" to the root-servers for .home or 2) resolvers of the future would have to be smart enough to not do that either.
The point is that you would have your own name server that is authoritative for that domain. Then it won't try recursively resolving it.
Of course. You'd have to have an authority server. But at the same time you can't use your authority server for lookups where you are not the authority: hence, a resolver. And the resolver must be aware of which authority to contact for non-root TLDs.
I'm not sure what you're trying to say here, this is the standard setup. The DNS server on the internal network is authoritative for a certain set of domains. Anything other than that is automatically resolved recursively. Why would it be any different for the .home domain?
exact this is my setup - but just with a .local, which I will rename to a .home, but this will take a week or so, e.g. I've to regenerate my local CA (there this .local must be changed to .home, too) SSL certificates must be changed, ...
On Wed, 2017-06-07 at 20:59 +0200, Walter H. wrote:
this is my setup - but just with a .local, which I will rename to a .home, but this will take a week or so, e.g. I've to regenerate my local CA (there this .local must be changed to .home, too) SSL certificates must be changed, ...
This is another situation where having a registered domain name becomes handy. If you ever want to use it publicly (e.g. you want to access something on your LAN remotely), you don't have to change all those kind of things, again. You're already set up.
On 06/06/2017 12:41 PM, Walter H. wrote:
I replied to this mail with:
if I interpret your reply correctly, I could also use just .waldi or .waldinet?
and their reply was:
If it's only for internal network, you can use .waldi or .waldinet.
If you really want to make sure it's unique, why don't you just go with .unique as your TLD?
On 06.06.2017 22:01, Joe Zeff wrote:
On 06/06/2017 12:41 PM, Walter H. wrote:
I replied to this mail with:
if I interpret your reply correctly, I could also use just .waldi or .waldinet?
and their reply was:
If it's only for internal network, you can use .waldi or .waldinet.
If you really want to make sure it's unique, why don't you just go with .unique as your TLD?
your idea is good, but I'm not sure, if this TLD becomes public in near future, and then I've a problem again ...
On 06/07/2017 09:20 AM, Walter H. wrote:
On 06.06.2017 22:01, Joe Zeff wrote:
On 06/06/2017 12:41 PM, Walter H. wrote:
I replied to this mail with:
if I interpret your reply correctly, I could also use just .waldi or .waldinet?
and their reply was:
If it's only for internal network, you can use .waldi or .waldinet.
If you really want to make sure it's unique, why don't you just go with .unique as your TLD?
your idea is good, but I'm not sure, if this TLD becomes public in near future, and then I've a problem again ...
Yes, and you can respond the same way no matter what we suggest. If you're looking for a way to reject everything we come up with, congratulations: you found it.
Allegedly, on or about 07 June 2017, Walter H. sent:
your idea is good, but I'm not sure, if this TLD becomes public in near future, and then I've a problem again ...
Well, the only foolproof solution for you is going to be:
Register a domain name, so that you own it.
You only have to register it, there doesn't have to have some DNS server out there on the internet with your IPs in it, serving them to all and sundry. You can run your own DNS server, on your LAN, to resolve your own addresses.
If you find you're stuck with a registrar that insists you set up public DNS records, then set up a record with one address in it, that you're not going to use, unrelated to your LAN. When I had a play with NoIP, years ago, I left a record with 127.0.0.1 in it.
On 06/05/2017 09:13 PM, Walter H. wrote:
Actually, that*IS* a problem. You should not be doing that. That is quite likely the source of all your problems. That domain name is reserved for a specific purpose and putting it in DNS will cause conflicts.
Sorry, you're telling*BULLSHIT*; the TLD .local is exactly reserved for this purpose ...
Actually, .local is reserved by RFC 6762 for resolution via multicast DNS:
https://en.wikipedia.org/wiki/.local
OP is using that domain in standard DNS, in violation of relevant standards.
RFC 2606 reserves .test, .example, .invalid, and .localhost, none of which are recommended for use in private networks. RFC 7686 reserves .onion for Tor hidden services. As far as I know, there are no TLDs reserved for private networks. All users should use properly registered domains for all DNS zones, private and public.
On 06/05/2017 11:31 PM, Gordon Messmer wrote:
As far as I know, there are no TLDs reserved for private networks. All users should use properly registered domains for all DNS zones, private and public.
Swell. Happen to know of a registrar that will let me register a domain that has no public facing DNS server? (At pretty much zero cost, of course)
On Tue, Jun 06, 2017 at 09:38:39AM -0500, Robert Nichols wrote:
Swell. Happen to know of a registrar that will let me register a domain that has no public facing DNS server? (At pretty much zero cost, of course)
Almost any registrar should let you do this.
On 06.06.2017 16:43, Matthew Miller wrote:
On Tue, Jun 06, 2017 at 09:38:39AM -0500, Robert Nichols wrote:
Swell. Happen to know of a registrar that will let me register a domain that has no public facing DNS server? (At pretty much zero cost, of course)
Almost any registrar should let you do this.
mine told me, that 2 DNS server are needed ..., and nobody is held to delegate subdomains to private IP (RFC1918) DNS servers
On Tue, 6 Jun 2017 09:38:39 -0500 Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 06/05/2017 11:31 PM, Gordon Messmer wrote:
As far as I know, there are no TLDs reserved for private networks. All users should use properly registered domains for all DNS zones, private and public.
Swell. Happen to know of a registrar that will let me register a domain that has no public facing DNS server? (At pretty much zero cost, of course)
I think this one will meet your requirements. About $9 a year, and it isn't necessary to use their DNS for the domain. And they allow me to use their address as the address of record for the domain. I have no affiliation with them, just use them. There might be better deals out there, but this one works with minimum hassle. They have a comparison feature, so you can compare them to their competitors.
On Tue, Jun 6, 2017 at 1:32 PM, stan stanl-fedorauser@vfemail.net wrote:
On Tue, 6 Jun 2017 09:38:39 -0500 Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 06/05/2017 11:31 PM, Gordon Messmer wrote:
As far as I know, there are no TLDs reserved for private networks. All users should use properly registered domains for all DNS zones, private and public.
Swell. Happen to know of a registrar that will let me register a domain that has no public facing DNS server? (At pretty much zero cost, of course)
I think this one will meet your requirements. About $9 a year, and it isn't necessary to use their DNS for the domain. And they allow me to use their address as the address of record for the domain. I have no affiliation with them, just use them. There might be better deals out there, but this one works with minimum hassle. They have a comparison feature, so you can compare them to their competitors.
https://www.namesilo.com/ _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
TLD -- Top Level Domain
On Tue, 2017-06-06 at 10:32 -0700, stan wrote:
On Tue, 6 Jun 2017 09:38:39 -0500 Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 06/05/2017 11:31 PM, Gordon Messmer wrote:
As far as I know, there are no TLDs reserved for private networks. All users should use properly registered domains for all DNS zones, private and public.
Swell. Happen to know of a registrar that will let me register a domain that has no public facing DNS server? (At pretty much zero cost, of course)
I think this one will meet your requirements. About $9 a year, and it isn't necessary to use their DNS for the domain. And they allow me to use their address as the address of record for the domain. I have no affiliation with them, just use them. There might be better deals out there, but this one works with minimum hassle. They have a comparison feature, so you can compare them to their competitors.
There are several providers out there with zero-cost options. I used no-ip.org for a while. They do nag you to revalidate from time to time, but if that doesn't bother you it's a viable option.
poc
On Tue, June 6, 2017 06:31, Gordon Messmer wrote:
OP is using that domain in standard DNS, in violation of relevant standards.
can someone bring this to a standard https://www.ietf.org/staging/draft-hoehlhubmer-private-tlds-00.txt
On 06/05/2017 09:13 PM, Walter H. wrote:
On Mon, June 5, 2017 22:25, Samuel Sieb wrote:
On 06/05/2017 11:44 AM, Walter H. wrote:
On 05.06.2017 20:38, Samuel Sieb wrote:
nslookup resolved the .local addresses? That's surprising and might be a problem.
I'm using inside my network a .local domain which is defined in a ZONE on my DNS - so no problem ...
Actually, that *IS* a problem. You should not be doing that. That is quite likely the source of all your problems. That domain name is reserved for a specific purpose and putting it in DNS will cause conflicts.
Sorry, you're telling *BULLSHIT*; the TLD .local is exactly reserved for this purpose ...
While that may have been the original intent Apple's Bonjour (mDNS) decided to glom onto that tld, rendering its use problematic. Here's a snippet from Wikipedia's entry on Multicast DNS:
"By default, mDNS only and exclusively resolves host names ending with the .local top-level domain (TLD). This can cause problems if that domain includes hosts which do not implement mDNS but which can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that violate the zero-configuration goal."
On 06/05/2017 11:13 PM, Walter H. wrote:
On Mon, June 5, 2017 22:25, Samuel Sieb wrote:
On 06/05/2017 11:44 AM, Walter H. wrote:
On 05.06.2017 20:38, Samuel Sieb wrote:
nslookup resolved the .local addresses? That's surprising and might be a problem.
I'm using inside my network a .local domain which is defined in a ZONE on my DNS - so no problem ...
Actually, that *IS* a problem. You should not be doing that. That is quite likely the source of all your problems. That domain name is reserved for a specific purpose and putting it in DNS will cause conflicts.
Sorry, you're telling *BULLSHIT*; the TLD .local is exactly reserved for this purpose ...
I'm not familiar with the use or misuse of .local, but I am having a problem that might be related. I have a surveilance camera, which I am trying to make work-- a Pyle PIPCAM5. My Linux is PCLinuxOS, but that probably is not germane. Two days ago I investigated the camera, which is (at the moment) connected to the lan by cat5 cable. Using nmap and one other program I got the responses that the camera's name is Android.local and I found the ip address and the MAC address (which was supposed to be on the bottom of the camera but wasn't). On that day, I could ping the camera by its ip or by its name, and the ping would work. I also found that it was made by Murata. Now the problem: yesterday and today it is inaccessible by any means--ping by ip or name, or by nmap. I have tried connecting and disconnecting the lan cable, the power cable, and rebooted the router, but nothing works. And since I can't access it, if the name is a problem, there is no way to get to it and change the name, even if I knew how! (Oh, I also tried to access it wirelessly, but that doesn't work either.) What does TLD mean, anyway?
--doug
On 06/06/2017 10:28 AM, Doug wrote:
was made by Murata. Now the problem: yesterday and today it is inaccessible by any means--ping by ip or name, or by nmap. I have tried connecting and disconnecting the lan cable, the power cable, and rebooted the router, but nothing works. And since I can't access it, if the name is a problem, there is no way to get to it and change the name, even if I knew how! (Oh, I also tried to access it
Most likely unrelated. The name will not affect you being able to access it by IP address. If it's not picking up a DHCP address, then there's something wrong with the camera. Try finding a reset button. Also, use tcpdump to see if you can see any DHCP requests or other traffic from it.
wirelessly, but that doesn't work either.) What does TLD mean, anyway?
Top Level Domain. e.g. .com .net .uk
Allegedly, on or about 05 June 2017, Walter H. sent:
I'm using inside my network a .local domain which is defined in a ZONE on my DNS - so no problem ...
If somewhere on your LAN are things using ZeroConf, Bonjour, or other similar autonomous psuedo-DNS software (client or server), then using .local for your own DNS records will probably cause problems. Those things (ZeroConf et al), expect to have control of it all by themselves, and get their knickers in a twist if you get involved.
And, not only that, they do their name resolutions using a different system, on a different port number. So, printer software, for example, trying to work out where laserjet.local can be found, is unlikely to consult your regular DNS server on port 53. And the converse is true, as I found out, with my printer that wanted to self-configure using the .local scheme, and only the .local scheme. I have a fully working traditional DNS, but no multicast DNS (ZeroConf, Bonjour, etc). The printer got nowhere with it's self-misconfiguration routines.
If you had a purely old-school DNS setup, you can almost get away with using any name that isn't in use by anything else (my problem with an annoying Pixma printer proved that, even then, it's a problem, as you add new hardware). In the past, there was a list of suggested top-level domains, for LANs, that included .local. But, since then, at least one of those autonomous systems began using .local for themselves.
There is one virtually guaranteed way to manage your own DNS without any conflicts, and that's to register a domain name. It's yours, you can do what you like with it, and other people are prevented from making public use of it (something that would cause you problems). You don't even have to use it with a website, or other public service. But if you do use it on the WWW, then you can make a subdomain for your LAN, to separate the two without managerial headaches.
If you don't want to go down that route, then choose one of the other (current) recommendations. And be prepare to keep an eye out for changes to that list of recommendations.
Supposedly, these auto-config DNS-like systems should make things simpler for you. You'd simply call your computer a name, put a name into your printer, likewise with your router (though many devices come preconfigured with their own names), and the auto-config networking will handle all the behind-the-scenes name resolution without you having to do a thing. Mind you, it's like that plug-and-play debacle, where you have to trust everything on your LAN, and anything plugged in is implicitly allowed to do whatever it wants to. That might be okay for basic home LANs, but not so for offices where random dopey employees may plug in random un-authorised devices.
-
Bob Marcan -
Dave Stevens -
Doug -
Ed Greshko -
Gordon Messmer -
Joe Zeff -
Matthew Miller -
Mike Wright -
Patrick O'Callaghan -
Robert Nichols -
Samuel Sieb -
stan -
Terry Polzin -
Tim -
Tom Horsley -
Walter H. -
Walter H.