[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

[libor.peltan]

Hi all,

On the other hand, couldn't it actually be beneficial if the signalling 
zone name is generic enough, and if (in theory on the future) it is 
shared with possibly completely different signals, possibly unrelated to 
DNSSEC?


With this in mind, I support the signalling label _signal. Otherwise, I 
would prefer something of comparable (or even lower) length, not like 
_dnssec-signal.


Libor

Dne 21. 04. 24 v 1:38 Paul Wouters napsal(a):

On Sat, 20 Apr 2024, Peter Thomassen wrote:

The authors certainly don't insist, but we'd need to pick a suitable 
replacement for the "_signal" label.


John proposed "_dnssec-signal" elsewhere in this thread.

The authors would like to note that adding "_dnssec-" eats up 8 more 
bytes, increasing chances that bootstrapping will fail due to the 
_dsboot.._dnssec-signal. length limitation. 
Other than this (unnecessary?) use case narrowing, this choice seems 
fine.


That said, does this choice address your concerns?


It would, but I would also be okay if it is just _dnssec.

The main question then is to get implementations updated. I'm thus 
copying a few implementers so they can comment w.r.t. making this 
change in their implementation. I suppose that barring their 
objections, it's fine to go ahead?


I feel less sympathy there because I brought this up a long time ago :)
But also, implementations are all young and new and I think it is still
pretty easy to change.

Paul

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


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

Re: [DNSOP] [Ext] About key tags

[libor.peltan]

Hi John,

Dne 27. 02. 24 v 21:24 John Levine napsal(a):

The total number of domains where I found duplicate tags was 105.

As I said earlier, is while I appreciate such research, I warn against 
misinterpreting it. The main point isn't about the zones that are 
currently experiencing a keytag-conflict; it's about the zones where 
there is a potential threat that they might do tomorrow (considering the 
case when many mainstream validating resolvers would start enforcing 
strong keytag-conflict-intolerance).


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

Re: [DNSOP] [Ext] About key tags

[libor.peltan]

Hi all,

let me speak up as an open-source authoritative server (Knot DNS) 
implementer.


Since long time, we do care when generating keys to avoid keytag 
conflict. Yes, this was motivated purely by easing key management.


However, in the Offline KSK and multi-signer scenarios, keytag conflicts 
can still appear. Each co-signer generates their own keys (usually even 
in advance) and there is hardly any way how to synchronize it. And no, 
they are usually not pipelined in the way that the second co-signer 
would see the first one's results first.


One solution that came to my mind would be if the co-signers are 
implemented and carefully configured in the way that one produces e.g. 
only even keytags and the other one only odd keytags. Or modulo 
something for more co-signers. I'm just afraid that resolver caches 
might make the final solution more challenging, needing to consider 
deleted keys which have still some TTL to go...


This is of course not yet implemented anywhere, so we can't outlaw 
keytag conflicts now. We can implement this first in all mainstream 
signing software, then politely ask the rest of the world with a help of 
some new RFC, and only after that, arrive with a flag day...


I'd like to warn about mis-interpreting the (useful!) mentioned 
research. Yes, there are just 200 or so tiny little zones that are 
currently experiencing a keytag conflict. However, there are plenty more 
and really important zones out there that use signing software and setup 
which can generate a keytag conflict at any second, possibly tomorrow. I 
beg please don't in any way consider outlawing keytag conflicts in any 
near future, this would create a hard-to-grasp sneaky danger all around DNS.


Another warning that I have is regarding to simple thoughts like "if the 
resolver sees a keytag conflict, then it shoud XY" (go insecure, go 
bogus, flush cache...). Isn't is possible that an attacker may inject a 
malicious answer packet containing a keytag conflict? In the case of the 
first DNSKEY query, the RRSIG doesn't have to fit, since the resolver is 
just receiving the KSK in that same packet. I mean, the resolver can 
only really be sure that there is (or isn't) a keytag conflict once it 
has already validated the DNSKEY RRSet!


Anyway, it is interesting to see how keytags are transitioning from 
being a probabilistic heuristic to something the resolvers want to rely 
on, and want it to be reliable and unambiguous. And it's funny how at 
the same time, there were ideas of abandoning keytags whatsoever.


I'm not really a "resolver guy". What I think the resolvers should do is 
to somehow limit the very general amount of work per each domain, no 
matter if the amount is caused by keytag conflict, excessive NSEC3 
iteration count, long CNAME chains, expensive signing algorithm, 
whatever. But I'd be still happy if the resolvers impose a limit of 
conflicting keys, to be like 3 or 4.


Thanks for reading!

Libor

 And no, the pipeline doesn't go the way that one co-signer signs "Dne 
14. 02. 24 v 10:39 Petr Špaček napsal(a):

On 14. 02. 24 2:57, Mark Andrews wrote:

On 13 Feb 2024, at 00:56, Edward Lewis  wrote:
On 2/9/24, 22:05, "Mark Andrews"  wrote:

The primary use of the key tag is to select the correct key to 
validate the signature from multiple keys.


Yes - which is great if 1) you need to pare down the potential set 
of keys into something you can handle (like, from 10's to 3) and 2) 
if you have somewhat to request only those keys.


Operators generally only publish 2 keys outside of rolls, 3 when 
rolling the ZSK or the KSK, maybe more if they aren't optimizing.  
There's no need to specify a subset.  I say this with complete 
highsight.


I would still argue that there is still a need even if there is only 
2 keys.  Verification is expensive.  It always has been.


I think CVE-2023-50387 listed on
https://www.nlnetlabs.nl/projects/unbound/security-advisories/
is nice demonstration how dangerous it can be when resolver has to 
implement try-and-see approach.


In my mind this is good enough reason to outlaw keytag collisions - 
without them it would be _much_ easier to implement reasonable limits 
without risk of breaking legitimate clients.




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

Re: [DNSOP] New Version Notification for draft-homburg-dnsop-igadp-00.txt

[libor.peltan]

Hi Philip,

I don't really want to discourage you, but I think this is in general a 
bad idea: optimizing for the best case, but no benefit -- or even 
twice(?) as more resources consumption -- under a random-subdomain attack.


It looks even weirder to me when I see you argumenting with DDoS 
protection in the draft Introduction.


However, Erik indicated that some commercial services are already doing 
this, so I might be wrong in considering it a bad idea (or might not).


Regarding the ECS stuff, I guess that if this is implemented, it should 
you the exact same tricks for sharing ECS among authoritative servers as 
with full AXFR/IXFR. Unfortunately, those tricks are not yet defined by 
IETF (which we suffer as well). I think this deserves some BoF as soon 
as the DNS community gets less busy with current stuff. But this is a 
broader idea which is partly orthogonal to yours.


Libor

Dne 18. 10. 23 v 17:13 Philip Homburg napsal(a):

Based on some feedback we received, I created a draft that describes what to
do if you want to build a proxy that acts as an authoritative server in an
anycast setup. The draft just describes the basics, if there is interest we
can add the details.

Name: draft-homburg-dnsop-igadp
Revision: 00
Title:Implementation Guidelines for Authoritative DNS Proxies
Date: 2023-10-17
Group:Individual Submission
Pages:5
URL:  https://www.ietf.org/archive/id/draft-homburg-dnsop-igadp-00.txt
Status:   https://datatracker.ietf.org/doc/draft-homburg-dnsop-igadp/
HTML: https://www.ietf.org/archive/id/draft-homburg-dnsop-igadp-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-homburg-dnsop-igadp


Abstract:

In some situations it be can attractive to have an authoritative DNS
server that does not have a local copy of the zone or zones that it
serves.  In particular in anycast operations, it is sensible to have
a great geographical and topological diversity.  However, sometimes
the expected use of a particular site does not warrant the cost of
keeping local copies of the zones.  This can be the case if a zone is
very large or if the anycast cluster serves many zones from which
only a few are expected to receive significant traffic.  In these
cases it can be useful to have a proxy serve some or all of the
zones.  The proxy would not have a local copy of the zones it serves,
instead it forwards request to another server that is authoritative
for the zone.  The proxy may have a cache.  This document describes
the details of such proxies.

___
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] NOTIFY: How to locate the target

[libor.peltan]

Hi,

i think this issue shall be considered in two split cases:

a) when the *registry* is to be notified. I think this can be achieved 
easily, the registry only creates a single target for child notifies. 
I'm not sure if current specs allow to do it safely (so that that target 
is separated enough from the rest of registry infrastructure) or any new 
(but single!) record is needed for the target signalling.


b) when the *registrar* is to be notified. AFAIK registrars are so far 
not at all represented anywhere in the DNS tree. I assume that the 
notify target has to be settled somehow in the contract between the 
registrant and the registrar.


The "alternative #2" would demand creating a new zone with as many 
records (mostly CNAMEs?) as there are delegations in the registry. I'd 
expect this would be operationally difficult at least from the point of 
adding/removing records for the zones that are added/removed from the 
registry. Aesthetically speaking, I don't like this idea.


Libor

Dne 08. 11. 23 v 18:05 Peter Thomassen napsal(a):

Dear DNSOP,

As laid out at the DNSOP session on Tuesday, 
draft-ietf-dnsop-generalized-notify (and also 
draft-johani-dnsop-delegation-mgmt-via-ddns) require a method for 
locating the parent-side endpoint (target) where the child DNS 
operator can send a NOTIFY for DS update (or other kind of signal).


Locating the target via a DNS query needs a predictable qname and 
type. The feeling from the room was that for various reasons, a new 
rrtype with SVCB semantics should be used.


As for the qname, the authors would like to gather some feedback from 
the list regarding the preferred approach. The below uses the domain 
"child.se" for illustration:


Alternative #1(a): Look up record at se. (delegating parent's apex)
- Simple
- Clogs the apex with more records
- Likely does not cover all use cases (such as per-registrar target, 
when they want to process the NOTIFY)


Alternative #1(b): Look up record at _notify.se. (some underscore 
label below parent)

- Slightly more complex than above
- Avoids clogging the apex, at the expense of some namespace pollution
- Covers same use cases

Alternative #2: Look up record at child._notify.se. (or other magic 
label)
- Allows parent to publish per-child targets (e.g. the registrar's 
endpoint)

   * Needs maintenance or synthesis
- Magic label could be considered namespace pollution
- Unneeded complexity if parent is not a registry (e.g. a university)

Alternative #3: Try #2, and on failure fall back to #1(a) or #1(b)
- Combines simplicity and flexibility, but conceptually most complex
- Might cause two DNS queries

Please weigh in on what you think is the best approach.

Thanks,
Johan, John, Peter



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

Re: [DNSOP] Automated delegation management via DDNS

[libor.peltan]

Hi,
I'm not sure if this helps the discussion, but Knot DNS implements "DS 
push", an automated DDNS update updating the DS (not NS) at parent.
It's mostly intended for single-organization parent-child relations, 
where TSIG (or soon DDNSoQ) can be configured easily.

Libor

Dne 25. 10. 23 v 17:30 Johan Stenstam napsal(a):

Hi Joe,


On 25 Oct 2023, at 11:32, Joe Abley  wrote:

On 25 Oct 2023, at 10:10, Johan Stenstam 
 wrote:


So now there’s a new draft, that further extends the same core idea (locate the 
target for the information being sent via a DNS lookup in the parent zone). 
However, the new draft (draft-johani-dnsop-delegation-mgmt-via-ddns-00) 
proposes that instead of sending a NOTIFY (triggering a scan from the 
recipient) the child sends a DNS UPDATE containing the exact change with a 
signature that can be verified by the recipient.

I am not at all familiar with SIG(0), so bear with me. What is the key 
distribution mechanism for the DNS UPDATE originator's public key? RFC 2931 
suggests an unsigned KEY RR, I think?

