New (silent) reverse dns checks
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
Jonas Frey wrote:
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.
Indeed? Really? Wow.
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.
We strongly agree. Don't blacklist open resolvers RIPE! -- nemox.net Rudolf E. Steiner r.steiner@nemox.net http://nemox.net/pdat/res/
On 7 Jun 2019, at 11:29, Rudolf E. Steiner <r.steiner@nemox.net> wrote:
Don't blacklist open resolvers RIPE!
Surely running an open resolver and your authoritative name server on the same IP address is not considered good practice? Split them into different IP addresses and RIPE won’t mind. Simon
Simon Lockhart quoted/wrote:
Don't blacklist open resolvers RIPE! Surely running an open resolver and your authoritative name server on the same IP address is not considered good practice?
Not in all situations.
Split them into different IP addresses and RIPE won’t mind.
I know. But RIPE is not the internet-police. Don't block open resolvers! You can warn, if you want. -- nemox.net Rudolf E. Steiner r.steiner@nemox.net http://nemox.net/pdat/res/
On 7 Jun 2019, at 12:54, Rudolf E. Steiner <r.steiner@nemox.net> wrote:
Split them into different IP addresses and RIPE won’t mind.
I know. But RIPE is not the internet-police.
Don't block open resolvers! You can warn, if you want.
Most registrars check the same for forward delegations so I think RIPE checking the same for reverse make sense. - Kurtis -
why does it make sense? I don't see how one follows from the other. Registrars doing such checks are generally frowned upon as they get in the way of out-of-order provisioning. On Fri, Jun 7, 2019 at 2:07 PM Kurt Erik Lindqvist <kurtis@linx.net> wrote:
On 7 Jun 2019, at 12:54, Rudolf E. Steiner <r.steiner@nemox.net> wrote:
Split them into different IP addresses and RIPE won’t mind.
I know. But RIPE is not the internet-police.
Don't block open resolvers! You can warn, if you want.
Most registrars check the same for forward delegations so I think RIPE checking the same for reverse make sense.
- Kurtis -
_______________________________________________ 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/job%40instituut.net
On 7 Jun 2019, at 13:09, Job Snijders <job@instituut.net> wrote:
why does it make sense? I don't see how one follows from the other. Registrars doing such checks are generally frowned upon as they get in the way of out-of-order provisioning.
If you mean that you request delegation to non-existing or stale DNS I am not sure why that would be a good thing? As in the case for open resolvers, if you really have a use case for them you can separate the IPs. I am pretty convinced that in the vast majority of cases where RIPE detects an open resolver there should not be one. So closing these is a good thing. - Kurtis -
Out-of-order provisioning is in 98% (my experience, see further down) of the cases a bad idea, and in transfer cases simply ends up blacking out the resource for an unnecessarily long time. I personally started verifying presence of running zone at the receiving operator when I was one of two people running redelegations of SE children, and while verification was cumbersome, the net result was that the least empowered, the end users who just wanted their domain to work, in the overwhelming majority of cases were transferred with a minimum of down time. When we did not verify, the usual order was "no email for a week, because it all bounces". Since then, people quit using email, and started living their lives online instead, and the systems people came up with all manners of clever OLTP-style provisioning tools. Or more succinctly: I think "out-of-order provisioning" is a very weak argument 2019. And, open resolvers have no place on authoritative servers. Full stop. -- Måns Nilsson SVT +46 8 7848628 Den 2019-06-07 14:12 skrev "members-discuss på uppdrag av Job Snijders" <members-discuss-bounces@ripe.net på uppdrag av job@instituut.net> följande: why does it make sense? I don't see how one follows from the other. Registrars doing such checks are generally frowned upon as they get in the way of out-of-order provisioning. On Fri, Jun 7, 2019 at 2:07 PM Kurt Erik Lindqvist <kurtis@linx.net> wrote: > > On 7 Jun 2019, at 12:54, Rudolf E. Steiner <r.steiner@nemox.net> wrote: > > >> Split them into different IP addresses and RIPE won’t mind. > > > > I know. But RIPE is not the internet-police. > > > > Don't block open resolvers! You can warn, if you want. > > Most registrars check the same for forward delegations so I think RIPE checking the same for reverse make sense. > > - Kurtis - > > _______________________________________________ > 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/job%40instituut.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/mans.axel.nilsson%40s...
On 7 Jun 2019, at 20:39, Måns Nilsson <mans.axel.nilsson@svt.se> wrote:
And, open resolvers have no place on authoritative servers. Full stop.
+100 Måns! Torbjörn Eklöv | Interlan Gefle AB Marielundsvägen 2, 803 22 GÄVLE Växel: 026-18 50 00 | Direkt: 070-683 51 75 http://www.dnssecandipv6.se "A home without IPv6 is just a house"
On Fri, Jun 07, 2019 at 06:53:37PM +0000, Torbjörn Eklöv wrote:
On 7 Jun 2019, at 20:39, Måns Nilsson <mans.axel.nilsson@svt.se> wrote:
And, open resolvers have no place on authoritative servers. Full stop.
+100 Måns!
This is all great and I agree. However, it is not RIPE NCC's place to dictate what one does on one's servers/services. Unless RIPE NCC has a financial stake in the operation, I'd prefer it if they don't make any evaluations and just do as instructed. Kind regards, Job
Hi, On Sat, Jun 08, 2019 at 04:14:57PM +0000, Job Snijders wrote:
On Fri, Jun 07, 2019 at 06:53:37PM +0000, Torbjörn Eklöv wrote:
On 7 Jun 2019, at 20:39, Måns Nilsson <mans.axel.nilsson@svt.se> wrote:
And, open resolvers have no place on authoritative servers. Full stop.
+100 Måns!
This is all great and I agree. However, it is not RIPE NCC's place to dictate what one does on one's servers/services. Unless RIPE NCC has a financial stake in the operation, I'd prefer it if they don't make any evaluations and just do as instructed.
Well, I assume they *do* as instructed: do checks on the sanity of the request, as per consensus in the DNS WG. Which is the place to discuss whether to change said consensus. I, for one, am a great fan of having as strict DNS checks as possible - because for everyone who can convincingly explain to me that *he* is the big exception and this really is not something he wants to have, I see 1000 broken DNS setups where having whatever checks in place is a very good thing. (I maintain our DNS infrastructure, so I see a lot of "interesting" approaches to DNS...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Den 2019-06-09 00:08 skrev "Job Snijders" <job@instituut.net> följande:
This is all great and I agree. However, it is not RIPE NCC's place to dictate what one does on one's servers/services. Unless RIPE NCC has a financial stake in the operation, I'd prefer it if they don't make any evaluations and just do as instructed.
Looking at RFC 1591, I think there are reasons for the NCC to actually evaluate the technical status of name servers to which delegation is sought. (While 1591 mostly is talking about, and has been quoted in, forward DNS operations, it encompasses all delegations from the root, including ARPA and children.) Yes, this should move to dns-wg. I'll send a starting message there. /Måns -- Måns Nilsson SVT +46 8 7848628
Mans, can you explain why? ISC (as for bind) itself only states that separting them has one purpose: protecting from downtimes should one fail [1] DJ Bernstein stated it also has protective reasons due to ressource exhaustion [2] (but that info is from 2003). With current hardware in 2019 i hardly see this possible. Even more unlikely if combined with RRL (on bind), which is neccessary for anything open nowadays. With uRPF on the network side this handles quite well. Given all this, what are the real reasons in 2019 to not combine recursor and auth.? - Jonas [1] https://kb.isc.org/docs/bind-best-practices-authoritative [2] https://cr.yp.to/djbdns/separation.html
And, open resolvers have no place on authoritative servers. Full stop.
-- Måns Nilsson SVT +46 8 7848628
Ok, Mentioning djb and DNS operations is a bait, but I'm stupid and I'll bite. 1. Cache poisoning. Yeah, the risk is lessened since BIND 9 has way better memory management and data structures than older software, but there are corner cases still. 2. Operational integrity. I do not like having stupid stub resolvers as clients hardwired to my backend system. The stub resolver <-> full service resolver relation is a lot less resilient than the self-healing and adaptive relation between full-service resolver and name server. If I suddenly have clients that are unable to select another server (except by timeout, and then won't learn from it) a lot more outages become service affecting. If one of say 4 name servers for a zone stops answering, no one except monitoring systems will notice. If one of four resolvers stops, 25% of the clients will claim that the Internet is b0rkened. (nothing today feels like working when the timeout to server #2 in /etc/resolv.conf is between 5 to 10 seconds...) 3. Bedwetting is nice until it gets cold. Having an authoritative name server as resolver will mask out real delegation problems further up in the delegation chain, giving issues like "It looks OK here" which is business-affecting ignorance. 4. Resource exhaustion is real. I have recent experience from a corporate system where there was a mixup of name service and resolver service. That was not a nice way to start a Friday morning. I encourage my competitors to run BIND 8 as resolver and name server. Myself, I stopped doing that in 2001. -- Måns Nilsson SVT +46 8 7848628 Den 2019-06-07 22:03 skrev "Jonas Frey" <ripe@probe-networks.de> följande: Mans, can you explain why? ISC (as for bind) itself only states that separting them has one purpose: protecting from downtimes should one fail [1] DJ Bernstein stated it also has protective reasons due to ressource exhaustion [2] (but that info is from 2003). With current hardware in 2019 i hardly see this possible. Even more unlikely if combined with RRL (on bind), which is neccessary for anything open nowadays. With uRPF on the network side this handles quite well. Given all this, what are the real reasons in 2019 to not combine recursor and auth.? - Jonas [1] https://kb.isc.org/docs/bind-best-practices-authoritative [2] https://cr.yp.to/djbdns/separation.html > And, open resolvers have no place on authoritative servers. Full > stop. > > -- > Måns Nilsson SVT > +46 8 7848628
Mans, 1) Ok, but as you say this is a corner case and has to be decided on a rare per-case basis.2) Ok, but this would require the resolvers to be actually down/broken which can be mitigated by monitoring (as you say). The stability is dependent on the software one is using, so this is again a per-case basis. Basically this is (almost) what ISC is saying in the link i provided. 3) Basically same as 2) which (if proper monitoring is in place) can be mitigated easily. 4) Not seen this yet (with proper limiting via RRL et al in place). All of this is very situation dependent and (in my eyes) doesnt apply to every setup. Now as for the pro's of a combined setup i can see: - less resources (i.e. no additional IP addresses "wasted", no requirement for a 3rd/4th server/VM) - less operational effort (i.e. managing 2 servers vs. 4) But i think this is now going way off-topic and should probably be discussed on the dns-wg of RIPE as per Anand's recommendation. The bottom line is that if a feature is changed or dropped i'd like to be noticed (best in advance) of that and that this is actually compiled into a rule set or BCP for people using that service. (and that this is readable somewhere, which isnt the case right now) - Jonas Am Freitag, den 07.06.2019, 20:22 +0000 schrieb Måns Nilsson:
Ok,
Mentioning djb and DNS operations is a bait, but I'm stupid and I'll bite.
1. Cache poisoning. Yeah, the risk is lessened since BIND 9 has way better memory management and data structures than older software, but there are corner cases still.
2. Operational integrity. I do not like having stupid stub resolvers as clients hardwired to my backend system. The stub resolver <-> full service resolver relation is a lot less resilient than the self- healing and adaptive relation between full-service resolver and name server. If I suddenly have clients that are unable to select another server (except by timeout, and then won't learn from it) a lot more outages become service affecting. If one of say 4 name servers for a zone stops answering, no one except monitoring systems will notice. If one of four resolvers stops, 25% of the clients will claim that the Internet is b0rkened. (nothing today feels like working when the timeout to server #2 in /etc/resolv.conf is between 5 to 10 seconds...)
3. Bedwetting is nice until it gets cold. Having an authoritative name server as resolver will mask out real delegation problems further up in the delegation chain, giving issues like "It looks OK here" which is business-affecting ignorance.
4. Resource exhaustion is real. I have recent experience from a corporate system where there was a mixup of name service and resolver service. That was not a nice way to start a Friday morning.
I encourage my competitors to run BIND 8 as resolver and name server. Myself, I stopped doing that in 2001.
-- Måns Nilsson SVT +46 8 7848628
Den 2019-06-07 22:03 skrev "Jonas Frey" <ripe@probe-networks.de> följande:
Mans, can you explain why? ISC (as for bind) itself only states that separting them has one purpose: protecting from downtimes should one fail [1] DJ Bernstein stated it also has protective reasons due to ressource exhaustion [2] (but that info is from 2003). With current hardware in 2019 i hardly see this possible. Even more unlikely if combined with RRL (on bind), which is neccessary for anything open nowadays. With uRPF on the network side this handles quite well. Given all this, what are the real reasons in 2019 to not combine recursor and auth.? - Jonas [1] https://kb.isc.org/docs/bind-best-practices-authoritative [2] https://cr.yp.to/djbdns/separation.html > And, open resolvers have no place on authoritative servers. Full > stop. > > -- > Måns Nilsson SVT > +46 8 7848628
_______________________________________________ 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
Most registrars check the same for forward delegations so I think RIPE checking the same for reverse make sense.
Kurt, thats exactly what i wrote previously. Some do check and if they do, they warn - none block. And so should RIPE - but RIPE blocks. There was no notification from RIPE about this change (atleast we didnt see it) and as that it breaks existing functionality. If RIPE really wants to deny open resolvers (for whatever reason), why not notify members about the upcoming change so people have appropiate time to apply changes? I'd be OK with that, however i'd prefer RIPE to not block at all. (RIPE should be neutral on that) -Jonas
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%40ripe.net
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
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
participants (9)
-
Anand Buddhdev -
Gert Doering -
Job Snijders -
Jonas Frey -
Kurt Erik Lindqvist -
Måns Nilsson -
Rudolf E. Steiner -
Simon Lockhart -
Torbjörn Eklöv