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

[tirumal reddy]

On Mon, 10 Jul 2023 at 10:22, Joseph Salowey  wrote:

>
>
> On Tue, Jul 4, 2023 at 5:20 AM tirumal reddy  wrote:
>
>> Thanks for the review. Please see inline
>>
>> On Sat, 1 Jul 2023 at 10:41, Joseph Salowey via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>> Reviewer: Joseph Salowey
>>> Review result: Has Issues
>>>
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG. These comments were written primarily for the benefit of the
>>> security area directors. Document editors and WG chairs should treat
>>> these comments just like any other last call comments.
>>>
>>> This document is well written and useful. The document does have a good
>>> security considerations section but I think it could be improved.
>>>
>>> 1. I think it would be good to provide more context for the
>>> recommendations in
>>> the security considerations section (and for the processing rules in
>>> section
>>> 5.3).  For example, the information in if untrusted information in the
>>> c, j and
>>> o fields are presented to an end user they may be used to misdirect the
>>> user to
>>> contact a malicious party to resolve their problem which could result in
>>> further compromise to the user's security (this could be worded better
>>> and
>>> there may be better examples).  I think this may help readers to
>>> understand the
>>> implications of not following the recommendations.
>>>
>>
>> Good point, added the following text:
>> For example, an end user can use contact details in the "c" field to
>> contact an attacker
>> to solve the problem of being unable to reach a domain. The attacker can
>> mislead the end user to
>> install malware or spyware to compromise the device security posture or
>> mislead the end user to reveal
>> Personally Identifiable Information (PII).
>>
>> [Joe] Yes this helps.
>
>
>>
>>> 2. I find the SHOULD NOT make text clickable difficult.  I don't think
>>> that the
>>> text should be clickable in general, but the contact field is
>>> essentially a
>>> series of link so the temptation is going to be to make it clickable.
>>
>>
>> Yes, that's the reason the above restriction is only imposed for "j" and
>> "o" fields.
>>
>>
> I think
>>> the document should describe better under what conditions the link can be
>>> clickable.  Also its probably worth saying that the fields are rendered
>>> as text
>>> and not HTML.
>>>
>>
>> Yes, fixed to say these fields need to be rendered as text and not as
>> HTML.
>>
>>
> [Joe] Why is this a SHOULD NOT instead of a MUST NOT, when is it
> appropriate that these fields are clickable?
>

I can't think of any valid reason why these fields should be clickable, we
will modify it to "MUST NOT".


>
> Is the intent that the "c" fields are clickable or not?
>

Yes, "c" field can be clickable (to make a VOIP call).


>
>
>>
>>> 3. Since links involved could be customized to the individual case
>>> privacy
>>> considerations may be needed. Following the contact links could possibly
>>> reveal
>>> information to another party.
>>>
>>
>> The proposed text to address comment#1 should address this issue as well.
>>
>>
>
> [Joe] I think the text helps. It is probably worth having a more privacy
> focused review here.  It could be possible that the clickable links could
> be customized to provide user tracking, perhaps to reveal what sites the
> user is visiting to a third party.  Perhaps an addition "...the user to
> reveal personal data or information about the sites they are connecting
> to." ?
>

The DNS resolver would anyway know the domains the user is visiting and can
possibly share that information with a third party. Trusted recursive
resolvers need to meet the policy requirements of the clients (for example,
see https://www.rfc-editor.org/rfc/rfc8932.html#section-5.3.3).  The fields
will not be displayed unless the resolver is trusted and even when the
resolver is trusted, none of the fields are clickable (excluding the "c"
field).

-Tiru


>
>
>>
>>> 4. A little bit of a nit- In section 5.3 it says if the C and J fields
>>> are
>>> missing then discard the whole message, yet later there are cases where
>>> you
>>> MUST ignore the C and J fields and yet can still handle the S field.
>>> This
>>> seems a little contradictory to me,  however I think technically its not
>>> a
>>> problem and would be implementable as it is.
>>>
>>
>> In the JSON schema, "c" and "j" fields are mandatory; hence the rule to
>> discard the EXTRA-TEXT field. However, these fields will be ignored in
>> several scenarios like opportunistic encryption mode or response from an
>> untrusted resolver.
>>
>>
> [Joe] Sounds good, thanks.
>
>
>> Cheers,
>> -Tiru
>>
>
___
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

[Shumon Huque]

Thanks and reviews/re-reviews welcome.

Note: we've held off on a few of the points that Erik Nygren raised because
they require a more involved treatment (detailed discussion of the
token/name/account binding process; multi provider/CDN support, etc). I've
asked Erik to contribute some text on those, and we might have some
corresponding updates later.

Shumon.

On Mon, Jul 10, 2023 at 4:30 PM Tim Wicinski  wrote:

> All
>
> Shivan, Shumon and Paul have incorporated feedback from the WG as well as
> several area reviews, and more.
> It's a much better document because of that, and we thank everyone.
>
> The chairs want to give the WG a 7-10 days to review the changes and
> confirm there are no issues
>
> thanks
> tim
>
>
> On Mon, Jul 10, 2023 at 2:57 PM Shivan Kaul Sahib <
> shivankaulsa...@gmail.com> wrote:
>
>> Hi folks, we received a bunch of feedback over the last couple of
>> months that we've addressed in this draft revision.
>>
>> Some notable things:
>>
>>1. We now use the term "domain control validation" instead of "domain
>>verification" since that seems to be the industry standard
>>2. Make the problem statement clearer in the new Common Pitfalls
>>section
>>3. Added new text on delegated domain control validation techniques
>>that are often used by CDNs. This technique uses CNAMEs, so we removed the
>>text around saying that CNAMEs are NOT RECOMMENDED
>>4. Removed strict requirements on the generation of the random token
>>5. Clarified that metadata in the validation record is optional
>>6. Addressed SECDIR and ARTART early review comments
>>7. Clarified scope of validation (i.e. apex vs not)
>>8. Cleaned up the Terminology section
>>9. Did a bunch of general document refactoring to make the
>>recommendations clearer
>>10. Added text for DNAME
>>
>>
>>
>> On Mon, 10 Jul 2023 at 08:59,  wrote:
>>
>>>
>>> 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   : Domain Control Validation using DNS
>>>Authors : Shivan Sahib
>>>  Shumon Huque
>>>  Paul Wouters
>>>Filename:
>>> draft-ietf-dnsop-domain-verification-techniques-02.txt
>>>Pages   : 15
>>>Date: 2023-07-10
>>>
>>> Abstract:
>>>Many application services on the Internet need to verify ownership or
>>>control of a domain in the Domain Name System (DNS).  The general
>>>term for this process is "Domain Control Validation", and can be done
>>>using a variety of methods such as email, HTTP/HTTPS, or the DNS
>>>itself.  This document focuses only on DNS-based methods, which
>>>typically involve the application service provider requesting a DNS
>>>record with a specific format and content to be visible in the
>>>requester's domain.  There is wide variation in the details of these
>>>methods today.  This document proposes some best practices to avoid
>>>known problems.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
>>>
>>> There is also an HTML version available at:
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-02.html
>>>
>>> A diff from the previous version is available at:
>>>
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-02
>>>
>>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>>> :internet-drafts
>>>
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Viktor Dukhovni]

