NCC reverse delegation criteria
Hello all, as for this topic, i have started the discussion on the members-discuss list. So far it seems there are various opinions about this topic. From the replys i have received it seems these are: - Dont run a open resolver, let RIPE block - Dont run a open resolver, let RIPE warn - Run a open resolver and secure it propely, RIPE pass - Dont check anything, RIPE pass - Let RIPE check for amplification level, decide on that The main question is if RIPE should prohibit technically valid configurations. IMO: if the open resolver+auth. resolver is considered a bad setup (for operational reasons/resilience or whatever) then that should be left up to the company running it (as possible impact is limited to that - besides amplification). (However there seem to be huge controversal thoughts about this, i.e. if dividing both functions is still neccessary in 2019) As previously noted most (if not all) ccTLD registrys do not block when a open recursor is found. (C/N/O: Verisign pass, EU EURID: pass, DE DE- NIC: pass with warn). Now that these ccTLDs deal with *alot* more nameservers than RIPE (probably), why would it make sense for RIPE to force a block of them? -- Mit freundlichen Grüßen / Best regards, Jonas Frey ---------------------------------------------------------------- Probe Networks Jonas Frey e-Mail: jf@probe-networks.de Auf Strützberg 26 D-66663 Merzig Tel: +(49) (0) 6861 90897-00 Fax: +(49) (0) 6861 90897-99 Internet: www.probe-networks.de Hotline: 0800 1656531 ---------------------------------------------------------------- Diese E-Mail enthaelt moeglicherweise vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist strengstens untersagt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the contents of this e-mail is strictly prohibited. ------------------------------------------
On 11 Jun 2019, at 17:28, Jonas Frey <jf@probe-networks.de> wrote:
Run a open resolver and secure it propely
These two things are mutually exclusive. Sorry.
Run a open resolver and secure it propely These two things are mutually exclusive. Sorry.
Well, then all of these (running open resolvers) must be wrong: - Google - Cloudflare - Quad9 - OpenDNS - Yandex - Comodo - Norton - Clean Browsing - ... Anyway, isnt this the wrong discussion? The topic is wether RIPE should block, warn or pass these resolvers. - Jonas
On 11 Jun 2019, at 17:58, Jonas Frey <jf@probe-networks.de> wrote:
Run a open resolver and secure it propely These two things are mutually exclusive. Sorry.
Well, then all of these (running open resolvers) must be wrong: - Google - Cloudflare - Quad9 ...
They’ve taken business decisions that the risks of operating open resolvers are worth the rewards. And AFAICT, they don't intermingle recursive and authoritative DNS on the same server(s).
Anyway, isnt this the wrong discussion? The topic is wether RIPE should block, warn or pass these resolvers.
Indeed.
Em 11 de jun de 2019, à(s) 13:58:000, Jonas Frey <jf@probe-networks.de> escreveu:
Run a open resolver and secure it propely These two things are mutually exclusive. Sorry.
Well, then all of these (running open resolvers) must be wrong: - Google - Cloudflare - Quad9 - OpenDNS - Yandex - Comodo - Norton - Clean Browsing - ...
Anyway, isnt this the wrong discussion? The topic is wether RIPE should block, warn or pass these resolvers.
None of those organisations run authoritative servers on the same open recursive servers, either for direct or reverse domains. Rubens
None of those organisations run authoritative servers on the same open recursive servers, either for direct or reverse domains.
Rubens
Rubens, neither me nor Jim Reid claimed that here, please re-read our replys:
Run a open resolver and secure it propely
These two things are mutually exclusive. Sorry.
On 11 Jun 2019, at 17:28, Jonas Frey <jf@probe-networks.de> wrote:
As previously noted most (if not all) ccTLD registrys do not block when a open recursor is found. (C/N/O: Verisign pass, EU EURID: pass, DE DE- NIC: pass with warn). Now that these ccTLDs deal with *alot* more nameservers than RIPE (probably), why would it make sense for RIPE to force a block of them?
With the exception of gTLDs who pretty much have to do what ICANN tells them, registries are free to make their own policies on delegation. If the RIPE community wants a more restrictive or liberal delegation policy for reverse zones than some other registry, that is perfectly fine. The community decides. And what’s “right” for one registry isn’t necessarily right for another. It’s not a question of how many/few nameservers a registry might need to check. That’s (mostly unimportant) implementation detail.
IMO: if the open resolver+auth. resolver is considered a bad setup (for operational reasons/resilience or whatever) then that should be left up to the company running it (as possible impact is limited to that - besides amplification).
Nope. There are other much more unpleasant impacts: consider cache poisoning. If your authoritative server also handles arbitrary recursive queries, I can make your name server query my DNS server which tells lies. Unless your server does DNSSEC validation, it will then spread these lies for me. Thanks! Worst case, I might even be able to hijack your authoritative domains by injecting new glue records for those domains into your server’s cache. That said, I’m usually not in favour of preventing people or companies from doing stupid things - like intermingling recursive and authoritative DNS servers. [Darwinism will always win in the end.] I can get paid $$$$ to fix these broken setups. :-) But more importantly, people tend to learn best from their mistakes because they then make sure they don’t repeat them. As someone once said “The IETF is not in the business of hanging people. But it does provide plenty of rope.”. I think those comments apply very well here too.
Nope. There are other much more unpleasant impacts: consider cache poisoning.
If your authoritative server also handles arbitrary recursive queries, I can make your name server query my DNS server which tells lies. Unless your server does DNSSEC validation, it will then spread these lies for me. Thanks! Worst case, I might even be able to hijack your authoritative domains by injecting new glue records for those domains into your server’s cache.
That said, I’m usually not in favour of preventing people or companies from doing stupid things - like intermingling recursive and authoritative DNS servers. [Darwinism will always win in the end.] I can get paid $$$$ to fix these broken setups. :-) But more importantly, people tend to learn best from their mistakes because they then make sure they don’t repeat them.
As someone once said “The IETF is not in the business of hanging people. But it does provide plenty of rope.”. I think those comments apply very well here too.
Jim, i am aware of that - it was discussed on the member-discuss list, too. If cache poising is beeing taken care of (be it via DNSSEC or else) what other reasons are there to not combine both? So far, the most important points i do see are amplification and poisioning which both can be mitigated, what am i missing? It seems to me that all documentation regarding this topic is highly outdated (atleast what i have found, see ISC's docs for BIND). Sorry...but once again going into detail on this topic. - Jonas
Hi, On Tue, Jun 11, 2019 at 07:52:18PM +0200, Jonas Frey wrote:
If cache poising is beeing taken care of (be it via DNSSEC or else) what other reasons are there to not combine both?
Well, the reason we separated these functions (like some 20 years ago) was "provisioning of customer domains that are not delegated to us at the corresponding TLD servers". So, asking our recursives would give *different* answers than "the formally correct one" if they also hold authoritative zones which have not yet been delegated to us (or have been moved away from us, and updated at their new ISP, while our zones have not yet been deleted and still serve the old values). The time window might be small, but serving wrong answers was not acceptable for us. OTOH, while not the original reason, we're quite happy with the decision to split the function, because now we can mix and match DNS software according to their strenghts - recursive runs unbound and pdns_recursor, authoritative runs bind and knot. And possibly nsd one day. Without having to consider "will this nice authoritative DNS software package do recursive as well?"... Can you explain why it would be desirable to *have* these unified? 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
Gert,
The time window might be small, but serving wrong answers was not acceptable for us.
ok, but in the automated world of today this small window is likely to be _really_ small.
Can you explain why it would be desirable to *have* these unified?
Gert Doering -- NetMaster
I do see 3 major benefits to combine/unify these: - "saving" IP addresses (depending of how many you run of course[1]) - less effort managing (not having multiple places for configuration thus unifiying [automated] setup) - saving ressources (servers, virtual machines, whatever they run on) - Jonas [1] reminds me of http ssl virtual host per-ip setups...from time ago...
Hi, On Tue, Jun 11, 2019 at 08:40:05PM +0200, Jonas Frey wrote:
The time window might be small, but serving wrong answers was not acceptable for us.
ok, but in the automated world of today this small window is likely to be _really_ small.
Only if everything works perfectly. Especially "customer asks for the auth records and then moves their delegation at some unspecified point in time" is something you can only catch by regularily polling the delegating servers - which we certainly could do (like "every 5 seconds") - but today, we poll once a day, and are not in a hurry.
Can you explain why it would be desirable to *have* these unified?
I do see 3 major benefits to combine/unify these: - "saving" IP addresses (depending of how many you run of course[1]) - less effort managing (not having multiple places for configuration thus unifiying [automated] setup) - saving ressources (servers, virtual machines, whatever they run on)
Except for the "saving IP addresses" part I find this not overly convincing - these things are different, and treating them as such makes provisioning, monitoring, and sizing way easier. And yeah, you can save like 2 IP addresses... (two recursors, all those addresses anycasted to as many instances as you need for scale anyway). 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
Gert Doering wrote on 11/06/2019 21:50:
On Tue, Jun 11, 2019 at 08:40:05PM +0200, Jonas Frey wrote:
The time window might be small, but serving wrong answers was not acceptable for us.
ok, but in the automated world of today this small window is likely to be _really_ small.
Only if everything works perfectly. Especially "customer asks for the auth records and then moves their delegation at some unspecified point in time" is something you can only catch by regularily polling the delegating servers - which we certainly could do (like "every 5 seconds") - but today, we poll once a day, and are not in a hurry.
Incidentally, I've seen "really small" last about 10 years for one particular domain, starting some time around 2008-2009 and ending a couple of months ago. Good thing that server wasn't doing resolution because 10Y of broken dns responses would have been messy. There doesn't seem to be any particular reason for the RIPE NCC to change their operational practice here; nor is there any compelling reason for the DNS WG to jump and start dishing out instructions to the RIPE NCC about how to do their job. It looks entirely like a case of "good to see common sense prevailing. pls carry on". Can we move on now? There are plenty of actual dns problems in the world to solve which don't relate to accommodating monumentally awful operational practice. Nick
I do see 3 major benefits to combine/unify these: - "saving" IP addresses (depending of how many you run of course[1]) Should not be a problem with IPv6, and running the same function
Moin! On 11 Jun 2019, at 20:40, Jonas Frey wrote: like http on the same IP is quite different from running different functions (recursive vs authoritative DNS) on the same IP.
- less effort managing (not having multiple places for configuration thus unifiying [automated] setup) That is wrong. You have more efforts managing as you need to update the sever software more often. I can not count the numbers of times some CVE in bind was caused by the fact that it is both a recursive and authoritative server. From a security these have different attack scenarios and you now need to take care of both and some mitigations are only applicable to one function.
- saving ressources (servers, virtual machines, whatever they run on) Those are machine resources and cheap. Your manpower resources running mixed servers are higher as you have to be a lot more careful how you treat a mixed function dns server. Even pur bind shops these days run there servers with only one function.
And all modern DNS software is either authoritative or recursive and there is a good reason for that. Unless you believe people dealing with this for decades are wrong. So long -Ralf —-- Ralf Weber
On 11 Jun 2019, at 19:40, Jonas Frey <jf@probe-networks.de> wrote:
I do see 3 major benefits to combine/unify these: - "saving" IP addresses (depending of how many you run of course[1]) - less effort managing (not having multiple places for configuration thus unifiying [automated] setup) - saving ressources (servers, virtual machines, whatever they run on)
First off, apologies for a meaningful and relevant Subject: header. :-) These assumptions may well hold for you and your network. I doubt they apply anywhere else. I think you also need to consider the setup and recurrent costs of doing things in this way compared to the alternatives. It *might* be cheaper to setup DNS your way (though I doubt it). But it will surely cost you a lot more in the long run: management, support, debugging, risk/threat analysis, etc. More so if you one day need to use some feature for authoritative service which is bad for your recursive service (or vice versa). Keeping these things functionally and physically separate is both basic common sense and good administrative practice. It just doesn’t make any sort of sense to roll up all of your DNS operations into an easily avoided single point of failure. *By design.* You shouldn’t need a document to tell you that. You seem to be using criteria from the mid-/late-1980s - an era of acoustic couplers, wardrobe-sized 1-MIP minicomputers, TCP/IP stacks that had UDP checksumming disabled by default and 64Kb/s leased lines for a university campus. Things have moved on since then. In those early days, BIND was the only game in town for DNS. So pretty much everyone used the same DNS daemon for authoritative and recursive service. There was essentially no alternative. That practice died out as hardware and networks got cheaper and faster, other DNS software emerged, cache poisoning and reflector attacks started happening, etc, etc.
If you allow remote servers to query your recursive servers (even if you only allow RD=0 access to your authoritative zones), then it's very easy for miscreants to deny service to your users. My resolvers reject TCP connections from outside our network to avoid this issue, amongst other techniques. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Northwest Viking: Northeasterly 6, veering southeasterly 4 or 5 later. Rough, becoming moderate later. Rain. Good, occasionally poor.
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Tue, Jun 11, 2019 at 07:52:18PM +0200 Quoting Jonas Frey (jf@probe-networks.de):
It seems to me that all documentation regarding this topic is highly outdated (atleast what i have found, see ISC's docs for BIND).
Because 20 years ago, we realised that this is a problem and stopped intermingling recursive and authoritative service. Software like the djb suite, nsd and unbound was written to assist in this separation. Thus, noone has bothered to revisit the docs on the subject. Part of the response you have received, thus, is because the separation requirement is mostly regarded as completely uncontroversial, like "do not allow TELNET without IAC DO ENCRYPT" or "Do not let SNMP community Public have write access" and similar obviousities. I suggest we wait for the NCC folks to come back with the exact list of requirements used today and starting from those the community, since this is more controversial than I and others thought, should try to formulate a policy that is consistent with the desires and needs of the community and the Internet. /Måns, down memory lane. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I've read SEVEN MILLION books!!
I suggest we wait for the NCC folks to come back with the exact list of requirements used today and starting from those the community, since this is more controversial than I and others thought, should try to formulate a policy that is consistent with the desires and needs of the community and the Internet.
I'd argue that it is not controversial at all. We have good BCP and the RIPE NCC delegation checks it. By all means wait for the RIPE NCC to respond, but I see no reason to change the status quo. This seems like a complaint about nothing of importance IMHO. Ian Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
Ian,
I'd argue that it is not controversial at all. We have good BCP and the RIPE NCC delegation checks it. By all means wait for the RIPE NCC to respond, but I see no reason to change the status quo. This seems like a complaint about nothing of importance IMHO.
Ian
Well, even if you do not want to change the status quo then this complaint has one undoubtful point: This whole BCP (whatever that includes in detail) is nowhere documented. - Jonas
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Tue, Jun 11, 2019 at 11:10:01PM +0200 Quoting Jonas Frey (jf@probe-networks.de):
Ian,
I'd argue that it is not controversial at all. We have good BCP and the RIPE NCC delegation checks it. By all means wait for the RIPE NCC to respond, but I see no reason to change the status quo. This seems like a complaint about nothing of importance IMHO.
Ian
Well, even if you do not want to change the status quo then this complaint has one undoubtful point: This whole BCP (whatever that includes in detail) is nowhere documented.
It is now, since Anand replied to the list, in <68c1d8f7-7b0b-a5d0-d1ed-d75f215624d2@ripe.net> . I suggest that we perform the absolute minimum of policy footwork to endorse this procedure as is. Because I feel we have a strong if not absolute consensus for carrying on as usual from those who spoke up here. I'm a tad rusty on procedure here, so others will have to help with how we continue. Regards, -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Xerox your lunch and file it under "sex offenders"!
Måns Nilsson wrote on 12/06/2019 22:42:
I suggest that we perform the absolute minimum of policy footwork to endorse this procedure as is. Because I feel we have a strong if not absolute consensus for carrying on as usual from those who spoke up here.
we don't really need this because it's not fixing a problem. If an actual problem crops up in future, then creating a policy might be one potential approach for handling it, or maybe not. Otherwise, the RIPE NCC's record for handling dns delegation over the years shows that they're doing a good job and unless this changes, the best thing to do would be to let them continue doing their job as they see fit. Nick
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Wed, Jun 12, 2019 at 11:06:33PM +0300 Quoting Nick Hilliard (nick@foobar.org):
Måns Nilsson wrote on 12/06/2019 22:42:
I suggest that we perform the absolute minimum of policy footwork to endorse this procedure as is. Because I feel we have a strong if not absolute consensus for carrying on as usual from those who spoke up here.
we don't really need this because it's not fixing a problem. If an actual problem crops up in future, then creating a policy might be one potential approach for handling it, or maybe not. Otherwise, the RIPE NCC's record for handling dns delegation over the years shows that they're doing a good job and unless this changes, the best thing to do would be to let them continue doing their job as they see fit.
This, s what I mean with "absolute minimum of policy footwork". I think we're done. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 ... I see TOILET SEATS ...
On 12 Jun 2019, at 21:06, Nick Hilliard <nick@foobar.org> wrote:
we don't really need this because it's not fixing a problem.
Indeed. There’s no problem here that needs fixing.
... the RIPE NCC's record for handling dns delegation over the years shows that they're doing a good job and unless this changes, the best thing to do would be to let them continue doing their job as they see fit.
+1. The current mechanism is working just fine. It isn’t broken.
On Thu, Jun 13, 2019 at 09:40:20AM +0100, Jim Reid wrote:
On 12 Jun 2019, at 21:06, Nick Hilliard <nick@foobar.org> wrote:
we don't really need this because it's not fixing a problem.
Indeed. There???s no problem here that needs fixing.
... the RIPE NCC's record for handling dns delegation over the years shows that they're doing a good job and unless this changes, the best thing to do would be to let them continue doing their job as they see fit.
+1.
The current mechanism is working just fine. It isn???t broken.
+1 Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland
Well, even if you do not want to change the status quo then this complaint has one undoubtful point: This whole BCP (whatever that includes in detail) is nowhere documented. It is now, since Anand replied to the list, in <68c1d8f7-7b0b-a5d0-d1 ed-d75f215624d2@ripe.net> .
I suggest that we perform the absolute minimum of policy footwork to endorse this procedure as is. Because I feel we have a strong if not absolute consensus for carrying on as usual from those who spoke up here.
I'm a tad rusty on procedure here, so others will have to help with how we continue.
Regards,
Ok, thanks everyone for the input - i do see that the negative effects of combining auth. resolver with open recurses outweight the positive ones now. I wouldnt have started all this if there was documentation about requirements for reverse delegation nameservers somewhere. I do know that time ago there were no open resolver checks (or they didnt work properly), so my assumption was that this was silently introduced (since i didnt find any "changelog"). Now that Anand has provided insight on how RIPE does its checks, this should be easy to find for any upcoming questions. I do agree with Mans that there is no new policy etc needed and we can move on. - Jonas
On 6/11/19 11:10 PM, Jonas Frey wrote:
This whole BCP (whatever that includes in detail) is nowhere documented.
hi, to be honest there is a meaningful BCP about the topic: RFC 5358, BCP 140, Preventing Use of Recursive Nameservers in Reflector Attacks. under "Recommended configuration" paragraph: In general, it is a good idea to keep recursive and authoritative services separate as much as practical. -- antonio
Because 20 years ago, we realised that this is a problem and stopped intermingling recursive and authoritative service. Software like the djb suite, nsd and unbound was written to assist in this separation.
Thus, noone has bothered to revisit the docs on the subject.
Part of the response you have received, thus, is because the separation requirement is mostly regarded as completely uncontroversial, like "do not allow TELNET without IAC DO ENCRYPT" or "Do not let SNMP community Public have write access" and similar obviousities.
I suggest we wait for the NCC folks to come back with the exact list of requirements used today and starting from those the community, since this is more controversial than I and others thought, should try to formulate a policy that is consistent with the desires and needs of the community and the Internet.
/Måns, down memory lane.
Mans, i get your point but it appears that since those 20 years one might have forgotten to just ask that question again (with todays technology in mind). "Its not working that way." "Why?" "It never worked that way, dont try". While telnet was replaced by SSH (and others), SNMP is still there but has made progress (v3, crypto etc). I'd rather compare the auth nameserver+open resolver thing to SNMP than to telnet. I agree with you to wait for the NCC to specify the requirements and see what the community thinks about it. In any way this should be documented somewhere, so that further confusion is avoided. - Jonas
participants (11)
-
Antonio Prado -
Gert Doering -
Ian Dickinson -
Jim Reid -
Jonas Frey -
Måns Nilsson -
Nick Hilliard -
Piotr Strzyzewski -
Ralf Weber -
Rubens Kuhl -
Tony Finch