Support for SRV with Port "0" and Target "."

I’m asking for Cloudflare support on SRV record with entry of 0 0 0 .

Currently, Cloudflare requires port number to be greater then or equal to 1 and setting the target to . automatically changes it to the current domain used.

But per RFC 2052,

The port on this target host of this service. The range is 0-65535. This is often as specified in Assigned Numbers but need not be.

As for MX, the domain name of the target host. There MUST be one or more A records for this name. Implementors are urged, but not required, to return the A record(s) in the Additional Data section. Name compression is to be used for this field.

A Target of “.” means that the service is decidedly not available at this domain.

So, the RFC said that the range of 0 and the target of . is a valid entry. Could Cloudflare support these entry?

For a use-case, please refer to RFC 6186 regarding “Use of SRV Records for Locating Email Submission/Access Services” at Section 3.4

I am also trying to figure this out…

How do you enter the following RFC 6186 compliant SRV record in Cloudflare?
_pop3._tcp SRV 0 0 0 .

Cloudflare appears to replace the “.” with the domain name which is not correct. I am trying to figure out how to inform auto-discovery processes that pop3 is not supported.

In addition, with SRV RRs it is possible to indicate that a
particular service is not supported at all at a particular domain by
setting the target of an SRV RR to “.”. If such records are present,
clients MUST assume that the specified service is not available, and
instead make use of the other SRV RRs for the purposes of determining
the domain preference.

Example: service records for IMAP and POP3 with both TLS and non-TLS
service types are present. Both IMAP and POP3 non-TLS service types
are marked as not available. IMAP (with TLS) has a lower-numbered
priority value 0 than POP3 (with TLS) at priority 10, indicating to
the MUA that IMAP is preferred over POP3, when the MUA can support
either service, and only the TLS versions of the services are

   _imap._tcp     SRV  0 0 0   .
   _imaps._tcp    SRV  0 1 993
   _pop3._tcp     SRV  0 0 0   .
   _pop3s._tcp    SRV 10 1 995

I reported this many moons ago, sad to see that no action has been taken.

I reported this way back in May 2016, and it was supposedly marked for fixing in June 2016 - amazed it’s still an issue.

Unfortunately SRV records is one area where in an attempt to be clever Cloudflare shoots themselves in the foot by mangling the user’s definitions trying to ‘correct’ things which don’t necessarily need correcting. e.g. you can’t have an SRV record point to a Cloudflare-proxied hostname on port 443 because it’ll get transparently changed to a direct connection hostname meaning you no longer get Cloudflare’s SSL termination on the target. Sigh.

Hopefully these get fixed one day.

While technically not invalid, port zero is not necessarily the best idea

1 Like

Correct, that’s the entire point. 0 across all fields, with a host of . (also not a meaningful name) is the way you create a SRV record which specifies “this service is not offered”.

Why does it matter? Why use a null record rather than no record at all? Well, if you have a mail client that wants to know what connection options are available, by explicitly specifying that I don’t offer _imap._tcp at all a client will know to only use the _imaps._tcp record which ensures there is no possibility of the client sending an unencrypted password.

1 Like

In combination with “.” as host I agree, that could be considered a “null” record. Otherwise it still could be a valid entry.

I am afraid you’ve lost me there. If you dont offer the service there is no point in specifically advertising that you dont. So I am not convinced there’d be a benefit of such a record.

If SRV records existed from the start and were mandatory then we might have a different situation, but at the moment the lack of a SRV record does not indicate a particular service isn’t offered, it can just as easily indicate that the administrator hasn’t bothered to create a SRV record.

A simple case is that without a SRV record, clients may fall back to guessing and can end up with a sub-optimal or incorrect configuration.

I get your point, but it does not explain how that is a benefit if the service is not offered anyhow. The client can guess as much as it likes if the service is not offered it wont be able to connect.

To start off with, guessing can take a lot of time, on the order of several minutes if networks are misconfigured to drop packets rather than rejecting connections.

More importantly though, when clients start guessing they can easily end up broadcasting credentials to incorrect servers, potentially in plaintext.

