This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/members-discuss@ripe.net/
[members-discuss] New (silent) reverse dns checks
- Previous message (by thread): [members-discuss] New (silent) reverse dns checks
- Next message (by thread): [members-discuss] New (silent) reverse dns checks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Anand Buddhdev
anandb at ripe.net
Fri Jun 7 16:30:32 CEST 2019
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 at ripe.net >> > https://mailman.ripe.net/ >> > Unsubscribe: >> > https://lists.ripe.net/mailman/options/members-discuss/agollan%40ri >> > pe.net >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://mailman.ripe.net/ >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/r >> ipe%40probe-networks.de > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://mailman.ripe.net/ > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/agollan%40ripe.net
- Previous message (by thread): [members-discuss] New (silent) reverse dns checks
- Next message (by thread): [members-discuss] New (silent) reverse dns checks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]