[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-ns-revalidation-07.txt

[Willem Toorop]

Thanks for the reference Gio (and Raffaele who also pointed this out to me),

We're citing your paper now in our work-in-progress copy (see 
https://github.com/shuque/ns-revalidation/commit/5e52689 ), so it will 
be part of the next version.


-- Willem

Op 08-07-2024 om 12:55 schreef Giovane C. M. Moura:

Hi Willem,


We've got a peer-reviewed reference[0]  that can help back up some of 
the claims in the draft.




```
2.  Motivation

   There is wide variability in the behavior of deployed DNS resolvers
   today with respect to how they process delegation records. Some of
   them prefer the parent NS set, some prefer the child, and for others,
   what they preferentially cache depends on the dynamic state of
   queries and responses they have processed.

```

Section 4 in [0] covers a bunch of such cases with Ripe Atlas, and we 
see just that, and section 5 evaluate some resolver software 
individually. In short: it backs up what you say


```
The delegation NS RRset at the bottom of the parent zone and the apex
   NS RRset in the child zone are unsynchronized in the DNS protocol.
   Section 4.2.2 of [RFC1034] says "The administrators of both zones
   should insure that the NS and glue RRs which mark both sides of the
   cut are consistent and remain so.
```

We found 13M of domains having parent/child NSSet inconsistency, from 
.com, .org, and .net, which amounts to 8% of the total.



thanks,

/giovane

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org


OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-ns-revalidation-07.txt

[Willem Toorop]

Dear all,

This latest version 07 of draft-ietf-dnsop-ns-revalidation has all 
feedback from DNS Directorate early review, the mailing list, the room 
and hallways, since it was presented at the last IETF119 in Brisbane, 
processed. The authors believe the draft is ready for working group last 
call.


Changes in response to DNS Directorate review:

 * Section 3 is now formatted as paragraphs.
 * RFC 2119 keywords are used throughout the document
 * Explain what to do with auth answer with NS in authority section

From feedback from the list:

 * Corrected error in security section

From feedback from the room and hallways:

 * Send DNS Error report on NS set mismatch is detected
 * ZONEMD also adds DNSSEC protection to infrastructure data
 * A paragraph on parent only resolvers, how they are less vulnerable
   to some cache poisoning attacks, but also do not benefit from DNSSEC
   protection against query redirection
 * A paragraph on implementations wishing to consider to limited
   revalidation to the parts of the domain name space where it counts
   the most.
 * Added an Implementation status section


 Doorgestuurd bericht 
Onderwerp: 	New Version Notification for 
draft-ietf-dnsop-ns-revalidation-07.txt

Datum:  Mon, 08 Jul 2024 01:45:12 -0700
Van:internet-dra...@ietf.org
Aan: 	Paul Vixie , Shumon Huque , 
Willem Toorop 




A new version of Internet-Draft draft-ietf-dnsop-ns-revalidation-07.txt has
been successfully submitted by Willem Toorop and posted to the
IETF repository.

Name: draft-ietf-dnsop-ns-revalidation
Revision: 07
Title: Delegation Revalidation by DNS Resolvers
Date: 2024-07-08
Group: dnsop
Pages: 13
URL: https://www.ietf.org/archive/id/draft-ietf-dnsop-ns-revalidation-07.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-ns-revalidation-07


Abstract:

This document recommends improved DNS [RFC1034] [RFC1035] resolver
behavior with respect to the processing of Name Server (NS) resource
record (RR) sets (RRsets) during iterative resolution. When
following a referral response from an authoritative server to a child
zone, DNS resolvers should explicitly query the authoritative NS
RRset at the apex of the child zone and cache this in preference to
the NS RRset on the parent side of the zone cut. The (A and )
address RRsets in the additional section from referral responses and
authoritative NS answers for the names of the NS RRset, should
similarly be re-queried and used to replace the entries with the
lower trustworthiness ranking in cache. Resolvers should also
periodically revalidate the child delegation by re-querying the
parent zone at the expiration of the TTL of the parent side NS RRset.



The IETF Secretariat




OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Ext] [DNSOP]Requesting final comments on draft-ietf-dnsop-rfc8109bis

[Willem Toorop]

Sorry, I noticed my first comment was particularly deformed. Below that 
first comment corrected into something (hopefully) more readable.


Op 07-06-2024 om 10:33 schreef jab...@strandkip.nl:

More substantially, this section describes a series of vulnerabilities that would be 
mitigated by signing the ROOT-SERVERS.NET  zone.
Unfortunately not. A signed root-servers.net zone has the potential to 
be mitigate those vulnerabilities, but at the time of writing it would 
have very limited impact (see: 
https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf 
)


OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Ext] [DNSOP]Requesting final comments on draft-ietf-dnsop-rfc8109bis

[Willem Toorop]

Hi Joe,

Comments inline.

Op 07-06-2024 om 10:33 schreef jab...@strandkip.nl:

Hi Tim, all,

On Jun 7, 2024, at 01:11, Tim Wicinski  wrote:


On Wed, Jun 5, 2024 at 12:28 PM Paul Hoffman  wrote:


Tim jumped the gun by about an hour: we just submitted the -05. It incorporates 
the suggested text from below; you can see the diff at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05

I am guilty as charged.  But our comment on we would like people to review the 
changes.

3.3 DNSSEC with Priming Queries

I know perfectly well what "the root NS RRset" is, but it seems like it could be made a little more clear 
with only a small change as "the apex NS RRset in the root zone", "root zone" being a well-defined 
term of art whereas "root" as adjective being a bit vague.

More substantially, this section describes a series of vulnerabilities that would be 
mitigated by signing the ROOT-SERVERS.NET  zone.
Unfortunately not. I would say that have the potential to be mitigated 
by a signed root-servers.net one, but at the time of writing, a signed  
root-servers.net zone would have impact. (see: 
https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf 
)

However, it does not mention that a validating resolver that received a rogue 
response from an imposter root server has the eventual opportunity to discard signed 
RRSets whose signatures do not validate; by not mentioning this there is perhaps some 
danger that a casual reader would infer a greater overall vulnerability resulting 
from an unsigned ROOT-SERVERS.NET  zone than in fact 
exists.
Agree, we could mention the opportunity. But it requires changes in 
resolver software behavior (see again the above quoted report).

Including signed RRSets from the ROOT-SERVERS.NET  
zone in the priming response would result in larger responses,
Signed root server addresses included with the priming response cannot 
help. A resolver cannot determine whether those are authoritatively 
present in the root zone or not (and if they are not they can be 
included without signatures, so an adversary can always replace signed 
root server addresses with spoofed addresses without signatures; see 
section "DNSSEC signed root server addresses in the priming response" in 
the above quoted report: 
https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf#h.tb7mwc7hrt18 
)

to which in the past there has been some sensitivity. Since a priming query with DO=1 
definitely has EDNS(0) as an option this is not a show stopper, but if the previous 
sensitivites around all of this are no longer a concern I think it would make sense 
to say so explicitly when speculating about future signatures in that zone.  The 
chain of trust from a root zone trust anchor through a signed delegation to NET and 
thence to ROOT-SERVERS.NET  would also deserve some 
scrutiny from the perspective of a priming response which is presumably often landing 
on an empty cache; the ability to validate those signatures requires queries to be 
sent to as-yet untrusted root servers. It seems odd not to mention this as something 
that would need work, given the depth of the other text that is included.
Agree, this needs work. I am working on text within the delegation 
revalidation draft that explicitly addresses this. Perhaps it should be 
referenced from here (but I steel need to update the text and submit the 
new version).

The final paragraph makes a reference to a naming scheme, presumably referring to the names 
chosen for root servers (but that could be more clear). The RSSAC wrote quite a large document 
about this stuff and I certainly don't have all of their conclusions swapped in, but thanks to 
the late Bill Manning's flash of insight the current scheme features a high degree of name 
compression already and reducing the single label 
"ROOT-SERVERS.NET" to something smaller is not going 
to substantially reduce the size of the priming response.


I assume you are referring to RSSAC028. Note that we also did an 
extensive evaluation of those naming schemes and have written that all 
down in another report: 
https://www.icann.org/en/system/files/files/rssac028-implementation-study-report-27sep23-en.pdf



It feels like part of the solution space here is to consider root-server names that live 
in the root zone and not in a child zone, which is a different consderation from the 
naming scheme. Mainly this paragraph reads like a throwaway comment that doesn't include 
enough depth to be useful. It should at least say something along the lines of "this 
is complicated".


Unfortunately, as I mentioned above, signed root server addresses 
included with the priming response cannot help. However, revalidating 
the root server 

Re: [DNSOP] Comment on Ranking data

[Willem Toorop]

Thank you Fujiwara-san,

I agree that some data should be discarded depending on use case.

I also think the draft should be more explicit on what data is actually 
meant in those ranks (i.e. referral responses with "B: Data from the 
authority section of a non-authoritative answer, Additional information 
from non-authoritative answers." etc.) and I also agree that we should 
remove the ranks which are currently meaningless and would not occur in 
practice (like the BB ranks in the list). I furthermore agree with your 
recommendation for DNS software to discard all data which is not in the 
list.


I am still contemplating whether or not the list is too generalized with 
respect to roles or functions in the DNS ecosystem (Authoritative, 
Recursive Resolver, Forwarder & Stub). Different functions get the data 
from different places, but since software may be a mix of those 
different functions, it does make sense to me to put an order to the 
preference of the data depending on where it came from in a single list.


Even with an authoritative only name server without cache, you could 
still say that data acquired over a zone transfer should be preferred 
over data read from a zone file (that may be just loaded to initialize a 
secondary name server). The other ranks in the list would then simply be 
inapplicable.


I acknowledge that it is better to accept DNSSEC validated secure data 
only when it makes sense in the context of the work a DNS software is 
doing instead of blindly trusting validated data. I will rephrase that 
in the draft. But that aside, why would it be bad to blindly trust 
DNSSEC validated secure data? What do others think?


Op 05-04-2024 om 09:28 schreef Kazunori Fujiwara:

dnsop WG,

RFC 2181 Section 5.4.1 Ranking data should be obsoleted.
The "Raning data" draft (draft-toorop-dnsop-ranking-dns-data-00)
defines each data's ranking and importance.
However, some of the data should be discarded depending on the use cases.

We have four DNS functions: Authoritative, Recursive Resolver, Forwarder, Stub.

Some implementations have multiple functions.  For example, some
recursive resolvers have "split-holizon" and "local zones" functions.

Both "split-holizen" and "local zones" can be treated as a function
where descendants of a specified domain name behave as an authoritative
server rather than a recursive server.

Authoritative (only) servers:

   Authoritative-only servers SHOULD answer zone data from a
   single source (for example, zone file, zone transfer, other database),
   so rankings SHOULD not be used to replace data.

   "BBB: Occluded data" SHOULD be discarded.
 (at least when responding to queries)

Recursive (only) resolvers:

   They don't have "AAA: zone file" / "AA: Data from a zone transfer".

   "CCC: Names and addresses for the root servers from a hints file"
or "CC: built into resolver software" SHOULD be used for the priming only.

   The data that can be returned to the stub resolver as a name
   resolution result is "A: The authoritative data included in the answer
   section of an authoritative reply" only.

   "A-: Data from the authority section of an authoritative answer."
  NXDOMAIN response contains a SOA RR in the autority section.
  Some authoritative servers add NS RRSet in the authority section.
  I want to discard the NS RR set.
  If you want it, send NS queries (as described in the ns-revalidation 
draft).

   "BB: Data from the answer section of a non-authoritative answer"
   discard it.

   "BB: non-authoritative data from the answer section of authoritative answers"
   discard it.

   "B: Additional information from an authoritative answer"
   If those data correspond to type MX, HTTPS/SVCB, or SRV responses,
   resolvers can decide based on local policy.

   "B: Data from the authority section of a non-authoritative answer,
   Additional information from non-authoritative answers."
   This is a referral response.

 A non-authoritative response from a server with administrative
 authority for a certain name that has NS RRSet in the authority
 section and Glue data in the additional section is a delegated
 response, and is used only for name resolution and not for
 responding to stub resolvers.
 The rank of the referral response is "A", I think.

   Any other response may be an attack and should be discarded.

   "AAA: all data that is verifiable DNSSEC secure regardless off were it came 
from"
 I don't like this rank.
 I like to use DNSSEC validation to decide
   whether to use "Additional information",
 but I don't like to blindly trust data
   that has been successfully validated.

   I believe many recursive resolver implementations have already
   discarded unnecessary responses.

Stub resolvers: accept all responses from the recursive resolver.

--
Kazunori Fujiwara, JPRS 

___
DNSOP mailing list
DNSOP@ietf.

Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-06.txt

[Willem Toorop]

Op 18-03-2024 om 17:01 schreef Florian Obser:

On 2024-03-17 20:12 -07,internet-dra...@ietf.org  wrote:

Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It is

| 7.  Security Considerations
| [...]
| In case of non DNSSEC validating
| resolvers, an attacker controlling a rogue name server for the root
| has potentially complete control over the entire domain name space
| and can alter all unsigned parts undetected.

can alter *all* parts undetected.

It's a non-DNSSEC validating resolver, it doesn't care about signed or
unsigned. Maybe just drop that sentence, it doesn't add much.


Ah sorry, no the "In case of non DNSSEC validating resolvers" is wrong, 
this should be "In case of a DNSSEC validating resolver that does not do 
revalidation, ..."




OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

[Willem Toorop]

Op 06-03-2024 om 22:06 schreef Wessels, Duane:


Hi, some initial thoughts:

RFC 2181 says "Data from a zone transfer, other than glue” but this 
draft doesn’t make any exceptions for glue or non-authoritative data 
from a zone transfer.  Is that intentional?
Well, RFC 2181 had a uniquely broad definition of glue (see also the 
terminology draft: 
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-10.html#section-7-2.29), 
so I came up with "other than occluded data" to be more generic, but I 
suppose that wouldn't include the delegation NS records themselves, so 
that won't work either. I'll try to come up with something better...

Should RFC 8767 stale data be ranked differently than fresh data?
Should EDNS Client Subnet play into ranking?


I like your thinking! Yes, fresh data should replace stale data in 
resolver caches, and yes a more specific ECS prefix answer is preferable 
over a less specific ECS prefix. The draft is intended to start 
re-evaluation and re-thinking of that ranking. The authors are planning 
to discuss this extensively at the hackathon preceding IETF 119. This is 
already very good input! So, Thanks!


-- Willem



DW





On Mar 4, 2024, at 6:37 PM, Benno Overeinder  wrote:

Caution: This email originated from outside the organization. Do not 
click links or open attachments unless you recognize the sender and 
know the content is safe.

 Forwarded Message 
Subject: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt
Date: Mon, 04 Mar 2024 13:12:26 -0800
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org

Internet-Draft draft-toorop-dnsop-ranking-dns-data-00.txt is now 
available.


  Title:   Ranking Domain Name System data
  Authors: Paul Hoffman
   Shumon Huque
   Willem Toorop
  Name:    draft-toorop-dnsop-ranking-dns-data-00.txt
  Pages:   4
  Dates:   2024-03-04

Abstract:

  This document extends the list ranking the trustworthiness of domain
  name system (DNS) data (see Section 5.4.1 of [RFC2181]).  The list is
  extended with entries for root server names and addresses built-in
  resolvers, and provided via a root hints file with the lowest
  trustworthiness, as wel as an entry for data which is verifiable
  DNSSEC secure with the highest trustworthiness.  This document
  furthermore assigns ranked values to the positions of the list for
  easier reference and comparison of trustworthiness of DNS data.

The IETF datatracker status page for this Internet-Draft is:
https://secure-web.cisco.com/1-KFlj_oYrZOH-5BhyKqBeDYA57SqQxpkiil5nsPhQR9QBqNk5C1dftYIqaAaBo55ch7u5zlzSyavgTQh3U4JVQSRVGLu4rDLk6FjqWp5kurgOW2oqCka2YyZ9SzqiOfjQbUP2XEQi9izTnWo90VgorxeKRntDUgxyVOYihvFygAM6nuXgV8jBlXpMb2pxDPAfbX70Wv0uqDcZiq1A979EWVqSt9MCvNxQr2kerBKq7OAzltfygzvl6X_KUg8Hoq1R3TOzWDL9uJCJdiWawGKtp80A9QP2MuAXF70_-cRUAI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-toorop-dnsop-ranking-dns-data%2F

There is also an HTMLized version available at:
https://secure-web.cisco.com/1MS_L_uLvJbHCh42n3cgkh_vZRkcg-dAAs_ThN8dzzEXCzyNrE60Pow2LR2HWuKjY1rtp9zIXQPO9QWmDyKZ3drYTqpRRPAhOG408US3yeZ_ybTUwx5ZmGVFIDhhZCDyIuP4Rg_kj_e4KE4mxsKgzgEfIQdwq7bK01e2Edkb4wSY0JIrc-Hzwsw6uz-xNn84Qrb8f3ltQ4Ei9RGjHCnWzJ4NFCNmChSwQ7D9QkgFVPeZKGEVSEIwpohbW91IyDYpcHAs4A1RD-dezuELyugLuLafMYiooQeTs6JwhnK9UPXc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-toorop-dnsop-ranking-dns-data-00

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
DNSOP mailing list
DNSOP@ietf.org
https://secure-web.cisco.com/1tsEMQC3Zecz5o61auTq0E97pflQrX3OHLUXtw4gyrJms3GEbkEmq1XikMPMvYLfFtsbpF0ywAkAOP674RMmrkeAJCnXXx9NyLN0KU9uKmvS3lhZ4ste6C9PM-fjBLzZQeg8oaUexDd7FDoDEkx6l4vrXi5QadmS-ZydnLgKxJsLB2arRZlHXiMm_UXCLHZWYGwTlCYoxupX1buUc3jOw3QN7hp6TmPsUEaNJUIJoiustJUfO4pppH1yzrjf_B9-bnwZJBnApnH_AL9Dep-ELQxFrkCKXZONXLa_VZgKV50M/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc8109bis-04.txt

[Willem Toorop]

Thanks Paul,

I feel Section 3.3. "DNSSEC with Priming Queries" may not do the effects 
of redirected query traffic enough justice. RFC 8109 already didn't do 
it enough justice I think.


For starters, the second paragraph already assumes a 
"machine-in-the-middle" attack, but there may also be off-path attacks 
that manage to spoof priming responses. The first paragraph already 
states that the address records are not signed. I think that should be 
the emphasis of the attack vector. I have some alternative text 
proposals for the first two paragraphs. I will copy the original text as 
well, followed by my proposals.


For the first paragraph I would like to add that the NS RRset is signed 
and can be validated, so instead of:


The resolver MAY set the DNSSEC OK (DO) bit. At the time of 
publication, there is little use to performing DNSSEC validation on 
the priming query. At the time this document is published, all root 
server names end in "root-servers.net" and the  and A RRsets for 
the root server names reside in the "root-servers.net" zone. All root 
servers are also authoritative for this zone, allowing priming 
responses to include the appropriate root name server A and  
RRsets. But, because the "root-servers.net" zone is not signed at the 
time this document is published, these RRsets cannot be validated.

I propose this text:
The root NS RRset is DNSSEC signed and can be validated by a DNSSEC 
validating resolver. At the time this document is published, the 
addresses for the names in the root NS RRset reside in the 
"root-server.net" zone. All root servers are also authoritative for 
this zone, allowing priming responses to include the appropriate root 
name server A and  RRsets. But, because the "root-servers.net" 
zone is not signed at the time this document is published, these 
RRsets cannot be validated. An attacker that is able to provide a 
spoofed priming response can provide alternative A and  RRsets and 
fool a resolver into taking addresses under the control of the 
attacker to be authoritative for the root zone.



Then, the second paragraph is all about how DNSSEC signed data cannot be 
modified undetected and can only be a denial of service attack, but I 
think this obvious and not really interesting. What is more interesting 
is that the unsigned parts can be altered. So instead of


A machine-in-the-middle attack on the priming query could direct a 
resolver to a rogue root name server. Note, however, that a validating 
resolver will not accept responses for signed TLDs from rogue root 
servers if they are different from the real responses because the 
resolver has a trust anchor for the root and the answers from the root 
are signed.

/In between note: This is not true, the unsigned parts can be altered/
Thus, if there is a machine-in-the-middle attack on the priming query, 
the results for a validating resolver for signed TLDs could be a 
denial of service, or the attacker seeing queries while returning good 
answers, but not the resolver's accepting the bad responses; however, 
for unsigned TLDs, the attack would be successful.


I propose instead of this second paragraph, this text:

A rogue root name server can view all queries from the resolver to the 
root and alter all unsigned parts of responses, such as the parent 
side NS RRsets and glue in referral responses. Resolvers following 
referrals from a rogue root server, that do not explicitly query the 
authoritative NS RRset at the apex of the child (TLD) zone and do not 
explicitly query for the authoritative A and  RRsets for those 
child (TLD) NS RRsets, can subsequently be fooled into taking 
addresses under the control of the attacker to be authoritative for 
those delegations. With such resolvers (that do not do those explicit 
follow up authoritative NS and address queries), an attacker that 
controls a rogue root server effectively controls the entire domain 
name space and can view all queries and alter all unsigned data 
undetected (see also Section 3 of [draft-ietf-dnsop-ns-revalidation]).


An attacker controlling a rogue root name server also has complete 
control over all unsigned delegations, and over the entire domain name 
space in case of non DNSSEC validating resolvers.



The third paragraph is fine I think.

-- Willem

Op 14-02-2024 om 19:25 schreef internet-dra...@ietf.org:

Internet-Draft draft-ietf-dnsop-rfc8109bis-04.txt is now available. It is a
work item of the Domain Name System Operations (DNSOP) WG of the IETF.

Title:   Initializing a DNS Resolver with Priming Queries
Authors: Peter Koch
 Matt Larson
 Paul Hoffman
Name:draft-ietf-dnsop-rfc8109bis-04.txt
Pages:   11
Dates:   2024-02-14

Abstract:

This document describes the queries that a DNS resolver should emit
to initialize its cache.  The result is that the resolver gets both a
current NS Resource Record Set (RRset) for the root zone and the
necessar

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Willem Toorop]

Op 08-06-2023 om 11:59 schreef Benno Overeinder:

Dear DNSOP WG,

The authors and the chairs feel this document has reached the stage 
where it's ready for Working Group Last Call.


This starts a Working Group Last Call for: 
draft-ietf-dnsop-dns-error-reporting.


Dear all,

I find this is a very valuable addition to the DNS protocol for zone 
owners and authoritative operators. It also opens up potential for 
valuable future extensions, such as for example dy-run DNSSEC example ;).