My answer is “whatever mechanism the child and parent is using today for 
communicating critical information like that”. The thing here is that I do not 
primarily expect the TLD registries to change from the current path of either 
no automation of synchronisation of delegation information OR running a CDS 
(and perhaps CSYNC) scanner.

The problem I have with that is that this leaves out major parts of the 
namespace. I.e. I want a mechanism that works for the University of Foobar to 
automate the delegation information for a ~100 departments. I want a mechanism 
that works for the Stockholm Health Care district to deal with hundreds of 
hospitals, care givers and other parts of the local health care infora 
structure. Etc. Neither of those have DNS as a major focus, DNSSEC even less 
and they are extremely unlikely to run any CDS and/or CSYNC scanners in the 
foreseeable future.

So what do all these parents that are not registries use today? All sorts of 
semi crappy mechanisms, from email, via webforms to various local APIs, etc. 
All of these mechanisms have drawbacks, all have security issues and all of 
them have a certain failure rate because there is manual labor involved.

I want to completely get rid of the manual part of maintaining existing 
delegations and the proposal is to transport the public key to the parent in 
any way that is acceptable to both child and parent. I don’t think an unsigned 
KEY RR is a particularly attractive alternative, but I have nothing against a 
DNSSEC signed KEY RR.

Johan

PS. In the case where the parent *is* a registry, and there are registrars then 
I think an EPP extension for the submission of the public SIG(0) keys will work 
just fine. But, as I said, that’s not my primary goal at this time.


___
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: New Version Notification for draft-peltan-edns-presentation-format-01.txt

[libor.peltan]

Hi Ben, DNSOP,


thank you so much for your reading and comments. We considered both of 
your suggestions useful, and substantially updated the document to 
reflect them:


 - for each EDNS option, abstract name, type and value are defined, and 
both presentation and JSON formats are derived from those, leading to 
mutual unification


 - the presentation format is as similar as arguably possible to 
current dig/kdig text output



The new version of the draft can be seen here: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-02.html



We also already have a piece of "running code": kdig 3.3.2 implements 
both JSON and presentation format in accordance to the draft.



We think this might be of interest of DNSOP.


Thanks,


Libor


Dne 29. 08. 23 v 19:01 Ben Schwartz napsal(a):
I have reviewed this draft.  It seems potentially useful and like a 
reasonable attempt to define a solution.


I would like to see a unified rule connecting the text and JSON 
representations, rather than explicitly defining new formats for each 
key (and in some cases even changing the key names, e.g. NSID vs. 
NSIDHEX).  For example, some options could be defined as having "list" 
type output, and then we could define generically how list values are 
represented in JSON and text. Similarly for numbers, strings, etc.  
Alternatively, the JSON format could be defined first, and the text 
format could be defined via an algorithm that acts generically on the 
JSON values.


I think it's worth taking a close look at the existing commonly used 
presentation formats before defining a new one.  For example, it might 
be worthwhile to standardize a text representation that is closer to 
the current "dig" output, for the sake of compatibility with existing 
systems.


--Ben Schwartz
----
*From:* DNSOP  on behalf of libor.peltan 


*Sent:* Wednesday, May 31, 2023 4:33 AM
*To:* dnsop 
*Subject:* [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt
Hi dsnop, we'd like to turn your attention again to our draft 
https: //www. ietf. org/archive/id/draft-peltan-edns-presentation-format-01. html 
We believe this document shall fill a missing gap in specifications, 
and help interoperability of DNS

ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html 
<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html>


We believe this document shall fill a missing gap in specifications, 
and help interoperability of DNS tools. Therefore, we think it'd make 
sense if this document once becomes a dnsop-homed RFC.


We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Future EDNS(0) Options (thanks 
to Pieter Lexis); nitpicks.


Thank you!

Libor and Tom



 Přeposlaná zpráva 
Předmět: 	New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Datum:  Wed, 31 May 2023 01:30:33 -0700
Od: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
Komu: 	Libor Peltan  
<mailto:libor.pel...@nic.cz>, Tom Carpay  
<mailto:tomcar...@gmail.com>





A new version of I-D, draft-peltan-edns-presentation-format-01.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 01
Title: EDNS Presentation and JSON Format
Document date: 2023-05-31
Group: Individual Submission
Pages: 20
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt 
<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt>
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/ 
<https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/>
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format 
<https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format>
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01 
<https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01>


Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat



___
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-bellis-dnsop-qdcount-is-one-01.txt

[libor.peltan]

I would even rather see a recommendation that firewalls and middleboxes 
don't do any kind of DNS packet handling. Why should they? DNS traffic 
is for DNS servers and they are the most capable entity for handling 
them, including FORMERR responses on wrongly formatted queries.


Libor

Dne 29. 09. 23 v 0:08 Robert Edmonds napsal(a):

Hi,

I noticed that Section 4 of the draft states:

Firewalls that process DNS messages in order to eliminate unwanted
traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as
malformed traffic.  See Section 4 of [RFC8906] for further guidance.

However, I couldn't find the guidance in Section 4 of RFC 8906 being
referred to. Most of that section is actually about misbehavior in
firewalls in response to well-formed traffic, not correct behavior in
response to malformed traffic. The most relevant text seems to be:

Firewalls and load balancers should not drop DNS packets that they
don't understand.  They should either pass the packets or generate an
appropriate error response.

[…]

However, there may be times when a nameserver mishandles messages
with a particular flag, EDNS option, EDNS version field, opcode, type
or class field, or combination thereof to the point where the
integrity of the nameserver is compromised.  Firewalls should offer
the ability to selectively reject messages using an appropriately
constructed response based on all these fields while awaiting a fix
from the nameserver vendor.  Returning FORMERR or REFUSED are two
potential error codes to return.

If I understand correctly, the QDCOUNT is a field, not a flag, so it
would not be included in the list of "a particular flag, EDNS option,
EDNS version field, opcode, type or class field, or combination thereof"
described here. Even if QDCOUNT were included in this list, I can't
think of an example where QDCOUNT > 1 would compromise the integrity of
a nameserver. One could also imagine a *valid*, non-malformed
combination of query parameters that could result in the integrity of a
nameserver being compromised, so this paragraph isn't solely about
malformed traffic. So I'm having difficulty understanding how exactly to
apply this section when reading it alongside the draft.

If the intention of Section 4 of this draft is to allow firewalls to
meddle with OPCODE = 0, QDCOUNT > 1 as a general, ongoing deployment
posture rather than as a temporary workaround "while awaiting a fix from
the nameserver vendor", it would seem to go a bit beyond the narrow
guidance in Section 4 of RFC 8906.

Also, I think the phrase "to eliminate unwanted traffic" is vague. How
would a firewall eliminate unwanted traffic? May it drop OPCODE = 0,
QDCOUNT > 1? May it synthesize a FORMERR response? If it synthesizes a
FORMERR response, should those responses be rate-limited in case the
sender's source address is spoofed?

Thanks!

Joe Abley wrote:

Hi all,

This version mainly incorporates feedback from the room at the last meeting and 
relate to document clarity; the advice is unchanged.


Joe


On 28 Sep 2023, at 15:21, internet-dra...@ietf.org wrote:

Internet-Draft draft-bellis-dnsop-qdcount-is-one-01.txt is now available. It
is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.

   Title:   In the DNS, QDCOUNT is (usually) One
   Authors: Ray Bellis
Joe Abley
   Name:draft-bellis-dnsop-qdcount-is-one-01.txt
   Pages:   7
   Dates:   2023-09-28

Abstract:

   This document clarifies the allowable values of the QDCOUNT parameter
   in DNS messages with OPCODE = 0 (QUERY) and specifies the required
   behaviour when values that are not allowed are encountered.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one-01

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-bellis-dnsop-qdcount-is-one-01

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

Re: [DNSOP] Cache refreshes like in DNS over CoAP

[libor.peltan]

Hi,

I have also difficulties finding any benefit of such feature. Shall it 
help lowering bandwidth usage for authoritatives or for recursives? I'd 
say that for authoritatives in general, legitimate traffic is the 
minority, so reducing that would not help much.


I'd oppose the idea of having the "noting has changed" signal insecure. 
It should be carefully discussed why it would be not a big problem.


One idea that came to my mind is to utilize ZONEMD: the recursive could 
re-query just ZONEMD (+its RRSIG), assume that nothing else in the zone 
has changed (SOA, DNSKEYs, any RRSIGs), and re-set their TTLs to 
original. It could just cause problems if TTL of ZONEMD is greater than 
TTL of DNSKEY, in case of some key roll-overs, so one would probably 
require the TTL of ZONEMD be the minimum of zone's TTLs (currently it's 
RECOMMENDED to equal SOA TTL).


Libor

Dne 04. 08. 23 v 13:07 jab...@strandkip.nl napsal(a):

Hi Petr,

On Aug 4, 2023, at 05:21, Petr Menšík  wrote:


Again, this proposal is not targeted to gigabit+ links connectivity. This is 
not indented to fight DDoS in data centers. It would be links, where data are 
still counted in kilobytes or megabytes. Satellite links or long range radios 
might be example. Low-power IoT devices battery operated devices as well.

I still have my doubts about the usefulness of shaving a relatively small 
number of bytes off a transaction that is already pretty light on the wire. Any 
device for which a significant proportion of its available capacity is consumed 
by DNS in normal operation is presumably not doing very much else. But...


I would recommend checking the paper I have referenced about CoAP. It explains 
well constrained environment with limited connectivity and low maximal MTU.

... that is a very reasonable request, and I will do so.


Joe

___
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-domain-verification-techniques-02.txt

[libor.peltan]

Dne 17. 07. 23 v 21:41 Brian Dickson napsal(a):


TCP traffic is several orders of magnitude more expensive than UDP.


This might be true, but it must be carefully considered. Yes, a 
performant authoritative server is able to answer (for example) 10 Mqps 
over UDP or 10 kqps over TCP. One could conclude, that a TCP query is 
1000x more expensive than a UDP query.


However, typical authoritative server (anywhere) faces up to 10 kqps of 
legitimate traffic, or often less. For reliable DNS over UDP service 
though, it needs to have giant overhead in performance, in order to 
mitigate possible UDP DoS attacks, which can't be mitigated otherwise. 
So it needs to be able to answer 10 Mqps at peak.


I'm not sure how much overhead is needed to handle possible TCP DoS 
attacks. Most of them are SYN attacks, which can be handled already in 
some firewall/BPF (hand waving). The rest -- dunno. Let's say that you 
need 2x overhead for TCP, that is 20 kqps, that is two servers.


In the end, in my example (the figures may be wy wrong), TCP looks 
like 2x more expensive than UDP. Even if all the DNS queries were TCP.


(In Knot DNS, we implemented TCP-over-XDP, which offers great 
performance leap. I admit that it is not entirely production-quality 
yet, but we expected to keep improving it while getting feedback from 
users. We promoted it on some impacted DNS community meetings, but AFAIK 
it earned no attention at all. Therefore, I suspect that there is little 
concern about DNS-over-TCP performance.)


I think its short-sighted attempting to keep authoritative DNS be mostly 
UDP. Especially vetoing any kind of progress that would "threaten" 
increased usage of TCP. We have RFC 7766 and soon we'll have 
authoritative DoQ.


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

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

[libor.peltan]

Hi Peter,

Dne 23. 06. 23 v 19:29 Peter Thomassen napsal(a):

On 6/23/23 17:21, libor.peltan wrote:
I would expect the combination of a nameserver not being reachable 
and the other party being malicious to be quite a rare event.
A combination of a nameserver being unreachable and an other one 
being misconfigured e.g. in the sense of Section 2.2.1 (in the -03 
version of the doc) does not seem too inprobable to me.


My take is that the likelihoods multiply, so the combination is much 
more unlikely than an isolated event of either type.


My concerns are based on following situation. Imagine that:

 - two servers publish inconsistent CDNSKEY+CDS records for some 
