Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: NNPS / TCP port 433 (Julien ?LIE)
2. Re: NNPS / TCP port 433 (Grant Taylor)
3. Re: NNPS / TCP port 433 (Grant Taylor)
4. Re: NNPS / TCP port 433 (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Sat, 11 Dec 2021 20:57:06 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: NNPS / TCP port 433
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Grant and Russ,
>> I'm of the mind that we as the NNTP using community make a server rule
>> -- a la. "house rule" -- that the NNSP port 433 be implicitly TLS
>> protected much like NNTPS port 563 is. -- I say this because the
>> current industry best practices are to use implicit encryption. So if
>> the NNSP port 433 is largely unused and we want to start making use of
>> it, why not impose implicit encryption.
>
> Unfortunately, there is quite substantial existing use of 433 unencrypted
> and innd among others doesn't support TLS on that port right now. So I
> think there's some work ahead of us before we could get to that point.
> The flag day of switching port 433 from unencrypted to encrypted is a bit
> tricky to navigate.
Making use of SRV records in DNS may be a useful use case for that scenario.
Following the syntax of RFC 2782 (which was declined in RFC 6186 for
mail), one could add:
_nnsp._tcp SRV 10 1 119 news.server.com.
_nntp._tcp SRV 10 1 119 news.server.com.
_nntps._tcp SRV 0 1 563 news.server.com.
_nnsps._tcp SRV 0 1 433 news.server.com.
to say that nntps has more priority (0) than nntp (10). As well as
nnsps (0) has over nnsp (10). Port 433 uses implicit TLS, as mentioned
for NNSPS.
If NNSP pointed to 433 (or even both 119 and 433), it would have meant
that port 433 does not use implicit TLS.
_nnsp._tcp SRV 20 1 119 news.server.com.
_nnsp._tcp SRV 10 1 433 news.server.com.
(saying that port 433 is preferred over 119)
Format is: priority weight port target.
FWIW, I've just added SRV records for my news server:
_nnsp._tcp SRV 10 1 119 news.trigofacile.com.
_nntp._tcp SRV 10 1 119 news.trigofacile.com.
_nntps._tcp SRV 0 1 563 news.trigofacile.com.
_nnsps._tcp SRV 0 0 0 .
[RFC 2782]
A Target of "." means that the service is decidedly not
available at this domain.
I believe using such SRV records could be interesting in the use case
mentioned in this discussion.
The client only has to resolve:
% dig SRV _nnsp._tcp.trigofacile.com. +short
10 1 119 news.trigofacile.com.
% dig SRV _nnsps._tcp.trigofacile.com. +short
0 0 0 .
--
Julien ?LIE
??? Il t'arrive une tuile??
? Oui, je ne peux pas payer mon ardoise.??
------------------------------
Message: 2
Date: Sun, 12 Dec 2021 00:02:40 -0700
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 12/11/21 12:57 PM, Julien ?LIE wrote:
> Hi Grant and Russ,
Hi Julien,
> Making use of SRV records in DNS may be a useful use case for that
> scenario.
I've long been intrigued by SRV records. But I've not /yet/ found them
even remotely convenient to use.
> _nnsp._tcp???? SRV 10 1 119 news.server.com.
> _nntp._tcp???? SRV 10 1 119 news.server.com.
> _nntps._tcp??? SRV? 0 1 563 news.server.com.
> _nnsps._tcp??? SRV? 0 1 433 news.server.com.
My issue with this example is that you are using different service names
in each of the records. Thus clients are going to need to enter
something different depending on what they want.
> to say that nntps has more priority (0) than nntp (10).
Except I don't think that it does /because/ of the different service
names nntps != nntp.
> As well as nnsps (0) has over nnsp (10).
Same problem. nnsps != nnsp.
> Port 433 uses implicit TLS, as mentioned for NNSPS.
> If NNSP pointed to 433 (or even both 119 and 433), it would have meant
> that port 433 does not use implicit TLS.
Okay.
> _nnsp._tcp???? SRV 20 1 119 news.server.com.
> _nnsp._tcp???? SRV 10 1 433 news.server.com.
>
> (saying that port 433 is preferred over 119)
Agreed. The service names are the same, thus the subsequent fields apply.
> Format is: priority weight port target.
Yep.
If memory serves, priority and weight sort in opposite directions.
> FWIW, I've just added SRV records for my news server:
I like the idea.
However ...
> I believe using such SRV records could be interesting in the use case
> mentioned in this discussion.
>
> The client only has to resolve:
There's more than just resolving. There's also sorting based on
priority and weight. After sorting clients have to deal with different
ports.
I've not /yet/ found any way that's not remotely hacky to shoe horn SRV
support into things that aren't coded for it. E.g. I can't have
`telnet` or `netcat` use SRV records.
Sure, I can come up with some sort of hack to do the sorting to find a
top contender. I can even extend it to return the target and port in a
way that the client program can use it. E.g.
`telnet $(mySRVresolver _nntp._tcp.trigofacile.com)`
Where mySRVresolver returns `news.trigofacile.com 119` which `telnet`
can use as input.
Theoretically I can even have mySRVresolver attempt connections in the
proper order and return the first one that can successfully connect.
But what I can't do is have telnet re-try the next lower priority
candidate if the previous higher priority candidate failed to connect.
I will have to re-try / re-start the telnet command. So ... how do I
communicate to mySRVresolver that the previous connection failed, so
don't return it? Or so on and so forth?
So ... I've been stuck in the rut of I really like the idea of SRV
records, but I have yet to find an acceptable, much less decent, way to
leverage them for things that don't natively support them.
I /want/ to use SRV records. But I find them largely useless for things
that don't explicitly support them.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20211212/64da73bf/attachment-0001.bin>
------------------------------
Message: 3
Date: Sun, 12 Dec 2021 00:10:30 -0700
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 12/12/21 12:02 AM, Grant Taylor wrote:
> I /want/ to use SRV records.? But I find them largely useless for things
> that don't explicitly support them.
As I clicked send, I started to wonder if there might be a way to abuse
/ overload SOCKS or HTTP(S) CONNECT proxies such that you ask them to
connect to a _service._protocol.FQDN and they automagically perform the
SRV resolution /and/ *connection* (proxying) for the proxy client.
Then I realized that there is a fundamental disconnect between the
application layer protocol that clients are expecting. E.g. unencrypted
and encrypted.
Maybe it would be possible to extend the proxy to incorporate something
akin to stunnel / OpenSSL's s_client to do conversion between
unencrypted NN{S,T}P and encrypted NN{S,T}PS. But that's out the
northbound side between the proxy and the SRV target(s). I suppose the
southbound side between the client and the proxy would have it's own
independent encryption (or not).
Like I said, I /really/ /do/ want to use SRV records. But ... they just
aren't conducive to use by things that don't understand them.
I'd love to have _ssh._tcp.<FQDN> plugged into OpenSSH's ProxyCommand.
But ... alas ....
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20211212/e28949e8/attachment-0001.bin>
------------------------------
Message: 4
Date: Sun, 12 Dec 2021 10:51:20 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Grant,
>> _nnsp._tcp???? SRV 10 1 119 news.server.com.
>> _nntp._tcp???? SRV 10 1 119 news.server.com.
>> _nntps._tcp??? SRV? 0 1 563 news.server.com.
>> _nnsps._tcp??? SRV? 0 1 433 news.server.com.
>
> My issue with this example is that you are using different service names
> in each of the records.? Thus clients are going to need to enter
> something different depending on what they want.
>
>> to say that nntps has more priority (0) than nntp (10).
>
> Except I don't think that it does /because/ of the different service
> names nntps != nntp.
It can do:
[RFC 6186]
The priority field in the SRV RR allows a domain to indicate that
some records have a higher preference than others in the DNS query
results (determined by those records having a lower-numbered priority
value). Typically, this is used for choosing a record from a set for
a single service label; however, it is not restricted to choice
within only one service.
Often a site will offer both IMAP and POP3 message store access
services for users. However, the site may have a preference for one
over the other that they want to convey to the user to ensure that,
when the user has an MUA capable of using both IMAP and POP3, the
preferred choice is used.
To aid with this choice, sites SHOULD offer both sets of IMAP (_imap
and/or _imaps) and POP3 (_pop3 and/or _pop3s) SRV records in their
DNS and set the priority for those sets of records such that the
"preferred" service has a lower-numbered priority value than the
other. When an MUA supports both IMAP and POP3, it SHOULD retrieve
records for both services and then use the service with the lowest
priority value. If the priority is the same for both services, MUAs
are free to choose whichever one is appropriate. When considering
multiple records for different protocols at the same priority but
with different weights, the client MUST first select the protocol it
intends to use, then perform the weight selection algorithm given in
[RFC2782] on the records associated with the selected protocol.
Example: service records for both IMAP and POP3, with IMAP having a
lower-numbered priority value (0) than POP3 (10), indicating to the
MUA that IMAP is preferred over POP3, when the MUA can support either
service.
_imap._tcp SRV 0 1 143 imap.example.com.
_pop3._tcp SRV 10 1 110 pop3.example.com.
>> Port 433 uses implicit TLS, as mentioned for NNSPS.
>> If NNSP pointed to 433 (or even both 119 and 433), it would have meant
>> that port 433 does not use implicit TLS.
>
> Okay.
That's what we wanted to achieve.
> I've not /yet/ found any way that's not remotely hacky to shoe horn SRV
> support into things that aren't coded for it.? E.g. I can't have
> `telnet` or `netcat` use SRV records.
Use of SRV records is not wide-spread at all...
It seems like e-mail clients haven't implemented it but use other
mechanisms of autodiscovery or like. Nonetheless, it does not mean we
could not try for NNTP/NNSP.
> Sure, I can come up with some sort of hack to do the sorting to find a
> top contender.? I can even extend it to return the target and port in a
> way that the client program can use it.? E.g.
>
> ?? `telnet $(mySRVresolver _nntp._tcp.trigofacile.com)`
>
> Where mySRVresolver returns `news.trigofacile.com 119` which `telnet`
> can use as input.
>
> Theoretically I can even have mySRVresolver attempt connections in the
> proper order and return the first one that can successfully connect.
>
> But what I can't do is have telnet re-try the next lower priority
> candidate if the previous higher priority candidate failed to connect. I
> will have to re-try / re-start the telnet command.? So ... how do I
> communicate to mySRVresolver that the previous connection failed, so
> don't return it?? Or so on and so forth?
Isn't it the same thing as when there are several DNS servers to try?
When one does not respond, the secondary should be queried, and so forth.
I agree that using SRV is not natively supported in these utilities...
--
Julien ?LIE
??? Il t'arrive une tuile??
? Oui, je ne peux pas payer mon ardoise.??
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 136, Issue 2
*******************************************
