Re: [dns-wg] RIPE NCC DNSSEC trust anchors

[Peter Koch]

Anand, all,

On Thu, Nov 13, 2014 at 03:54:54PM +0100, Anand Buddhdev wrote:

> 151.76.62.in-addr.arpa
> ripe.int
> ripen.cc

> On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys
> and added the new trust anchors for these three zones to the ISC
> DLV TAR. Because we believe manual configuration of trust anchors is
> very rare these days, we are taking this opportunity to stop publishing
> trust anchors for these three zones on our website. The trust anchors
> remain available via the ISC DLV TAR. Of course, as soon as we are

Thanks for this note.  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.  Nowadays, I consider it detrimental to
deployment because it complicates matters for everybody deciding
to actually validate (getting those figures up is the real challenge).

Manually configured trust anchors aren't the ultimate wisdom, either,
so with regard to the three zones above I wonder

a) what is the actual benefit of extra steps for publishing the KSK out
   of band (continued signing obviously stremlines processes)?

b) what steps could be taken to get the TA published the "natural" way?
   This is probably most interesting for the INT TLD, given all the current
   transition debate.

Regards,
  Peter (no hat)

[dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors]

[Peter Koch]

On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote:

> On Nov 13, 2014, at 8:05 AM, Doug Barton  wrote:
> > The NCC should simply release ripe.int, as the historical reasons for
> > it no longer apply. (FWIW, same goes for apnic.int. None of the other
> > RIRs have similar domains.)
> 
> +1

this might be the exact wrong point in time.  The NCC likely does not fulfill
the eligibility criterie laid out in ,
but obviously the registrations in INT benefit from a genaral protection
of confidence.  Also, the 'policy' document linked above does not provide
for a revocation mechanism.

So, there is a registrant in INT interested in having key material published.
What does it take to get INT sigend? What is the governing body? The 'policy'
document bases itself on RFC 1591 but also says "The IANA no longer _grants_
.int domain names [...]". While this particular issue is out of scope, the
text may be read as if "the IANA" was acting with its own authority rather
than being a registry operator bound by some policy set by the competent body.
So, again: who is to be convinced to make INT signed?

-Peter

Re: [dns-wg] {Use of} the INT TLD {by the NCC and others} [Re: RIPE NCC DNSSEC trust anchors]

[Peter Koch]

Hi David,

On Thu, Nov 13, 2014 at 11:21:00AM -1000, David Conrad wrote:

> Or, given the IANA Functions transition, the exact right point in time if 
> people want to avoid a pointless political food fight.

well, we hopefully agree that 'unasking' the questions isn't the right
thing to do.  Whether ripe.int is OK to continue to exist is a detail that
only triggered the subsequent questions, that being the 'registration policy'
for the INT TLD and the governing body for other decisions (like the deployment
of DNSSEC, the DPS, choice of name server operators).  We don't need responses
instatntly (although you, Kim, and Barbara were helpful in providing those),
but the questions need to be listed.

> What's a "general protection of confidence"?

That's my, apparently failed, attempt to translate a legalese clause from
my mother tongue into English legalese with the help of this Internet.
It should have described a general priciple that anyone is entitled to
maintain their status, provided they got there bona fide and before
rules existed.

> > Also, the 'policy' document linked above does not provide
> > for a revocation mechanism.

> If an entity does not meet the documented policy criteria, then it should not 
> be in the zone. However, IANA does not unilaterally remove zones. 
> Traditionally, the entity simply says "please remove my entry".  Are you 
> recommending RIPE knowingly and intentionally violate a documented policy?

Even if the NCC (or any other entity) did (or "do") not fulfill today's 
eligibility
criteria, the current policy does not include a revocation clause (see above).
Even if it did, the policy at the time of registration would prevail and unless 
that
had had a clause submitting the registrant to future changes, there'd be no 
handle.
So, my response to the question is "no", because there is no "documented 
policy" to
"knowingly and intentionally violate".
Whether the registrant gives up the domain name is a different issue.

> As mentioned, management of .INT is part of the IANA Functions contract, 
> specifically section C.2.9.4 of 
> http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf.

Thanks.

> Um, yeah.  1591 also says "Second level names in INT are registered by the 
> PVM at ISI.EDU." Good luck with that. I personally find the cherry picking of 
> RFC 1591 quite fascinating. The Internet has changed a bit since 1994 and it 
> has never been clear to me that relying on that document in contravention to 
> existing evolved policies makes a lot of sense.

For obvious reasons I will refrain from a discussion re: the applicability of 
RFC 1591
in the general case. For the INT TLD I do not see any cherry picking in action. 
I had only quoted
from the IANA's website.

> Until the IANA Functions transition, NTIA.  After the transition: that's an 
> interesting question.

Thanks, that was one important point to raise.

Regards,
  Peter

Re: [dns-wg] RIPE NCC DNSSEC trust anchors

[Peter Koch]

On Tue, Nov 18, 2014 at 11:16:19AM +, Niall O'Reilly wrote:

>   I'm reading that as a call from one of the co-chairs for (more)
>   voices from the WG, so here's mine.
> 
>   Let's have RIPE.INT removed.

this isn't f*cebook. As a co-chair of this wg I doubt it is reasonable
for the WG to micro manage the NCC in what domain names and which TLD(s)
it uses. It is also not clear to me why the DNS WG would be formally competent
w.r.t. the subject matter.

> > > 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.
> 
>   Let's have RIPEN.CC removed also.

Again, I doubt that a voting is helpful here.  No matter what, even
if the NCC gave up on the use of "ripen.cc", releasing the domain name
is probably a bad idea.

Also, simply removing those domains without a signed parent doesn't
ultimately help solving the DLV issue.  Why can't a zone be signed
(for reasons of symmetry or streamlined processes) without the TA
being published?

-Peter

Re: [dns-wg] reminder about the WG Chair appointment process

[Peter Koch]

On Tue, Nov 25, 2014 at 12:09:25PM +, Jim Reid 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. A co-chair cannot serve more than 2 consecutive terms.

as was mentioned during the session, not all of the co-chairs agreed on
this text. Let me explain my dissent:  iff (sic!) we accept the 'as lightweight
as possible' axiom for the design, the term limit seems redundant to me
based on the assumption that common sense should prevail. Change and rotation
is already taken care of by the useful term length and explicit appointment
procedures.  Rest assured this is not myself looking forward to a lifetime 
sentence.

> [5] The WG may decide by consensus to remove a WG co-chair at any time.

Last time this became imminent in another WG, a lynch mob was orchestrated
kind of along these lines. The result was right, just that due process
suffered "a bit".  Therefore I think this aspect is underspecified and
would benefit from replacement by what the WG chair task force had come up with.
Of course, that's not specific to this particular WG.

-Peter (no hat)

Re: [dns-wg] yet another heave on the WG Chair selection procedure

[Peter Koch]

Jim, all,

On Mon, Jan 05, 2015 at 05:33:48PM +, Jim Reid wrote:

> 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.

I didn't quite say it that way and definitely not ex officio.

What I tried was hold you/the proposal to its design criteria,
first and foremost being "minimalist" or lean or lightweight,
in the spirit of good protocol design - it's ready when yoy can't delete
anything further.  To that extent, the limits are superfluous
because common sense will prevail.
Should they be deemed necessary, there are probably bigger fish to fry,
e.g., the impeachment clause.  

-Peter

[dns-wg] Call for input for the RIPE 70 DNS WG meeting

[Peter Koch]

Dear WG,

the meeting plan for RIPE 70 
in Amsterdam shows a 90 minute slot on Thursday (14 May) for the DNS WG.

This is the usual call for input, presentations, suggestions for discussions.
Please let me or us (== ) know what you'd like
to present, share, or talk about.

Our goal is to have a draft agenda ready by the end of February.

Thanks,
   Peter

[dns-wg] Draft Agenda for DNS WG meeting at RIPE 70, Amsterdam

[Peter Koch]

Dear DNS WG,

the next RIPE meeting, RIPE 70 in Amsterdam, is eight weeks away.
The DNS WG has a single slot on Thursday morning this time.
Please find below the first draft agenda for our meeting.

We are pretty much filling our assigned time already, but please do not
hesitate to comment here or directly to your co-chairs at 
.

-
RIPE 70 DNS WG  14 May 2015 09:00 - 10:30
-

A   Administrivia
WG chairs

B   RIPE NCC report
Anand Buddhdev, RIPE NCC

C   Reports from abroad (IETF, ICANN, OARC, ...)
N.N.

D   Knot DNS 2.0 - status update - a new major version introducing updated 
DNSSEC
Jan Vcelák, CZ.NIC

E   Knot Resolver - more thorough introduction
Marek Vavrusa, CZ.NIC

F   Network-Tuning for DNS zone transfers in (lossy) Long Fat Networks
Marco Prause, DENIC

G   DLV sunset
Vicky Risk, ISC

-

Best regards,
Peter

Re: [dns-wg] Draft Agenda for DNS WG meeting at RIPE 70, Amsterdam

[Peter Koch]

Dear DNS WG,


> We are pretty much filling our assigned time already, but please do not
> hesitate to comment here or directly to your co-chairs at 
> .

there is good news that is not yet reflected by the agenda at
, but already
visible at : we have
another 90 minute slot available, Wednesday morning.  The wg chairs will
work with the presenters (and those waiting) on the exact scheduling,
so some of the talks listed for Thu will end up on Wed.
Thanks everybody for contributing to the agenda so early.

Regards,
  Peter

[dns-wg] final DNS WG agenda for Wed & Thu

[Peter Koch]

Dear WG,

after some careful shifting and resizing, here's now the final agenda
for our two DNS WG sessions on Wednesday and Thursday:

-
RIPE 70 DNS WG  Wed 13 May 2015 09:00 - 10:30
-

A   Administrivia
WG chairs

B   RIPE NCC report
Anand Buddhdev, RIPE NCC

C   IETF report

D   Knot DNS 2.0 - status update - a new major version introducing updated 
DNSSEC
Jan V#elák, CZ.NIC

E   Test cases for validating a DNS delegation - a step towards a best 
practice
Sandoche Balakrichenan, Mats Dufberg

F   DNSSEC ECDSA algorithm use and acceptance
Olafur Gudmundsson, Cloudflare

G   DLV sunset
Jim Martin, ISC

-
RIPE 70 DNS WG  Thu 14 May 2015 09:00 - 10:30
-

H   Knot Resolver - more thorough introduction
Marek Vavru#a, CZ.NIC

I   Network-Tuning for DNS zone transfers in (lossy) Long Fat Networks
Marco Prause, DENIC

J   Root Zone KSK Rollover
Ed Lewis, ICANN

K   An enlightening talk
N.N.

Z   Wrapup
Chairs

-

-Peter

Re: [dns-wg] RIPE NCC domain registrations

[Peter Koch]

Hi,



On Tue, Jun 30, 2015 at 02:30:39PM +0200, Romeo Zwart wrote:

> Some of these domains were only registered as a "protection"
> mechanism, which was considered good practice at the time.

and probably still is?  There's probably no actual value in
keeping them for a use, but once they are relaesed, they might
be "parked' in shady places of town.  So unless the internal
procedural cost is going to hurt - just keep'em.

> ripe.int

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.

-Peter

Re: [dns-wg] Last Call for presentations and Draft programme for RIPE 71

[Peter Koch]

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.

-Peter

Re: [dns-wg] Co-chair appointment process: 2015 call for volunteers/nominees

[Peter Koch]

Dear WG,

On Mon, Oct 12, 2015 at 01:42:25PM +0100, Jim Reid wrote:

> 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.

so that you do not wonder we'd add a fourth co-chair in violation of the
rules, I'd like to let you know that taking advantage of the absence of
defined terms for the transition I have decided to give it a start and
vacate my seat.  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.

So, volunteers more than welcome!

Best Regards,
Peter

Re: [dns-wg] Yeti DNS and the RIPE NCC

[Peter Koch]

On Tue, May 24, 2016 at 02:41:45PM +0200, Shane Kerr wrote:

> the RIPE NCC would be awesome in this capacity, given their unique role
> in the DNS world (they are the only RIR who is also a root operator,
> plus they do a lot of work supporting various ccTLD). Personally I

indeed the NCC's participation would add certain amounts of weight,
however the more important "currency" would be research contribution.
Could you please elaborate on your expectations in this regard?

-Peter

Re: [dns-wg] Yeti DNS and the RIPE NCC

[Peter Koch]

On Wed, May 25, 2016 at 11:50:15AM +0200, João Damas wrote:
> Actually Jim, first comes the poll of the community to see if this fits, 
> later comes what you suggest, if the community decides to ask the RIPE NCC to 
> look into it, or have we become the Ministry of IP?

this member of the community considers the request underspecified to offer
an informed opinion.  I do not consider running alternative root name servers
a "good fit" - everything else I do not know.  Clarification appreciated.

-Peter

[dns-wg] nomination for DNS WG co-chair

[Peter Koch]

Dear DNS WG,

for the vacant position as a DNS WG co-chair I would like to nominate
Ralf Weber  .

Ralf has been an active and thoughtful member of the DNS community
within RIPE and beyond for a longer while.  He is familiar with various
roles in the DNS, be that vendor, operator, registry or registrar. And of
course, he's on this list and will join the thread to respond to
questions the group might have.

-Peter

Re: [dns-wg] Deletion of ns-v6.ripe.net

[Peter Koch]

On Tue, Apr 24, 2018 at 10:33:16PM +0200, Gert Doering wrote:

> Thus: have ns-v6.ripe.net point to a *new* server, which will then
> be able to notice "oh, people have something in their configuration,
> somewhere, which references ns-v6.ripe.net".

will this shed only collect the bikes or also release them and if so,
what type of bikes will be available to those asking?

-Peter

Re: [dns-wg] SLD .gov.* within european countries

[Peter Koch]

On Wed, Jun 13, 2018 at 10:59:08PM +0200, Florian Weimer wrote:

> bund.de is used by the German federal government.  I'm not aware of
> any non-federal users.

this is true, but the name is in no way special. It is just a registration
like any other, DE does not have any 'structure' at the second level (and
essentially never had).
Also, not all government entities use domains under 'bund.de', which would be an
orthogonal policy perspective.
I'm really curious what this little survey is really up to.

-Peter

Re: [dns-wg] SLD .gov.* within european countries

[Peter Koch]

Antonio, all,

On Thu, Jun 14, 2018 at 04:03:23PM +0200, Antonio Prado wrote:

> 'the second level domain (SLD) ".gov", when used, identifies only the
> administrations within the EU and the USA (as the first level) central
> government, with the exception of the United Kingdom, and not without
> distinction any central and local public administration including
> educational institutions (for which the SLD ".edu" is used) as is the
> case today in Italy.'

thanks for sharing this background.

Colleagues within CENTR (representing ccTLDs within Europe, but also
beyond as shown below) were kind enough to provide first hand information
for the following list of TLDs:

-
BG  In Bulgaria the e-government law says that government agencies should 
use sub domains of gov.bg
CH  gov.ch is reserved exclusively for Swiss authorities and registered by 
the Federal Chancellery. However, it is the SLD admin.ch that is used for the 
websites of Swiss authorities. admin.ch on the other hand is not exclusively 
reserved for Swiss authorities.
CZ  gov.cz domain is registered for Ministry of the Interior of the Czech 
Republic and used as the information portal of public administration, as well 
as the third-level names are created and used by some of public authorities.
DE  has no predefined structure at the second level. gov.de is registered, 
but unrelated to government.
DK  the registrant of gov.dk is the Danish state, but it does not seem to 
be in use as such. Most governmental authorities prefer to have their own 
specific .dk domain name.
EE  The gov.ee is used by Estonian Government but it is not reserved 
exclusively for them. At .ee we don't reserve any domain names for central 
government. We have a list of reserved names for the respective local 
governments - (see regulation here 
).
ES  We have an SLD "gob.es", reserved to Government (central, regional or 
local) More precisely, art. 10.d of the 2005 National Plan on domain names 
under ".es" reserves ".gob.es" to "Spanish Public Administrations and the 
Public Bodies responsible to them, including any branches, agencies and units 
thereof." See 
http://www.dominios.es/dominios/sites/dominios/files/normativa_en1.pdf
EU  The "gov.eu" is on the list of reserved name by the EU institutions, 
and not in use
FI  gov.fi is used by Finnish Government but it is not reserved exclusively 
for them. At .fi we don't reserve any domain names for central government (or 
anyone else).
FR  I confirm that .gouv.fr is reserved to the French government. Although 
it is not clearly established that it is restricted to the "central" 
government, each registration requires the approval of the Government 
Information Service.
IE  At .ie, gov.ie is reserved for the Irish Government.  In practice, it 
appears to be used by 'central' government departments only.
IL  The SLD Gov.il is managed since the 90's by the e-GOV unit at PM 
office.  Basically, domains under GOV.il are for government bodies only 
(including parliament, central bank, regulators etc.). Local municipalities can 
register under muni.il (with 2 exceptions TelAviv.gov.il and Jerusalem.gov. Il 
for historic reasons).
JP  I hope information about non-EU ccTLD helps a bit: .go.jp is a space 
strictly for central government.  .lg.jp is a space strictly for local 
government
LT  gov.lt domain was created in 2004. The use of gov.lt domain is 
dedicated to the state institutions of the Republic of Lithuania at various 
levels of central, counties, districts and local authorities administration 
levels.
LU  gov.lu is registered by the government but is, as far as we can see, 
not used as to create third-level names
LV  .gov.lv is designated to government and a local government or other 
public persons established by law. Registrations in this subdomain are handled 
by the Latvia State Radio and Television Centre (LVRTC) according to Regulation 
of Cabinet of Ministers "Procedures by which Institutions Place Information on 
the Internet".
NL  The domain name gov.nl was originally a reserved domain name, but in 
2005 we gave our government the opportunity to register the domain name. They 
did and they seem to use it for a redirect to their main website.  As far as we 
know, there is no specific applicable law about the use of this domain name and 
the registrant is contractual free to use the domain name as he pleases.
PL  The .gov.pl is  used by central government and other governmental 
organisations according to the officially announced list.
PT  In Portugal, domain names under .gov.pt may be registered only by 
entities which are part of the Government structure of the Portuguese Republic
RO  I confirm that gov.ro and guv.ro are reserved for Romanian government.
SE  Gov.se is registe

Re: [dns-wg] Volunteer list for RIPE DNS working group chair

[Peter Koch]

Dave, all,

On Thu, Oct 15, 2020 at 05:47:26PM -0400, Dave Knight wrote:

> 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
> 
> Having observed that in all of the three above cases the first person to 
> respond to the call for nominations was selected to be a co-chair we changed 
> our interpretation of the process and asked that future nominations be sent 
> to the wg chairs to be released en masse in order to preclude a first 
> responder advantage.
> 
> Oct 2018, RIPE 77  Dave Knight was the only volunteer and is serving a second 
> and final three year term
> Oct 2019, RIPE 79  Shane Kerr was the only volunteer and is serving a second 
> and final three year term
> Oct 2020, RIPE 81  Joao Damas is the only volunteer

thanks a lot for adding data and thereby getting the history straight and the 
current rules on the table.
Also appreaciate the learning from take one.

I'd just add that in the first round none of you three was really new (feature) 
and two, IIRC, weren't
even new to the chair role (data point).

The current trio has done a very good job, IMHO, especially by adding the 
regular zoom sessions during the course
of the year.  Other than that, the WG (and that might apply to some other RIPE 
WGs more or less) is little
more(*) than a specialized track in the overall RIPE program.  Traffic on the 
list is low (I know I'm
showing my age by even mentioning the mailing list as an indicator) and 
dominated by this very thread,
meeting announcements and announcements of RIPE Labs articles, usually with 
little subsequent discussion.
That's OK and in particular I don't think that's a fault and even less a fault 
of the chairs, but it
could put importance and emotions (around voting or acclamation) a bit into 
perspective.

The (*) little more is the function as a resonance chamber (not to be confused 
with echo chamber)
for the RIPE NCC's DNS activities, of course.

Best,
  Peter

Re: [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations

[Peter Koch]

On Thu, Dec 02, 2021 at 01:11:17PM +0100, Jeroen Massar via dns-wg wrote:

> > Same. I support this, and I also support lowering NS even further, even
> > to 3600.
> 
> Another Aye from me on DS & NS to TTL 3600.

I'm slightly reminded of the solar activity cycle by another instance of
a race to low TTLs, to be followed by another train of thought recommending
high (infrastructure RRSet) TTLs in favour of resilience.

No objection to Anand's proposal at all, but maybe there are limits to 
committees
finding "optimum" numbers, especially under the impression of a prominent 
incident.

-Peter

-- 

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