Re: [dns-wg] Retiring ns.ripe.net
> On 3 May 2024, at 10:29, Erik Bais wrote: > > I think it was about bloody time that the NCC starts to look as services like > this and sunsets them .. Don’t muck about Erik! Tell us what you *really* think. +1 to the orderly closure of ns.ripe.net. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] RIPE NCC DNS operations update
> On 11 May 2022, at 13:20, Anand Buddhdev wrote: > > Our main reason is that we do not have separate storage for the KSKs and > ZSKs. They were all stored together on the signer. Additionally, our ECDSA > KSKs and ZSKs were of the same size. Therefore, there is no additional > protection offered by separating them, and so it is reasonable to use a CSK. Makes sense. Like everything else you do. Thanks Anand. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] RIPE NCC DNS operations update
> On 11 May 2022, at 12:53, Anand Buddhdev wrote: > > On Tuesday 3 May, we performed a DNSSEC Key Signing Key (KSK) roll-over for > all the zones that we maintain and sign. During this roll-over, we dropped > the Zone Signing Keys (ZSKs), and began signing the zones with just their new > KSKs. Technically, these keys are the same as any other KSKs, but since they > sign the entire zone, and there's no ZSK, such KSKs are informally known as > Combined Signing Keys (CSKs). Many thanks for the update Anand. Could you give a bit more detail on why you decided to dump the ZSKs? Was it just a matter of having fewer keys to manage and fewer moving parts that could break? -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] DNS4EU?
> On 12 Jan 2022, at 17:35, Ana Sen wrote: > > Would anybody know which stakeholders have the capacity to apply for this > call? I can think of several. But I won’t identify them by name. The obvious candidates are any of the larger (anycast) DNS providers, TLD registries, major registrars, etc. In other words, pretty much anyone that’s already running chunky global DNS infrastructure. They’ll have the economies of scale and deep pockets to take on this project. It’s possible but unlikely someone might take a punt on a start-up venture purely to go after this opportunity. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] DNS4EU?
> On 12 Jan 2022, at 17:09, Stephane Bortzmeyer wrote: > > Does it mean that the machines will not be on AWS or other US hoster? Stephane, that’s really a question for the EU officials who are in charge of the CFP. FWIW I think using AWS or whatever outside the EU for part of the resolver service will probably be OK, subject to some of the other requirements in the CFP. ie The successful EU-based bidder ensures any non-EU elements comply with stuff such as the Data Retention, GDPR and NIS directives, access to EU LEA, contracts are under jurisdiction in an EU member state, etc, etc. Though this is just guesswork on my part. Disclaimer: I am not an EU official and don’t play one on TV. Questions about CFP detail should probably go to the email address given in the CFP doc: "Non-IT related questions should be sent to: hadea-cef-digital-ca...@ec.europa.eu”. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] DNS4EU?
> On 15 Dec 2021, at 11:30, Chris Buckridge wrote: > > Apologies for the delay here - was hoping to have some more substantial > information, but in the absence of that, our colleagues at the European > Commission have been able to share the content of the four slides that they > delivered at last month’s HLIG meeting. Many thanks for this Chris. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
> On 2 Dec 2021, at 13:46, Petr Špaček wrote: > > Why not make the TTL _dynamic_, based on time of last change in the RIPE > database? Because it’s a very bad idea? 1) The RIPE database and its reverse zone DNS data are orthogonal things (modulo the nameserver objects for bits of the reverse tree). These two different things shouldn’t get linked in this way. There needs to be a clean and clear separation between the two. If they get entangled, the outcome will be painful for everyone. 2) It imposes (IMO unwanted) operational requirements on the database -- uptime, availability, extra tooling, new processes, opportunites for adding cruft, etc -- unrelated to the database's prime function. 3) Changes to the RIPE database for some reverse zone do not necessarily mean changes to that zone’s DS TTLs or the LIR’s DNSSEC policies. Anyways, to get back on topic I think it would be better to discuss TTL values for NS and DS records based on solid engineering. At present, we seem to be plucking numbers out of the air based on gut feel. Simply saying “I think the TTL should be X” is not helpful when without some justification for choosing X - or why X is better than Y - or an explanation of the operational impacts. Anand and his colleagues have identified an issue. But I’m not convinced his proposal is the right one. LIRs may well have good reasons for choosing TTLs for NS and DNSKEY RRs that are higher or lower than the defaults that are being proposed. I think this needs careful WG consideration: unintended consequences and all that. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] mailing list management
> On 12 Nov 2021, at 11:40, Nick Hilliard wrote: > > from a practical point of view, it would help if emails to dns-wg@ripe.net > included a footer on how to unsubscribe. That info is already in the mail headers of every message Nick. Putting it in a footer just means there would be another place for the info to be ignored. > This is arguably also required under gdpr. I’m not sure it is. Even so, I think the “welcome to the list” email -- which I’m sure everyone keeps forever -- includes info on how to subscribe/unsuscribe, change preferences, etc. IMO that should take care of GDPR concerns.
Re: [dns-wg] DNS wg co-chair selection: candidates
> On 12 Nov 2021, at 11:21, Tim Wicinski wrote: > > One place I worked we would make decisions on who would end up with some > maintenance nobody wanted with a spirited match of rock-paper-scissors. Ooh! I forgot we could also have a meta-meta-discussion about what sort of random selection mechanism gets used. Sorry about that. :-)
Re: [dns-wg] DNS wg co-chair selection: candidates
> On 12 Nov 2021, at 10:36, Tim Wicinski wrote: > > I love both candidates equally. I must protest making me choose. > > Moritz if the group wants to dig into more research discussions, but I like > Brett's TLD and operations view of the world. > > I can't choose, sorry. Both will serve well. Do what I’m doing Tim. Support both candidates. Moritz and Brett would be great co-chairs. So I support both of them equally. If everybody did this, I suppose we could then have a meta-discussion about what sort of coin gets tossed to decide between them. :-)
[dns-wg] mailing list management
> On 12 Nov 2021, at 10:38, Andrea Kurucsó wrote: > > Hi All, please take me out of this mailing list. I haven't been working in > this for years, and I keep getting the emails. How is the mailing list software supposed to know what you are or aren’t working on? Visit https://www.ripe.net/mailman/listinfo/dns-wg to get yourself added or removed from the WG mailing list. > It is very annoying. I hope you understand. So are your repeated emails about this. There is *nothing* anyone here can do about your list subscription/unsubscription. You need to sort it out yourself. I hope you understand.
Re: [dns-wg] DNS wg co-chair selection: candidates
> On 11 Nov 2021, at 17:52, Andrew Campling > wrote: > > From a strong field, I would like to cast a vote for Brett Carr as co-chair. Andrew, it’s a SELECTION process. We don’t “vote”. RIPE takes important decisions by consensus. Since RIPE is open to all, an election implies there’s some way of determining who gets to “vote” and how often they do that. Which is impractical. Presumably the WG co-chairs will consider your post as an expression of support for Brett.
Re: [dns-wg] Volunteer list for RIPE DNS working group chair
> On 15 Oct 2020, at 23:40, Leo Vegoda wrote: > > Succession planning is good but placing the burden on the chairs themselves > seems a lot to ask. I strongly disagree Leo. For one thing, any burden from things like this is why WG co-chairs get the big bucks. :-) When you’re in a leadership position (for some definition of that term), it’s reasonable to be expected to show some... er... leadership. Succession planning comes with the territory. As is making an orderly handover when your term ends. Succession planning is not a lot to ask in terms of time or effort. Or shouldn’t be. In my experience it’s far less of a resource drain than planning or running a WG session. How hard can it be to identify a couple of possible candidates, explain what the job entails (preferably over a tasty beverage) and ask them if they’d be interested or willing to stand as a co-chair? Finally, if a WG's co-chairs can’t or won’t do the succession planning who will? [Hopefully not yet another NomCom.] And would their efforts have any credibility? Imagine if it was someone who had never run a WG or understood the WG dynamics who tried to do the succession planning.
Re: [dns-wg] Volunteer list for RIPE DNS working group chair
> On 16 Oct 2020, at 00:00, Dave Knight wrote: > >> Maybe have the outgoing and existing chairs explicitly go out and >> encourage someone who hasn't served before to volunteer? > > I struggle to reconcile our efforts toward impartiality with the notion of > having the chairs encouraging a preferred candidate. It depends on what’s meant by encouragement. I'm fairly sure Paul means approaching someone (or more than one) and saying “Have you ever thought of becoming a WG co-chair?”. Which would be fine. He almost certainly wasn’t meaning the co-chairs dictate to the WG who they must select. Which obviously would not be fine. Encouraging someone to stand doesn’t necessarily mean there’s a preferred candidate (after all the WG makes the selection) or impartiality has been compromised.
Re: [dns-wg] Volunteer list for RIPE DNS working group chair
> On 15 Oct 2020, at 22:47, Dave Knight wrote: > > The new process has been exercised several times since then with these results > > Nov 2015, RIPE 71 Peter Koch was succeeded by Dave Knight for a 3 year term > Oct 2016, RIPE 73 Jim Reid was succeeded by Shane Kerr for a 3 year term > Oct 2017, RIPE 75 Jaap Akkerhuis was succeeded by Joao Damas for a 3 year > term When the selection process was introduced, Jaap, Peter and myself said we would all be standing down to make way for new people. That procedure was the catalyst for regime change that probably should have happened earlier than it did. This was carried out over 2 years to allow for a phased handover. The current arrangement with term limits is intended to help with that too. That way, there’s an orderly transition and the newcomer gets time to settle in and learn from their more experienced co-chairs. > If the working group feels strongly about encouraging new faces perhaps we > should amend the process such that new co-chairs may servce onlky a single > term? I’m not sure. Serving a single three year term seems too short IMO. A bit more stability would be desirable. Besides, is it the selection procedure that's discouraging new faces or could it be the incumbents are doing such a good job, nobody feels the need to disrupt that? Let’s first identify the problem before deciding what the solution is. Maybe the co-chairs need to do a little succession planning: finding suitable candidates to mentor and then encouraging them to volunteer when the term limits kick in.
[dns-wg] term limits for fun and profit
> On 15 Oct 2020, at 20:30, Janos Zsako wrote: > > I think putting a term limit may prevent talented people from serving the > community in spite of their willingness to continue their useful work. I agree and disagree with this Janos. Term limits might well mean somebody good gets forced to quit prematurely. On the other hand, they ensure there are opportunities to bring in somebody new => fresh approach, new ideas, etc, etc. A regular but prudent approach to leadership changes is generally a very healthy thing to do: just enough to stop things from getting stale but not stopping other talented people from getting a chance to run things.
[dns-wg] vote early, vote often - again
> On 15 Oct 2020, at 18:47, Randy Bush wrote: > > > o no +1s. leave it until the actual election RIPE does not vote!!! Important decisions get taken by consensus, not elections. It’s beyond stupid to talk about an election or use that mechanism when there are no eligibility criteria on who gets to vote or constraints on how often they can do that. RIPE NCC uses votes. Which is fine. The NCC has a legal identity and a clearly defined membership which is underpinned by contracts and fees. The RIPE community has none of these things. > o we might think about term limits We already have. They’ve been built into the co-chair *selection* process from the start: https://www.ripe.net/participate/ripe/wg/active-wg/dns/dns-wg-chair-selection-process
Re: [dns-wg] Volunteer list for RIPE DNS working group chair
> On 14 Oct 2020, at 14:29, Dave Knight wrote: > > The nomination period for the RIPE DNS working group chair selection has > completed with a single volunteer, Joao Damas I support Joao’s reappointment.
[dns-wg] DANE goes mainstream?
Microsoft has announced Office 365 Exchange Online is going to support DNSSEC and DANE: https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494
[dns-wg] Contingency plans for the next Root KSK Ceremony
FYI. If you have comments or questions, please contact Kim or one of the TCRs. > Begin forwarded message: > > From: Kim Davies > Subject: [RZERC] Contingency plans for the next Root KSK Ceremony > Date: 26 March 2020 at 01:52:29 GMT > To: "rz...@icann.org" > > Colleagues, > > (Feel free to circulate within your respective groups as you see fit.) > > The IANA team, and the broader ICANN organization, have been giving > significant thought to the Coronavirus pandemic and its impact on root zone > KSK operations. Managing the KSK is centred on conducting "key signing > ceremonies", where trusted community representatives (TCRs) attend from > around the world to witness utilization of the root zone KSK private key. > This approach seeks to engender trust in the broader community that the key > has not been compromised, in addition to more typical controls such as > third-party auditing. > > In light of world events we have developed contingency plans around how to > hold key ceremonies in the short term. To that end, we identified a graduated > set of options, in summary: > Hold the next ceremony as planned on April 23, with a quorum of participants > globally. > Hold the next ceremony on a different date using only US-based TCRs. > Hold the next ceremony using our disaster recovery procedure, which provides > for a staff-only ceremony (i.e. no TCRs would be physically present). > In general, our goal has been to navigate from Option 1, and if that is not > possible, Option 2, and so on. However, at this time, our focus is on > developing a plan around Option 3. > > The ceremony is currently scheduled unusually early in the quarter (it is > typically held in May), and needs to be held to generate signatures that will > be needed in production for July. Our contingency plan is comprised of: > > Holding the ceremony with a bare minimum of staff (approximately 6); > Using 3 TCRs’ credentials, either by having their access key transferred to > us in a secure manner in advance of the ceremony, or by drilling the safety > deposit box that holds their secure elements. > Holding the ceremony under typical audit coverage, allowing for remote > witnessing of events by all, plus providing additional opportunities for TCRs > to stay involved in the process remotely. > Signing key materials to cover one or more subsequent quarters, to provide > relief from the need to necessarily hold ceremonies later in 2020 if > circumstances disallow it. (The additional signatures would be withheld > securely until they are needed.) > Our key management facilities were designed with the disaster recovery > capability of performing staff-only ceremonies in mind, but this is a > significant shift from normal operations and we want to promote broader > community awareness of this work. Those directly involved in key ceremonies - > the trusted community representatives, our vendors and auditors - have been > consulted and are broadly supportive of this effort. > > Should there be any specific feedback you would like to share with our team, > please let me know or respond to this thread. We will take it into > consideration as we finalize our plans. > Thank you for your support.
Re: [dns-wg] Hidden master maintenance
> On 3 Mar 2020, at 11:38, Anand Buddhdev wrote: > > The RIPE NCC runs a pair of hidden masters for transferring in zones > from various sources, and distributiong these zones to the K-root and > reverse DNS anycast clusters that we operate. > > On Thursday 5 March 2020, between 12:00 and 17:00 UTC, we will be doing > maintenance on one of these servers. In this duration, the server will > be offline for some time. Its IP addresses are: > > 93.175.159.250 > 2001:67c:2d7c:66::53 Well, I suppose it’s no longer a *hidden* master. :-)
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.
[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
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
> 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: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
> 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.
[dns-wg] RFC 7344 support in the RIPE database
> On 17 Oct 2018, at 15:51, Tony Finch wrote: > > I would like to help get RFC 7344 support into the RIPE database, so what > do we need to do next to make it happen? You probably should start a conversation in this WG about what needs to be done -- problem statement, possible solutions, etc. Once there's consensus on that the WG would punt the request for a new/changed database object to the Database WG. That's likely to be the formal way to proceed. There a lot of people at RIPE77 who you could talk to over beer or coffee and help make things happen.
[dns-wg] the day of reckoning is near
So, who’s stocked up on canned food and ammunition in case it all goes horribly wrong at 16:00 UTC tomorrow? :-)
Re: [dns-wg] SLD .gov.* within european countries
> On 10 Jun 2018, at 10:39, Antonio Prado via dns-wg wrote: > > does the SLD .gov.* within european countries' ccTLDs identify only > central government bodies and not local government or other public > administrations as well? No. Well, not under gov.uk. The domain has local authorities as well as central government. It also includes a few state-run institutions -- registrar of companies, national archives, vehicle/driver licensing, land registry, etc -- which technically are not part of government. Other parts of the UK government such as the NHS and police have their own SLDs. signature.asc Description: Message signed with OpenPGP
Re: [dns-wg] Deletion of ns-v6.ripe.net
> On 24 Apr 2018, at 16:33, Gert Doering wrote: > > Hi, > > On Tue, Apr 24, 2018 at 04:25:59PM +0100, Jim Reid wrote: >> Thanks Job. Though I wasn???t thinking (or caring) about github crapware. I >> was thinking about stuff that might have been written for internal use -- >> say at an ISP -- and would only show up whenever these scripts or whatever >> made queries for ns-v6.ripe.net. > > I would say that such software needs to be broken, often, and hard. I agree Gert. Though before we do that, it would be good to know what’ll break and what the impact of that will be*. Probably not much in this case. However better safe than sorry. * Consider the risk mitigation effort that had to be done when it emerged there was active cruft that couldn’t handle the root KSK rollover. > Gert Doering >-- writer of scripts that do stupid things Hey, that’s *my* job! I was here first. :-) signature.asc Description: Message signed with OpenPGP
Re: [dns-wg] Deletion of ns-v6.ripe.net
On 24 Apr 2018, at 16:07, Anand Buddhdev wrote: > > Even if we *could* look at the queries, and they showed queries for > "ns-v6.ripe.net", it doesn't mean that the name is in use. Well, I would say that if the name’s in the query traffic, that means it’s “in use”. For some definition of that term. YMMV. >> I’m wondering if the name might still be hard-wired into scripts or >> provisioning/testing tools. > > It may be hard-wired in some scripts, and if so, they may produce an > error. However, it is not used as the target of any NS records that we > are aware of, so I don't expect any major outages. OK. Thanks for that Anand.
Re: [dns-wg] Deletion of ns-v6.ripe.net
> On 24 Apr 2018, at 15:51, Job Snijders wrote: > > At least this is a good sign: > https://github.com/search?q=ns-v6.ripe.net&type=Code Thanks Job. Though I wasn’t thinking (or caring) about github crapware. I was thinking about stuff that might have been written for internal use -- say at an ISP -- and would only show up whenever these scripts or whatever made queries for ns-v6.ripe.net. As I’m sure we all realise, there’s a long tail of legacy cruft out there. So even when some name gets removed from the DNS (or isn't found in github), that doesn’t necessarily mean that the name is no longer used. For instance, there’s still traffic going to IP addresses for root servers that were renumbered years ago. Admittedly that’s not quite the same thing because the names of the root servers in question haven’t gone away, but it illustrates the point I was trying to make.
Re: [dns-wg] Deletion of ns-v6.ripe.net
> On 24 Apr 2018, at 15:33, Anand Buddhdev wrote: > > Now that the name ns-v6.ripe.net is no longer in use by anyone, we are > going to delete it from the ripe.net zone. Anand, could you clarify what you mean by “no longer in use”? Has it gone from all the reverse zones that referenced it? Are no more queries for ns-v6.ripe.net hitting the ripe.net name servers? I’m wondering if the name might still be hard-wired into scripts or provisioning/testing tools. signature.asc Description: Message signed with OpenPGP
[dns-wg] reporting in The Register
> On 28 Nov 2017, at 12:34, Stephane Bortzmeyer wrote: > > Note that there was an article in the Internet tabloid: > > http://www.theregister.co.uk/2017/11/28/powerdns_dnssec_bugs/ > > The "explanations" mix up DNS with BGP! "for example, if a network is > tricked into advertising itself as the whole of the Internet, it can > be hosed, or if the wrong network promises it's the best way to reach > YouTube, then YouTube is blackholed." All this with PowerDNS :-) Well if it’s in The Register it has to be true, right? :-)
Re: [dns-wg] PowerDNS vulnerabilities
> On 28 Nov 2017, at 11:51, Job Snijders wrote: > > I hope most people track security bulletins through other distribution > channels than dns-wg@ripe.net. I would hope so too Job. However using these sorts of lists to get an even wider distribution wouldn’t hurt. YMMV. There are probably quite a few people like me who aren’t on vendor-specific lists but would like to be informed about recent vulnerabilities/upgrades in commonly used DNS software.
[dns-wg] PowerDNS vulnerabilities
A bunch of vulnerabilities have been found in the Authoritative and Recursor servers. Here’s the list of security advisories: http://seclists.org/oss-sec/2017/q4/329 I’m surprised this hasn’t been mentioned on these lists yet.
Re: [dns-wg] f.root-servers.net problem - UA-IX exchange point
> On 21 Oct 2017, at 11:16, Сергій Співак wrote: > > There is a problem with a F root-server node connected to UA-IX traffic > exchange point (ix.net.ua, AS15645) since October, 14. This is out of scope for the WG list. However there may well be ops people from ISC who are here. You should probably send questions about DNS operational issues (for instance routing problems or service outages) to dns-operati...@oarc.net and/or the appropriate fora at the relevant IX. Contact data for ISC's NOC is also on-line. I've chosen not to provide that so you can find it for yourself. That way, you'll hopefully remember how to contact them the next time. If there is one.
Re: [dns-wg] KSK Rollover Postponed
> On 28 Sep 2017, at 12:53, David Conrad wrote: > > As far as I am aware, nothing is on fire. Given the lack of time criticality, > I would have thought it’d be more important to the technical communities to > have more concrete data to present. Given propagation delays in non-technical > circles, I believe ICANN comms felt doing a “normal” press announcement-style > approach sooner rather than later and then providing more details to folks > who were interested later was a better approach. YMMV. David, I would have expected some sort of announcements via the usual suspects mailing lists would have been part of that “normal” communication approach. YMMV. Instead, I learnt about the postponement because of a hearsay comment about a tweet. More details would of course be welcome. [And I’m sure forthcoming.] In due course. When the time is right. Blah, blah, blah. However if that info isn’t yet available for sharing, it shouldn’t have prevented announcements to the expected technical/operational mailing lists. I don’t understand why those lists weren’t told or how using those channels to get the word out could have been harmful. > We made an announcement within a few hours of making the decision to postpone > the KSK rollover and are proceeding to attempt to gather more information to > inform the community. Do you feel the fact that we did not send that > announcement to technical mailing lists despite not having that additional > information have an operational impact on resolver operators? Perhaps. There wouldn’t of course be an impact on resolving and validation. There may however be second-order effects. Responsible resolver operators may well have lined up a small army of staff to be on call and prepare for problems and/or TEOTWAWKI on the 11th. If so, they wouldn’t need to wait for that additional information so they could tell their helpdesks and ops people to stand down. It wouldn’t immediately matter to them why the rollover was being postponed, just that this was happening and that any resolver operator planning for that event could be postponed too. From that perspective I think it would have been better to communicate the news as widely as reasonably possible.
Re: [dns-wg] KSK Rollover Postponed
> On 28 Sep 2017, at 11:50, Michele Neylon - Blacknight > wrote: > > They seem to have made the announcement about 12 hours or so ago, so why not > give them a bit of time? ( Surely 12 hours is more than enough? Besides, if ICANN's comms people had time to put out a tweet (ugh!) and update the web site, I think they had time to post to the obvious mailing lists. YMMV. Providing timely, prompt and clear information is a crucial part of the root KSK rollover. In some ways it’s the most crucial. So it’s a shame that didn’t happen as expected for something so significant as last night's showstopper. And so close to the finishing line too. I appreciate how difficult and stressful last night’s decision was for everyone who was involved in making it. Plus of course the complexities of aligning all of those moving parts to be in the same place at the same time. Those considerations are however orthogonal how that decision got communicated. Or should be. Still, at least we now know the root KSK rolloover is delayed. For some definition of we.
Re: [dns-wg] KSK Rollover Postponed
> On 28 Sep 2017, at 11:22, Nico CARTRON wrote: > > it was tweeted this morning Sigh. You would hope ICANN’s communications team knew better. It’s disappointing that there’s been silence on all of the usual mailing lists where you’d expect this information would have been announced. Perhaps more detail will be given at this weekend’s OARC meeting?
[dns-wg] new KSK for the root
In case anyone missed this event, the new KSK for the root got added today. Though it’s not signing anything yet. Thanks to everone who made this happen.
Re: [dns-wg] Full text of DNS services contract (was Verisign to provide secondary DNS services for the RIPE NCC’s zones)
> On 26 Oct 2016, at 11:34, Shane Kerr wrote: > > I am curious what kinds of legal restrictions would prevent publishing > a contract, but that's not really important. They exist! Shane, commercial contracts are almost always confidential because they contain information which is commercially sensitive: SLAs, price, how/where the service is delivered, escalation/support arrangements, points of contact etc. I expect your contract of employment with BII and BII's contracts with its bandwidth and hosting providers will not be public for similar reasons. > Still... certainly there is precedent for publishing such details - for > example the Verisign Cooperative Agreement with the NTIA (NCR 92-18742). That's for something *very* different from DNS hosting. You're comparing apples and oranges. > If the community thinks that it is important, does it make sense to ask > that future contracts be open? This would be clear to anyone responding > to an RfP in advance and could avoid any restrictions. It makes no sense at all. In fact, a move like that would pretty much guarantee no reputable supplier will submit a bid. Why do that if the details of your offer are going to be exposed to your competitors if you win the RFP? The nature of this contract is implementation detail and therefore out of scope for the WG. Our involvement should be on the outcome of that contract. ie Is the outsourced hosting service working well or not and if not, what steps should be taken to correct that.
Re: [dns-wg] Verisign to provide secondary DNS services for the RIPE NCC’s zones
> On 18 Oct 2016, at 10:53, Antonio Prado wrote: > > besides, I cannot fully understand how this WG could ask the NCC board > to investigate "if we have reason to believe the rfp was unfair or > defective in some way" when, actually, you just said "the contractual > terms are out of scope for the WG". Antonio, these are two different things. The WG does not concern itself with what’s in this contract or how the RFP was conducted. That’s operational/implementation detail. If the service provided by the contract or RFP went wrong in some way or if someone complains, that falls within the WG’s remit. We don’t need to have knowledge of the content of that contract (or the RFP) to raise questions whenever a problem arises. ie The WG could formulate a list of questions for the NCC management/board and ask them to look into the matter and report back. I hope this clarifies matters.
Re: [dns-wg] Verisign to provide secondary DNS services for the RIPE NCC’s zones
On 18 Oct 2016, at 11:04, Carsten Schiefner wrote: > > Hi Jim, > > On 18.10.2016 11:36, Jim Reid wrote: >> The contractual terms are implementation detail and therefore out of >> scope for the WG. This also applies to the RFP and NCC’s selection >> procedure. > > what other forum you would see fit then for such kind of Q&A? Depends on the Q&A. If they’re about the NCC’s standard RFP process -- or it it has such a thing -- that’s for the NCC Services WG or maybe the GM. If the question is “was the NCC’s standard RFP mechanism followed for some DNS thing?”, that’s for this WG. If someone thinks any contract involving the NCC is unfair or unreasonable, they ask the NCC Board to look into it and report back to the GM and/or any WG the board decides is appropriate > But as a side note: how would you come to believe that the RfP and/or > contract is unfair or defective in some way, if neither one is disclosed? For starters, by how the service is performed by the chosen supplier. Or if that supplier was an unknown or had a poor reputation. Or if the losing bidders were complaining. Or (say) if Romeo tells us root server activities are being scaled back so he can pay the bills from the outsource partner. >> The WG must not and can’t (try to) micromanage the NCC’s DNS team. > > Not that I have attempted this by any means, I think. I’m glad to hear that Carsten. But I must say you gave me that impression by asking for details of the RFP and how well/poorly the bidders performed.
Re: [dns-wg] Verisign to provide secondary DNS services for the RIPE NCC’s zones
> On 18 Oct 2016, at 09:54, Romeo Zwart wrote: > > The proposal submitted by VeriSign Sàrl (“Verisign”) was the best fit. > We subsequently signed a contract with Verisign, which comes into effect > before the end of this year. The contract is for the period of one year, > with the intention to renew yearly. Prior to renewal, we will look at > the benefits of the service and actual market situation at that time to > decide on renewing the service. Thanks Romeo. This is great news. Bringing in a competent DNS hosting provider will add diversity and resiliance to the DNS infrastructure for ripe.net. It’s also good that these new arrangements are documented in a contract. I’m sure the WG agrees. Well, I hope it does... :-) I’m sure you’ll keep the WG informed of how this works out and what happens when the contract comes up for renewal. My thanks and appreciation to your team for the hard work of preparing and running the RFP and arranging the contract with the supplier.
Re: [dns-wg] Verisign to provide secondary DNS services for the RIPE NCC’s zones
> On 18 Oct 2016, at 10:09, Carsten Schiefner wrote: > > in the light of transparency, will resp. can the contract be disclosed? > > If not, is it a contract (draft) that has been put on the table by the > NCC? Or, vice versa, VeriSign's standard contract for such services? Or > rather - as a result of heavy negotiations in smoke filled rooms behind > closed doors ;-) - an amalgam of both? > > Also, how (far) the three final bidders met the RfP requirements would > be interesting. I don't mind if the names of the non-winning two would > be anonymized. Hi Carsten. The contractual terms are implementation detail and therefore out of scope for the WG. This also applies to the RFP and NCC’s selection procedure. The WG should only intervene here -- ie by asking the NCC board to investigate -- if we have reason to believe the RFP and/or contract was unfair or defective in some way. The WG must not and can’t (try to) micromanage the NCC’s DNS team.
[dns-wg] co-chair appointment: yet another reminder
There’s still time for people to volunteer. But not much. Anyone who wishes to stand is leaving it rather late. They should do so before the end of this week. At present, two candidates have emerged and there have only been a few statements of support for them. This makes it a little uncomfortable to make a consensus judgement since just a handful of WG members have expressed an opinion. I’d appreciate it if more members of the WG spoke up. Vote early, vote often. :-) Not that we do voting.
Re: [dns-wg] DNS WG co-chair nomination
> On 20 Sep 2016, at 17:46, tjw ietf wrote: > > Is it too late to hitch onto the Shane Kerr Bandwagon? Not at all Tim. Feel free to attach yourself to as many other bandwagons as you want to. Or even create some new ones. A nice thing about consensus based decision-making is people are able to express support for more than one candidate if they want to. Expressing support for Shane (say) doesn’t preclude a member of the WG from expressing support for other candidate(s).
[dns-wg] reminder about the co-chair appointment
Colleagues, there is still plenty of time to nominate candidates for the upcoming WG co-chair vacancy. Anyone can be nominated. They can even nominate themselves! Details of the role’s responsibilities are outlined in RIPE Document 542 tough this is a little out of date. Dave, Jaap and myself are of course happy to provide more details or answer questions from potential candidates - just get in touch. At present, only two names have emerged: Ralf Weber and Shane Kerr. More choices would be welcomed. So far, there have only been a few statements of support on the list for both Ralf and Shane. More voices of support would strengthen the consensus determination that has to be made. So vote early, vote often! Assuming we did voting at RIPE :-) The plan remains to have the WG discuss/endorse the choice of candidates on the list, make a consensus determination about that at RIPE73 and announce the result to the WG then.
Re: [dns-wg] WG co-chair's appointment procedure
> On 25 Aug 2016, at 14:34, Gert Doering wrote: > > In that case, enjoy your retirement :-) - "chair emeritius". Thanks Gert. Though I’m not quite ready to become a piece of furniture! :-)
[dns-wg] WG co-chair's appointment procedure
> On 25 Aug 2016, at 14:18, Gert Doering wrote: > > Is Jim trying to get away, or willing to serve another term? Jim is not trying to get away. He will be going away. Well, as a co-chair anyway. I’ll still be coming to RIPE meetings. I’ve co-chaired the WG for 15 years (yikes!). So it’s time for a change and for this Old Fart to make way for a fresh face. This year's iteration of the WG’s appointment procedure will be a convenient opportunity to do that. The news shouldn’t be a surprise because I announced it at the WG session in Bucharest last year. In fact, I'd planned to step down last year but Peter beat me to it.
Re: [dns-wg] Request for trusted party to provide secondary DNS services for the RIPE NCC’s zones
> On 25 Jul 2016, at 16:56, Romeo Zwart wrote: > > Hi Jim, > Thanks for the quick response. > > On 16/07/25 17:42 , Jim Reid wrote: >> The above URL doesn’t say very much. Could you please provide some more >> details? > > As expressed on the page mentioned above, the intention of the process > is that interested parties respond to the email address quoted to be > sent the detailed RfP document. Well, it would be nice if the web page actually said something like “interested parties can get the RFP documention by contacting the NCC at...”. :-) BTW, it makes sense not to publish the RFP bumf at this stage in case it encourages members of the WG to try to micro-manage what is an implementation/operational matter for the NCC. Though in the interests of openness and transparency it might be worthwhile publishing that document once the service provider(s) has been chosen. > I'd invite you to do so if you are interested to provide services. :) Hell no! I have enough trouble looking after my own zones without looking after the NCC’s too. :-) > We have tried to make these requirements as clear as possible, including > distinctions between mandatory and optional elements, and we have > documented those in the document that will be sent on request. Great! It’s a pity this isn’t mentioned in the announcement. > It would indeed be unrealistic to expect detailed responses based on the > limited information that is on the mentioned web page. That is clearly > not our expectation. I’m glad to hear that Romeo. Though until your recent clarification email, I fear you may well have given prospective bidders that impression. >> I also think it’s a bit optimistic to give bidders just three weeks to >> prepare their responses. More so during peak holiday season. Why the rush? > > We are expecting experienced and professional service providers to > respond, who have the required infrastructure and service machinery in > place and for whom three weeks will be a suitable period to respond. It’s always fun to make bidders sweat a bit and watch them squirm. :-) I’ve done it myself more than a few times when running RFPs. However you may well be pushing things to get good quality bids in such a short time-frame when just about everyone will be on holiday. I’d like to be proven wrong about that.
Re: [dns-wg] Request for trusted party to provide secondary DNS services for the RIPE NCC’s zones
> On 25 Jul 2016, at 15:59, Romeo Zwart wrote: > > The RIPE NCC requests proposals for service from a DNS service provider > in order to improve the resiliency of the RIPE NCC's zones, especially > ripe.net. > > The submission deadline is Sunday, 14 August 2016. > > For more details please see: > > > https://www.ripe.net/publications/news/announcements/request-for-trusted-party-to-provide-secondary-dns-services Thanks for this Romeo. The above URL doesn’t say very much. Could you please provide some more details? Are you expecting fully-baked and costed proposals by the mid-August deadline or just expressions of interest by then? What sort of service levels and commitments are the NCC looking for from potential suppliers? eg: a 24x7 NOC, SLAs, minimum/maximum query rates, anycast/unicast provision, server location(s), diversity of DNS software, statistics/logging, incident handling & escalation, mandatory/optional protocol requirements, support for DNS features like RRL, etc, etc. Which things on this sort of shopping list are essential/desirable/optional? It seems unrealistic/unreasonable to ask for responses when there’s so little information on what bidders are expected to be quoting on. Or what the "small number of additional zones” might be. [Do they include “.” or subdomains of .arpa? :-)] Or what is meant by a small number. I also think it’s a bit optimistic to give bidders just three weeks to prepare their responses. More so during peak holiday season. Why the rush?
[dns-wg] Hijacking DNS traffic for fun and profit... or something
> On 6 Jul 2016, at 20:36, Max Grobecker > wrote: > > "Do not do illegal stuff with your internet connection" and "We will hijack > your DNS requests (and maybe other services, too) just to make sure you don't > do illegal stuff" are two completely different things. Indeed. And sometimes ISPs hijack DNS traffic (or whatever) even when there’s nothing untoward going on: think stupid hotel and coffee shop networks for instance. My point remains though. Unless your contract and national law explicitly says the ISP never rewrites DNS responses, you shouldn’t assume it doesn’t happen. And even if those legal documents did say this, that doesn’t necessarily mean DNS rewriting doesn’t happen either. FWIW this is one reason why all my computers run their own validating resolvers. :-) > Of course, the contract with my ISP (in my case Deutsche Telekom) contains > paragraphs that make me fully liable to anything I do with my internet > connection, including > illegal file sharing, hacking attacks or whatever. But they won't finger in > my data traffic. Your contract might not explicitly say that Max. But I expect the small print will say somewhere that DT has the right to do things to your service if they consider your use of their interwebs to be naughty or harms others or is blocked by court order, blah, blah, blah. Those contractual provisions will go beyond holding you liable after the fact: eg blocking port 25 if they decide you're sending spam. As you’ve just pointed out. > The worst thing that can happen to you is that they block port 25/TCP on your > connection if you're sending SPAM. Hmmm. I wonder what would happen if you tried to visit a child abuse web site or something that was similarly illegal in Germany? [It doesn’t matter where that content happens to be hosted BTW.] And please note I am not suggesting you actually test this.
Re: [dns-wg] New on RIPE Labs: Is Your ISP Hijacking Your DNS Traffic?
> On 6 Jul 2016, at 13:21, Max Grobecker > wrote: > > You wrote: > >> You can’t blame your service provider for hijacking your DNS traffic or >> running DPI on their network these days. In fact most of them use DPI to >> some extent for various reasons. > > Yes, I would blame my ISP for that. That's something I wouldn't expect as a > customer Better check the small print of your contract with the ISP. Unless you’re living in a banana republic, your ISP will very likely be complying with laws that prevent access to illegal content. That generally means deploying things like DPI and policy-based DNS rewriting. Whether or not ISPs deserve to be blamed for that is another matter.
Re: [dns-wg] Tweaks to RIPE 663: Secondary DNS Service for ccTLD Operators
> On 26 May 2016, at 14:44, Romeo Zwart wrote: > > Following the guidelines of the working group, we (the NCC) have > recently started reviewing eligibility of ccTLDs based on the existing > document text. If the document moves back to a 'limbo-state' based on > renewed discussion in the WG that makes it very difficult for the NCC to > proceed. Romeo, I think the NCC should continue with its current plans based on RIPE663 rather than wait for an updated document which might not emerge any time soon, if at all.
Re: [dns-wg] Tweaks to RIPE 663: Secondary DNS Service for ccTLD Operators
> On 26 May 2016, at 13:33, Shane Kerr wrote: > > 1. Gaurab and I think that there should be an exemption for ccTLD who > do not currently have IPv6 service. (There are a few tens of ccTLD > who do not yet have IPV6, and I would like the RIPE NCC to be > able to help them get IPv6 service if they want it.) I disagree. If those ccTLDs want to be reachable over IPv6 there are plenty of commercial DNS hosting providers who can provide that service. The NCC does not need to provide that crutch IMO. Those ccTLDs should be making their own IPv6 arrangements instead of relying on the NCC to do it for them. > 2. Gaurab mentioned that there are some ccTLD who have 3 servers but > they are all in the same network. The document should be flexible in > order to insure network diversity. It already is. I quote: "If there is sufficient diversity and there are more than three other secondary name servers for the zone already, the operator of the zone is considered to be no longer in the start-up phase of their operations." Three name servers in the same network does not pass the RIPE663's threshold for sufficient diversity. That only adds up to two secondary name servers too. > I know the document is less than 6 months old and just being > implemented now, but maybe we can revise it to include these two > changes? I think the document is fine as-is but will welcome text which clarifies any ambguities or misunderstandings.
Re: [dns-wg] Yeti DNS and the RIPE NCC
> On 25 May 2016, at 10:50, João Damas wrote: > > Actually Jim, first comes the poll of the community to see if this fits, Well Joao the community already seems to be heading in that direction. YMMV. That said, it would be helpful for the WG to have a better understanding of the requirements before asking the NCC to investigate. > later comes what you suggest, if the community decides to ask the RIPE NCC to > look into it, Up to a point. Though before the NCC does look into this (or anything else for that matter), I think the NCC should have a sense of what the WG's expectations and objectives are. Unclear requirements help nobody. > or have we become the Ministry of IP? I have no idea what this Ministry does or why they should interfere in WG matters. :-)
Re: [dns-wg] Yeti DNS and the RIPE NCC
> On 24 May 2016, at 13:41, Shane Kerr wrote: > > Please let us know what you think about this idea. Before we take this idea forward, could someone please suggest metrics and milestones that could be used to assess the success or failure of this activity? For bonus points, it would be good to know what sort of resource commitments will be needed and the level of reporting that can be expected from the NCC being involved in Yeti DNS. We should be careful to not have the NCC get into open-ended, vague commitments where there's uncertainty about the on-going value to the community. Experiments are all very well but both the WG and the NCC's DNS team need to know how/when to decide to kill the experiment or turn it into a formally supported resource or do something else with it.
[dns-wg] RIPE70 minutes
Colleagues, here are the minutes from our meeting in Amsterdam last year. My apologies for the unacceptable delay in getting these circulated. Please let us know if there are any errors or omissions. DNS WG - Session 1 RIPE 70 13 May 2015 WG co-Chairs: Peter Koch, Jim Reid, Jaap Akkerhuis Scribe: Emile Aben A. Administrivia Peter Koch opened the session and the minutes of the previous meeting were approved. B. RIPE NCC Report - Anand Buddhdev and Romeo Zwart, RIPE NCC https://ripe70.ripe.net/presentations/75-RIPE70_AnandBuddhdev_DNS_Update.pdf Lars Liman, Netnod, noted that the old scripts won't go away even if visualisations were removed. Romeo answered he was aware of that. George Michaelson, APNIC, expressed interest in query rates for AS112, He was surprised by seeing 10% of queries over IPv6. Anand said he saw similar numbers for other authoritative servers. Jim Reid suggested putting a 'this is going away' sign on the old DNSMON visualisations. Romeo responded that was already done, and said the plan is to make landing page for old DNSMON a redirect to the new DNSMON. C. IETF Report Peter made the room aware of a virtual interim meeting of the IETF dns-ops group. Minutes of this meeting are available online: https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/minutes/minutes-interim-2015-dnsop-1 D. Knot DNS 2.0 - Status Update - A New Major Version Introducing Updated DNSSEC - Jan Vcelak, CZ.NIC https://ripe70.ripe.net/presentations/71-ripe70-vcelak-knot.pdf Olafur Gudmundsson, Cloudflare, asked if key management is time driven or predicate driven. Jan said they plan to provide hooks so external scripts can do various checks. Jan further explained that if a key server is down, steps in key management are postponed. Patrik Falstrom, Netnod, said he likes to have callback mechanism so it's possible to have external software react to key management events. E. Test Cases for Validating a DNS Delegation - A Step Towards Best Practice - Sandoche Balakrichenan, AFNIC https://ripe70.ripe.net/presentations/83-TRTF-RIPE2015.pdf Sebastian Castro, NZRS, said they have code ready for a discovery check, and wanted to clarify if only compliance checks were wanted, or also discovery checks. Sandoche responded that if there was code and consensus that this should be added, it would be added. Jelte Janssen, SIDN, commented that he liked the effort and said it's probably good if tool sets can have slightly different focus. F. DNSSEC ECDSA Algorithm Use and Acceptance - Olafur Gudmundsson, Cloudflare https://ripe70.ripe.net/presentations/85-Alg-13-support.pdf Anand responded to Olafur’s presentation with the promise that for next meeting all resolvers will have ECDSA support. Anand asked if Cloudflare could contribute in making validating with ECDSA faster. Olafur responded they have code for OpenSSL to speed things up. Geoff Huston, APNIC, said he kept on hearing there is no DNSSEC out there, but he sees 25% of users do validate. He also said that lack of ECDSA support went from one in three last September to one in five now, and thanked Olafur for the efforts in making that happen. G. DLV Sunset - Jim Martin, ISC https://ripe70.ripe.net/presentations/81-RIPE-DLV-timeline-20150513.pdf George Michaelson suggested a shorter time line for the DLV sunset. He also asked what the resolver side failure mode is when the server stops responding. Jim Martin said it was SERVFAIL if you are running BIND. Warren Kumari, Google, thought that because of Jim's presentation the number of DLV participants would drop and would be interested in seeing the number of participants on 14 May. Jim Reid said he found the time line for sunset quite reasonable with regards to software packaging, and thanked ISC for bringing about the long overdue death of DLV. He also brought up the issue of DLV code in BIND and suggested ISC remove it from the next appropriate BIND release. Jim Martin responded he would take that suggestion to the developers at ISC. DNS Working Group - Session 2 RIPE 70 14 May 2015, 9:00 WG Co-Chairs: Jim Reid, Peter Koch, Jaap Akkerhuis Scribe: Florian Obser H. Knot Resolver – A More Thorough Introduction - Marek Vavruša, CZ.NIC https://ripe70.ripe.net/presentations/121-knot-resolver-ripe70.pdf Ed Lewis, ICANN, asked if the resolver can learn a new trust anchor for the root zone. Marek answered that he didn't talk about DNSSEC because it doesn't validate yet. Jim Reid asked when the software will be released for general use. Marek said that he wants to have it production ready by the end of the year, maybe earlier and that there is a release plan on the web site. I. Network-Tuning for DNS Zone Transfers in (lossy) Long Fat Networks - Marco Prause, DENIC https://ripe70.ripe.net/presentations/123-TuningZoneTranfers4LFNs.pdf Ed Lewis asked what kind of records are in the IXFR and if they are mostly to be removed RRSIGs. Marco co
Re: [dns-wg] IDN registration question
On 21 Apr 2016, at 15:51, Shane Kerr wrote: > >> try registering the puny code version? >> xn--5o7dx5d.com > > Genius idea! Trying it... > > Domain.com tells me that I can get it for .COM, .CLUB, .NET, .US, .ORG, > and .ME but that sadly it is already taken > in .CO, .ONLINE, .SITE, .WEBSITE, and .BIZ. FWIW: shaun% dig xn--5o7dx5d.co ns | grep status ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25390 shaun% dig xn--5o7dx5d.online ns | grep status ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55541 shaun% dig xn--5o7dx5d.site ns | grep status ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56114 shaun% dig xn--5o7dx5d.website ns | grep status ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7099 shaun% dig xn--5o7dx5d.biz ns | grep status ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64503 and: shaun% whois -h whois.nic.biz xn--5o7dx5d.biz Not found: xn--5o7dx5d.biz This suggests xn--5o7dx5d.biz isn’t registered or in some lock/expire/suspended state at the registry. I can’t be bothered checking the other TLDs. Trusting a registrar’s control panel is usually a bad idea. Perhaps the registrar is getting confused by the EPP responses from the registry and translates them into bogus messages about domain names being already taken. Or maybe the registrar’s screwing up the outgoing domainCreate/domainInfo EPP requests? I think you need to find another registrar.
Re: [dns-wg] Additional DNS service capacity for ripe.net zone
> On 7 Apr 2016, at 13:57, Romeo Zwart wrote: > > However, to be better prepared for extreme traffic floods, we will work with > an external party to provide additional DNS service capacity for serving the > ripe.net zone. Romeo, this is great news! IMO, “outsourcing” some DNS hosting to complement the NCC’s DNS operations is a Very Good Thing for the reasons you mentioned: more diversity and capacity, extra resilience to withstand DDoS attacks, sharper focus on “core” activities, etc. It should also mean a clearer separation between the NCC’s core DNS (and other key services) and stuff that’s peripheral or irrelevant to the NCC’s mission. That should also reduce the risks from collateral damage. Have you given any thought to adding a third (anycast?) DNS hosting option? ie Highest priority: K root Medium priority: .arpa stuff (and ripe.net?) Lowest priority: best efforts slave service for deserving ccTLDs Each of these might or might not include an outsourced component from a reliable DNS hosting provider. Just sayin’...
Re: [dns-wg] RIPE Authoritative DNS services degraded
Thanks for the update Romeo. Best wishes to you and your colleagues for your damage limitation efforts.
Re: [dns-wg] Meanwhile, at ICANN...
> > On 6 Jan 2016, at 08:03, Shane Kerr wrote: > > Not necessarily RIPE Database related, but I thought I'd point out that > ICANN is considering replacing WHOIS for gTLD: > > https://www.icann.org/news/announcement-2016-01-04-en Hi Shane. I think you’re grossly overstating things. IMO a call for volunteers to "serve on a PDPWorking Group to establish a policy framework for a next-generation gTLD Registration Directory Service” — whatever these things might be — is unlikely to amount to anything, even by ICANN’s dismal record on whois matters. By all means watch the never-ending whois food fights at ICANN. But don’t expect any sort of constructive or useful outcome.
Re: [dns-wg] Algorithm Upgrade for RIPE NCC DNS Zones
On 21 Dec 2015, at 12:51, Anand Buddhdev wrote: > I am happy to report that we have completed the roll-over of the keys > of all our zones, and upgraded the signatures to RSA/SHA256. Well done! Congratulations to you and your colleagues Anand for the successful completion of this task. Are there any experiences or lessons learned during this rollover that are worth sharing with the WG?
[dns-wg] finalising the RIPE Documents on DNSMON and ccTLD service
There have been no further comments on the draft documents since the RIPE meeting in Bucharest. We can declare victory and get these published/adopted. Some minor tweaks were suggested when the drafts were originally circulated for comment. Romeo has taken account of these and will incorporate these into the final versions. My thanks to Romeo for his patience and hard work on these documents and to the WG.
[dns-wg] WG minutes from RIPE71
Colleagues, here are the minutes from Bucharest. Please let the WG co-chairs know if there are any errors or omissions. Thanks. ripe71minutes Description: Binary data
Re: [dns-wg] Reminder about the WG Chair appointment process
On 12 Nov 2015, at 23:45, Jim Martin wrote: > Can he simply be appointed by acclamation? Jim, the idea is the WG decides by consensus who fills the vacancy. It will be easier to make that consensus judgement if there are more statements of support (or opposition) for the nominees. Clearly, it would be better if a larger number of WG members than we've seen so far expressed their opinion about who they wanted to appoint. That said, there should be some sort of appointment by acclamation at the WG next week.
[dns-wg] Reminder about the WG Chair appointment process
Colleagues, there's still time left to nominate candidates and to express support for those who have been nominated. The response so far from the WG has been disappointing and that's making it awkward to decide if consensus has been reached. Please speak up! Even if it's just to say "meh". :-)
[dns-wg] revised agenda for RIPE71
The agenda for next week's meeting has been updated. Here's the latest version. Please note that things are not finalised and there might be further tweaks to the agenda or running order. # # $Id: agenda,v 1.7 2015/11/11 14:08:51 jim Exp $ # FIRST SESSION A. Usual Administrivia 5 mins Agenda bashing Minutes of previous meeting Review of Action Items B. NCC Report 15 mins Anand Buddhdev C. Measuring the impact of IPv6 resolver preference 20 mins Chris Baker, Dyn D. Impact of DNS over TCP - a resolver point of view15 mins Joao Damas, Bondis The impact two very different aspects of the life of a recursive server were examined for this project: queries to authoritative servers as well as the queries from stub resolvers. Traffic from two different ISP's recursive resolvers was captured to analyse the potential impact on the servers of long lived TCP sessions, investigating the effect of timeout settings, the total number of simultaneous connections that would be kept open and the potential benefits of connection reuse as proposed in the current version of draft-ietf-dnsop-5966bis, with the intent of offering simulated operational advice, based on observed traffic. E. Integration testing of DNS Recursive servers 15 mins Ondřej Surý, CZ.NIC A generic testing framework was produced as a part of developing the Knot Resolver. This framework is written in python and can use UNIX domain sockets to bypass the underlying physical network. F .nl Open DNS datasets and Statistics 10 mins Marco Davids, SIDN SIDN makes available aggregated datasets from .NL authoritative servers to the Internet/Research/DNS communities. It includes visualizations of the DNS-traffic for .nl, as well as statistics on domain registrations, DNS queries, DNSSEC usage, plus layer-3 and layer-4 information. The datasets (starting from May 2014) are updated on a daily basis. They are provided in JSON-format and can be found on https://stats.sidnlabs.nl. G. Discussion of latest SSAC recommendations10 mins SSAC Stuckee SECOND SESSION H. Discovery method for a validating stub resolver 20 mins Xavier Gorjón, NLnetLabs This research project aims to develop a discovery method to ensure DNSSEC information can be delivered to the end host. It used RIPE ATLAS to study the current state of DNSSEC aware and DNSSEC validating resolvers, and define a course of action from that information. The project explored a novel method to discover the capabilities of the ISP's recursive resolver and bypass incompetent Customer-premises equipment (CPE) middle-boxes to target the often more capable ISP's resolver directly. I. DNSSEC for Legacy Applications 15 mins Willem Toorop, NLnetLabs Validating stub resolvers are hampered by middle boxes (typically CPE) that corrupt the path from the stub to the recursive resolver. Using the getdns library and the Linux/Unix name resolution framework, libnss_getdns provides (stub-level) DNSSEC validation for legacy applications. This module can work around broken middle boxes by double checking bogus answers. It also offers in-path signalling of DNSSEC failure for http, informing the end-user why validation failed and giving them control of deciding how to deal with that. J. Implementation challenges of geographic split-horizon DNS20 mins Jan Včelák, CZ.NIC There are multiple ways to find a network service according to a client's geographic location. One possibility is to perform a split-horizon at the DNS level. The presentation will briefly inform about existing approaches, problems introduced by this mechanism, possible solutions of these problems, and experience we gained when implementing this feature into Knot DNS. K. Root Zone KSK rollover 30 mins Roy Arends, IANA L. WG Co-chair appointment 5 mins M. AOB
[dns-wg] draft agenda for Bucharest
Colleagues, here's the draft agenda for RIPE71. Please note that this is subject to change, most likely in the running order. A definitive agenda will be circulated in a couple of weeks. I'll remind you all that the WG co-chair appointment process is under way. There's still time for volunteers to come forward. It would be nice to see more statements of support for those who have volunteered too. Hope to see you all in sunny Bucharest next month. # # $Id: agenda,v 1.6 2015/10/21 22:01:47 jim Exp $ # FIRST SESSION A. Usual Administrivia 5 mins Agenda bashing Minutes of previous meeting Review of Action Items B. NCC Report 15 mins Anand Buddhdev C. Measuring the impact of IPv6 resolver preference 20 mins Chris Baker, Dyn D. Impact of DNS over TCP - a resolver point of view20 mins Joao Damas, Bondis The impact two very different aspects of the life of a recursive server were examined for this project: queries to authoritative servers as well as the queries from stub resolvers. Traffic from two different ISP's recursive resolvers was captured to analyse the potential impact on the servers of long lived TCP sessions, investigating the effect of timeout settings, the total number of simultaneous connections that would be kept open and the potential benefits of connection reuse as proposed in the current version of draft-ietf-dnsop-5966bis, with the intent of offering simulated operational advice, based on observed traffic. E. Integration testing of DNS Recursive servers 15 mins Ondřej Surý, CZ.NIC A generic testing framework was produced as a part of developing the Knot Resolver. This framework is written in python and can use UNIX domain sockets to bypass the underlying physical network. F. Discussion of latest SSAC recommendations15 mins SSAC Stuckee SECOND SESSION G. Discovery method for a validating stub resolver 20 mins Xavier Gorjón, NLnetLabs This research project aims to develop a discovery method to ensure DNSSEC information can be delivered to the end host. It used RIPE ATLAS to study the current state of DNSSEC aware and DNSSEC validating resolvers, and define a course of action from that information. The project explored a novel method to discover the capabilities of the ISP's recursive resolver and bypass incompetent Customer-premises equipment (CPE) middle-boxes to target the often more capable ISP's resolver directly. H. DNSSEC for Legacy Applications 15 mins Willem Toorop, NLnetLabs Validating stub resolvers are hampered by middle boxes (typically CPE) that corrupt the path from the stub to the recursive resolver. Using the getdns library and the Linux/Unix name resolution framework, libnss_getdns provides (stub-level) DNSSEC validation for legacy applications. This module can work around broken middle boxes by double checking bogus answers. It also offers in-path signalling of DNSSEC failure for http, informing the end-user why validation failed and giving them control of deciding how to deal with that. I. Implementation challenges of geographic split-horizon DNS20 mins Jan Včelák, CZ.NIC There are multiple ways to find a network service according to a client's geographic location. One possibility is to perform a split-horizon at the DNS level. The presentation will briefly inform about existing approaches, problems introduced by this mechanism, possible solutions of these problems, and experience we gained when implementing this feature into Knot DNS. J. Root Zone KSK rollover 30 mins Roy Arends, IANA K. WG Co-chair appointment 5 mins L. AOB
[dns-wg] co-chair nomination and appointment reminder
Colleagues, here's a reminder that there is still time to nominate candidates. Please post statements of support on the list for those who have been nominated. This will help the disintersted co-chairs make a consensus judgement about who should be appointed. If there's no clear consensus, it will be necessary to make a choice at random from the consensus-tied candidates. I hope it doesn't become necessary to use that option. So please speak up!
Re: [dns-wg] Co-chair appointment process: 2015 call for volunteers/nominees
On 12 Oct 2015, at 15:49, Peter Koch wrote: > And this is meant literally, i.e., after more than a decade > as a DNS WG co-chair I will not make myself available for another election > or appointment. It has been a pleasure to serve this community in that role, > and I'll promise (or threaten, if you prefer) not to go silent (nor dormant), > but we're seriously encouraging a change here. Thanks for making your intentions clear Peter. I appreciate all you've done for the WG and am sorry to see you step down and create a vacancy. FWIW I will be following in Peter's footsteps next year. I am going to step down then and will not be seeking re-appointment. Our phased departures ensure the WG will get some new faces as co-chairs in an orderly manner over the next year or two and that's a healthy (and perhaps overdue) thing.
Re: [dns-wg] Co-chair appointment process: 2015 call for volunteers/nominees
On 12 Oct 2015, at 15:19, Gert Doering wrote: > Maybe my old eyes are failing me - but is this to add a WG co-chair to > the existing group, or is one of you stepping down - and if yes, who? Hi Gert. The object of this exercise is not to add another co-chair. Our procedure only allows for 2 or 3 co-chairs anyway. The intention is to have one co-chair in place by the end of this year who has been selected by the process that was agreed by the WG earlier this year. That selection process will repeat in future years until all of the WG's co-chairs have been appointed by that procedure. After that point it will be the end of the first term for whoever gets selected this year. So by 2017, things should just roll on indefinitely with one beauty contest a year unless something goes badly wrong. This means one of the current co-chairs is going to step down this year and may (or may not) make themselves available for selection. And as I type this, Peter's given further clarification on the next steps.
[dns-wg] Co-chair appointment process: 2015 call for volunteers/nominees
Colleagues, you will be aware that we have adopted a procedure for the regular appointment of a WG co-chair. It is now going to be invoked for the first time. If you are interested in helping to run the WG, now's your chance to step forward. The main responsibility for a co-chair is to prepare the agenda for WG sessions by identifying potential speakers and discussion topics. There are also some obligations for the Policy Development Process but these are not so significant for the DNS WG because it rarely makes DNS policy. Further details of a WG Chair's responsibilities are in RIPE Document 542. If anyone is interested in volunteering and needs more info about what that entails, feel free to contact any or all of Jaap, Peter or myself. The barriers for entry are zero. Anyone can volunteer simply by posting to the list. You can nominate anyone, including yourself. It might be helpful for candidates to give the WG an explanation of why they have been nominated, what fresh ideas or suggestions they have, possible improvements to WG activities, etc, etc. Members of the WG can express their support (or not) for those who volunteer. The WG will decide by consensus on the list who gets appointed. If there is no consensus, the consensus tied candidates will draw lots. The aim is to have a co-chair appointed by this process at the meeting in Bucharest.
Re: [dns-wg] Last Call for presentations and Draft programme for RIPE 71
On 27 Sep 2015, at 07:26, Peter Koch wrote: > On Sat, Sep 26, 2015 at 10:21:06PM +0200, Benno Overeinder wrote: > >> https://ripe71.ripe.net/programme/ >> >> There are still few slots remaining for a final RIPE 71 programme and >> RIPE Programme Committee will accept new proposals until 11 October 2015. > > just to avoid any confusion: this is only relevant to the _plenary_ programme. FWIW, there is still a little time available in the WG's provisional agenda. So please email dns-wg-cha...@ripe.net if you have suggestions for agenda items. Do it soon though. It might not be possible to squeeze in last-minute proposals.
Re: [dns-wg] RIPE NCC domain registrations
> On 17 Sep 2015, at 09:13, Romeo Zwart wrote: > > We have completed the release of some currently unused domains. Thanks very much Romeo. It’s good to know that we’re rid of this cruft.
[dns-wg] Agenda items for RIPE71
Colleagues, it may seem odd to be doing this at the height of the summer holidays when the next RIPE meeting is 3 months away. If you have suggestions for agenda topics or presentations for the WG session(s) in Bucharest, could you please contact the co-chairs at dns-wg-cha...@ripe.net? Thanks. The draft meeting plan has allocated just one slot for the WG. It's tentatively scheduled for the Thursday morning (https://ripe71.ripe.net/programme/meeting-plan). The WG will only get a second slot (ideally also on the Thursday) if we have a draft agenda which shows the extra slot is needed. We also need to do that before any other WGs try to grab the currently free slots. So the sooner we can get an outline agenda put together, the better! Your co-chairs often get last-minute suggestions and/or overspill from the plenary which can be tricky to accommodate. That could be harder if we just have a single slot next time. So to avoid disappointment, please try to give us plenty of advance notice for your proposed agenda items and discussion topics. Ta. I hope you all enjoy the summer holidays and look forward to seeing everyone at RIPE71.
Re: [dns-wg] RIPE NCC secondary DNS configuration changes complete
On 3 Aug 2015, at 11:25, Anand Buddhdev wrote: > We have now completed this configuration change. Well done to you and your team Anand!
[dns-wg] retaining ripe.int
On 30 Jun 2015, at 18:53, Peter Koch wrote: > This is probably an exception for the lack of a drop catching risk, > but keeping the domain to maintain a stake in the INT domain > might be OK. That is a remarkably bad idea. The .int domain's supposed to be for international treaty organisations. The NCC is not one. There is no reason why it should "maintain a stake in the INT domain". It simply shouldn't have a stake in this at all. If anything the NCC should be running away from .int as fast as is humanly possible.
Re: [dns-wg] RIPE NCC domain registrations
On 30 Jun 2015, at 17:28, Ralf Weber wrote: >> Holding on to these domains and continuing to maintain them "just because" >> seems unwise. ICANN already has ripe. on a reserved list so there is >> no chance of them going to an impostor. > ripen.*, but not ripe(-)ncc.*. Will be interesting to see what happens to > them. Perhaps in the same sense that watching paint dry can turn out to be interesting... :-) FWIW lookups of ripe-ncc.$GTLD for some of the most popular gTLDs after .com, .net and .org return NXDOMAIN. [I got bored after making a handful of queries and couldn't be bothered checking every gTLD.] Since nobody else has snapped up these Really Juicy Names yet, it seems reasonable to assume this isn't going to happen any time soon. OTOH this discussion might well prompt the domain name industry's bottom feeders to do just that. :-)
Re: [dns-wg] RIPE NCC domain registrations
On 30 Jun 2015, at 13:41, Ralf Weber wrote: > Is this considered bad practice now? Was there a policy change I missed? Hi Ralf. AFAICT there has never been any policy in this area: that's another rat-hole we don't need to explore for now. The NCC has from time to time registered domain names which were felt to be either a good idea or potentially useful at some point. Sometimes those choices have in hindsight turned out to be misguided. For others the domain names have long outlived their usefulness. So it's reasonable for the NCC to do some housekeeping and get rid of unwanted or unneeded cruft. It's good operational practice. Consulting the WG about that is also to be welcomed, even though the WG should not micro-manage operational matters. Romeo's saying "Here are some domains that deserve to die. Any objections?". If you or anyone else has objections to this approach, please say so and give good reason(s) for your PoV. >> We now plan to release the following domains, which are not being >> actively used by the RIPE NCC: >> >> ripe-ncc.org >> ripe-ncc.com >> ripe-ncc.net >> ripencc.com >> ripencc.net >> ripencc.org >> ripelabs.net >> ripen.cc >> ripe.int >> ipv6roadshow.com >> ipv6roadshow.net >> ipv6roadshow.org > So we are talking about 12 domains. What is the hassle of keeping them? Adding cruft for cruft's sake creates needless hassles and overhead. We should all be wary about asking the NCC to make open-ended commitments and at the very least review those sorts of requests/decisions from time to time. From that perspective, getting a sense from the WG about these domain names is a good thing. > I'm pretty "confident" the new owners won't do as good things with it > as the RIPE NCC. Who cares? If the domains no longer serve any useful purpose or have no worthwhile affiliation with the NCC or the RIPE community, there seems to be little point in keeping them. Or as was discussed a few months ago, there would be no point rolling over their DLV keys. Since DLV is going away, that may well be the catalyst to give some of these crufty domains a one-way ticket to Dignitas. Holding on to these domains and continuing to maintain them "just because" seems unwise. ICANN already has ripe. on a reserved list so there is no chance of them going to an impostor. Personally speaking, I do not like open-ended commitments which are just allowed to drift. In this case, nobody appears to be sure why these domains need to exist any more or have a good reason to hold on to them. Romeo's asking the WG if there are good reasons, just in case there are factors which have been overlooked. If anyone knows of such considerations, please speak up.
Re: [dns-wg] RIPE NCC domain registrations
On 30 Jun 2015, at 15:25, Nick Hilliard wrote: > There's no policy requirement, but it's good practice for the NCC to > consult with the community for something like this. It keeps one side > honest and the other side well-informed. Indeed. > FWIW, I'm in favour of dropping all the inactive / registration protection > domains. There are no compelling reasons to keep any of them. No hats... Me too! IMO the domain names Romeo's list are long overdue for removal. I strongly support their orderly and timely removal.
Re: [dns-wg] a final(?) co-chair selection process
On 5 May 2015, at 16:26, Nick Hilliard wrote: > in the case where two chairs are due to resign in the same year, the > process for deciding who stands down is still ambiguous. When this was > discussed in January, there was some consensus that this should be > clarified. See clause 7.
[dns-wg] a final(?) co-chair selection process
Colleagues, here is what I hope could be a co-chair selection process that the WG can adopt. It's been tweaked to take account of recent feedback and should now be free of ambiguities. The most significant change is a new Clause 7: how to handle things whenever an unforseen situation arises. ie The WG will decide how best to handle these situations as and when they arise. This should hopefully avoid further rat-holing on hypothetical corner cases. Please remember this process is not etched in stone. It's not Holy Writ. It's supposed to be a "good enough" starting point. If later experience tells us that assessment is wrong or if a better mechanism happens to come along, the WG can of course apply its usual consensus based decision-making to change or replace whatever process is currently in use. Traffic on the list about this topic has been rather light and this has made it difficult to make an assessment on whether consensus has been reached or not. The WG needs to make a decision about this by RIPE70 - ie next week. With that in mind, your co-chairs have decided that silence implies consent. So unless there are substantive comments to the proposed text -- meaningful objections supported by an justification/explanation and replacement text -- the intention will be to adopt the proposed text at the WG meeting next week. Similarly, if anyone objects to this silence-implies-consent-approach or feels more time is needed, please speak up. Assuming the WG adopts this process, it will be invoked for the first time later this year, probably at or around RIPE71. # # $Id: appointment,v 1.9 2015/05/05 12:53:39 jim Exp $ # [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as determined by the WG. [2] A co-chair will serve a term of N years, where N is the number of co-chairs. Terms will be staggered so that one term expires every year. [3] The WG will be given adequate notice that a co-chair's term is ending and to invite applications for that position. Anyone can volunteer for appointment except that at the end of a second consecutive term, the outgoing co-chair may not do so. [4] At the end of a co-chair's term, the WG will decide by consensus who is appointed to the available co-chair position. In the event of a tie, the consensus tied candidates will draw lots. [5] The WG may decide by consensus to remove a WG co-chair at any time. [6] Consensus will be determined on the DNS WG mailing list. The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair(s) who is the subject of that consensus judgement. [7] Any issues relating to the selection or replacement of a co-chair which are not covered by the above will be decided by WG consensus. When the WG is unable to reach consensus, the matter will be referred to the RIPE Chair (or their deputy) whose decision shall be final. [8] Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final.
Re: [dns-wg] yet another heave on the WG Chair selection procedure
On 11 Jan 2015, at 19:16, Nick Hilliard wrote: > But it was fewer words and simpler to say "every second RIPE meeting". "every calendar year" is even simpler and fewer words than that Nick. :-) I doubt it will matter or if anyone really cares when the selection process kicks in at some point during the year. Maybe it's Q1 one year and Q4 the next. So what? Or maybe the selection thing needs to be started earlier than normal because a co-chair resigns before their term's anniversary. I think that provided a selection event takes place at least once during a calendar year, it shouldn't matter when in that year that process is invoked. It's kind of like an AGM which usually can take place +/- 3 months from the previous one.
Re: [dns-wg] yet another heave on the WG Chair selection procedure
On 7 Jan 2015, at 20:15, Nick Hilliard wrote: > On 06/01/2015 12:41, Niall O'Reilly wrote: >> [2] A co-chair will serve a term of N years, where N is the number >> of co-chairs. Terms will be staggered so that one term expires every >> year. > > This is also semantically non-deterministic in the case where the number of > co-chairs changes. It's not Nick. If the number of co-chairs changes, the term of office would be adjusted to reflect this. ie If/when 3 co-chairs drops to 2, what were the 3 year terms of the two remaining incumbents would automagically drop by a year. Likewise if we go from 2 to 3, the 2 year terms of the incumbents get extended by a year and the new stuckee slips into the gap that's just been created in the selection cycle. This is implicit from what was in the proposed text. Or should be. Now I suppose we could choose to write this up and spell it out in painstaking detail. But that seems to be overkill and/or shed painting. YMMV. That said your suggested [2] seems to be a cleaner and less verbose solution: > [2] Every second RIPE meeting, the co-chair who has been in that > position the longest will resign. If more than one co-chair qualifies > for resignation, then only one co-chair will be required to resign, as > determined by [drawing lots|some other appropriate means]. Though I'd prefer "once a year" to "every second RIPE meeting" in case the number of RIPE meetings per year changes or one of them gets cancelled say because the Kras catches fire. And while the selection process may well be aligned with a RIPE meeting, I would be very uncomfortable if that gave the impression that the meeting took precedence over the mailing list when it came to making the consensus decision.
[dns-wg] yet another heave on the WG Chair selection procedure
Happy new year everyone. The list has been silent about the draft selection procedure. This means it's not possible to decide if there's a consensus or not so we can declare victory and move on. Sigh. Could I ask you all to review the proposal and comment on the list? One sticking point appears to be the "A co-chair cannot serve more than 2 consecutive terms." provision in [2]. Someone commented at the mike at RIPE69 that this was a good thing. One of your co-chairs says the opposite. Everyone else has not commented one way or the other. Result: stalemate. WGs are supposed to have adopted a selection process by now and have it up and running in good time for RIPE70. Our WG is lagging behind the others. So, could we please have some comments on the proposed procedure and try to get the WG to converge on a consensus? Thanks. It would be appreciated if people gave clear statements of support or objection. In the latter case, please explain why and suggest alternate text. Simply saying "I disagree" will not be constructive. Though it would of course help with the consensus determination. Here's the suggested process again: # # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ # [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as determined by the WG. [2] A co-chair will serve a term of N years, where N is the number of co-chairs. Terms will be staggered so that one term expires every year. A co-chair cannot serve more than 2 consecutive terms. [3] The WG will be given adequate notice that a co-chair's term is ending and to invite applications for that position. Anyone can volunteer for appointment. [4] At the end of a co-chair's term, the WG will decide by consensus who is appointed to the available co-chair position. In the event of a tie, the consensus tied candidates will draw lots. [5] The WG may decide by consensus to remove a WG co-chair at any time. [6] Consensus will be determined on the DNS WG mailing list. The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair who is the subject of that consensus judgement. [7] Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final.
Re: [dns-wg] reminder about the WG Chair appointment process
On 25 Nov 2014, at 17:54, Nick Hilliard wrote: > You're welcome for the comments. I wasn't able to make the london wg > session and only subscribed to the mailing list on Oct 11, which was a > couple of days after the previous discussion about chair proposals ended. > Timing is everything, apparently. Indeed. Sigh. > I don't disagree with any of this, including the common sense thing, but > you've put your finger on the core issue: making things up as you go along > is fine in situations where the WG chairs are both benign and competent. But why should this be a problem? Presumably the WG can be trusted to select people who have those qualities. If it turns out not to be the case, the WG has the tools to get rid of someone who no longer has the confidence of the WG for whatever reason. The proposed mechanism includes a measure for removing any WG co-chair who was evil or incompetent or both. So it shouldn't be necessary to go beyond that. If this admittedly complacent attitude later turns out to have been a mistake, it can be addressed at that point. > Problems arise where either of these attributes is missing, which is one of > the core reasons why there is a move to have WG selection guidelines in the > first place. Not quite Nick. The main reasons for this WG chair selection-fest are accountability and transparency. It was not motivated by the recent need to remove a defective WG chair. Though admittedly some people felt at that time that the absence of a process to follow was a concern. Not that this gap made a difference to the outcome in that particular case once an angry mob with pitchforks and blazing torches made their feelings known in the relevant WG.
Re: [dns-wg] reminder about the WG Chair appointment process
On 25 Nov 2014, at 12:37, Nick Hilliard wrote: > Jim, the proposal is non-deterministic. Nick, thanks for your comments. I'm both surprised and disappointed. Surprised because the mood of the room/WG appears to be the proposed text is "good enough". Nobody has advocated making radical surgery to it despite the proposed text being in circulation for almost two months now. I'm disappointed that you've not provided alternate text to address the concerns you raised. This is not helpful. > There's no discriminator in place > to decide who gets to stand down if N changes and two chairs need to stand > down at the same time, or if somehow the chair terms become synchronised. Just apply common sense. If we go from 3 to 2 WG co-chairs, the one that's next due to stand down does not get replaced and the remaining ones get their terms cut by one year. If we then go from 2 to 3, do the reverse: extend the current terms by a year and slot in a new co-chair appointment at the newly-created gap in the cycle. If a co-chair leaves mid-term, the replacement (if one) gets appointed for the remainder of that term and we carry on from there: no muss, no fuss. Says he making it up as he goes along :-) > Drawing lots is fine but where, how, who, what? In whatever place and format that the WG decides is resonable and appropriate: presumably at a webcasted session of the WG. A decision on that is implementation detail and since it may change from time to time, I think it's undesirable to have a rigid definition here. IMO RIPE should always operate with the minimum of rules so there's the maximum flexibility to deal with issues in the most pragmatic way whenever they pop up. This is what differentiates our community from ICANN. Or the ITU. It would be great shame if that got lost. It would be even worse if we deliberately chose to follow the models used by those institutions. > What happens if the WG goes to blazes and there's only one chair and that > chair is subject of a mutiny? If that ever happens, bring in Bijal to kill the WG. :-) The WG would clearly be irreedemably broken by then and cannot continue. The community can then decide to create a new WG (or not) using the usual mechanisms of running a BoF or two, finding a possible chairman and drafting a new chapter. This seems so obvious to me, it shouldn't need to get documented in some Big Book of Working Group Procedures resting in the Holy Grail at the Temple of Process. [Hey, isn't that the title of the next Indiana Jones film? :-)] There's nothing in the current proposal to deal with one of the WG co-chairs getting incapacitated by killer sharks with mind-control lasers. Or all co-chairs disappearing in a mysterious boating accident involving the Loch Ness monster. The point I'm making here is inventing rules to cover every potential corner case and scenario is a mug's game. I hope everyone has got better things to do. IMO all that's needed is to agree and document the fundamental principles. How these get applied can be decided if/when some unforseen circumstance emerges and what approach is best to handle that, getting consensus from the WG if need be. I would expect the WG can trust itself to take a reasonable and pragmatic course of action at that point. If it can't, no amount of rules or process is going to help. > Maybe this isn't important +1 > and we can do the usual trick of sweeping it > under the carpet and pretending that it doesn't exist / isn't a problem / Works for me. YMMV. > oh look at the nice view out the window over there. Look! A squirrel!
[dns-wg] reminder about the WG Chair appointment process
Colleagues, there's been very little response or discussion about the procedure which was proposed at the beginning of October. I think it's now time to start a "Last Call" on this. If anyone has any tweaks to he proposed text or counter proposals, please speak up now! It would be helpful if any changes are accompanied by suggested replacement text and an explanation. Simply saying "I don't like Clause Foo" is not helpful or productive: please say why you don't like that clause and provide replacement text. Since the PDP uses 4 weeks for its Last Call phase, let's do the same here. So if there are no changes or comments on the suggested text by the end of the year, it will be considered to be the agreed, final version of the procedure. [Well, until we revisit this in the future...] Assuming there is agreement on the final text by the end of the year, I will ask the WG for statements of support for that final text so that we can hopefully declare consensus early in the new year. The plan would then be for the procedure to start in good time for RIPE70. In case anyone cares, here's that proposed text again. # # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ # [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as determined by the WG. [2] A co-chair will serve a term of N years, where N is the number of co-chairs. Terms will be staggered so that one term expires every year. A co-chair cannot serve more than 2 consecutive terms. [3] The WG will be given adequate notice that a co-chair's term is ending and to invite applications for that position. Anyone can volunteer for appointment. [4] At the end of a co-chair's term, the WG will decide by consensus who is appointed to the available co-chair position. In the event of a tie, the consensus tied candidates will draw lots. [5] The WG may decide by consensus to remove a WG co-chair at any time. [6] Consensus will be determined on the DNS WG mailing list. The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair who is the subject of that consensus judgement. [7] Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final.
Re: [dns-wg] RIPE NCC DNSSEC trust anchors
On 18 Nov 2014, at 15:51, Rob Evans wrote: > I certainly don't want the RIPE community to be associated with theripen.cc > domain, but if the RIPE NCC wants to use it (or at least reserve it), we > might think it's a mistake, but it's the company's mistake to make unless we > get into a level of micro-management that I think we, as a community, > delegate to the Board. I'm sort of in agreement with that Rob. Experiments and trying new stuff with other name spaces are fine, provided there's a clear understanding of what's going on and why. There also needs to be a clear exit or migration strategy. Cruft can't be allowed to just stagnate indefinitely or accumulate even more cruft along the way. There should be clear milestones around future go/no go decisions. There should be some reporting about all of the above, either to the DNS or NCC Services WG - whatever of the two is most appropriate. None of that has been done for ripe.int, ripen.cc and their injection into DLV. Well OK, nothing apart from the accummulation of cruft. My key question the has yet to be answered remains "why is the NCC putting keying material into ripe.int into DLV when the domain does not appear to be used and the case for continued DLV registration is vague to non-existent?". I would like some hard data about that. That said, I think it is reasonable for the community to decide "ripe.foo is no longer used or needed. Please let it die.".
Re: [dns-wg] RIPE NCC DNSSEC trust anchors
On 18 Nov 2014, at 14:59, Rob Evans wrote: > If they want to sit on a domain that bears a resemblance to the company > identity, I'll leave that up to them... That way lies madness: ripe.$TLD-of-the-week. IMO one domain name is enough. If someone can make a convincing case to use more than that or why ripe.whatever can achieve something not possible with ripe.net, please speak up.
Re: [dns-wg] RIPE NCC DNSSEC trust anchors
On 18 Nov 2014, at 14:50, Jorma Mellin wrote: > I remember the day when ripe.net -domain was unreachable because of > failure to renew it. The hassle was pretty big, as it took a long time to > convince the domain registry (at U.S) to understand that "yes, we really need > this at european territory”. This must have happened a *long* time ago and I am sure the NCC now has robust procedures in place to ensure domain names get renewed in good time. Though it might be worth asking about that. > This was the primary reason to register .int as well. The origins of ripe.int are unclear and it would be good to know why it was done. > I have no clue have the situation changed about this but if not why to get rid > of the backup? It's not a backup: gromit% dig ripe.int mx ... ;; ANSWER SECTION: ripe.int. 21600 IN MX 250 kaka.ripe.net. ripe.int. 21600 IN MX 200 koko.ripe.net. gromit% dig www.ripe.int ... ;; ANSWER SECTION: www.ripe.int. 21600 IN CNAME www.ripe.net. FWIW I have never seen a URL or email address containing has ripe.int.
Re: [dns-wg] RIPE NCC DNSSEC trust anchors
On 18 Nov 2014, at 14:59, Rob Evans wrote: > Isn't this really, as Romeo puts it, "an operational decision" for the RIPE > NCC? Er no. It's a decision for the community which domain names it needs or wants to use to identify itself. After all the NCC should respond to the needs of the RIPE community and the NCC membership. It's an operational matter for the NCC how to register those domain names, which registrar(s) to use, provision the names, choose the name servers, etc, etc. YMMV. Nobody here knew about ripe.int until recently and it doesn't seem to be used. Since it does not appear to have community support -- for some definition of both community and support -- the case for retaining the domain is poor at best.
Re: [dns-wg] RIPE NCC DNSSEC trust anchors
On 17 Nov 2014, at 15:49, Romeo Zwart wrote: > 1/ While the RIPE NCC controls 62/8, the delegations under it are not > necessarily under our control. Specifically the /24 mentioned in the > original post is part of 62.76/16, which is delegated to the Russian > Institute for Public Networks (RIPN). RIPN does not sign its zones, > therefore we have been using an out of band mechanism. Surely sticking this in DLV should be a decision for the holder of that /24 and not the NCC? Though it seems 62.76.151/24 supports an anycast instance of K. Hmmm... If that's the case, it opens even more questions. > 2/ The RIPE NCC has been publishing this key material out of band for > historical reasons. If there is a consensus in the WG that this is no > longer needed, or even undesirable, we are happy to phase out the use of > the DLV. Glad to hear that. Though the WG has still to decide about this. > 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are > currently not using ripe.int, other than by redirecting to ripe.net. If > the community advises the RIPE NCC to request IANA to sign .int, we can > spend some effort on this, but we'd like to follow up on this separately. I am not sure a request IANA to sign .int is worth doing any time soon. Signing .int will almost certainly be blocked by layer 9+ issues until long after the dust has settled on the NTIA-IANA transition. Besides, the few voices on this thread that have mentioned ripe.int appear to be asking for it to be removed, not for it to be signed in a signed TLD. I think the WG needs to reach consensus on what should be done here. > 4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it > and we are not planning any future use. Releasing the domain is an > operational decision that we may take in the future. Just kill it! IMO the domain should get removed from DLV as soon as it is prudent to do so: which probably means immediately. ripen.cc can die on its renewal date. Though these too should be consensus decisions for the WG. The NCC needs to have a procedure to review its DLV entries -- report to the WG once a year? -- and an exit strategy for the cruft^W names and keys it has there. It seems silly to be co-ordinating a key rollover for DLV material that probably isn't getting used for domain names that aren't getting used.
Re: [dns-wg] RIPE NCC DNSSEC trust anchors
On 18 Nov 2014, at 08:22, Romeo Zwart wrote: > There was an explicit suggestion on the list about using ripe.int as a > 'lever' to get .int signed, hence my comment. I think you are mistaken Romeo. Peter asked some meta issues on policy and procedural matters around the signing of .int: ie who is the governing body for the TLD and needs to be done to get them to sign it. He did not ask for the TLD to be signed. AFAICT nobody on the list has explicitly asked to get .int signed. Anyways, this is somewhat off-point. Although it would be good to know the answer to those questions, it belongs in another thread. Could we please return to the matter at hand: [1] What DNS/web/whatever traffic goes to ripen.cc? If it's low, can this be killed? When? [2] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? [3] What DNS/web/whatever traffic goes to ripe.int? If it's low, can this be killed? When? [4] When was the utility of its DLV entry last assessed? What's the exit strategy for that? How often does its DLV name get validated and by whom/what? [5] What's the NCC's overall exit strategy for DLV? FWIW I have still not seen any valid reason or meaningful daya explaining why the NCC still uses DLV.
Re: [dns-wg] RIPE NCC DNSSEC trust anchors
On 14 Nov 2014, at 10:19, Tony Finch wrote: > Peter Koch wrote: >> >> I'd rather not see the RIPE NCC further endorse the DLV technology and >> service by continuing to submit key material there. DLV was meant as a >> temporary deployment aid and might have been a good idea at its time. > > We would like to stop using the DLV but some of our reverse zones cannot > be validated without it because JANET has only signed ac.uk. Although you know I very much want to see DLV killed, that is not the matter at hand. What we are discussing is the NCC's use of DLV for stuff that either has no reason to be there or for domain names that have little or no relevance/use to the NCC and the community. I would like to keep the focus on that. In that context, Peter's comments go to the heart of the matter. There's a meta-issue too. Some years ago, long before the root was signed, the NCC shoved stuff into DLV as a short-term kludge. It's continuing to do that even though there seems to be no good reason for doing that any more. So have the NCC reviewed its processes for DLV population or assessed whether this activity is necessary or worthwhile? If you wish to continue discussing DLV's worth and relevance to the local problem you mentioned, go ahead. But please do so on another thread.
[dns-wg] oversight of .int
On 13 Nov 2014, at 20:50, Peter Koch wrote: > So, again: who is to be convinced to make INT signed? Runs away screaming... The politics around .int and its oversight are... well... interesting. It might be inadvisable to dive into that while the IANA arrangements are in flux.