On Mon, Jul 10, 2023 at 03:48:34PM -0700, internet-dra...@ietf.org wrote:

> 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   : DNS Error Reporting
>Authors : Roy Arends
>  Matt Larson
>Filename: draft-ietf-dnsop-dns-error-reporting-05.txt
>Pages   : 11
>Date: 2023-07-10

Some comments on on the -05 update.

* Spelling:  s/unsollicited/unsolicited/

* Substance: The new text suggests using TCP **and** cookies:

   Resolvers that send error reports SHOULD send these over TCP
   [RFC7766] and SHOULD use DNS COOKIEs [RFC7873].  This makes it
   hard to falsify the source address.  The monitoring agent SHOULD
   respond to queries received over UDP with the truncation bit (TC
   bit) set to challenge the resolver to re-query over TCP.

I don't believe it is at all common to combine TCP with cookies,
typically cookies are used over UDP, with fallback to TCP (sans
cookies) if the server's cookie is missing or invalid.

So above should be "either TCP **or** COOKIES".  If error reports are
infrequent no recent cookies will be cached for the monitoring agent,
and obtaining a cookie will require a round trip.  So perhaps simplest
to just use TCP.

I don't yet see any text about rate-limiting of reports beyond per
qname/qtype/info-code caching.  And yet the resolver has significant
additional context:

- The IP address of the problem nameserver.

* It can rate-limit the frequency of reports per nameserver IP.

- The server zone.

* It can rate-limit the frequency of reports per zone.

The per IP limit can be significantly more "generous", than the per-zone
limit, because some nameservers serve O(1M) zones, of which a few
thousand might exhibit a problem, while the server's overall health is
fine.  Reports for many different qnames in the same zone are likely
to be substantially redundant.

-- 
Viktor.

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

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

[Mark Andrews]

I think the issue is that NAT64 is being used to reach internal IPv4 addresses
(e.g. RFC 1918) so the traffic needs to go through a NAT64 that can reach those
addresses.


> On 10 Jul 2023, at 17:32, mohamed.boucad...@orange.com wrote:
> 
> Hi Gert,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Gert Doering 
>> Envoyé : lundi 10 juillet 2023 08:53
>> À : BOUCADAIR Mohamed INNOV/NET 
>> Cc : Ted Lemon ; v6...@ietf.org; Xipengxiao
>> ; dnsop 
>> Objet : Re: [v6ops] DNS64/Thread RE: [DNSOP] WG call for adoption:
>> draft-momoka-v6ops-ipv6-only-resolver-01
>> 
>> Hi,
>> 
>> On Fri, Jul 07, 2023 at 01:19:38PM +,
>> mohamed.boucad...@orange.com wrote:
>>> For your last point: problems may arise if a distinct pref64 is
>> used
>>> by the upstream DNS64 than the one used locally. Unless I???m
>>> mistaken, we currently don???t have a solution to detect
>> mismatches
>>> between what is used by a local NAT64 and an upstream DNS64 let
>> alone
>>> whether an upstream resolver is also performing DNS64. I used to
>> have
>>> a proposal for this:
>>> 
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> data
>>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-dnsop-prefix64-
>> 02&data
>>> 
>> =05%7C01%7Cmohamed.boucadair%40orange.com%7C156480ca56e144dd3c7708
>> db81
>>> 
>> 125189%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824568789974
>> 8586
>>> 
>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>> iI6I
>>> 
>> k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7hwX%2Bwnur4AnRNpe9LCY
>> lWNR
>>> jDC5Sk%2BCnzSpTZNmqi0%3D&reserved=0
>> 
>> I would assume that it just does not matter if there are two NAT64
>> boxes available, with different prefixes. Depending on which
>> prefix you use for the IPv6 synthesis, your packets will use one
>> or the other to be translated - which is actually one of the
>> brilliant aspects of NAT64, that it does not need to be in the
>> "non NAT" packet flow.
> 
> [Med] Yes, but not sure this is relevant to the point above.
> 
>> 
>> Same for "having two DNS64 in sequence" - while unusual, it will
>> still work.
> 
> [Med] I'm afraid not. Failure will be observed if there are no on-path NAT64 
> that uses the prefix used by these DNS64. 
> 
>  The first DNS64 to see the IPv4-only reply will do
>> synthesisis, the second DNS64 will see an IPv6 answer, and won't
>> have to do anything except "forward".  If they agree on the NAT64
>> prefix, packets will use the same NAT64 gateway in any case, if
>> not, see above.
>> 
>> Gert Doering
>>-- NetMaster
>> --
>> have you enabled IPv6 on something today...?
>> 
>> SpaceNet AG  Vorstand: Sebastian v. Bomhard,
>> Michael Emmer
>> Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-
>> Culemann
>> D-80807 Muenchen HRB: 136055 (AG Muenchen)
>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> ___
> 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

[DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-05.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   : DNS Error Reporting
   Authors : Roy Arends
 Matt Larson
   Filename: draft-ietf-dnsop-dns-error-reporting-05.txt
   Pages   : 11
   Date: 2023-07-10

Abstract:
   DNS error reporting is a lightweight reporting mechanism that
   provides the operator of an authoritative server with reports on DNS
   resource records that fail to resolve or validate.  A domain owner or
   DNS hosting organization can use these reports to improve domain
   hosting.  The reports are based on extended DNS errors as described
   in RFC 8914.

   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 a monitoring agent specified by
   the authoritative server.

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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-05

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

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


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

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

[Viktor Dukhovni]

On Mon, Jul 10, 2023 at 10:27:45PM +0100, Roy Arends wrote:

> > Right, but surely the monitoring agent can decide whether to solicit
> > such a prefix label or not.  That is whether an "_er" prefix label is
> > signalled is a *local matter* betweent the authoritative server
> > signalling the option and the monitoring agent.
> 
> I agree that a monitoring agent can specify a domain that may include
> a separator as the least significant label. However, it also requires
> the monitoring agent to understand that it should sometimes include
> this separator, and that it may be redundant at other times.

If all the monitoring agent's "customers" (authoritative servers that
return its "suffix" in the new option) are informed to signal an
"_er.agent.example" name, there's no "sometimes".  The agent, by mutual
agreement with the nameservers it supports can choose whatever suffix
format meets its needs, fixed across all customers, or customer-specific.

I haven't yet seen a reason to insist on a fixed suffix pattern.  The
resolver just stutters back the suffix it was handed by the
authoritative server's extension payload.  What problem does mandating
the least significant label of the suffix solve, that can't be solved by
just signalling the desired suffix, special label and all?

> It assumes that those running the authoritative server that returns
> the agent domain and those that run the reporting agent are in sync.
> Those are a lot of assumptions.

If they're not in sync, surely reporting will be broken, whether or not
an "_er" suffix label is used.

> >  Why should resolvers have to be responsible for this?
> 
> Because this separating label is trivial to include and avoids a lot of 
> hassle.

The hassle in question remains unclear.  I see two relevant/likely
deployment models:

* Self-hosted reporting, directly by the authoritative server:

- Error reports are special by virtue of a dedicated qname
  suffix and perhaps qtype.

- No special coördination required, the server both publishes
  and consumes the error reporting suffix.

 * Outsourced/centralised reporting, via server IPs dedicated to
   error report processing.

 - Here again no need for "_er", because all queries are
   presumptively error reports, and if the signal from the
   "customer" auth server was wrong (whether or not an "_er"
   label is included) the error report will not be handled
   correctly.

  - If the signal has the correct (mutually agreed) suffix,