Let’s look at the reverse: What is the value in restricting RFC-valid records (records which are already in normal use) from being created?

We will have to agree to disagree on this.

First, clients should not guess in the first place. Second, even if they do it wouldnt take minutes and would quickly get re-configured. Third, if they cant connect they cant send credentials either.

I get your point but I still dont recognise the benefit in specifying it.

The reality today is that clients do guess, it does sometimes take minutes to fail, and they really do send credentials to unexpected places. I don’t like it any more than you do, but this is already reality.

Mail clients are a great example, in a worst-case scenario clients often try the bare domain, various prefixes (mail., imap, imap4, smtp., pop, pop3, etc) each on multiple ports (25, 110, 143, 465, 587, 993, 995, and I’ve seen some that hit 2525 and others), potentially on each of IPv4 and IPv6. If the domain has a wildcard DNS record pointing to an IP that drops packets (rather than sending a connection failure packet) then each of these takes one timeout to fail. The default timeout is typically going to be 60 seconds for a TCP connection and 300 seconds for each command if a TCP session is accepted and the server decides to be slow.

While you could make multiple attempts in parallel, typically most mail clients don’t.

Yes, this is a worst case scenario, if the connections get a proper TCP RST or ICMP response then no timeout are needed, often there is only IPv4, and hostnames that don’t exist can be quickly skipped. These are not always things that are under my control.

Clients also do end up sending credentials: Consider the above example, my mail server might be, but my wildcard DNS record might point to a webserver hosted by a third party who happens to have their own SMTP/POP3/IMAP servers. In this case the client will get a connection and will then attempt to authenticate. It fails, but the damage is done: the credentials have been transmitted across the wire.

It is a lot easier to convince client authors to stop guessing when they get real answers from SRV records, but it will likely never happen that clients stop guessing in the absence of autoconfiguration hints simply because creating a negative first-try onboarding experience results in a high user abandon rate, and increases technical support load for those users who do stick around. Some protocols have a high adoption rate for SRV records and therefore default to “no record = no service autoconfiguration”, but for legacy protocols that predate SRV records autoconfiguration guesswork is the best fallback.

I haven’t seen any suggestion as to why valid records should be refused.

No offence, but there is way too much speculation, what-ifs, and extreme/unlikely examples in there. E.g. the sending of credentials - if you dont have the service, as you said, nothing will be sent. Of course, if you still have an unsecure or different service configured the story will be different but then it is a configuration issue in the first place.

But again, lets agree to disagree, I really would not want to hijack this thread.

No speculation at all, I’ve spent my entire career in the SMB space, much of it on email specifically. This is how things currently work.

You don’t bump into such things setting up a account or similar because clients have databases of large domains and mechanisms to detect large hosting providers and work through it automatically.

A 20 employee roofing company does not get into these databases and instead relies on client based auto configuration. Annoyingly there is a trend toward not even exposing manual settings until auto configuration fails (Spark is a good example of this).

Ideally I don’t run random servers I don’t need, but when I’m working with a client to move their self-hosted email to a new platform I don’t have the luxury to tell them to change web hosting providers because their current one has a SMTP service (a server that someone likely needs and uses) and doesn’t return TCP RST packets to closed ports.

But again, why not support the valid values as specified by the RFCs? If the RFC authors intended port numbers to start at 1, they would have said so, instead the standard is explicitly written to allow port numbers starting from 0. Cloudflare implemented only a subset of the standard without there being any technical limitation as to why, and based on the fact that this does come up, it is obviously something that impacts more than just me.

It is accepted via the API at the moment. Not sure of the status of UI.


I beg to differ :slight_smile:

I was not saying it should not be supported, I was saying I dont see much point in specifying such a record.

Actually port zero is accepted. The issue is the hostname. A . is automatically changed into the naked domain.

True, just ran a test and it accepted it. So it seems to be a UI issue where it converts the period into the naked domain.

Just as heads-up, Cloudflare API Documentation could do with an update in regard to SRV records. The required parameters are not really required in this context but the required data field is not mentioned at all.