reason, e.g. misconfiguration. This is the exact thing that the draft 
tries to address.


 - this persists for quite some time, which is highly probable, as DNS 
is usually a slowly-changing environment.


 - the parent queries both servers and detects the inconsistency. So it 
does nothing and tries later. It is the same. It tries again, but still 
the same.


 - it tries once more and it happens that some stumble on the network 
causes that one of the queries/responses/connections times out and one 
of the CDNSKEY+CDS scans fails.


 - the parent concludes that one of the servers in unreachable and the 
other one is consistent with itself, accepting his CDNSKEY+CDS. This is 
the very thing that your draft is trying to defend against, but fails in 
this case.


I would think about defining some form of "permanent unreachability" and 
ignore the servers only in that case. Everything would become much more 
complicated, but I think it is the right thing to do. And if not, it 
should be argumented that the risk is reasonably acceptable.




Oh yeah, I agree. It's just that the section got longer and longer, 
and I felt like it takes forever until the reader arrives at the 
actual spec -- so I turned that section into an appendix.

All right! I overlooked the appendix, sry.


Cheers,
Peter

Please don't take his as if I tried to torpedo your draft. I'm trying to 
improve it by constructive opposition ;)


Libor

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

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

[libor.peltan]

Hi Peter,

Dne 22. 06. 23 v 18:10 Peter Thomassen napsal(a):
I would expect the combination of a nameserver not being reachable and 
the other party being malicious to be quite a rare event.
A combination of a nameserver being unreachable and an other one being 
misconfigured e.g. in the sense of Section 2.2.1 (in the -03 version of 
the doc) does not seem too inprobable to me.


Given the probably much more frequent "price" of blocking DS 
maintenance, I think this is the right trade-off.
If you think this is the right trade-off, you should write into the 
document that this is the right trade-off, and that this consideration 
has been made. I would kindly leave the exact wording on you.


Where would you suggest to put more words about that? (Right there, or 
in the Security Considerations? Which words?)
I'm not sure. Anyway, the Security Considerations section also claims 
"ensuring that an operator in a multi-homing setup cannot unilaterally 
modify the delegation", which is not entirely true according to me, 
considering the above discussion. If one nameserver becomes (even 
temporarily!) unreachable, the inability of unilateral modification is 
not ensured. It's only trade-off-ed :)


Also, I addressed all other comments received so far in response to 
the adoption call (commits in same repo). For convenience, see the 
editor's copy: 
https://peterthomassen.github.io/draft-ietf-dnsop-cds-consistency/
Ouch, it seems that in your newest version, Section 2 disappeared 
completely. I'd vote for keeping the motivational prose present. 
Disclosing the motivations and goals of a standard is a good habit among 
RFCs.


Best,
Peter


Cheers,

Libor

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

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

[libor.peltan]

Hi,
here are my comments to draft-thomassen-dnsop-cds-consistency-03.

"In all cases, consistency is REQUIRED across received responses only. 
Nameservers that appear to be unavailable SHOULD be disregarded as if 
they were not part of the NS record set."


I don't feel confident about the consequences of this cathegorical 
statement. What if you have two DNSSEC providers, one has an outage (or 
just network breakage between them and the polling entity), and the 
other one maliciously takes over by publishing new CDNSKEYs? The polling 
entity might re-query several times from different locations, but this 
is usually only performed when bootstrapping the scure delegation, not 
when already established. And even if, it's not clear if (when) this 
would be enough. I understand, on the other hand, that relying on 
permanently disfunctional (or lame in any meaning of that word) child 
NSs might be problematic. To sum this up, if this is an issue in the 
proposed method, it should be fixed, and if it isn't, it should be more 
verbosely described why. The document seems too brief in this regard.


"CDS/CDNSKEY records at the Child zone apex MUST be fetched ... with 
DNSSEC validation enforced."


Isn't this sentence disabling secure delegation bootstrapping?

Thanks,
Libor

Dne 21. 06. 23 v 15:52 Tim Wicinski napsal(a):


All

The call for adoption period for this draft wrapped up this morning.  
While we saw several strong comments and issues raised, we also saw 
the working group wishing to adopt this work and working on it.  We 
consider this passed. Thanks all, and we will work with the authors to 
itemize the list of larger issues


thanks
tim


On Wed, Jun 7, 2023 at 11:52 AM Tim Wicinski  wrote:


All,

We've had this document in DNSOP for a bit and Peter has presented
three different meetings. When I went back and looked at the
minutes, the feedback was good.  But when the chairs and Warren
discussed it, we had confused ourselves on this document, which is
our bad.  We decided to stop confusing ourselves and let the
working group help us out.

What I did was to pull the comments on this document from the
minutes of the meetings and include them below to make it easier
to remember what was said.


This starts a Call for Adoption for
draft-thomassen-dnsop-cds-consistency

The draft is available here:
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/

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: 21 June 2023

Thanks,
tim wicinski
For DNSOP co-chairs

Minutes from past meetings on "Consistency for CDS/CDNSKEY and
CSYNC is Mandatory"



114
    Mark: CDS records are no different than any others
        One NS might be down, which would stop the
        Peter: This is telling the parent how to act when faced with
inconsistent information
    Viktor: There might be hidden masters
        Don't want to get stuck
        Peter: Wording could be changed to allow servers down
    Ben: There is a missing time constant
        When do I recheck if I get an inconsistent set?
        Peter: 7344 doesn't put any time limit
        Ben: Should suggest some time to retry when there is an
inconstancy

115
    Wes: Supports this
        Likes mandating checking everywhere
    Ralf: Supports this
        Can't ask "all" servers in anycast
        What if you don't get a response
        Peter: Ask each provider
            Is willing to add in wording about non responses
        Paul Wouters: This wasn't in CSYNC, our bug
    Viktor: Concern was hidden masters and nameservers that are gone
and are never going to come back


116
    Viktor: Corner case: if someone is moving to a host that doesn't
do DNSSEC
        Peter: Could add a way to turn off DNSSEC on transfer
    Johan Stenstram: Breaks the logic that "if it is signed, it is
good"
        Doesn't like "if this is really important"
        Let's not go there
        Authoritative servers are proxies for the registrant
        Out of sync is reflection on the registrant: business issues
    Wes: CSYNC was for keeping DNS up and running
        CSYNC can't fix the business problems
    Peter: Agrees that one signature should be OK
        Other parts of the spec also suggest asking multiple places


___
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: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

[libor.peltan]

Hi,

I like the ideas in this document and I support its adoption, willing to 
comment its contents.


Libor

Dne 07. 06. 23 v 17:52 Tim Wicinski napsal(a):


All,

We've had this document in DNSOP for a bit and Peter has presented 
three different meetings. When I went back and looked at the minutes, 
the feedback was good.  But when the chairs and Warren discussed it, 
we had confused ourselves on this document, which is our bad.  We 
decided to stop confusing ourselves and let the working group help us out.


What I did was to pull the comments on this document from the minutes 
of the meetings and include them below to make it easier to remember 
what was said.



This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency

The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/


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: 21 June 2023

Thanks,
tim wicinski
For DNSOP co-chairs

Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC 
is Mandatory"




114
    Mark: CDS records are no different than any others
        One NS might be down, which would stop the
        Peter: This is telling the parent how to act when faced with
inconsistent information
    Viktor: There might be hidden masters
        Don't want to get stuck
        Peter: Wording could be changed to allow servers down
    Ben: There is a missing time constant
        When do I recheck if I get an inconsistent set?
        Peter: 7344 doesn't put any time limit
        Ben: Should suggest some time to retry when there is an
inconstancy

115
    Wes: Supports this
        Likes mandating checking everywhere
    Ralf: Supports this
        Can't ask "all" servers in anycast
        What if you don't get a response
        Peter: Ask each provider
            Is willing to add in wording about non responses
        Paul Wouters: This wasn't in CSYNC, our bug
    Viktor: Concern was hidden masters and nameservers that are gone
and are never going to come back


116
    Viktor: Corner case: if someone is moving to a host that doesn't
do DNSSEC
        Peter: Could add a way to turn off DNSSEC on transfer
    Johan Stenstram: Breaks the logic that "if it is signed, it is
good"
        Doesn't like "if this is really important"
        Let's not go there
        Authoritative servers are proxies for the registrant
        Out of sync is reflection on the registrant: business issues
    Wes: CSYNC was for keeping DNS up and running
        CSYNC can't fix the business problems
    Peter: Agrees that one signature should be OK
        Other parts of the spec also suggest asking multiple places


___
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-peltan-edns-presentation-format-01.txt

[libor.peltan]

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html


We believe this document shall fill a missing gap in specifications, and 
help interoperability of DNS tools. Therefore, we think it'd make sense 
if this document once becomes a dnsop-homed RFC.


We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Future EDNS(0) Options (thanks to 
Pieter Lexis); nitpicks.


Thank you!

Libor and Tom



 Přeposlaná zpráva 
Předmět: 	New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Datum:  Wed, 31 May 2023 01:30:33 -0700
Od: internet-dra...@ietf.org
Komu:   Libor Peltan , Tom Carpay 




A new version of I-D, draft-peltan-edns-presentation-format-01.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 01
Title: EDNS Presentation and JSON Format
Document date: 2023-05-31
Group: Individual Submission
Pages: 20
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01


Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[libor.peltan]

Hi Paul,

if you really ask for opinions, here is mine.

Considering the recent voluminous discussion about the meaning of Lame 
delegation, it seems to me that there are at least several people being 
more-or-less sure what the term means, with the issue that everyone 
thinks something slightly (or less slightly) different.


A word that means something different according to each speaker is not a 
good communication tool. I'm afraid (but not sure) that we should rather 
avoid it to prevent present and future misunderstanding.


In order to do so, I'd suggest treating it similalrly as the term 
Bailiwick: abandon the word and make up a new, precisely defined term 
that means the same for everyone. But I don't insist.


Cheers,

Libor


Dne 01. 05. 23 v 18:09 Paul Hoffman napsal(a):

It would be grand if a bunch more people would speak up on this thread.

--Paul Hoffman, wearing my co-author hat

On Apr 27, 2023, at 1:05 PM, Benno Overeinder  wrote:

Dear WG,

The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
on lame delegation did not find consensus, but two specific suggestions
were put forward.  We would like to include one of them in rfc8499bis if
we can get consensus to do so.

The chairs are seeking input on the following two suggestions:

* Either we leave the definition of “lame delegation” as it is with the
  comment that no consensus could be found, or

* alternatively, we include a shorter definition without specific
  examples.

1) Leaving the definition of lame delegation as in the current
   draft-ietf-dnsop-rfc8499bis, and including the addition by the
   authors that:

   "These early definitions do not match current use of the term "lame
   delegation", but there is also no consensus on what a lame delegation
   is."  (Maybe change to ... no consensus what *exactly* a lame
   delegation is.)

2) Update the definition as proposed by Duane and with the agreement of
   some others (see mailing list 
https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/):

   "A lame delegation is said to exist when one or more authoritative
   servers designated by the delegating NS RRset or by the child's apex
   NS RRset answers non-authoritatively [or not at all] for a zone".

The chairs ask the WG to discuss these two alternative definitions of
the term "lame delegation".  We close the consultation period on
Thursday 4 May.

Regards,

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] Subject: request for adoption: draft-edns-presentation

[libor.peltan]

Hi Pieter,

Dne 24. 11. 22 v 11:41 Pieter Lexis napsal(a):

I wonder if it should update RFC 6891 and all related OPTION RFCs as
well.

I'm not sure as well.


I also wonder if it could make sense to add guidance on how to choose
the correct presentation format for newly drafted EDNS options so
future option-drafts and documents have presentation formats in there.
Thanks much for this idea! We will definitely add some guidance for 
future EDNS(0) options' specifications authors.