again no problem.

  - And of course the monitoring agent can specify the use
of "_er" (or whatever) if that's convenient.

What use-case actually benefits from the "_er" LSL (least-significant
label) in the signal?  How is this benefit not obtained by mutual
agreement between the monitoring agent and its customers?

> >> The sole purpose of the leading “least-significant” “_er” is to
> >> distinguish between qname-minimized queries (for lack of a better
> >> term) and “full” queries. I understand that you argue that a
> >> monitoring agent can determine this without the _er labels (as
> >> described below), but that seem suboptimal to me.
> > 
> > The qname minimised query (whether or not a dedicated qtype is used)
> > will be for "A" or "NS" records, not TXT or the dedicated qtype, so
> > there's no need for "_er" in the first label, the qtype is sufficient.
> 
> RFC9156 contains no hard requirement to use A/NS. So I’m not confident
> that all current and future qname-minimisation implementations use
> A/NS. 

This is where this document can specify that qname minimised error
reports MUST use a qtype other than the qtype for the final error
report.

> > However, to avoid forwarding junk reports to the monitoring agent, a
> > resolver may well sensibly choose to not forward such queries, and
> > only source them internally.
> 
> I’m not following.

If the qtype is "TXT", then an open resolver is easily subject to
proxying forged error reports purporting errors that the resolver did
not observe.  Some client of the open resolver sends an explicit query
for:

. IN TXT ?

which then looks like an error report from *that* resolver to the
monitoring agent.  If instead we have a dedicated qtype for error
reports, it becomes a simple matter of refusing to iterate queries for 

. IN  ?

Any resolver wanting to report an error must do so directly, not via a
forwarder.  Especially because the forwarders won't be passing the
agent extension through to their clients!

> > The specification might also recommend that "stub" resolvers that
> > forward most queries to a "full service" resolver, should send error
> > reports *directly* to the monitoring agent.  And, of course, "full
> > service" resolvers MUST NOT *forward* the monitoring agent OPTION to
> > clients, if they send such an option, it should be locally generated
> > to signal the monitoring agent for the

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

[Roy Arends]

Hi Viktor,

Again, thank you for your detailed, in-depth and insightful response. My 
comments are inline, and I’ve removed the parts in agreement.

> On 10 Jul 2023, at 17:58, Viktor Dukhovni  wrote:
> 
> On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote:
> 
>>> The proposed qname structure is suboptimal:
>>> 
>>>   - There is insufficient justification for the "_er" labels
>>> at either end of the error report qname.
>>> 
>>>   o  If the monitoring agent wants to see some particular prefix,
>>>  (perhaps even periodically rotated to quickly drop stale
>>>  junk) the authoritative server can vend the prefix with the
>>>  agent domain.  So the "most-significant" parent "_er" is
>>>  IMNHSO redundant.
>> 
>> The monitoring agent has to determine where the QNAME ends, and the
>> agent domain starts. If you assume that a monitoring agent only uses a
>> single agent domain for all its reports, then sure, the _er_ label
>> between the strings is redundant.
>> 
>> If however, the monitoring agent has domains in use, where the least
>> significant labels collide with existing top level domains, it needs
>> to determine heuristically where the agent domain starts. This is IMHO
>> suboptimal.
> 
> Right, but surely the monitoring agent can decide whether to solicit
> such a prefix label or not.  That is whether an "_er" prefix label is
> signalled is a *local matter* betweent the authoritative server
> signalling the option and the monitoring agent.

I agree that a monitoring agent can specify a domain that may include a 
separator as the least significant label. However, it also requires the 
monitoring agent to understand that it should sometimes include this separator, 
and that it may be redundant at other times. It assumes that those running the 
authoritative server that returns the agent domain and those that run the 
reporting agent are in sync. Those are a lot of assumptions.

>  Why should resolvers
> have to be responsible for this?

Because this separating label is trivial to include and avoids a lot of hassle.

>  If a given monitoring agent does
> not need such signalling, what value does it add?

It may need this signalling in the future, when it adds new costumers (new 
domains to monitor) to its portfolio. If there is a collision, it needs to 
update its entire user-base to avoid it.

>>>   o The leading "least-significant" "_er" is likewise (see below)
>>> not adequately justified.
>> 
>> The sole purpose of the leading “least-significant” “_er” is to
>> distinguish between qname-minimized queries (for lack of a better
>> term) and “full” queries. I understand that you argue that a
>> monitoring agent can determine this without the _er labels (as
>> described below), but that seem suboptimal to me.
> 
> The qname minimised query (whether or not a dedicated qtype is used)
> will be for "A" or "NS" records, not TXT or the dedicated qtype, so
> there's no need for "_er" in the first label, the qtype is sufficient.

RFC9156 contains no hard requirement to use A/NS. So I’m not confident that all 
current and future qname-minimisation implementations use A/NS. 


>>> Also, qtypes are cheap, and I rather think that a dedicated qtype (one
>>> that a supporting resolver might refuse to accept in queries from
>>> clients for example) makes sense here.  There's no need to overload
>>> TXT here.
>> 
>> This seems counter intuitive to me. A qtype that a supporting resolver
>> might refuse to accept in queries from clients is either a temporary
>> state (it may be accepted in the near future when this qtype will be
>> implemented), or it needs to be specified that this qtype should not
>> be accepted in queries from clients, which makes this qtype not cheap
>> (that is, we won’t be able to simply use the template to request one,
>> as it requires additional work). 
> 
> There's no need to require that it not be accepted from clients, but
> it is easier to do that with a dedicated qtype.  It can be added to:
> 
>- RRSIG (semantically vacuous sans the associated RRset)
>- NSEC3 (not part of the zone's qname namespace).
>- ANY (if that's what the resolver chooses to do).
> 
> However, to avoid forwarding junk reports to the monitoring agent, a
> resolver may well sensibly choose to not forward such queries, and
> only source them internally.

I’m not following.

> The specification might also recommend that "stub" resolvers that
> forward most queries to a "full service" resolver, should send error
> reports *directly* to the monitoring agent.  And, of course, "full
> service" resolvers MUST NOT *forward* the monitoring agent OPTION to
> clients, if they send such an option, it should be locally generated
> to signal the monitoring agent for the resolver itself.

I’m not following. 

> 
>> Allocating a new QTYPE for this purpose just seems redundant. 
> 
> It is not.  This is not a normal query, it is an error report.

However, it is a normal

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

[Yaron Sheffer]

Looks good. Thank you Roy!

Yaron

On 10/07/2023, 19:45, "Roy Arends" mailto:r...@dnss.ec>> wrote:


Hi Yaron,


> On 9 Jul 2023, at 18:27, Yaron Sheffer  > wrote:
> 
> Hi Roy,
> 
> Please see some responses below, prefixed with YS.
> 
> Thanks,
> Yaron
> 
> On 05/07/2023, 14:31, "Roy Arends" mailto:r...@dnss.ec> 
> >> wrote:
> 
> 
> 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)
> 
> YS: I'm not sure I understand the proposed text, because the draft does not 
> provide a way (namely, authentication) to establish a "known, trusted set of 
> resolvers". Unless there's a way to authenticate these reports that I'm not 
> familiar with.


In general, resolvers do not cryptographically authenticate themselves to 
authoritative servers. What remains is to make sure that the source address is 
not spoofed. One method to make spoofing harder is for the auth-server to reply 
with a response containing a TC bit and challenge the resolver to re-query 
(re-send the error report) over TCP. In addition, some of these source 
addresses may be well known to the monitoring agent.


I’ll add some text around this.


> 
>> - 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.
> 
> YS: understood. It just seems to me that we're not providing the agent with 
> enough input for this analysis. And I guess I was suggesting to add a 
> feature: aggregated (or random, sample based) reporting on *successful* name 
> resolution.


I’m not convinced this feature is a good idea.


> 
>> - 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?
> 
> YS: fair enough.
> 
>> - 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?
> 
> YS: even if you deem DNSSEC policy to be out of scope, the question about 
> normative language still stands. Or at least guidance on when this mitigation 
> is recommended.


Will add.


Thanks Yaron!


Roy


___
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

[Ben Schwartz]

Thanks!  I think making it clear that auth servers are allowed to send TC to 
force TCP upgrade is a nice compromise.

From: DNSOP  on behalf of Roy Arends 
Sent: Monday, July 10, 2023 4:04 PM
To: Ben Schwartz 
Cc: Benno Overeinder ; DNSOP Working Group 
; DNSOP Chairs 
Subject: Re: [DNSOP] Working Group Last call for 
draft-ietf-dnsop-dns-error-reporting

!---|
  This Message Is From an External Sender

|---!

Ben,

Thanks for this! Comments inline.

> On 23 Jun 2023, at 02:27, 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 reputable resolvers than from unrecognized 
> sources.

Ack

> I think the draft should probably say something like: "To defend against 
> spoofing of source IP addresses used for error reports, reporting resolvers 
> MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC 7873], or another procedure 
> that defeats IP address spoofing."

