Re: [dns-wg] NCC reverse delegation criteria
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Wed, Jun 12, 2019 at 11:06:33PM +0300 Quoting Nick Hilliard (n...@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 ... signature.asc Description: PGP signature
Re: [dns-wg] NCC reverse delegation criteria
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
Re: [dns-wg] NCC reverse delegation criteria
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 signature.asc Description: OpenPGP digital signature
[dns-wg] combining authoritative and recursive DNS service
> On 11 Jun 2019, at 19:40, Jonas Frey 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. signature.asc Description: Message signed with OpenPGP
[dns-wg] RIPE NCC's reverse DNS delegation process and stats
Dear colleagues, As requested, here is some information about the reverse DNS delegation process applied by the RIPE NCC. We perform pre-delegation checks with a local instance of Zonemaster, which is DNS delegation testing software that was developed by AFNIC and IIS. The software performs the following tests: https://github.com/zonemaster/zonemaster/tree/master/docs/specifications/tests Test results are classified into one of five levels of severity: INFO, NOTICE, WARNING, ERROR, or CRITICAL. This classification is governed by a policy, and ours follows the default Zonemaster profile here: https://github.com/zonemaster/zonemaster-engine/blob/master/share/profile.json According to this policy, a name server offering recursion is classified as ERROR. When we perform pre-delegation tests, the request is rejected if any of the test results are classified at the ERROR or CRITICAL levels. We have the results of pre-delegation tests going back to 30 June 2017. Between then and now, we rejected 5,125 delegation requests for 1,833 zones because at least one of the name servers of a zone was an open recursor. It's worth noting that these requests may have been rejected for other reasons in addition to this one, and there were multiple requests for some zones, which accounts for the imbalance between the two numbers. Finally, before Zonemaster we used software called DNScheck, which was developed by IIS. This also checked for open recursive name servers and classified this condition as an error. Regards, Anand Buddhdev RIPE NCC
