[dns-wg] NCC reverse delegation criteria
Recently, a discussion regarding the checks performed by the NCC before reverse delegation is made came up on the members-discuss list. It was concluded that this should be discussed here rather than there. The members archive might not be available to all, so I'll try to summarize. Please add your take on summary if you find mine lacking. The questioned practice was that the NCC rejects the delegation request if the target server is found to be an open recursor. Some participants argued that this is not a technical problem, and some said yes it is. Some held that the NCC has no authority blocking a request, but it was argued that every delegation is subject to RFC 1591 responsibilites. For starters, are the delegation requirements described somewhere? Best regards, -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR+46 705 989668 In 1962, you could buy a pair of SHARKSKIN SLACKS, with a "Continental Belt," for $10.99!! signature.asc Description: PGP signature
[dns-wg] 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: j...@probe-networks.de Auf Strützberg 26 D-3 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. -- signature.asc Description: This is a digitally signed message part
Re: [dns-wg] NCC reverse delegation criteria
First question is (and RIPE should have the data) how many delegations do they reject because the server is an open recursor ? In today's world, I suspect it would be quite low Tim On Mon, Jun 10, 2019 at 3:23 AM Måns Nilsson wrote: > Recently, a discussion regarding the checks performed by the NCC before > reverse delegation is made came up on the members-discuss list. It was > concluded that this should be discussed here rather than there. > > The members archive might not be available to all, so I'll try to > summarize. Please add your take on summary if you find mine lacking. > > The questioned practice was that the NCC rejects the delegation request > if the target server is found to be an open recursor. > > Some participants argued that this is not a technical problem, and some > said yes it is. > > Some held that the NCC has no authority blocking a request, but it was > argued that every delegation is subject to RFC 1591 responsibilites. > > For starters, are the delegation requirements described somewhere? > > Best regards, > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE SA0XLR+46 705 989668 > In 1962, you could buy a pair of SHARKSKIN SLACKS, with a "Continental > Belt," for $10.99!! >
Re: [dns-wg] NCC reverse delegation criteria
Måns, Speaking mostly as myself, except where indicated below On 10/06/2019 09.22, Måns Nilsson wrote: Recently, a discussion regarding the checks performed by the NCC before reverse delegation is made came up on the members-discuss list. It was concluded that this should be discussed here rather than there. The members archive might not be available to all, so I'll try to summarize. Please add your take on summary if you find mine lacking. The questioned practice was that the NCC rejects the delegation request if the target server is found to be an open recursor. Some participants argued that this is not a technical problem, and some said yes it is. In almost all cases, running an open resolver indicates a bad configuration. I'm actually having a hard time imagining a case where someone actually wants to run authoritative reverse DNS on the same server as a public DNS resolver. (I can imagine wanting to run an authoritative reverse DNS server on the same server as a _private_ DNS resolver, for split horizon reasons. I think that is a bad idea, but at least it makes some sense for some setups.) Some held that the NCC has no authority blocking a request, but it was argued that every delegation is subject to RFC 1591 responsibilites. The RIPE NCC runs the parent zone for reverse DNS in its service region, so as I understand it has complete authority to decide what is a valid delegation or not. I am not aware of any laws requiring that Dutch membership-based organizations add specific delegations to particular zones, and I do not know what else would limit the authority of the RIPE NCC to manage the parent zone however it wants. The good news is that as a member of the RIPE community, you and all of the rest of us have a chance to shape the policy here. If we think that we need a RIPE policy or other RIPE community recommendation to the RIPE NCC regarding delegation to open resolvers, we have a policy process we can follow to make one. Personally I think that it is unlikely that the RIPE DNS working group would recommend that the RIPE NCC delegate to open resolvers, but I am often wrong. For starters, are the delegation requirements described somewhere? This particular test case is described here: https://github.com/zonemaster/zonemaster/blob/master/docs/specifications/tests/Nameserver-TP/nameserver01.md I don't know how much modification the RIPE NCC has made from the standard Zonemaster configuration, but at least in the default setup this particular check is made. Cheers, -- Shane
Re: [dns-wg] NCC reverse delegation criteria
Shane Kerr wrote: > > The good news is that as a member of the RIPE community, you and all of the > rest of us have a chance to shape the policy here. If we think that we need a > RIPE policy or other RIPE community recommendation to the RIPE NCC regarding > delegation to open resolvers, we have a policy process we can follow to make > one. I couldn't find out how to use the policy process to get RFC 7344 CDS automation in place :-( Tony. -- f.anthony.n.finchhttp://dotat.at/ Fair Isle, Faeroes: North or northwest 4 or 5, veering northeast 5 to 7. Moderate or rough, occasionally slight at first in south. Rain or showers. Good, occasionally moderate.
Re: [dns-wg] NCC reverse delegation criteria
> I couldn't find out how to use the policy process to get RFC 7344 CDS > automation in place :-( sounds more like education and engineering than policy. if not the dns wg, where may be lost in the s:n, maybe an ncc services request. randy
Re: [dns-wg] NCC reverse delegation criteria
Dear all, Is a complete overview of the current policy / testing process available? To further this discussion - I think it would be good to have a full understanding of what the current state of affairs is in this context. Kind regards, Job
Re: [dns-wg] NCC reverse delegation criteria
> On 10 Jun 2019, at 17:04, Randy Bush wrote: > >> I couldn't find out how to use the policy process to get RFC 7344 CDS >> automation in place :-( Tony, all you need to do is write a proposal and post it to dns-wg@ripe.net. I’m sure the WG co-chairs will be happy to advise. > sounds more like education and engineering than policy. if not the dns > wg, where may be lost in the s:n, maybe an ncc services request. I’m not sure Randy. I agree a policy proposal and invoking the PDP might well be overkill. And take forever to complete. However I expect the NCC’s DNS team would be uncomfortable acting on a request from the NCC Services WG to do DNS stuff which hadn’t first been scrutinised or approved by the DNS WG. Another option might be for the NCC’s DNS team to come to the DNS WG with a plan to support RFC7344 and get WG endorsement for that plan*. The same approach could be taken to discontinue delegations to authoritative reverse zone servers that have recursion enabled. This is what we did several years ago when the NCC began to make an orderly exit from providing DNS slave service for TLDs. That was discontinued for the TLDs who could afford to buy that service elsewhere. Anand or Romeo would give an update to the WG on how that was progressing. The DNS WG provided feedback and approval. The NCC Services WG and the PDP weren’t involved. Though in retrospect I think the WG could have documented this better than we did. * A variation on this would be for concerned WG members discuss to this with the NCC’s DNS team, work out the practicalities and develop a plan which then comes to the DNS WG for endorsement.
Re: [dns-wg] NCC reverse delegation criteria
Good morning Måns, We will come back to you shortly with answers to your and others' questions in this thread. Regards, Anand Buddhdev RIPE NCC On 10/06/2019 09:22, Måns Nilsson wrote: > Recently, a discussion regarding the checks performed by the NCC before > reverse delegation is made came up on the members-discuss list. It was > concluded that this should be discussed here rather than there. > > The members archive might not be available to all, so I'll try to > summarize. Please add your take on summary if you find mine lacking. > > The questioned practice was that the NCC rejects the delegation request > if the target server is found to be an open recursor. > > Some participants argued that this is not a technical problem, and some > said yes it is. > > Some held that the NCC has no authority blocking a request, but it was > argued that every delegation is subject to RFC 1591 responsibilites. > > For starters, are the delegation requirements described somewhere? > > Best regards, >
Re: [dns-wg] NCC reverse delegation criteria
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Tue, Jun 11, 2019 at 10:52:00AM +0200 Quoting Anand Buddhdev (ana...@ripe.net): > Good morning Måns, > > We will come back to you shortly with answers to your and others' > questions in this thread. Excellent! -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR+46 705 989668 I hope I bought the right relish ... z ... signature.asc Description: PGP signature
Re: [dns-wg] NCC reverse delegation criteria
> On 11 Jun 2019, at 17:28, Jonas Frey wrote: > > Run a open resolver and secure it propely These two things are mutually exclusive. Sorry. signature.asc Description: Message signed with OpenPGP
Re: [dns-wg] NCC reverse delegation criteria
> > 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 signature.asc Description: This is a digitally signed message part
Re: [dns-wg] NCC reverse delegation criteria
> On 11 Jun 2019, at 17:28, Jonas Frey 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. signature.asc Description: Message signed with OpenPGP
Re: [dns-wg] NCC reverse delegation criteria
> On 11 Jun 2019, at 17:58, Jonas Frey 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. signature.asc Description: Message signed with OpenPGP
Re: [dns-wg] NCC reverse delegation criteria
> Em 11 de jun de 2019, à(s) 13:58:000, Jonas Frey > 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
Re: [dns-wg] NCC reverse delegation criteria
> 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. signature.asc Description: This is a digitally signed message part
Re: [dns-wg] NCC reverse delegation criteria
> 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 signature.asc Description: This is a digitally signed message part
Re: [dns-wg] NCC reverse delegation criteria
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 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [dns-wg] NCC reverse delegation criteria
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... signature.asc Description: This is a digitally signed message part
Re: [dns-wg] NCC reverse delegation criteria
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 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [dns-wg] NCC reverse delegation criteria
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Tue, Jun 11, 2019 at 07:52:18PM +0200 Quoting Jonas Frey (j...@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!! signature.asc Description: PGP signature
Re: [dns-wg] NCC reverse delegation criteria
> 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.
Re: [dns-wg] NCC reverse delegation criteria
> 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 signature.asc Description: This is a digitally signed message part
Re: [dns-wg] NCC reverse delegation criteria
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 signature.asc Description: This is a digitally signed message part
Re: [dns-wg] NCC reverse delegation criteria
Moin! On 11 Jun 2019, at 20: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]) Should not be a problem with IPv6, and running the same function 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
Re: [dns-wg] NCC reverse delegation criteria
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
Re: [dns-wg] NCC reverse delegation criteria
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Tue, Jun 11, 2019 at 11:10:01PM +0200 Quoting Jonas Frey (j...@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-d75f21562...@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"! signature.asc Description: PGP signature
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
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
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
> On 12 Jun 2019, at 21:06, Nick Hilliard 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.
Re: [dns-wg] NCC reverse delegation criteria
On Thu, Jun 13, 2019 at 09:40:20AM +0100, Jim Reid wrote: > > On 12 Jun 2019, at 21:06, Nick Hilliard 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
Re: [dns-wg] NCC reverse delegation criteria
> > 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-d75f21562...@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 signature.asc Description: This is a digitally signed message part