I have spend a few IETF hackathons on Proof of Concept implementations, 
and I can report that it is very straight-forward to implement. The 
draft PR for Unbound that emerged from those hackathons, is already 
almost the finished feature: 
https://github.com/NLnetLabs/unbound/pull/902 (still pending the EDNS0 
opcode though!)


I have one nit.

In the Example in section 4.2., a request still "includes an empty ENDS0 
report channel". The third paragraph of that same section states 
something similar: "As support for DNS error reporting was indicated by 
a empty EDNS0 report channel option in the request". But Section 6.1. 
Reporting Resolver Specification states: "The EDNS0 report channel 
option MUST NOT be included in queries."


I believe the text in the Example section is a left over from an earlier 
version and should be corrected.



Thanks to Roy, and all the other people who worked on this!

-- Willem



Current versions of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/.


The Current Intended Status of this document is: Standards Track.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please 
speak out with your reasons.

Supporting statements that the document is ready are also welcome.

This starts a two week Working Group Last Call process, and ends on: 
June 22nd, 2023.


Thanks,

-- Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-klh-dnsop-rfc8109bis

[Willem Toorop]

I am also in favor of adoption.

I am a member of a consortium carrying out a study on behalf of ICANN on 
the naming scheme used for the root servers (the RSSAC028 Implementation 
study 
). 
This is a follow up study of the Advisory from the ICANN Root Server 
System Advisory Committee (RSSAC) RSSAC028 
.


I expect that our work and the report we are currently in the process of 
writing, will provide the means for well considered feedback and input 
on this draft.


I am also voicing support for adaption on behalf of the other consortium 
members: Moritz Müller and Marco Davids from SIDN and Yorgos 
Thessalonikefs  and Benno Overeinder (with consortium hat) from NLnet Labs.


-- Willem

Op 31-05-2023 om 15:54 schreef Tim Wicinski:


All

A reminder that there is an open call for 
adoption on draft-klh-dnsop-rfc8109bis.
While this document may not be relevant to most operators, there are 
some that do

find this useful, and we wish to hear from them.

This call for adoption ends: 7 June 2023

tim



On Wed, May 24, 2023 at 10:01 AM Tim Wicinski  wrote:


All

The authors for RFC8109 have made some updates to their document
"Initializing a DNS Resolver with Priming Queries", and are
looking to have the
work adopted by DNSOP.

You can see the changes made since RFC8109 here:


https://author-tools.ietf.org/iddiff?url1=rfc8109&url2=draft-klh-dnsop-rfc8109bis-06&difftype=--html



This starts a Call for Adoption for draft-klh-dnsop-rfc8109bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-klh-dnsop-rfc8109bis/


Please review this draft to see if you think it is suitable for
adoption
by DNSOP, and send any comments to the list, clearly stating your
view.

Please also indicate if you are willing to contribute text,
review, etc.

This call for adoption ends: 7 June 2023

Thanks,
tim wicinski
For DNSOP co-chairs


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification - draft-ietf-dnsop-dns-catalog-zones-09.txt

[Willem Toorop]

Op 09-02-2023 om 17:50 schreef Tim Wicinski:



On Thu, Feb 9, 2023 at 9:56 AM Paul Wouters <mailto:p...@nohats.ca>> wrote:


On Thu, 9 Feb 2023, Willem Toorop wrote:

 >>  Or it could use “_catalog.example.com
<http://catalog.example.com>”  ?
 >
 > Yes, if we add a sentence that the fictional organization
producing this
 > catalog is "example.com <http://example.com>", then we could use
that too yes.

That would imho be the best solution.


I agree with Paul here.


Me too. Example zone name changed in commit:


https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/93113b7

Cheers

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification - draft-ietf-dnsop-dns-catalog-zones-09.txt

[Willem Toorop]

Op 09-02-2023 om 14:46 schreef Paul Wouters:

On Feb 9, 2023, at 06:33, Willem Toorop  wrote:

Op 07-02-2023 om 16:45 schreef Paul Wouters:> I find the valid use of the name 
"invalid" to be pretty horrible. An

engineer looking at a catalog might quickly believe
the invalid is a bug where it should have shown a real domain. Why not 
_catalog.arpa or something ?


We, the co-authors, actually prefer producers to use a domain they own (because 
no chance on collisions with consumers from multiple producers). I've done a 
commit to express that more clearly. The new text is:

   ``It is RECOMMENDED to use a domain name owned by the catalog producer if possible, or 
if that is not possible use a name under a suitable name such as "invalid." 
[RFC6761].''


A name under a suitable name such as invalid would then be 
“example.com.invalid” and not as it has now just “invalid” ?


Do you mean in the Catalog Zone Example appendix ( 
https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-09.html#appendix-A 
) ?


The name used there is "catalog.invalid.", not just "invalid.".
You prefer "example.com.invalid" over "catalog.invalid"?


Or it could use “_catalog.example.com”  ?


Yes, if we add a sentence that the fictional organization producing this 
catalog is "example.com", then we could use that too yes.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification - draft-ietf-dnsop-dns-catalog-zones-09.txt

[Willem Toorop]

Op 09-02-2023 om 12:38 schreef Willem Toorop:

Op 08-02-2023 om 14:27 schreef Paul Wouters:
While re-reading the properties / version bits, I noticed this text in 
section 4.3.2.1 <http://4.3.2.1>:


       In this scenario, consumer(s) shall, by agreement, not sign the 
member zone "example.com <http://example.com>." with DNSSEC.


Since the "nodnssec" got removed, this sentence makes no more sense to 
me. How does the example "show" the

meaning of "not sign the member zone" ?


Sorry, I stand corrected.

Before the example is a paragraph, with the first mention of the value 
"foo", stating:


   ``For example, the "foo" group could be agreed to indicate that a 
zone not be signed with DNSSEC.''


I have reverted the previous commit, because of its redundancy.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification - draft-ietf-dnsop-dns-catalog-zones-09.txt

[Willem Toorop]

Op 08-02-2023 om 14:27 schreef Paul Wouters:
While re-reading the properties / version bits, I noticed this text in 
section 4.3.2.1 :


       In this scenario, consumer(s) shall, by agreement, not sign the 
member zone "example.com ." with DNSSEC.


Since the "nodnssec" got removed, this sentence makes no more sense to 
me. How does the example "show" the

meaning of "not sign the member zone" ?


We changed that text line into:

   ``By agreement, "foo" could in this scenario indicate that the 
consumer(s) shall not sign the member zone "example.com." with DNSSEC.''


in commit:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/a253f82

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification - draft-ietf-dnsop-dns-catalog-zones-09.txt

[Willem Toorop]

Op 07-02-2023 om 16:45 schreef Paul Wouters:> I find the valid use of 
the name "invalid" to be pretty horrible. An

engineer looking at a catalog might quickly believe
the invalid is a bug where it should have shown a real domain. Why not 
_catalog.arpa or something ?


We, the co-authors, actually prefer producers to use a domain they own 
(because no chance on collisions with consumers from multiple 
producers). I've done a commit to express that more clearly. The new 
text is:


   ``It is RECOMMENDED to use a domain name owned by the catalog 
producer if possible, or if that is not possible use a name under a 
suitable name such as "invalid." [RFC6761].''


in commit:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/451de04



NITS:

A mangled quote (eg ") made it into the document


I notice this in the diff indeed!, but in the uploaded XML it was no 
different than other quotes. Note also that the mangled quote does not 
appear in the txt and html rendering of the document. So I guess it's a 
bug in the iddiff viewer...


Willem Toorop on behalf of the draft-ietf-dnsop-dns-catalog-zones co-authors




Paul


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-dns-catalog-zones-08

[Willem Toorop]

Hi Catherine,

Op 09-12-2022 om 23:17 schreef Catherine Meadows via Datatracker:

The security considerations section gives a number of reasonable authentication
and privacy requirements, but does stops short of the use of the word MUST.  Is
MUST avoided because it is not yet practical?


We think that the precise privacy and security requirements are very 
diverse for the variety of different deployments currently and in the 
future. Some zones and list of zones may have the requirement to be 
published publicly without authentication (such as the zones managed by 
IANA). We don't want to rule anything out. Therefore we deemed it 
unpractical to have hard MUST requirements. Instead, we've tried to 
enumerate all the considerations (and measures) as completely as we could.


Also, regular zone transfers (RFC5936) don't currently have MUST 
requirements w.r.t. authentication or encryption. Encrypted zone 
transfers (RFC9103) MUST be authenticated though.


We did fortify the requirements a little bit by changing that 
"consumer(s) SHOULD scope the set of admissible member zones" instead of 
"MAY".




Nits:  There are a lot of unexplained acronyms, especially at the beginning:
RR, SOA, NS RR, RDATA, PTR, and so on.  These should be spelled out the first
time they are used at the document.  It would also help to have the more
important ones described in more detail in the terminology section.



This has been addressed in version -09 by adding the text that was 
suggested by Joe Abley:


"This document makes use of terminology that is specific to the DNS, 
such as for transfer mechanisms (AXFR, IXFR), for record types (SOA, NS, 
PTR), and other technical terms (such as RDATA). Since these terms have 
specific meanings in the DNS they are not expanded at first use in this 
document. For definitions of those and other terms, see [RFC8499]."



Thank you for your review and kind regards,

Willem Toorop on behalf of the draft-ietf-dnsop-dns-catalog-zones 
co-authors.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-catalog-zones-08

[Willem Toorop]

Hi Russ, Lars and Roman,

Thank you for your review Russ. Your (minor) concerns have all been 
addressed and we will soon upload a new version of the draft with, 
amongst others, your concerns and nits addressed.


Lars and Roman, this reply also addresses your IESG comments on the use 
of the word "meaningless".



Op 03-12-2022 om 20:17 schreef Russ Housley via Datatracker:

Minor Concerns:

The document lacks an IANA Considerations section.  Please add one,
even if it says that there are no actions for IANA and asks the
RFC Editor to remove the section when the document is published.
Such a section provides clarity during IANA review of the document.


A new, soon to be uploaded, version will have a IANA Consideration 
section with a registry request for catalog zones properties. It can be 
previewed here:


https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/blob/master/draft-ietf-dnsop-dns-catalog-zones.md#iana-considerations-iana




Section 3 says:

Catalog consumers MUST ignore any RR in the catalog zone which is
meaningless to or otherwise not supported by the implementation.

I am unsure what is meant by "meaningless".  Please define the term
or provide some explanation.


We have rephrased the sentence without the word "meaningless" as follows:

"Catalog consumers MUST ignore any RRs in the catalog zone for 
which no processing is specified or which are otherwise not supported by 
the implementation."


In this commit:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/737bcfe



Nits:

Section 2 provides a list to definitions.  Please add some form of
punctuation after the word being defined (a colon or a hypen or
something else to aid the reader).


Thanks! Done in commit 
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/3f55e43



Lars and Roman, I believe we have responded to all your IESG comments 
now. Can you confirm?


Thanks

Willem Toorop on behalf of the draft-ietf-dnsop-dns-catalog-zones co-authors

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Murray Kucherawy's Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)

[Willem Toorop]

ce:

   "A catalog zone MUST follow the usual rules for DNS zones. In 
particular, SOA and NS record sets MUST be present and adhere to 
standard requirements (such as [RFC1982])"


Is that better?



Section 4.2:

The SHOULD at the end leaves implementers with a choice.  Why might an
implementer choose to do something other than what it says?  Or should this
really be a MUST?


As it is most likely that catalog producers and consumers hold the zone 
authoritatively, TTLs shouldn't play a role as the records are not 
cached anyway. However, we could imagine a catalog consumer processing 
the catalog (or part of it) by performing queries. Such a consumer may 
not have the choice to ignore TTLs when it is querying indirectly via a 
resolver. SHOULD leaves the door open for other "kinds" of 
implementations than we have now.




Section 4.3:

It doesn't say anywhere (unless I missed it) that the RRTYPEs of properties are
unspecified, and depend on the property.  It might be good to make that
explicit, because I kept searching for it.


We said in the second half of the second sentence of the section:

   "with type(s) as appropriate for the respective property."

We've changed "with type(s)" into "with RR types(s)" to make it clearer.



Section 4.4.1:

Regarding the last paragraph, is there any advice to pass on to operators about
how exactly one can tell when the COO is complete?


Not really without querying all the secondaries, but at least 
secondaries will pick it up if they either lost the notify or were down.
I suppose monitoring the network status of the secondary provider and 
making sure the whole network has been up for at least the refresh time 
of the catalog zone ... and then a bit more, would be a safe bet, but 
it's very much dependent on the specific operational reality.




Section 7:

Why are the protections of zone transfers and updates only SHOULDs?


It depends on the operational reality. Zone transfers may be using a 
completely separate distribution network which is shielded from external 
DNS access (with VPNs or UPDATES from an internal network or local 
machine even). It is also not a MUST with zone transfers in general 
which may also contain privacy sensitive or operational critical 
information.




I plan to record all the changes that have been done in the Change 
History appendix and then upload version -09 for rereview.


Best regards,

Willem Toorop on behalf of the draft-ietf-dnsop-dns-catalog-zones co-authors

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)

[Willem Toorop]

Hi Paul, Hi Murray,

Hereby the responses to Paul's review. I've CC'ed you Murray, because 
you mentioned explicitly that you support Paul's DISCUSS positions.


Op 04-01-2023 om 05:05 schreef Paul Wouters via Datatracker:

DISCUSS:
-- 
## DISCUSS


### Section 4.3.1 Versioning

What should one do if the version supported is lower than the version of zone
received? Attempt to understand it? preventively fail?

Are version 1 and 2 compatible? In what ways are they not? Should perhaps
version 1 catalog zones always be ignored ?


Version 1 and 2 are not compatible. Version 1 was bind's original but 
not standardized idea/implementation. New implementations are better of 
implementing version 2 because the exact details of version 1 are not 
standardized (and thus kind of unknown).


Commit 
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/8eed29f 
adds the explicit mention that version 1 catalog zones should also be 
considered broken by catalog consumers that only have version 2 
implemented to the enumeration of section 4.3.1. Schema Version (version 
property).




### Group Properties

It seems like Section 4.4.2 defines "group properties" that are standardized,
while Section 4.5 specifies Private Use group properties.


There are no "group properties", only "group property *values*". The 
values listen in 4.4.2 are only examples and not standardized. Section 
4.5 is about private use properties and is not involved in group values.



But there is actually
no registry created for Group Properties, and no definitions other than
"examples" are given. This makes the status of, for example "nodnssec",
unclear. Is this a custom (eg bind implementation only) property or is this
really a custom private use entry, in which case the example is bad as it
belongs under .bind.ext.

Since "nodnssec" seems a real use case, why does this document not create an
IANA registry for Catalog Zone Group Properties and places "nodnssec" in it?


We have done several modifications to the draft to clarify this better.
  - We refer to the values of group properties now as "group property 
values" or even simply as "group values".
  - The group values now have non-descriptive names as to not suggest 
that they have meanings in implementations (it's the operator that 
determines the "meaning" and not the implementation)
  - We have extended the lines about catalog producers publishing at 
two consumer operators and how mapping of group values is a matter of 
those producer/consumer relationships, so it now reads:


  "Implementations MAY facilitate mapping of a specific group value 
to specific configuration configurable on a per catalog zone basis to 
allow for producers that publish their catalog zone at multiple consumer 
operators. Consumer operators SHOULD namespace their group values to 
reduce the risk of having to resolve clashes."



The co-authors do recognize that a registry for *properties* is a good 
idea and have added that to the draft (with PR 
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/67 )




### 5.3 "MUST be removed"?
```
 Only when the zone was configured from a specific catalog zone,
 and the zone is removed as a member from that specific catalog
 zone, the zone and associated state (such as zone data and DNSSEC
 keys) MUST be removed.
```

What is "removed" here? I think perhaps it should be limited to "MUST no longer
be served". For example, it would be bad if the operator made an error, and
ended up briefly removing the zone and "removing" (aka destroying) some private
DNSSEC keys, complicating the zone restoration. Also, perhaps the
implementation wants to simply keep the state on disk but move it to a
/var/lib/xxx/zones/archived/ directory. The use of "remove" sounds like that
might not be allowed.


We have added a line explicitly stating this operational consideration 
to Section 5.3. Member zone removal:


   "Consumer operators may consider to temporarily archive associated 
state to facilitate mistake recovery."




### Operational Considerations

What are the risks and benefits of Extension group properties?