I’ve added language to this extend. However, I’ll won’t go as far as MUST. I’ve 
made this is a SHOULD (for both TCP and cookie), while the authoritative server 
SHOULD respond with TC bit set to force a re-query over TCP.

Hope this suffices.

Warmly,

Roy


> --Ben SchwartzFrom: DNSOP  on behalf of Benno 
> Overeinder 
> Sent: Thursday, June 8, 2023 5:59 AM
> To: DNSOP Working Group 
> Cc: DNSOP Chairs 
> Subject: [DNSOP] Working Group Last call for 
> draft-ietf-dnsop-dns-error-reporting
>  !---|
>   This Message Is From an External Sender
>
> |---!
>
> Dear DNSOP WG,
>
> The authors and the chairs feel this document has reached the stage
> where it's ready for Working Group Last Call.
>
> This starts a Working Group Last Call for:
> draft-ietf-dnsop-dns-error-reporting.
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/  .
>
> The Current Intended Status of this document is: Standards Track.
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please
> speak out with your reasons.
> Supporting statements that the document is ready are also welcome.
>
> This starts a two week Working Group Last Call process, and ends on:
> June 22nd, 2023.
>
> Thanks,
>
> -- Benno
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


___
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

[Tim Wicinski]

All

Shivan, Shumon and Paul have incorporated feedback from the WG as well as
several area reviews, and more.
It's a much better document because of that, and we thank everyone.

The chairs want to give the WG a 7-10 days to review the changes and
confirm there are no issues

thanks
tim


On Mon, Jul 10, 2023 at 2:57 PM Shivan Kaul Sahib 
wrote:

> Hi folks, we received a bunch of feedback over the last couple of
> months that we've addressed in this draft revision.
>
> Some notable things:
>
>1. We now use the term "domain control validation" instead of "domain
>verification" since that seems to be the industry standard
>2. Make the problem statement clearer in the new Common Pitfalls
>section
>3. Added new text on delegated domain control validation techniques
>that are often used by CDNs. This technique uses CNAMEs, so we removed the
>text around saying that CNAMEs are NOT RECOMMENDED
>4. Removed strict requirements on the generation of the random token
>5. Clarified that metadata in the validation record is optional
>6. Addressed SECDIR and ARTART early review comments
>7. Clarified scope of validation (i.e. apex vs not)
>8. Cleaned up the Terminology section
>9. Did a bunch of general document refactoring to make the
>recommendations clearer
>10. Added text for DNAME
>
>
>
> On Mon, 10 Jul 2023 at 08:59,  wrote:
>
>>
>> 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   : Domain Control Validation using DNS
>>Authors : Shivan Sahib
>>  Shumon Huque
>>  Paul Wouters
>>Filename:
>> draft-ietf-dnsop-domain-verification-techniques-02.txt
>>Pages   : 15
>>Date: 2023-07-10
>>
>> Abstract:
>>Many application services on the Internet need to verify ownership or
>>control of a domain in the Domain Name System (DNS).  The general
>>term for this process is "Domain Control Validation", and can be done
>>using a variety of methods such as email, HTTP/HTTPS, or the DNS
>>itself.  This document focuses only on DNS-based methods, which
>>typically involve the application service provider requesting a DNS
>>record with a specific format and content to be visible in the
>>requester's domain.  There is wide variation in the details of these
>>methods today.  This document proposes some best practices to avoid
>>known problems.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
>>
>> There is also an HTML version available at:
>>
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-02.html
>>
>> A diff from the previous version is available at:
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-02
>>
>> 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] I-D Action: draft-ietf-dnsop-cds-consistency-02.txt

[Peter Thomassen]

Hi,

In preparation for the SFO meeting, this is to address the feedback that was 
still open.

Changes:
- Retry before assuming a nameserver is permanently unreachable

Thanks,
Peter


On 7/10/23 22:24, internet-dra...@ietf.org wrote:


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   : Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Author  : Peter Thomassen
Filename: draft-ietf-dnsop-cds-consistency-02.txt
Pages   : 11
Date: 2023-07-10

Abstract:
Maintenance of DNS delegations requires occasional changes of the DS
and NS record sets on the parent side of the delegation.  RFC 7344
automates this for DS records by having the child publish CDS and/or
CDNSKEY records which hold the prospective DS parameters.  Similarly,
RFC 7477 specifies CSYNC records to indicate a desired update of the
delegation's NS (and glue) records.  Parent-side entities (e.g.
Registries, Registrars) typically discover these records by querying
them from the child, and then use them to update the delegation's DS
RRset accordingly.

This document specifies that when performing such queries, parent-
side entities MUST ensure that updates triggered via CDS/CDNSKEY and
CSYNC records are consistent across the child's authoritative
nameservers, before taking any action based on these records.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-02.html

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

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


--
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

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

[DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-02.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   : Consistency for CDS/CDNSKEY and CSYNC is Mandatory
   Author  : Peter Thomassen
   Filename: draft-ietf-dnsop-cds-consistency-02.txt
   Pages   : 11
   Date: 2023-07-10

Abstract:
   Maintenance of DNS delegations requires occasional changes of the DS
   and NS record sets on the parent side of the delegation.  RFC 7344
   automates this for DS records by having the child publish CDS and/or
   CDNSKEY records which hold the prospective DS parameters.  Similarly,
   RFC 7477 specifies CSYNC records to indicate a desired update of the
   delegation's NS (and glue) records.  Parent-side entities (e.g.
   Registries, Registrars) typically discover these records by querying
   them from the child, and then use them to update the delegation's DS
   RRset accordingly.

   This document specifies that when performing such queries, parent-
   side entities MUST ensure that updates triggered via CDS/CDNSKEY and
   CSYNC records are consistent across the child's authoritative
   nameservers, before taking any action based on these records.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-02.html

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

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

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