Best regards,

Pieter

___
DNSOP mailing list
DNSOP@ietf.org


Nice friday!

Libor

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

[DNSOP] Subject: request for adoption: draft-edns-presentation

[libor.peltan]

Hi DNSOP,
we have prepared a specification document (see below), which fills a gap 
that appears to be missing currently — The EDNS(0) textual and JSON format.

It also fixes a "specification bug" in an existing and related RFC.

We believe this draft is pretty much complete and have a first PoC 
implementation ready. While it would be viable to submit it 
individually, we believe that the adoption by the WG would be generally 
beneficial.


We would also welcome any improvement suggestions and useful 
corrections. However, fearing discussion loops arguments about details, 
we encourage to moderate discussion of details, such as if some fields 
in a specific option shall be separated by commas or slashes.
This document is full of design decisions that might be differently 
appealing to everyone. The format might seem complicated, but the goal 
was best possible human readability.
And the more general (and important) goal is to make the standard 
useful, so that it gets adopted by implementations.


Thank you for reading the document and for considering its adoption,
Libor & Tom



 Přeposlaná zpráva 
Předmět: 	New Version Notification for 
draft-peltan-edns-presentation-format-00.txt

Datum:  Wed, 23 Nov 2022 11:20:19 -0800
Od: internet-dra...@ietf.org
Komu:   Libor Peltan , Tom Carpay 




A new version of I-D, draft-peltan-edns-presentation-format-00.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 00
Title: EDNS Presentation and JSON Format
Document date: 2022-11-23
Group: Individual Submission
Pages: 19
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format



Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat

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

Re: [DNSOP] .alt filtering in recursive servers

[libor.peltan]

Dne 11. 11. 22 v 10:48 Wessels, Duane napsal(a):

5.  Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .alt names with NXDOMAIN.


I don't like to repeat myself, but I still consider this requirement 
proposal inproper and I disagree with it.


The reasons have been already stated.

Libor

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

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

[libor.peltan]

Hi,

regarding the question of "necessary" versus "useful". I apologize, but 
I must kind-of undermine the question.


Imagine that a delegation is supplemented with an SVCB record that 
describes how to connect securely (with TLS) to the delegated 
nameserver. (Dunno if this really can happen today, but it's an 
imaginable situation in general.)


Then the SVCB is not necessary for the DNS resolution per se, but it is 
necessary for the resolution to proceed securely. If the client's policy 
is "privacy or nothing", then they will not proceed with the resolution 
unless the SVCB is returned. As a consequence, the record is not 
necessary to some clients (but may still be useful), but necessary to 
others. Thus, the term necessary is relative and it can hardly be used 
in the definition of glue.


Thank you for considering my comment :)

Libor

Dne 03. 11. 22 v 22:48 Benno Overeinder napsal(a):

Dear WG,

With the DNSOP rfc8499bis interim in September, we had the action 
point to send two questions to the DNSOP WG to find consensus on the 
bailiwick and glue discussion.


You can find the interim meeting material here 
https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop 
and the recording of session here https://youtu.be/wY7-f40lDgU.


This is the second email to the WG, focussing on the definition of glue.

Questions:

2. Definition of Glue provided by Duane Wessels on the DNSOP WG mailing
   list:

   "Glue is non-authoritative data in a zone that is transmitted in the
   additional section of a referral response on the basis that the data
   might be necessary for resolution to proceed at the referred name
   servers."

   On the mailing list, we have seen a discussion about "necessary"
   versus "useful".  In this context glue is defined to be exclusively
   A/ records (traditional understanding), or do we also consider
   other RRtypes to be glue, e.g. SCVB/HTTPS or DS records? Concern is
   that "useful" may lead to a definition that is too broad.

Taking the last point a step further: if the definition is expanded 
and glue-is-not-optional becomes a requirement then responses may grow 
in size and exceed fragmentation/truncation thresholds and lead to 
more TCP.


Remark by WG during interim meeting: One might need a registry for 
RRtypes being glue (in the future).


Thanks,

-- Suzanne, Tim and 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] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

[libor.peltan]

Hi,

I'm trying to understand this, but not sure if I do. What I see is:

"The definition of bailiwick (in-b, out-of-b) is messed up and any 
further use of it in normative documents will probably lead to 
ambiguities. The proposed tactic is to stop using it and define a new 
term (in-domain) which means the same but it's definition will be 
precise and relevant in current state of DNS."


If my understanding above is matching reality, then (note the 
implication) I agree with the proposed tactic.


Libor

Dne 03. 11. 22 v 22:44 Benno Overeinder napsal(a):

Dear WG,

With the DNSOP rfc8499bis interim in September, we had the action 
point to send two questions to the DNSOP WG to find consensus on the 
bailiwick and glue discussion.


You can find the interim meeting material here 
https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop 
and the recording of session here https://youtu.be/wY7-f40lDgU.


We will send two questions to the WG, in two separate emails to keep 
the discussion separate.  This email is the first question to the WG 
that addresses the definition of bailiwick.



Questions:

1. Move Bailiwick to historical.

1a.  During the interim, there was a (feeling of) consensus to drop a
 formal definition of "bailiwick", but keep a historical definition
 (how it was interpreted by) of "bailiwick". Also do not define and
 use the term "in-bailiwick".

 Suggested terms to use are "in-domain name server" and "sibling
 domain domain server", as defined and used in
 draft-draft-ietf-dnsop-glue-is-not-optional, section 2.1 and 2.2.

 [The latest draft of glue-is-not-optional does provide a definition
 of sibling domain name servers, but it does not really provide one
 for in-domain name servers.  That would be easy to fix.]

1b.  Does this also mean changing the definition of "out-of-bailiwick"
 to a more historical definition as well?  Or do we still need a
 term for in-domain name server, sibling domain name server and ...
 (alternative for out-of-bailiwick)?

 Is "unrelated name server" a term that can be used?


Thanks,

-- Suzanne, Tim and 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] [Ext] root crud, Possible alt-tld last call?

[libor.peltan]

Dne 26. 10. 22 v 19:02 Klaus Frank napsal(a):
I don't quite understand what the controversial part with this is, but 
why not just copy RFC7686 (onion special use domain name) for .ALT?



Please don't.

RFC7686 requires that all DNS software, both recursive and 
authoritative, treats .onion in specific way. AFAIK this is ignored by 
many. A standard that is widely being deliberately ignored is not a best 
standard.


Moreover, it requires that non-root authoritative servers answer 
NXDOMAIN out of their bailiwicks, which is against all other standards 
and general DNS concepts.


I suspect that RFC7686 had not been reviewed enough by DNS nerds before 
published. Dunno the history, but please at least, don't repeat it.


Thanks,

Libor

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[libor.peltan]

Dne 24. 10. 22 v 20:18 David Conrad napsal(a):

Libor,

On Oct 24, 2022, at 9:11 AM, libor.peltan  wrote:

The root of the DNS is a commons, supported by volunteers who are paying out of 
their own pocket to provision a global infrastructure. I’m personally not 
comfortable recommending techniques that can add undefined (could be minimal, 
might not be: no one knows for sure) load to that infrastructure.

Well, the modern and well-configured resolvers will protect Root servers by employing 
Aggresive Negative Caching or Root Zone Prefetch (and eventually Query Name Minimisation 
for the sake of querier's privacy); outdated and broken resolvers will keep bombing the 
root's auths with junk queries even if we declare they MUST NOT. As a consequence, those 
arguments for this "MUST NOT" are moot.

We appear to be arguing about wording/capitalization.

I don't think so.


Obviously, simply saying “MUST NOT” in an RFC will have (and has always had) 
zero effect on code behaviors. What matters is what people actually implement. 
If a modern/well-configured iterative resolver/forwarder implements according 
to (the potential future) spec (either “MUST NOT” or “should not”), then all 
queries for .alt sent by outdated/broken stub resolvers will not bomb the root 
as soon as the modern code is deployed.  As applications/operating systems get 
updated over time, even the stub resolvers could behave better.  However, 
implementation of code is all about priorities. I personally believe that, in 
general, a spec that says “MUST NOT” has a slightly higher likelihood of being 
prioritized over a spec that says “should not” but maybe that’s just me.
So far, the modern features like Aggresive Negative Caching and Root 
Zone Prefetch (hereinafter: (*)) are already standardized and being 
implemented by a (hopefully) raising fraction of resolvers. Do you think 
that if we now standardize this explicit blockade of specific TLD for 
resolvers, it will get implemented much faster and broadlier than (*) 
and protect the Root zone in the meantime before (*) is implemented 
sufficiently close-to-everywhere?


The real point here is #3 in the list I provided earlier:

"3) whether the inevitable leakage of .alt queries to the DNS represent potential 
issues, and if so, should there be an effort to address those issues."

Using the AS112 project approach could help address the leakage to the root 
issue (even for outdated/broken resolvers), although it wouldn’t generally 
address the privacy leakage issue. It also has its own implications (e.g., 
delegating an explicitly non-DNS TLD in the DNS). Given the AS112 approach 
doesn’t result in code change, would you be ok with using it with .alt?


I don't like neither lame delegation of non-DNS name in DNS Root Zone, 
nor lame DNAME therein.



I would expect the correct approach is:

1) Put a proper MUST NOT into the piece of software that will be 
responsible for determining DNS and non-DNS queries. It should prevent 
query leakage into DNS as much as possible.


2) If it doesn't, the resolver should be able to avoid any lame queries 
(not limited to .alt) to Root zone with the help of (*). We don't need 
any RFC for this -- this already happens, and frankly: if Quad8 
implements this, half of the problem is gone.


3) If it doesn't, the Root servers shall be solid enough to withstand a 
stream of lame queries (not limited to .alt). We don't need and RFC for 
this, this already happens.



On the other hand, I agree that an analysis of how heavily the Root 
Server could potentially be impacted by stray .alt queries would be 
beneficial for deciding if we need to implement a defense and how. But I 
doubt this is possible to estimate.




Regards,
-drc


Libor

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[libor.peltan]

Hi,

Dne 23. 10. 22 v 21:00 David Conrad napsal(a):


The root of the DNS is a commons, supported by volunteers who are 
paying out of their own pocket to provision a global infrastructure. 
I’m personally not comfortable recommending techniques that can add 
undefined (could be minimal, might not be: no one knows for sure) load 
to that infrastructure.