Should one try to standardize these instead? Why is this document not doing
that based on its operational experience with eg bind and knot and powerdns ?


This document will standardize three properties: "version", "coo" and 
"group". Implementations can create their own custom properties below 
the "ext" label. Bind9 has several custom properties ("primaries", 
"allow-query" and "allow-transfer"), but the other implementations don't 
have them yet. When the other implementations will create similar custom 
properties (from operator feedback) they can be considered to be 
standardized as regular (and not custom) properties and don't need to be 
below the "ext" label.



if one is experimenting with further properties in the extension part,

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-dns-catalog-zones-08

[Willem Toorop]

Hi David,

Response inline at the bottom.

Op 03-01-2023 om 19:42 schreef Blacka, David:




On Jan 3, 2023, at 12:48 PM, Peter Thomassen  wrote:

Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
Hi David,

Thank you for your review. Please see inline.


Thanks! Also see inline.



On 12/27/22 18:14, David Blacka via Datatracker wrote:


Second, some comments:
This draft is not quite definitive on whether or not Catalog Zones are directly
queryable.  Instead, it strongly discourages them from being queried, but
usually using non-normative language. (The exception: the security
considerations RECOMMEND limiting who can query the zone.)  I wonder if the
document would be better served with a more up-front statement on this issue?


Good point -- the text indeed was a bit hand-wavy in this regard. I modified as 
follows:

- Replace (with better wording) or remove "casual" (non-normative) references 
to DNS queries (e.g. when talking about TTL values)

- Add justification why limiting queries is RECOMMENDED (namely, to prevent 
unintentional exposure of catalog zone contents)


I looked at your changes, and I think those updates work for this.




An appendix showing a full example catalog zone would be a nice addition to the
document.  There are examples throughout the text demonstrating specific
concepts, however, so it isn't clear that such an appendix is strictly
necessary.


Done, based on an example from the Knot DNS documentation. (This has also been 
requested by other reviewers.)


Also great!




Catalog zones appear to be intentionally not fully interoperable between
completely un-coordinated instances.  Is this interpretation correct?  I think
my basic confusion arises from not seeing what can be done with catalog zones
*without* custom properties.


This is correct.

As to "what can be done without custom properties": The main use case is 
provisioning and deprovisioning zones on secondary DNS servers.

Without catalog zones, the secondary has to either somehow retrieve the list of zones via 
an out-of-band channel, or rely on heuristic processing of indirect signals from the 
primary. For example, a common way for removing secondary zones has been to let them 
"expire": check periodically whether the primary still knows the zone, and if 
it doesn't for say 1 week, assume it's not a glitch and remove the zone. This scales 
badly (requires lots of checking queries) and also risks deleting a zone prematurely when 
there actually is some other kind of problem causing the primary to not respond as 
expected.

This is the use case in which catalog zones are expected to be interoperable. 
Beyond that, vendors are free to map whatever zone settings their 
implementation offers, by means of custom properties. Examples of this could be 
zone-specific rate limiting or statistics collection.


Ah, I wasn’t clear.  I understand the overall use case for the catalog zones, 
but there were so few non-custom properties I wondered if one could effectively 
use catalog zones without them. I was expecting a few standard properties 
describing (e.g.) what the secondary should use as masters and what TSIG key to 
use.  That is, I can see you must give the zone name for the given zone, but 
nothing else seems to be required.  Did I miss some text that describes what is 
expected to happen by default?


Setting up a catalog on the secondary is a manual step anyhow (see 
Section 6. second paragraph en the third paragraph of Section 3.). 
Catalogs are assumed to be associated with a set of configuration (third 
paragraph of section 3) which is predefined (perhaps while configuring 
for consumption for that catalog) on the secondaries. Part of this set 
of configuration for secondaries are the primaries and TSIG keys to use. 
Secondary name servers can have multiple catalog zones configured and be 
a consumer for them, each catalog zone for a different set of primaries 
(and TSIG keys).


The (predefined) set of configuration can furthermore be changed per 
individual member zone within a catalog basis with the `group` property.


Also, a member zone can be migrated to a different catalog hosted on the 
same secondary which is associated with a different set of predefined 
configuration.


Do you think this needs to be stated more explicitly in the draft?

For the record: BIND9's implementation does provide custom properties 
for primaries, the names of the TSIG keys to use, and query and transfer 
ACL, but the other implementation do not as far as I can see in the 
documentation for each (co-authors please correct me if I'm wrong).


Many thanks for you review David!

Cheers,
-- Willem

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AD Review of draft-ietf-dnsop-dns-catalog-zones

[Willem Toorop]

Thanks Warren,

We have addressed your change requests in the freshly submitted version 
-08. I'll go over them individually as well as answer your questions 
inline below. (most of them copied verbatim from the PR for these 
changes: 
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/54 )


Op 30-10-2022 om 11:46 schreef Warren Kumari:

AD Review: Catalog Zones.

Hi there,

Thank you for all of the work you have put into this document; I think 
that catalog zones are a really useful feature, and should be documented.


Before I can start IETF Last Call, however, there are some questions 
and issues that need to be addressed - the majority of these are 
simply editorial changes where the document could be made clearer and 
more readable, but there are also some more substantive questions / 
places that need additional text.


Thank you again for writing this, and please SHOUT LOUDLY once you've 
had a chance to address these and post a new version, or if you'd like 
to discuss / have any questions, etc.

SSSHHHOOOUUUTTT!!!


W


Meta: The document has 7 authors, which exceeds the recommended 5. 
While we can approve more, but it requires justification - why does 
this document have 7?


To guarantee and maximize interoperability we wanted representatives of 
some of the Open Source authoritative name server implementations (BIND, 
Knot, NSD and PowerDNS) as well as one operator to be authors on this 
draft. For two of the Open Source implementations also the persons that 
did the actual implementation the protocol were added. So it is both to 
express the endorsement from ISC, CZ.NIC, NLnet Labs , PowerDNS and 
deSEC, as well as recognition of the actual implementers (which also 
collaborated intimately on this draft).


All 7 authors contributed substantially to the draft's content.


Sec 1:
O: "... they must also add/remove the
   zone from all secondaries, either manually or via an external
   application."
P: "they must also add/remove the configuration for the zone from all 
secondaries"

C: Just above it says that the zone is transferred using [AI]XFR.

done


O: "This can be both inconvenient and error-prone; it is
   also dependent on the nameserver implementation."
C: I don't have proposed text, but it is unclear what is mean by "it". 
Perhaps "... and error-prone; the configuration syntax ..."

done ("and error-prone; in addition, the steps required are dependent")


O: "This document describes a method in which the catalog is..."
C: Perhaps "list of zones" instead of catalog? Otherwise it feels a 
bit like a circular definition. Just a thought...

done


O: "As zones are added to or removed from the
   catalog zone, these changes are distributed to the secondary
   nameservers in the normal way."
C: Well, no - it's really not "in the normal way" - the normal way is 
that you edit the config file. I understand what you are trying to 
say, but I don't think that this says it. I propose just "As zones are 
added to or removed from the catalog zone, these changes are 
distributed to the secondary nameservers." or "... this zone is 
distributed to the secondary namesservers (just like any other zone)."

done similarly (also rephrased an adjoining sentence)


Sec 3:
O: "Catalog consumers MUST ignore any RR in the catalog zone which is
   meaningless or useless to the implementation."
C: Ourgrgh... Can you reword this? "useless to the implementation" is 
really really vague, and this *will* result in DISCUSS ballots.

done ("meaningless to or otherwise not supported by the implementation")



O: "The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields [RFC1035]
   are used during zone transfer."
C: Erm, "are used" how? Perhaps either drop this sentence (it doesn't 
seem to add anything), or "The SOA record's SERIAL, REFRESH, RETRY and 
EXPIRE fields [RFC1035] are used during zone transfer, just like they 
would be for any other zone"?

done (dropped)


Sec 4:
O: "More than one record in the RRset denotes a broken
   catalog zone..."
C: Can you come up with a better word than "denotes"? To me "denotes" 
implies that the user has *chosen* to do this. Perhaps "results in"? 
Sorry I don't have a better suggestion.
done ("indicate"), both in Section 4.2 and in 4.4.1. -- Potential 
alternatives: "signify", "are a sign of"


O: "The TTL field's value is not defined by this memo."
C: Erm... perhaos "The TTL field's value has no meaning in this 
context, and [MUST/SHOULD] be ignored."? Otherwise someone will ask 
what it means...

done, also swapped and merged with subsequent sentence.


Sec 4.4.2.1.  Example
I think that the example is quite unclear, and it will raise more 
questions than it answers -- for example, people are going to ask who 
exactly parses "operator-x-sign-with-nsec3", and they will also try 
and figure out where these verbs (e.g 'nodnssec') are defined. I think 
that you need to clarify that the meaning of the text records are 
opaque / defined between the produc

Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt

[Willem Toorop]

Dear dnsop,

We submitted a new version of a “dry-run DNSSEC” draft. The draft
describes a method that allows for testing DNSSEC deployments in real
world DNS(SEC) deployments without affecting the DNS service in case of
DNSSEC errors. Any encountered errors are signaled to the DNS operator
of the faulty zone with DNS Error Reporting
(draft-ietf-dnsop-dns-error-reporting).

This is a new idea which will be presented during dnsop at the IETF114
and was also presented at the IETF113. A recording of the IETF113
presentation is here: https://youtu.be/watch?v=7HxcmvFOnlU&t=3675s
Slides here:
https://datatracker.ietf.org/meeting/113/materials/slides-113-dnsop-dry-run-dnssec-01

We received a lot of feedback with our presentation which we used to
reorganize the draft to convey the idea more clearly and coherently. We
also received some critique and objections which were non-technical in
nature. Below is a list with these objections followed by our response.

** This is another straw on the camel’s back **

Not all resolvers have to support/implement it. Most important is that
provisioning at the registry and signaling of Dry-run is supported. If
needed we can say it is OPTIONAL for resolvers in the draft. We intend
to implement it ourselves in Unbound and have it enabled by default when
error reporting is enabled. We know from experience with trust-anchor
signaling and sentinel record that with only a small, up to date
resolver population, the signaling is already quite substantial.

There are different kinds of straws and this one is one that has the
good cause of enabling operators to deploy DNSSEC with confidence.


** Why not have a duplicate parallel test deployment? **

There is nothing better than testing with your actual user population to
dry-run your DNSSEC deployment. Note that slack’s parallel test
deployment did not show them the Route53 failure that caused them to
have an DNSSEC outage eventually[1]


** Why not sell DNSSEC domains cheaper? **

Yes, we’re all for that too, but that’s orthogonal to seeing what the
actual effect of starting DNSSEC with your deployment with your real
user population would be.


The other objections which were more technical, like for example
“registries supporting only fixed sized hashes per algorithm” and
“couldn’t we normalize the different DS hacks somehow” are all addressed
in the new version of the document.

We’re looking forward to a new round of feedback and critique ;)
Both on-list and in-person at the IETF-114!

Kind regards,

Yorgos, Willem and Roy


Op 11-07-2022 om 23:58 schreef internet-dra...@ietf.org:
> 
> A new version of I-D, draft-yorgos-dnsop-dry-run-dnssec-01.txt
> has been successfully submitted by Yorgos Thessalonikefs and posted to the
> IETF repository.
> 
> Name: draft-yorgos-dnsop-dry-run-dnssec
> Revision: 01
> Title:dry-run DNSSEC
> Document date:2022-07-11
> Group:Individual Submission
> Pages:12
> URL:
> https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/
> Html:   
> https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-yorgos-dnsop-dry-run-dnssec-01
> 
> Abstract:
>This document describes a method called "dry-run DNSSEC" that allows
>for testing DNSSEC deployments without affecting the DNS service in
>case of DNSSEC errors.  It accomplishes that by introducing a new DS
>Type Digest Algorithm that signals validating resolvers that dry-run
>DNSSEC is used for the zone.  DNSSEC errors are then reported with
>DNS Error Reporting, but any bogus responses to clients are withheld.
>Instead, validating resolvers fallback from dry-run DNSSEC and
>provide the response that would have been answered without the
>presence of a dry-run DS.  A further option is presented for clients
>to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC
>testing.
> 
>   
> 
> 
> 
> The IETF Secretariat
> 
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

[Willem Toorop]

Op 10-07-2022 om 10:56 schreef Willem Toorop:
> 
> I will try to go over the document once more to "correct" those cases.
> 

Sorry! The quotes surrounding "correct" were from an earlier version of
the text when I still didn't agree completely yet! So no quotes
intended! Instead:

I will try to go over the document once more to correct those cases.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

[Willem Toorop]

Op 08-07-2022 om 00:21 schreef Michael StJohns:
> On 7/7/2022 5:32 AM, Willem Toorop wrote:
>> Dear dnsop,
>>
>> This draft describes a mechanism for automatic provisioning of zones
>> among authoritative name servers by way of distributing a catalog of
>> those zones encoded in a regular DNS zone.
>>
>> The version's focus was finalizing for Working Group Last Call.
>> We made sure that all MUSTs in the document have a companion description
>> that tells what to do if that MUST condition is not met. Also the
>> `group` property restrictions have been loosened to accommodate multiple
>> sets of catalog consumers offering different sets of group properties.
> 
> Not to be a pedant and having not read the document, don't you mean
> "SHOULD" above rather than "MUST"?  MUST's are absolute requirements
> that should have no wiggle room. SHOULD's are the requirements where you
> probably need to explain what to do if the condition isn't met.

Michael I agree! I do see that we've been too sloppy in some cases in
the sense that we allow the consumer to have a choice to be strict or
lenient with SHOULDs. These SHOULDs should indeed be replaced with MUSTs
telling whether the consumer MUST be strict (and disregard the whole
catalog zone) or MUST be lenient and tolerate certain conditions to
support future extensions to the protocol. If those cases we may replace
the MUST on the producing side with a SHOULD too then yes for coherency.

I will try to go over the document once more to "correct" those cases.

Thanks for pointing this out!

> 
> One brief example taken from your document (section 4.1):
> 
>> Catalog consumers SHOULD ignore NS record at
>>apex.  However, at least one is still required so that catalog zones
>>are syntactically correct DNS zones.  A single NS RR with a NSDNAME
>>field containing the absolute name "invalid." is RECOMMENDED
>>[RFC2606][RFC6761].
> 
> Instead: "Catalog consumer MUST ignore the NS record at the apex of the
> catalog zone.  Catalog zones SHOULD include a single NS RR with a
> NSDNAME containing the absolute name 'invalid.', but consumers MUST NOT
> error out if this is not present.  Non-catalog clients will take an
> error as expected when retrieving the zone.  Non-catalog-aware servers
> may fail to load or serve the catalog zone if this NS RR is absent." 
> (The "will" and "may" in the last two sentences are lower case as they
> are explanatory and not requirements.  The last sentence explains the
> probable result of omitting the NS RR.)
> 
> My $.02. 
> 
> Mike
> 
> 
> 
>> The authors consider this version to be complete to the best of our
>> ability and we'd like to ask the working group to proceed with this
>> document for Working Group Last Call.
>>
>>
>> Op 07-07-2022 om 11:03 schreef internet-dra...@ietf.org:
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Domain Name System Operations WG of the 
>>> IETF.
>>>
>>> Title   : DNS Catalog Zones
>>> Authors : Peter van Dijk
>>>   Libor Peltan
>>>   Ondrej Sury
>>>   Willem Toorop
>>>   Kees Monshouwer
>>>   Peter Thomassen
>>>   Aram Sargsyan
>>>   Filename: draft-ietf-dnsop-dns-catalog-zones-06.txt
>>>   Pages   : 20
>>>   Date: 2022-07-07
>>>
>>> Abstract:
>>>This document describes a method for automatic DNS zone provisioning
>>>among DNS primary and secondary nameservers by storing and
>>>transferring the catalog of zones to be provisioned as one or more
>>>regular DNS zones.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-06.html
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-06
>>>
>>>
>>> Internet-Drafts are also available by rsync at 
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

[Willem Toorop]

Dear dnsop,

This draft describes a mechanism for automatic provisioning of zones
among authoritative name servers by way of distributing a catalog of
those zones encoded in a regular DNS zone.

The version's focus was finalizing for Working Group Last Call.
We made sure that all MUSTs in the document have a companion description
that tells what to do if that MUST condition is not met. Also the
`group` property restrictions have been loosened to accommodate multiple
sets of catalog consumers offering different sets of group properties.

The authors consider this version to be complete to the best of our
ability and we'd like to ask the working group to proceed with this
document for Working Group Last Call.


Op 07-07-2022 om 11:03 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : DNS Catalog Zones
> Authors : Peter van Dijk
>   Libor Peltan
>   Ondrej Sury
>   Willem Toorop
>   Kees Monshouwer
>   Peter Thomassen
>   Aram Sargsyan
>   Filename: draft-ietf-dnsop-dns-catalog-zones-06.txt
>   Pages   : 20
>   Date: 2022-07-07
> 
> Abstract:
>This document describes a method for automatic DNS zone provisioning
>among DNS primary and secondary nameservers by storing and
>transferring the catalog of zones to be provisioned as one or more
>regular DNS zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-06.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-06
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-yorgos-dnsop-dry-run-dnssec-00 and DS digest field

[Willem Toorop]

Thanks Libor,

I'm planning to create an overview of all the feedback and proposed
solutions to our issues we've had since IETF113 (including your
proposal), discuss that with the co-authors, and then post that to dnsop
together with an announcement that we're working on this.

Cheers,

-- Willem

Op 30-03-2022 om 16:58 schreef libor.peltan:
> Hi dnsop, Yorgos, Willem, Roy,
> I really like this idea of dry-run DNSSEC. I think it could really help
> new DNSSEC adopters.
> 
> The evidently weird thing of the proposal is the displacement of DS
> digest field into the first byte of DS hash field, in order to free up
> space for dry-run signalling. This will cause difficulties in human
> readability of resulting DS. The obvious counter-proposal would be to
> simply take the most-significant bit of the DS digest field (set to 1
> for dry-run), which would take 128 of available DS digest numbers
> (instead of just one), but wouldn't otherwise introduce any
> inconsistencies in DS format. As only four are taken so far, it seems
> viable to me.
> 
> Should we (dnsop) discuss this specific matter, or even poll?
> 
> Thanks,
> Libor
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-05.txt

[Willem Toorop]

Dear dnsop,

This draft describes a mechanism for automatic provisioning of zones
among authoritative name servers by way of distributing a catalog of
those zones encoded in a regular DNS zone.

This version's focus was getting ready for WGLC.

This version of the draft deals solely with catalog zones and the
operations involved with them and nothing else. It no longer specifies
the "serial" property (which was an optimization for zone transfers
build upon catalog zones, but not dealing with the catalog itself).

New in this version are global custom properties.


Op 07-03-2022 om 23:05 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : DNS Catalog Zones
> Authors : Peter van Dijk
>   Libor Peltan
>   Ondrej Sury
>   Willem Toorop
>   Kees Monshouwer
>   Peter Thomassen
>   Filename: draft-ietf-dnsop-dns-catalog-zones-05.txt
>   Pages   : 17
>   Date: 2022-03-07
> 
> Abstract:
>This document describes a method for automatic DNS zone provisioning
>among DNS primary and secondary nameservers by storing and
>transferring the catalog of zones to be provisioned as one or more
>regular DNS zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-05.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-05
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-04.txt

[Willem Toorop]

Dear dnsop,

This draft describes a mechanism for automatic provisioning of zones
among authoritative name servers by way of distributing a catalog of
those zones encoded in a regular DNS zone.

