NNPS / TCP port 433
Grant Taylor
gtaylor at tnetconsulting.net
Sun Dec 12 17:22:35 UTC 2021
On 12/12/21 2:51 AM, Julien ÉLIE wrote:
> Hi Grant,
Hi Julien,
> It can do:
Okay.
> [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.
So this means that the RFC blesses using SRV records across different
service names / QNAMEs.
> 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.
This supports specifying different types of services on the different
target / port pairings. But it does not indicate if it's the same or
different service name(s) / QNAME(s).
I believe the following would also achieve the same results:
_mail._tcp SRV 40 10 110 pop3-pri.example.net.
_mail._tcp SRV 40 20 110 pop3-alt.example.net.
_mail._tcp SRV 30 10 143 imap-pri.example.net.
_mail._tcp SRV 30 20 143 imap-alt.example.net.
_mail._tcp SRV 20 10 995 pop3s-pri.example.net.
_mail._tcp SRV 20 20 995 pop3s-alt.example.net.
_mail._tcp SRV 10 10 993 imaps-pri.example.net.
_mail._tcp SRV 10 20 993 imaps-alt.example.net.
My intention is to prefer encrypted protocols (IMAPS / POP3S) over
unencrypted protocols (IMAP / POP3) and to prefer IMAP(S) over POP3(S)
therein.
However, all of the SRV records are returned with the single service
name / QNAME of _mail._tcp... There is no need to do additional queries
for multiple service names / QNAME(s).
> 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.
This supports using different service names / QNAMEs and having the
client aggregate and prioritize.
IMHO this actually makes the client side of SRV support /more/ complicated.
> 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.
Hum.... :-/
> 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.
Nuances about how to prioritize.
> 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.
>
> That's what we wanted to achieve.
Agreed.
> Use of SRV records is not wide-spread at all...
Nope.
For the longest time, Microsoft Active Directory was the only thing I
ever saw using it. Though, based on my understanding, I do think that
it used SRV records properly. It wasn't until the last 10 or so years
that I saw anything else start to dabble in SRV records.
> 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.
Agreed.
> Isn't it the same thing as when there are several DNS servers to try?
Conceptually, maybe.
In practice / executing, I don't think so. Perhaps a DNS server could
do some of the sorting and return the multiple records to the client.
But there's no viable way to return any port information in that sorted
list.
It's the classic disconnect of two independent things working with each
other in a limited way. E.g. Netscape Navigator independent of Netscape
Mail vs Netscape Communicator that encompassed both Navigator and Mail.
The bridge between the two personalities is distinctly different with
the former being less capable than the latter.
> When one does not respond, the secondary should be queried, and so forth.
Please elaborate. I'm not seeing how something like `telnet` / `openssl
s_client` can /gracefully/ work with a list of names. I'm assuming /
eliding the same port and the same service on said ports for the sake of
conversation.
> I agree that using SRV is not natively supported in these utilities...
Sadly.
--
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/56c72232/attachment.bin>
More information about the inn-workers
mailing list