Well, the modern and well-configured resolvers will protect Root servers 
by employing Aggresive Negative Caching or Root Zone Prefetch (and 
eventually Query Name Minimisation for the sake of querier's privacy); 
outdated and broken resolvers will keep bombing the root's auths with 
junk queries even if we declare they MUST NOT. As a consequence, those 
arguments for this "MUST NOT" are moot.


I personally don't like any suggestions that recursive and/or 
authoritative server software has some hard-wired handling of special 
TLDs. Especially (but not limited to!) RFC7686 (.onion), which requires 
even non-root auth servers to answer NXDOMAIN for names out of their 
configured bailiwicks (which is being ignored by auth software vendors 
AFAIK).


Libor

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

Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

[libor.peltan]

Hi,

Dne 13. 09. 22 v 18:21 Viktor Dukhovni napsal(a):

The "OPT-RR" is message metadata, and so should not be confused with
other sorts of additional records.  (TSIG would also fall into that
bucket).


Thank you for this point. So we should invent a way how to convert OPT 
record into properties of the JSON-represented message structure.


However, RFC 8427 gives no hints at all, how to do it. So there is big 
chance that everyone will implement this differently, leading to 
non-interoperability.


Can we do something about it?


I should also note that in terms of presentation forms, the SVCB record
is particularly challenging, since it also sports extensible options of
arbitrary types, and requires both a generic presentation form (for not
known options) and a type-specific form for known options.


It seems that SVCB will be standardized soon, which makes me think that 
we may inspire ourselves.


It might be possible to invent a presentation format for EDNS (despite 
it does not appear in zonefiles, it should be still useful for other 
purposes), which would use the same tricks as SVCB presentation format. 
What do you think?


Thanks,

Libor

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

[DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

[libor.peltan]

Hi all, especially Paul,

while implementing RFC 8427 in Knot DNS, we found that this RFC does not 
say anything about EDNS option. This results in general rules for RR 
being applied, resulting in very ugly:


  "additionalRRs": [
    {
  "NAME": ".",
  "TYPE": 41,
  "TYPEname": "OPT",
  "CLASS": 1232,
  "TTL": 32768,
  "rdataOPT": "\\# 24 
00030014646E732D7669782D646E7330312E6E69632E637A",

  "RDLENGTH": 24,
  "RDATAHEX": "00030014646e732d7669782d646e7330312e6e69632e637a"
    }

It seems interesting to me, that this RFC is single-authored, 
Informational and non-WG.


Do you think we should improve this, making the JSON representation of 
OPT anyhow more useful?


If so, how do you think we should proceed? Writing a new RFC draft 
updating this?


Thank you for considerations,

Libor

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

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

[libor.peltan]

Hi Willem, Yorgos, Roy, dnsop,
I dare to repeat my support for the ideas in dry-run-dnssec draft.
However, I still don't like the suggested format of dry-run DS record.
Another alternative idea: how about putting the Digest Type into the 
first octet of Digest field like in the draft, but cropping (or 
stretching) the rest of the actual digest in a way that the overall size 
of the resulting Digest field is something "normal" (e.g. 32 octets), 
and does not differ based on actual Digest Type? I assume that for 
dry-run, the weakened actual security of cropped Digest is not a big deal.

Please consider my thought and employ/deny it as needed.
Best,
Libor

Dne 12. 07. 22 v 16:35 Willem Toorop napsal(a):

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



___

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

[libor.peltan]

Hi Peter, Nils, DNSOP,

In general, I very much like the Bootstrapping idea, and the draft. I 
also like that it now allows in-bailiwick NS (unless in-bailiwick-only).


However, I'd like to discuss if it really should *replace* RFC8078, 
Section 3 whatsoever.


Sure, it's definitely more secure than the rather quirky Accept after 
Delay/Checks/Challenge procedures, but it adds also more limitations, as 
described in section 3.4 anyway.


I would prefer if both options remained standardized in parallel, so 
that anyone can choose between more secure, or more universal way of 
DNSSEC bootstrapping.


Alternatively, we may say that the RFC8078 bootstrapping is deprecated, 
but still, it doesn't mean that we replace it.


Thanks for more opinions,

Libor

Dne 17. 06. 22 v 12:17 Peter Thomassen napsal(a):

Dear DNSOP,

We have addressed the WG's feedback from the Interim on May 24, and 
also addressed remaining outstanding issues (mainly editorial).


From the authors' perspective, the protocol draft is now "final" (in 
the sense, that no action items remain). We would appreciate the 
group's thorough feedback, and -- if the group feels like it -- 
proceed to WG Last Call



The most significant changes are:

Introduced Signaling Type prefix (_dsboot), renamed Signaling Name 
infix from _dsauth to _signal.


Allow bootstrapping when some (not all) NS hostnames are in bailiwick.


Due to the first change, DS signaling records now live at names such 
as: _dsboot.example.co.uk._signal.ns1.example.net



Other changes are:


Clarified Operational Recommendations according to operator feedback.

Turn loose Security Considerations points into coherent text.

Do no longer suggest NSEC-walking Signaling Domains. (It does not 
work well due to the Signaling Type prefix. What's more, it's unclear 
who would do this: Parents know there delegations and can do a 
targeted scan; others are not interested.)


Editorial changes.

Added IANA request.



On other news, Cloudflare has announced production deployment of the 
protocol on all their signed domains (see slide 10 of Christian's 
slides at https://74.schedule.icann.org/meetings/WiPRZ59cBZDvj5ws2).


Thanks,
Peter



On 6/17/22 12:06, 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   : Automatic DNSSEC Bootstrapping using 
Authenticated Signals from the Zone's Operator

 Authors : Peter Thomassen
   Nils Wisiol
Filename    : draft-ietf-dnsop-dnssec-bootstrapping-01.txt
Pages   : 14
Date    : 2022-06-17

Abstract:
    This document introduces an in-band method for DNS operators to
    publish arbitrary information about the zones they are authoritative
    for, in an authenticated fashion and on a per-zone basis. The
    mechanism allows managed DNS operators to securely announce DNSSEC
    key parameters for zones under their management, including for zones
    that are not currently securely delegated.

    Whenever DS records are absent for a zone's delegation, this signal
    enables the parent's registry or registrar to cryptographically
    validate the CDS/CDNSKEY records found at the child's apex. The
    parent can then provision DS records for the delegation without
    resorting to out-of-band validation or weaker types of cross-checks
    such as "Accept after Delay" ([RFC8078]).

    This document updates [RFC8078] and replaces its Section 3 with
    Section 3.2 of this document.

    [ Ed note: This document is being collaborated on at
https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
(https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
    The authors gratefully accept pull requests. ]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-01.html 



A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-01 




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] draft-yorgos-dnsop-dry-run-dnssec-00 and DS digest field

[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

Re: [DNSOP] On removing a pargraph in RFC4035

[libor.peltan]

On the other hand, do you know any zones that permanently (other than 
active roll-over) sign with two algorithms in parallel? AFAIK this is 
_not_ the usual way how new algorithms are being rolled out. I guess new 
algorithms would continue to be adopted in the same way: first wide 
enough support in validators, second adoption (exclusive) by some 
pioneering zones who "risk" being insecure for older validators, third 
general adoption. I don't think it would be so huge an issue, but still 
a bit of an issue, as I described in the first e-mail.


Libor

Dne 21. 03. 22 v 10:32 Ben Schwartz napsal(a):
I'm concerned about this.  Concretely, this seems like it would raise 
a major barrier to rolling out new algorithms.  For example, any zone 
that offers ECDSA and RSA signatures would be insecure for any 
RSA-only resolvers.  It's hard to see how new algorithms could be 
adopted at scale if this rule were in place.


On Sun, Mar 20, 2022 at 4:42 PM libor.peltan 
 wrote:


Hi Ulrich, dnsop,
thank you for your effort in improving DNS.

This is a follow-up to your proposal on easing the requirements by
RFC4035, which say, in short, that if there's a DS of an algorithm,
there must be a complete DNSKEY set of that algorithm, and if
there is a
DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of
that
algorithm.

The counter-proposal is to only require at least one valid
DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how
this
would enable multi-signer setups with the signers supporting
different
algorithms, which in turn is beneficial to enable smooth transitions
between such signers.

Let's suppose we go this way. How do we specify the validator
behaviour
when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs,
and
the validator only understands algorithm A, but not B? I guess BOGUS
will be no longer proper here, we would probably stick at
INSECURE. Am I
correct?

Now a different scenario. There are algorithm A and B DNSKEYs, the
whole
zone is also signed by both alg A and B RRSIGs, and the validator
only
understands alg A. Some man-in-the-middle attacker intercepts the
answers by fiddling with the records, while removing algorithm A
RRSIGs
from the packets. The validator ends up with INSECURE and lets the
attacker poison some cache...

With current DNSSEC requirements, it is enough for security if
there is
any intersection between the algorithms which the zone is signed
by, and
the algorithms supported by the validator, respectively. With your
proposal, it would be required that the validator supports all the
algorithms, which the zone is signed by.

I agree that in case the zone is signed by just one algorithm
(occasionally being rolled-over to just one different one), these
conditions are equivalent. Fortunately, it did not happen yet (or I'm
not aware of), that the existence of different validators with
distinct
sets of supported algorithms forced signers to permanently sign zones
with two algorithms in parallel. The question is, if it remains so
for
the future. I can't imagine what would happen in case of a
"post-quantum
apocalypse", maybe it wouldn't be a problem, but it might.

It would also cause the paradox and indeed creepy security quirk,
that
if you sign your zone with one more algorithm, which is
cryptographically strong but poorly adopted (perhaps
experimental), it
will result in _less_ security. Hardly anyone does this, but if
they do,
they will be surprised, I think.

Just to be clear, I don't want to fight against your ideas. I'm just
pointing at possible problems that could emerge.

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

[DNSOP] On removing a pargraph in RFC4035

[libor.peltan]

Hi Ulrich, dnsop,
thank you for your effort in improving DNS.

This is a follow-up to your proposal on easing the requirements by 
RFC4035, which say, in short, that if there's a DS of an algorithm, 
there must be a complete DNSKEY set of that algorithm, and if there is a 
DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that 
algorithm.


The counter-proposal is to only require at least one valid 
DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this 
would enable multi-signer setups with the signers supporting different 
algorithms, which in turn is beneficial to enable smooth transitions 
between such signers.


Let's suppose we go this way. How do we specify the validator behaviour 
when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and 
the validator only understands algorithm A, but not B? I guess BOGUS 
will be no longer proper here, we would probably stick at INSECURE. Am I 
correct?


Now a different scenario. There are algorithm A and B DNSKEYs, the whole 
zone is also signed by both alg A and B RRSIGs, and the validator only 
understands alg A. Some man-in-the-middle attacker intercepts the 
answers by fiddling with the records, while removing algorithm A RRSIGs 
from the packets. The validator ends up with INSECURE and lets the 
attacker poison some cache...


With current DNSSEC requirements, it is enough for security if there is 
any intersection between the algorithms which the zone is signed by, and 
the algorithms supported by the validator, respectively. With your 
proposal, it would be required that the validator supports all the 
algorithms, which the zone is signed by.


I agree that in case the zone is signed by just one algorithm 
(occasionally being rolled-over to just one different one), these 
conditions are equivalent. Fortunately, it did not happen yet (or I'm 
not aware of), that the existence of different validators with distinct 
sets of supported algorithms forced signers to permanently sign zones 
with two algorithms in parallel. The question is, if it remains so for 
the future. I can't imagine what would happen in case of a "post-quantum 
apocalypse", maybe it wouldn't be a problem, but it might.


It would also cause the paradox and indeed creepy security quirk, that 
if you sign your zone with one more algorithm, which is 
cryptographically strong but poorly adopted (perhaps experimental), it 
will result in _less_ security. Hardly anyone does this, but if they do, 
they will be surprised, I think.


Just to be clear, I don't want to fight against your ideas. I'm just 
pointing at possible problems that could emerge.


Thanks,
Libor

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

Re: [DNSOP] How Slack didn't turn on DNSSEC

[libor.peltan]

Hi Philip,

Dne 01. 12. 21 v 11:46 Philip Homburg napsal(a):


qqq.slackexperts.com.   2370IN  NSEC\000.qqq.slackexperts.com. 
RRSIG NSEC

This is returned in response to a  query. The intent was that the NSEC
record should have the 'A' bit as well.

What exactly do Knot and Unbound ignore in this case?


they do not ignore the record when processing the answer.

What they don't is to store this NSEC record in their cache and use it 
for crafting other negative responses for subsequent queries without 
re-querying the authoritative server.


Libor

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

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

[libor.peltan]

Hi Paul,


for any non-root server, an RD=0 question for example.onion should be 
answered with SERVFAIL. this is a condition signal, and the condition 
is "since i'm hearing this query, someone thinks i'm holding a 
delegation, and i'm not, so i might be lame for some zone, so the 
server (me, this authority server) has failed."


from what I've observed so far, there seem to be a consensus among the 
authoritative servers out there :) They all answer out-of-bailiwick 
queries with REFUSED. I haven't met any that would say SERVFAIL or 
NOTAUTH or anything else. If you propose to normatively change this, 
with the idea that it would make more sense, then OK, but dunno if it 
has any benefit.


$ kdig @d.in-addr-servers.arpa. nonexistent-tld. +nordflag +noall +header
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 2834
;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
$ kdig @a.ns.nic.cz. nonexistent-tld. +nordflag +noall +header
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 63681
;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
$ kdig @a0.org.afilias-nst.info. nonexistent-tld. +nordflag +noall +header
;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 45946
;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

If you propose that onion. TLD (non-existing) and its subtree shall be 
an exception (for very all auth servers) and answered differently than 
other non-existent TLDs, then OK, but I simply don't like the idea.


Libor

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

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

[libor.peltan]

Hi John,
If a query for a special use name, whether it's foo.onion or 
7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is 
the right answer.


not really. First of all, in-addr.arpa. zone is normal part of DNS tree 
and various authoritative (depends for which zone) servers answer with 
proper delegations on it. Sure, 9.10.in-addr.arpa. is already an 
NXDOMAIN (according to auth servers for 10.in-addr.arpa. , but none 
others!) since 10.0.0.0/8 is a private address space.


On the other hand, onion. zone does not exist in DNS, therefore, the 
root servers (authoritative for ".") answer such queries as NXDOMAIN, 
whereas all other authoritative servers (for example, authoritative for 
zone example.com.) answer it with REFUSED, because it's out of their scope.


The requirement that all authoritative servers must answer onion. (or 
any subdomains) with NXDOMAIN does not make sense:

1) all (AFAIK) auth server implementations to date do not comply
2) would be an unnecessary exceptional behavior, possibly confusing things
3) would be probably in conflict with other DNS RFCs
4) it's not clear how such answers would be DNSSEC'ed