This version of the draft is the result of thorough review and
discussion with the goal of getting it in shape for publication as RFC.

Besides rephrasing and reordering, predictability of owner names
("member labels") in the catalog zone is now left out of consideration.
As a result, the `epoch` property (a property specific for predictable
member labels) was removed.

This version of the draft has catalog zones specified to the best of our
ability and we request you to review it thoroughly with the documents
readiness for WGLC in mind.

Op 25-10-2021 om 21:37 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : DNS Catalog Zones
> Authors : Peter van Dijk
>   Libor Peltan
>   Ondrej Sury
>   Willem Toorop
>   Leo Vandewoestijne
>   Peter Thomassen
>   Filename: draft-ietf-dnsop-dns-catalog-zones-04.txt
>   Pages   : 19
>   Date: 2021-10-25
> 
> Abstract:
>This document describes a method for automatic DNS zone provisioning
>among DNS primary and secondary nameservers by storing and
>transferring the catalog of zones to be provisioned as one or more
>regular DNS zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-04.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-04
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 36 Workshop, November 29th & 30th, Extending Call for Contributions

[Willem Toorop]

The Program Committee has decided to extend the Call for Contributions
until 15 Oct 2021 23:59 UTC.

Thank you if you've already submitted a proposal. We still haven't
filled the capacity and are able to accept more content. Please, do not
hesitate and send in your suggestions.

Updated Workshop Milestones:

* 25 August 2021 - Submissions open via Indico
* 11 October 2021 - Initial Contribution list published
* 15 October 2021 - Extended deadline for submission (23:59 UTC)
* 1 November 2021 - Full agenda published
* 16 November 2021 - Deadline for slideset submission and Rehearsal
* 29 & 30 November 2021 - OARC 36 Workshop

The details for presentation submission are published at the Workshop
website:

https://www.dns-oarc.net/oarc36

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 
Willem Toorop, for the DNS-OARC Programme Committee

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARConline 35a Registrations and OARC 36 Call for Contributions

[Willem Toorop]

OARConline 35a is around the corner and will be taking place online on
September 8th at 15:00 UTC. Registrations are now open at
<https://www.dns-oarc.net/oarc35a>.

OARC 36 will be an online meeting on November 29th & 30th starting at
10:00 UTC. The Programme Committee is seeking contributions from the
community.

All DNS-related subjects and suggestions for discussion topics are
welcome. For inspiration, we provide a non-exhaustive list of ideas:

- Deployment: Managing DNS changes and propagation, release process,
change management.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
- Scaling: Managing service capacity, failovers, disaster recovery.

As it is an online workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional time
for questions).

**Workshop Milestones:**

* 25 August 2021 - Submissions open via Indico
*  1 October 2021 - Deadline for submission (23:59 UTC)
* 11 October 2021 - Initial Contribution list published
*  1 November 2021 - Full agenda published
* 16 November 2021 - Deadline for slideset submission and Rehearsal
* 29 & 30 November 2021 - OARC 36 Workshop

The Registration page and details for presentation submission are
published at:

<https://www.dns-oarc.net/oarc36>

DNS-OARC provides registration fee waivers for the workshop to support
those who are part of underrepresented groups at DNS-OARC. See the
registration page for details.

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARC 36:

* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
* you will be expected to attend a rehearsal on November 16th. It would
be very useful to have your slides (even if draft) ready for this.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Willem Toorop, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-03.txt

[Willem Toorop]

Dear dnsop,

This version of the draft is the result of a big cleanup of the messy
state in which we delivered the previous version.  We have tried to
present the topics involved in catalog zone operations and the
(optional) properties that help out in streamlining those operations, as
a more coherent whole.

Op 25-08-2021 om 23:27 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : DNS Catalog Zones
> Authors : Peter van Dijk
>   Libor Peltan
>   Ondrej Sury
>       Willem Toorop
>   Leo Vandewoestijne
>   Filename: draft-ietf-dnsop-dns-catalog-zones-03.txt
>   Pages   : 20
>   Date: 2021-08-25
> 
> Abstract:
>This document describes a method for automatic DNS zone provisioning
>among DNS primary and secondary nameservers by storing and
>transferring the catalog of zones to be provisioned as one or more
>regular DNS zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-03.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-03
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARConline 35a Workshop, September 8th, Call for Contributions now open

[Willem Toorop]

OARConline 35a will be an online meeting on September 8th 2021 starting
at 15:00 UTC. The Programme Committee is seeking contributions from the
community.

All DNS-related subjects and suggestions for discussion topics are
welcome. For inspiration, we provide a non-exhaustive list of ideas:

- Deployment: Managing DNS changes and propagation, release process,
change management.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
- Scaling: Managing service capacity, failovers, disaster recovery.

As it is an online workshop, we'd like to encourage brevity;
presentations will be 10 or 20 minutes (including time for questions).

**Workshop Milestones:**

* 30 June 2021 - Submissions open via Indico
* 20 July 2021 - Deadline for submission (23:59 UTC)
* 27 July 2021 - Initial Contribution list published
* 10 August 2021 - Full agenda published
* 24 August 2021 - Deadline for slideset submission and Rehearsal
* 08 September 2021 - OARConline 35a Workshop

The Registration page and details for presentation submission are
published at:

<https://www.dns-oarc.net/oarc35a>

DNS-OARC provides registration fee waivers for the workshop to support
those who are part of underrepresented groups at DNS-OARC. See the
registration page for details.

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARConline 35a:

* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
* you will be expected to attend a rehearsal on August 24th. It would be
very useful to have your slides (even if draft) ready for this.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Willem Toorop, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

[Willem Toorop]

Op 22-03-2021 om 15:50 schreef Ben Schwartz:
> On Mon, Mar 22, 2021 at 5:41 AM Willem Toorop  <mailto:wil...@nlnetlabs.nl>> wrote:
> 
> But what about the keys in the "mandatory" SvcParam? Should they be
> sorted automatically? Or should the parser produce an error if they are
> not sorted? Currently both both Net::DNS and ldns sort them for you.
> 
> 
> The draft says:
> 
>    The presentation "value" SHALL be a comma-separated list
>    (Appendix A.1) of one or more valid SvcParamKeys, either by their
>    registered name or in the unknown-key format (Section 2.1).  Keys MAY
>    appear in any order, but MUST NOT appear more than once.
> 
> and
> 
>    In wire format, the keys are represented by their numeric values in
>    network byte order, concatenated in ascending order.
> 
> Hopefully that's clear enough.

Sure, so this:

x8.example. 3600IN  SVCB16 foo.example.org. (
key853="test" key123="some other text"
ipv4hint=192.0.2.1 mandatory=ipv4hint,alpn,key853,key123
alpn=h2,h3-19 ipv6hint=2001:db8::1.2.3.4,2001:db8::
)

is equivalent with

x8.example. 3600IN  SVCB( \# 115 0010
03666f6f076578616d706c65036f7267 00 ; foo.example.org.
 0008 00010004007b0355
0001 0009 0268320568332d3139
0004 0004 c201
0006 0020 20010db801020304
  20010db8
; key123=...
007b 000f 736f6d65206f746865722074657874
; key853=...
0355 0004 74657374
)

Would be good to have that in a test vector ;).

> What if keys appear double in the "mandatory" SvcParam? Should the
> parser produce an error or remove the doubles? Currently ldns removes
> them, but Net::DNS produces and error.
> 
> 
> I think authoritative servers "SHOULD" enforce the zone file
> requirements to the extent possible, but responsibility ultimately lies
> with the zone owner.

Excellent! How SHOULD it enforce? By failing to load or by fixing.
Most here tilt to *failing to load*, so these should fail to load:

; Forbidden key in mandatory
x9.example. 3600IN  SVCB0 . mandatory=key0
x10.example.3600IN  SVCB( \# 9  00
 0002 
)

; Double key in mandatory
x11.example.3600IN  SVCB0 . (
ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv4hint,alpn,key4
)
x12.example.3600IN  SVCB( \# 28  00
 0006 000100040004
0001 0003 026832
0004 0004 c201
)

; Key without SvcParam in mandatory
x13.example.3600IN  SVCB0 . (
ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv6hint,alpn,key4
)
x14.example.3600IN  SVCB( \# 28  00
 0006 000100040006
0001 0003 026832
0004 0004 c201
)

I think it would be good to have this added to the test-vectors appendix.

Should this fail to load too?

; Wireformat has SvcParams unordered
x15.example.3600IN  SVCB( \# 26  00
0004 0004 c201
0001 0003 026832
 0004 00010004
)

or am I stretching it now...

Cheers,
-- Willem

> 
> What if keys that may not appear in "mandatory" (like key0 or mandatory
> itself) appear in the "mandatory" SvcParam? Should they be removed
> automatically or should they produce and error.
> 
> What if keys that are listed in "mandatory" do not appear in the RR.
> 
> 
> The draft says:
> 
>    For self-
>    consistency (Section 2.4.3), listed keys MUST also appear in the
>    SvcParams.
> 
> and (in Section 2.4.3)
> 
>    Zone-file implementations
>    SHOULD enforce self-consistency.  Clients MUST reject any RR whose
>    recognized SvcParams are not self-consistent, and MAY reject the
>    entire RRSet.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

[Willem Toorop]

Op 19-03-2021 om 18:03 schreef Pieter Lexis:
> Hi Willem,
> 
> On 3/19/21 11:47 AM, Willem Toorop wrote:
>> That'd be nice!
> 
> PR is here [1].
> 
>> Do you also have tests for peculiar/corner and failure cases?
> 
> I'm a little bit unsure what you men with this :).

Well, I am wondering how much the parser should just normalize or
produce a syntax error instead. I noticed from the 7th example in your
PR, that you automatically put the SvcParams in the correct order, so
you apply normalization there in the sense that your parser sorts the
SvcParams. So do Net::DNS and (unreleased) ldns b.t.w.

But what about the keys in the "mandatory" SvcParam? Should they be
sorted automatically? Or should the parser produce an error if they are
not sorted? Currently both both Net::DNS and ldns sort them for you.

What if keys appear double in the "mandatory" SvcParam? Should the
parser produce an error or remove the doubles? Currently ldns removes
them, but Net::DNS produces and error.

What if keys that may not appear in "mandatory" (like key0 or mandatory
itself) appear in the "mandatory" SvcParam? Should they be removed
automatically or should they produce and error.

What if keys that are listed in "mandatory" do not appear in the RR.

What if there is a DNSSEC signature alongside the SVCB or HTTPS RR?
Should normalization be applied to the rdata then?

What if the SVCB and/or HTTPS is not parsed by an authoritative, but
received via AXFR or IXFR? Or dynamic updates?

Also, I love the annotated RFC3597 format that Net::DNS produces and I
think we should use that in the test-vectors!

> The code is here[2].
> I've also opened a PR updating our parser for the draft-03 changes for
> multiple values, that one also has some tests for the value parser[3].
> 
> Cheers,
> 
> Pieter
> 
> 1 - https://github.com/MikeBishop/dns-alt-svc/pull/307
> 2 -
> https://github.com/PowerDNS/pdns/blob/3a63bb5fca1c45a6e9dee808a56ca6cbea2be0d8/pdns/test-dnsrecords_cc.cc#L209-L230
> 3 -
> https://github.com/PowerDNS/pdns/pull/10074/files#diff-1c55ae7b2d1073637c05a035de9ef6688ecffb209e50b3bef8b3d9ea1c5a329dR308-R393
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] OARC 35 Workshop, May 6th & 7th, Registration and Call for Contributions now open

[Willem Toorop]

The Program Committee decided to extend the Call for Contributions
until 25 Mar 2021 23:59 UTC (a week from now).

Thank you if you have already submitted a proposal. We still have
capacity to accommodate a few more talks. Please, do not hesitate and
send in your suggestions.

The upcoming milestones are:

* 25 Mar 2021 - Deadline for submission (23:59 UTC)
* 25 Mar 2021 - Initial Contribution list published
* 08 Apr 2021 - Full agenda published
* 22 Apr 2021 - Deadline for slideset submission and Rehearsal
* 06 May 2021 - OARC 35 Workshop

Willem Toorop, for the DNS-OARC Programme Committee


Op 22-02-2021 om 10:16 schreef Willem Toorop:
> OARC 35 will be an online meeting on May 6th & 7th starting at 01:00
> UTC. The Programme Committee is seeking contributions from the community.
> 
> All DNS-related subjects and suggestions for discussion topics are
> welcome. For inspiration, we provide a non-exhaustive list of ideas:
> 
> - Stories of DNS Migrations: Reasoning for DNS software migration.
>   Tooling used to ensure a smooth and correct process.
> - DNS Intricacies: Chasing down problems and surprising behavior.
> - Garbage Traffic: Analysis on unexpected traffic seen by authoritative
>   and recursive servers.
> - DITL: Day In The Life of various roles and teams in DNS.
> 
> As it is an online workshop, we'd like to encourage brevity;
> presentations should not be longer than 20 minutes (with additional time
> for questions).
> 
> **Workshop Milestones:**
> 
> * 04 Feb 2021 - Submissions open via Indico
> * 18 Mar 2021 - Deadline for submission (23:59 UTC)
> * 25 Mar 2021 - Initial Contribution list published
> * 08 Apr 2021 - Full agenda published
> * 22 Apr 2021 - Deadline for slideset submission and Rehearsal
> * 06 May 2021 - OARC 35 Workshop
> 
> The Registration page and details for presentation submission are
> published at:
> 
> <https://www.dns-oarc.net/oarc35>
> 
> DNS-OARC provides registration fee waivers for the workshop to support
> those who are part of underrepresented group at DNS-OARC. See the
> registration page for details.
> 
> To allow the Programme Committee to make objective assessments of
> submissions, so as to ensure the quality of the workshop, submissions
> SHOULD include slides. Draft slides are acceptable on submission.
> 
> Additional information for speakers of OARC 35:
> 
>   * your talk will be broadcast live and recorded for future reference
>   * your presentation slides will be available for delegates and others
> to download and refer to, before, during and after the meeting
>   * you will be expected to attend a rehearsal on April 22nd. It would
> be very useful to have your slides (even if draft) ready for this.
> 
> If you have questions or concerns you can contact the Programme Committee:
> 
> https://www.dns-oarc.net/oarc/programme
> 
> via 
> 
> Willem Toorop, for the DNS-OARC Programme Committee
> 
> OARC depends on sponsorship to fund its workshops and associated social
> events.  Please contact  if your organization is
> interested in becoming a sponsor.
> 
> (Please note that OARC is run on a non-profit basis, and is not in a
> position to reimburse expenses or time for speakers at its meetings.)
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

[Willem Toorop]

Op 19-03-2021 om 11:19 schreef Pieter Lexis:
> Hi Willem, Ben,
> 
> On 3/19/21 11:14 AM, Willem Toorop wrote:
>> Also, it would have been nice to have some test-vectors of RR's in
>> presentation format and wire format (in hexdump) in an appendix in the
>> document, to assist in the creation of interoperable implementations.
>> Maybe this can still be added?
> 
> +1000
> 
> The PowerDNS unit tests already has a bunch of tests that do the
> presentation -> wire -> presentation roundtrip. I could convert those to
> using example.com, use some more hex and send a PR to the authors should
> they want this.

:+1:

That'd be nice!

Do you also have tests for peculiar/corner and failure cases?

Cheers,
-- Willem

> 
> Cheers,
> 
> Pieter
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

[Willem Toorop]

No version of NSD, Unbound, ldns and getdns with SVCB and HTTPS support
has been released yet, so no problem for us to change the name of
SvcParamKey 5 to ech for us there, but ...

The Net::DNS perl library does have parsing and printing of SVCB and
HTTPS based on draft-ietf-dnsop-svcb-https-01 since version 1.26
(released on August 6, 2020). @Dick, what is your position on this?

I am aware of only 1 deployed HTTPS RR with echconfig:

crypto.cloudflare.com.  300 IN  HTTPS   1 . alpn=h2
ipv4hint=162.159.135.79,162.159.136.79
echconfig=AEf+CQBDABNjbG91ZGZsYXJlLWVzbmkuY29tACAjs5LfHm27uMBFmLDI++shXFnrIB3tDgU6gMZfkJoFYAAgAAQAAQABAA==
ipv6hint=2606:4700:7::a29f:874f,2606:4700:7::a29f:884f

Also, it would have been nice to have some test-vectors of RR's in
presentation format and wire format (in hexdump) in an appendix in the
document, to assist in the creation of interoperable implementations.
Maybe this can still be added?

-- Willem

Op 19-03-2021 om 09:05 schreef libor.peltan:
> FYI in Knot DNS, the implementation is at exactly the same state: an
> existing merge request. For us, it's technically no issue if the
> presentation/wire format changes during next few weeks.
> 
> I'm saying nothing about ideological consequences of such approach.
> 
> /Libor
> 
> Dne 19. 03. 21 v 0:05 Mark Andrews napsal(a):
>>
>>> On 19 Mar 2021, at 04:42, Tommy Pauly
>>>  wrote:
>>>
>>>
>>>
 On Mar 17, 2021, at 6:04 PM, Ben Schwartz
  wrote:

 Release notes for this revision:
    *  Simplify the IANA instructions (pure First Come First Served)
    *  Recommend against publishing chains of >8 aliases
    *  Clarify requirements for using SVCB with a transport proxy
    *  Adjust guidance for Port Prefix Naming
    *  Minor editorial updates

 I'm only aware of one outstanding issue: a proposal to change the
 name of the "echconfig" key to "ech".  This key corresponds to a
 value that is an "ECHConfigList", which is a collection of
 "ECHConfig" structs, and some implementers have reported that the
 singular/plural name-value mismatch created confusion.  This issue
 is discussed in detail here:
 https://github.com/MikeBishop/dns-alt-svc/pull/299.

 This name has no effect on queries, responses, or zone transfers,
 but it does appear in zone files.  Zone files will not be portable
 between implementations that use different names.  This is true
 whether we "burn" the current codepoint and allocate a new one, or
 simply rename the current codepoint.  However, using a new codepoint
 would allow updated implementations to support both names,
 facilitating zone file portability in one direction.  It would also
 be possible to support the old name with special-case name aliasing
 logic.

 In my view, the temporary portability benefit is too small to
 justify the permanent registry pollution of a deprecated codepoint,
 especially because ECH itself is not yet finalized, and there are no
 deployments except for standards development purposes.  However,
 others have disagreed.  We'll need to reach consensus before making
 any changes here.
>>> Personally, I’d prefer to see the name change, and not burn a
>>> codepoint, as long as we’re not breaking any zone files.
>>>
>>> I think the question is: does anyone have a zone that has actually
>>> deployed the echconfig parameter? I see many responses with
>>> SVCB/HTTPS records, but none with the echconfig in practice. If
>>> someone is aware of a production deployment that can’t move, please
>>> speak up!
>>>
>>> Tommy
>> It’s not so much is it in use or not.  As I said this is a process
>> issue.  When
>> the code point was assigned the way it was the wire and presentation
>> formats are
>> supposed to be *frozen* as that allows DNS developer to deploy code
>> without having
>> to worry about the specification changing underneath them.
>>
>> For BIND we haven’t shipped code with SVBC / HTTPS code points yet
>> even to the
>> point of parsing the records.  We have merge request that has been
>> tracking the
>> draft.  I never felt the specification was stable enough to do that
>> and unfortunately
>> I was correct.  ALPN has had its parsing changed, the same
>> presentation format produces
>> different wire formats.  echconfig vs ech is minor compared to that.
>>
>> I have not looked to see what other DNS vendors have done so far.
>>
>> If we go ahead there needs to be a section that specified the
>> differences in
>> parsing between the draft when the code point was issued and when the
>> RFC is
>> published.
>>
>> Mark
>>
 --Ben

 On Wed, Mar 17, 2021 at 1:11 PM  wrote:

 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.
 This draft is a work item of the Domain Name System Operations WG of
 the IETF.

  Title   : Service binding and paramete

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-02.txt