[Peter Thomassen]

Hi all,

This revision only contains editorial changes from Scott's dnsdir review (plus 
an unclear sentence that I found and fixed).

Thanks,
Peter


On 7/10/23 22:05, internet-dra...@ietf.org wrote:


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   : Automatic DNSSEC Bootstrapping using Authenticated 
Signals from the Zone's Operator
Authors : Peter Thomassen
  Nils Wisiol
Filename: draft-ietf-dnsop-dnssec-bootstrapping-05.txt
Pages   : 16
Date: 2023-07-10

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 deprecates the DS enrollment methods described in
Section 3 of [RFC8078] in favor of Section 3 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 Internet-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-05.html

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

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


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


--
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

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

[DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-05.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   : Negative Caching of DNS Resolution Failures
   Authors : Duane Wessels
 William Carroll
 Matthew Thomas
   Filename: draft-ietf-dnsop-caching-resolution-failures-05.txt
   Pages   : 17
   Date: 2023-07-10

Abstract:
   In the DNS, resolvers employ caching to reduce both latency for end
   users and load on authoritative name servers.  The process of
   resolution may result in one of three types of responses: (1) a
   response containing the requested data; (2) a response indicating the
   requested data does not exist; or (3) a non-response due to a
   resolution failure in which the resolver does not receive any useful
   information regarding the data's existence.  This document concerns
   itself only with the third type.

   RFC 2308 specifies requirements for DNS negative caching.  There,
   caching of type (1) and (2) responses is mandatory and caching of
   type (3) responses is optional.  This document updates RFC 2308 to
   require negative caching for DNS resolution failures.

   RFC 4035 allows DNSSEC validation failure caching.  This document
   updates RFC 4035 to require caching for DNSSEC validation failures.

   RFC 4697 prohibits aggressive requerying for NS records at a failed
   zone's parent zone.  This document updates RFC 4697 to expand this
   requirement to all query types and to all ancestor zones.

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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-caching-resolution-failures-05

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-caching-resolution-failures-05

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


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

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

[Peter Thomassen]

Hi Scott,

On 7/5/23 21:59, Rose, Scott W. (Fed) wrote:

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.

In case some better way of resolving the above occurs to you, please let me 
know.

For now, I've posted the revision (-05) that includes your feedback. Thank you 
very much!

Peter

--
https://desec.io/

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

[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-05.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   : Automatic DNSSEC Bootstrapping using Authenticated Signals 
from the Zone's Operator
   Authors : Peter Thomassen
 Nils Wisiol
   Filename: draft-ietf-dnsop-dnssec-bootstrapping-05.txt
   Pages   : 16
   Date: 2023-07-10

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 deprecates the DS enrollment methods described in
   Section 3 of [RFC8078] in favor of Section 3 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 Internet-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-05.html

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

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


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

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

[Roy Arends]

Ben,

Thanks for this! Comments inline.

> On 23 Jun 2023, at 02:27, 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 reputable resolvers than from unrecognized 
> sources.

Ack

> I think the draft should probably say something like: "To defend against 
> spoofing of source IP addresses used for error reports, reporting resolvers 
> MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC 7873], or another procedure 
> that defeats IP address spoofing."

I’ve added language to this extend. However, I’ll won’t go as far as MUST. I’ve 
made this is a SHOULD (for both TCP and cookie), while the authoritative server 
SHOULD respond with TC bit set to force a re-query over TCP. 

Hope this suffices.

Warmly,

Roy


> --Ben SchwartzFrom: DNSOP  on behalf of Benno 
> Overeinder 
> Sent: Thursday, June 8, 2023 5:59 AM
> To: DNSOP Working Group 
> Cc: DNSOP Chairs 
> Subject: [DNSOP] Working Group Last call for 
> draft-ietf-dnsop-dns-error-reporting
>  !---|
>   This Message Is From an External Sender
> 
> |---!
> 
> Dear DNSOP WG,
> 
> The authors and the chairs feel this document has reached the stage 
> where it's ready for Working Group Last Call.
> 
> This starts a Working Group Last Call for: 
> draft-ietf-dnsop-dns-error-reporting.
> 
> Current versions of the draft is available here: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ .
> 
> The Current Intended Status of this document is: Standards Track.
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please 
> speak out with your reasons.
> Supporting statements that the document is ready are also welcome.
> 
> This starts a two week Working Group Last Call process, and ends on: 
> June 22nd, 2023.
> 
> Thanks,
> 
> -- Benno
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


___
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

[Shivan Kaul Sahib]

Hi folks, we received a bunch of feedback over the last couple of
months that we've addressed in this draft revision.

Some notable things:

   1. We now use the term "domain control validation" instead of "domain
   verification" since that seems to be the industry standard
   2. Make the problem statement clearer in the new Common Pitfalls section
   3. Added new text on delegated domain control validation techniques that
   are often used by CDNs. This technique uses CNAMEs, so we removed the text
   around saying that CNAMEs are NOT RECOMMENDED
   4. Removed strict requirements on the generation of the random token
   5. Clarified that metadata in the validation record is optional
   6. Addressed SECDIR and ARTART early review comments
   7. Clarified scope of validation (i.e. apex vs not)
   8. Cleaned up the Terminology section
   9. Did a bunch of general document refactoring to make the
   recommendations clearer
   10. Added text for DNAME



On Mon, 10 Jul 2023 at 08:59,  wrote:

>
> 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   : Domain Control Validation using DNS
>Authors : Shivan Sahib
>  Shumon Huque
>  Paul Wouters
>Filename: draft-ietf-dnsop-domain-verification-techniques-02.txt
>Pages   : 15
>Date: 2023-07-10
>
> Abstract:
>Many application services on the Internet need to verify ownership or
>control of a domain in the Domain Name System (DNS).  The general
>term for this process is "Domain Control Validation", and can be done
>using a variety of methods such as email, HTTP/HTTPS, or the DNS
>itself.  This document focuses only on DNS-based methods, which
>typically involve the application service provider requesting a DNS
>record with a specific format and content to be visible in the
>requester's domain.  There is wide variation in the details of these
>methods today.  This document proposes some best practices to avoid
>known problems.
>
> The IETF datatracker status page for this Internet-Draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-02.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-02
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Viktor Dukhovni]

On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote:

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

Thanks.  That will be helpful.

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

Appreciated.

> > Requiring cookies would be great, but they have not yet seem broad
> > adoption.  Can we reasonably expect the monitoring agent zones to
> > support them (and ensure consistent cookie keys across the server
> > pool behind each server IP)?
> > 
> > Requiring TCP, combined with per-IP rate limits is probably simpler.
> 
> I will include a note to implementors that reports received over TCP
> will be more reliable. The rate limiting you mentioned can be managed
> by resolver caching, right?

Yes.

