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 (Grant Taylor)
2. Re: NNPS / TCP port 433 (Russ Allbery)
3. Re: NNPS / TCP port 433 (Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Sun, 12 Dec 2021 10:22:35 -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 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-0001.bin>
------------------------------
Message: 2
Date: Sun, 12 Dec 2021 09:50:44 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: NNPS / TCP port 433
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> 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.
Ah, yes, using this for NNTP is a neat idea. However, it probably also
implies that we'd want to write a short RFC to document this behavior
(once someone implemented it), since I think by default SRV records are
only interpreted for a single protocol.
> Use of SRV records is not wide-spread at all...
They're widely used in a few places. Kerberos uses them heavily. But it
varies wildly based on protocol.
> It seems like e-mail clients haven't implemented it but use other
> mechanisms of autodiscovery or like.
I think email clients mostly use manual configuration, even. I've yet to
work somewhere where the email servers were autodiscovered. There's
always some documentation somewhere saying what to enter into the various
fields.
The most natural way to use SRV records, particularly across protocols, is
to ask DNS for the values of all the SRV records in question and then sort
and apply logic to them within the client. That's what Kerberos does, for
example. It unfortunately means handling the DNS lookups directly in the
client and not outsourcing them to a program like netcat or telnet that
isn't aware of what protocol you're using.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Sun, 12 Dec 2021 10:57:14 -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:
> Making use of SRV records in DNS may be a useful use case for that
> scenario.
Pursuant to this (sub)thread I spent some time reading a bout Service
Bindings (SVCB) records [1] to compare and contrast against Service
(SRV) records.
N.B. The following is based on my loose understanding of SVCB records.
It could be wrong or things could change before ratification.
In short, I think that SVCB records /might/ have a little bit of an
advantage over SRV records. Mostly in that SVCB directly intends to
support different protocols across the same service name.
First, the high level overview of SVCB records.
[[_<port>.]_<scheme>.]<service>.<domain>.<tld> <TTL> IN SVCB
<SvcPriority> <TargetName> <SvcParameters>
Note:
1) _<scheme> is optional.
2) _<port> is optional, but requires _<scheme>.
As such, I think that the following would be the SVCB counterpart for
the _mail._tcp example I shared a little bit ago.
mail SVCB 1 imaps.example.net. alpn=imaps
mail SVCB 2 pop3s.example.net. alpn=pop3s
mail SVCB 3 imap.example.net. alpn=imap
mail SVCB 4 pop3.example.net. alpn=pop3
Additional records to add priority within each given target.
imaps SVCB 1 imaps-pri.example.net. alpn=imaps port=993
imaps SVCB 2 imaps-alt.example.net. alpn=imaps port=10993
pop3s SVCB 1 pop3s-pri.example.net. alpn=pop3s port=995
pop3s SVCB 2 pop3s-alt.example.net. alpn=pop3s port=10995
imap SVCB 1 imap-pri.example.net. alpn=imap port=143
imap SVCB 2 imap-alt.example.net. alpn=imap port=10143
pop3 SVCB 1 pop3-pri.example.net. alpn=pop3 port=110
pop3 SVCB 2 pop3-alt.example.net. alpn=pop3 port=10110
Note: The <SvcParameters> options can (but don't have to) specify
various options, including the port and / or the protocol; IMAPS / POP3S
/ IMAP / POP3.
The thing that I /think/ that I prefer of SVCB is the inherent use of a
/single/ service name / QNAME that spans multiple protocols (via the
`alpn` SvcParameter).
[1] Service binding and parameter specification via the DNS (DNS SVCB
and HTTPS RRs) -
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-03.html
--
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/40dd27b6/attachment.bin>
------------------------------
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 3
*******************************************