[Willem Toorop]

Dear dnsop,

We have been thinking & working hard on how to facilitate:
  - updates,
  - state resets,
  - change of configuration,
  - change of ownership and
  - custom configuration
for member zones in a catalog zone, catering the best for operators and
different implementations. The current document reflects all those
mechanisms and approaches which we believe can work together nicely.
That said, the document is currently very much a work-in-progress on
which the dust has not yet settled. It is in a bit of a rough and
inconsistent shape for which we want to apologize.

We hope to tell you all about the recent developments on the document
during one of the dnsop sessions on Thursday the 11th of Match in the
upcoming IETF110!

Op 22-02-2021 om 22:35 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : DNS Catalog Zones
> Authors : Peter van Dijk
>   Libor Peltan
>   Ondrej Sury
>   Willem Toorop
>   Leo Vandewoestijne
>   Filename: draft-ietf-dnsop-dns-catalog-zones-02.txt
>   Pages   : 18
>   Date: 2021-02-22
> 
> Abstract:
>This document describes a method for automatic DNS zone provisioning
>among DNS primary and secondary nameservers by storing and
>transferring the catalog of zones to be provisioned as one or more
>regular DNS zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-02.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 35 Workshop, May 6th & 7th, Registration and Call for Contributions now open

[Willem Toorop]

OARC 35 will be an online meeting on May 6th & 7th starting at 01:00
UTC. The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are
welcome. For inspiration, we provide a non-exhaustive list of ideas:

- Stories of DNS Migrations: Reasoning for DNS software migration.
  Tooling used to ensure a smooth and correct process.
- DNS Intricacies: Chasing down problems and surprising behavior.
- Garbage Traffic: Analysis on unexpected traffic seen by authoritative
  and recursive servers.
- DITL: Day In The Life of various roles and teams in DNS.

As it is an online workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional time
for questions).

**Workshop Milestones:**

* 04 Feb 2021 - Submissions open via Indico
* 18 Mar 2021 - Deadline for submission (23:59 UTC)
* 25 Mar 2021 - Initial Contribution list published
* 08 Apr 2021 - Full agenda published
* 22 Apr 2021 - Deadline for slideset submission and Rehearsal
* 06 May 2021 - OARC 35 Workshop

The Registration page and details for presentation submission are
published at:

<https://www.dns-oarc.net/oarc35>

DNS-OARC provides registration fee waivers for the workshop to support
those who are part of underrepresented group at DNS-OARC. See the
registration page for details.

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARC 35:

  * your talk will be broadcast live and recorded for future reference
  * your presentation slides will be available for delegates and others
to download and refer to, before, during and after the meeting
  * you will be expected to attend a rehearsal on April 22nd. It would
be very useful to have your slides (even if draft) ready for this.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Willem Toorop, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF 110 Agenda and Call for Agenda Items DNSOP WG

[Willem Toorop]

I'd like to request 20 minuted for draft-ietf-dnsop-dns-catalog-zones.
We have a lot to discuss!

Op 18-02-2021 om 17:23 schreef Benno Overeinder:
> Hi all,
> 
> The IETF 110 Agenda is out https://datatracker.ietf.org/meeting/110/agenda.
> 
> DNSOP has two sessions scheduled:
> 
>     dnsop Session 1 (1:00 requested)
>     Thursday, 11 March 2021, Session II 1530-1630
>     Room Name: Room 4 size: 504
>     -
>     dnsop Session 2 (2:00 requested)
>     Thursday, 11 March 2021, Session III 1700-1900
>     Room Name: Room 6 size: 506
>     -
> 
> iCalendar: https://datatracker.ietf.org/meeting/110/sessions/dnsop.ics
> 
> 
> This is also a Call for Agenda Items.  Please email the chairs
>  with your requests.  *Or* drop us a pull request
> https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf110
> look for dnsop-ietf110-agenda-requests.md.
> 
> Please Note: Draft Submission Deadline is Monday 22 February 2021.
> 
> See https://datatracker.ietf.org/meeting/important-dates/:
> * 2021-02-22 (Monday): Internet Draft submission cut-off (for all
> drafts, including -00) by UTC 23:59.  Upload using the ID Submission
> Tool https://datatracker.ietf.org/submit/.
> 
> 
> Thanks,
> 
> Suzanne
> Tim
> Benno
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Various Thoughts on Catalog Zones (draft-ietf-dnsop-dns-catalog-zones-01)

[Willem Toorop]

Peter, Thank you!

I am intrigued by your suggestion to use CSYNC RR to signal SOA Serial
numbers and to help out in. And indeed, the flags in CSYNC's flags rdata
field appear to have helpful names and meanings with respect to clashing
member zones and member zone transitions. What a good catch! How did we
miss that?

We will work to have a new version submitted before the IETF110 deadline
(Monday the 22th). Let's discuss and see if and how we can incorporate this.

-- Willem


Op 08-02-2021 om 18:00 schreef Peter Thomassen:
> Hi,
> 
> As we've been facing the "zone provisioning and removal problem" for a 
> while, I recently looked at draft-ietf-dnsop-dns-catalog-zones-01.  I 
> think it's a great effort in the right direction, and I'm glad to see 
> it moving!
> 
> I have various thoughts on the current proposal (mostly on serial 
> signaling and on advanced use cases), and figured I'd post them here.
> 
> The discussion ventures in several directions (not necessarily all 
> compatible), so I hope you have a cup of tea ready.  If this should 
> have gone into several threads, please let me know for the future (and 
> accept my apologies in advance).
> 
> 
> 1. Non-exposure
> ---
> 
> The last paragraph of Section 3 says:
>> It is not expected that the content of catalog zones will be
>> accessible from any recursive nameserver.
> 
> In light of this, it may be useful to state that catalog zones SHOULD 
> reside under "internal.".
> 
> Rationale:
> 
> a) It helps lower the administrative burden without enumerating catalog 
>zones. (In dnsdist, for example, it's enough to do 
>`addAction("internal.", RCodeAction(DNSRCode.REFUSED))`.)
> 
> b) Similarly, public-facing software may choose to categorically refuse 
>queries into "internal.", without necessarily being aware of the 
>catalog zone mechanism.  (A configuration option to turn this on or 
>off notwithstanding.)
> 
> c) It also prevents mistakes like accidentally shadowing parts of 
>another zone by mounting the catalog zone underneath (KnotDNS warns 
>against this [1]).
> 
> However, please see point 3 of this message, which is in contradiction 
> to this proposal.
> 
> [1]: https://www.knot-dns.cz/docs/3.0/singlehtml/index.html#catalog-zones
> 
> 
> 2. Serial Property
> --
> 
> The idea of (optionally) communicating the SOA serial through the 
> catalog is highly intriguing.  To that end, the document proposes the 
> new SERIAL record type, outlining several different methods of using 
> it.  At the same time, paragraph 3 of Section 5 contains provisions for 
> the case that the serial of the zone currently deployed on the 
> secondary is larger than the value of the serial property.  In that 
> case, the document says that the transfer MUST be aborted.
> 
> I see several issues here:
> 
> a) It is unclear to me whether decreasing serial numbers must really be 
>avoided at all times.  In particular, it is possible that catalog  
>zones may displace the serial mechanism in the future, and operators 
>may decide to make replication decisions based on other criteria 
>(such as a changing "" label, or whatever else).
> 
>I am pointing this out because increasing serials come with serious 
>conceptual and implementional cost [2, 3].  It therefore seems to me 
>that enforcing the maintenance of serial logic indefinitely may 
>introduce an undue level of technical debt.
> 
>My suggestion would thus be to change this to SHOULD, if making any 
>provisions at all.  (Implementors are, of course, free to offer 
>functionality that does what you'd except for increasing serials -- 
>I just don't think it should be a normative statement.)
> 
> [2]: https://tools.ietf.org/html/rfc1982
> [3]: 
> https://doc.powerdns.com/authoritative/dnssec/operational.html#soa-edit-ensure-signature-freshness-on-slaves
> 
> b) A new record type is introduced (SERIAL).  Its content is very 
>similar to the CSYNC record type from RFC 7477 (which has a serial 
>field, flags, and an NSEC-style type bitmap) [4].  Instead of 
>introducing a new record type, I'd like to suggest reusing CSYNC.
> 
>One may object that CSYNC records are larger than SERIAL.  While 
>true in principle, the effect is very small:  At least the last 
>field (type bitmap) does not take up any space if it is empty.
> 
>That leaves us with the "flags" field (16 bits).  The CSYNC record 
>currently has two possible flags, 0x01 ("immediate") and 0x02 
>("soaminimum").  The first dictates whether an action should be 
>triggered automatically (or only after out-of-band approval), and 
>the second governs the behavior regarding the issue discussed above 
>under a), namely what to do if the serial given in the record is 
>"out of order".
> 
>I think that these two flags are very well suited for the purposes 
>of catalog zones (with an anologuous meaning).  In pa

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-05.txt

[Willem Toorop]

Dear DNSOP, Stephen and Benjamin,

After IESG evaluation it was decided that we needed to post a revised
version of the DNS Server Cookies draft, with the DISCUSS position
resolved. Also SECDIR review had a "Has Issues" result.
This is that revised version.

To resolve the SECDIR review issues and DISCUSS positions, this version
has timing recommendations in section 4.3 and section 5 aligned, and has
more/better text on the properties and requirements of the Server Cookie
and the pseudorandom function used in its calculation. The document also
has extra text around timestamp compares.

Besides these blocking issues IESG provided a *lot* of COMMENTs and
suggestions which we have (almost) all addressed. Below I have included
a log of those changes.

Stephen and Benjamin, could you please review and see if your Issues and
DISCUSS positions are resolved, and if so, change those statuses?
Thanks!

Changes
===
Comments from Stephen Farrell:

  * Remove "strong" in "strong cookie" in section 1
  * Point out more explicitly the Timestamp field is **unsigned** and
tell RFC1982 handles difference in the future even in case of
wrap-arounds.
  * Use an authoritative citation for SipHash-2-4

Comments from Benjamin Kaduk:

  * Fix timing inconsistency of section 4.3 and section 5
  * Motivate the use of SipHash-2-4 as pseudorandom function
  * Consolidate everything after the first paragraph in the Abstract
into a single second paragraph
  * Single implementation no anycast services also benefit for a well-
studies algorithm
  * Avoid the word 'nonce' with Client Cookies
  * Language style improvements in "tracking of Client Cookies
prevention" description
  * Make the single server case more explicit in Server Cookie
construction description
  * A DNS Server MAY generate a new Server Cookie more often than every
half hour
  * Length verification of Server Cookies so byte string input into
SipHash-2-4 is injective and not susceptible to data substitution \
attacks.
  * Explain how different Client Cookie for each server provides minimal
authentication (in Section 3)
  * Provide Security Considerations for Server Cookies
  * Mention Timestamp values in test vector examples
  * Miscellaneous other minor editorial suggestions

Comments from Erik Kline:

  * Section 1: s/in a Client protecting fashion/in a privacy protecting
fashion/
  * Section 8: s/five minute/five minutes/
  * Mention that "tracking of the public IP of a NAT" is beyond the
scope of this document

Comments from Roman Danyliw:

  * Use an authoritative citation for SipHash-2-4
  * Be clear on the notation of SipHash-2-4 (with dashes)

Comments from Murray Kucherawy:

  * Fix linebreaks in section 7
  * Remove Section 1.1 "Contents of this document"

Comments from Barry Leiba:

  * Suggest implementation-defined period of time to renew Client Cookie
(with one year as the maximum limit)
  * Implementations MUST set reserved bits to 0 when constructing a
cookie (but not when verifying!)

Comments from Éric Vyncke:

  * Fix capitalization of "client" and "server"
  * More consistent summary of the types of attacks
  * Mention that "tracking of the public IP of a NAT" is beyond the
scope of this document

Comments from Robert Wilton:

  * Suggest implementation-defined period of time to renew Client Cookie
(with one year as the maximum limit)
  * Repeat that "Changing the Server Secret regularly is RECOMMENDED" in
Section 5

Cheers,
-- Willem

Op 13-01-2021 om 15:33 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : Interoperable Domain Name System (DNS) Server 
> Cookies
> Authors : Ondrej Sury
>   Willem Toorop
>   Donald E. Eastlake 3rd
>   Mark Andrews
>   Filename: draft-ietf-dnsop-server-cookies-05.txt
>   Pages   : 18
>   Date: 2021-01-13
> 
> Abstract:
>DNS Cookies, as specified in [RFC7873], are a lightweight DNS
>transaction security mechanism that provide limited protection to DNS
>servers and clients against a variety of amplification denial of
>service, forgery, or cache poisoning attacks by off-path attackers.
> 
>This document updates [RFC7873] with precise directions for creating
>Server Cookies so that an anycast server set including diverse
>implementations will interoperate with standard clients, suggestions
>for constructing Client Cookies in a privacy preserving fashion, and
>suggestions on how to update a Server Secret.  An IANA registry
>

Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

[Willem Toorop]

Op 17-12-2020 om 08:37 schreef Éric Vyncke via Datatracker:
> --
> COMMENT:
> --

Thank you for your feedback Éric,

> -- Section 3 --
> I like that a Client cookie must be changed upon local IP address change but I
> am afraid that there is no way to detect that a provider Carrier Grade NAT
> (CGN) is using round robin among a pool of public address; this still allows
> for client tracking as the client cookie is unchanged even if the public IP
> address has changed. Should there be some text around this issue or in the
> security section ?

Agree, I have a soon to be submitted revised document that has a
paragraph on tracking of public IP of a NAT devices being beyond the
scope of the document. See:


https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/pull/23/commits/83155e4bfed1afb08611723a13f9ebc045179e63

> 
> -- Section 4.4 --
> Should there be a recommended minimum length of the shared secret (or entropy
> level) ?

With SipHash-2-4, the secret is fixed length: 128 bits.

> -- Section 6 --
> In "This document REQUIRES compliant DNS Server to use SipHash-2.4 as a
> mandatory and default algorithm for DNS Cookies", I wonder whether "a 
> mandatory
> and default" is required as only one algorithm is specified and there is a
> "REQUIRES".

Well, there could be more algorithms in the future, but in that case
this one will be the default one.


Your other comments and nits are addressed in the revised document.
Except for the suggestion for a different title, which we're still
discussing.

Cheers,
-- Willem

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Martin Duke's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

[Willem Toorop]

Op 16-12-2020 om 19:55 schreef Martin Duke via Datatracker:
> --
> COMMENT:
> --
> 
> It seems to me the mechanisms in Section 5 would be simplified by using some
> the reserved bit to have an identifier for the secret.

Thanks Martin for the suggestion,

We actually considered this idea ourselves in an early stage of the
document, but have rejected it, because it would require the identifier
to be derived from the Server Secret somehow so that all servers in the
anycast set associate the id with the same secret. Also, there is almost
always just 1 Server Secret. Only when a Server Secret is updated (which
should takes a limited amount of time), using an identifier for the
Server Secret would be slightly more efficient.

Cheers,
-- Willem

> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

[Willem Toorop]

Thank you Murray for your review,

Op 16-12-2020 om 07:31 schreef Murray Kucherawy via Datatracker:
> --
> COMMENT:
> --
> 
> In Section 3 there's a line that says "Client-Cookie = 64 bits of entropy"
> which is both (a) not a sentence, and (b) the same as something said in the
> first paragraph of this section.  I think it can be removed.

It is an ascii-art showing how the value of the Client Cookie is
determined, similar to how there is an ascii-art for the Hash value in
the Server Cookie in section 4.4.

> Also in Section 7, you're creating a registry with Expert Review, but there's
> no particular guidance offered to the Designated Expert once one is assigned,
> as suggested by RFC 8126.  Are we all OK with that?  You might advise, for
> example, that the registration of a new Method really should have a
> specification someplace.

The revised document (posted soon) does have more text on the
requirements for the pseudorandom function (though not in Section 7
itself). Also, we don't really expect a new algorithm anytime soon.

Your other comments have been addressed in the revised document.

Cheers,
-- Willem

> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

[Willem Toorop]

Thank you Roman for your review,

Op 16-12-2020 om 01:00 schreef Roman Danyliw via Datatracker:
> --
> COMMENT:
> --
> 
> ** Section 7.  For future agility, should a “recommended” column be
> sub-registry just as was added to
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> or is the thinking that there will only be serial updates of the cookie
> algorithm where concurrent use is not expected?

I think that this is not necessary as we do not expect new algorithms to
be added any time soon.  I suppose we could still consider it when and
if it becomes an issue.

Your other comments have been addressed in a revised document that will
be posted for review soon.

Cheers,
-- Willem

> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

[Willem Toorop]

Op 15-12-2020 om 09:10 schreef Erik Kline via Datatracker:
> --
> COMMENT:
> --
> 
> [ questions ]]
> 
> [ section 3 ]
> 
> * I assume it's not a big deal that sometimes the client cannot easily
>   tell when its upstream IP address has changed (vis. RFC 7873 S6
>   considerations)?
> 
>   NAT makes it difficult to comply with the MUST for clients stated
>   in section 8, but...what should a client do if only has, say, an
>   RFC 1918 address and is quite likely to be behind a NAT?  If its
>   server is also a likely-NAT'd IP then it might presume no NAT between
>   the two, but if the server has a global IP address...I suppose it
>   can just rotate the per-server cookies once per year?

Thanks Erik,

Indeed, I have added a paragraph to the Security Considerations that
preventing tracking of the public IP of a routing device that performs
NAT is beyond the scope of this document, see:


https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/pull/23/commits/83155e4bfed1afb08611723a13f9ebc045179e63

The nits have been processed too.

Cheers,
-- Willem

> [[ nits ]]
> 
> [ section 1 ]
> 
> * Final sentence of the final paragraph:
>   "in a Client protecting fashion" ->
>   "in a privacy protecting fashion"? (to match the abstract)
> 
> [ section 8 ]
> 
> * "five minute" -> "five minutes"
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 34 Workshop, February 4th & 5th, Deadline for Contributions extended to 11/01/2021 23:59

[Willem Toorop]

OARC 34 will be an online meeting on February 4th & 5th starting at
16:00 UTC. The Programme Committee is seeking contributions from the
community.

The deadline for submissions has been extended to the 11th of January

All DNS-related subjects and suggestions for discussion topics are
welcome. Based on the feedback from the previous workshop, the DNS-OARC
audience is interested to see more content related to DNS operations.
Therefore we are particularly interested in submissions from DNS
Operators about attack mitigation and any major (public or non-public)
DNS outages that your organization might have faced over the last year
or so, the steps taken to resolve/mitigate the immediate issue, and to
prevent future such events and any lessons learned.

As it is an online workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional time
for questions).

**Workshop Milestones:**

*  9 Dec 2020 - Submissions open via Indico
* 11 Jan 2021 - Deadline for submission (23:59 UTC)
* 14 Jan 2021 - Initial Contribution list published
* 21 Jan 2021 - Full agenda published
* 28 Jan 2021 - Deadline for slideset submission and Rehearsal
*  4 Feb 2021 - OARC 34 Workshop

The Registration page and details for presentation submission are
published at:

