Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

[Mark Andrews]

> On 6 Jul 2023, at 12:32, Ted Lemon  wrote:
> 
> It’s not a problem to validate before translating if you’re a full service 
> resolver. 

Ted you are missing the point.  It is impossible to *reliably* run a validating 
client
behind a DNS64 server.  DNS64 uses CD in a manner that is *incompatible* with 
DNSSEC.
Sure as long as the DNS64 server *always* gets good answers you can “get away 
with it”
but once you don’t things break.

In DNSSEC
CD=1 is for when the recursive validating resolver has bad time / trust anchors
CD=0 is ensures the cache returns answers that can validate as secure (the 
server is
supposed to try multiple sources as it is required to “treat as never having 
arrived”
responses that don’t validate)

“Always send CD=1” is stupid advice.  I tried to prevent it being published in 
the
first place.

If the DNS64 server happens to lock onto a bad source of data or is losing the 
race
with spoofed responses the client will never get anything that validates as 
secure as:
CD=1 the bad data is passed through or returned from the cache.
CD=0 the DNS64 server produces responses that don’t validate.

Anything that further promotes the use of a BROKEN protocol should not be 
published.

Mark

> Op wo 5 jul 2023 om 21:10 schreef Mark Andrews 
> I’ll repeat that it is a bad idea to make this an RFC.  I’m saying this 
> despite adding
> this to named. 
> 
> It is perpetuating DNS64 which does not work with DNSSEC.  It sends the wrong 
> signal
> that DNS64 is a good protocol to deploy when we know that it breaks lots of 
> things.
> 
> The better solution would be to improve the automatic installation of 464XLAT 
> (RFC6877)
> support in nodes.  There is already a RA PREF64 option (RFC8781) to signal 
> that NAT64 is
> available on the network and that works for all applications on the node, not 
> just the
> nameserver.
> 
> Similarly for DS-Lite.
> 
> Linux has https://github.com/toreanderson/clatd
> FreeBSD has 464XLAT support built in since FreeBSD 11.3
> 
> While CLAT is not everywhere there yet it is definitely on the way.
> https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networks/
> 
> I really don’t know why we are just not saying if you want to run a DNS64 
> server behind
> a IPv6 only link install CLAT support if it is not already available.
> 
> 
> > On 6 Jul 2023, at 01:12, Tim Wicinski  wrote:
> > 
> > Momoka
> > 
> > Thanks for making DNSOP aware of this.  We encourage anyone with comments 
> > on the document adoption to reach out.
> > 
> > Everything I've heard and read on this work (wearing no hats) is that this 
> > is good work and should be adopted.
> > 
> > thanks
> > tim
> > 
> > 
> > 
> > On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto  wrote:
> > Dear dnsop wg 
> > cc:v6ops wg
> > 
> > My name is Momoka, the author of the draft-momoka-v6ops-ipv6-only-resolver. 
> > This draft, which has already been introduced to the V6OPS Working Group, 
> > aims to address a pertinent operational issue: facilitating the transport 
> > of query packets from an IPv6-only iterative resolver to an IPv4-only 
> > authoritative DNS server.
> > 
> > In light of some suggestions in V6OPS and considering the overlapping 
> > interests, I am introducing this draft to the DNSOP Working Group. Its core 
> > proposition lies in the mechanics of transporting query packets rather than 
> > the alteration of the DNS protocol behavior, but the operational context 
> > undoubtedly makes this draft relevant to both groups.
> > 
> > Here are links to the draft and the ongoing discussions in V6OPS:
> > 
> > 1. Draft: 
> > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
> > 2. V6OPS Thread: 
> > https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ85OY/
> > 
> > 
> > Currently, there is an adoption call in V6OPS for this draft set to end on 
> > July 10, 2023. Your opinion, input, and suggestions will be highly valued 
> > as we explore and progress this topic. I look forward to fruitful and 
> > enlightening discussions.
> > 
> > Best regards,
> > 
> > Momoka Yamamoto
> > momoka@gmail.com
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> > ___
> > v6ops mailing list
> > v6...@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-domain-verification-techniques-01

[Shumon Huque]

On Thu, Apr 20, 2023 at 11:46 AM Paul Wouters  wrote:

>
> > ### CNAME chaining
> >
> > In §3.2 we see the text "Another issue with CNAME records is that they
> must
> > not point to another CNAME" provided, with no reference.  But CNAME
> chains are
> > in heavy use on the internet in practice with no ill effect (case in
> point: my
> > employer's CDN business), so I'd recommend removing the discussion of
> CNAME
> > chaining, or supplying a reference and discussion around them that is
> closer
> > to the deployment reality.
>

Yes, my employer too! :)


> Looking up the exact reference, I do find in
> https://www.rfc-editor.org/rfc/rfc1034.html#section-3.6.2
>
> CNAME chains should be followed
>
> So perhaps our advise here was a bit too strong. We already had an open
> item at looking to change the language there to make it less restrictive
> on CNAMEs so we will take item this into that discussion.


Thanks Paul (and Ben ..),

We've now addressed this in the current github draft by just removing the
discussion on CNAME chains, as I don't think it is crucial to the potential
pitfalls with CNAMEs used for domain control validation.

We've also relaxed the recommendation against using CNAME based methods.
The original rationale for that was because they can't coexist with any
other records at the same name. However, there are many providers that do
CNAME based validation by placing the validation record at a random
subdomain of the name being validated, rather than at the actual name
itself, which avoids the collision problem entirely. See an example in the
appendix for Amazon ACM, although quite a number of others can be cited
(Docusign, Sectigo, etc). We also account for the delegated validation
model which employs a CNAME pointing to a TXT record hosted at a 3rd party.

We still recommend the TXT based method, as it uses an application specific
underscore prefix label (which both avoids collisions with CNAMEs and makes
it easier to identify the service associated with the validation record).

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

Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-verification-techniques-01

[Shumon Huque]

On Thu, Mar 30, 2023 at 4:52 PM Erik Nygren  wrote:

> Hello,
>
> Thank you for pulling together this draft!  Having worked on related
> systems a number of times it will be valuable to have something here
> standardized.
>

Thanks for the review Erik, sorry for our very late response, and thanks to
Tim for prodding us. IETF is around the corner, and it's time to unbury
myself from the day job!

