[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://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 at 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 at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > 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 ]