I suggest to remove any specific errcode (NXDOMAIN, REFUSED) mentions 
from such requirement. In the future, those errcodes and their names may 
be altered. I quite like the Peter's original proposal, though any 
wording can always be slightly improved. I don't dare to suggest any 
wording though.


Libor

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

Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

[libor.peltan]

Hi Roy,

Change 2) There was an observation by developers that some 
authoritative servers do not parse (unknown) EDNS0 options correctly, 
leading to an additional roundtrip by the resolver. It was suggested 
that authoritative servers could return the new EDNS0 option 
“unsolicited”. This is already the case for Extended DNS errors. We 
have adopted this suggestion. It was also pointed out that this kind 
of unsolicited behaviour can be surveyed. We believe that one such 
effort is underway.


Let me express my personal opinion here.

While sending unsolicited EDE seems fine for me as it's just few bytes, 
the error-reporting address might be usually roughly 100 bytes long, so 
sending it with very every response may lead to perceptible increase in 
traffic, including increase in TCP fallbacks.


This may be tolerable, if there were some better reason for it. But I 
don't like argumenting with broken implementations. Always dodging 
broken implementation only leads to more broken implementations (see DNS 
Flag Day etc). In ideal case, we should aim for the state where broken 
implementation are failing constantly.


Libor

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

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

[libor.peltan]

Hi,

I'm just not sure if this requested SHOULD->MUST change would actually 
have any consequences.


It still doesn't say anything about what authoritative, and recursive 
servers should do.


The draft's sections about authoritative server behavior are somewhat 
brief, but that may be OK.


In general, they tend to expect that the authoritative server passes 
through any SVCB/HTTPS records without too much verification. Just check 
syntax in order to be able to translate zonefile <--> wire format.


The semantic consistency seems to be expected only between the record 
author and the client, which seems to be OK.


Libor

Dne 31. 10. 21 v 2:03 Mark Andrews napsal(a):

In AliasMode, records SHOULD NOT include any SvcParams, and
recipients MUST ignore any SvcParams that are present.


Today we had the following record like this

example.com IN HTTPS 0 . alpn=h2 ipv4hint=192.0.2.1 ipv6hint=2001:DB8:

interpreting this as described leads to “0 .” which indicates
NO SERVICE OFFERED.  Rejecting this at load time would be much
safer but the weasel wording of "SHOULD NOT” makes this difficult.

Please make this MUST NOT.

Mark



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[libor.peltan]

Hi all,

although for me, as an implementer of an auth server, it's not too 
important, I'd like to ask for clarification regarding the foreseen 
reporting domain(s) setup in the (usual) case of many secondary auth 
servers.


The draft says: "Each authoritative server SHOULD be configured with a 
unique reporting agent domain."


I see two possible error situations:

1) the zone itself is wrongly signed, so all secondaries share the same 
error
2) some of the secondaries respond wrongly from correctly signed zone, 
so the error is slave-specific


IMHO the case (2) is far less common. And the case (1) doesn't require 
per-secondary reporting domain, just per-zone.


Is it really recommended (in capitals) that the zone operator prepares 
extra reporting domain for each secondary around the world (it can be 
hundreds)?


If so, it can cause a disclosure about which secondary the answer is 
comming from, dunno if some zone operators are not willing to conceal this.


Thanks!

Libor

Dne 27. 04. 21 v 16:47 internet-dra...@ietf.org napsal(a):

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 Error Reporting
 Authors : Roy Arends
   Matt Larson
Filename: draft-ietf-dnsop-dns-error-reporting-00.txt
Pages   : 12
Date: 2021-04-27

Abstract:
DNS Error Reporting is a lightweight error reporting mechanism that
provides the operator of an authoritative server with reports on DNS
resource records that fail to resolve or validate, that a Domain
Owner or DNS Hosting organization can use to improve domain hosting.
The reports are based on Extended DNS Errors [RFC8914].

When a domain name fails to resolve or validate due to a
misconfiguration or an attack, the operator of the authoritative
server may be unaware of this.  To mitigate this lack of feedback,
this document describes a method for a validating recursive resolver
to automatically signal an error to an agent specified by the
authoritative server.  DNS Error Reporting uses the DNS to report
errors.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-error-reporting-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-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] The DNSOP WG has placed draft-salgado-dnsop-rrserial in state "Call For Adoption By WG Issued"

[libor.peltan]

Hi,

just an idea: I don't know how important the amplification factor is. If 
it is, the proposed EDNS option would have the advantage of practically 
no answer:query amplification, unlike multi-query or additional SOA.


Libor

Dne 28. 05. 21 v 21:27 Peter Thomassen napsal(a):

Hi,

I like the idea of having a way to add provenance information to 
responses. However, as with all new proposals, I think what's needed 
is a careful analysis of alternative ways to achieve the same goal, 
then an assessment of what's the best approach (which may very well 
turn out to be RRSERIAL).



Some thoughts on this (some may be new, others not):




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

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

[libor.peltan]

Hi all,

just my comment:

Perhaps complexity is subjective.  The important thing is that the 
standard be reasonably implementable.  I hope that the list of 
published implementations [3] will serve as convincing evidence that 
the current draft is sufficient in that regard.


--Ben

I agree that complexity is subjective. I have no problem implementing 
complex procedures. But more complexity means more probability for bugs 
(and even security issues).


Currently, the authoritative server (while transforming presentation to 
wire format), MUST:


 - sort the SvcParams by key
 - verify their uniqueness
 - deal with list of fields nested in other fields (this includes the 
discussed comma escaping)


and the client MUST:

 - verify that SvcParams are sorted and unique
 - deal with list of fields nested in other fields (at least that 
various "lengths" match)


In the concurrent proposal, the sorting and deduplication will be "for 
free", because DNS ensures this, and each RData would consist on just 
one list of values, much easier to handle.


On the other hand, the client would have to group several RData (already 
sorted) to get all info, and believe they're all there (as Brian pointed 
out, it has to anyway). And it would cost more bandwith due to DNS 
overhead -- repeated TTLs etc (thanks Ben and Vladimir for the lesson).


Have I summarized the pros/cons of both approaches well enough?

Libor

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

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

[libor.peltan]

Hi Ben,

Dne 11. 05. 21 v 18:08 Ben Schwartz napsal(a):



On Tue, May 11, 2021 at 3:31 AM libor.peltan <mailto:libor.pel...@nic.cz>> wrote:


If there really is a strong reason for putting multiple key-value
records into one RData (instead of one RRSet), it should be
described somewhere clearly

OK, I've proposed text documenting the reasoning here: 
https://github.com/MikeBishop/dns-alt-svc/pull/323/files 
<https://github.com/MikeBishop/dns-alt-svc/pull/323/files>.


The proposed text is:

Thank you for at least this effort.


Storing a key-value map within a single RR, rather than placing each 
key-value

pair in a separate RR, provides the following advantages:

* It enables a familiar key=value zone file syntax that matches zone 
authors'
  experience with command-line arguments and other typical key-value 
mappings.

* It avoids requiring zone file authors to manage inter-pair binding IDs.
* It makes each record independently meaningful, consistent with the usual
  convention for DNS records (c.f. SRV, MX, , etc.).
* It saves at least 11 bytes of overhead per parameter by avoiding 
repetition of

  the name, type, class, TTL, and inter-pair binding ID.


May I be wrong, but I think that name, type, class and TTL are not 
repeated in one RRSet with multiple RData. Not in wire format and not 
necessarily even in zonefile. (?)


The inter-pair binding ID would be not too large, maybe it would cancel 
out with some avoided textual dash :)


* It provides a wire format whose structural nesting matches the 
logical scope

  of each key=value pair, and avoids requiring cross-RR reconstruction of
  bindings by the client.

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

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

[libor.peltan]

Hi all,

this is actually not the first time someone has come with this issue: 
https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1=WxZLxeJF3vSHiOG0jGm8kek5ajI


If there really is a strong reason for putting multiple key-value 
records into one RData (instead of one RRSet), it should be described 
somewhere clearly (more clearly than Ben's two pretty relativisable 
sentences). If so, I would accept it happily.


Brian, thanks for nice elaborate on the "counter-proposal". What exactly 
is illogical on that, in the end?


FYI in Knot DNS authoritative, we were able to implement 
zonefile<->wireformat transitions according current draft (being a Merge 
request to date). I feel no need to change the escaping manner.


Libor

Dne 11. 05. 21 v 1:59 Brian Dickson napsal(a):



On Mon, May 10, 2021 at 9:58 AM Ben Schwartz 
> wrote:


I don't support breaking the SvcParams into separate RRs across
the RRSet.  This would be an extremely inefficient encoding in
wire format, and would conflict with the usual understanding of
resource records as independently meaningful alternatives.

[snip]

To see why I favor two-pass, consider a SvcParam whose wire format
value is defined to be CBOR, represented as JSON in the zone
file.  JSON is defined as UTF-16, and allows strings containing
any character from the Basic Multilingual Plane.  It also allows
various kinds of backslash escaping including " \" " for quotes
within strings, and "\uD834\uDD1E" for extended unicode
codepoints.  A one-pass parser must somehow integrate this into
the flow of zone file parsing.  The easiest way is to simply
disable all RFC1035-style escapes and line-breaks for the duration
of the SvcParamValue, but this is a major breach of standard zone
file practice, and raises questions about how to store UTF-16
characters in a zone file. Alternatively, we could somehow combine
both RFC1035 and JSON escaping, but if this is even possible, it
would seem to require writing a new RFC1035+JSON hybrid parser.  I
also think these behaviors would be confusing to users, who would
have to try to understand how this new integrated escaping works
in order to author zone files containing either kind of escape.


[snip]

Let me ask what is probably a really leading question, in terms of the 
semantics for SVCB (and HTTPS).
If I understand the draft in its current form, the goal is to be able 
to encode and parse some DNS RRset in such a way as it lets you 
obtain, in one fell swoop (but possibly multiple passes for parsing) 
everything needed to obtain:
- A well-ordered list of one or more targets, where each target has a 
set of attributes.
- The examples currently show RRsets with multiple distinct Priority 
values
- However, the words indicate that it is permissible for two RRs in 
the set to have the same Priority value.
- The effect is having an array of objects, each of which has a 
priority, name, and optional set of key/value pairs (where values can 
be lists).


So, I have a proposed solution that will make the parsing, and 
generation of post-parsing JSON objects as close to trivial as possible.
This borrows heavily from what Joe Abley already wrote. I'm just 
taking the concept to its (il)logical conclusion.


Encode everything using the following mechanism:
Priority Enumeration Key Value
One of the "Keys" would be Target, with a corresponding Value of FQDN.
All of the records with the same value for "enumeration" belong 
together, and form a single SvcParameter list.
For the AliasForm, both the Priority and Enumeration would be 0, and 
only a single Target,Value pair are permitted.


To take one example from the draft, and re-encode it thusly:
$ORIGIN svc.example. ; A hosting provider.
pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."
              HTTPS 2 .      alpn=h2 ech="abc..."
pool   300 IN A        192.0.2.2
                   2001:db8::2
h3pool 300 IN A        192.0.2.3
                   2001:db8::3

This would become (for brevity, encoding just a list of RDATA values 
for all of the "pool HTTPS" records):

1 1 target "h3pool"
1 1 alpn "h2,h3"
1 1 ech "123..."
2 2 target "."
2 2 alpn "h2"
2 2 ech "abc..."


I think this is likely a lot easier to parse, and to convert into 
whatever form your ALPN-handling stuff wants (including JSON).
I is also very close to trivial to write a JSON -> Zone File 
transliterator, so user input in JSON (which meets the JSON structure 
expected) can be handled, and even bidirectionally allow Zone File -> 
JSON for user editing of already-existent entries.


For the example above;
If the priority of both of the above were the same, they would be all 
"1 1 ..." and "1 2 ..." instead of "1 1 ..." and "2 2 ...".

If my JSON isn't horribly bad, I think this would get converted into:
 [ { "name" : "h3pool", "priority" : 1, "SvcParams" : { "alpn" : 
"h2,h3", "ech" : "123..." } }, ...]

Re: [DNSOP] NXDOMAIN and RFC 8020

[libor.peltan]

Hi Murray,

if foo.example does not exist and DNSSEC is in place, than the resolver 
actually, even with the queries "in reverse order", obtains and NSEC(3), 
proving non-existence for much more.


For example, the query is bar.foo.example, and the authoritative returns 
an NSEC proving that there is nothing between fa.example and fz.example. 
Thus, the resolver can later deduct nonexistence not only for 
foo.example, but also for fun.example and bar.fun.example, etc...


Without DNSSEC, this deduction (called "aggresive NSEC caching") is not 
possible.


Cheers,

Libor

Dne 06. 04. 21 v 20:11 Murray S. Kucherawy napsal(a):
I'm wondering something about tree walks, which John Levine asked 
about in November, as it's a topic of interest to the evolution of DMARC.


I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" 
also covers later queries for "bar.foo.example".  Makes sense.


Can this be used (or maybe amended) to cover the queries if they come 
in the reverse order?  For instance, if "bar.foo.example" arrives 
first, but the authoritative server can determine that the entire 
"foo.example" tree doesn't exist, could it reply with an NXDOMAIN for 
the question plus a cacheable indication about the entire tree instead 
of just the name that was in the question?


This would make an ascending tree walk even for something crazy like 
"a.b.c.d.y.z.foo.example" extremely cheap as the cached NXDOMAIN 
for "foo.example" covers the entire subtree, for a caching nameserver 
implementing RFC 8020.


Maybe this is discussed somewhere that I missed in the references.  
I'm happy to take a "go read this for the answer" if that's the case.


Thanks,

-MSK

___
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

[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 parameter specification via the 
DNS (DNS SVCB and HTTPS RRs)
 Authors : Ben Schwartz
   Mike Bishop
   Erik Nygren
 Filename: draft-ietf-dnsop-svcb-https-04.txt
 Pages   : 48
 Date: 2021-03-17

Abstract:
This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTPS origins.  SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration and keys for encrypting the TLS ClientHello).
They also enable aliasing of apex domains, which is not possible with
CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins.  By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.

TO BE REMOVED: This document is being collaborated on in Github at:
https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
working version of the document, open issues, etc. should all be
available there.  The authors (gratefully) accept pull requests.

Re: [DNSOP] [Ext] DNSSEC Strict Mode

[libor.peltan]

Hi Ben,

Dne 25. 02. 21 v 1:50 Ben Schwartz napsal(a):



On Wed, Feb 24, 2021 at 6:57 PM Brian Dickson 
mailto:brian.peter.dick...@gmail.com>> 
wrote:



That's not possible. The DS records are on the parent side (TLD)
and the TTL is set by the TLD per whatever their standard policy
is. Same for RRSIGs over those DS records.


That's fine.  I meant the TTLs of the ZSKs and zone contents.  
Switching from provider A to provider B, the sequence would be

1. Set all TTLs in the zone to zero
2. Wait
3. Copy zone to provider B
4. Add DS for B's keys to the parent


This wouldn't work as well. The resolver would see two DSs with 
different algorithms at the parent zone, but only one (pair of) DNSKEYs 
with single algorithm, whichever provider of your zone it'll query.


This would violate RFC 4035: "The apex DNSKEY RRset itself MUST be 
signed by each algorithm appearing in the DS RRset located at the 
delegating parent (if any)."



5. Wait
6. Add B's NS to the parent
7. Remove A's NS from the parent
8. Wait
9. Remove DS for A's keys from the parent
10. Set zone TTLs to > 0


IMHO, performing an algorithm rollover while switching DNSSEC providers 
is indeed difficult, if possible at all. Even the lax validation doesn't 
help much.


However, performing an algorithm rollover normally isn't that hard using 
proper tooling, so I don't think we should continue to justify lax 
validation only in order to encourage signers to switch from using 
obsolete algorithms.


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] [Ext] DNSSEC Strict Mode

[libor.peltan]

Hi Ulrich,

please see below..

Libor

Dne 24. 02. 21 v 16:01 Ulrich Wisser napsal(a):


On 23 Feb 2021, at 17:49, Ben Schwartz 
> wrote:




On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler > wrote:

...

Recognizing that I'm likely biased by my history of working on the
current "mandatory algorithm rules", I don't buy the need for this
complexity.  In practice our "weak" algorithms aren't _that_ weak.
And, if they are, we might as well stop signing with them entirely.


I think that was true for a long time, but I'm not sure it's still 
true, or will stay true.  I'm particularly motivated by the ongoing 
discussion about adding Algorithms to the registry [1], and a recent 
overview of Post-Quantum cryptography for DNSSEC [2].  Also, 829-bit 
RSA was factored last year [3].  Validator update timelines are Very 
Slow, so we should be thinking about adding features we might need 
before we need them.


Even if we are currently in a state where zone owners feel like they 
have simple, safe choices, I don't think we should assume that this 
will remain true indefinitely.


This seems like unnecessary further loading of the camel.


FWIW, my preference would be to simply remove the lax-validation rule 
from RFC 6840, which would simplify the standard overall ... but 
there must have been a good reason for it.  Strict Mode might be a 
stepping-stone in that direction.


Not only am I in favor of the RFC6840 lax validation, it is in fact 
necessary for secure DNSSEC operation.
I think lax validation is not necessary for secure DNSSEC operation. 
DNSSEC can be operated securely in the strict mode completely, including 
algorithm roll-overs.
In fact I believe the RFC 4035 needs to be updated to explicitly allow 
algorithms without signatures.


I believe the lax validation needs to be denied completely in order to 
not support RFC4035 (and 6840) non-compliant signers.


At the current state of dnssec RFC definitions it is unclear how you 
could change DNS operators securely if these operators do not sign the 
zone with the same algorithm.

IMHO it's pretty clear: it's simply not possible at all.




Ben, if you decide to persist with this idea, I've filed some issues
in your GH repo.


Thanks!

[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00 

[2] https://indico.dns-oarc.net/event/37/contributions/811/ 

[3] https://en.wikipedia.org/wiki/RSA_numbers#RSA-250 


___
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] DNSSEC Strict Mode

[libor.peltan]

Hi Ben,

Yes, RFC 6840 tells validators to be lax.

However, it also requires exactly the same as RFC 4035 from signers.

As I understand it, the requirement is rephrased, but entirely 
equivalent, and there is a MUST.


So, is your proposal only about a bit in DNSKEY record, signalling "this 
zone is RFC compliant"?


If so, I have no more questions, but you should maybe state this clearly ;)

Cheers,

Libor

Dne 23. 02. 21 v 16:26 Ben Schwartz napsal(a):

Libor,

That's what I thought too.  See RFC 6840 Section 5.11:

> The last paragraph of Section 2.2 of [RFC4035] includes rules
> describing which algorithms must be used to sign a zone.  Since these
> rules have been confusing, they are restated using different language
> here:
...
>> A signed zone MUST include a DNSKEY for each algorithm present in
>> the zone's DS RRset and expected trust anchors for the zone.  The
>> zone MUST also be signed with each algorithm (though not each key)
>> present in the DNSKEY RRset.
...
> This requirement applies to servers, not validators. Validators
> SHOULD accept any single valid path.

RFC 6840 tells validators to be lax, so if we want to enforce this 
rule then we need a signal (or we need to update RFC 6840).


On Tue, Feb 23, 2021 at 10:17 AM libor.peltan <mailto:libor.pel...@nic.cz>> wrote:


Hi Ben,

could you please briefly summarize how this relates to last
paragraph of https://tools.ietf.org/html/rfc4035#section-2.2
<https://tools.ietf.org/html/rfc4035#section-2.2> ?

The way how I understand it, each DNSKEY already must be treated
as the proposed "strict" mode, thus this proposal is completely
useless.

Thanks,

Libor

Dne 23. 02. 21 v 16:08 Ben Schwartz napsal(a):

Inspired by some recent discussions here (and at DNS-OARC), and
hastened by the draft cut-off, I present for your consideration
"DNSSEC Strict Mode":

https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00

<https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00>


Abstract:
Currently, the DNSSEC security of a zone is limited by the
strength of its weakest signature algorithm. DNSSEC Strict Mode
makes zones as secure as their strongest algorithm instead.

The draft has a long discussion about why and how, but the core
normative text is just three sentences:

The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags
field.  If this flag is set, all records in the zone MUST be
signed correctly under this key's specified Algorithm.  A
validator that receives a Strict Mode DNSKEY with a supported
Algorithm SHOULD reject as Bogus any RRSet that lacks a valid
RRSIG with this Algorithm.

--Ben Schwartz

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


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

Re: [DNSOP] DNSSEC Strict Mode

[libor.peltan]

Hi Ben,

could you please briefly summarize how this relates to last paragraph of 
https://tools.ietf.org/html/rfc4035#section-2.2 ?


The way how I understand it, each DNSKEY already must be treated as the 
proposed "strict" mode, thus this proposal is completely useless.


Thanks,

Libor

Dne 23. 02. 21 v 16:08 Ben Schwartz napsal(a):
Inspired by some recent discussions here (and at DNS-OARC), and 
hastened by the draft cut-off, I present for your consideration 
"DNSSEC Strict Mode": 
https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00 
 



Abstract:
Currently, the DNSSEC security of a zone is limited by the strength of 
its weakest signature algorithm.  DNSSEC Strict Mode makes zones as 
secure as their strongest algorithm instead.


The draft has a long discussion about why and how, but the core 
normative text is just three sentences:


The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags 
field.  If this flag is set, all records in the zone MUST be 
signed correctly under this key's specified Algorithm.  A validator 
that receives a Strict Mode DNSKEY with a supported Algorithm 
SHOULD reject as Bogus any RRSet that lacks a valid RRSIG with 
this Algorithm.


--Ben Schwartz

___
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-02.txt

[libor.peltan]