<https://www.dns-oarc.net/oarc34>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARC 34:

  * your talk will be broadcast live and recorded for future reference
  * your presentation slides will be available for delegates and others
to download and refer to, before, during and after the meeting
  * you will be expected to attend a rehearsal on January 28th. It would
be very useful to have your slides (even if draft) ready for this.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Willem Toorop, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Implementation status for ZONEMD?

[Willem Toorop]

Op 22-12-2020 om 01:07 schreef Benno Overeinder:
> Hi Paul,
> 
> On 18/12/2020 22:57, Paul Hoffman wrote:
>> Greetings. Now that ZONEMD is waiting in the RFC Editor's queue, I was
>> wondering how the developers are coming with implementation. The
>> protocol is ripe for two-party testing.
> 
> 
> 
> We have implemented ZONEMD (verification and DNSSEC validation) in
> Unbound, ready to be merged into the main branch and released early next
> year.


Recently, also the ldns library has been extended with zone-digest
functionality. ZONEMD RRs can now be calculated and added with
ldns-signzone , and verified with ldns-verify-zone .
This is available on the develop branch on

https://github.com/NLnetLabs/ldns

this will also be released early next year.


Usage: ldns-signzone [OPTIONS] zonefile key [key [key]]
  signs the zone with the given key(s)
  -z <[scheme:]hash>Add ZONEMD resource record
 should be "simple" (or 1)
 should be "sha384" or "sha512" (or 1 or 2)
this option can be given more than once
  -ZAllow ZONEMDs to be added without signing



Usage: ldns-verify-zone [OPTIONS] 
Reads the zonefile and checks for DNSSEC errors.

It checks whether NSEC(3)s are present, and verifies all signatures
It also checks the NSEC(3) chain, but it will error on opted-out delegations
It also checks whether ZONEMDs are present, and if so, needs one of them
to match the zone's data.

OPTIONS:
-Z  Requires a valid ZONEMD RR to be present.
When given once, this option will permit verifying
just the ZONEMD RR of an unsigned zone. When given
more than once, the zone needs to be validly DNSSEC
signed as well.


Cheers,

-- Willem

> 
> 
> Cheers,
> 
> -- Benno
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 34 Workshop, February 4th & 5th, Registration and Call for Contributions now open

[Willem Toorop]

Hi All,

OARC 34 will be an online meeting on February 4th & 5th starting at
16:00 UTC. The Programme Committee is seeking contributions from the
community.

All DNS-related subjects and suggestions for discussion topics are
welcome. Based on the feedback from the previous workshop, the DNS-OARC
audience is interested to see more content related to DNS operations.
Therefore we are particularly interested in submissions from DNS
Operators about attack mitigation and any major (public or non-public)
DNS outages that your organization might have faced over the last year
or so, the steps taken to resolve/mitigate the immediate issue, and to
prevent future such events and any lessons learned.

As it is an online workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional time
for questions).

**Workshop Milestones:**

*  9 Dec 2020 - Submissions open via Indico
*  4 Jan 2021 - Deadline for submission (23:59 UTC)
* 14 Jan 2021 - Initial Contribution list published
* 21 Jan 2021 - Full agenda published
* 28 Jan 2021 - Deadline for slideset submission and Rehearsal
*  4 Feb 2021 - OARC 34 Workshop

The Registration page and details for presentation submission are
published at:

<https://www.dns-oarc.net/oarc34>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARC 34:

  * your talk will be broadcast live and recorded for future reference
  * your presentation slides will be available for delegates and others
to download and refer to, before, during and after the meeting
  * you will be expected to attend a rehearsal on January 28th. It would
be very useful to have your slides (even if draft) ready for this.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Willem Toorop, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt

[Willem Toorop]

Hi All,

This new version has two new sections: "The Serial Property" and
"Implementation Status".

During the last hackathon at IETF-109, a new idea emerged where the
version of a member zone in a catalog (indicated by the member zone's
SOA serial number) is also in the catalog. This can help ensuring
dissemination of member zones in a catalog from the primary to the
secondary nameservers will happen in a timely fashion more reliably, and
can also alleviate the burden on primary nameservers in cases where
there are a large number of secondary nameservers serving a large number
of zones.

This is presented in the new section 5: "The Serial Property"

The section also presents three different ways to provide a "serial"
property with a member zone.

We invite the workgroup to review this section thoroughly, and discuss
whether or not this is a good idea, and if so, what way to provide a
"serial" property would be best.


The new section "Implementation Status", lists production ready
implementations, as well as upcoming and Proof of Concept
implementations. Experience gained during the IETF hackathon also
reported in this section.


Op 04-12-2020 om 23:33 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : DNS Catalog Zones
> Authors : Peter van Dijk
>       Libor Peltan
>   Ondrej Sury
>   Willem Toorop
>   Leo Vandewoestijne
>   Filename: draft-ietf-dnsop-dns-catalog-zones-01.txt
>   Pages   : 15
>   Date: 2020-12-04
> 
> Abstract:
>This document describes a method for automatic DNS zone provisioning
>among DNS primary and secondary nameservers by storing and
>transferring the catalog of zones to be provisioned as one or more
>regular DNS zones.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-01.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Willem Toorop]

Op 02-12-2020 om 23:31 schreef Stephen Farrell:



> FWIW, I'd say it's worth a few more words to try reduce
> the probability of such failures happening, e.g. maybe
> just highlighting the "unsigned/2106" point you made
> above would be enough. But, if the WG don't want to do
> that, that's also fine by me.

Sure, NP. I'll include Brian Dicksen's provided clarification in the
text. Also, I approached Jean-Philippe Aumasson and he fixed the url we
used in the draft for SipHash, but recommends to use this one in the future:

https://www.aumasson.jp/siphash/

So I'll change that too.

Cheers,
-- Willem

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Willem Toorop]

Op 02-12-2020 om 22:49 schreef Stephen Farrell:
> 
> Hiya,
> 
> On 02/12/2020 21:38, Willem Toorop wrote:
>> Op 02-12-2020 om 21:37 schreef Stephen Farrell:
>>
>> 
>>
>>>> ad 2) we need a value that’s synchronized well enough and monotonic.
>>>> I honestly don’t see any value in using 64-bit value here. Using
>>>> unixtime has a value in itself, it’s a well-known and there’s a
>>>> little room for any implementer to make a mistake in an
>>>> implementation. The interoperability is more important than the
>>>> actual value of the counter. It’s write only counter, nobody is going
>>>> to interpret it after it has been generated, and it’s wide enough to
>>>> prevent brute forcing.
>>>
>>> So what happens after 2038? That's really not v. far in the
>>> future any more.
>>
>> The draft states that `All comparisons involving these fields MUST
>> use "Serial number arithmetic", as defined in [RFC1982]'. So it can not
>> be used to compare differences larger than 68 years, but comparisons of
>> cookie timestamps are more in the "hours" order of magnitude.
> 
> Sorry for being dim, but is clear what value to put
> in those 4 octets in say 2039 such that different
> implementations will do the right thing
Well the text does specify an "32-bit unsigned number of seconds elapsed
since 1 January 1970 00:00:00 UTC", so because of the "unsigned" the
wrap to 0 is only in 2106, not 2038.

But even then, in 2106, it should not be a problem to check the age of a
cookie because of the rfc1982 comparison (which takes care of the wrap)
and the fact that Server Cookies will not be older than hours (and not
years).

Cheers,
-- Willem

> I did glance
> at rfc1982, so there may be very far-sighted text
> in there that I missed:-) And it may even be fine
> for this purpose if different servers differ by a
> second or so at that point, but even if so, it may
> be a bad plan to leave that unspecified in case
> other timestamps use the same code.
> 
> Cheers,
> S.
> 
>>
>> Cheers,
>> -- Willem
>>
>>>
>>> Cheers,
>>> S.
>>>
>>>>
>>>> Cheers, Ondřej -- Ondřej Surý — ISC (He/Him)
>>>>
>>>>> On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker
>>>>>  wrote:
>>>>>
>>>>> Reviewer: Stephen Farrell Review result: Has Issues
>>>>>
>>>>> I see two issues here worth checking:
>>>>>
>>>>> 1. I don't recall SipHash being used as a MAC in any IETF standard
>>>>> before. We normally use HMAC, even if truncated. Why make this
>>>>> change and was that checked with e.g. CFRG? (And the URL given in
>>>>> the reference gets me a 404.)
>>>>>
>>>>> 2. Is it really a good idea to use a 32 bit seconds since
>>>>> 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours
>>>>> since then or seconds since some date in 2020 would be better.
>>>>>
>>>>> Here's a couple of nits too: - section 1: what's a "strong
>>>>> cookie"? - "gallimaufry" - cute! but not sure it'll help readers to
>>>>> learn that word.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ___ DNSOP mailing list
>>>> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
>>>>
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Willem Toorop]

Op 02-12-2020 om 21:37 schreef Stephen Farrell:



>> ad 2) we need a value that’s synchronized well enough and monotonic.
>> I honestly don’t see any value in using 64-bit value here. Using
>> unixtime has a value in itself, it’s a well-known and there’s a
>> little room for any implementer to make a mistake in an
>> implementation. The interoperability is more important than the
>> actual value of the counter. It’s write only counter, nobody is going
>> to interpret it after it has been generated, and it’s wide enough to
>> prevent brute forcing.
> 
> So what happens after 2038? That's really not v. far in the
> future any more.

The draft states that `All comparisons involving these fields MUST
use "Serial number arithmetic", as defined in [RFC1982]'. So it can not
be used to compare differences larger than 68 years, but comparisons of
cookie timestamps are more in the "hours" order of magnitude.

Cheers,
-- Willem

> 
> Cheers,
> S.
> 
>>
>> Cheers, Ondřej -- Ondřej Surý — ISC (He/Him)
>>
>>> On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker
>>>  wrote:
>>>
>>> Reviewer: Stephen Farrell Review result: Has Issues
>>>
>>> I see two issues here worth checking:
>>>
>>> 1. I don't recall SipHash being used as a MAC in any IETF standard
>>> before. We normally use HMAC, even if truncated. Why make this
>>> change and was that checked with e.g. CFRG? (And the URL given in
>>> the reference gets me a 404.)
>>>
>>> 2. Is it really a good idea to use a 32 bit seconds since
>>> 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours
>>> since then or seconds since some date in 2020 would be better.
>>>
>>> Here's a couple of nits too: - section 1: what's a "strong
>>> cookie"? - "gallimaufry" - cute! but not sure it'll help readers to
>>> learn that word.
>>>
>>>
>>>
>>>
>>
>> ___ DNSOP mailing list
>> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
>>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-server-cookies

[Willem Toorop]

Thanks Brian,

All but one nit resolved in these commits:

*
https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/db51181a
*
https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/e1e763e8

For your convenience, a rendered possible future version of the document
with these changes can be viewed here:

*
https://raw.githubusercontent.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/master/draft-ietf-dnsop-server-cookies-04.txt

I've provided a bit more feedback inline below.

Op 10-10-2020 om 23:13 schreef Brian Dickson:
> 
> 
> On Fri, Oct 9, 2020 at 8:38 AM Benno Overeinder  > wrote:
> 
> This starts a Working Group Last Call for
> draft-ietf-dnsop-server-cookies.
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
> 
> The Current Intended Status of this document is: Standards Track
> 
> FYI, I will not shepherd this document, as it was written with one
> of my coworkers.
> Tim Wicinski will be Document Shepherd.
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please
> speak out with your reasons.
> 
> 
> I have read the document, and support publication (modulo very minor
> nits that should be fixed).
> 
> In addition to these nits, I do have one further suggestion for Section 8.
> 
> I'm not sure if it is too late to make such a suggestion, but on reading
> (and thinking about) the spec,
> it could be useful guidance (particularly for clients which may not be
> aware of changes to their Client-IP address):
> 
> "o   In order to determine that a Server has detected a change to the
> Client-IP, a Client may consider
>       a BADCOOKIE error sooner than would be expected from a Server
> Cookie refresh as a signal
>       that the Client-IP may have changed, and thus that a new Client
> Cookie should be created for each Server."

This is too late. For privacy reasons, the server should not be able to
discover that the Client-IP changed so it cannot *track* Clients with
the help of a DNS Cookie.  The Client needs to detect source address
changes before it uses it to send out queries.

> 
> Nits:
> Introduction - I believe "provides" should be "provide", to agree with
> the singular "is" of the verb. (Sorry, grammar nit.)
> 
> Section 1.1 - I believe all the "Section Section" instances should
> really just be "Section".
> 
> Section 4 - "too frequent" -> "too frequently". 
> 
> Section 4.3 - "in the anycast." -> "in the anycast set."
> 
> Section 4.4 - hash calculation, end of first line "Client-IP," ->
> "Client-IP |"

(from Wikipedia)
SipHash is not actually a cryptographic hash, bot only suitable as
message authentication code: a keyed hash function like HMAC.

It has the form SipHash(message, key)

Thanks,
-- Willem

> 
> Section 5 - "anycast group" -> "anycast set"; "us used" -> "is used"
> 
> Section 8 - "like for example five minute." -> "for example five minutes."
> 
> Brian
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Willem Toorop]

Op 12-05-2020 om 00:48 schreef George Michaelson:
> I support adoption.
> 
> I wondered a little about "it is absolutely essential for these
> transfers to be protected from unexpected modifications on the route.
> So, catalog zone transfers SHOULD be authenticated using TSIG
> [RFC2845]."
> 
> The use of a categorical *absolutely* and SHOULD is jarring. If this
> is really categorical, the normative enforcement needs to be stronger
> maybe?

Agree, how about replacing "it is absolutely essential" with "it is key"?

> I also wondered why the TTL of the RR is not held to be meaningful. It
> felt like there is an opportunity to use this field but thats quibble,
> the document as-is defines it as 0 and thats ok, if perhaps missing an
> opportunity to use a field close to the zone being catalogued for some
> purpose.

We're staying away from actual configuration properties in this draft on
purpose.  TTL could be used to mean something in the dynamics of adding
& removing of zones itself, but it feels a bit fragile to do that to be
honest - we might exclude (or make more difficult) certain setups where
the catalog could not be used by or from the authoritative nameserver
directly.

-- Willem
> 
> On Tue, May 12, 2020 at 3:42 AM Tim Wicinski  wrote:
>>
>>
>> All,
>>
>> As we stated in the meeting and in our chairs actions, we're going to run
>> regular call for adoptions over next few months.
>> We are looking for *explicit* support for adoption.
>>
>>
>> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
>>
>> The draft is available here: 
>> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
>>
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and comments to the list, clearly stating your view.
>>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> This call for adoption ends: 25 May 2020
>>
>> Thanks,
>> tim wicinski
>> DNSOP co-chair
>>
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Willem Toorop]

Op 11-05-2020 om 21:38 schreef Bob Harold:
> On Mon, May 11, 2020 at 1:42 PM Tim Wicinski  > wrote:
> 
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going
> to run
> regular call for adoptions over next few months.  
> We are looking for *explicit* support for adoption.
> 
> 
> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 25 May 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> 
> I support adoption and will review.
> 
> "3.  Description
> An implementation of catalog zones MAY allow the catalog to contain
>    other catalog zones as member zones."
> 
> It seems ok to me to allow catalog zones to include other catalog zones
> as future feature, although I cannot figure out yet how that would work,
> but it might conflict with:
> 
> "6.1.  Implementation Notes
>    Catalog zones on secondary nameservers would have to be setup
>    manually"

Thanks Bob,

The secondary has to be "setup manually",
- to regard the zone to be a catalog zone
- but also, optionally, to associate a set of configuration which are
  applied to the zones generated from the catalog.

One of the things in the associated set of configuration could be that
zones from a certain catalog, are catalog zones themselves, however with
which set of configuration the zones added from those catalog are
associated, also needs to be configured manually on the secondaries.

-- Willem

> 
> -- 
> Bob Harold
>  
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Willem Toorop]

Op 16-04-2020 om 16:05 schreef Richard Gibson:
> Doesn't that preclude scenarios in which a zone transitions from one
> catalog to another?

Not necessarily, but we do need to provide more text here to describe
precisely how that would work yes. So thanks for bringing that up!

Something like:

When a member zone is removed from a specific catalog zone, an
authoritative server MUST NOT remove the zone and associated state data
if the zone was not configured from that specific catalog zone.
Only when the zone was configured from a specific catalog zone, and the
zone is removed as a member from that specific catalog zone, the zone
and associated state MUST be removed.
Subsequently, after removal, an implementation MUST check if another
catalog zone is present with has the zone as a member. In that case the
zone must be configured and associated according to the set of
configuration associated with that catalog zone.
If there are multiple other catalog zones which have the previously
removed zone as member, one should be picked randomly.

This is just a quick sketch text proposal.
I've submitted an issue for it in our github repo:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/issues/9

-- Willem

> 
> On 4/16/20 09:17, Willem Toorop wrote:
>> An authoritative nameserver might have two or more catalog zones, each
>> associated with their own set of configuration.  In that case, the
>> member zone that was configured first (and associated with the settings
>> of the particular catalog zone it was a member of) will keep that
>> association, regardless of it being a member zone of other catalog zones
>> as well.
>>
>>
>> -- Willem

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Willem Toorop]

Op 16-04-2020 om 14:37 schreef Bob Harold:
> On Wed, Apr 15, 2020 at 5:27 AM Willem Toorop  <mailto:wil...@nlnetlabs.nl>> wrote:
> 
> Dear all,
> 
> This is the new catalog zones draft as presented yesterday at the
> DNSOP WG Interim meeting. The idea of catalog zones is to establish
> automatic zone provisioning along existing primary/secondary
> relationships.
> 
> This is an earlier idea which was previously worked on by ISC
> authors. The editor's pen has been picked up by authors from
> different DNS Software implementations with the aim to create a
> cross-implementation compatible version of catalog zones.
> Most prominent modifications to earlier versions are:
> 
>  1. There are descriptions nor definitions of zone properties anymore
>  2. A zone is required to reset state when its unique label changes
>  3. The version TXT RR now can be a RRset to allow for versions that
> are backwards compatible with earlier versions.
> 
> Willem
> 
>  Doorgestuurd bericht 
> Onderwerp:[EXT] New Version Notification for
> draft-toorop-dnsop-dns-catalog-zones-01.txt
> Datum:Tue, 14 Apr 2020 04:02:23 -0700
> Van:  internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> Aan:  Ondrej Sury  <mailto:ond...@isc.org>, Libor
>     Peltan  <mailto:libor.pel...@nic.cz>, Peter van
> Dijk 
> <mailto:peter.van.d...@powerdns.com>, Willem Toorop
>  <mailto:wil...@nlnetlabs.nl>, Leo
> Vandewoestijne  <mailto:leo@dns.company>
> 
> 
> 
> A new version of I-D, draft-toorop-dnsop-dns-catalog-zones-01.txt
> has been successfully submitted by Willem Toorop and posted to the
> IETF repository.
> 
> Name: draft-toorop-dnsop-dns-catalog-zones
> Revision: 01
> Title: DNS Catalog Zones
> Document date: 2020-04-14
> Group: Individual Submission
> Pages: 11
> URL:
> 
> https://www.ietf.org/internet-drafts/draft-toorop-dnsop-dns-catalog-zones-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
> Htmlized:
> https://tools.ietf.org/html/draft-toorop-dnsop-dns-catalog-zones-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-toorop-dnsop-dns-catalog-zones
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-toorop-dnsop-dns-catalog-zones-01
> 
> Abstract:
> This document describes a method for automatic DNS zone provisioning
> among DNS primary and secondary nameservers by storing and
> transferring the catalog of zones to be provisioned as one or more
> regular DNS zones.
> 
> 
> 5.1..  General Requirements
> 
> If there is a clash between an existing member zone's name and an
>    incoming member zone's name (via transfer or update), the new
>    instance of the zone MUST be ignored and an error SHOULD be logged.
> 
> -- I do not understand.  Can you give an example?

