DNS verification in ProtonMail is completely insecure!

[yaydabug]

ProtonMail does not use authoritative name servers for DNS verification for custom domains!

This means that anyone with a little knowledge can perform a DNS poisoning attack on any public non-authoritative name server, resulting in unauthenticated verification of domains that aren't owned by the attacker.

Instead of looking for the domain's authoritative name servers, ProtonMail looks for a public DNS resolver, which may cache bogus zones.

[bartbutler]

Our resolvers absolutely use authoritative name servers and not any third-party resolvers. What evidence do you have that we do not?

If you think you have found a bug, please file a report here: https://proton.me/security/bug-bounty.

[yaydabug]

Anyone using the dig command can see that ProtonMail does not use the domain's authoritative name servers.

Because you're lying, I'd like to see those resolvers that "absolutely use authoritative name servers."

[bartbutler]

I might be slow today but I have no idea what that means. dig queries performed by anyone have no bearing on what kinds of queries our resolvers execute and where.

[yaydabug]

I actually run authoritative name servers and have never received a single query from ProtonMail for the domains I added for verification, despite the fact that the zone files for the domains are obviously on the authoritative name server.

If ProtonMail "absolutely use authoritative name servers," the domain would already be verified, but this is clearly not the case.

ProtonMail does not look for the authoritative name server because the public DNS resolvers lack the TXT record. The dig command, on the other hand, clearly demonstrates that the authoritative name servers are indeed returning the expected TXT record.

[bartbutler]

The NXDOMAIN could be cached. If you can supply a domain name, I can check for you what's going on, or open a ticket if you are not comfortable posting it here.

[yaydabug]

NXDOMAIN should be returned only if the domain does not exist!

Assume your resolver returns NXDOMAIN for PROTON.ME because a TXT record that you requested is missing. When the requested TXT record is not found, returning an NXDOMAIN is extremely serious and should never happen!

[bartbutler]

Sorry, I meant the empty TXT set. In any case, I can look at any specific case you'd like me too.

[yaydabug]

If any record is missing from the zone when you lookup, the resolver will and should always return NOERROR, unless you are looking for non-existent subdomains. That is the only situation in which you can obtain an NXDOMAIN. NXDOMAIN is never caused by a missing TXT record.

[bartbutler]

Yes, I misspoke.

[yaydabug]

Example:

$ whois example.com ... name server: ns1.example.com name server: ns2.example.com

$ dig example.com NS ;; ANSWER SECTION: example.com. 8600 IN NS ns1.example.org. example.com. 8600 IN NS ns2.example.org.

$ dig example.com SOA ;; ANSWER SECTION: example.com. 8600 IN SOA ns1.example.org. ...

In this case, the authoritative name servers for example.com are ns1.example.org and ns2.example.org.

[bartbutler]

What domain do want me to debug?

[yaydabug]

You are not required to "debug" any domain. As previously stated, ProtonMail does not look for records on authoritative name servers.

I'm very curious about how ProtonMail looks up DNS records. You should talk about it or show me the relevant section of the source code.

Here's another, more straightforward example:

└─$ nslookup protonmail.ch
Server: 10.10.0.1 Address: 10.10.0.1#53

Non-authoritative answer: Name: protonmail.ch Address: 185.70.42.21

└─$ nslookup protonmail.ch dns.quad9.net
Server: dns.quad9.net Address: 9.9.9.9#53

Non-authoritative answer: Name: protonmail.ch Address: 185.70.42.21

AUTHORITATIVE:

└─$ nslookup protonmail.ch ns1.protonmail.ch Server: ns1.protonmail.ch Address: 185.70.42.150#53

Name: protonmail.ch Address: 185.70.42.21

[bartbutler]

I get what you're saying, and I'm saying our resolvers do use authoritative name servers--we use no third-party DNS resolve services. Failure to contact your servers could be several things, including some kind of network issue, and the domain checks are periodic as well. The fastest way for me to check a given domain with our resolvers is to know which domain you are having problems with.

[yaydabug]

Of course, you understand now.

Please post the address of ProtonMail's DNS resolver here or show me the relevant sections of the source code.

[bartbutler]

Our production resolvers are private and do not have public IPs or accept requests from public IPs (of course). I think this conversation has reached it's conclusion unless you are willing to help me help you with the problem you are experiencing. If you'd rather file a support ticket, feel free.

[yaydabug]

I'll say it again.

ProtonMail does not search authoritative name servers for records.

The concept of "caching" that you mentioned would be meaningless if ProtonMail looked for the records on the authoritative name servers. Caching is performed by non-authoritative public DNS servers.

ProtonMail should determine which name servers are authoritative before querying the record from that/those servers.

Neither my domain, zone, or DNS servers are experiencing any problems and are correctly responding to requests.

The previously mentioned problem exists only in your system.

[bartbutler]

We cache SERVFAILs as well, so if our resolvers can't reach your authoritative name servers, they might cache an error (not sure how long the TTL for that is in the configuration). We also may have made a query for TXT records before you added the verification record, that was the caching I was alluding to before, in which case the result set would have the associated TTL.

[yaydabug]

ProtonMail should never cache anything if attempting to validate a record that may be missing at the time of the query.

The zone file as a whole may have set the expiry to one year, so if ProtonMail query the non-existent record, ProtonMail deny the verification for one year? How does that make sense?

Because ProtonMail is not a public DNS resolver, caching makes no sense. In the case of DNS cache poisoning it would be even a fatal mistake.

[bartbutler]

We don't cache SERVFAILs for any large amount of time, but we do cache them to avoid retrying failures too quickly. Anyway, the caching is likely irrelevant here. What I'm guessing is happening is that our resolvers can't reach your name servers for whatever reason, which is something I'd like to look into but I need an affected domain to do that.

[yaydabug]

It's amazing how you start blaming the user when your company clearly has issues.

I've said it before and will say it again: ProtonMail does not look for records on authoritative DNS servers. A query to the authoritative DNS server would return the TXT and other records right away.

You should either show me the relevant source code or reveal the ProtonMail's super-secret DNS resolver.

[bartbutler]

Weird networking failures happen--it's not blaming the user. And sure, it could be something broken in our resolver stack that is affecting your domain specifically. But I can't figure that out if I don't have a domain to look up. What I can say is that we do do lookups on authoritative DNS servers, and I don't understand why you are convinced we do not and what evidence you are basing that conclusion on.

We host tens of thousands of domains which verify fine, so if it is an issue on our end, which I have said from the beginning it very well could be, it is not super widespread. But I very much would like to track down your issue, I just need a domain to do so. Or file a ticket with the information and our CS people who do this every day will look into it, and it'll have no connection to this conversation, that's fine too.