First, I wanted to let the working group know that we've renamed the title
(and topic) of the draft to: "Domain Control Validation using DNS", DCV
being the widely used and more commonly known industry term for this. (In
the github repo, we'll push out the latest version before the draft cutoff).



> A number of comments and suggestions:
>
> 1) APEX domains, and hostnames vs domains
>
> You define APEX but don't then reference this.  This is an important topic
> to cover in considerably more detail, however.  In particular, some systems
> want to validate an apex domain while others want to validate each
> particular hostname.  It is critical that validation record and its
> contents are unambiguous as to which of these is the case.
>
> As an example, ACME has separate mechanisms for wildcard certs (eg, "*.
> example.com") vs individual names (eg, "bar.example.com").
> This is likely to apply across the board to these systems: sometimes they
> want to validate usage for a domain and sometimes for just specific names.
>
> For the individual hostname case, it is important to clarify that the
> challenge should be "_foo-challenge.bar.example.com".
>
> For the whole domain case this could be  "_
> foo-wildcard-challenge.example.com"  or have an attribute in the TXT
> token (eg, wildcard=true).ACME (rfc8555 section-8.4) doesn't seem to
> have this differentiation, which seems unfortunate, unless I'm misreading.
> I'd think that it should be unambiguous to domain admins whether a
> challenge is for just the "example.com" name, for "*.example.com", or for
> "example.com, *.example.com, *.*.example,com, etc".
>

Yes, indeed. The authors discussed 'scope of validation' during the initial
drafting of this document and the inclusion of apex in the definitions
section was likely related to that, but the topic apparently was forgotten
along the way somewhere.

I agree that this distinction is very important, and I have to deal with it
in my day job. We frequently need to seek clarification from the requester
of a DNS validation record about whether it applies to a single domain name
or the entire domain rooted at the name, before deciding whether the
request should be granted.

Certificate issuance could benefit from the addition of a wildcard naming
convention or attribute as you suggest. If we propose that, I think it
would be best to get alignment from the ACME folks first.

The more general case of an application service (like Atlassian, Docusign,
Google Workspace, etc) being authorized to provide a service on behalf of a
domain owner is harder to judge without reviewing more details of the
service. But in my experience it is almost alway for the entire domain
rooted at the name.

What it means to validate a hostname or a domain or a wildcard set of
> hostnames may vary widely per application, and we may want to talk more
> about the security considerations here.
>
> Ambiguities about whether a given verification token grants powers over a
> specific hostname or an entire domain also introduce security challenges
> that we may wish to talk about in Security Considerations.  DNS domain
> administrators need to be able to understand the consequences of adding in
> particular challenge entries into their domain, especially in cases like a
> multi-tenant Enterprise environment.
>

Yes, agreed.


> 2) Public suffixes
>
> We may wish to encourage (or require) validating against Public Suffix
> lists (eg, https://publicsuffix.org/), in the absence of a more general
> DBOUND solution.  At a minimum we should discuss this in security
> considerations.
>
> One Security Consideration is that services operating a public suffix
> should take extreme care about when they allow underscore labels to be
> created within a shared domain.  As an example, if a service provider
> allows "_foo-challenge.publicsuffix.example" to be registered as a domain
> (for a DNS registrar) or to be created as a CNAME or TXT record (eg, for a
> dynamic DNS provider or cloud provider) then this might grant unintended
> powers over all of "publicsuffix.example".
>
> We may also want to (encourage? require?) confirming that a user isn't
> trying to place a validation token on a public suffix.  ACME has this as a
> "CA Policy Consideration" (Section 10.5 of rfc8555).  There are some
> legitimate use-cases here, but caution (and perhaps extra validation?) is
> needed.
>
> (For the Appendix, another example would be the PSL itself.  Per
> https://github.com/publicsuffix/list/wiki/Guidelines
> It uses "_psl.alphaexample.com TXT
> https://github.com/publicsuffix

Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

[Mark Andrews]

I’ll repeat that it is a bad idea to make this an RFC.  I’m saying this despite 
adding
this to named. 

It is perpetuating DNS64 which does not work with DNSSEC.  It sends the wrong 
signal
that DNS64 is a good protocol to deploy when we know that it breaks lots of 
things.

The better solution would be to improve the automatic installation of 464XLAT 
(RFC6877)
support in nodes.  There is already a RA PREF64 option (RFC8781) to signal that 
NAT64 is
available on the network and that works for all applications on the node, not 
just the
nameserver.

Similarly for DS-Lite.

Linux has https://github.com/toreanderson/clatd
FreeBSD has 464XLAT support built in since FreeBSD 11.3

While CLAT is not everywhere there yet it is definitely on the way.
https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networks/

I really don’t know why we are just not saying if you want to run a DNS64 
server behind
a IPv6 only link install CLAT support if it is not already available.


> On 6 Jul 2023, at 01:12, Tim Wicinski  wrote:
> 
> Momoka
> 
> Thanks for making DNSOP aware of this.  We encourage anyone with comments on 
> the document adoption to reach out.
> 
> Everything I've heard and read on this work (wearing no hats) is that this is 
> good work and should be adopted.
> 
> thanks
> tim
> 
> 
> 
> On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto  wrote:
> Dear dnsop wg 
> cc:v6ops wg
> 
> My name is Momoka, the author of the draft-momoka-v6ops-ipv6-only-resolver. 
> This draft, which has already been introduced to the V6OPS Working Group, 
> aims to address a pertinent operational issue: facilitating the transport of 
> query packets from an IPv6-only iterative resolver to an IPv4-only 
> authoritative DNS server.
> 
> In light of some suggestions in V6OPS and considering the overlapping 
> interests, I am introducing this draft to the DNSOP Working Group. Its core 
> proposition lies in the mechanics of transporting query packets rather than 
> the alteration of the DNS protocol behavior, but the operational context 
> undoubtedly makes this draft relevant to both groups.
> 
> Here are links to the draft and the ongoing discussions in V6OPS:
> 
> 1. Draft: 
> https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
> 2. V6OPS Thread: 
> https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ85OY/
> 
> 
> Currently, there is an adoption call in V6OPS for this draft set to end on 
> July 10, 2023. Your opinion, input, and suggestions will be highly valued as 
> we explore and progress this topic. I look forward to fruitful and 
> enlightening discussions.
> 
> Best regards,
> 
> Momoka Yamamoto
> momoka@gmail.com
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

[Joe Abley]

Hi Duane,

On Wed, Jul 5, 2023 at 18:32, Wessels, Duane 
<[dwessels=40verisign@dmarc.ietf.org](mailto:On Wed, Jul 5, 2023 at 18:32, 
Wessels, Duane < wrote:

> On Jun 30, 2023, at 2:32 PM, Joe Abley  wrote:
>
>> I wonder whether another subsection of section 2 would be useful to discuss 
>> transactions that don't time out, but whose transports return positive 
>> indications of failure, e.g. a TCP handshake failure or RST, or a TLS 
>> negotiation failure when using DoT or DoH. These are not
>
>> timeouts, but they also lack RCODEs (since they lack responses). Is it worth 
>> suggesting that failures that are transport-specific be cached, e.g. to 
>> record that server 192.0.2.1 doesn't respond on TCP so don't bother 
>> bombarding it with SYNs? You talk about this in 3.1; perhaps a forward 
>> reference from section 2 would be helpful.
>
> Based on your points here, we suggest this update to section 2.3:
>
> 2.3. Timeouts and Unreachable Servers
>
> A timeout occurs when a resolver fails to receive any response from a
> server within a reasonable amount of time. Additionally, a transport
> layer protocol may more quickly indicate lack of reachability in a
> way that wouldn't be considered a timeout. For example: an ICMP port
> unreachable message, a TCP "connection refused" error, or a TLS
> handshake failure. [RFC2308] refers to these conditions collectively
> as "dead / unreachable servers."
>
> Note that resolver implementations may have two types of timeouts: a
> smaller timeout which might trigger a query retry and a larger
> timeout after which the server is considered unresponsive.
> Section 3.1 discusses the requirements for resolvers when retrying
> queries.

I like it.

>> Section 2 talks at some length about RCODEs like SERVFAIL and REFUSED but is 
>> silent on the existence of the extended error option. This may be ok, e.g. 
>> since the EDE spec is quick to specify that it "does not change the 
>> processing of RCODEs" and since the purpose of your draft is presumably to 
>> deal with retry behaviour regardless of whether EDE is supported, but it 
>> feels odd not to mention it at all even if it's just to clarify why it's ok 
>> for this specification to deal just with RCODEs.
>
> We’ve added this:
>
> Although the extended DNS errors method exists "primarily to extend
> SERVFAIL to provide additional information," it "does not change the
> processing of RCODEs" [RFC8914]. This document operates at the level
> of resolution failure and does not concern particular causes.

Great!

>> Section 3.1 uses the phrase "a server's transport". I stared at that for 
>> quite a bit and I'm not sure I know for sure what it means. I think you're 
>> talking about the number of successive transmission of the same query using 
>> the same transport that are sent to the same server address. Perhaps that's 
>> obvious to other people (or perhaps my interpretation illustrates that there 
>> is some ambiguity).
>
> That is the intention. Is this more verbose text better?
>
> A resolver MUST NOT retry a given query to a server address over a
> given transport protocol more than twice (i.e., three queries in
> total) before considering the server address unresponsive over that
> transport for that query.

That seems better to me, thanks.

>> Later in this section when you say "timeout value" I think you're talking 
>> about how long to wait before identifying a timeout. Again, perhaps that's 
>> obvious.

> how about this?
>
> This document does not place any requirements on how long an
> implementation should wait before retrying a query (aka timeout
> value), which may be implementation- or configuration-dependent. It

Unless you're going to reuse the phrase "timeout value" somewhere else I'm not 
sure why you define it, but that is definitely clearer to me than the original 
and I am wary of being even more pedantic than I already was (which is why I 
didn't make any comment above about "a given query") (whoops, inside voice).

Thanks for taking care of those things. I think the document is ready to ship.

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

[DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-13.txt

[Tim Wicinski]

All

The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
implementers to expand upon the index of Known Implementations, and what
they implement specifically.

The chairs would like to have a one week follow up Working Group Last Call
comment period. We are looking for substantive comments regarding the
changes made, and if they are enough to address concerns raised.

This comment period will end Wednesday July 12, 2023.   If there
are substantive comments raised, we can address these during the meeting.

thanks
tim


-- Forwarded message -
From: 
Date: Wed, Jul 5, 2023 at 3:47 AM
Subject: New Version Notification -
draft-ietf-dnsop-avoid-fragmentation-13.txt
To: , , , <
war...@kumari.net>



A new version (-13) has been submitted for
draft-ietf-dnsop-avoid-fragmentation:
https://www.ietf.org/archive/id/draft-ietf-dnsop-avoid-fragmentation-13.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/

Diff from previous version:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-avoid-fragmentation-13

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

Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

[Wessels, Duane]

> On Jun 30, 2023, at 2:32 PM, Joe Abley  wrote:
> 
> 
> 
> I have read -04. i like it. I think it's useful and sensible and it should be 
> published. Whether this particular rev is ready for publication I would say 
> depends on whether the authors disagree with all the pedantic nonsense that 
> follows. They should feel free not to agree.

Thanks Joe, some responses inline.

> 
> There are some nits that the authors might want to address or prepare to be 
> outraged at the suggestion of.
> 
> The last paragraph in section 1.3 defines terms that are not used in this 
> document except in that paragraph, I think? Perhaps they are vestigial.

Good catch, we’ve removed the reference to Private Use, Reserved, etc.


> 
> In section 2.1 the phrase "Authoritative servers, and more specifically 
> secondary servers, return server failure responses when they don't have any 
> valid date for a zone." I don't think secondary servers are special from the 
> perspective of a client sending a query; such clients cannot usually 
> distinguish between primary and secondary servers and there are a wealth of 
> well-used authoritative servers deployed that don't use zone transfers 
> anyway. I suggest removing the qualifying "and more specifically secondary 
> servers".

We’re inclined to agree and have removed the phrase as you suggest.

> 
> In section 2.1 the phrase "server failure responses" is used in place of 
> SERVFAIL. In section 2.2 return codes are referred to as RCODEs and REFUSED 
> is used in place of "refused return codes" or something. I don't think it 
> matters too much which is used, but it seems like the document should be 
> consistent. I like the all-caps representations, personally, but if you go 
> with that there's an argument that they should be defined, e.g. by means of a 
> reference to whatever the latest dns-terminology draft is in section 1.3.

We’ve made changes to be more consistent when talking about SERVFAIL, REFUSED, 
and FORMERR responses, using the short all-caps names as you suggest.

> 
> I wonder whether another subsection of section 2 would be useful to discuss 
> transactions that don't time out, but whose transports return positive 
> indications of failure, e.g. a TCP handshake failure or RST, or a TLS 
> negotiation failure when using DoT or DoH. These are not

> timeouts, but they also lack RCODEs (since they lack responses). Is it worth 
> suggesting that failures that are transport-specific be cached, e.g. to 
> record that server 192.0.2.1 doesn't respond on TCP so don't bother 
> bombarding it with SYNs? You talk about this in 3.1; perhaps a forward 
> reference from section 2 would be helpful.

Based on your points here, we suggest this update to section 2.3:

2.3.  Timeouts and Unreachable Servers

   A timeout occurs when a resolver fails to receive any response from a
   server within a reasonable amount of time.  Additionally, a transport
   layer protocol may more quickly indicate lack of reachability in a
   way that wouldn't be considered a timeout.  For example: an ICMP port
   unreachable message, a TCP "connection refused" error, or a TLS
   handshake failure.  [RFC2308] refers to these conditions collectively
   as "dead / unreachable servers."

   Note that resolver implementations may have two types of timeouts: a
   smaller timeout which might trigger a query retry and a larger
   timeout after which the server is considered unresponsive.
   Section 3.1 discusses the requirements for resolvers when retrying
   queries.

> 
> Section 2 talks at some length about RCODEs like SERVFAIL and REFUSED but is 
> silent on the existence of the extended error option. This may be ok, e.g. 
> since the EDE spec is quick to specify that it "does not change the 
> processing of RCODEs" and since the purpose of your draft is presumably to 
> deal with retry behaviour regardless of whether EDE is supported, but it 
> feels odd not to mention it at all even if it's just to clarify why it's ok 
> for this specification to deal just with RCODEs.

We’ve added this:

   Although the extended DNS errors method exists "primarily to extend
   SERVFAIL to provide additional information," it "does not change the
   processing of RCODEs" [RFC8914].  This document operates at the level
   of resolution failure and does not concern particular causes.

> 
> Section 3.1 uses the phrase "a server's transport". I stared at that for 
> quite a bit and I'm not sure I know for sure what it means. I think you're 
> talking about the number of successive transmission of the same query using 
> the same transport that are sent to the same server address. Perhaps that's 
> obvious to other people (or perhaps my interpretation illustrates that there 
> is some ambiguity).

That is the intention.  Is this more verbose text better?

   A resolver MUST NOT retry a given query to a server address over a
   given transport protocol more than twice (i.e., three queries in
   total) before considering 

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

[Peter Thomassen]

Hi Libor,

On 6/26/23 13:56, libor.peltan wrote:

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.


That's a fair point that I had not appreciated -- thank you for raising it! 
Viktor told me off list that it is also in line with his thoughts on 
reachability (he had commented on related aspects earlier, so I reached out).

So, how about replacing the second paragraph of Section 2 with the following:

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

NEW:
   In all cases, consistency is REQUIRED across received responses only.
   When a response cannot be obtained from a given nameserver, the
   Parental Agent SHOULD attempt obtaining it at a later time, before
   concluding that the nameserver is permanently unreachable and
   removing it from further consideration.  A retry schedule with
   exponential back-off is RECOMMENDED.

This leaves the duration of the retry period to the operator. I'm fine with 
specifying something (it may actually help interoperability across TLDs), I'm 
just not sure what's a good value. Three days?

I labeled the retry mechanism "SHOULD", not "MUST", because even without this mechanism, 
the consistency requirements provide *some* protection. Do we want to say that 
"better-than-nothing" implementations that don't keep this state are in violation of the spec?

It would be great if someone who has a CDS scanner could comment.

Thanks,
Peter

--
https://desec.io/

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

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-bootstrapping-04

[Rose, Scott W. (Fed)]

On 4 Jul 2023, at 10:03, Peter Thomassen wrote:

> Hi Scott,
>
> Thank you very much for your feedback -- responses inline.
> o "inline" the actual definition, but that was just a feeling.)
>
>> Also, “Signaling Name” sounds
>> confusing compared to the Signaling Domain. Would it be easier to write it 
>> as:
>>
>> “Signaling Name  The owner name of comprised of a prefix, the Child zone name
>> and the Signaling domain name. Used by the Parental Agent to identify and
>> retrieve the Signaling Type used by the Child zone (See Section 2.2). “
>>
>> To stress it is a name in the Signaling Domain, but contains the child zone
>> name.
>
> Coming up with this terminology was really challenging. The reason that the 
> Signaling Name is only the prefix, without the Signaling Domain, is that it 
> makes the rest of the spec easier. For example, from Section 3.1:
>
>To [...]
>authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator
>MUST co-publish them at the corresponding Signaling Name under each
>out-of-bailiwick Signaling Domain [...]
>
> With your definition, one would have to say
>
>To [...]
>authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator
>MUST co-publish them at each corresponding out-of-bailiwick Signaling
>Name [...]
>
> Do you feel that's an improvement?
>

I honestly don’t have a good solution so maybe the original wording is best.

I was thinking maybe changing it to “Signaling Name Prefix” but that isn’t an 
improvement either.

I would be fine in leaving the text as-is since there doesn’t seem to be a 
better wording that is apparent. The rest of the doc is clear as to how the 
name is formed and used and that is the important part.

I am fine with the other changes. I can update the review to “Ready” to 
finalize things for this version.

Scott


>
> Thanks,
> Peter
>
> -- 
> https://desec.io/


==
Scott Rose NIST/CTL
scott.r...@nist.gov
ph: +1-301-975-8439 (w)
+1-571-249-3761 (GoogleVoice)
==

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

Re: [DNSOP] Feedback on draft-ietf-dnsop-domain-verification-techniques-01

[Tim Wicinski]

Erik

I placed your excellent comments into the author's issue tracker, then we
decided to split them up into separate issues.
Take a look to confirm. If anything is wrong, it's one me

tim


APEX domains, and hostnames vs domains

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/65

Public Suffix

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/66

SaaS/Paas/intermediary provider cases (eg CDNs)

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/67

Leveraging ACME challenges for other purposes

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/68

Multi-provider / multi-CDN setups

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/69

Token format / construction

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/70

Binding tokens to requests

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/71

TTL recommendations

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/72

Policy constraints as a variant

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/73

Registry of labels

https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/74

On Thu, Mar 30, 2023 at 4:53 PM Erik Nygren  wrote:

> Hello,
>
> Thank you for pulling together this draft!  Having worked on related
> systems a number of times it will be valuable to have something here
> standardized.
>
> A number of comments and suggestions:
>
> 1) APEX domains, and hostnames vs domains
>
> You define APEX but don't then reference this.  This is an important topic
> to cover in considerably more detail, however.  In particular, some systems
> want to validate an apex domain while others want to validate each
> particular hostname.  It is critical that validation record and its
> contents are unambiguous as to which of these is the case.
>
> As an example, ACME has separate mechanisms for wildcard certs (eg, "*.
> example.com") vs individual names (eg, "bar.example.com").
> This is likely to apply across the board to these systems: sometimes they
> want to validate usage for a domain and sometimes for just specific names.
>
> For the individual hostname case, it is important to clarify that the
> challenge should be "_foo-challenge.bar.example.com".
>
> For the whole domain case this could be  "_
> foo-wildcard-challenge.example.com"  or have an attribute in the TXT
> token (eg, wildcard=true).ACME (rfc8555 section-8.4) doesn't seem to
> have this differentiation, which seems unfortunate, unless I'm misreading.
> I'd think that it should be unambiguous to domain admins whether a
> challenge is for just the "example.com" name, for "*.example.com", or for
> "example.com, *.example.com, *.*.example,com, etc".
>
> What it means to validate a hostname or a domain or a wildcard set of
> hostnames may vary widely per application, and we may want to talk more
> about the security considerations here.
>
> Ambiguities about whether a given verification token grants powers over a
> specific hostname or an entire domain also introduce security challenges
> that we may wish to talk about in Security Considerations.  DNS domain
> administrators need to be able to understand the consequences of adding in
> particular challenge entries into their domain, especially in cases like a
> multi-tenant Enterprise environment.
>
> 2) Public suffixes
>
> We may wish to encourage (or require) validating against Public Suffix
> lists (eg, https://publicsuffix.org/), in the absence of a more general
> DBOUND solution.  At a minimum we should discuss this in security
> considerations.
>
> One Security Consideration is that services operating a public suffix
> should take extreme care about when they allow underscore labels to be
> created within a shared domain.  As an example, if a service provider
> allows "_foo-challenge.publicsuffix.example" to be registered as a domain
> (for a DNS registrar) or to be created as a CNAME or TXT record (eg, for a
> dynamic DNS provider or cloud provider) then this might grant unintended
> powers over all of "publicsuffix.example".
>
> We may also want to (encourage? require?) confirming that a user isn't
> trying to place a validation token on a public suffix.  ACME has this as a
> "CA Policy Consideration" (Section 10.5 of rfc8555).  There are some
> legitimate use-cases here, but caution (and perhaps extra validation?) is
> needed.
>
> (For the Appendix, another example would be the PSL itself.  Per
> https://github.com/publicsuffix/list/wiki/Guidelines
> It uses "_psl.alphaexample.com TXT
> https://github.com/publicsuffix/list/pull/100"; for validation.)
>
> 3) SaaS/Paas/intermediary provider cases (eg, CDNs)
>
> A common use-case is for delegation of control over to an

Re: [DNSOP] Next steps: draft-ietf-core-dns-over-coap

[Ben Schwartz]

I think firmware size is a perfectly reasonable and sufficient motivation for 
this draft, but I don't think it can be described as "performance".

--Ben Schwartz



From: Christian Amsüss
Sent: Wednesday, July 5, 2023 12:17 PM
To: Ben Schwartz
Cc: Martine Sophie Lenders; c...@ietf.org; 
draft-ietf-core-dns-over-c...@ietf.org; dnsop; DNS Privacy Working Group
Subject: Re: [DNSOP] Next steps: draft-ietf-core-dns-over-coap

Hello Ben,

picking one of the points in the thread and leaving the rest to another
subthread:

> > We have a paper on the performance benefits just accepted for CoNEXT,
> > which we will cite once it is published. An early pre-print (the final
> > paper underwent some major revisions though) is available on arXiv [5].
>
> This paper appears to be focused on DNS performance, but DNS is
> usually only a small component of overall system performance.

In this context, I think a relevant performance metric is firmware size
(or, equivalently, network load from firmware updates) -- a metric that
is covered in the latest preprint[1] of the same work. While a CoAP plus
OSCORE stack is marginally larger in firmware that a DNS plus DTLS stack
(and admittedly that's not even accounting for EDHOC that'd also be
needed if the DNS server is authenticated with public key cryptography),
that is text the application already pulls in, whereas the DTLS
component of DNS over DTLS alone already weighs another 20KiB of
firmware size. That represents a significant portion of the flash memory
available on the relevant microcontrollers.

Software complexity (both in terms of LoC and in terms of items on an
SBOM) is a factor that improves in parallel to the binary size savings.

BR
Christian

[1]: https://arxiv.org/abs/2207.07486v2

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOPReminder: Please review draft-ietf-dnsop-svcb-dane

[Ben Schwartz]

From: DNSOP  on behalf of Viktor Dukhovni 


Quoting from the draft:
...
>   If the initial TLSA base domain is the start of a secure CNAME chain,
>   clients MUST first try to use the end of the chain as the TLSA base
>   domain, with fallback to the initial base domain, as described in
>   Section 7 of [RFC7671].
...
If we don't expect prolific use of SVCB or HTTPS targets that are in
turn CNAMEs, perhaps it is time to reconsider the advice in 7671 which
was written when operational experience was still evolving.
As an interim step, what do you think about this addition: 
https://github.com/bemasc/svcb-dane/pull/6/files ?

My hope is that this gives us room to make a change like you're imagining in 
the future, while also ensuring that a client for this draft can be implemented 
entirely as a wrapper around an existing, non-SVCB-aware DANE implementation.

>   If a TLSA RRSet is securely resolved, the client MUST set the SNI to
>   the TLSA base domain of the RRSet.  In usage modes other than DANE-
>   EE(3), the client MUST validate that the certificate covers this base
>   domain, and MUST NOT require it to cover any other domain.

Note that after 7671 was published it was pointed out by Richard Barnes
in https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00  that
not verifying the server name with DANE-EE(3) is problematic in the
web browser use-case, because it can lead to cross-origin issues that
are absent in protocols such as SMTP.
FWIW, I believe that draft overlooks the defense against misdirected requests 
in HTTP: 
https://datatracker.ietf.org/doc/html/rfc9110#name-rejecting-misdirected-reque. 
 I believe that UKS attacks are not possible from HTTP/1.1 onwards.

Therefore, barring specific knowledge that the application protocol in
question faces no similar issues, the certificate name should by default
always be checked.  This is reflected in the OpenSSL DANE
implementation, which requires a non-default flag to turn off name
checks when validating a peer via a matching DANE-EE(3) TLSA record.
I don't think it helps to check the certificate against the TLSA base domain, 
if (as here and in SRV) the TLSA base domain is independent of the original 
QNAME.  Perhaps you mean to check it against the original QNAME, but this seems 
extremely limiting, as it would prevent a CDN from publishing a single TLSA 
record for use by numerous customers.

How about this text on the topic: https://github.com/bemasc/svcb-dane/pull/7 ?

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

Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

[Tim Wicinski]

All

Thanks for all the feedback on this document. We chairs understand there
are some questions around privacy considerations.

However, there was no comments on DNSOP adopting this work to resolve those
issues.  The document can go to the Independent
Stream Editor and we can point them to this email thread as something that
can be addressed.

Authors should fill free to submit to the ISE. We will alert them as well

tim


On Fri, Jun 23, 2023 at 4:18 PM Tim Wicinski  wrote:

>
> All
>
> Draft-dulaunoy-dnsop-passive-dns-cof was originally submitted back in
> 2014, and has had 10 revisions since then.
>
> https://datatracker.ietf.org/doc/draft-dulaunoy-dnsop-passive-dns-cof/
>
> Note that the format is now fixed, and there are several implementations.
>
> We had asked DNSOP (in the poll we held)to help us assess the level of
> interest in it, and the responses  largely put it moderately high  ("Adopt,
> but not now"). It would be helpful to find out if this is still the case,
> as things have progressed since then: the format is now widely used, and so
> the format itself is basically fixed. As an example, the format is being
> used within the US government agencies for event logging and incident
> response[0].
>
>
> One of two things could happen:
>
> 1: DNSOP decides that they are really interested, adopts and improves the
> justification / operational / supporting text, and the draft gets published
> as an IETF RFC; or
>
>
> 2: DNSOP says "No thanks, but we don't actively object". In which case the
> ISE (and Warren!) has a much easier time explaining why it's being
> published as an RFC on the Independent stream. . We will also ask for a DNS
> Directorate review.
>
>
> Feedback Welcome
>
> tim
>
> [0]: Because the draft had expired, and the USG cannot (realistically)
> point at expired IDs, they had to copy and paste it into an internal
> document:
> https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf
>  Page 15 is the table where they defined the Passive DNS Log fields.
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Next steps: draft-ietf-core-dns-over-coap

[Christian Amsüss]

Hello Ben,

picking one of the points in the thread and leaving the rest to another
subthread:

> > We have a paper on the performance benefits just accepted for CoNEXT,
> > which we will cite once it is published. An early pre-print (the final
> > paper underwent some major revisions though) is available on arXiv [5].
> 
> This paper appears to be focused on DNS performance, but DNS is
> usually only a small component of overall system performance.

In this context, I think a relevant performance metric is firmware size
(or, equivalently, network load from firmware updates) -- a metric that
is covered in the latest preprint[1] of the same work. While a CoAP plus
OSCORE stack is marginally larger in firmware that a DNS plus DTLS stack
(and admittedly that's not even accounting for EDHOC that'd also be
needed if the DNS server is authenticated with public key cryptography),
that is text the application already pulls in, whereas the DTLS
component of DNS over DTLS alone already weighs another 20KiB of
firmware size. That represents a significant portion of the flash memory
available on the relevant microcontrollers.

Software complexity (both in terms of LoC and in terms of items on an
SBOM) is a factor that improves in parallel to the binary size savings.

BR
Christian

[1]: https://arxiv.org/abs/2207.07486v2

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


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

Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

[Tim Wicinski]

Momoka

Thanks for making DNSOP aware of this.  We encourage anyone with comments
on the document adoption to reach out.

Everything I've heard and read on this work (wearing no hats) is that this
is good work and should be adopted.

thanks
tim



On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto  wrote:

> Dear dnsop wg
> cc:v6ops wg
>
> My name is Momoka, the author of the
> draft-momoka-v6ops-ipv6-only-resolver. This draft, which has already been
> introduced to the V6OPS Working Group, aims to address a pertinent
> operational issue: facilitating the transport of query packets from an
> IPv6-only iterative resolver to an IPv4-only authoritative DNS server.
>
> In light of some suggestions in V6OPS and considering the overlapping
> interests, I am introducing this draft to the DNSOP Working Group. Its core
> proposition lies in the mechanics of transporting query packets rather than
> the alteration of the DNS protocol behavior, but the operational context
> undoubtedly makes this draft relevant to both groups.
>
> Here are links to the draft and the ongoing discussions in V6OPS:
>
> 1. Draft:
> https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
> 2. V6OPS Thread:
> https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ85OY/
>
>
> Currently, there is an adoption call in V6OPS for this draft set to end on
> July 10, 2023. Your opinion, input, and suggestions will be highly valued
> as we explore and progress this topic. I look forward to fruitful and
> enlightening discussions.
>
> Best regards,
>
> Momoka Yamamoto
> momoka@gmail.com
> ___
> 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] DNSOPReminder: Please review draft-ietf-dnsop-svcb-dane

[Ben Schwartz]

From: Wes Hardaker 

Ben Schwartz  writes:

A few comments:

1. the MUST NOT in the first paragraph in 5.2 really feels like it should
be a SHOULD NOT.  Though its not wise, there could be scenarios where
someone really wants to do it and if they feel it's operationally
possible then they should be allowed to.
In general, my view is that compliance with the mandatory requirements should 
be sufficient for interoperability.  If this requirement is not mandatory, that 
creates an interoperability problem with the next paragraph's rule that 
"service operators MAY reject TLS connections whose SNI does not correspond to 
an approved TLSA base domain".
[I had a really hard time
writing this, as I think you're right about the importance, but we do
try to opt for SHOULD NOTs unless it always breaks something]
Personally, I tend to think that things that reliably break in some visible way 
don't really need normative language, because implementors will figure out that 
it's broken.  "MUST NOT" is most important when the problem is subtle, 
systemic, or delayed, as in this case.

Also, note that there is an escape hatch here ("unless they have an explicit 
arrangement ..."), so this is really not a technical requirement, and what 
constitutes such an arrangement is open to interpretation.
2. in the security considerations, the first sentence in the second
paragraph seems like it should have a solid requirement in it.  Maybe
"The SVCB and associated TLSA records MUST be validated by DNSSEC."  And
this is one of those cases where the MUST feels right as it
significantly degrades the security of the protocol if only a SHOULD is
used.  As such, I'd drop the rest of the paragraph.
We avoided this requirement for two reasons, both somewhat related to ADoT:

  1.  Unsigned TLSA records do exist (e.g. 
dns:_853._tcp.a.ns.facebook.com?type=TLSA) and provide some security benefit in 
situations where (a) full authentication is not well-defined or widely deployed 
and (b) the attacker is on the application path but not on the DNS path.
  2.  There have been some Authenticated ADoT proposals that rely at least in 
part on transport security rather than DNSSEC.  We used the phrase "resolved 
securely" to avoid prejudging that discussion.

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

Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

[Tim Wicinski]

All

The Working Group Last Call has completed and the chairs thank everyone for
their comments.
It appears that the authors have addressed all issues, and the document is
ready to advance.

tim


On Wed, Jun 21, 2023 at 11:00 AM Tim Wicinski  wrote:

> All
>
> This starts a Working Group Last Call for
> draft-ietf-dnsop-caching-resolution-failures
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
>
> The Current Intended Status of this document is: Proposed
> Standard/Standards Track
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on: 5
> July 2023
>
> thanks
> tim
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dns-error-reporting-04

[Roy Arends]

Thanks James,

I will update the Drink POC link

Warmly,

Roy

> On 7 Jun 2023, at 22:10, James Gannon via Datatracker  
> wrote:
> 
> Reviewer: James Gannon
> Review result: Ready
> 
> Hi Folks,
> I am the assigned DNSDIR reviewer for this draft.
> Thank you for a well-written draft that appears comprehensive and easy to
> understand from an implementor's perspective. I found no major or minor issues
> and I believe the draft is ready to progress.
> 
> A minor nit: The link in the additional resources to the Drink POC is a dead
> link.
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dns-error-reporting-04

[Roy Arends]

Yaron, many thanks for your review. Comments inline:

> On 26 Jun 2023, at 13:24, Yaron Sheffer via Datatracker  
> wrote:
> 
> Reviewer: Yaron Sheffer
> Review result: Has Nits
> 
> I am not a DNS expert so these may or may not be real issues. But I would
> appreciate the authors' clarifications.
> 
> - The error reports are unauthenticated. Some possible implications include:
> (1) Operators may choose to implement automated responses to error reports, 
> and
> will not consider that the source of the reports is untrusted.
> (2) An adversary
> may create massive error report flooding to camouflage an attack. At minimum, 
> I
> suggest to mention these risks in the security considerations.

Will do.

> 
> - "Authentication significantly increases the burden on the reporting resolver
> without any benefit to the monitoring agent, authoritative server or reporting
> resolver." I'm not sure I agree there's no benefit: a known, trusted set of
> reporting resolvers can provide a higher level of confidence in the error
> reports, and potentially enable more automated processing of these reports.
> CDNs may become such trusted resolvers, for example.

I will tone down the dismissive language and just use the following:

"Authentication significantly increases the burden on the reporting resolver, 
however, a known, trusted set of reporting resolvers can provide a higher level 
of confidence in the error reports, and potentially enable more automated 
processing of these reports.”

(I’ve used your text as guidance)

> - In general, is there value to error reporting in the absence of (aggregated)
> reporting on success? In other words, when evaluating a stream of errors, 
> isn't
> it important to measure the percentage of errors as part of the overall number
> of requests for a particular domain?

Absolutely. However, I wanted to avoid predicting how the reporting agent is 
going to implement its analysis and reporting functions.

> - This is yet another DNS covert channel. Should we mention it in the Security
> Considerations?

Is it though? If it is, isn’t all DNS susceptible to being a covert channel? 
Isn’t any traffic, not just DNS, susceptible of being another covert channel?

> - What is the broader effect of avoiding DNSSEC for the agent domain? Does it
> interfere with policies (and their automated enforcement) such as "sign
> everything under .tld"?

This should be dealt with in the relevant policy area.

> - More formally, there is no normative language around avoiding DNSSEC. Is it 
> a
> SHOULD?



> 
> - DNS query name minimization - shouldn't there be some guidance on this?
> Clearly minimization does not apply to the actual error portion of the report
> QNAME.

Clearly?

An agent domain can setup its servers in various ways, say, a single agent 
domain “uk.error.com”, and subsequently delegate:

uk._er.uk .error.com
co.uk ._er.uk.error.com 
police.uk ._er.uk.error.com 
Some_org.co.uk._er.uk.error.com 

You’ll see that a single error for “example.co.uk ” may 
be delegated a few times before it reaches the target server.

Hope this helps,

Thanks for the review Yaron!

Warmly,

Roy

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

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

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

[Roy Arends]

Viktor, thanks for your feedback. Comments inline.

> On 26 Jun 2023, at 22:13, Viktor Dukhovni  wrote:
> 
> On Thu, Jun 08, 2023 at 11:59:59AM +0200, Benno Overeinder wrote:
> 
>> This starts a two week Working Group Last Call process, and ends on: 
>> June 22nd, 2023.
> 
> I hope my feedback is not too late.  There are a few important elements
> of the draft that could use some changes.
> 
> On Tue, Jun 20, 2023 at 01:14:02PM +0200, Willem Toorop wrote:
>> 
>> I have one nit.
>> 
>> In the Example in section 4.2., a request still "includes an empty ENDS0 
>> report channel". The third paragraph of that same section states 
>> something similar: "As support for DNS error reporting was indicated by 
>> a empty EDNS0 report channel option in the request". But Section 6.1. 
>> Reporting Resolver Specification states: "The EDNS0 report channel 
>> option MUST NOT be included in queries."
> 
> On Tue, Jun 20, 2023 at 12:20:51PM +0100, Roy Arends wrote:
>> 
>> Ah, yes, I will remove that sentence completely!
> 
> So, under what conditions is the authoritative server free to include
> the error reporting channel extension in its reply?
> 
>- Does the resolver have to explicitly solicit it?

No.

> The reason this is important, is that there is non-negligible population
> of authoritative servers that (EDNS0 requirements notwithstanding) are
> not tolerant of unrecognised EDNS0 options.

Correct.

>  Therefore, soliciting the
> error reporting channel information is (at least initially, while this
> is not widely supported) more likely to lead to errors than to help to
> resolver errors.

Indeed. 

>  This is then not attractive to implement!
> 
> I would prefer to require resolvers to be more tolerant of unexpected 
> options, and would have servers report the channel without explicit
> solicitation.

That is indeed the plan. I shall make that explicit in the new text.

> 
> On Tue, Jun 20, 2023 at 11:35:28PM +0100, Dick Franks wrote:
>>> An authoritative server includes the option if configured to do so
>>> AND if it has the a non-null domain name configured as the reporting
>>> channel. It will then reply to each query. This is IMHO better than
>>> having a resolver include the option each and every time. Note that
>>> resolvers will ignore options that are unknown to them.
>> 
>> 6.2.  Authoritative server specification
>> Contains not a shred of normative language saying any of that.
>> 
>> The preliminary waffle in the overview could apply to either the
>> solicited or unsolicited regime.
>> 
 I withdraw my earlier statement that the document is almost ready.
 Now, clearly it is not.
>>> 
>>> I hear you. I do not agree though, and I hope you reconsider
>> Not without further work
> 
> I agree this needs to be made more explicit than just deleting the
> conflicting text.
> 
> On Thu, Jun 22, 2023 at 04:10:46PM -0700, Wes Hardaker wrote:
>> Roy Arends  writes:
>> 
>>> That, IMHO is already captured by the last paragraph. I did not
>>> explicitly write a recipe of how to do that, and which servers could
>>> be used for that :-). Could you suggest text to improve the last
>>> paragraph without naming services?
>> 
>> Erg.  I hate it when I have to come up with text :-P
>> 
>> How about replacing the last sentence of security considerations with:
>> 
>> This method can be abused by intentionally deploying broken zones with
>> agent domains that are delegated to victims.  This is particularly
>> effective when DNS requests that trigger error messages are sent through
>> open resolvers [RFC8499] or widely distributed network monitoring
>> systems that perform distributed queries from around the globe.
>> Implementations SHOULD rate-limit outgoing error messages to a
>> recipient to no more than 1 a minute.
> 
> What is a "recipient"?  Is it a monitoring agent "zone", or a monitoring
> agent transport endpoint?  If we're concerned about DoS, perhaps it
> should be the latter, since many zones can resolve to the same set of
> underlying nameservers...

I will deal with this text in the update.

> 
> On Fri, Jun 23, 2023 at 01:27:21AM +, Ben Schwartz wrote:
> 
>> I want this draft to move forward, but upon review I noted with
>> concern the security section text:
>> 
>>   DNS error reporting is done without any authentication between the
>>   reporting resolver and the authoritative server of the agent domain.
>>   Authentication significantly increases the burden on the reporting
>>   resolver without any benefit to the monitoring agent, authoritative
>>   server or reporting resolver.
>> 
>> Strong authentication (e.g. to a zone identity with DNSSEC) is
>> probably excessive, but the current draft appears to have no defense
>> against even trivial IP spoofing.  Anyone in the world who can spoof
>> IP addresses can impersonate a reputable resolver and pollute the
>> error reports sent to authoritative servers.  As an authoritative
>> server operator, I would place a lot more trust in reports from
>> 

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-structured-dns-error-03

[mohamed . boucadair]

Hi Matt, Di,

Thank you for the follow-up. 

We released a new version that addresses both your reviews. FWIW, a diff to 
track the changes can be seen at: 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-structured-dns-error-03&url2=draft-ietf-dnsop-structured-dns-error-04&difftype=--html

Cheers,
Med

> -Message d'origine-
> De : DNSOP  De la part de Matt Brown
> Envoyé : lundi 3 juillet 2023 10:40
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : dns...@ietf.org; dnsop@ietf.org; draft-ietf-dnsop-structured-
> dns-error@ietf.org
> Objet : Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-
> structured-dns-error-03
> 
> Hi Med,
> 
> Thanks for the responses, further comments in-line.
> 
> On Fri, Jun 30, 2023 at 9:24 PM 
> wrote:
> >
> > Hi Matt,
> >
> > Thank you for the review.
> >
> > Please see inline. I let my co-author further comment as
> appropriate.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Matt Brown via Datatracker  Envoyé :
> vendredi
> > > 30 juin 2023 00:01 À : dns...@ietf.org Cc : dnsop@ietf.org;
> > > draft-ietf-dnsop-structured-dns- error@ietf.org Objet :
> Dnsdir
> > > early review of draft-ietf-dnsop-structured-dns-
> > > error-03
> > >
> > > Reviewer: Matt Brown
> > > Review result: Almost Ready
> > >
> > > I believe this draft has ambiguities that will present issues
> for
> > > implementing clients that require further discussion and
> > > clarification before proceeding.
> > >
> > > **Issue 1**
> > > RFC8914 is clear (section 2) regarding EXTRA-TEXT that “This
> > > information is intended for human consumption (not automated
> > > parsing).“.
> > >
> >
> > [Med] Sure. That is already called out in the spec:
> >
> > Abstract:
> >This document updates RFC 8914 by signaling client support
> for
> >structuring the EXTRA-TEXT field of the Extended DNS Error to
> provide
> >details on the DNS filtering.  Such details can be parsed by
> the
> >client and displayed, logged, or used for other purposes.
> >
> > Introduction:
> >
> >This document describes a format for computer-parsable data
> in the
> >EXTRA-TEXT field of [RFC8914].  It updates Section 2 of
> [RFC8914]
> >which says the information in EXTRA-TEXT field is intended
> for human
> >consumption (not automated parsing).
> >
> > > Section 4 of this draft implicitly updates that requirement by
> > > stating that I-JSON can be sent in the field, but focuses on
> the
> > > technical aspects of the JSON structure, not on the
> implications of
> > > reversing that statement.
> > >
> > > Changing a field stated as for human consumption to a field
> intended
> > > to be machine-readable is a major change and the implications
> of
> > > this change should be discussed in the draft, including an
> explicit
> > > statement updating the intent of the EXTRA- TEXT field.
> > >
> > > In particular I would expect to see discussion and
> consideration of
> > > how backwards compatibility with RFC8914 compliant, but
> > > structured-dns-error ignorant clients would be achieved.
> >
> > [Med] Clients that are capable to consume the json format will
> behave as follows:
> >
> >It SHOULD use an OPTION-LENGTH of 2,
> >the INFO-CODE field set to "0" (Other Error), and an empty
> EXTRA-TEXT
> >field.  This signal indicates that the client desires that
> the server
> >responds in accordance with the present specification.
> >
> > The server will take that into account to elicit which format to
> use. Will double check if we need to better clarify this in the
> text. For now, I identified this change
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> github.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop-structured-dns-
> error%2Fpull%2F35%2Ffiles&data=05%7C01%7Cmohamed.boucadair%40orang
> e.com%7Cf866518611f84bac03ee08db7ba13ac2%7C90c7a20af34b40bfbc48b92
> 53b6f5d20%7C0%7C0%7C638239704623560543%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 3000%7C%7C%7C&sdata=d83rOc775XtiQyh9%2FAuhj6EhSxQ7OKKSZfT9jdZ3eb8%
> 3D&reserved=0.
> 
> OK! My apologies. I managed to completely overlook and miss this
> discrimination mechanism in my multiple readings of the draft,
> even when specifically trying to work out how the concerns I
> originally raised here would be avoided. It seems obvious to me
> now that you've pointed it out, but it definitely wasn't obvious
> to me in any of my earlier readings.
> 
> I would suggest a few extra pointers to this mechanism elsewhere
> in the draft to help avoid my struggle in future, e.g.:
> * The first sentence of section 4 could change from "DNS servers
> that are compliant with this specification ..." to "DNS servers
> that are compliant with this specification AND have received an
> indication that the client also supports this specification as per
> s5.1 send I-JSON..."
> * In section 5.2, add some statement to cover the normal cases
> (e.g.
> "When responding to a que

[DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-04.txt

[internet-drafts]

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

   Title   : Structured Error Data for Filtered DNS
   Authors : Dan Wing
 Tirumaleswar Reddy
 Neil Cook
 Mohamed Boucadair
   Filename: draft-ietf-dnsop-structured-dns-error-04.txt
   Pages   : 22
   Date: 2023-07-05

Abstract:
   DNS filtering is widely deployed for various reasons, including
   network security.  However, filtered DNS responses lack information
   for end users to understand the reason for the filtering.  Existing
   mechanisms to provide explanatory details to end users cause harm
   especially if the blocked DNS response is to an HTTPS server.

   This document updates RFC 8914 by signaling client support for
   structuring the EXTRA-TEXT field of the Extended DNS Error to provide
   details on the DNS filtering.  Such details can be parsed by the
   client and displayed, logged, or used for other purposes.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-04.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-structured-dns-error-04

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] I-D Action: draft-ietf-dnsop-avoid-fragmentation-13.txt

[internet-drafts]

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

   Title   : Fragmentation Avoidance in DNS
   Authors : Kazunori Fujiwara
 Paul Vixie
   Filename: draft-ietf-dnsop-avoid-fragmentation-13.txt
   Pages   : 12
   Date: 2023-07-05

Abstract:
   EDNS0 enables a DNS server to send large responses using UDP and is
   widely deployed.  Large DNS/UDP responses are fragmented, and IP
   fragmentation has exposed weaknesses in application protocols.  It is
   possible to avoid IP fragmentation in DNS by limiting response size
   where possible, and signaling the need to upgrade from UDP to TCP
   transport where necessary.  This document proposes techniques to
   avoid IP fragmentation in DNS.

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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-13

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-avoid-fragmentation-13

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