Dear Jonas, It's possible that a bug or accidental misconfiguration in the reverse DNS delegation checking system did not flag an open resolver as a problem, though this is an exceptional case. You are correct that we do not explicitly publish all of the criteria regarding which conditions will result in a delegation update being rejected. We can improve this by publishing them more clearly. Lastly, I stated that the IANA (not ccTLD registries) will not delegate to open recursive name servers: https://www.iana.org/help/nameserver-requirements I am happy to discuss your specific case further if you contact me off-list. I'm sure we can find a solution. Regards Anand Buddhdev RIPE NCC On 2019-06-07 15:50, Jonas Frey wrote:
Dear Anand,
that is not true. I have just briefly checked some blocks and we made changes in (atleast) 2016 which did pass (without warning). I can send you the relevant blocks in a separate message. Either your information is incorrect or the enforcement was not working properly before.
Where exactly does RIPE state that the nameserver is not allowed to be a recursor? I cannot find any information in any paper on this.
As stated previously, i am indeed talking about a managed public resolver which does imburse rate-limiting and other security measures.
Which ccTLD do you mean in detail? I have just done some quick checks: .de - DENIC: Warning but passes .eu - EURID: Pass, no warning .com - Verisign: Pass, no warning
As you can see, you are alone on enforcing this.
- Jonas
Am Freitag, den 07.06.2019, 15:07 +0200 schrieb Anand Buddhdev:
Dear Jonas,
We have denied reverse DNS delegation to open recursive resolvers for over a decade now. There has not been any recent change to our DNS check software or policy.
Open recursive resolvers (as opposed to managed public resolvers like Google or Cloudflare DNS) are generally considered to be a security risk. They are vulnerable to cache poisoning or may be used to launch DNS response amplification attacks against other servers.
Almost all cases of open recursive resolvers are due to misconfiguration of a name server, and users are usually not aware of the security risks. Our reverse DNS checks help users to improve their configuration and security practices, and generally contribute to a safer Internet.
We are not alone in enforcing this check. IANA does the same for delegations to name servers of ccTLDs, for example.
If you feel this check is too stringent, we invite you to start a discussion in the RIPE DNS Working Group. We will be happy to adjust our policy for reverse DNS checks based on input from the working group.
Regards
Anand Buddhdev Senior System Engineer RIPE NCC
On 2019-06-07 12:20, Jonas Frey wrote:
Hi all,
we just found out that RIPE seems to have silently integrated new checks for reverse delegation of zones. Its no longer possible to add or even change a zone if the nameservers used by them are open recursors. The update will fail. Yes - open recursors are (sometimes) bad. But there are legitimate reasons to run them (freedom of speech, filtered resources etc). Once properly configured (i.e. querys rate limited) they wont pose a threat.
I wasnt able to find any information on when this was implemented or if this was even voted for (please someone supply me with links if possible).
I dont know of any NIC/registrar that will deny the creation/update of a domain name if the nameservers are recursors. I know that some will warn but none will refuse it. Please fix me if there are some which will indeed deny.
Of course i have created a ticket about this but it all went like "fix the dns or we wont delegate".
So basically this is about 2 things: silently changing checks (if it was indeed silent) and if those checks are really usefull or should rather be dropped/changed to warnings.
Regards, Jonas
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/agollan%40ri pe.net
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/r ipe%40probe-networks.de
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/agollan%40ripe.net