An authoritative nameserver might have two or more catalog zones, each
associated with their own set of configuration.  In that case, the
member zone that was configured first (and associated with the settings
of the particular catalog zone it was a member of) will keep that
association, regardless of it being a member zone of other catalog zones
as well.


-- Willem

> 
> -- 
> Bob Harold
>  
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Willem Toorop]

Dear all,

This is the new catalog zones draft as presented yesterday at the DNSOP
WG Interim meeting. The idea of catalog zones is to establish automatic
zone provisioning along existing primary/secondary relationships.

This is an earlier idea which was previously worked on by ISC authors.
The editor's pen has been picked up by authors from different DNS
Software implementations with the aim to create a cross-implementation
compatible version of catalog zones.
Most prominent modifications to earlier versions are:

 1. There are descriptions nor definitions of zone properties anymore
 2. A zone is required to reset state when its unique label changes
 3. The version TXT RR now can be a RRset to allow for versions that are
backwards compatible with earlier versions.

Willem

 Doorgestuurd bericht 
Onderwerp:  [EXT] New Version Notification for
draft-toorop-dnsop-dns-catalog-zones-01.txt
Datum:  Tue, 14 Apr 2020 04:02:23 -0700
Van:internet-dra...@ietf.org
Aan:Ondrej Sury , Libor Peltan ,
Peter van Dijk , Willem Toorop
, Leo Vandewoestijne 



A new version of I-D, draft-toorop-dnsop-dns-catalog-zones-01.txt
has been successfully submitted by Willem Toorop and posted to the
IETF repository.

Name: draft-toorop-dnsop-dns-catalog-zones
Revision: 01
Title: DNS Catalog Zones
Document date: 2020-04-14
Group: Individual Submission
Pages: 11
URL:
https://www.ietf.org/internet-drafts/draft-toorop-dnsop-dns-catalog-zones-01.txt
Status:
https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
Htmlized:
https://tools.ietf.org/html/draft-toorop-dnsop-dns-catalog-zones-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-toorop-dnsop-dns-catalog-zones
Diff:
https://www.ietf.org/rfcdiff?url2=draft-toorop-dnsop-dns-catalog-zones-01

Abstract:
This document describes a method for automatic DNS zone provisioning
among DNS primary and secondary nameservers by storing and
transferring the catalog of zones to be provisioned as one or more
regular DNS zones.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-02.txt

[Willem Toorop]

Dear DNSOP,

Please review our new DNS Server Cookies draft.

It has an updated Client Cookie construction section and a new Security
and Privacy section that elaborates in particular on the considerations
for Client Cookie construction.


Op 19-11-2019 om 00:01 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : Interoperable Domain Name System (DNS) Server 
> Cookies
> Authors : Ondrej Sury
>       Willem Toorop
>   Donald E. Eastlake 3rd
>   Mark Andrews
>   Filename: draft-ietf-dnsop-server-cookies-02.txt
>   Pages   : 16
>   Date: 2019-11-18
> 
> Abstract:
>DNS cookies, as specified in RFC 7873, are a lightweight DNS
>transaction security mechanism that provides limited protection to
>DNS servers and clients against a variety of denial-of-service and
>amplification, forgery, or cache poisoning attacks by off-path
>attackers.
> 
>This document provides precise directions for creating Server Cookies
>so that an anycast server set including diverse implementations will
>interoperate with standard clients.
> 
>This document updates [RFC7873]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-02
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-01.txt

[Willem Toorop]

Op 06-11-2019 om 17:27 schreef Philip Homburg:
>> Philip Homburg pointed out that, although impractical to determine the
>> Client IP before Client Cookie construction, it is feasible for a Client
>> to detect it when it learns a Server Cookie from a specific Server.  It
>> can subsequently be tried to be reused for the same Server which will
>> fail if the Client IP has changed.
>>
>> This new (and practically implementable) requirement does not only
>> enhance privacy and make DNS Cookies work with the IPv6 Privacy
>> Extensions (by preventing tracking), it also makes them work in other
>> environments where Client source IP can change frequently, such as in
>> setups with multiple outgoing gateways.
> 
> Note that my preference was a pseudo-random client cookie. 
> 
> I can see two issues with the current approach:
> 1) I'm not sure this actually fixes the IPv6 privacy extensions problem.
>The same client cookie can be used on different addresses if the 
>server doesn't support cookies and the client at some point forgets
>that the server doesn't support cookies (and sends the server the
>same client cookie after a new privacy address is generated).
> 
> 2) As an extension of the previous, if no server supports cookies, then the
>client will not change the Client Secret and continues to use the same
>client cookie after it moves to new location.

Ack!

I see e need to adapt Client Construction section again. Also, these
considerations should be well expressed in a privacy and security
section as well.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-01.txt

[Willem Toorop]

Dear dnsop,

This version has an updated Client Cookie construction section in which
it is now REQUIRED to change a Client Cookie when the Client IP address
changes.

Previously (in versions before the previous version) the Client IP
address was used in Cookie construction, however that turned out to be
impractical to implement and therefore dropped from the previous version
recommending to disable DNS Cookies when privacy was a requirement.

Philip Homburg pointed out that, although impractical to determine the
Client IP before Client Cookie construction, it is feasible for a Client
to detect it when it learns a Server Cookie from a specific Server.  It
can subsequently be tried to be reused for the same Server which will
fail if the Client IP has changed.

This new (and practically implementable) requirement does not only
enhance privacy and make DNS Cookies work with the IPv6 Privacy
Extensions (by preventing tracking), it also makes them work in other
environments where Client source IP can change frequently, such as in
setups with multiple outgoing gateways.

Op 04-11-2019 om 21:58 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : Interoperable Domain Name System (DNS) Server 
> Cookies
> Authors : Ondrej Sury
>       Willem Toorop
>   Donald E. Eastlake 3rd
>   Mark Andrews
>   Filename: draft-ietf-dnsop-server-cookies-01.txt
>   Pages   : 15
>   Date: 2019-11-04
> 
> Abstract:
>DNS cookies, as specified in RFC 7873, are a lightweight DNS
>transaction security mechanism that provides limited protection to
>DNS servers and clients against a variety of denial-of-service and
>amplification, forgery, or cache poisoning attacks by off-path
>attackers.
> 
>This document provides precise directions for creating Server Cookies
>so that an anycast server set including diverse implementations will
>interoperate with standard clients.
> 
>This document updates [RFC7873]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-01
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-00.txt

[Willem Toorop]

On 09-09-19 15:45, Philip Homburg wrote:
> In your letter dated Mon, 9 Sep 2019 14:13:01 +0200 you wrote:
>> When implementing DNS Cookies, several DNS vendors found that
>> impractical as the Client Cookie is typically computed before the Client
>> IP address is known. Therefore, the requirement to put Client IP address
>> as input to was removed, and it simply RECOMMENDED to disable the DNS
>> Cookies when privacy is required. herefore, the requirement to put
>> Client IP address as input to was removed, and it simply RECOMMENDED to
>> disable the DNS Cookies when privacy is required.
> 
> I don't quite understand this.
> 
> The proposed way of constructing a client cookie:
>   Client-Cookie = MAC_Algorithm(Server IP Address, Client Secret )
> 
> means that if a host moves between networks it is quite likely it will
> continue to use the same cookie. This allows a host to be tracked across
> networks.

This is true.  Including the Client IP in constructing the Client Cookie
was intended to deal with this, but this operation is impractical with
UDP; expensive at best and not suitable for high volume recursive to
authoritative traffic.

We could recommend it for stub to recursive traffic, for which the high
volume performance requirements are less of an issue... what do you think?

> Neither RFC 7873 nor this draft has text that requires the host to change
> the Client Secret when moving to a different link. 
> 
> Most DNS client software is general enough that we cannot rule out that it
> will be used on a mobile device.
> 
> So we reach then end of Section 3, which says '[...] simply RECOMMENDED
> to disable the DNS Cookies when privacy is required'
> 
> So it seems that this draft implicitly recommends that DNS client
> cookies are by default disabled and should only be enabled on hosts that have
> stable IP addresses.
> 
> If that's the intention, then maybe this can be stated explicitly in the
> introduction.>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-00.txt

[Willem Toorop]

On 09-09-19 14:52, Paul Wouters wrote:
> On Mon, 9 Sep 2019, Willem Toorop wrote:
> 
>> The only change since the previous version (i.e.
>> draft-sury-toorop-dnsop-server-cookies-00) is that we no longer
>> recommend to include the Client IP address with constructing client
>> cookies:
>>
>> When implementing DNS Cookies, several DNS vendors found that
>> impractical as the Client Cookie is typically computed before the Client
>> IP address is known. Therefore, the requirement to put Client IP address
>> as input to was removed, and it simply RECOMMENDED to disable the DNS
>> Cookies when privacy is required. herefore, the requirement to put
>> Client IP address as input to was removed, and it simply RECOMMENDED to
>> disable the DNS Cookies when privacy is required.
> 
> Wouldn't this enable me to obtain some cookies from within a network,
> and then re-use those cookies from outside the network? The reason for
> including the IP was the pin the cookie to the specific client IP.

No, Client IP is still included in *Server* Cookie generation, just not
in Client Cookie construction.  So the re-user from different network
protection is still there.

> I cannot see a diff because you didn't instruct the data tracker that
> this adopted document continues from the individual submission :(

Oh, sorry.  I indicated that it replaced the previous draft (and
Donald's) that is not correct?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-00.txt

[Willem Toorop]

Hi All,

The only change since the previous version (i.e.
draft-sury-toorop-dnsop-server-cookies-00) is that we no longer
recommend to include the Client IP address with constructing client cookies:

When implementing DNS Cookies, several DNS vendors found that
impractical as the Client Cookie is typically computed before the Client
IP address is known. Therefore, the requirement to put Client IP address
as input to was removed, and it simply RECOMMENDED to disable the DNS
Cookies when privacy is required. herefore, the requirement to put
Client IP address as input to was removed, and it simply RECOMMENDED to
disable the DNS Cookies when privacy is required.

-- Willem

On 09-09-19 12:26, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Title   : Interoperable Domain Name System (DNS) Server 
> Cookies
> Authors : Ondrej Sury
>       Willem Toorop
>   Donald E. Eastlake 3rd
>   Mark Andrews
>   Filename: draft-ietf-dnsop-server-cookies-00.txt
>   Pages   : 14
>   Date: 2019-09-09
> 
> Abstract:
>DNS cookies, as specified in RFC 7873, are a lightweight DNS
>transaction security mechanism that provides limited protection to
>DNS servers and clients against a variety of denial-of-service and
>amplification, forgery, or cache poisoning attacks by off-path
>attackers.
> 
>This document provides precise directions for creating Server Cookies
>so that an anycast server set including diverse implementations will
>interoperate with standard clients.
> 
>This document updates [RFC7873]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dns-privacy] Do53 vs DoT vs DoH Page Load Performance Study at ANRW

[Willem Toorop]

On 21-07-19 16:26, Puneet Sood wrote:
> * The experiment was run from Princeton, New Jersey in Northeast US.
> The location is in a very well connected part of the world between
> network peering points in NYC and Washington DC. You will not see much
> difference (due to network latency) between the cloud providers and
> the default (local) Do53. Running the experiment from locations which
> are further away from cloud providers would provide another
> interesting set of data.

Thanks for this Puneet and for stating this at the microphone during the
presentation.  I have some numbers that support this.

At the hackathon at the African Internet Summit in Kampala Uganda one
month ago, I participated with a team using RIPE Atlas to compare
response time of the locally configured resolvers of RIPE Atlas probes
in the Africa region, to the cloud resolvers 1.1.1.1, 8.8.8.8 and 9.9.9.9.

On UDP, on the median, local resolvers returned responses 27 times
quicker than the fastest cloud resolver: 2ms RTT for the local resolver
versus 55ms for the fastest cloud resolver (which was 9.9.9.9). On TCP,
local resolvers provide responses at least 6 times quicker. 14ms versus
94ms (again Quad9).

We also measured DoT which had +-3 times longer response time than TCP
on the cloud DNS providers.  There were only very few probes with
resolvers other than the quads that supported DoT, but those were also
remote given their long round trip times.

See also our post/report on:

https://labs.ripe.net/Members/willem_toorop/hackathon-africa-internet-summit-2019

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-sury-toorop-dnsop-server-cookies-00.txt

[Willem Toorop]

Dear All,

A new draft has been submitted addressing the issue of DNS Cookies in
multi-vendor anycast deployments.

DNS Cookies are currently impractical in such deployments, because one
implementation - even though it shares its secret with another
implementation - cannot validate the Server Cookies constructed by that
other implementation, because their methods for constructing Server
Cookies differ.

This draft provides precise directions for creating Server Cookies to
align the implementations.  This draft introduces a registry for methods
suitable for Cookie construction.  This draft deprecates all previous
methods of creating Server Cookies and introduces an inter-operable
method (version 1) employing the SipHash-2.4 pseudorandom function.

This is an update on draft-sury-toorop-dns-cookies-algorithms-00 draft
based on the experience we gained during the hackathon at IETF105. Mark
Andrews and Donald Eastlake are added as co-authors.

Willem


 Forwarded Message 
Subject: New Version Notification for
draft-sury-toorop-dnsop-server-cookies-00.txt
Date: Wed, 26 Jun 2019 04:12:58 -0700
From: internet-dra...@ietf.org
To: Mark Andrews , Willem Toorop ,
Donald E. Eastlake 3rd , Ondrej Sury ,
Donald Eastlake 


A new version of I-D, draft-sury-toorop-dnsop-server-cookies-00.txt
has been successfully submitted by Willem Toorop and posted to the
IETF repository.

Name:   draft-sury-toorop-dnsop-server-cookies
Revision:   00
Title:  Interoperable Domain Name System (DNS) Server Cookies
Document date:  2019-06-26
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/internet-drafts/draft-sury-toorop-dnsop-server-cookies-00.txt
Status:
https://datatracker.ietf.org/doc/draft-sury-toorop-dnsop-server-cookies/
Htmlized:
https://tools.ietf.org/html/draft-sury-toorop-dnsop-server-cookies-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-sury-toorop-dnsop-server-cookies


Abstract:
   DNS cookies, as specified in RFC 7873, are a lightweight DNS
   transaction security mechanism that provides limited protection to
   DNS servers and clients against a variety of denial-of-service and
   amplification, forgery, or cache poisoning attacks by off-path
   attackers.

   This document provides precise directions for creating Server Cookies
   so that an anycast server set including diverse implementations will
   interoperate with standard clients.

   This document updates [RFC7873]




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-sury-toorop-dns-cookies-algorithms-00.txt

[Willem Toorop]

Thanks Mukund,

Comments inline below...

On 31-05-19 19:54, Mukund Sivaraman wrote:
> On Tue, Mar 12, 2019 at 12:29:13PM +0100, Willem Toorop wrote:
>> Dear DNSOP,
>>
>> A new draft has been submitted addressing the issue of DNS Cookies in
>> multi-vendor anycast deployments.
> 
> I came across this draft today in a thread on the dns-operations@ list.
> 
> Here is a short review:
> 
> * Any draft that specifies things clearly / clarifies things is
>   welcome. The following criticizes some things that stand out.
> 
> * The method in section 3 looks different from the syntax BIND currently
>   uses for the server cookie. Is this going to break (server-side)
>   compatibility with existing deployed versions of BIND that are in
>   various products when used as part of a cluster?

Yes.  Unfortunately there is no version indicator in current BIND's
implementation and therefore it is impossible to detect whether a cookie
is generated by BIND previous mechanism or not.  We do need the version
field in the server cookie to signal how the cookies are constructed and
how they can be verified.

Implementations can choose to fallback to previous BIND behaviour or
have that behaviour set explicitly in a configuration...


> * I feel HMAC-SHA256 should not be moved to "MUST NOT", because:
> 
>   (a) This proposal leaves SipHash as the only choice. AES is proposed
>   as "MAY" and from the commentary in section 4, it appears the draft
>   considers AES as obsolete for DNS COOKIE. It is not as straighforward
>   as a HMAC for non-cryptographers anyway (typical DNS programmers)
No Mukund, we had an inter-operable DNS Server cookies implementation
based on SipHash in the hackathon of IETF 104 in Prague for BIND, Knot,
NSD, Unbound and PowerDNS recursor.  So no implementation barriers.

>   (b) HMAC-SHA256 is already available as a subroutine in typical DNS
>   implementations because of its use in other parts of DNS such as TSIG.
>   On the contrary, SipHash would typically be a new dependency for DNS
>   implementations unless they're already using it for something such as
>   hashtables. Due to its youth, many projects appear to "roll their own"
>   SipHash in C code which may not be far off in performance
>   vs. libcrypto's SHA-256.

SipHash is now included in OpenSSL. Also the reference implementation is
in the Public Domain with a very permissive license: (see
https://github.com/veorq/SipHash/blob/master/LICENSE )

>   (c) While SHA-256 is slower than SipHash, it should still be OK to
>   have it as an option for the server cookie part, especially as some
>   modern processors include specialized instructions for computing
>   SHA-256 as part of their ISA. It is a server admin's decision about
>   the performance tradeoff. On my machine, result of a quick benchmark
>   of SHA-256 for single core appears fine for typical usage.

To get an inter-operable version of DNS Cookies out in implementations
quickly, I think we should restrict ourselves to SipHash now.  We, the
OS dns software vendors) have proven that we can do such an
implementation based on SipHash-2.4 quickly during the IETF105 hackathon.

Additional methods with different pseudorandom functions can be
discussed and added later on.

> * For compatibility, the AES method should be specified in more detail
>   than "other implementations MAY implement AES algorithm as implemented
>   in BIND" as otherwise it has the same problem this draft is attempting
>   to address.

Agree, I have just submitted a new version of the draft, which I will
forward to the list after this reply.

> 
> * DNS COOKIE primarily addresses two problems - cache poisoning at the
>   client side, and amplification attacks on the server side.
> 
>   There have been multiple complaints (even previously from the current
>   thread on dns-operations@) on multi-implementation DNS clusters having
>   issues with getting the server cookie / secret right.
> 
>   By discarding FNV (which is not a PRF) this new draft makes frequent
>   updating of keys unnecessary which is a welcome relief, esp. when the
>   key has to be synchronized across multiple machines.
>   
>   However, there is still the possibility that two implementations don't
>   get it right somehow, due to incompatibility of methods or
>   implementation bugs.
> 
>   I feel it would be beneficial to introduce a mode (as mandatory to
>   implement) where the server can be confgured to simply echo the option
>   back to the client. It would then replicate a client-supplied nonce in
>   the query message (technically the client-cookie part as far as the
>   protocol client is concerned), and would serve at least one out of the
>   two main purposes of DNS COOKIE - addres

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Willem Toorop]

I support adoption too and have (the version in this draft) of ZONEMD
provisioned already in the net-dns.org. zone.
Dick Franks worked on a ZONEMD verifier for Net::DNS during the
Hackathon last Saturday/Sunday (remotely).

On 10-03-19 15:31, Tim Wicinski wrote:
> 
> The chairs feel the document has been updated to address 
> several issues raised from the last meeting, including 
> some implementations.   
> 
> If there is pushback during this call for adoption, we can 
> take the topic up in Prague. 
> 
> This starts a Call for Adoption for draft-wessels-dns-zone-digest
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 24 March 2019
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-sury-toorop-dns-cookies-algorithms-00.txt