Hi Ben, all,
i'd like to ask for some clarification of expected Authoritative server 
behaviour around Alias SVCB records:


1) when there are multiple Alias SVCB records for an owner name, should 
the Authoritative server put targeted records into Additionals for all 
of them, or just pick one?
(Section 4.1 says "authoritative DNS servers SHOULD return A, , and 
SVCB records in the Additional Section for any in-bailiwick 
TargetNames", but section 2.4.2 will render it useless with "If multiple 
are present, clients or recursive resolvers SHOULD pick one at random." 
Which means, half (or most) of the additionals will get thrown away.)


2) When the TargetName points to an in-bailiwick CNAME, should the 
autoritative server populate the CNAME chain inside the Additional 
section? It seems to me (fortunately :) ), that following such CNAME is 
only required for Recursive resolvers, however e.g. this zone will thus 
need three upstream queries to fetch it all:

foo 3600 IN SVCB 0 bar
bar 3600 IN CNAME baz
baz 3600 IN SVCB 0 . alpn=...
baz 3600 IN  1::2

Thanks for your answers,
Libor

PS: is this e-mail thread the right place to ask for details 
clarification around SVCB features?


Dne 16. 11. 20 v 7:43 Ben Schwartz napsal(a):

For those who haven't looked at the diff, here are the changes since -01
      *  Added a Privacy Considerations section
      *  Adjusted resolution fallback description
      *  Clarified status of SvcParams in AliasMode
      *  Improved advice on zone structuring and use with Alt-Svc
      *  Improved examples, including a new Multi-CDN example
      *  Reorganized text on value-list parsing and SvcPriority
      *  Improved phrasing and other editorial improvements throughout

Notably, the normative changes are extremely limited compared to the 
previous draft.  This reflects the authors' view that this draft is 
stabilizing and should be ready for WGLC soon.


Perhaps more important than the changes that were made are the changes 
that were discussed but have not been made:
* We had an extensive discussion regarding the meaning of TargetName = 
".", which is currently shorthand for the owner name.  Some suggested 
augmenting this to mean "owner name minus underscore prefix labels", 
and others suggested removing this special-case entirely.  
(https://github.com/MikeBishop/dns-alt-svc/issues/252 
)
* We received a suggestion to ban fallback to non-SVCB connection 
establishment (https://github.com/MikeBishop/dns-alt-svc/issues/256 
). (We clarified 
the fallback text but did not change the recommendation.)
* The escaping of ALPNs that contain commas continues to be 
contentious.  We received a suggestion to remove support for such 
ALPNs (https://github.com/MikeBishop/dns-alt-svc/issues/268 
).


In each case, we think that the draft's current text still reflects 
the group's consensus and strikes the right balance. If you disagree, 
please open a thread on the dnsop list and we will discuss it.


We have one open issue that seems likely to result in a text change 
(https://github.com/MikeBishop/dns-alt-svc/issues/87 
). This is a fine 
point regarding the HTTPS user experience if TLS fails, and we are 
soliciting input from experts on those topics.


On Mon, Nov 2, 2020 at 4:44 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 parameter
specification via the DNS (DNS SVCB and HTTPS RRs)
        Authors         : Ben Schwartz
                          Mike Bishop
                          Erik Nygren
        Filename        : draft-ietf-dnsop-svcb-https-02.txt
        Pages           : 45
        Date            : 2020-11-02

Abstract:
   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS
ClientHello).
   They also enable aliasing of apex domains, which is not
possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at:

[DNSOP] Additional EDE codes for resource limits

[libor.peltan]

Hi all,

I just suggest a discussion about some more error codes for EDNS 
Extended Errcode (EDE).


In some cases, a server (authoritative or recursive) is not able/willing 
to answer the query, because:

1) it lacks resources
2) rate-limiting was applied

Do you think it would be useful to have one or two additional EDE 
errcodes for those?


Thanks,

Libor

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

Re: [DNSOP] zone contents digest and DNSSEC stuff

[libor.peltan]

Hi Joe,

Dne 29.09.20 v 15:03 Joe Abley napsal(a):

The other use case I seem to think you're implying is that a consumer of the 
signed zone could verify that it was intact using the signed-zone ZONEMD, then 
strip the DNSSEC RRs and retain the ability to verify that the result was an 
accurate representation of the unsigned zone using the unsigned-zone ZONEMD. 
This seems like a slightly odd thing to want to do, but perhaps I'm just not 
thinking hard enough?


Joe


yes, something like this.

My initial thought was that the signer, which converts the un-signed 
zone by adding signatures and keys, might not be able to compute/update 
the ZONEMD record.


It might also be useful, when the zone is only re-signed and otherwise 
unchanged, if the zone checksum was unchanged.


I'm not sure. This is just a thing to be thought of.

I would love if there was a bit flag indicating if the checksum has been 
computed including DNSSEC records, or without them. This would let the 
freedom of choice on the users, while adding some complexity to software 
implementation.


Thanks for consideration,

Libor

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

[DNSOP] zone contents digest and DNSSEC stuff

[libor.peltan]

Hi,

I don't fully know the background of this topic, so my question might be 
dumb.


Often the zone operators work with both un-signed and signed "versions" 
of their zone. The un-signed version usually comes from a registry 
system or a database, whereas a "signer" server adds "the DNSSEC stuff", 
like DNSKEYs, RRSIGs, NSECs, etc. It's also usually possible to do the 
reverse: strip DNSSEC-related records from signed zone, if needed.


I feel like it would be equally useful to maintain a digest of the 
un-signed and signed version of the zone, respectively.


Does the calculation of ZONEMD include the DNSSEC-related records? Have 
you maybe thought about including two such records, for both cases?


Thanks for comments,

Libor

Dne 25.09.20 v 22:09 internet-dra...@ietf.org napsal(a):

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   : Message Digest for DNS Zones
 Authors : Duane Wessels
   Piet Barber
   Matt Weinberg
   Warren Kumari
   Wes Hardaker
Filename: draft-ietf-dnsop-dns-zone-digest-11.txt
Pages   : 36
Date: 2020-09-25

Abstract:
This document describes a protocol and new DNS Resource Record that
provides a cryptographic message digest over DNS zone data.  The
ZONEMD Resource Record conveys the digest data in the zone itself.
When a zone publisher includes a ZONEMD record, recipients can verify
the zone contents for accuracy and completeness.  This provides
assurance that received zone data matches published data, regardless
of how the zone data has been transmitted and received.

ZONEMD does not replace DNSSEC.  Whereas DNSSEC protects individual
RRSets (DNS data with fine granularity), ZONEMD protects a zone's
data as a whole, whether consumed by authoritative name servers,
recursive name servers, or any other applications.

As specified herein, ZONEMD is impractical for large, dynamic zones
due to the time and resources required for digest calculation.
However, The ZONEMD record is extensible so that new digest schemes
may be added in the future to support large, dynamic zones.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-11
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-11


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] Authoritative servers announcing capabilities

[libor.peltan]

Let me leave some personal opnion/comments on this AUTHINFO idea, 
although I don't know the background here.


There are multiple kinds of "capabilities" of an authoritative server.

Some of them are properties of the zone, some are properties of the DNS 
server implementation, some are properties of the operational policy. 
For examples: DNS algorithm, EDNS version, network MTU, respectively.


While it seems reasonable to disclose some properties of the zone by an 
extra zone RR (although it would probably require extra query!), the 
properties of DNS server will often vary since implementation diversity 
is a general recommendation.


I don't know the foreseeable use-cases for this or similar kinds of 
properties signalization. The listed examples are already signalized 
another way (EDNS buf size), or useless (DNSSEC presence and DNSKEY 
algorithm).


By the way, the operators tend to hide properties of their server 
implementations, rather than disclose it. See version.server. CH TXT ...


BR,

Libor

PS: i'm very sorry for the previous e-mails. My client got somehow mad 
and sent the e-mail while I was typing it!


Dne 12.09.20 v 03:40 Paul Vixie napsal(a):

On Fri, Sep 11, 2020 at 09:04:02PM -0400, Paul Wouters wrote:

On Sep 11, 2020, at 20:48, Paul Vixie  wrote:

???On Sat, Sep 12, 2020 at 09:40:11AM +1000, Mark Andrews wrote:

and why is it a RR type at all.  An EDNS option or a opcode is better
suited for this sort of thing.

+1.

An RR type can be signed and distributed differently and allow for
preloading of (distributed) caches which enhanced the decentralization of
recursive DNS servers.

an authority server's capabilities are with respect to a zone. for example,
dnssec availability, dnssec details like algs, maximum message sizes,
truncation policy, willingness to do persistent TCP (or QUIC) sessions.

our community seems hell bent on gradually evolving the system toward the
needs that micro-leasing would address, without actually understanding that
or getting there. _it's never about the server_.



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

Re: [DNSOP] Question regarding RFC 8499

[libor.peltan]

Hi,

just a factual comment.

While primary/secondary = master/slave is indeed a recent transition of 
terms among DNS community, and I agree that this should be handled 
carefully when writing new RFCs,


parent/child is a different relation: `com.` domain is the parent of 
`example.com.`.


I haven't heard about "main".

BR,

Libor

Dne 22.07.20 v 01:00 Michael De Roover napsal(a):

Hello,

I've read through RFC 8499, and found some things I considered odd. 
Particularly page 14 and 19 which describe the "master files" and the 
"primary" and "secondary" servers.


In most of the DNS-related documentation I've read so far, the "master 
files" are often called zone files. I find it strange that in the RFC 
this is only acknowledged, rather than defined into its own term and 
prioritized.


Regarding the primary and secondary servers, it's a fair euphemism but 
this among further fracturing of nomenclature in other projects makes 
this definition very fragmented (master/slave is now 
primary/secondary, main, parent/child, etc). This is something I find 
unnecessary and harmful, as it creates confusion while merely 
redefining the same. It also unnecessarily obsoletes older 
documentation. Newcomers to the DNS could become confused. I was very 
confused when I recently built my own DNS server infrastructure.


The discussion regarding these tends to get emotional and political, 
but I feel like these should be kept outside of standards bodies. Just 
like we are still stuck with 29.97 Hz refresh rates on televisions 
from implementations half a century ago, these changes could also 
affect those half a century from now on.




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

[DNSOP] Comments on draft-ietf-dnsop-svcb-https

[libor.peltan]

Hi all,

i'm a developer of Knot DNS authoritative server. I have some comments 
on the SVCB draft and some suggestions for improvements. Just consider 
my thoughts and then do whatever is best.


(1) The format of SVCB (and HTTPS) RR is too complicated, especially for 
parsing presentation format to wireformat and back, including 
consistency checks. Perhaps instead of


www 3600 IN HTTPS 1 . alpn=h2 port=8443

It could be

www 3600 IN HTTPS 1 . alpn h2
  1 . port 8443

Which gives slightly bigger RRSet wireformat, but not by much.

(2) Paragraph 2.2 explicitly requires that SvcDomainName must not be 
compressed. Is there a reason? Especially when the response packets are 
large (and I expect that for SVCB they will), any compression helps.


(3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name of 
a domain that has SVCB, , or A records" versus "SvcDomainName MAY be 
the owner of a CNAME record". What is the meaning here?


(4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 
4.1 is too vague and I don't see what an authoritative (not recursive!) 
server shall answer in situation SVCB->CNAME->A (all in-bailiwick). 
Shall the CNAME and A be added to additional section? For comparison, in 
situation MX->CNAME->A we don't bother since this situation is forbidden 
(see RFC 2181).


(5) Wouldn't one octet for priority field be enough?

(6) There are not enough examples in the document. There are many 
variants of SVCB records, the formal ABNF description is difficult to 
read, and it would also illustrate what kind of services those records 
are designed to handle.


Best regards and thanks for your effort,

Libor Peltan
CZ.NIC

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