> > The proposed qname structure is suboptimal:
> > 
> >- There is insufficient justification for the "_er" labels
> >  at either end of the error report qname.
> > 
> >o  If the monitoring agent wants to see some particular prefix,
> >   (perhaps even periodically rotated to quickly drop stale
> >   junk) the authoritative server can vend the prefix with the
> >   agent domain.  So the "most-significant" parent "_er" is
> >   IMNHSO redundant.
> 
> The monitoring agent has to determine where the QNAME ends, and the
> agent domain starts. If you assume that a monitoring agent only uses a
> single agent domain for all its reports, then sure, the _er_ label
> between the strings is redundant.
> 
> If however, the monitoring agent has domains in use, where the least
> significant labels collide with existing top level domains, it needs
> to determine heuristically where the agent domain starts. This is IMHO
> suboptimal.

Right, but surely the monitoring agent can decide whether to solicit
such a prefix label or not.  That is whether an "_er" prefix label is
signalled is a *local matter* betweent the authoritative server
signalling the option and the monitoring agent.  Why should resolvers
have to be responsible for this?  If a given monitoring agent does
not need such signalling, what value does it add?

> >o The leading "least-significant" "_er" is likewise (see below)
> >  not adequately justified.
> 
> The sole purpose of the leading “least-significant” “_er” is to
> distinguish between qname-minimized queries (for lack of a better
> term) and “full” queries. I understand that you argue that a
> monitoring agent can determine this without the _er labels (as
> described below), but that seem suboptimal to me.

The qname minimised query (whether or not a dedicated qtype is used)
will be for "A" or "NS" records, not TXT or the dedicated qtype, so
there's no need for "_er" in the first label, the qtype is sufficient.

> > Also, qtypes are cheap, and I rather think that a dedicated qtype (one
> > that a supporting resolver might refuse to accept in queries from
> > clients for example) makes sense here.  There's no need to overload
> > TXT here.
> 
> This seems counter intuitive to me. A qtype that a supporting resolver
> might refuse to accept in queries from clients is either a temporary
> state (it may be accepted in the near future when this qtype will be
> implemented), or it needs to be specified that this qtype should not
> be accepted in queries from clients, which makes this qtype not cheap
> (that is, we won’t be able to simply use the template to request one,
> as it requires additional work). 

There's no need to require that it not be accepted from clients, but
it is easier to do that with a dedicated qtype.  It can be added to:

- RRSIG (semantically vacuous sans the associated RRset)
- NSEC3 (not part of the zone's qname namespace).
- ANY (if that's what the resolver chooses to do).

However, to avoid forwarding junk reports to the monitoring agent, a
resolver may well sensibly choose to not forward such queries, and
only source them internally.

The specification might also recommend that "stub" resolvers that
forward most queries to a "full service" resolver, should send error
reports *directly* to the monitoring agent.  And, of course, "full
service" resolvers MUST NOT *forward* the monitoring agent OPTION to
clients, if they send such an option, it should be locally generated
to signal the monitoring agent for the resolver itself.

> Allocating a new QTYPE for this purpose just seems redundant. 

It is not.  This is not a normal query, it is an error report.

> >> This document gives no guidance on the content of the TXT resource
> >> record RDATA for this record.
> > 
> > The dedicated

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

[Roy Arends]

Hi Yaron,

> On 9 Jul 2023, at 18:27, Yaron Sheffer  wrote:
> 
> Hi Roy,
> 
> Please see some responses below, prefixed with YS.
> 
> Thanks,
> Yaron
> 
> On 05/07/2023, 14:31, "Roy Arends" mailto:r...@dnss.ec>> 
> wrote:
> 
> 
> 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)
> 
> YS: I'm not sure I understand the proposed text, because the draft does not 
> provide a way (namely, authentication) to establish a "known, trusted set of 
> resolvers". Unless there's a way to authenticate these reports that I'm not 
> familiar with.

In general, resolvers do not cryptographically authenticate themselves to 
authoritative servers. What remains is to make sure that the source address is 
not spoofed. One method to make spoofing harder is for the auth-server to reply 
with a response containing a TC bit and challenge the resolver to re-query 
(re-send the error report) over TCP. In addition, some of these source 
addresses may be well known to the monitoring agent.

I’ll add some text around this.

> 
>> - 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.
> 
> YS: understood. It just seems to me that we're not providing the agent with 
> enough input for this analysis. And I guess I was suggesting to add a 
> feature: aggregated (or random, sample based) reporting on *successful* name 
> resolution.

I’m not convinced this feature is a good idea.

> 
>> - 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?
> 
> YS: fair enough.
> 
>> - 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?
> 
> YS: even if you deem DNSSEC policy to be out of scope, the question about 
> normative language still stands. Or at least guidance on when this mitigation 
> is recommended.

Will add.

Thanks Yaron!

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

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

[Barry Leiba]

Thanks, Shivan, for addressing my comments.

Barry

On Mon, Jul 10, 2023 at 12:04 PM Shivan Kaul Sahib
 wrote:
>
> Hi Barry, we've uploaded a new version that should address your helpful 
> comments: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
>
> On Mon, 3 Apr 2023 at 00:38, Barry Leiba via Datatracker  
> wrote:
>>
>> Reviewer: Barry Leiba
>> Review result: Ready with Nits
>>
>> This is short and reasonably sweet, easily digested.  I have a few minor
>> comments that I think will help make the document slightly clearer, and I 
>> hope
>> you'll consider them:
>>
>> — Section 3.1 —
>>
>> I think this is generally understandable, but reuse of “it” does allow room 
>> for
>> error.  I suggest avoiding vagueness, possible ambiguity, and 
>> misunderstanding
>> as follows:
>>
>> OLD
>>1.  Generate a Random Token with at least 128 bits of entropy.
>>
>>2.  Take the SHA-256 digest output [SHA256] of it.
>>
>>3.  base64url encode it.
>>
>> NEW
>>1.  Generate a Random Token with at least 128 bits of entropy.
>>
>>2.  Create a SHA-256 digest [SHA256] of the Random Token.
>>
>>3.  base64url encode the SHA-256 digest.
>>
>> END
>>
>> (And you might include RFC 4648 as a reference for base64url encoding.)
>>
>> One thing that I do find unclear is this:
>>
>>Providers MUST provide clear instructions on when a verifying record
>>can be removed.  The user SHOULD de-provision the resource record
>>provisioned for a DNS-based domain verification challenge once the
>>one-time challenge is complete.  These instructions SHOULD be encoded
>>in the RDATA via comma-separated ASCII key-value pairs [RFC1464]
>>using the key expiry.  If this is done, the token should have a key
>>token.  For example:
>>
>> _foo-challenge.example.com.  IN   TXT
>> "token=3419...3d206c4,expiry=2023-02-08T02:03:19+00:00"
>>
>> First: It’s unclear how a one-time challenge fits in with an “expiry” key.  
>> Is
>> it meant to be the case that lack of an “expiry” key means that the “token” 
>> is
>> meant for one-time use, and presence of “expiry” makes it time-based?  Or
>> something else?  I think this could be clearer.
>>
>> Second: “the token should have a key token” confused me until I finally
>> realized that you ought to be using quotes to identify the key names, thus:
>>
>> NEW
>>These instructions SHOULD be encoded
>>in the RDATA via comma-separated ASCII key-value pairs [RFC1464]
>>using the key “expiry”.  If this is done, the token should have a key
>>“token”.
>> END
>>
>> That makes it clearer that the key names are not just words in the 
>> explanatory
>> text.
>>
>> — Section 3.2 —
>>
>> In the newspaper business, what you’ve done here is called “burying the 
>> lede”.
>> I suggest instead, leading with the recommendation and following with the
>> reasoning:
>>
>> NEW
>>Because CNAME records cannot co-exist with any other data, it is
>>NOT RECOMMENDED to use CNAMEs for DNS domain verification.
>>
>>Reasoning: What happens when both a CNAME and other records exist
>>depends on the DNS implementation, and might break in unexpected
>>ways.  If a CNAME is added for continuous authorization, and for
>>another service a TXT record is added, the TXT record might work but
>>the CNAME record might break.  Another issue with CNAME records is
>>that they must not point to another CNAME.  But while this might be
>>true in an initial deployment, if the target that the CNAME points to
>>is changed from a non-CNAME record to a CNAME record, some DNS
>>software might no longer resolve this as expected.  However, when
>>using a properly named prefix, existing CNAME records should never
>>conflict with regular CNAME records.
>> END
>>
>> Thanks,
>> Barry
>>
>>

___
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

[Shivan Kaul Sahib]

Hi Ben, thanks again for your comments! We've uploaded a new version that
takes them into account.

On Wed, 19 Apr 2023 at 17:40, Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Benjamin Kaduk
> Review result: Has Issues
>
> # SecDir review of draft-ietf-dnsop-domain-verification-techniques-01
> CC @kaduk
>
> ## Discuss
>
> ## Comments
>
> I'm a little nervous about allocating a new BCP number for a topic of
> fairly
> narrow scope such as this, but the guidance is good and worth publishing,
> and
> I have not better alternative to offer, so I will stifle any objection I
> might
> have raised.
>
> On the whole the content is reasonable, but read on for some suggestions on
> how to tighten things up and some questions about why all the pieces are
> needed.
>
> I also made a PR with some editorial suggestions,
>
> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/51
>
> ### Continuing Ownership
>
> While I see the example in Appendix A.1.4.1 about Atlassian, when we say in
> the introduction that sometimes the DNS record must be kept in the zone to
> prove continued ownership of the domain, that doesn't exactly seem to hold
> true, or at least only provides a weak indication of continued ownership.
> I
> think that to really prove continued ownership the challenge would need to
> be
> rotated periodically; just putting one record in once and leaving it there
> mostly only shows that you had control of the domain at the one point in
> time
> it was added and that there isn't anything cleaning up old records.  A
> wholesale migration of the domain to a different DNS server would clean up
> old
> records, but staffing changes within a large organization would not.
>
> ### Underscore for attrleaf
>
> In §3.1 we say "The provider constructs the validation domain name by
> prepending a provider-relevant prefix followed by "-challenge" to the
> domain
> name being validated (e.g. "_foo-challenge.example.com")." which
> implicitly
> uses an underscore-prefixed atterleaf name component.  Is the underscore
> part
> of the required or recommended behavior?
>
> ### Hashing the random token
>
> The recommendations in §3.1 requires computing the SHA-256 digest of the
> Random Token before base64url encoding and use as RDATA, but provides no
> justification for the SHA-256 step that I can see.  If the intent is for
> the
> Random Token to be a non-public identifier for the challeng with only the
> digest value being public, we should say that.  Otherwise it's not clear
> what
> we gain over just using base64url(random-data) as the RDATA.
>
> ### TXT RDATA contents
>
> We say that the RDATA of the recommended TXT resource record construction
> must
> "contain" a certain token construction (rather than "consist of").  Does
> the
> format/structure of the RDATA also need to be one that unambiguously
> identifies where the token is (or is a raw substring match sufficient)?
>
> I think we might provide clearer guidance if we laid out the recommended
> comma-separated key-value format first and talked about the token=
> contents,
> and then only afterward mention that even if other formats are used, the
> RDATA
> MUST contain the token value (and whether it must be identifiable as such
> via
> some metadata).  Or we could state up front what properties we want from
> the
> RDATA before going on to describe how we achieve those properties.  But the
> current formulation starts out with a MUST-level requirement without much
> context and then tries to build the context around it, which tends to cause
> confusion in the reader.
>
> Reading again, I think that the core of what is confusing me here is that
> the
> SHOULD-level guidance for using the comma-separated key-value pair format
> is
> buried as an aside in the mechanism for conveying the instructions for
> removing a resource record.  It seems like it's a more generic
> recommendation
> and should be framed as such.
>
> ### Instructions for TXT record removal
>
> We say
>
> > Providers MUST provide clear instructions on when a verifying record
> > can be removed.  The user SHOULD de-provision the resource record
> > provisioned for a DNS-based domain verification challenge once the
> > one-time challenge is complete.  These instructions SHOULD be encoded
> > in the RDATA via comma-separated ASCII key-value pairs [RFC1464]
> > using the key expiry.  If this is done, the token should have a key
> > token.  For example:
>
> I think that the "these instructions" refers to the "clear instructions"
> provided by the provider.  But the TXT record is something provisioned by
> the
> user, not the provider.  If the instructions are to be encoded in the
> RDATA,
> does that require that the RDATA contents themselves are provided by the
> provider to the user?  I'd strongly recommend including some more
> description
> of the workflow that's envisioned if it includes the provider giving the
> user
> the entire RDATA contents to

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

[Shivan Kaul Sahib]

Hi Barry, we've uploaded a new version that should address your helpful
comments:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/

On Mon, 3 Apr 2023 at 00:38, Barry Leiba via Datatracker 
wrote:

> Reviewer: Barry Leiba
> Review result: Ready with Nits
>
> This is short and reasonably sweet, easily digested.  I have a few minor
> comments that I think will help make the document slightly clearer, and I
> hope
> you'll consider them:
>
> — Section 3.1 —
>
> I think this is generally understandable, but reuse of “it” does allow
> room for
> error.  I suggest avoiding vagueness, possible ambiguity, and
> misunderstanding
> as follows:
>
> OLD
>1.  Generate a Random Token with at least 128 bits of entropy.
>
>2.  Take the SHA-256 digest output [SHA256] of it.
>
>3.  base64url encode it.
>
> NEW
>1.  Generate a Random Token with at least 128 bits of entropy.
>
>2.  Create a SHA-256 digest [SHA256] of the Random Token.
>
>3.  base64url encode the SHA-256 digest.
>
> END
>
> (And you might include RFC 4648 as a reference for base64url encoding.)
>
> One thing that I do find unclear is this:
>
>Providers MUST provide clear instructions on when a verifying record
>can be removed.  The user SHOULD de-provision the resource record
>provisioned for a DNS-based domain verification challenge once the
>one-time challenge is complete.  These instructions SHOULD be encoded
>in the RDATA via comma-separated ASCII key-value pairs [RFC1464]
>using the key expiry.  If this is done, the token should have a key
>token.  For example:
>
> _foo-challenge.example.com.  IN   TXT
> "token=3419...3d206c4,expiry=2023-02-08T02:03:19+00:00"
>
> First: It’s unclear how a one-time challenge fits in with an “expiry”
> key.  Is
> it meant to be the case that lack of an “expiry” key means that the
> “token” is
> meant for one-time use, and presence of “expiry” makes it time-based?  Or
> something else?  I think this could be clearer.
>
> Second: “the token should have a key token” confused me until I finally
> realized that you ought to be using quotes to identify the key names, thus:
>
> NEW
>These instructions SHOULD be encoded
>in the RDATA via comma-separated ASCII key-value pairs [RFC1464]
>using the key “expiry”.  If this is done, the token should have a key
>“token”.
> END
>
> That makes it clearer that the key names are not just words in the
> explanatory
> text.
>
> — Section 3.2 —
>
> In the newspaper business, what you’ve done here is called “burying the
> lede”.
> I suggest instead, leading with the recommendation and following with the
> reasoning:
>
> NEW
>Because CNAME records cannot co-exist with any other data, it is
>NOT RECOMMENDED to use CNAMEs for DNS domain verification.
>
>Reasoning: What happens when both a CNAME and other records exist
>depends on the DNS implementation, and might break in unexpected
>ways.  If a CNAME is added for continuous authorization, and for
>another service a TXT record is added, the TXT record might work but
>the CNAME record might break.  Another issue with CNAME records is
>that they must not point to another CNAME.  But while this might be
>true in an initial deployment, if the target that the CNAME points to
>is changed from a non-CNAME record to a CNAME record, some DNS
>software might no longer resolve this as expected.  However, when
>using a properly named prefix, existing CNAME records should never
>conflict with regular CNAME records.
> END
>
> Thanks,
> Barry
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.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   : Domain Control Validation using DNS
   Authors : Shivan Sahib
 Shumon Huque
 Paul Wouters
   Filename: draft-ietf-dnsop-domain-verification-techniques-02.txt
   Pages   : 15
   Date: 2023-07-10

Abstract:
   Many application services on the Internet need to verify ownership or
   control of a domain in the Domain Name System (DNS).  The general
   term for this process is "Domain Control Validation", and can be done
   using a variety of methods such as email, HTTP/HTTPS, or the DNS
   itself.  This document focuses only on DNS-based methods, which
   typically involve the application service provider requesting a DNS
   record with a specific format and content to be visible in the
   requester's domain.  There is wide variation in the details of these
   methods today.  This document proposes some best practices to avoid
   known problems.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-02

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

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

[Paolo Volpato]

Dear WGs,

After following the cross-WGs discussion, I am favor of adopting this draft.
It focuses on a specific case (that may be generalized in future works), but I 
think that it provides a good description of the issue and a valid operational 
approach.

BR
Paolo

From: v6ops  On Behalf Of Momoka Yamamoto
Sent: Sunday, July 9, 2023 11:48 AM
To: list ; dnsop 
Subject: Re: [v6ops] [DNSOP] WG call for adoption: 
draft-momoka-v6ops-ipv6-only-resolver-01

Dear All,

Thank you for your constructive feedback and the rich discussion that has 
followed the sharing of the draft. I've taken the time to digest all your 
comments.

Concerning the DNS64 breaking DNSSEC issue:
As Philip rightfully pointed out, the inclusion of DNS64 in this draft has 
indeed been misleading, and I will amend it by removing references to DNS64. 
DNSSEC is an important topic but this proposal doesn't directly interact with 
DNS64, hence the DNSSEC issues associated with DNS64 are out of its scope.

Regarding the specificity of DNS resolvers when RFC7051 exists, there is a 
diverse range of opinions on this topic on list, some arguing the necessity of 
such documentation and others deeming it redundant. Some considerations I think 
are important include:
* A resolver is one of the few applications that have a genuine requirement to 
use an IPv4 literal.
* The inability of an iterative resolver to utilize RFC7050 for Pref64 
discovery may be worth highlighting.
* While 464XLAT has demonstrated its effectiveness in home networks supporting 
various apps and devices, the situation is different for DNS servers with more 
uniform tasks. In these cases, executing the translation within the resolver 
software could be more efficient.
The process of the iterative resolver creating an IPv4 socket, which is then 
translated to an IPv6 packet by the CLAT, is inefficient as it adds an 
unnecessary layer of packet translation.
* However, considering instances like Thread and other applications such as 
browsers, which already implement the synthesizing function, a draft dedicated 
to iterative resolvers may seem repetitive.

Concerning the appropriate Working Group for this draft:
While there is ongoing debate about whether this draft should be adopted or 
not, I did not find any strong opinions stating that this draft should be 
conducted at DNSOP.
Furthermore, as Med proposed, BCP 91 could be updated, 19 years 
post-publication, to include these solutions for IPv6-only networks.

For a more comprehensive and balanced draft, future steps will include removing 
references to DNS64 and incorporating both the 464XLAT and Pref64 solutions.
For those unable to transition to 464XLAT promptly, having the resolver execute 
the translation will act as an essential bridge. This, however, does not 
preclude the consideration of 464XLAT as a potential future strategy.
This approach aims to provide well-rounded guidance, assisting in better 
decision-making.

I look forward to further discussions and appreciate your feedback on these 
matters.

Best Regards,

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

[DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-14.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-14.txt
   Pages   : 13
   Date: 2023-07-10

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

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

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

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

[mohamed . boucadair]

Hi Gert,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Gert Doering 
> Envoyé : lundi 10 juillet 2023 08:53
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Ted Lemon ; v6...@ietf.org; Xipengxiao
> ; dnsop 
> Objet : Re: [v6ops] DNS64/Thread RE: [DNSOP] WG call for adoption:
> draft-momoka-v6ops-ipv6-only-resolver-01
> 
> Hi,
> 
> On Fri, Jul 07, 2023 at 01:19:38PM +,
> mohamed.boucad...@orange.com wrote:
> > For your last point: problems may arise if a distinct pref64 is
> used
> > by the upstream DNS64 than the one used locally. Unless I???m
> > mistaken, we currently don???t have a solution to detect
> mismatches
> > between what is used by a local NAT64 and an upstream DNS64 let
> alone
> > whether an upstream resolver is also performing DNS64. I used to
> have
> > a proposal for this:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> data
> > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-dnsop-prefix64-
> 02&data
> >
> =05%7C01%7Cmohamed.boucadair%40orange.com%7C156480ca56e144dd3c7708
> db81
> >
> 125189%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824568789974
> 8586
> >
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6I
> >
> k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7hwX%2Bwnur4AnRNpe9LCY
> lWNR
> > jDC5Sk%2BCnzSpTZNmqi0%3D&reserved=0
> 
> I would assume that it just does not matter if there are two NAT64
> boxes available, with different prefixes. Depending on which
> prefix you use for the IPv6 synthesis, your packets will use one
> or the other to be translated - which is actually one of the
> brilliant aspects of NAT64, that it does not need to be in the
> "non NAT" packet flow.

[Med] Yes, but not sure this is relevant to the point above.

> 
> Same for "having two DNS64 in sequence" - while unusual, it will
> still work.

[Med] I'm afraid not. Failure will be observed if there are no on-path NAT64 
that uses the prefix used by these DNS64. 

  The first DNS64 to see the IPv4-only reply will do
> synthesisis, the second DNS64 will see an IPv6 answer, and won't
> have to do anything except "forward".  If they agree on the NAT64
> prefix, packets will use the same NAT64 gateway in any case, if
> not, see above.
> 
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG  Vorstand: Sebastian v. Bomhard,
> Michael Emmer
> Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-
> Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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