[Willem Toorop]

Dear DNSOP,

A new draft has been submitted addressing the issue of DNS Cookies in
multi-vendor anycast deployments.

DNS Cookies are currently impractical in such deployments, because one
implementation - even though it shares its secret with another
implementation - cannot validate the Server Cookies constructed by that
other implementation, because their methods for constructing Server
Cookies differ.

This draft provides precise directions for creating Server Cookies to
align the implementations.  In doing so, this draft introduces a
registry for functions suitable for Cookie construction.  More
specifically, FNV and HMAC-SHA-256-64 are obsoleted and SipHash-2.4 is
introduced as a suitable function.

Willem

 Forwarded Message 
Subject: New Version Notification for
draft-sury-toorop-dns-cookies-algorithms-00.txt
Date: Mon, 11 Mar 2019 09:12:24 -0700
From: internet-dra...@ietf.org
To: Willem Toorop , Ondrej Sury 


A new version of I-D, draft-sury-toorop-dns-cookies-algorithms-00.txt
has been successfully submitted by Willem Toorop and posted to the
IETF repository.

Name:   draft-sury-toorop-dns-cookies-algorithms
Revision:   00
Title:  Algorithms for Domain Name System (DNS) Cookies construction
Document date:  2019-03-11
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-sury-toorop-dns-cookies-algorithms-00.txt
Status:
https://datatracker.ietf.org/doc/draft-sury-toorop-dns-cookies-algorithms/
Htmlized:
https://tools.ietf.org/html/draft-sury-toorop-dns-cookies-algorithms-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-sury-toorop-dns-cookies-algorithms


Abstract:
   [RFC7873] left the construction of Server Cookies to the discretion
   of the DNS Server (implementer) which has resulted in a gallimaufry
   of different implementations.  As a result, DNS Cookies are
   impractical to deploy on multi-vendor anycast networks, because the
   Server Cookie constructed by one implementation cannot be validated
   by another.

   This document provides precise directions for creating Server Cookies
   to address this issue.  Furthermore, [FNV] is obsoleted as a suitable
   Hash function for calculating DNS Cookies.  [SipHash-2.4] is
   introduced as a new REQUIRED Hash function for calculating DNS
   Cookies.

   This document updates [RFC7873]




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] raising the bar: requiring implementations

[Willem Toorop]

I would love to see a hard requirement for implementations &
implementation reports (like IDR has) in the charter or in the working
group house rules.  Early implementations (perhaps even during the
hackathon) can reveal implications that might have been missed while
designing the draft.  In addition it is a good way to see if everybody
interprets a draft the same way, by interoperability testing.


Op 24-03-18 om 12:07 schreef Job Snijders:
> Dear DNSOP,
> 
> I'd like to share some pointers from the working group that governs the
> BGP protocol, IDR, on requiring implementations before drafts can
> advance towards RFC publication. Raising the bar for publication will
> take weight off the camel's back.
> 
> The IDR policy and rationale is outlined here: 
> https://trac.ietf.org/trac/idr/wiki
> 
> An example of an implementation report is available here:
> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations
> Every normative (RFC 2119 / RFC 8174) term should expand into a
> compliance test, and it is particularly good to document where
> implementations deviate from what is required or suggested in the
> proposed specification. The work listed on this wikipage was done
> _before_ the draft was submitted to the IESG, and we intentionally
> sought to create more than the minimum amount of implementations
> required.
> 
> In the case of the BGP large communities project the working group was
> particularly lucky because Pier Carlo Chiodi created an open 'regression
> testing'-style environment into which BGP speakers could be plugged in
> to assess their compliance:
> https://github.com/pierky/bgp-large-communities-playground
> https://github.com/pierky/bgp-large-communities-playground/blob/master/tests/README.md
> 
> The DNS world would benefit from such environments and automated
> compliance testing. Manual testing for a specification (that is still
> being worked on) can be tedious, having a 'playground' can pay huge
> dividend. We did catch bugs in implementations thanks to this
> environment, so it not only helped the specification, but increased the
> quality of the participating implementations.
> 
> RFC 7942 suggest that During the development of a draft people are
> encouraged to document what implementations exist, an example is here:
> https://tools.ietf.org/html/draft-ietf-idr-large-community-12#section-7
> 
> Closed source implementations as part of such a list is not an issue
> (just a little bit more work), at IETF meetings we'd meet up, plug
> laptops with virtual machines into each other and run compliance tests.
> Sidenote: when IANA codepoints are needed but not yet assigned, don't
> forget to keep everything on separate beta/feature branches; don't ship
> software with squatted codepoints :-)
> 
> The DNSOP working group will have to figure out what constitutes a
> meaningful implementation in what context. For example, a tcpdump or
> wireshark decoder would hardly count as an implementation of a proposed
> DNS feature, but those decoders are _incredibly_ useful to have
> alongside real implementations, especially during development. DNS
> people will probably want to see multiple implementation reports in
> context of packet decoding, stub, resolver, and authoritative.
> 
> Kind regards,
> 
> Job
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

[Willem Toorop]

Op 20-07-17 om 10:45 schreef Shumon Huque:
> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson
> mailto:ola...@cloudflare.com>> wrote:
> 
> 
> I disagree, if a zone operator selects "less-than" common algorithm
> they do that at their own risk, 
> if the risk is not acceptable then it should dual sign 
> 
> 
> Yes. The point I was trying to make is that DANE sites (and probably
> others if they care about security) cannot afford to fail open. So they
> have to dual sign if they can stomach the costs, or delay deploying new
> algorithms for a long time. This draft is intended to (eventually) make
> the dual signing case easier to deal with operationally.

So,

Providers of DANE backed services are stuck on the well-known
algorithms, and do not have insight on algorithm support by clients
verifying these services with DANE.

This draft in combination with double signing, provides the means to
deal with this (and in a secure manner too).

I think this is an important motivation of this work and that this
should be reflected in the Introduction section of the draft.

-- Willem

> 
> -- 
> Shumon Huque
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

[Willem Toorop]

Op 18-07-17 om 18:09 schreef Tony Finch:
> The other kind of DNS server that might be able to do something useful
> with ANAME is a recursive server, so it could co-operate nicely with
> authoritative servers that are playing clever tricks. But the rDNS will
> have to be careful about not breaking downstream validators.
> 
> Say (for example) my zone has:
> 
> dotat.at. ANAME   www.chiark.greenend.org.uk.
> dotat.at. RRSIG   ANAME
> dotat.at. A   212.13.197.229
> dotat.at. RRSIG   A
> dotat.at. 2001:ba8:1e3::
> dotat.at. RRSIG   
> 
> A client queries its resolver for dotat.at A, but chiark has renumbered,
> so the client gets a response from the ANAME-aware resolver like below. A
> validating ANAME-aware client can see it should use the additional address
> 212.13.197.231 in preference to the address in the answer.
> 
> ; ANSWER
> dotat.at.   A   212.13.197.229
> dotat.at. RRSIG   A
> 
> ; ADDITIONAL
> dotat.at.   2001:ba8:1e3::
> dotat.at. RRSIG   
> dotat.at.   ANAME   www.chiark.greenend.org.uk.
> dotat.at. RRSIG   ANAME
> www.chiark.greenend.org.uk.   A   212.13.197.231
> www.chiark.greenend.org.uk.   RRSIG   A
> www.chiark.greenend.org.uk.   2001:ba8:1e3::
> www.chiark.greenend.org.uk.   RRSIG   
> 
> Note that neither the resolver nor the client needs any algorithm updates
> to avoid being confused by this additional information; they just need a
> code update so that they are able to make good use of it.
> 
> If the resolver knows the client is DNSSEC-oblivious then it can do the
> substitution itself and return a simple answer like this:
> 
> dotat.at. A   212.13.197.231
> 
> Validating but ANAME-oblivious resolvers won't get to enjoy clever
> latency minimization tricks.

Yes!  This should be included in the aname draft.
Thanks,

-- Willem
> 
> Tony.
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

[Willem Toorop]

I support trying to come up with a standards solution for alias names at
the apex.  But

The dependency on online signing is a little more then just a technical
issue.

Currently the zone owner, the holder of the domain name, is the one
having control over the zone content and as such also the one deciding
who may sign her zone.  She may choose to delegate this to a DNS
operator, or she may decide to sign the zone herself and let the DNS
operator serve the signed zone.

Currently all DNS Resource Records support the "offline" domain-name
holder signed zones mode of DNSSEC.  There is another provisioning
oriented resource record: DNAME.  For DNAME, it is described how
validators can verify that the followed referral matches. The same thing
should be done for ANAME.

It would be a new DNSSEC feature that need to be supported by the DNSSEC
validators.  There has been an earlier instance of the introduction of a
new DNSSEC feature: NSEC3.  The introduction of a DNSSEC compatible
ANAME should be done the same way as how NSEC3 was introduced: introduce
new algorithm numbers that indicate ANAME support.

We currently have 12 DNSSEC algorithms.  The introduction of a new
feature could list these same algorithm from number 17 up to 29, with
the indication that it supports the new DNSSEC features,  ANAME would be
one of them.  NSEC5 another maybe?


Op 27-05-17 om 23:36 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
> Title   : Address-specific DNS Name Redirection (ANAME)
> Authors : Evan Hunt
>   Peter van Dijk
>   Anthony Eden
>   Filename: draft-ietf-dnsop-aname-00.txt
>   Pages   : 10
>   Date: 2017-05-27
> 
> Abstract:
>This document defines the "ANAME" DNS RR type, to provide similar
>functionality to CNAME, but only redirects type A and  queries.
>Unlike CNAME, an ANAME can coexist with other record types.  The
>ANAME RR allows zone owners to redirect queries for apex domain names
>in a standards compliant manner.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-aname-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy?

[Willem Toorop]

Excellent idea!  Looking forward to help out with this!
I will discuss with Wouter (what he thinks about this and how he would
take it on), but also Sara is deep into Unbound code, especially with
respect to transports!

-- Willem

Op 02-07-15 om 22:36 schreef Daniel Kahn Gillmor:
> On Thu 2015-07-02 16:20:30 -0400, Tom Ritter wrote:
>> As an idea:  some months ago dkg looked at hooking up unbound to an
>> upstream resolver over TCP/TLS.  It works, but it isn't ideal right
>> now.  Our findings:
>>
>> A) client and server together negotiate TLS 1.2 (that's good!)
>>
>> B) client doesn't appear to even try to validate the certificate
> 
> this is https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658
> 
>> C) client doesn't hold open connections, but rather does one query per
>>connection.  This is a tremendous amount of overhead.
>>
>> D) server selects TLS_RSA_WITH_AES_256_GCM_SHA384 even though
>>client preferred TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 or
>>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
>>
>> E) server offers a TLS session ticket each time, and
>>client is not re-using the session ticket (or any other abbreviated
>>handshake mechanism) that i can tell.
> 
> I hope to work on these issues during the hackathon.
> 
>   --dkg
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Definition of "validating resolver"

[Willem Toorop]

I'd like to maintain the term exactly as specified in RFC4033
(understanding DNSSEC but not validating), because it comes in use when
talking about validating stubs.

Some network operators don't know or care about DNSSEC and do not equip
their network's resolver with a trust anchor.  Such a resolver is
obviously not validating, but if it is a modern resolver it is very
likely to be security-aware.

An application using a validating stub can leverage such a resolver to
get DNSSEC answers from the cache which it can then validate itself.
For example to get an authenticated TLSA and bootstrap an encrypted channel.

I have presented measurements on the amount of security-aware resolvers
in RIPE ATLAS in the context of this use case at ICANN50:

https://london50.icann.org/en/schedule/wed-dnssec/presentation-dnssec-validation-deployment-25jun14-en.pdf

Though in the research we called those DNSSEC-aware instead of
security-aware.

-- Willem

Op 08-03-15 om 23:31 schreef Ralf Weber:
> Moin!
> 
> On Sun, Mar 08, 2015 at 12:21:49PM -0700, Paul Hoffman wrote:
>> Greetings again. Paul Wouters noticed an inconsistency in the terminology
>> draft, and upon investigation, I believe it is a problem (hopefully
>> fixable) with the definitions in RFC 4033.  RFC 4033 and 4035 use the term
>> "validating resolver" in a few places.  However, RFC 4033 never defines
>> that.  RFC 4033 *does* define "security-aware resolver":
>>
>>Security-Aware Resolver: An entity acting in the role of a resolver
>>   (defined in section 2.4 of [RFC1034]) that understands the DNS
>>   security extensions defined in this document set.  In particular,
>>   a security-aware resolver is an entity that sends DNS queries,
>>   receives DNS responses, supports the EDNS0 ([RFC2671]) message
>>   size extension and the DO bit ([RFC3225]), and is capable of using
>>   the RR types and message header bits defined in this document set
>>   to provide DNSSEC services.
>>
>> My personal interpretation is that "validating resolver" is a synonym for
>> "security-aware resolver".  Do others agree?  If not, how would you
>> differentiate them?
> I was told that the difference is that a security aware resolver does
> not validate, but instead relies on the "Validating Stub Resolver" to 
> protect the user. So it would handle all the DNSSEC processing to the
> authoritative and would store the records with signatures in the cache,
> but it wouldn't check if they are valid. 
> 
> The people who told me that interpreation of the RFC never did deploy DNSSEC
> and thankfully most of the people who did and deployed DNSSEC used
> validating and security aware resolvers. I don't think it makes sense to
> deploy a caching resolver without validation.  So would be ok if we define
> it as you suggest.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-hoffman-dns-terminology-00.txt

[Willem Toorop]

Op 23-02-15 om 15:15 schreef Ray Bellis:
> 
>> On 23 Feb 2015, at 14:06, Willem Toorop  wrote:
>>
>> Maybe this document can give a decisive answer on the expansion of AXFR
>> as well?  In the RFC Editor Abbreviations List (
>> https://ftp.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt ), this
>> is expanded as either - Asynchronous Full Transfer (AXFR)  or
>>   - Authoritative Transfer or
>>   - full zone transfer (AXFR) (RFC 6168)
>>
> 
> Where on earth did "Asynchronous" come from in that first expansion?!

Who knows, but it appears frequently used like this outside the IETF
(google yourself).  It made me wonder what is cause and what is
consequence.  Is it in the rfc style guide because it is used so
frequently?  Or is it used like this because it is in the style guide?

> It's not mentioned anywhere in 1034 or 1035 

Neither is authoritative transfer...
...but mention frequently like this in other rfcs yes.

-- Willem

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-hoffman-dns-terminology-00.txt

[Willem Toorop]

Maybe this document can give a decisive answer on the expansion of AXFR
as well?  In the RFC Editor Abbreviations List (
https://ftp.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt ), this
is expanded as either - Asynchronous Full Transfer (AXFR)  or
   - Authoritative Transfer or
   - full zone transfer (AXFR) (RFC 6168)

Op 28-11-14 om 16:28 schreef Paul Hoffman:
> Greetings. Andrew and Kazunori and I have prepared the first draft of what 
> will hopefully be a useful document collecting definitions that useful in the 
> DNS community. We fully admit that this is quite rough, and didn't even try 
> to do definitions for some of the terms that we expect to be filled in before 
> we are done.
> 
> The idea is that this will be an IETF consensus document, if possible, but we 
> are not yet asking for adoption in the DNSOP WG, and we might not even later. 
> For now, we'd like to hear what additional terms should be added, what 
> clarifications to the terms we already have would be helpful, and so on.
> 
> --Paul Hoffman
> 
>> A new version of I-D, draft-hoffman-dns-terminology-00.txt
>> has been successfully submitted by Paul Hoffman and posted to the
>> IETF repository.
>>
>> Name:draft-hoffman-dns-terminology
>> Revision:00
>> Title:   DNS Terminology
>> Document date:   2014-11-28
>> Group:   Individual Submission
>> Pages:   9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/
>> Htmlized:   http://tools.ietf.org/html/draft-hoffman-dns-terminology-00
>>
>>
>> Abstract:
>>   The DNS is defined in literally dozens of different RFCs.  The
>>   terminology used in by implementers and developers of DNS protocols,
>>   and by operators of DNS systems, has sometimes changed in the decades
>>   since the DNS was first defined.  This document gives current
>>   definitions for many of the terms used in the DNS in a single
>>   document.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-01.txt

[Willem Toorop]

Thanks,

Are section 6 and 7 an alternative drop in replacement for section 4 and
5?  Because I feel there are some pieces missing in section 7 about
server policies and how that works out in responses, that can be found
in section 5.

Sections 7.2.3 (Only a CLIENT Cookie) and 7.2.4.1 (A Client Cookie and
Invalid Server Cookie) state that the server creates and sets a server
cookie for/in the response.  Then the sections mention: "The server
SHALL process the query as if the Client Cookie was not present."

That last statement depends on server policy, yes?  These server
policies are not explicitly mentioned in section 7, but there are some
suggestions in section 5.2.2 and 5.2.3: one could (1) silently discard
(but not always), (2) reply with error response or (3) process as normal.

Suppose a server policy (2) that returns error responses on absent or
wrong server cookie requests;  With the absence of the extra rcodes in
section 6 & 7, does that mean a REFUSED response including the server
cookie?

THE REFUSED response is only mentioned in 5.2.2, policy option (2).
Do I interpret the last paragraph of that section correct that there is
a suggestion to return REFUSED responses with the TC bit set, to
stimulate the initiation of TCP connection as an alternative weak
authentication?  Is this acceptable policy for sections 7.2.1 and 7.2.2
as well?

Is policy (1), silently discard, from section 5.2.2 and 5.2.3 also
considered a viable policy option in section 7?

Also, I think that the (obvious?) inclusion of a server cookie with
policies (2) and (3) could be mentioned more explicitly in section 5.2.3.

Regards,

-- Willem

Op 23-02-15 om 05:01 schreef internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Domain Name System Operations Working Group 
> of the IETF.
> 
> Title   : Domain Name System (DNS) Cookies
> Authors : Donald E. Eastlake
>   Mark Andrews
>   Filename: draft-ietf-dnsop-cookies-01.txt
>   Pages   : 34
>   Date: 2015-02-22
> 
> Abstract:
>DNS cookies are a lightweight DNS transaction security mechanism that
>provides limited protection to DNS servers and clients against a
>variety of increasingly common denial-of-service and amplification /
>forgery or cache poisoning attacks by off-path attackers. DNS Cookies
>are tolerant of NAT, NAT-PT, and anycast and can be incrementally
>deployed.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dnsop-cookies-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] New user mailing-list for Net::DNS

[Willem Toorop]

[This message has been mailed to several lists, apologies for duplicates]

Dear Perl DNS programmers,

NLnet Labs has been maintaining the perl Net::DNS and Net::DNS::SEC
packages for more then seven years. Traditionally people who wanted to
discuss Net::DNS used RT at cpan or directly mailed the maintainer(s).

While Net::DNS and Net::DNS::SEC are libraries that are supported by
NLnet Labs, they also benefit from significant community contribution
and collaboration.

Until now, there was no official platform for Net::DNS users to talk to
each other and share experiences. About time to set this up; ie. a
mailing-list for Net::DNS users.

If you use Net::DNS and Net::DNS::SEC and wish to discuss it with other
users (and with us), please subscribe to our list on the webpage:

https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users

or subscribe by sending an email to net-dns-users-requ...@nlnetlabs.nl
with the word `subscribe' in the subject or body.

Best regards,

Willem Toorop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop