[members-discuss] New (silent) reverse dns checks

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