NNPS / TCP port 433

[Grant Taylor]

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.bin>