[DNSOP] Approved: draft-ietf-dnsop-avoid-fragmentation

[Warren Kumari]

Hi there Authors, IESG, WG, and Secretariat,

draft-ietf-dnsop-avoid-fragmentation - "IP Fragmentation Avoidance in DNS
over UDP"
 is
now approved.

I'd like to thank everyone, especially the authors and Benno Overeinder,
for all of their diligent hard work to get this done.

This document was rough one, and sat in my queue for an exceptionally long
time while we got agreement on how to address the last set of concerns.

I'd like to thank everyone again for their collegiate attitude, willingness
to hear and consider each other's viewpoints, and patience.

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

[DNSOP] Re: I-D Action: draft-ietf-dnsop-avoid-fragmentation-19.txt

[Warren Kumari]

On Fri, Sep 20, 2024 at 7:44 AM, Štěpán Němec  wrote:

> Some minor (editorial) issues I noticed in the current (19) draft:
>


Thank you very much everyone - this document has been a long time in the
making.

As mentioned in the document: "This document was originally intended to be
a BCP, but due to operating system and socket option limitations, some of
the recommendations have not yet gained real-world experience and therefore
the document is published as Informational.  It is hoped and expected that,
as operating systems and implementations evolve, we will gain more
experience with the recommendations, and plan to publish an updated
document as a Best Current Practice."

I'd like to specifically thank the authors (Paul and Fujiwara-san), and
Benno, and the implementers for large amounts of constructive discussion,
and willingness to compromise to get to this position. I hope that we will
soon be able to publish RFC-bis as a BCP with definitive, tested
solutions and advice for fragmentation.

I'd like to request that the authors incorporate these last few editorial
comments (to make the RFC Editors life easier), and then I will ship it.

Much thanks again to everyone,
W


> 3.1
>
> R4. If the UDP responder detects an immediate error indicating that the
> UDP packet cannot be sent beyond the path MTU size, the UDP responder may
> recreate response packets fit in the path MTU size, or with the TC bit set.
>
> s/packets fit/packets that fit/ ? Or perhaps "to fit"?
>
> I also find "the UDP packet cannot be sent beyond the path MTU size" hard
> to interpret (specifically the "sending beyond the path MTU size" part), do
> you mean "packet exceeds the path MTU size"?
>
> 3.2. Proposed Recommendations for UDP requestors
>
> R5. UDP requestors should limit the requestor's maximum UDP payload size
> that fit in the minimum of the interface MTU, the network MTU value
> configured by the knowledge of the network operators, and the RECOMMENDED
> maximum DNS/UDP payload size 1400. A smaller limit may be allowed. (See
> Appendix A for more information.)
>
> s/that fit/to fit/ ?
> s/by the knowledge of the network operators/by the network operators/ ? Or
> perhaps "according to the knowledge of the network" (not operators)?
>
> 4. Proposed Recommendations for DNS operators
>
> Large DNS responses are typically the result of zone configuration. People
> who publish information in the DNS should seek configurations, resulting in
> small responses.
>
> The comma makes no sense here (should be dropped).
>
> 7.1. On-path fragmentation on IPv4
>
> If the Don't Fragment (DF) bit is not set, on-path fragmentation may
> happen on IPv4, and be vulnerable, as shown in Section 7.3. To avoid this,
> recommendation R6 need to be used to discard the fragmented responses and
> retry by TCP.
>
> s/be vulnerable/lead to vulnerabilities/ ?
> s/R6 need/R6 needs/ (or "should")
>
> 7.3. Weaknesses of IP fragmentation
>
> [...]
> "Domain Validation++ For MitM-Resilient PKI" [Brandt2018] proposed that
> off-path attackers can intervene in the path MTU discovery
> [RFC1191] to perform intentionally fragmented responses from authoritative
> servers.
>
> I didn't manage to obtain free access to the paper in the limited time I
> was willing to spend on the matter, but the way such papers are usually
> written is they describe attacks and propose solutions, not the other way
> round (and the abstract[1] seems to confirm that prejudice), so:
>
> s/proposed/noted/ ?
>
> And perhaps also rather "cause authoritative servers to return/produce
> fragmented responses"?
>
> [...]
> due to the small amount of entropy provided by UDP port numbers and DNS
> message identifiers, each of which being only 16 bits in size, and both
> likely being in the first fragment of a packet if fragmentation occurs.
>
> s/each of which/both/
>

Actually, I think that the original is better; to me "both" makes the
sentence ambiguous (could be read as "UDP port numbers are 16 bit, and DNS
message identifiers are 16 bit" or "added together (both) UDP port numbers
and DNS message identifiers are 16 bits").


> 7.5. Possible actions for resolver operators
> [...]
> Specifically, config the firewall functions before the full-service
> resolver to discard incoming DNS response packets
>
> s/config/configure/
> s/before/in front of/ ? Or "protecting", to avoid any spacial vs. temporal
> ambiguity?
>
> Appendinx A.
> [...]
> in the interior of the
> Internet between recursive resolvers and authoritative servers the
> prevailing MTU is at 1,500
>
> I realize this comes verbatim from the report text[2], but for
> consistency/PoLA I suggest s/is at 1,500/is 1500/ (with all the numbers and
> plus/minus/maximum/at least flying around in the document I was at first
> wondering if "least" might be missing after "at", and the comma is
> distracting at best). Failing that, add quotation marks so that it is clear
> that this is a quote from another document (following different style).
>

[DNSOP] Re: [EDE] Registering a few more error codes

[Warren Kumari]

On Wed, Sep 11, 2024 at 9:22 AM, Stephane Bortzmeyer 
wrote:

> In the current registry for Extended DNS Error Codes (RFC 8914), there are
> codes that may be interesting to add:
>
> * One to say that the response was deliberately minimal (RFC 8482)
> * One to say that the response comes from a local root (RFC 8806)
> * One to say that the response has been tailored because of ECS (RFC 7871)
> [the most useful, IMHO]
>
> I am thinking about asking for a registration. Policy for this registry is
> "first come, first served". Before I start sending email to IANA, I ask
> your advice. Is it a good idea?
>


H. I'm not really sure….
The last one seems like a valuable bit of information.
The first one seems less interesting, but possibly still useful.
I don't really see the point / utility of the middle one, but it's entirely
likely that I'm missing something.

I think that there is a tradeoff between A: providing useful operational
and debugging information and B: additional software complexity and larger
response sizes.

It sort of feels like the EDE document should have included a mechanism for
a client to signal "I'm trying to debug something weird, please send me all
possible information that you have", and then we could have reserved a set
of codepoints for "Random other bits which are only interesting  to DNS
geeks, and only intended for human consumption". This could include things
like 'the actual server that answered' (some NSID systems only lists the
"load-balancer"/anycast site), zone version (see zoneversion :-)), if the
answer came from disk or is secretly forwarded, if the answer is "static"
or dynamically sourced / wildcard expanded, quote of the day, what's for
lunch, etc.

It also seems like there are some set of error codes which I'd be fine
shipping over a TCP connection, but which I don't want to waste UDP bits
on….

W


Will the authors of resolver / authoritative software use it?
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Dnsdir telechat review of draft-ietf-dnsop-rfc7958bis-05

[Warren Kumari]

On Mon, Sep 02, 2024 at 4:01 AM, Petr Špaček  wrote:

> Reviewer: Petr Špaček
> Review result: Ready with Issues
>
> I was assigned as the dnsdir reviewer for draft-ietf-dnsop-rfc7958bis-05.
> For more information about the DNS Directorate, please see https://wiki.
> ietf.org/en/group/dnsdir
>


Thank you very much for the DNSDIR review, and for following up!



> Philosophical questions of what the document is or should do are out of
> scope, see
> https://mailarchive.ietf.org/arch/msg/dnsop/Lmmz5BoKb5AjMHNfQL1HfXayeJM/
>
>

Thank you!


>
> The most visible change in -05 is moving paragraphs to Security
> Considerations. The result reads better than -04.
>
> Version -05 introduced a _new_ problem:
> In section 2.3. XML Example the  was added to the
> XML _but_ this change was NOT reflected in the paragraph following the XML.
> It starts with text "The DS record derived from this example would be:".
>
> Either a DS RR is missing, or the text needs to specify a timestamp which
> is before validFrom for the newly added key. I think an explicit timestamp
> is in order anyway.
>
> To make things faster here is a proposal with fixed text:
> -
> DS records derived from this XML example on 2024-08-01 would be:
> . IN DS 20326 8 2
> E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
> . IN DS 38696 8 2
> 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
> -
> (Someone please double-check ...)
>
>
Doh! Yes, it looks like this was missed. Thank you for noticing it — I have
not checked the DS's, but yes, these should be fixed…



> Because -05 contains a factual problem and needs an update anyway I'm
> going to remind authors that -06 is an opportunity to fix other trouble
> pointed out in review of -04.
>
> It's unclear why -05 did not react to some of the previous review comments
> related to examples in -04. Given the lack of an explicit answer I'm going
> to assume it's omission caused by confusing threading.
>


Yes, I suspect that this was a threading issue.


> The only point I'm going to reiterate is
> https://mailarchive.ietf.org/arch/msg/dnsop/rbOyxQ5JCZCOQ5lj3TsFHqTnUbQ/
> - the point marked as "C.", further explained in https://mailarchive.ietf.
> org/arch/msg/dnsop/RXdry2-vzn7uvV1V6i17AjKapJ0/
>
> TL;DR version: DNSKEY example is really missing, along with suitable
> Security Considerations! The DNSKEY example was already present in -03 but
> got lost in -04. I don't understand why.
>
> To expedite things here is a proposal how to fill in the missing bits of
> text here. Hopefully it will not fall through cracks between -05 and -06:
>
> ... to be put after "DS records derived from this XML example on"
> paragraph in 2.3 XML Example ...
> -
> DNSKEY record derived from this XML example on 2024-08-01 would be:
> . IN DNSKEY 257 3 8
> AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
> +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
> ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
> 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
> oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
> RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=
>
> Please note the inconsistency between DS and DNSKEY sets above. DNSKEY
> record for KSK-2024 cannot be reconstructed from KeyDigest element
> id=Kmyv6jo because it does not contain the optional publickeyinfo element.
> -
> (Someone please double-check ...)
>
>
Yup. I have not double-checked, but yes, this seems to have fallen out
accidentally in editing.


This extended 2.3 XML Example should be complemented by an additional
> paragraph in Security Considerations. Something like:
> -
> Relying parties which depend on the optional publickeyinfo element are at
> risk of not seeing TAs published without this optional element.
> Consequently different parties who ingest the same XML at the same time can
> produce different set of trust anchors.
> -
>
>
That seems like a great addition! Authors, please integrate these.

Thank you very much!
W

I assume authors consider this property of the XML format acceptable. I
> personally don't like it, but if everyone else is okay with it I will not
> press further for mandatory publickeyinfo element.
>
> --
> Petr Špaček
>
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Warren Kumari]

On Thu, Aug 29, 2024 at 6:21 PM, Michael StJohns 
wrote:

> On 8/29/2024 4:24 PM, Paul Hoffman wrote:
>
> On Aug 27, 2024, at 16:46, Warren Kumari  
>  wrote:
>
> Thank you very much for your comments. We've had some discussions, and the 
> authors will be publishing a new version in the next few days addressing 
> these.
>
> As you can see, we have turned in -05. We think this deals with the comments 
> from Petr and Mike. In the diff, you can see that we moved all things that 
> said what a relying party who accepts the trust anchor file MUST/SHOULD do to 
> the Security Considerations; this puts them in one place and gives the 
> context for them. We also added some text about how to do the comparison for 
> the two fields (referring to the specific part of RFC 4034 that they need).
>
> Given that this is still in your (Warren's) two hands, not the WG's many 
> hands, let us know if you need any more changes before the assigned telegchat.
>
> --Paul Hoffman (for the authors)
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
> Hi -
>
> Took a brief look at -05.  Still problems unaddressed.  Section 2.2 6th
> paragraph:
>
>
>The validFrom and validUntil attributes in the KeyDigest element
>specify the range of times that the KeyDigest element can be used as
>a trust anchor.
>
>
> "can be used as a trust anchor" is problematic as it appears to be
> directive on the recipient.   As I've said - now at least three times -
> please change this language so it represents what the IANA is doing, not
> what the recipient should do.  Among other things, specifying a
> "validUntil" date on a trust anchor and then NOT ceasing to use that trust
> anchor and not "replacing" it is problematic.
>
> Instead replace this paragraph with:
>
> "The validFrom attribute in the KeyDigest element indicates the first
> planned date that the IANA intends to start signing the root DNSKEY RRSet
> with this key.  Likewise, the validUntil attribute indicates the last
> planned date of such signing.  However, these are for planning purposes
> only and relying parties should not automatically invoke a state change on
> a trust anchor based on these dates as operational considerations may
> result in a delay past these dates."
>


Yes, you have stated this multiple times; however, I believe you are in the
rough. The IANA has reviewed this text (which is identical in the original
RFC, RF7958), and the validUntil is intended to mean exactly what it
says:  the material is validUntil then, and is not intended to be used
after that. Yes, this does mean that the IANA has to publish new keys
before then, and it is an error if they don't. This is just like any other
trust anchor — e.g my machine ships with a "Baltimore CyberTrust Root" cert
in the trust store, which is Not Valid After Monday, May 12, 2025 at
7:59:00 PM Eastern Daylight Time. This is when it stops being valid, not
necessarily when they hope to have replaced it by…

Yes, I might *personally* decide to use the IANA TA after the validUntil if
they haven't published a new one. If I did, that would be entirely my own
(bad) decision, and I'm clearly doing something unsupported… just like if I
happen to eat a can of beans past their expiration date…


Section 4 - nit - generally we don't have single entry subsections.
>
>
> Delete section 4.1.1 - continues to be a problem if IANA fails to
> supercede a trust anchor on the planned schedule.
>


As above -- the validUntil is not the planned schedule; it is when the key
is validUntil.


> It is directive on the relying party in a way that could cause operational
> difficulties - to wit - iana actually continuing to sign with the set of
> trust anchors past their validUntil dates.  There is also no such thing as
> "change to a trust anchor" in DNSSEC.  All trust anchors are equally valid
> until revoked or removed.
>
> Delete the third paragraph of section 5.
>
> In section 5, replace the first sentence with:
>
> "The intent is for the IANA to publish trust anchors using this format at
> least <6> months before the first use of a new trust anchor.  The intent is
> also that the published document will include all DNSSEC trust anchors for
> the root zone that are currently under management (e.g. generated and
> loaded for use within a key signing ceremony but not revoked) by the IANA
> at the time of publication."
>
> Second paragraph - lower case the "may" - people are mostly not protocol
> elements, although the DNS crowd seems to think so.  Also, add "Also for
> oper

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Warren Kumari]

On Mon, Aug 26, 2024 at 11:51 AM, Petr Špaček  wrote:

> Hi everyone,
>
>
>
Hi everyone!

Thank you very much for your comments. We've had some discussions, and the
authors will be publishing a new version in the next few days addressing
these.

In addition, I will be deferring the IESG Evaluation / Balloting from this
telechat/cycle to the following one. I would really like to get this
published soon (so that the IANA can use it), but the document will benefit
from some more clarity / polish.

Thank you all very much again,
Warren.


I'm responding only to Paul's reaction to my previous comments.
>
> I don't want discuss IANA operational procedures here so I tried to focus
> on the XML and it's consumers.
>
> On 21. 08. 24 0:20, Paul Hoffman wrote:
>
> On Aug 10, 2024, at 08:21, Michael StJohns 
> wrote:
>
> On 8/9/2024 5:09 PM, Paul Hoffman wrote:
>
> On Aug 9, 2024, at 12:16, Michael StJohns  wrote:
>
> On Aug 15, 2024, at 02:43, Petr Špaček  wrote:
>
> I've re-reviewed the -04 version. It addresses the major problem of the
> format - the inability to represent some DNSSEC TAs.
>
> -04 changes resulted in some omissions in the new text, see below.
>
> 2.3. XML Example
>
> Between versions -03 and -04 we have lost text with explicit instructions
> how to reconstruct text representation of DS and DNSKEY. I'm fine with
> doing it in the new section 2.3 but there are two omissions in the -04
> text:
>
> A.
> Missing example of DNSKEY RR reconstruction. It was formerly present in
> the draft -03 section 2.4. Most notably -04 text is missing instruction
> about DNSKEY "Protocol" field which is not represented in the XML.
>
> I think it needs a reference to RFC 4034 section 2.1.2 and an unambiguous
> instruction that constant "3" needs to be put in place of the Protocol
> field of the DNSKEY RR under (re)construction.
>
> B.
> Missing instruction about implicit class "IN". RFC 4034 defined all RR
> types as class-independent. I think it's fine to say "add constant 'IN' and
> be done with this", but I'm not aware of any RFC which would say that
> non-IN classes are not to be ever used.
>
> I'm not understanding the threat model here. Are you saying that there
> might be validating resolvers who need a properly formatted DNSKEY record,
> but don't know how to put one together using the publickeyinfo? People
> wanted the document to be simpler, so we took out what was basically a
> restatement of RFC 4034.
>
> I did not mean to imply any security threat.
>
> It's simply that reader of the document cannot immediately see why certain
> fields of DNSKEY are not defined in the XML and their values have to be
> pulled out of thin air with no explicit instructions.
>
> Having said that, I agree with you that a reader of the document who knows
> DNSSEC lore can fill in these two fields without any real risk.
>
> I think it's wrong to leave things undefined in a document defining an
> interoperable file format but I don't insist on these two nits.
>
> C.
> Besides these two protocol omissions I think it would be good to expand
> the example to cover corner case created by optional publickeyinfo
> elements.
>
> I would recommend to base the 2.3 XML example section on the current
> version of http://data.iana.org/root-anchors/root-anchors.xml _with
> DNSKEY added_ for the 20326 keytag.
>
> I.e. we would show three KeyDigest elements:
> - 19036 which is expired (validUntil in the past)
> - 20326 which is currently valid and also contains (PublicKey, Flags)
> - 38696 which is also valid but does NOT contain (PublicKey, Flags)
>
> Is this important enough for us to have to do a new draft?
>
> See below. I think it is.
>
> Then the text should show how to reconstruct:
> - DS set with two valid DSes (20326, 38696)
> - DNSKEY set with just one DNSKEY (20326 only because material for 38696
> is missing)
>
> Again, I'm not seeing the value to restating RFC 4034 here.
>
> Sorry but no, this has nothing to do with RFC 4034. It's limitation of the
> proposed XML format which has an optional field. That optional feature
> makes the format internally inconsistent for different groups of readers -
> depending on whether the reader implementation looks at Digest or
> publickeyinfo elements.
>
> ... and say that the relying party needs to deal with this discrepancy
> between DS and DNSKEY sets.
>
> We already have that in the Security Considerations.
>
> I can't see any words about DS vs. DNSKEY set mismatch in the current
> Security Considerations section. Are they somewhere else I could not find
> them?
>
> Personally I still think it's a mistake to make publickeyinfo optional but
> with the current safeguards in place (last paragraph of sect 3.2) I'm
> hesitantly okay with leaving it optional.
>
> If we make it mandatory, then the current trust anchor file, and all
> previous trust anchor files, are invalid. We thought it was better to keep
> them valid.
>
> I don't think it's an useful goal. Allow me to explain:
>
> - Old versions of 

[DNSOP] Re: [Editorial Errata Reported] RFC9276 (8090)

[Warren Kumari]

On Mon, Aug 26, 2024 at 3:53 PM, John Levine  wrote:

> It appears that RFC Errata System  said:
>
> -
> [ZONEENUM] Wang, Z., Xiao, L., and R. Wang, "An efficient DNSSEC zone
> enumeration algorithm", DOI 10.2495/MIIT130591, April 2014,  org/10.2495/MIIT130591>.
>
> This page at researchgate says it was given at:
>
> International conference on Management Innovation and Information
> Technology, Volume: 61
>
> https://www.researchgate.net/publication/
> 269031030_An_efficient_DNSSEC_zone_enumeration_algorithm
>
> I can find no evidence that there ever was an "International conference on
> Management Innovation and Information Technology". When I search for it I
> find a lot of conferences with those words in different orders, but not
> that one. I find no other trace of the paper or the authors, although Wang
> is such a common name it's hard to search for.
>
> It's not clear that the paper was ever really published or that the
> conference existed.
>


Hmmm…. I *think* that the WG / RFC Editor would have checked to make sure
that the link goes *somewhere*, and so I suspect that the paper did
actually exist at one point…. but, yes, I can also not find any sort of
archival copy of it, nor the conference it came from.
The Abstract (from ResearchGate) is also a little confusing / disjointed:
"The algorithm advances on one direction until the discovered fragments are
defragged. A stack is dedicated for the defragment with advantage of time
and space efficiency. Complexity analysis shows that compared with random
DNS queries, the algorithm reduces the number of queries to N."

Authors, any idea / links? Or does anyone have a current link to this paper?
W



> R's,
> John
>
> PS: Or maybe the authors remember where they saw it.
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Warren Kumari]

On Wed, Aug 21, 2024 at 10:28 AM, Edward Lewis 
wrote:

> On Aug 20, 2024, at 20:42, Michael StJohns 
> wrote:
>
> Hi Paul -
>
> I'm confused from your responses below - is this a WG document where the
> WG gets to decide, or is this an IANA document (like the one it was
> replacing) where IANA gets to decide? I *think* I saw you argue both ways
> in your response below.
>
> This question interests me.
>
> When DNSSEC was designed, there was a decision to treat all zones the
> same. The fear was large delegated zones (COM) would need special
> treatment, we didn’t want the protocol to different per zone for that. We
> didn’t address the uniqueness of the root zone though, specifically in
> distributing the trust anchor for it. This left a gap we’ve never
> addressed.
>
> IANA has addressed this for the DNS running on the global public Internet.
> Said in the sense that there is one DNS protocol and possibly many
> instantiations of a running DNS system. (I knew of a non-Internet DNS at
> one time, operating on a separate, private inter-network. It may not be
> around any more, on the other hand, when it comes to the inter-planetary
> work, there may be a DNS system per, say, planet.) This document is
> addressing how IANA is, has, and will be distributing the trust anchor for
> the root zone they manage.
>
> On the one hand, IANA wants to do what is in the best interests of the
> global public Internet and as such, seeks expert opinions of which this
> document is an example. The WG can’t materially change the document -
> without convincing IANA to alter something operational. This doesn’t make
> WG review futile, a “rubber stamp” step, IANA is listening to the feedback.
> OTOH, I wonder if this is truly a WG document or something that is best
> through the Independent stream but reviewed by the DNSOP WG.
>
> I doubt there is enough energy for the WG to design a “standards based”
> means for root zone trust anchor management and distribution that is out of
> band, despite the gap, as there is only one working example (IANA’s) and
> IANA has its methods (including this document) in place.
>
> “Automated Updates of DNSSEC Trust Anchors” is the WG’s in-band mechanism.
> A while ago I wrote a replacement for that to address issues uncovered in
> looking at a root zone DNS Security Algorithm change but abandoned the work
> once I realized the only operational deployment of it would be for the root
> zone, which isn’t enough to justify the standards work. The root zone
> implementation of Automated Updates isn’t precisely “by the RFC” but it
> works and for any change to the DNS Security Algorithm, it’ll be “made to
> work”, an alternate approach isn’t worth pursuing.
>
> Syntax is easy. Semantics are hard and this document has a bit too much
> ambiguity for a naive relying party. Strangely, if this were simply a
> signed file of hashes with a time associated with it indicating the IANA's
> current view (at time of publication) of the trust anchor set, I'd have a
> lot less to argue about. Someone tried to do too much I think.
>
> Protocol-defining IETF documents are meant to spur implementations, seeing
> multiple independent implementations interoperate is the goal. As a result,
> the documents often leave details up to the reader/implementer.
>
> But this document is not a pure protocol-defining document, it is an
> operational process document. As such, it ought to be more concrete. That
> is, if the goal is to describe the entirety of distributing the trust
> anchors.
>

I do not believe that that is the goal, nor should it be.

>From the Abstract:
"This document describes the format and publication mechanisms IANA uses to
distribute the DNSSEC trust anchors."
and Introduction:
"The publication of trust anchors for the root zone of the DNS is an IANA
function performed by ICANN, through its affiliate Public Technical
Identifiers (PTI).  A detailed description of corresponding  key management
practices can be found in [DPS].

This document describes the formats and distribution methods of DNSSEC
trust anchors that is used by IANA for the root zone of the DNS.  Other
organizations might have different formats and mechanisms for distributing
DNSSEC trust anchors for the root zone; however, most operators and
software vendors have chosen to rely on the IANA  trust anchors.

The formats and distribution methods described in this document are a
complement to, not a substitute for, the automated DNSSEC trust anchor
update protocol described in [RFC5011]."

This document describes the "format and publication mechanisms IANA uses",
not "this is what we believe that the IANA should do" - there are other
venues for that discussion.


The document could be here to just present the marshaling of the trust
> anchor materials - describing the syntax as it does - leaving the
> interpretation up to the writer (IANA) and reader (relying parties).
>
> Maybe this document ought to just describe what’s in the file. Maybe this

[DNSOP] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Warren Kumari]

Dear DNSOP,

During the DNSDIR review of draft-ietf-dnsop-rfc7958bis-03, Petr Špaček
identified an issue: if you include the DNSKEY material you also need to
include the flags.

The authors have published a new version addressing these changes, as well
as addressing more minor comments received during IETF LC.

As this required a change to the XML syntax, I'd like to get the DNSOP WGs
review / feedback on these changes.

The IANA is eagerly awaiting this becoming a standard so that they can
update their trust anchor with the DNSKEY material - so, if you have any
strong objections to these changes, please let me know by end of day
(anywhere!) on Aug 18th

Latest version:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/
Diff from -03:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-rfc7958bis-03&url2=draft-ietf-dnsop-rfc7958bis-04&difftype=--html

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

[DNSOP] Re: [Technical Errata Reported] RFC6781 (6692)

[Warren Kumari]

Awesome, thank you!

I marked it as Verified and linked to this thread for tracking / additional
info.

W


On Mon, Jul 08, 2024 at 6:22 PM, Peter Thomassen  wrote:

> Hi Warren,
>
> tl;dr: The erratum is correct, and I think can be verified.
>
> The situation described in the second-to-last paragraph of RFC 6781
> Section 4.3.5.1 (and illustrated in Appendix D) amounts to
>
> - adding operator B as a multi-signing party according to RFC 8901 Model,
> - removing operator A.
>
> The delegation goes directly from NS_A to NS_B, whereas a permanent
> multi-signer setup would have both NS_A and NS_B in the delegation.
> Otherwise, the above is identical to a Model 2 multi-signer configuration.
>
> To evaluate the erratum, it thus helps to think about multi-signer
> transitions. It turns out these have been analyzed in detail. For example,
> see page 2 of the IETF 115 DNSOP presentation on Multi-Signer Key Exchange
> [1], which says:
>
> DNSKEY responses must contain all keys a validating resolver may need for
> validation [...]
> (RRSIG is always from the same provider [as the DNSKEY RRset])
>
> Perhaps an example helps. If you have two providers, a resolver might
> fetch the DNSKEY RRset from provider A and some other RRset (e.g., www IN
> A) from provider B. (In multi-signer, this happens routinely, and in RFC
> 6781 Section 4.3.5.1 it happens when the delegation switches between the
> two fetches.) -- Now, what's important is that, at each provider,
>
> 1.) the DNSKEY RRset has either provider's ZSK, so that one can validate
> the "www IN A" RRset with it, regardless of which providers the DNSKEY and
> A RRset were fetched from;
>
> 2.) the DNKSEY RRset itself needs to be validated, which works if it is
> signed with a key that is represented in the DS RRset. In the situation at
> hand, there DS records for *both* provider's KSK, so *either one* can be
> used to validate the DNSKEY RRset. It therefore suffices if each provider
> serves their own DNSKEY RRSIG.
>
> They only need import each other's ZSKs, but not exchange KSKs or RRSIGs.
>
> This is exactly the point of the erratum.
>
> Best,
> Peter
>
> [1]: https://datatracker.ietf.org/meeting/115/materials/
> slides-115-dnsop-multi-signer-key-exchange-mske-00.pdf
>
> On 6/27/24 16:46, Warren Kumari wrote:
>
> Hi there WG,
>
> I am trying to go through and clean up all open Operations Errata.
>
> I would really appreciate some input / advice from the WG on what I should
> do here — I've read and reread the thread and the document, and cannot
> figure out if this Errata is correct or not….
>
> I'm tempted to mark this as Hold for Document Update, but I'm not sure if
> that is best.
>
> Errata: https://www.rfc-editor.org/errata/eid6692 <https://www.rfc-editor.
> org/errata/eid6692> RFC: RFC6781 - "DNSSEC Operational Practices, Version
> 2" <https://datatracker.ietf.org/doc/rfc6781/>
>
> Types of Errata: https://www.rfc-editor.org/errata-definitions/  www.rfc-editor.org/errata-definitions/>
>
> W
>
> On Fri, Sep 24, 2021 at 3:35 PM, Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
>
> I am going to assume that the DNSKEY of this zone is not a trust anchor.
>
> So it is going to use the DS RRset, not a cached DNSKEY RRset, to
> authenticate the child zone's apex DNSKEY RRset (the one from the
> response). Then from RFC 4035:
>
> o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the
> corresponding private key has signed the child zone's apex DNSKEY RRset,
> and the resulting RRSIG RR authenticates the child zone's apex DNSKEY
> RRset.
>
> I read this as the cached DNSKEY RRset does not come into play when
> validating the DNSKEY RRset from the response, and any implementation that
> does otherwise is not compliant.
>
> - Matthijs
>
> On 24-09-2021 15:01, Paul Wouters wrote:
>
> On Fri, 24 Sep 2021, Matthijs Mekking wrote:
>
> Second, I believe the corner case you mentioned is for Figure 15 (the one
> in Appendix D), and I don't understand the scenario you are describing.
> What do you mean with "the resolver getting the DNKSEY RRset for NS_B would
> not contain a valid key for the DNSKEY RRset of NS_B". I think the resolver
> would get a new DNSKEY RRset with a pre-fetch (or if the DNSKEY RRset was
> expired from cache) and that would be validated with the DNSKEY from the
> response.
>
> If it has a valid unexpired DNSKEY RRset, and a resolver fetches that
> DNSKEY RRset again, will it use the cached DNSKEY RRset or the DNSKEY RRset
> from the fetched record set to validate the signature against the cached DS
> RRse

[DNSOP] Re: [Technical Errata Reported] RFC6781 (6692)

[Warren Kumari]

Hi there WG,

I am trying to go through and clean up all open Operations Errata.

I would really appreciate some input / advice from the WG on what I should
do here — I've read and reread the thread and the document, and cannot
figure out if this Errata is correct or not….


I'm tempted to mark this as Hold for Document Update, but I'm not sure if
that is best.

Errata: https://www.rfc-editor.org/errata/eid6692
RFC: RFC6781 - "DNSSEC Operational Practices, Version 2"


Types of Errata: https://www.rfc-editor.org/errata-definitions/

W


On Fri, Sep 24, 2021 at 3:35 PM, Matthijs Mekking 
wrote:

> I am going to assume that the DNSKEY of this zone is not a trust anchor.
>
> So it is going to use the DS RRset, not a cached DNSKEY RRset, to
> authenticate the child zone's apex DNSKEY RRset (the one from the
> response). Then from RFC 4035:
>
> o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the
> corresponding private key has signed the child zone's apex DNSKEY RRset,
> and the resulting RRSIG RR authenticates the child zone's apex DNSKEY
> RRset.
>
> I read this as the cached DNSKEY RRset does not come into play when
> validating the DNSKEY RRset from the response, and any implementation that
> does otherwise is not compliant.
>
> - Matthijs
>
> On 24-09-2021 15:01, Paul Wouters wrote:
>
> On Fri, 24 Sep 2021, Matthijs Mekking wrote:
>
> Second, I believe the corner case you mentioned is for Figure 15 (the one
> in Appendix D), and I don't understand the scenario you are describing.
> What do you mean with "the resolver getting the DNKSEY RRset for NS_B would
> not contain a valid key for the DNSKEY RRset of NS_B". I think the resolver
> would get a new DNSKEY RRset with a pre-fetch (or if the DNSKEY RRset was
> expired from cache) and that would be validated with the DNSKEY from the
> response.
>
> If it has a valid unexpired DNSKEY RRset, and a resolver fetches that
> DNSKEY RRset again, will it use the cached DNSKEY RRset or the DNSKEY RRset
> from the fetched record set to validate the signature against the cached DS
> RRset ? Or is this implementation specific?
>
> Paul
>
> ___
> 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
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Technical Errata Reported] RFC7344 (7997)

[Warren Kumari]

On Fri, Jun 21, 2024 at 11:13 PM, Paul Wouters  wrote:

> This errata is correct.
>
> Paul
>


Doh! Yes, it is…

Paul, would you mind being the one to mark it as Verified? I'm an author,
and while I don't really see a much conflict of interest for an AD to mark
an errata as verified, it's probably cleaner if someone else does it…

W


> Sent using a virtual keyboard on a phone
>
> On Jun 21, 2024, at 17:47, RFC Errata System 
> wrote:
>
> The following errata report has been submitted for RFC7344,
> "Automating DNSSEC Delegation Trust Maintenance".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7997
>
> --
> Type: Technical
> Reported by: Casey Deccio 
>
> Section: 6.2.1
>
> Original Text
> -
> When a Parent operates in "calculate DS" mode, it can operate in one of
> two sub-modes:
>
> full: The Parent only publishes DS records it calculates from DNSKEY
> records.
>
> Corrected Text
> --
> When a Parent operates in "calculate DS" mode, it can operate in one of
> two sub-modes:
>
> full: The Parent only publishes DS records it calculates from CDNSKEY
> records.
>
> Notes
> -
> In the last sentence, "DNSKEY" should be "CDNSKEY". That is, the Parent
> calculates DS records from the CDNSKEY records, not from the DNSKEY
> records.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it will be
> removed shortly by the RFC Production Center.) Please use "Reply All" to
> discuss whether it should be verified or rejected. When a decision is
> reached, the verifying party will log in to change the status and edit the
> report, if necessary.
>
> --
> RFC7344 (draft-ietf-dnsop-delegation-trust-maintainance-14)
> --
> Title : Automating DNSSEC Delegation Trust Maintenance Publication Date :
> September 2014
> Author(s) : W. Kumari, O. Gudmundsson, G. Barwood Category : INFORMATIONAL
> Source : Domain Name System Operations Stream : IETF
> Verifying Party : IESG
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Approved: draft-ietf-dnsop-qdcount-is-one

[Warren Kumari]

On Thu, Jun 20 2024 at 1:30 PM, Joe Abley  wrote:

> Hi Warren,
>
> On Jun 20, 2024, at 18:56, Warren Kumari  wrote:
>
> Hi there Authors, IESG, WG and Secretariat,
>
> draft-ietf-dnsop-qdcount-is-one - "In the DNS, QDCOUNT is (usually) One"
> is now approved.
>
> I'd like to thank everyone, especially the authors and Eric Vyncke, for
> all of their hard work - it significantly improved the document.
>
> There are some editorial comments that can still be addressed; these are
> minor enough that they can occur with the RFC Editor…
>
> I have tackled the editorial comments in a candidate 04 (not submitted,
> URL below, work-in-progress-in-progress).
>


Awesome, thank you, Joe.

W

Since these changes are minor and don't affect the substance of the
> document I presumed to tackle these without bothering Ray, so any glaring
> errors in this candidate 04 are mine, not his. If anybody feels like
> checking my work, it can be found at:
>
> https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-qdcount-is-one
>
> The one comment I didn't address was Éric's comment on section 1, where we
> use (as in this sentence) the editorial "we" to outline the structure of
> the document to follow. I think the editorial "we" is sufficiently familiar
> from its use elsewhere (e.g. in many, many academic papers) that the
> context is clear, and I think the passive voice would make that paragraph
> harder to read, so I didn't change it. Of course if this seems
> unsatisfactory we can revisit it^W^W^W^Wit can be revisited.
>
> Joe
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Approved: draft-ietf-dnsop-qdcount-is-one

[Warren Kumari]

Hi there Authors, IESG, WG and Secretariat,

draft-ietf-dnsop-qdcount-is-one - "In the DNS, QDCOUNT is (usually) One"
 is now
approved.

I'd like to thank everyone, especially the authors and Eric Vyncke, for all
of their hard work - it  significantly improved the document.

There are some editorial comments that can still be addressed; these are
minor enough that they can occur with the RFC Editor…

Thank you again, all.
W
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Mahesh Jethanandani's No Objection on draft-ietf-dnsop-qdcount-is-one-03: (with COMMENT)

[Warren Kumari]

On Tue, Jun 18, 2024 at 3:09 PM, Mahesh Jethanandani 
wrote:

> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-dnsop-qdcount-is-one-03: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/
>
> --
> COMMENT:
> --
>
> Section 3, paragraph 1
>
> A brief summary of the guidance provided in the existing DNS specification
> for the use of QDCOUNT can be found in Appendix A. While the specification
> is clear in many cases, in the specific case of OPCODE = 0 (QUERY) there is
> some ambiguity which this document aims to eliminate.
>
> By "existing DNS specification" do you mean RFC1035? Please state so.
>



Looking at Appendix A, I see:
[RFC1035]
[RFC1996]
[RFC2136]
[RFC3425]
[RFC5936]
[RFC7873]
[RFC8490]

So this is not just RFC1035. I *guess* this could be "DNS specifications"
instead of "DNS specification"

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

[DNSOP] draft-ietf-dnsop-zoneversion, draft-ietf-dnsop-qdcount-is-one progress…

[Warren Kumari]

Hi there, authors and WG.

I recently wrote up a summary of the process for authors who are new to the
IETF.
While doing so, I realized that it might be useful to share this even with
experienced authors as well (and also WGs) , so here is a (very) brief
overview of the process:

After the WG chairs declare consensus and complete the document shepherd
writeup, they request publication and the document enters the AD (my) queue.

I then perform my "AD Review" —  this involves reviewing the document,
checking the document shepherd writeup and also doing a ballot writeup. I
will likely have a bunch of editorial comments and nits during the AD
review; addressing these before the IETF LC and IESG eval helps the
document more through the process more smoothly. Apart from just being
polite to the reader, if someone has a hard time reading a document (or
find lots of nits) they get irritated and grumpy towards the document :-)

After comments (if any) are addressed, I request IETF Last Call. Assuming
there is consensus, after comments (if any) have been addressed,  I
progress the document to IESG Evaluation.

*** This is where draft-ietf-dnsop-qdcount-is-one and
draft-ietf-dnsop-zoneversion
are now ***

This is where the entire IESG reviews the document, paying special
attention to conflicts with their area, etc. Note that you will get
comments during this evaluation; ADs review the document carefully, and
will likely have some questions, but also, because they are reviewing
carefully, you will likely get a bunch of editorial type comments and
suggestions.

This is also where you may get DISCUSS ballots on the document — these used
to be concerning to authors, and so I wrote a blog post to help explain how
to deal with them:
https://www.ietf.org/blog/handling-iesg-ballot-positions/ (and
a slightly more formal rewrite:
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ).
The key takeaway is that, even though DISCUSSes *are* blocking positions,
and you have to address them, they are called 'DISCUSS' for a reason - they
are intended to result in a DISCUSSion with the discussing AD.

Once the DISCUSS positions and comments are addressed, the document is then
sent to the RFC Editor for final editing (grammar, spelling, etc). At this
point all listed authors are required to approve publication (this is
called AUTH48), and then it finally becomes an RFC.

I'm mentioning all of this because there is still a fair bit of process
that needs to happen; much of this is on the AD (me), but there is still
some work for the authors, and it will still take some time. I wanted to
help explain the process and also set expectations.

If you'd like more info on how the process works, etc, here are some
(hopefully helpful) resources:
1: Scott Bradner’s “IETF: Publishing an RFC” -
https://youtu.be/j3Toe4P9Pa8?list=PLC86T-6ZTP5hXPJ-n4mwJbZ0BHaNlhTMA . This
is part of Scott's "Newcomers" series (
https://www.youtube.com/playlist?list=PLC86T-6ZTP5hXPJ-n4mwJbZ0BHaNlhTMA)

2: The IETF Process - an informal guide:
https://www.ietf.org/standards/process/informal/

3: The Tao of the IETF: https://www.ietf.org/about/participate/tao/

4: A convoluted state diagram:
https://static.ietf.org/dt/12.11.0/ietf/images/iesg-draft-state-diagram.png

I'm also (of course) happy to answer any questions, etc.,

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

[DNSOP] Re: [Editorial Errata Reported] RFC8945 (7983)

[Warren Kumari]

On Tue, Jun 11, 2024 at 3:10 PM, Paul Vixie <
paul=40redbarn@dmarc.ietf.org> wrote:

> this is a good fix to a true error in this rfc.
>


Excellent, thank you — I've just marked it as verified.

W




> RFC Errata System wrote on 2024-06-11 06:00:
>
> The following errata report has been submitted for RFC8945,
> "Secret Key Transaction Authentication for DNS (TSIG)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7983
>
> --
> Type: Editorial
> Reported by: Terts Diepraam 
>
> Section: 5.2
>
> Original Text
> -
> If the TSIG RR cannot be interpreted, the server MUST regard the message
> as corrupt and return a FORMERR to the server.
>
> Corrected Text
> --
> If the TSIG RR cannot be interpreted, the server MUST regard the message
> as corrupt and return a FORMERR to the client.
>
> Notes
> -
> Server send an error to the client, not to itself.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it will be
> removed shortly by the RFC Production Center.) Please use "Reply All" to
> discuss whether it should be verified or rejected. When a decision is
> reached, the verifying party will log in to change the status and edit the
> report, if necessary.
>
> --
> RFC8945 (draft-ietf-dnsop-rfc2845bis-09)
> --
> Title : Secret Key Transaction Authentication for DNS (TSIG) Publication
> Date : November 2020
> Author(s) : F. Dupont, S. Morris, P. Vixie, D. Eastlake 3rd, O.
> Gudmundsson, B. Wellington Category : INTERNET STANDARD
> Source : Domain Name System Operations Stream : IETF
> Verifying Party : IESG
>
> --
> P Vixie
>
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: AD Review of: draft-ietf-dnsop-qdcount-is-one

[Warren Kumari]

On Wed, May 29, 2024 at 6:03 AM, Ray Bellis  wrote:

> On 28/05/2024 22:12, Warren Kumari wrote:
>
> Hi there, authors (and WG),
>
> Thank you for this document, I found it clear, useful, and an easy read.
>
> I do have a few comments/nits; addressing these now should help the IETF
> LC and IESG evaluation go more smoothly.
>
> Please SHOUT loudly once you've had a chance to address these, and I'll
> start IETF LC.
>
> LOUDLY!
>

HEARD! :-)



> Questions / issues / comments:
> 1: Can you please update the Abstract to clarify *how* the document
> updates RFC1035?
>
> I think that something like:
> "This document updates RFC1035 by {clarifying|specifying} that the QDCOUNT
> parameter of a DNS Query must not be greater than one." or similar should
> work.
>
> I've committed an update, albeit it it doesn't take the above verbatim
> because it would've ended up -mostly- repeating the text that was already
> there and in the title.
>
> The abstract now reads:
>
> This document updates RFC 1035 by constraining the allowed value of the
> QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum of
> one, and specifies the required behaviour when values that are not allowed
> are encountered.
>
> If that suffices I'll actually upload that to the datatracker.
>
> I also took the opportunity to incorporate a trivial editorial nit spotted
> by Tony Finch that was reported to us over the weekend.
>


Excellent - once you post the new version I will start IETF LC. I should
notice the posting, but doesn't hurt to poke me too, just in case…
W



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

[DNSOP]AD Review of: draft-ietf-dnsop-qdcount-is-one

[Warren Kumari]

Hi there, authors (and WG),

Thank you for this document, I found it clear, useful, and an easy read.

I do have a few comments/nits; addressing these now should help the IETF LC
and IESG evaluation go more smoothly.

Please SHOUT loudly once you've had a chance to address these, and I'll
start IETF LC.

Questions / issues / comments:
1: Can you please update the Abstract to clarify *how* the document updates
RFC1035?

I think that something like:
"This document updates RFC1035 by {clarifying|specifying} that the QDCOUNT
parameter of a DNS Query must not be greater than one." or similar should
work.

The purpose of an abstract is so that readers know if they need to read the
rest of the document - if someone is chasing all of the updates to RFC1035
because they are interested in e.g the TTL, they can skip over this
document.

Huh, turns out I lied — I don't have "a few comments/nits", I only have the
one… but well, this is a template, so… ¯\_(ツ)_/¯.

Thank you again; I know that making edits to address nits can be annoying,
but we are expecting many people to read and review the document, and so
having it polished is important and polite (also, once people start
commenting on nits, they seem to continue :-) )
W
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Approved: draft-ietf-dnsop-dnssec-bootstrapping

[Warren Kumari]

Hi there Authors, WG, IESG and Secretariat,

draft-ietf-dnsop-dnssec-bootstrapping - "Automatic DNSSEC Bootstrapping
using Authenticated Signals from the Zone's Operator"
 is
now approved.

I'd like to thank everyone, especially the authors, as well as Paul
Wouters, for all of their hard work - it  has improved the document.

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

[DNSOP]DELEG Chair Announcement.

[Warren Kumari]

[ Apologies for the wide distribution - I sent the original request to
multiple WGs, and so figured this announcement should go to the same. ]

Hi all,

First, huge thanks to everyone who volunteered to serve as chairs for the
(in the process of being chartered) DELEG WG.

We had a large selection of very qualified candidates, which was both good
and bad.
The good part is how many people are both qualified and willing to serve .
The bad part is that this made is really difficult for Eric Vyncke and I to
select who to appoint; we'd like to have been able to appoint everyone;
but, after much discussion we have selected Brian Haberman and Duane
Wessels as chairs.  We would also like to appoint Tommy Jensen as WG
secretary & delegate.

Thank you very much again to everyone who volunteered, we really appreciate
it. We hope that you will contribute to the work, and be willing to
volunteer in the future (I'm also keeping the list around so I know whose
arms to twist… :-)

As an additional chair-related note:
As an AD, it is easy to make a decision to appoint chairs, and then never
revisit this decision - people get really busy, having "performance
related" discussions is not fun, it's easy to procrastinate, etc.  To help
mitigate this (and force myself to have the conversations!) I would like to
experiment with having (2 year) terms for chairs. This means that, in
addition to the general "how are things going" discussions, I will be
having a focused 1:1 discussion to confirm that they wish to continue,
discuss how things are going, etc.[0]. Having the terms aligned does not
seem great, and so I will be flipping a coin or using RFC3797 or similar to
decide how to stagger the appointments.

Thank you all again,
W

[0]: This is specifically not a term limit, and I expect in general to
reappoint chairs, but this will help ensure that this is intentional and
not just inertia / conflict avoidance…
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

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

[Warren Kumari]

Hi all,


I've read the thread multiple times, and can definitely see both sides of
the conversation. As Paul W is wearing both an AD hat and the DE hat, he
has asked me to make the decision and instruct him.

While I really don't love it, I believe that it makes sense to stick with
_signal.

Reasons against:
1: It is very generic. It's not at all clear that
foo.bar.baz._signal.example.com has anything to do with DNSSEC (although
_dsboot.foo.bar.baz._signal.example.com is clearer)

Reason for:
1: It is very generic - it another scheme happens to be able to fit well
under _signal, they can use it; _cheese.foo.bar.baz._signal.com **might**
be good if a parent wants to inform someone about their children's cheese
preferences)

2: Strings are cheap - if another scheme happens to not fit will under
_signal, they can choose another one (hopefully less generic next time!) —
_flavor.foo.bar._cheese.example.com.

3: It happens to already be some what deployed - and we cannot (easily)
tell who all has done so. Yes, CloudFlare presumably has this baked into a
variable somewhere and  it would be trivial to s/_signal/_dnssec-boot/, but
someone might also have already done this manually. Yes, I fully agree that
people shouldn't kvetch if they implemented from a draft and have to change
— which is why I only used this as a tie-breaker.

This was one of those "there is no perfect answer" situations, and at least
some set of people will be unhappy (sorry!), but I think that sticking with
the draft is the lesser of the two evils…

W



On Wed, May 15, 2024 at 4:49 PM, Peter Thomassen  wrote:

> Hi David,
>
> The DNSOP chairs have told me that the document is no longer a WG document
> as it's with the IESG, so a consensus call here is not applicable.
>
> Given the discussion here, we'll leave it to the IESG to decide. If I hear
> any news, I'll post them here.
>
> Thanks,
> Peter
>
> On 5/15/24 00:03, David Dong via RT wrote:
>
> Hi all,
>
> Following up on this. Please let us know how we should proceed for this.
> Thank you.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Thu May 09 09:39:29 2024, pe...@desec.io wrote:
>
> [another (last) attempt of reposting this as it did not get delivered to
> dnsop@ietf.org on May 7, as evidenced by the list archive]
>
> Hi,
>
> On 5/2/24 19:59, David Dong via RT wrote:
>
> Following up on this; does the group agree that "_dnssec" is OK?
>
> Looking at what's been said in this thread:
> - Two people have proposed to change the label, current proposal:
> _dnssec
> - Two implementers have said they'd make the change but don't seem
> convinced
> - The authors (hats off, but also implementers and authors of current
> drafts using the mechanism) are not convinced
>
> The authors don't feel comfortable declaring consensus in either direction
> (neither do we know whether that's our role), and we're not sure how to
> proceed. Perhaps the DNSOP chairs could weigh in, as the discussion is
> happening on the WG list although the document is technically out of the
> door ...
>
> I've been reluctant adding the following argument as to not seem
> insisting; OTOH it may have its own technical merit, so here is.
>
> The "_dnssec" label implies that the mechanism is not suitable for
> signaling unrelated to DNSSEC. That's an artificial limitation, and it's
> unclear why to impose the restriction. An operator could very well want to
> publish other things, like
>
> - TXT at _abuse.example.com._signal.ns1.provider.net for an abuse
> address,
> - PTR at _catalog.example.com._signal ... for catalog zone membership,
> - ...
>
> If the signaling method is generic, I believe it should have a short
> generic label. Any specificity to determine the kind of signal can go into
> the first label.
>
> I have no specific preference for "_signal" other than I don't know what a
> good alternative would be. Narrowing the scope with "_dnssec" doesn't seem
> to improve the situation.
>
> Thanks,
> Peter
> + Nils (for the "we"/author statements)
>
> Thank you.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote:
>
> On 20 Apr 2024, at 19:38, Paul Wouters wrote:
>
> On Sat, 20 Apr 2024, Peter Thomassen wrote:
>
> The authors certainly don't insist, but we'd need to pick a suitable
> replacement for the "_signal" label.
>
> John proposed "_dnssec-signal" elsewhere in this thread.
>
> The authors would like to note that adding "_dnssec-" eats up 8 more
> bytes, increasing chances that bootstrapping will fail due to the
> _dsboot.._dnssec-signal. length limitation. Other
> than this (unnecessary?) use case narrowing, this choice seems
> fine.
>
> That said, does this choice address your concerns?
>
> It would, but I would also be okay if it is just _dnssec.
>
> If the concern is that the label is too generic, “_dnssec” might be too
> generic as well. If it is to be more precise, go with _ds-boot or
> something more specific to the us

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

[Warren Kumari]

On Thu, May 16, 2024 at 11:48 AM, Peter Thomassen  wrote:

> Hi Paul, Warren,
>
> Following up on the telechat:
>
> On 5/15/24 20:34, Peter Thomassen wrote:
>
> Section 2:
>
>  The DS enrollment methods described in Section 3 of [RFC8078]
>  are deprecated and SHOULD NOT be used.
>
> I find this to be inconsistent with the Update: 8078 clause, as without
> "Section 3", you are basically obsoleting the entire 8078. I don't think
> this document should obsolete it, it should augment it. I would rewrite the
> above like:
>
>  The DS enrollment method described in this document provides more
>  security than the methods described in Section 3 of [RFC8078],
>  and are therefor RECOMMENDED in favour of the methods specified
>  in [RFC8078].
>
> If the authors/WG insists on the "deprecated" language, it should also
> Obsolete: 8078. But be aware that the document currently does make
> references to it, which it cannot do if it obsoletes the document.
>
> I now understood better what this was about.
>
> My understanding of the WG discussion [4] is that the intention of the
> current text ("the old method is NOT RECOMMENDED") is quite similar to that
> of Paul's proposal ("the new method is RECOMMENDED").
>
> The word "deprecated" adds the aspect of "phasing out" (i.e., "with a
> negative slope"), whereas "obsoleted" is stronger and means that it has
> already been phased out. (This is my limited non-native interpretation of
> English.)
>
> The telechat consensus appears to have been to adopt something like your
> wording, without implying a phase-out (deprecation). If I captured this
> correctly, we'll incorporate something along those lines.
>


Yup, I believe that this is correct.



> [4]: https://mailarchive.ietf.org/arch/msg/dnsop/
> Ld0lgCwJJQvgKIA9eBv8yEtgeoI/
>
> Section 5:
>
>  CDS/CDNSKEY records and corresponding signaling records MUST
>  NOT be published without the zone owner's consent.
>
> This opens a can of worms. How is an implementer going to codify this
> MUST? The only usable interpretation I can see is that the DNS hoster, by
> being assigned the DNS hoster, has permissions to DNS host the zone as it
> sees fit, and thus do DNSSEC. And especially not bother the zone owner with
> techno-babble for permissions.
>
>  Likewise, the child DNS operator MUST enable the zone owner
>
> Again, this wades into legalize and contractual matters best left outside
> of RFC specifications.
>
> These were added based on Warren's concerns that a DNS operator may lock
> in a customer by enabling DNSSEC without consent, thus making it harder to
> move away from that provider.
>
> The authors believe either way is fine, and would like to hear the IESG's
> decision on how to address this (or not).
>
> If I recall correctly, the sentiment was to change the wording around this
> to be less MUST-y, but still make the point. We'll try to come up with
> something suitable and circulate it here.
>


Yup. Paul W and I had a long (and fruitful) discussion. I'm personally
still twitchy about the potential for vendor lock-in and zones being
changed without the users' consent — but I'm willing to concede that I'm in
the rough here.

I'd be fine with this being changed to something along the lines of "Users
should be informed that the operator may enable DNSSEC on their behalf…" or
similar weasel-words…

W



> Peter
>
> --
> https://desec.io/
>
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.

[Warren Kumari]

Hello everybody,

Firstly thank you for all of the discussion on these documents - we really
appreciate the review and feedback.

We’ve read all of the discussion(s) and will be updating the documents to
address your comments, based on our understanding of the group’s consensus
so far. While reviewing the discussion, we came to the realization that
there are two potential paths forward for draft-hardaker-dnsop-rfc8624-bis,
and we would like your opinion on which choice everyone feels is best.

As evidenced by the discussions, implementations can’t realistically remove
the Foo algorithm if many of their customers are still using it. So:

Option 1: Pivot this document from providing implementers with guidance
(“Implementers MUST NOT use Foo for signing”) to providing guidance to
operators instead (“Operators MUST NOT use Foo for signing”).

Or

Option 2: Focus on removing algorithm usage first, by informing operators
to stop using an algorithm to be deprecated, and then, later, specify that
implementers may/should/must stop supporting the algorithm.

We think Option 2 makes much more sense, as this provides both “operational
guidance” and “implementation guidance.”  With such, we can leave
implementations interoperable while slowly decreasing algorithm deployment
until it is safe to actually remove implementation support once perceived
usage has decreased. If we were to provide guidance to either implementers
or operators -- but not both --  then we leave one side questioning their
purpose in life.

This means that we should actually have a column per type (i.e “Operators”
and “Implementers”) crossed with a column per DNSSEC usage type (“Signing”
and “Validation”), such that for the “Domain Name System Security (DNSSEC)
Algorithm Numbers” table we would be adding FOUR columns:

   -

   “Use for DNSSEC Signing”
   -

   “Use for DNSSEC Validation”
   -

   “Implement for DNSSEC Signing”
   -

   “Implement for DNSSEC Validation”

And four for “DNSSEC Delegation Signer (DS) Resource Record (RR) Type
Digest Algorithms”:

   -

   “Use for DNSSEC Delegation”
   -

   “Use for DNSSEC Validation”
   -

   “Implement for DNSSEC Delegation”
   -

   “Implement for DNSSEC Validation”


With these in place, drafts like the draft-hardaker-dnsop-must-not-sha1can
be written with each recommendation to be  discussed individually.

Note that we have not updated the text in the repository yet as this would
be a fairly major overhaul, and we wanted to get the working group’s
opinions on the subject first.


Wes and Warren


P.S: When reading the thread, we suddenly realized that the
“draft-hardaker-dnsop-must-not-gost” document needed even more
clarification that it is only talking about the “old” GOST (RFC5933), and
not the “new” GOST (RFC 9558).

The “old” GOST RFC was made historic (see “Change the status of GOST
Signature Algorithms in DNSSEC in the IETF stream to Historic” -
*https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/*

). Old GOST was “deprecated by the Orders of the Federal Agency for
Technical Regulation and Metrology of Russia (Rosstandart) in August 2012,
and superseded by GOST 34.10-2012 and GOST 34.11-2012 respectively from January
1, 2013), which provides a good justification. This means that we can
remove the “The security of the ECC-GOST algorithm [RFC5933] has been
slowly diminishing over time as various forms of attacks have weakened its
cryptographic underpinning.”  hand-wavy justification.


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

[DNSOP] You, yes you, could be chair of the (proposed) Deleg WG…

[Warren Kumari]

Hi there all,

I'm sending this to multiple lists, so you might get multiple copies…


As mentioned during the Deleg BoF, we are casting a wide net for chairs for
the (proposed) Deleg WG.

The DNS is "core plumbing" for the Internet. It is also one of the very few
protocols which has scaled throughout the life of the Internet with almost
no changes; as delegations are the primary scaling mechanism, we need to be
careful to not mess this up. Because of this, we are being extra cautious
with the chair selection. This makes it tempting to just reappoint
well-known, experienced chairs -- but we also want to ensure that we are
not overlooking anyone, and are also creating space for newcomers to be
able to gain some chairing experience.

Some people are not very comfortable putting  themselves forward, and so
I've decided to do this as a survey  / form — it's both less intimidating
to just fill in a form, and also this provides an easy way to nominate
someone else…

So, if you are interested in being considered as a chair for the (proposed)
Deleg WG, or know of anyone else who you think would be great, please fill
in this (anonymous) survey -- only Éric Vyncke and myself (Warren) will
have access to the results.

https://forms.gle/n1eDTDX7iAjGJ6Ne9


Thank you,
W
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Editorial / OCD nit on draft-ietf-dnsop-generalized-notify

[Warren Kumari]

Hey there authors and WG,

While reading draft-ietf-dnsop-generalized-notify - "Generalized DNS
Notifications"
 I
noticed (in the Abstract):

"This document extends the use of DNS NOTIFY ([RFC1996] beyond conventional
zone transfer hints, …"

There is an opening parenthesis with no closing one, and this
**completely** triggered my OCD…

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

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

[Warren Kumari]

Thank you, I have requested IETF LC be started on this document.

W


On Thu, Apr 11, 2024 at 9:03 AM, Peter Thomassen  wrote:

> Dear DNSOP,
>
> Here's a quick change log, all are editorial:
>
> - Editorial changes from AD Review
> - Updated implementation section
> - Change capitalization of terms from terminology section (from WGLC)
>
> Peter
>
> On 4/11/24 14:59, internet-dra...@ietf.org wrote:
>
> Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-08.txt is now
> available. It 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
> Name: draft-ietf-dnsop-dnssec-bootstrapping-08.txt Pages: 17
> Dates: 2024-04-11
>
> 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".
>
> This document deprecates the DS enrollment methods described in Section 3
> of RFC 8078 in favor of Section 4 of this document, and also updates RFC
> 7344.
>
> [ 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-08.
> html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/
> iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-08
>
> 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Demo of Github issues for tracking documents and next steps..

[Warren Kumari]

Gah….

Apologies all, autocomplete fail — turns out "dnsop-chairs" starts with
"dnsop".

Sorry for the noise,
W


On Wed, Apr 10, 2024 at 2:36 PM, Warren Kumari  wrote:

> Heyya chairs,
>
> I futzed some more with the demo GH issue tracker I created on the call,
> and invited you to the repo: https://github.com/wkumari/
> Temp-DNSOP_Doc_Tracker/issues . I did also play more with github projects
> (and some other project / ticket things), but they don't really looks like
> they would work well for this….
>
> I've only put in a few drafts and labels, but I think that it gives a
> flavor of how we might be able to use it to track, and more importantly,
> communicate the status of documents.
>
> Some examples:
> Documents waiting on chairs: https://github.com/wkumari/
> Temp-DNSOP_Doc_Tracker/issues?q=is%3Aopen+is%3Aissue+label%3AChairs
>
> Documents where we need more WG input: https://github.com/wkumari/
> Temp-DNSOP_Doc_Tracker/
> issues?q=is%3Aopen+is%3Aissue+label%3A%22Review+needed%22
>
> Things that need actions from me: https://github.com/wkumari/
> Temp-DNSOP_Doc_Tracker/issues/assigned/wkumari (once you've accepted the
> GH repo invite we demo assigning things to you).
>
> A document with some more detail / synthetic info: https://github.com/
> wkumari/Temp-DNSOP_Doc_Tracker/issues/8
>
>
> Clearly this is just a demo (and it will be much much more useful after
> it's been used for a while and so actually has useful information / data),
> but I figured it was worth playing with.
>
> Ideally, once we've had a look (and probably added some more labels, etc.)
> we can share it with the WG, and see what they think. People should be able
> to subscribe to particular issues, and so get updates when things change,
> etc.
> I'd also like to look into adding labels for "I'm requesting CfA" or
> "Requesting WGLC" that authors/participants can apply - this seems like it
> will be easier to track than a request buried in the bottom of an email.
>
>
> I fully agree with Suz it's sucky that we will have the same info in
> multiple places (DT, GH, etc) — ideally, after some amount of timing we can
> write up good feature requests, and ask the tools team to fold some of
> this into the datatracker. Yes, DT does already have the "History" tab for
> each draft, but the info there isn't shown on the dashboard, and you cannot
> (yet) add tags, etc.
>
> In the meantime we can probably write some simple automation to copy DT
> into into GH issues…
>
> Thoughts?  Does this seem useful?
> W
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Demo of Github issues for tracking documents and next steps..

[Warren Kumari]

Heyya chairs,

I futzed some more with the demo GH issue tracker I created on the call,
and invited you to the repo:
https://github.com/wkumari/Temp-DNSOP_Doc_Tracker/issues . I did also play
more with github projects (and some other project / ticket things), but
they don't really looks like they would work well for this….

I've only put in a few drafts and labels, but I think that it gives a
flavor of how we might be able to use it to track, and more importantly,
communicate the status of documents.

Some examples:
Documents waiting on chairs:
https://github.com/wkumari/Temp-DNSOP_Doc_Tracker/issues?q=is%3Aopen+is%3Aissue+label%3AChairs

Documents where we need more WG input:
https://github.com/wkumari/Temp-DNSOP_Doc_Tracker/issues?q=is%3Aopen+is%3Aissue+label%3A%22Review+needed%22

Things that need actions from me:
https://github.com/wkumari/Temp-DNSOP_Doc_Tracker/issues/assigned/wkumari (once
you've accepted the GH repo invite we demo assigning things to you).

A document with some more detail / synthetic info:
https://github.com/wkumari/Temp-DNSOP_Doc_Tracker/issues/8


Clearly this is just a demo (and it will be much much more useful after
it's been used for a while and so actually has useful information / data),
but I figured it was worth playing with.

Ideally, once we've had a look (and probably added some more labels, etc.)
we can share it with the WG, and see what they think. People should be able
to subscribe to particular issues, and so get updates when things change,
etc.
I'd also like to look into adding labels for "I'm requesting CfA" or
"Requesting WGLC" that authors/participants can apply - this seems like it
will be easier to track than a request buried in the bottom of an email.


I fully agree with Suz it's sucky that we will have the same info in
multiple places (DT, GH, etc) — ideally, after some amount of timing we can
write up good feature requests, and ask the tools team to fold some of
this into the datatracker. Yes, DT does already have the "History" tab for
each draft, but the info there isn't shown on the dashboard, and you cannot
(yet) add tags, etc.

In the meantime we can probably write some simple automation to copy DT
into into GH issues…

Thoughts?  Does this seem useful?
W
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] AD Review of: draft-ietf-dnsop-dnssec-bootstrapping

[Warren Kumari]

Hi there, authors (and WG),

Thank you for this document, I found it clear, useful, and an easy read.

I do have a few comments/nits; addressing these now should help the IETF LC
and IESG evaluation go more smoothly.


Please SHOUT loudly once you've had a chance to address these, and I'll
start IETF LC.



Comments / questions:
1: Please be consistent in capitalization of  Parent, Child, Registry,
Registrar.

2: "Signaling Domains SHOULD be delegated as zones of their own, so that
the Signaling Zone's apex coincides with the Signaling Domain (such as
_signal.ns1.example.net). While it is permissible for the Signaling Domain
to be contained in a Signaling Zone of fewer labels (such as example.net),
a zone cut ensures that bootstrapping activities do not require
modifications of the zone containing the nameserver hostname."
Can you please try and reword this? I'm not entirely sure what "Signaling
Domains SHOULD be delegated as zones of their own," actually *means*. I
think I sort of do, but I don't think I could fully articulate it — perhaps
"standalone zones"?

3: "To keep the size of the Signaling Zones minimal and bulk processing
efficient (such as via zone transfers), Child DNS Operators SHOULD remove
Signaling Records which are found to have been acted upon."
This feels fairly hand-wavey (especially because it has a "SHOULD") — how
would that child operators know that the signing records have been
processed/consumed? (yes, I know, but it seems like some text it needed).
Perhaps just rewording the sentence would help - something like: "Once a
Child DNS Operator determines that specific Signaling Records have been
processed (e.g by seeing the result in the Parent), they are advised to
remove the Signaling Record. This will help keep the Signaling Zone
smaller, and bulk processing (such as via zone transfers) more efficient."?
Something like that…

4: "It is RECOMMENDED to perform queries within Signaling Domains (Section
4.2) with an (initially) cold resolver cache or to limit the TTL of cached
records to the interval between scans, as to retrieve the most current
information regardless of TTL."
This sentence doesn't really work - it says to "limit the TTL of cached
records" so you have the most current information regardless of the TTL.
Perhaps just adding "regardless of the original TTL" (or "actual TTL" or
something...)

5: "(When a batch job is used to attempt bootstrapping for a large number
of delegations, the cache does not need to get cleared in between queries
pertaining to different Children.)"
Is this always true? I'm not sure, but it feels like there could be cases
where there are delegations to domain early on in a run, which you later
discover later in a run is also being bootstrapped. E.g you start with
example.com and it uses ns1.example.net. Later on you discover than
example.net is also bootstrapping, but it is already in the cache…. This
might be a really uncommon corner case (and I might be completely wrong
about this causing an issue!), but it seems like unless we are 100% sure we
should just drop this sentence (and implementers can figure out if the
optimization is worth potentially stepping on a rake :-P).
I'll happily note that I cannot figure out if my concern is valid, but it
*feels* like there is something scary here…


Nits:
1: s/involes/involves/

2: s/For lack of a comprehensive DNS-innate/Due to the lack of a
comprehensive DNS-innate/

3: "The Parent can then use this signal to cryptographically validate the
CDS/CDNSKEY records found at an insecure Child zone's apex, and upon
success secure the delegation."
Suggest: "The Parent can then use this signal to cryptographically validate
the CDS/CDNSKEY records found at an insecure Child zone's apex and, upon
success, secure the delegation." (I generally avoid noting comma-related
nits, but this one triggered my OCD, so…)

4:
O: "Other applications might arise in the future, such as publication of
API endpoints for third-party interaction with the DNS Operator or of other
operational metadata which the DNS Operator likes to publish."
P: "Other applications might arise in the future, such as publishing API
endpoints for third-party interaction with the DNS Operator or other
operational metadata that the DNS Operator likes to publish."
C: Flow / readability.

5: "To publish a piece of information about the Child zone"
s/a piece of// (I think that this works better, without changing the
meaning / intent).

6: "If, however, an error condition occurs, in particular: [many many
things] the Parental Agent MUST abort the procedure."
This seems somewhat tricky to read / parse — by the time you get down to
the "the Parental Agent MUST abort the procedure" bit you've forgotten
where the sentence starts. I recommend:
"If an error occurs in any of the following steps, the Parental Agent
MUST the procedure:
Step 1:... " (just a suggestion)

7: This seems a little clumsy:
"The Parental Agent does not use in-bailiwick Signaling Names during
vali

[DNSOP] Approved: draft-ietf-dnsop-dns-error-reporting - "DNS Error Reporting"

[Warren Kumari]

Hi there Authors, IESG, Secretariat, and WG,

draft-ietf-dnsop-dns-error-reporting - "DNS Error Reporting"
 is
now approved.

I'd like to thank everyone, especially the authors, and Paul Wouters, for
all of their hard work - it  significantly improved the document.

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

Re: [DNSOP] [Ext] on private use TLDS: .interNAL -> .LAN

[Warren Kumari]

On Tue, Feb 27, 2024 at 6:07 AM, Toerless Eckert  wrote:

> Thanks, Paul
>
> My comment:
>
> https://www.icann.org/en/public-comment/proceeding/
> proposed-top-level-domain-string-for-private-use-24-01-2024/submissions/
> eckert-toerless-27-02-2024 Summary of Submission:
> I would like to see a BCP RFC on the use of the "internal" TLD, and ICANN
> should not finalize availability of the TLD unless that RFC exists.
>


Some history: This was started in the IETF, as
https://www.ietf.org/archive/id/draft-wkumari-dnsop-internal-00.txt , and
this was presented at IETF 100 —
https://datatracker.ietf.org/meeting/100/materials/slides-100-dnsop-sessa-draft-wkumari-dnsop-internal

The message from the DNSOP participants was very clear (and, IMO,
correct):  this is not IETF work, and should be discussed in ICANN[0]... and
so the draft / idea was taken to ICANN SSAC, and progressed through that.

I'll point out that there isn't really a "availability of the TLD" - it is
simply a commitment to not delegate a strong, and so people can use a part
of the namespace for their internal use, secure in the knowledge that it
won't be delegated…

W
[0]: I knew this when I wrote the draft — but, the IETF is a nicer place to
work :-)


> Cheers
> Toerless
>
> On Sun, Jan 28, 2024 at 02:42:09AM +, Paul Hoffman wrote:
>
> Wearing my ICANN hat:
>
> When a topic is in a public comment period, it is very appropriate and
> appreciated for community members to send comments in, as Paul Marks has.
> Having a discussion on an external forum will have no effect on the public
> comment period because the comment from Paul Marks is already logged. When
> the comment period is over, IANA will read all the comments and respond in
> a single large report.
>
> (In case you want to comment: https://www.icann.org/en/public-comment/
> proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024)
>
> --Paul Hoffman
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

[Warren Kumari]

On Wed, Jan 31, 2024 at 8:57 PM, Paul Hoffman 
wrote:

> On Jan 31, 2024, at 17:39, Paul Wouters  wrote:
>
> On Wed, 31 Jan 2024, Paul Hoffman wrote:
>
> On Jan 31, 2024, at 15:15, Paul Wouters  wrote:
>
> Can they write a draft with why they are going against the RFC?
>
> Yes, that is possible. However, I think it would be unfair to the DNS
> community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to
> happen, and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis
> less honest about the current and possible future waiting for that to
> happen.
>
> As Mark just clarified. This isn't glue, so perhaps the text just needs
> updating.
>
> The current text is:
>
> If some root server addresses are omitted from the Additional section,
> there is no expectation that the TC bit in the response will be set to 1.
> At the time that this document is written, many of the root servers are not
> setting the TC bit when omitting addresses from the Additional section.
>
> Note that  updates 
> with respect to the use of the TC bit. It says "If message size constraints
> prevent the inclusion of all glue records for in-domain name servers, the
> server must set the TC (Truncated) flag to inform the client that the
> response is incomplete and that the client should use another transport to
> retrieve the full response."
>
> Maybe we should add to the second paragraph:
>
> Note, however, the root server addresses are not glue records, so setting
> the TC bit in truncated responses from the root servers is not required by
> RFC 9471.
>
> Does this solve your and Warren's issues?
>


Oh. Erm… yes!
That's a short, simple and elegant solution, and works for me…. I was
expecting this to require much more text changes, but this works. Nice!



> It raises another question why some root servers do set the TC bit though.
>
> If I read 1035 correctly, it specified the TC bit for all truncation, not
> just for truncated glue records.
>

Yup. RFC9471 updates RFC1034 to say:
"NEW:

   |  Copy the NS RRs for the subzone into the authority section of the
   |  reply.  Put whatever NS addresses are available into the
   |  additional section, using glue RRs if the addresses are not
   |  available from authoritative data or the cache.  If all glue RRs
   |  for in-domain name servers do not fit, set TC=1 in the header.  Go
   |  to step 4.
"
This says that all glue has to fit before setting TC.

I personally still think of "TrunCation" as meaning what the English word
means:

   1. shorten the duration or extent of.
   2. shorten by cutting off the top or end.
   3. (botany) (of a leaf, feather, or other part) ending abruptly as if
   cut off across the base or tip.

Or as it said in 1035:
"TC  TrunCation - specifies that this message was truncated
due to length greater than that permitted on the
transmission channel."

… but I understand that I can be in the rough….

Whatever the case, it seems like there is some confusion / lack of
agreement on what all RFC9471 means…

W


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

[DNSOP] AD Review of draft-ietf-dnsop-rfc8109bis

[Warren Kumari]

Hi there, authors (and WG),

Thank you for this document — I have some questions / comments before I can
progress it.

Firstly, the (presumably) easy one:
The document says:
"This document, when published, obsoletes RFC 8109." - can you add
something along the lines of "Section 1.1 contains a list of changes from
RFC 8109" or similar….

Now the harder one…
Sec 4.2:
"If some root server addresses are omitted from the Additional section,
there is no expectation that the TC bit in the response will be set to 1.
At the time that this document is written, many of the root servers are not
setting the TC bit when omitting addresses from the Additional section.

Note that [RFC9471] updates [RFC1035] with respect to the use of the TC
bit. It says "If message size constraints prevent the inclusion of all glue
records for in-domain name servers, the server must set the TC (Truncated)
flag to inform the client that the response is incomplete and that the
client should use another transport to retrieve the full response."  "

IMO, this text is confusing….
It sounds like it is saying "RFC9471 says you must set TC if you truncate
the glue. The root server folk are ignoring RFC9471, bad root server folk…"

I have read the discussion in the WGLC ( inc
https://mailarchive.ietf.org/arch/msg/dnsop/wtjuoVqkKmww988Hyq2QDq_nKpA/
and am assuming it was rewritten as "If some root server addresses are
omitted from the Additional section…".), but I don't really think that
really addresses my concern  — it's easy to miss the subtleties and the
"all glue records" vs "some addresses" bit is tricky.

It's also true that "At the time that this document is written, many
of the root
servers are not setting the TC bit when omitting addresses from the
Additional section." — RFC9471 was only published at the end of September,
there is an open BIND bug to update this behavior (I think! -
https://gitlab.isc.org/isc-projects/bind9/-/issues/4540 ), and is planned
to change in 9.19.x (I think!)

So,  while what it written is all technically correct[0], the tone feels
weird. I think that some of this is because ot the timing of when this and
RFC9471 were written.

RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will
survive at least that long.

I don't know how we address my concern, but it feels like, in e.g 6 years,
this text will have aged poorly...
Can you see about some more massaging of this text?

W
[0]: The best kind of correct….
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dealing with some open Errata:

[Warren Kumari]

Whoops, apologies, the previous reply was in my Drafts and I hit send on
the wrong version. 

I will ask the IANA to update the reference to be RFC4340, and include a
link to this thread.

W




On Mon, Jan 29, 2024 at 1:27 PM, Warren Kumari  wrote:

> On Mon, Jan 15, 2024 at 7:51 PM, John Levine  wrote:
>
>> It appears that Paul Wouters  said:
>>
>> Section 4.1.2. says:
>>   | URI| _dccp | [RFC7566] |
>>
>> I think this might have been part of a list used to "reserve" the names
>> of (transport) protocols, so that constructs like _25._quic.example.com
>> could be constructed where the _name denotes the protocol and not the name
>> of something. I think dccp got added to this list because it is references
>> as a "transport protocol" in RFC4340 and the author wanted to make sure
>> transport protocol names were not accidentally squatted by newly invented
>> things with a clashing name/acronym.
>>
>> I think I'm the one who added it and that was definitely the idea. You
>> should be able to use SRV or URI with any transport protocol so in view of
>> the modest set of transport protocols in use, we might as well reserve
>> their names. Dunno where that RFC number came from, though.
>>
>
>
> Okey donkey —I think that the best outcome then is to do what Dave
> suggested above — "leave the registration but take out the reference.".
>
> I'd love to be able to ask IANA to make the reference be "Because, well,
> we felt like it….",  but I'm trying to at least pretend to be a grownup, so
> I won't…
>
> W
>
>
>
>> R's,
>> John
>>
>> ___
>> 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] Dealing with some open Errata:

[Warren Kumari]

On Mon, Jan 15, 2024 at 7:51 PM, John Levine  wrote:

> It appears that Paul Wouters  said:
>
> Section 4.1.2. says:
>   | URI| _dccp | [RFC7566] |
>
> I think this might have been part of a list used to "reserve" the names of
> (transport) protocols, so that constructs like _25._quic.example.com
> could be constructed where the _name denotes the protocol and not the name
> of something. I think dccp got added to this list because it is references
> as a "transport protocol" in RFC4340 and the author wanted to make sure
> transport protocol names were not accidentally squatted by newly invented
> things with a clashing name/acronym.
>
> I think I'm the one who added it and that was definitely the idea. You
> should be able to use SRV or URI with any transport protocol so in view of
> the modest set of transport protocols in use, we might as well reserve
> their names. Dunno where that RFC number came from, though.
>


Okey donkey —I think that the best outcome then is to do what Dave
suggested above — "leave the registration but take out the reference.".

I'd love to be able to ask IANA to make the reference be "Because, well, we
felt like it….",  but I'm trying to at least pretend to be a grownup, so I
won't…

W



> R's,
> John
>
> ___
> 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] Errata 7689 against RFC 8906, "A Common Operational Problem in DNS Servers: Failure to Communicate"

[Warren Kumari]

Thanks all, done!
W


On Tue, Jan 16, 2024 at 5:01 AM, Joe Abley  wrote:

> Hi Warren,
>
> On 15 Jan 2024, at 22:49, Warren Kumari  wrote:
>
> Seeing as the document says you should "expect: flag: aa to be present",
> it does seem like it would be better if it also said: "expect: flag: do to
> be present if an RRSIG is in the response", as that is more inline with
> what someone writing a test would see.
>
> If someone checks for "flag: aa" literally in output they will be
> disappointed, given the output in your example.
>
> Similarly, if someone checks for "flag: do" literally in output they will
> suffer a different kind of disappointment, since the dig output uses
> "flags" plural.
>
> However, I think it would actually be better to detach the language more
> clearly from the output of a particular version of a particular tool (not
> just in this document, but in all documents). It's not like dig is the only
> game in town, and it's not like the output of dig is invariant between
> releases.
>
> This seems like a fairly simple clarification / place where things could
> have been worded better, but I don't think that it rises to the level of a
> "Verified" errata, but it's also not wrong, so my proposed resolution is:
>
> Accept the errata as Editorial, Hold for Document Update.
>
> That seems reasonable to me.
>
> Joe
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Errata 7689 against RFC 8906, "A Common Operational Problem in DNS Servers: Failure to Communicate"

[Warren Kumari]

Hi there all,

As part of the Great Errata Cleanup of 2024, I'm going through reported
Errata and trying to close them.
I'm just dealing with the ones that I can do myself, but there are some
which I need WG input on.

I'd like to get feedback by Monday Jan 29th, otherwise I'll just go with my
proposed resolutions below.

Errata: https://www.rfc-editor.org/errata/eid7689


I don't really think that the original RFC is *wrong*, but it could be
clearer.

It uses 'dig' as the testing mechanism, and says:

Check that DO=1 queries work (EDNS supported):¶


dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server

expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: DO=1 to be present if an RRSIG is in the response
expect: EDNS Version 0 in response
expect: flag: aa to be present

The actual output from dig goeth thus:

dig +nocookie +edns=0 +noad +norec +dnssec soa ietf.org @
jill.ns.cloudflare.com.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20613
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232



Seeing as the document says you should "expect: flag: aa to be present", it
does seem like it would be better if it also said: "expect: flag: do to be
present if an RRSIG is in the response", as that is more inline with what
someone writing a test would see.

This seems like a fairly simple clarification / place where things could
have been worded better, but I don't think that it rises to the level of a
"Verified" errata, but it's also not wrong, so my proposed resolution is:

Accept the errata as Editorial, Hold for Document Update.

("Hold for Document Update - The erratum is not a necessary update to the
RFC. However, any future update of the document might consider it and
determine whether it merits including in an update." — from:
https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
 )

Can anyone not live with this? Please speak up by Jan 29th, otherwise I'll
do what's above.
W
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Dealing with some open Errata:

[Warren Kumari]

[ + Dave Crocker (author), Paul Wouters, Frederico Neves (registry
experts)]

Hi there all,

As part of the Great Errata Cleanup of 2024, I'm going through reported
Errata and trying to close them.
I'm just dealing with the ones that I can do myself, but there are some
which I need WG input on.

These include two Errata filed by Bernie Hoeneisen (author of RFC6118)
against RFC8552 - "Scoped Interpretation of DNS Resource Records through
"Underscored" Naming of Attribute Leaves"


I'd like to get feedback by Monday Jan 29th, otherwise I'll just go with my
proposed resolutions below.



Errata1: https://www.rfc-editor.org/errata/eid7066
---
Section 4.1.2. says:
  | URI| _dccp | [RFC7566] |

It should say:
?

Notes:
Wrong reference. RFC7566 does not even mention "dccp". Unaware of a useful
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
—-

I **think** that the correct reference for this is actually RFC7553 - "The
Uniform Resource Identifier (URI) DNS Resource Record"
. Note that this initially
confused me, because I was looking for DCCP (and TCP and UDP) in the URI
*registry*, not in the DNS RR definition.


My proposed resolution: Mark Errata verified, update reference to be
RFC7553.




Errata 2: https://www.rfc-editor.org/errata/eid7068:
—-
Section 4.1.2. says:
  | URI| _tcp  | [RFC6118] |
  | URI| _udp  | [RFC6118] |

It should say:
?

Notes:
Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Unaware of
useful reference(s). Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
---


My proposed resolution: Same as above.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Notification Call for Adoption: draft-bash-rfc7958bis

[Warren Kumari]

I think that this is an important and useful document, and that it should
be adopted….



W



On Mon, Dec 18, 2023 at 12:15 AM, Geoff Huston  wrote:

> I am in support of adoption by the Working Group. The process of peer
> review has proved to be highly valuable over the years and the result is
> generally a more robust framework for critical elements of the DNS
> infrastructure.
>
> regards,
>
> Geoff
>
> On 17 Dec 2023, at 1:55 am, Tim Wicinski  wrote:
>
> Dear WG,
>
> The working group was asked to adopt draft-bash-rfc7958bis “DNSSEC Trust
> Anchor Publication for the Root Zone” as a working group document, and the
> call went out on October 12 this year. So far we've seen one support
> email on the list, and during the IETF 117 DNSOP WG session the chairs
> further indicated that they would like to see adoption of the document.
>
> This document, a bis version, introduces several changes compared to RFC
> 7958:
>
> * There is a significant technical change from erratum 5932  rfc-editor.org/errata/eid5932>. This is stated in the seventh paragraph
> of section 2.1.2.
>
> * Added the optional public key element
>
> * The reference to the DNSSEC Practice Statement [DPS] has been updated.
>
> * Explicitly say that the XML documents may contain XML comments in them.
>
> The document is important to DNS operators and implementers because it
> describes the format and publishing mechanisms that IANA has used to
> distribute the DNSSEC trust anchors.
>
> Although the document received positive support during presentations at
> IETF 117 and 118, we’ve observed limited support on the mailing list.
> Therefore, the chairs seek additional feedback from the working group and
> invite your opinion on its suitability for adoption by DNSOP. Please share
> your comments on the list, clearly stating your opinion, and indicate if
> you are willing to contribute text, review, etc.
>
> The Call for Adoption will conclude next Friday, December 22, 2023.
>
> Tim
> for the chairs
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-14.txt

[Warren Kumari]

Dear DNSOP,

Just a quick note / reminder to the WG:
This is the document which moved to the ISE and
became draft-makarenko-gost2012-dnssec. It is still sitting in my queue,
and has been for 400+ days. I'm planning on marking it DEAD
once draft-makarenko-gost2012-dnssec progresses (which, we think, will be
soon).

This update is just Dmitry removing himself as an author.

W



On Tue, Dec 12, 2023 at 7:56 PM,  wrote:

> Internet-Draft draft-ietf-dnsop-rfc5933-bis-14.txt is now available. It is
> a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
>
> Title: Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource
> Records for DNSSEC Authors: Boris Makarenko
> Vasily Dolmatov
> Name: draft-ietf-dnsop-rfc5933-bis-14.txt
> Pages: 11
> Dates: 2023-12-12
>
> Abstract:
>
> This document describes how to produce digital signatures and hash
> functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for
> DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System
> Security Extensions (DNSSEC).
>
> This document obsoletes RFC 5933 and updates RFC 8624.
>
> The IETF datatracker status page for this Internet-Draft is: https://
> datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-14
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc5933-bis-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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-error-reporting-07: (with DISCUSS)

[Warren Kumari]

On Tue, Dec 12, 2023 at 9:18 PM, Paul Wouters  wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-dnsop-dns-error-reporting-07: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
>
> --
> DISCUSS:
> --
>
> This document gives no guidance on the content of the TXT resource record
> RDATA for this record.
>
> Based on this, I assume the error report query is of qtype TXT, but this
> is not specified anywhere in the document. Someone could use a qtype of
> CNAME or ANY or just A or . Can this be stated explicitly ?
>

Erm, I think that it is?

Section 3.  Terminology
"   Report query:  The DNS query used to report an error is called a
  report query.  A report query is for a DNS TXT resource record
  type.  The content of the error report is encoded in the QNAME of
  a DNS request to the monitoring agent."

Section 4.  Overview
"The resulting report query is sent as a standard DNS query for a TXT
   DNS resource record type by the reporting resolver."

7.  IANA Considerations
   "IANA is requested to assign the following Underscored and Globally
   Scoped DNS Node Name registry:

 RR Type  _NODE NAME  Reference
 ---  -
 TXT  _er [this document]
"


> In Section 6.1.1. Constructing the Report Query, only the QNAME
> construction is documented, not the QTYPE (or CLASS but there is a
> reference that says only IN is supported)
>
> While no guidance on (TXT?) RDATA sending is fine, there should really be
> a Security Consideration on what to do with any RDATA. Let's avoid another
> vector for log4j.
>


Yup, this is a good point — the document says:
" It is RECOMMENDED that the authoritative server for the agent
domain replies with a positive response (i.e. not NODATA or
NXDOMAIN) containing a TXT record.".
Would simply noting that this is untrusted data and should be sanitized /
something before stuffing it into logs / displaying it / etc?


The reporting resolver MUST NOT use DNS error reporting to report a failure
> in resolving the report query.
>
> This might be tricky to implement. The resolver might not know why another
> thread is resolving some A/ record. For example if nohats.ca uses a
> reporting fqdn of foobar.fi, why shouldn't validation failures on foobar.
> fi try to report that to foobar.fi, if they themselves use a reporting
> fqdn.
>
> Similarly, recommending disabling DNSSEC for these queries can be tricky,
> if resolving the reporting fqdn requires a number of related DNS queries
> for NS, DS, A/, CNAMEs). I think it is better to not recommend this and
> let failures be failures. If the reporting fqdn fails to resolve, abort
> trying to report the failure.
>
> Which of course brings up: Should there be a consideration for the
> reporting fqdn not being in-domain ? eg ns1.nohats.ca serving nohats.ca
> should probably not use er.nohats.ca.
>
> The er QNAME construction assumes there was only 1 QTYPE. There are drafts
> being floated that have more than one QTYPE. How to construct the QNAME for
> those?
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC7477 typo?

[Warren Kumari]

On Fri, Dec 01, 2023 at 4:03 PM, Mark Andrews  wrote:

> It’s stopping the serial changing too fast.
>


Well, yeah, obviously, but what is "too fast"? Why is 2^16 OK but 2^20 or
2^30 or 2^18.365 not?

W



> --
> Mark Andrews
>
> On 2 Dec 2023, at 06:43, Warren Kumari  wrote:
>
>
> Dear DNSOP (and Wes),
>
> I was wading through my mailbox and realized that I hadn't seen any
> discussion of this.
>
>
> I'm quite sure that 2^16 is not a typo (there is quite a lot of text
> around this section), but I cannot really figure out / remember what
> exactly the threat model here is.
>
> Here are the relevant paragraphs:
> Sec 2.1.1.1.  The SOA Serial Field:
> "Although Section 3.2 of [RFC1982] describes how to properly implement
>a less-than comparison operation with SOA serial numbers that may
>wrap beyond the 32-bit value in both the SOA record and the CSYNC
>record, it is important that a child using the soaminimum flag must
>not increment its SOA serial number value more than 2^16 within the
>period of time that a parent might wait between polling the child for
>the CSYNC record."
>
> Sec 5.  Security Considerations
> "To ensure that an older CSYNC record making use of the soaminimum
>flag cannot be replayed to revert values, the SOA serial number MUST
>NOT be incremented by more than 2^16 during the lifetime of the
>signature window of the associated RRSIGs signing the SOA and CSYNC
>records.  Note that this is independent of whether or not the
>increment causes the 2^32 bit serial number field to wrap."
>
>
> I can (mostly) understand why the SOA must not fully wrap (2^32) or
> probably even 1/2 wrap (2^31), but what bad thing would happen if it
> incremented by e.g 2^24?
>
> It might just be that 2^16 was sufficiently far from 2^32 that it was
> viewed as "conservative even with much slop", but that feels somewhat like
> a cop-out…
>
> Can someone help me understand?
> W
>
>
>
> On Thu, Nov 09, 2023 at 1:45 PM, Bob Harold  wrote:
>
>> https://datatracker.ietf.org/doc/html/rfc7477#section-5
>> section 5.  Security Considerations
>> last paragraph
>>
>> "the SOA serial number MUST NOT be incremented by more than 2^16"
>>
>> 2^16 is a very small fraction of the 2^32 serial number space.  It seems
>> that half of the 2^32 would be sufficient, which is 2^31 (not 2^16).  Is
>> that a typo, or is there a reason for the small range?
>>
>> --
>> Bob Harold
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC7477 typo?

[Warren Kumari]

Dear DNSOP (and Wes),

I was wading through my mailbox and realized that I hadn't seen any
discussion of this.


I'm quite sure that 2^16 is not a typo (there is quite a lot of text around
this section), but I cannot really figure out / remember what exactly the
threat model here is.

Here are the relevant paragraphs:
Sec 2.1.1.1.  The SOA Serial Field:
"Although Section 3.2 of [RFC1982] describes how to properly implement
   a less-than comparison operation with SOA serial numbers that may
   wrap beyond the 32-bit value in both the SOA record and the CSYNC
   record, it is important that a child using the soaminimum flag must
   not increment its SOA serial number value more than 2^16 within the
   period of time that a parent might wait between polling the child for
   the CSYNC record."

Sec 5.  Security Considerations
"To ensure that an older CSYNC record making use of the soaminimum
   flag cannot be replayed to revert values, the SOA serial number MUST
   NOT be incremented by more than 2^16 during the lifetime of the
   signature window of the associated RRSIGs signing the SOA and CSYNC
   records.  Note that this is independent of whether or not the
   increment causes the 2^32 bit serial number field to wrap."


I can (mostly) understand why the SOA must not fully wrap (2^32) or
probably even 1/2 wrap (2^31), but what bad thing would happen if it
incremented by e.g 2^24?

It might just be that 2^16 was sufficiently far from 2^32 that it was
viewed as "conservative even with much slop", but that feels somewhat like
a cop-out…

Can someone help me understand?
W



On Thu, Nov 09, 2023 at 1:45 PM, Bob Harold  wrote:

> https://datatracker.ietf.org/doc/html/rfc7477#section-5
> section 5.  Security Considerations
> last paragraph
>
> "the SOA serial number MUST NOT be incremented by more than 2^16"
>
> 2^16 is a very small fraction of the 2^32 serial number space.  It seems
> that half of the 2^32 would be sufficient, which is 2^31 (not 2^16).  Is
> that a typo, or is there a reason for the small range?
>
> --
> Bob Harold
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic

[Warren Kumari]

On Mon, Nov 20, 2023 at 6:08 PM, Paul Hoffman 
wrote:

> [[Forwarding this to DNSOP because apparently the IESG forgot to...]]
>

Thank you.



> The IESG has received a request from an individual participant to make the
> following status changes:
>
> - RFC5933 from Proposed Standard to Historic
> (Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for
> DNSSEC)
>
>

So, the IANA has a question:
IANA Question --> What about the registrations that currently reference
RFC5933?

Should the registrations currently referencing RFC5933 be marked
"OBSOLETE," "DEPRECATED," changed in some other way, or left alone?

If IANA is asked to make changes to these registrations, IANA will add a
link to the status change document to the registrations."
—---


Seeing as GOST R34.10-2001 and GOST R 34.11-94. GOST 34.10-2001 and GOST
34.11-94 were deprecated by the Orders of the Federal Agency for Technical
Regulation and Metrology of Russia (Rosstandart) in August 2012, and
RFC5933 is being made historic (replaced by draft-makarenko-gost2012-dnssec
which describes how to use the GOST 2012 algs), I think that "OBSOLETE, see
" is best, but I wanted the WG's input…



W
[0]: This happened because the AD (me) requests that IETF LC be started,
and then the secretariat actually kicks it off. In this case I requested it
over the weekend, and was out on Monday.


> The supporting document for this request can be found here:
>
> https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic/
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2023-12-18. Exceptionally, comments
> may be sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The affected document can be obtained via
> https://datatracker.ietf.org/doc/rfc5933/
>
> IESG discussion of this request can be tracked via https://datatracker.
> ietf.org/doc/status-change-gost-dnssec-to-historic/ballot/
>
> ___
> 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] [Editorial Errata Reported] RFC8806 (7692)

[Warren Kumari]

Doh!  That is correct…

Thank you!
W


On Tue, Oct 31, 2023 at 8:59 AM, Joe Abley  wrote:

> Verified.
>
> On 31 Oct 2023, at 04:10, RFC Errata System 
> wrote:
>
> The following errata report has been submitted for RFC8806,
> "Running a Root Server Local to a Resolver".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7692
>
> --
> Type: Editorial
> Reported by: Deliang Chang 
>
> Section: 3
>
> Original Text
> -
> There is a risk that a system using a local authoritative server for the
> root zone cannot refresh the contents of the root zone before the expire
> time in the SOA. A system using a local authoritative server for the root
> zone MUST NOT serve stale data for the root zone. To mitigate the risk that
> stale data is served, the local root server MUST immediately switch to
> using non-local root servers when it detects that it would be serving state
> data.
>
> Corrected Text
> --
> There is a risk that a system using a local authoritative server for the
> root zone cannot refresh the contents of the root zone before the expire
> time in the SOA. A system using a local authoritative server for the root
> zone MUST NOT serve stale data for the root zone. To mitigate the risk that
> stale data is served, the local root server MUST immediately switch to
> using non-local root servers when it detects that it would be serving stale
> data.
>
> Notes
> -
> Based on the context, it seems that in the last sentence the intended word
> is "stale" as in stale data, instead of "state". So, I believe there might
> be a typo in the text, and the correct interpretation would be to swith
> back to the non-local root when stale data is detected.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it will be
> removed shortly by the RFC Production Center.) Please use "Reply All" to
> discuss whether it should be verified or rejected. When a decision is
> reached, the verifying party will log in to change the status and edit the
> report, if necessary.
>
> --
> RFC8806 (draft-ietf-dnsop-7706bis-12)
> --
> Title : Running a Root Server Local to a Resolver Publication Date : June
> 2020
> Author(s) : W. Kumari, P. Hoffman
> Category : INFORMATIONAL
> Source : Domain Name System Operations Area : Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
> ___
> 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] AD Review: draft-ietf-dnsop-zoneversion

[Warren Kumari]

Hi there, authors (and WG),

I support what the document is trying to accomplish — I think that
ZONEVERSIONs will be really useful once standardized and deployed.

Unfortunately though, I believe that it needs revision and clarification
before it is ready for last call.

I started performing my AD review, and found a bunch of nits (for which I
have tried to suggest some fixes). I then ran into  the description of the
LABELCOUNT parameter ("The LABELCOUNT number helps to disambiguate the name
of the zone that this ZONEVERSION refers to.  For example if the response
is a downward referral and the server is authoritative for some portion of
the QNAME that differs from a server that is below the zone cut and is
completely authoritative for a longer match of the labels in the QNAME.
Also, if the ANSWER section has more than one RR set with different zones
(like a CNAME and a target name in another zone) the number of labels in
the QNAME disambiguate such situation.") needs much more work than is
appropriate for me to provide. Even if one starts with an understanding of
what it is trying to say, this text is very very unclear.

The next few sentences don't really fix it either ("For example, a QNAME "
www.example.com." or
  "a.b.example.com" or "a.b.c.example.com" inside a "example.com." zone,
that is not delegated not authoritative for those sub-zones in the same
nameserver, has a LABELCOUNT field value of 2 for all such cases.") - what
is "that is not delegated not authoritative" supposed to mean?

In addition to the LABELCOUNT issue, the rest of the document would also
benefit from careful reading and cleanup, including of the Security
Considerations section.


Nits:
1: Abstract
O: "This "ZONEVERSION" data allows to debug and diagnose problems by"
P: "This "ZONEVERSION" data allows for debugging and diagnosing problems by"
C: Grammar.

2: Introduction.
O: "The "ZONEVERSION" EDNS option 
 [RFC6891 ] allows a DNS querier
to request to a DNS authoritative server to add an EDNS option in the
answer of such query with a token field representing the version of the
zone associated to the answered Resource Record (RR),"
P: "The "ZONEVERSION" EDNS option 
 [RFC6891 ] allows a DNS querier
to request that a DNS authoritative server add an EDNS option containing a
token field representing the version of the zone associated to the answered
Resource Record (RR),"
C: Readability - the original seemed very long and complicated.

3:
O: "DNS data is of loose coherent nature,"
P: "DNS data is of loosely coherent nature,"
C: Grammar

4:
O: "Even when in zones where the SOA serial field have the meaning of zone
version you could use a separate query to ask for the SOA RR of the zone
and therefore know its SOA serial, but such separate query is performed in
a different time and could arrive from another authoritative source (for
example, in the case the server is anycasted as described in Section 4.9
 of [RFC4786
]), so it's not directly
correlated with the original query."
C: This sentence needs a complete rewrite.

5:
O: "The ZONEVERSION EDNS extension can have different meaning depending on
the semantics of the zone maintainer and implementation of nameservers."
P: "The ZONEVERSION EDNS extension can have different meanings, depending
on the semantics of the zone maintainer and nameserver implementation"
C: This also needs a rewrite — people will ask what the different meanings
are. The next 2 sentences don't really answer that.

6:
O: "As of the writing of this document, we recognize there are cases where
nameservers use different backends for its data sources (like relational
databases or by using a different off-DNS synchronicity among others)
therefore, the SOA version field doesn't offer much relevance as a
versioning to its content, and in those cases the ZONEVERSION EDNS
extension SHOULD be extended with a different type and have an opaque value
for its data token."
C: This sentence is very unclear, but also it is not clear why this
document doesn't also create Type 1 which is just "opaque string" or
something. Aren't all versions either "something like an incrementing
serial number" or "something you are not expected to understand"?

7: The ZONEVERSION Option
O: "The OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for
queries, and MUST have the value of the length in octets for the next
OPTION-DATA for responses."
P: "The OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for
queries, and MUST have the value of the length (in octets) of the
OPTION-DATA for responses."
C: Why did this say "*next** OPTION-DATA? That implies more than one, and
(AFAIU) that cannot happen?

O: "An unsigned 1 byte Label Count number (LABELCOUNT) indicating the
numbe

[DNSOP] Warren did a bad (was Re: Datatracker State Update Notice: )

[Warren Kumari]

[ +DNSOP for real this time]
Dear DNSOP,

I accidentally did a bad.

Back in December 2022, when we were
progressing draft-ietf-dnsop-rfc5933-bis, I sent this mail, but I missed
the fact that DNSOP was not actually on the To: line, and so missed these
discussions.

This email basically just agrees with Roman's suggested path forward in
https://mailarchive.ietf.org/arch/msg/dnsop/XZoakWUDruPXylJ2wLIS4l4vevo/ ,
and asks if the ISE would take on the GOST stuff.

I also should have mentioned to the WG the ISE was
progressing draft-makarenko-gost2012-dnssec-03 and asked y'all to review.
Basically I was just received that it was finally moving along, and
completely  spaced on the "Oh, yeah, I should make sure DNSOP has seen
this" bit.

Apologies,
W

P.S: The discussions leading up to the ISE bit are all from 10-11 months
ago, so I've swapped out much of the state, and am still swapping it back
in…





On Thu, Dec 01, 2022 at 10:00 PM, Warren Kumari  wrote:

> Dear authors, and ISE (and Roman, PaulW, PaulH)
>
> Thank you for updating the document to address Paul Wouter's DISCUSS
> position ( https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/
> ballot/#draft-ietf-dnsop-rfc5933-bis_paul-wouters )
>
> Unfortunately I was unsuccessful in arguing that this should proceed in
> the IETF because:
> 1: the document only describes how to use GOST with DNSSEC (and doesn't
> define GOST itself)
> 2: RFC5933 was an IETF document which this obsoletes
> 3: the WG had updated the registry policy to allow this to become an
> Informational document and still progress in the WG.
>
> The IESG pointed to significant precedent on these sorts of documents
> going through the ISE, such as RFC 9189,
> draft-smyshlyaev-tls13-gost-suites, and draft-smyslov-ike2-gost.
>
> Roman has proposed a fairly simple, and, assuming that the ISE is willing,
> fast and easy path forward: https://mailarchive.ietf.org/arch/msg/dnsop/
> XZoakWUDruPXylJ2wLIS4l4vevo/ .
>
> So, while I'm sure that this is very frustrating to the authors, I'm
> asking you to please split the document as described. Again, I know that
> this is frustrating, and I'm willing to help with editorial issues, and
> Roman has agreed to assist as well.
>
> I'm also asking the ISE if they would be willing (please?) to take on and
> publish the (split) document, and, because it has already gone through the
> DNSOP WG, DNSOP WGLC, IETF LC, and IESG review, if they would be willing to
> fast-track it.
>
> Sorry for what I'm sure is discouraging news,
> W
>
>
>
> On Thu, Dec 01, 2022 at 11:06 AM, IETF Secretariat <
> ietf-secretariat-re...@ietf.org> wrote:
>
> IESG state changed:
>
> New State: IESG Evaluation::AD Followup
>
> (The previous state was IESG Evaluation)
>
> Datatracker URL: https://datatracker.ietf.org/doc/
> draft-ietf-dnsop-rfc5933-bis/
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

I still don't understand why (other than marketing/advertising) this is
needed — the EDE "4.18. Extended DNS Error Code 17 - Filtered" ("The server
is unable to respond to the request because the domain is on a blocklist as
requested by the client. Functionally, this amounts to "you requested that
we filter domains like this one.") seems to cover it.

If browsers are willing to do anything with the EDE codes (like "ERROR:
Your DNS filtering provider says you shouldn't go here") what additional
**important** information needs to be communicated? And if browsers are not
willing to do anything with just EDE codes, it sure doesn't seem like they
would want to do that **and** follow an unauthenticated URL…

Anything more simply adds complexity and security risks, and entails
privacy concerns for the user too…

W


On Thu, Oct 19, 2023 at 4:05 AM, Vodafone Gianpaolo Angelo Scalone <
Gianpaolo-Angelo.Scalone=40vodafone@dmarc.ietf.org> wrote:

> Hi,
>
> I think that we have now 2 good potential compromises:
>
>1. A browser interstitial page explaining that the following page is
>generated by the service that blocked the actual page, with a button
>indicating “proceed to the blocking page” and another “dismiss”
>2. A graphical representation of the blocking page, rendered as image
>with no clickable links, with a button indicating “proceed to the blocking
>page” and another “dismiss”
>
>
>
> This would be understandable by customers and provide a good user
> experience and security.
>
> In addition we could start thinking about a reputation mechanism.
>
>
>
> Kind regards
>
>
>
> Gianpaolo
>
> C2 General
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] AD Review of: draft-ietf-dnsop-dns-error-reporting

[Warren Kumari]

On Sun, Oct 15, 2023 at 5:46 PM, Roy Arends  wrote:

> Warren,
>
> Thanks for your feedback.
>
> I can add to the last line of the second paragraph in the abstract as
> follows
>
> Original:
> 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.
>
> New:
> 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 error is
> encoded in the QNAME, thus the very act of sending the query is to report
> the error.
>
> Let me know if this works for you.
>


Perfectly, and thank you.
W



> Warmly,
>
> Roy
>
> On 13 Oct 2023, at 21:59, Warren Kumari  wrote:
>
> Hi there, authors (and WG),
>
> Thank you for this document, I found it clear, useful, and an easy read.
>
> I did have one comment / clarification which I think would help the
> document.
>
> I don't think that it is especially clear to the first time reader that
> the query itself is the error report. Yes, it is stated (in the definition
> of "Report query"), and strongly implied in the last two paragraphs of the
> example, but I suspect that people will miss this. They will see "query"
> and "query report", but will assume that they should do something with the
> response to _er.1.broken.test.7._er.a01.agent-domain.example and somehow
> send the report there. People generally don't think of the qname itself
> signalling something.
>
> I don't have exact text to suggest to fix this, but perhaps something
> like:
> "The report query will ultimately arrive at the monitoring agent, and the
> monitoring agent extracts and parses the report from the query itself". or
> "The act of sending the query is itself the error report" or something?
>
> I think that this should be a simple, and clear improvement… but it's also
> entirely possible that it's just me who finds this confusing. If y'all
> think it's clear enough as is, I'm fine to start IETF LC….
>
> Please let me know LOUDLY either way,
>
> W
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] AD Review of: draft-ietf-dnsop-dns-error-reporting

[Warren Kumari]

Hi there, authors (and WG),

Thank you for this document, I found it clear, useful, and an easy read.

I did have one comment / clarification which I think would help the
document.

I don't think that it is especially clear to the first time reader that the
query itself is the error report. Yes, it is stated (in the definition of
"Report query"), and strongly implied in the last two paragraphs of the
example, but I suspect that people will miss this. They will see "query"
and "query report", but will assume that they should do something with the
response to  _er.1.broken.test.7._er.a01.agent-domain.example and somehow
send the report there. People generally don't think of the qname itself
signalling something.

I don't have exact text to suggest to fix this, but perhaps something like:
"The report query will ultimately arrive at the monitoring agent, and the
monitoring agent extracts and parses the report from the query itself". or
"The act of sending the query is itself the error report" or something?

I think that this should be a simple, and clear improvement… but it's also
entirely possible that it's just me who finds this confusing. If y'all
think it's clear enough as is, I'm fine to start IETF LC….

Please let me know LOUDLY either way,

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

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

[Warren Kumari]

On Fri, Oct 13, 2023 at 4:05 AM, tirumal reddy  wrote:

> On Thu, 12 Oct 2023 at 21:37, Tommy Pauly  org> wrote:
>
>>
>>
>> On Oct 11, 2023, at 3:17 PM, Warren Kumari  wrote:
>>
>>
>>
>>
>>
>> On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone <
>> Gianpaolo-Angelo.Scalone=40vodafone@dmarc.ietf.org> wrote:
>>
>>> I really love this draft and would like to see browser side
>>> implementation for the benefit of customers user experience. Today several
>>> services are implemented on top of DNS to filter malicious or unwanted
>>> traffic in an effective way, but customers cannot distinguish the blocking
>>> from a network error. This led to frustration or even worst put them in
>>> danger: a quick solution to the "network error" is to disable the
>>> protection and so be infected, or change browser. The server side
>>> implementation provides all the needed information to build a great user
>>> experience: in the example below I see at least 2 options
>>>
>>> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987 flags: qr rd ra;
>>> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS:
>>> version: 0, flags:; udp: 512
>>> EDE: 17 (Filtered): ({ "c": [https://blocking.vodafone.com/
>>> blockpage?list=malwarecc], "s": 1,"j": "Malware C&C", "o": "Vodafone
>>> Internet Services" }) QUESTION SECTION: malw.scalone.eu. IN A
>>>
>>> Option 1 - better user experience, some complexity to avoid security
>>> risks
>>>
>>> if the contact URI is trusted it is possible to present in the GUI a
>>> real blocking page. The problem is that untrusted providers could use this
>>> method as an attack vector. Potential solutions could be:
>>> Browsers accept Exte4nded DNS Errors only from DoH servers. URI domain
>>> has to be covered by DoH server certificate. There could potentially be a
>>> vetting process e.g. through IANA, whereby filtering providers would need
>>> to register. Only registered and approved providers would then be permitted
>>> to use this method
>>>
>>> Option 2 - Sub-optimal user experience; however, a significant
>>> improvement over today's user experience.
>>>
>>>  cannot open  because it
>>> has been filtered by 
>>> Blocking reason: 
>>>
>>>
>>>
>> Erm, can't a large amount of this already be accomplished using RFC8914
>> Extended Errors. E.g:
>> https://www.rfc-editor.org/rfc/rfc8914.
>> html#name-extended-dns-error-code-15-
>> —-
>> "4.16. Extended DNS Error Code 15 - Blocked
>> The server is unable to respond to the request because the domain is on a
>> blocklist due to an internal security policy imposed by the operator of the
>> server resolving or forwarding the query.
>>
>> 4.17. Extended DNS Error Code 16 - Censored
>> The server is unable to respond to the request because the domain is on a
>> blocklist due to an external requirement imposed by an entity other than
>> the operator of the server resolving or forwarding the query. Note that how
>> the imposed policy is applied is irrelevant (in-band DNS filtering, court
>> order, etc.).
>>
>> 4.18. Extended DNS Error Code 17 - Filtered
>> The server is unable to respond to the request because the domain is on a
>> blocklist as requested by the client. Functionally, this amounts to "you
>> requested that we filter domains like this one."
>> ---
>>
>> Yes, it doesn't give you the HTML page, but I personally view that as a
>> feature, not a bug.
>> You *know* that if my coffee-shop/hotel/car-dealer has the ability to
>> respond to every N-th DNS query with:
>> "({ "c": [https://subaru.example.com/buy-the-new-outback.html})" or "(({
>> "c": [https://www.example.com/free-donut-with-every-pumpkin-spice-latte
>> .]})"
>> they will.
>>
>> Yes, I shouldn't be trusting my coffee-shop/hotel/car-dealer's resolvers,
>> but with captive-portals and similar many people do…
>>
>>
>> Yeah, the existing error codes are quite good (and iOS and macOS natively
>> support them now!), but having more details would allow this to replace
>> more fully the cases where redirection occurs.
>>
>> I also am concerned about someone just putting advertisements or worse in
>> the contact information, so th

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

[Warren Kumari]

On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone <
Gianpaolo-Angelo.Scalone=40vodafone@dmarc.ietf.org> wrote:

> I really love this draft and would like to see browser side implementation
> for the benefit of customers user experience. Today several services are
> implemented on top of DNS to filter malicious or unwanted traffic in an
> effective way, but customers cannot distinguish the blocking from a network
> error. This led to frustration or even worst put them in danger: a quick
> solution to the "network error" is to disable the protection and so be
> infected, or change browser. The server side implementation provides all
> the needed information to build a great user experience: in the example
> below I see at least 2 options
>
> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987 flags: qr rd ra;
> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS:
> version: 0, flags:; udp: 512
> EDE: 17 (Filtered): ({ "c": [https://blocking.vodafone.com/
> blockpage?list=malwarecc], "s": 1,"j": "Malware C&C", "o": "Vodafone
> Internet Services" }) QUESTION SECTION: malw.scalone.eu. IN A
>
> Option 1 - better user experience, some complexity to avoid security risks
>
> if the contact URI is trusted it is possible to present in the GUI a real
> blocking page. The problem is that untrusted providers could use this
> method as an attack vector. Potential solutions could be:
> Browsers accept Exte4nded DNS Errors only from DoH servers. URI domain has
> to be covered by DoH server certificate. There could potentially be a
> vetting process e.g. through IANA, whereby filtering providers would need
> to register. Only registered and approved providers would then be permitted
> to use this method
>
> Option 2 - Sub-optimal user experience; however, a significant improvement
> over today's user experience.
>
>  cannot open  because it has
> been filtered by 
> Blocking reason: 
>
>
>
Erm, can't a large amount of this already be accomplished using RFC8914
Extended Errors. E.g:
https://www.rfc-editor.org/rfc/rfc8914.html#name-extended-dns-error-code-15-
—-
"4.16. Extended DNS Error Code 15 - Blocked
The server is unable to respond to the request because the domain is on a
blocklist due to an internal security policy imposed by the operator of the
server resolving or forwarding the query.

4.17. Extended DNS Error Code 16 - Censored
The server is unable to respond to the request because the domain is on a
blocklist due to an external requirement imposed by an entity other than
the operator of the server resolving or forwarding the query. Note that how
the imposed policy is applied is irrelevant (in-band DNS filtering, court
order, etc.).

4.18. Extended DNS Error Code 17 - Filtered
The server is unable to respond to the request because the domain is on a
blocklist as requested by the client. Functionally, this amounts to "you
requested that we filter domains like this one."
---

Yes, it doesn't give you the HTML page, but I personally view that as a
feature, not a bug.
You *know* that if my coffee-shop/hotel/car-dealer has the ability to
respond to every N-th DNS query with:
"({ "c": [https://subaru.example.com/buy-the-new-outback.html})" or "(({
"c": [https://www.example.com/free-donut-with-every-pumpkin-spice-latte.]})"
they will.

Yes, I shouldn't be trusting my coffee-shop/hotel/car-dealer's resolvers,
but with captive-portals and similar many people do…

W



Thank you
>
> Gianpaolo
>
> C2 General
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Warren Kumari]

On Mon, Sep 18, 2023 at 9:33 AM, Paul Wouters  wrote:

> On Sun, 17 Sep 2023, Salz, Rich wrote:
>
> [ speaking as individual only ]
>
> On the other hand, spending a week or two repeating a cycle to get an
> important term in the current document seems like a better solution.
>
> If the WG agrees that this is an important term, sure.
>
> Well, if the IETF has consensus :) I'm raising the issue during this last
> call that "round-robin" should be in the list of defined terms.
>
> I would say that if the WG didn't think it was important at the time by
> forgetting it, it probably is not an "important term", and I can see this
> not being fixed in an IETF LC anymore as an acceptable outcome.
>
> Especially as the DNS Terminology document seems to be getting refreshed
> pretty regularly to begin with.
>


I believe that we should consider adding round robin in the *next* version
of this document; this one has already had a (very extended) last call, and
we could easily get stuck in an endless loop of "just adding another term"/

Also, this sort of document would have been an ideal test case for "Living
Documents", but that particular effort never came to fruition[0].

W

[0]: After 8+ meetings, including a side meeting / BoF I realized that
consensus seemed unlikely. Almost everyone agreed that we needed something
like this, but almost everyone had a different idea of what it should look
like…



> But also, I didn't find a good definition of round robin in existing RFCs
> either. There is a mention in rfc1794 but it doesn't really define the term
> there. So I am not sure what the DNS Terminology document would reference?
>
> Paul
>
> ___
> 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] Publication has been requested for draft-ietf-dnsop-avoid-fragmentation-14

[Warren Kumari]

After discussions with the chairs, I'm (temporarily) returning this to the
WG.

W


On Fri, Aug 18, 2023 at 12:14 PM, Petr Špaček  wrote:

> On 18. 08. 23 17:33, Peter van Dijk wrote:
>
> Hello Tim,
>
> On Wed, 2023-08-16 at 15:45 -0700, Tim Wicinski via Datatracker wrote:
>
> Tim Wicinski has requested publication of
> draft-ietf-dnsop-avoid-fragmentation-14 as Best Current Practice on behalf
> of the DNSOP working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/
> draft-ietf-dnsop-avoid-fragmentation/
>
> In
> https://mailarchive.ietf.org/arch/msg/dnsop/lrPbp6B8Mkz2S7HBXlxSPoIhTOw/
> I pointed out that zero of the implementers honour item 2 in section 3.1.
>
> In
> https://mailarchive.ietf.org/arch/msg/dnsop/QOxTZHG03UVLom9E-y6iYG5s6po/
> you said "good point, we need to address this".
>
> After that I have seen no communication on the list about addressing this,
> so I'm very surprised to see this publication request.
>
> FTR I agree that this document does not describe Best _Current_ Practice,
> and to underline the point I add that
>
> D.1. BIND 9
> BIND 9 does implement recommendation 2 of Section 3.2.
>
> ... does not seem to be correct. None of the values is used, and none of
> the MAY methods is employed by BIND (in current versions).
>
> --
> Petr Špaček
> Internet Systems Consortium
>
> ___
> 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] AD Review of: draft-ietf-dnsop-rfc8499bis

[Warren Kumari]

1: Please add to the Abstract saying what this changes in RFC2308, and how
it obsoletes RFC8499.
E.g: "This document updates RFC 2308 by clarifying the definitions of
Forwarder and QNAME, and obsoletes RFC 8499 by adding multiple terms and
additional clarifications. A comprehensive list can be fond in Appendix A
and B."


Strong nit:
Abstract:
"The terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades since the
DNS was first defined."
 — I still (I commented on this when RFC8499 was originally sent to me)
really dislike the "has sometimes changed" phrasing. The terminology
**has** changed in the decades since the DNS was first defined — individual
terms may not have, but "The terminology has … changed in the decades since
the DNS was first defined." - this is clearly editorial / a personal
opinion (and I'll progress it if the authors *really* want to keep it like
this), but I think ti would be much better if it were changed.

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

Re: [DNSOP] IETF117 Chairs Actions

[Warren Kumari]

Heyya,

Just confirming that I can start IESG Eval on
draft-ietf-dnsop-caching-resolution-failures

?

I'm assuming so, but…

W


On Wed, Aug 16, 2023 at 6:57 PM, Tim Wicinski  wrote:

> All,
>
> Thanks for another productive session of DNSOP.  Paul's minutes have been
> uploaded. If you made comments at the microphone, please confirm everything
> is accurate.
>
> https://datatracker.ietf.org/doc/minutes-117-dnsop/
>
> https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf117/
> dnsop-ietf117-minutes.txt
>
>
> Actions
>
> draft-ietf-dnsop-caching-resolution-failures
>
>
>-
>
>Work to resolve questions on caching timeout value text.
>
>
> Good Discussions, let's have more:
>
>
>-
>
>draft-ietf-dnsop-cds-consistency
>
>
>
>-
>
>draft-ietf-dnsop-compact-denial-of-existence
>
>
>
> Call For Adoptions:
>
>
>-
>
>draft-thomassen-dnsop-generalized-dns-notify
>-
>
>   was going to do this after 116,
>   -
>
>   ended up with the discussion on two NOTIFY drafts
>
>
>
>-
>
>draft-bash-rfc7958bis
>-
>
>   This appears straightforward.
>
>
>
>-
>
>draft-bellis-dnsop-qdcount-is-one
>-
>
>   Ray will move Historical Text to appendix,
>   -
>
>   then will send out Call
>
>
> Current ordered list of Working Group Last Call documents:
>
>
>-
>
>draft-ietf-dnsop-dnssec-bootstrapping
>
>
>
>-
>
>draft-ietf-dnsop-rfc8109bis
>
>
>
>-
>
>draft-ietf-dnsop-svcb-dane
>
>
>
> More Discussion:
>
>
>-
>
>draft-grubto-dnsop-dns-out-of-protocol-signaling
>-
>
>   maybe ready for adoption?
>
>
>
>-
>
>draft-johani-tld-zone-pipeline
>
>
>
>-
>
>draft-dnsop-multi-alg-rules
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: rfc8499bis: lame

[Warren Kumari]

On Mon, Jun 12, 2023 at 1:14 PM, Edward Lewis 
wrote:

> On 6/8/23, 11:23 PM, "DNSOP on behalf of Bob Bownes -Seiri" <
> dnsop-boun...@ietf.org on behalf of bow...@seiri.com> wrote:
>
> I would posit that the potential to view the word as offensive has
> increased as language usage has changed in the intervening years since it
> was first used in this context.
>
> Researching a now-abandoned draft on the origin of domain names, I
> struggled to find dictionary definition of 'resolve' that matched what we
> now call DNS resolution. In the early IEN and RFC (Internet Engineering
> Notes and Request for Comments), the first uses of 'resolve' were in the
> context of a group of people deciding on a path forward. As in "the
> committee resolved to investigate..."
>
> It wasn't until I asked the authors of one of the old RFCs (I now forget
> which one) where the term 'resolve' began to mean mapping a name to a
> network address. The answer was 'from the field of compiler design.' As in
> resolving a variable name to a memory location. In hindsight, this was
> obvious but trying to go from dictionary definitions and common use then
> and now, I didn't see the link.
>
> As far as 'lame' - besides the term sliding from being an objective
> assessment to a derogatory term as time goes by, it's meaning in the DNS
> context is not clear. The use I am familiar with covers a server's response
> to a query for a name for which the server has absolutely no information,
> as opposed to looking at a delegation set which has 'issues.'
>

I have always pictured this sort of like a horse, with the zone being the
"body" of the horse, and various nameservers as being hooves at the end of
the legs. Basically, the horse is balancing on 4 nameservers. If one of the
legs is "lame", trying to use it doesn't work and the horse/zone is less
stable. If enough nameservers stop working, the horse topples over.

When I say: "I  have always pictured this …" I mean the one time that I
spent a few milliseconds going: "Oh, I wonder where that term came from?
Oh, horses get lame, makes sense, look a squirrel!"

W



Both of those deserve terms and different ones as they are different
> situations.
>
> I'm not sure the case of a server receiving a query for which it has no
> information is very important anymore. Servers now will return either
> SERVFAIL or REFUSED for it and the operationally impacting situation I was
> working has been mitigated by this. However, I have seen a situation when
> earnest traffic (not DDoS flood) has been sent to a server that was not
> (yet) configured for a zone. But this happened once and was taken care of
> locally once the sender of the traffic realized what they were doing (or
> hadn't done). Perhaps the use of 'lame' for this can be left in the
> dustbin, like so many other objects we no longer use in life. Perhaps the
> queries are just 'out of bailiwick' queries relative to the server.
>
> As far as assessing the health of a parent to child delegation, I'll leave
> terminology about that to those who work that area. Broken, damaged, etc.,
> but I bet that just about any descriptive term today may drift into other
> meanings as languages evolve.
>
> ___
> 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] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Warren Kumari]

On Fri, May 05, 2023 at 4:39 AM, Peter Thomassen  wrote:

> On 5/4/23 20:07, Havard Eidnes wrote:
>
> As an example, it's quite common for people to register a domain and point
> the DNS at some nameservers which they don't control, and have no
> relationship with.
>
> If this is common, I'm abhorred.
>
> Having the delegating party check for service for the requested zone at
> time of delegation request and refuse to update / register if this check
> fails
>
> It would be interesting to develop a consensus position on acceptance
> checks for delegations. (Obviously, that's out of scope for this draft, so
> renaming the subject.)
>
> I can see some value in such delegation checks. However, I think that very
> clear guidance on what kinds of checks are acceptable would be helpful, to
> avoid checks that primarily cause trouble. Examples:
>
> - DENIC customers have repeatedly reported to us (deSEC) DENIC's warning
> on how our SOA REFRESH and RETRY values should be related. We think it's
> entirely a matter of how the operator arranges their replication, and the
> parent should not be concerned. What's more, the DENIC recommendations are
> in contradiction to RIPE's. [1]
>
> - Lots of tools and some registries check reachability and other
> configuration details of the SOA MNAME, although the MNAME again is an
> internal matter to the operator. (Could be using a different replication
> scheme; could be a split-horizon setup; ...) For example, NIC.it
>  rejects nameservers whose SOA MNAME is a CNAME [2].
> Tools like MxToolbox, Zonemaster etc. trigger warnings when the SOA MNAME
> has no DNS service [3]. Other tools complain when the MNAME isn't
> dual-stack [4]. We receive similar complaints about the "serial date being
> in the future".
>
> - ISNIC recently started rejecting new delegation to deSEC (and warned to
> delete existing ones) because our zones allegedly don't have NS records. It
> turned out that their delegation tool did not honor the extended RCODE
> field (RFC 6891) which is why BADCOOKIE appeared like YXRRSET to them, and
> the tool gave up. (No public reference though, and it's been fixed within a
> few days.)
>
> While I'm not generally opposed to parents checking whether a delegation
> update would break the domain's resolution (this is like the CDS acceptance
> checks, and makes sense for NS, too), I do see some risk in encouraging
> people to do more checks.
>
> I imagine that others also spend time on sorting out these entirely
> unnecessary issues. If guidance were developed on delegation acceptance
> checks,
>


Well, yes… but where?

To me it feels like the IETF would be the right place to discuss and
develop the guidance (personally I think that a parent should check if the
name servers that are being proposed actually answer for the domain[0], and
strongly suggest (but do not prevent) that that be fixed[1].

As the most common place where this occurs is (citation needed!) at a TLD,
I'd think that once guidance is created, someone (SSAC?) should push for it
being strongly recommended / folded into ICANN contract.

it would be great to use the opportunity not only to encourage helpful
> checks, but also to discourage harmful ones.
>

Yup.

I think that these should be of the forms "SHOULD / SHOULD NOT /
RECOMMENDED", and not of the form "MUST / MUST NOT" — if I want to do
something silly with a domain, I should be able to (as long as it isn't
harming others).


W
[0]: Some, including myself, would call this lame, but….
[1]: As an example, I have a-random-test-domain.net pointing to
nameservers which have no idea about this domain - and I did that
intentionally…




> Thanks,
> Peter
>
> [1]: https://talk.desec.io/t/
> default-soa-does-not-match-denic-recommendations/520/2
> [2]: https://talk.desec.io/t/
> nic-it-cnamehosttest-failed-changing-nameservers/432
> [3]: https://talk.desec.io/t/invalid-soa-record/68
> [4]: https://talk.desec.io/t/reachability-of-digga-desec-io/339
>
> --
> https://desec.io/
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Thu, May 04, 2023 at 5:07 AM, Mark Delany  wrote:

> On 03May23, Edward Lewis apparently wrote:
>
> Was any "lame" situation defined which wasn't the result of a bad
> configuration?
>
> The difference between observing a symptom and diagnosing a cause is
> great. I say this to caution against tying the "why it is" with
> "what it is."
>
> This is a good point.
>
> I confess my perspective is that of the DNS admin/serving side focussed on
> "why it is" whereas lameness is most often observed as a "what it is" from
> the resolution/client-side perspective. To use your useful terms.
>
> I have one last question. Regardless of whether we agree precisely on what
> "lame" means, what is the call to action when a zone or its name servers
> are declared lame?
>

There doesn't need to be a call to action — I can say "my car squeals when
going round a corner" - "squeals" is a way to describe the noise, and it's
just an observation, just like "a-random-test-domain.net is a lame
delegation". I own both "a-random-test-domain.net" and "my car" - unless
the squealing / lameness impacts you, I don't think that there (or needs to
be) is a call to action on either.

>
> And how is that different from any other form of miscreant auth behaviour
> such as inconsistency?
>

Well, for one thing, it's not always "miscreant auth behavior" (by which
I'm assuming you mean misbehavior by the auth server / auth server
operator).

As an example, it's quite common for people to register a domain and point
the DNS at some nameservers which they don't control, and have no
relationship with. This is not "miscreant auth behaviour" by the auth
operator - they were not involved, and also have no realistic way to deal
with the issue.

If we did want to have a call to action" we could publish something saying
that pointing a domain at a name server that isn't "yours" is uncool, but I
don't really know how effective this would be…


W



> I mean if "lame" is a precious historical term that warrants considered
> clarification, surely it has a very specific value that we can all act on,
> right? So what is that very specific value?
>
> Mark.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Tue, May 02, 2023 at 7:43 PM, Havard Eidnes  wrote:

> My parent says that the NS for exmple.com are ns1.example.com, ns2.
> example.com , but I (example.com) say that my NS are ns1.example.com, ns2.
> example.com *and* ns3.example.com. I don't (personally) think that this
> is a lame delegation. Do others?
>
> Nope. Given this information, this is simply "inconsistent".
>
> If both ns1.example.com, ns2.example.com and ns3.example.com are
> configured to serve the example.com zone, and return answers with aa=1
> when queried for names in that zone, all is well and there is no instance
> of a "lame" delegation.
>
> However, if ns3.example.com isn't set up to serve the zone, and answers
> queries about names in the zone with aa=0, the delegation to that name
> server would be "lame".
>
> Flipped around: My parent says that the NS for exmple.com are ns1.example.
> com, ns2.example.com *and* ns3.example.com. I (example.com) say that my
> NS are only ns1.example.com and ns2.example.com.
>
> At this point I'd again say "inconsistent".
>
> If you query ns3.example.com, you get REFUSED. In that case I'd
> (personally) say that ns3.example.com is lame for example.com.
>
> You had to put that in there? :)
>
> Thinking a bit about it: the REFUSED error code could be the result of
> configuring a name server with recursion turned off, and if you then query
> that name server about a name in a zone it is not set up to serve, a
> REFUSED answer would be "natural" and is these days fairly common for such
> a situation.
>
> Now, as to whether that's an instance of a lame delegation? I would tend
> to say "yes".
>
> I don't think that I'd call example.com "lame", as both ns1 and ns2 work
> OK.
>
> Correct. It's the particular delegation to ns3 which is "lame".
>
> Another example: if both the parent / delegating zone and the child zone
> lists ns1.example.com, ns2.example.com and ns3.example.com, you have a
> perfectly consistent delegation. However, if one of these are not set up to
> serve the zone, the delegation of this zone to that particular name server
> would be
> "lame".
>
> I personally think that lameness is when a domain is delegated to a name
> server, but that server does not have the zone configured. A corner case is
> when the server is configured to not answer queries for that zone from that
> source address, and so returns REFUSED or possibly SERVFAIL.
>
> If we're talking about the global DNS, restricting responses on a
> publishing name server does not make much sense to me.
>

Well, perhaps - but it *is* a common deployment scenario.

Many companies use ACLs and views (or similar) to expose something like
corp.example.com, but only to "internal" IP addresses[0]. It's obviously
easier to just have one set of nameservers, so if you query e.g www.
example.com from the global Internet you get an address, but if you query
e.g accounting.corp.example.com you get REFUSED.
I slight variation on this is if the servers for example.com *do* answer
the public Internet, but have a delegation to other servers which handle
the corp.example.com zone, and these only answer queries from "inside" the
organization.


W
[0]: Obviously you can't let just anyone on the Internets know that you
have a server called e.g accounting.corp.example.com with the IP address of
192.168.13.24, because, um… well… erm.. no-one has ever really been able to
explain the threat model to me, but they are all *sure* that the sky will
fall if attackers know this… Often there is some allusion to "well, it may
leak that we working on a magic hovercraft product, because they'd see a
device called magic-hovercraft.new-products.corp.example.com
… ¯\_(ツ)_/¯



> Best,
>
> - Håvard
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Tue, May 02, 2023 at 12:14 PM, Peter Thomassen  wrote:

> On 5/2/23 17:52, Joe Abley wrote:
>
> On Tue, May 2, 2023 at 11:09, Peter Thomassen mailto:On
> Tue, May 2, 2023 at 11:09, Peter Thomassen <> wrote:
>
> If one of the NS answers non-authoritatively, then it doesn't serve a
> proper NS RRset, so it's not possible for that server's response to agree /
> be identical with that on the parent side. As a result, the delegation (to
> that server) is lame, isn't it?
>
> A nameserver can answer authoritatively for a particular query without
> being listed in any zone's NS RRSet.
>
> A response from a server doesn't necessarily include an NS RRSet anyway.
>
> Sure, but to compare to the delegation's NS RRset (as Paul was arguing),
> you'll have to ask the authoritative nameserver for the NS RRset, in which
> case the response should contain that RRset and the AA bit.
>
> Paul said that even if the AA bit was missing, that would not be lame, as
> long as the RDATA agree. I was trying to say that if the child's answer is
> indeed non-authoritative, that's not a proper situation because the two
> servers make conflicting authority claims.
>

Perhaps, but it *is* quite common (or, at least used to be quite common, I
haven't checked stats recently). A surprising number of people put some
sort of load-balancer in front of their authorative servers. These would
basically just be recursive servers which were only[0] willing to recurse
for a specific set of zones, or would do some sort of funky GSLB type
behavior, or were "DNS firewalls"(!). These often would skip setting the AA
bit, because they were, you know, not actually authorative.

What the parent and the child nameserver say w.r.t. the NS hosts' authority
> is not identical; as a result, I would call it lame. (Apologies for the
> loose wording in my earlier post; I really should be more careful.)
>


My parent says that the NS for exmple.com are ns1.example.com,
ns2.example.com , but I (example.com) say that my NS are ns1.example.com,
ns2.example.com *and* ns3.example.com. I don't (personally) think that this
is a lame delegation. Do others?

Flipped around: My parent says that the NS for exmple.com are
ns1.example.com, ns2.example.com *and* ns3.example.com. I (example.com) say
that my NS are only ns1.example.com and  ns2.example.com. If you query
ns3.example.com, you get REFUSED. In that case I'd (personally) say that
ns3.example.com is lame for example.com. I don't think that I'd call
example.com "lame", as both ns1 and ns2 work OK.

Note that both of these fail your parent and child need to be identical
test.


> Another case would be where the name server responds with REFUSED, which,
> depending on the reader's DNS expertise, could be construed as a "answering
> non-authoritatively", although it's not answer (only a response). Is this
> meant to be included in the "lame" definition?
>

I think so.

I personally think that lameness is when a domain is delegated to a name
server, but that server does not have the zone configured. A corner case is
when the server is configured to not answer queries for that zone from that
source address, and so returns REFUSED or possibly SERVFAIL.

This means that a server can be lame for a domain, or that "all of the
servers in a delegation can be lame", which I'd personally often just call
"a lame delegation".



> (It is not clear whether the verb "answering" is meant to require the
> presence of answer RRs, but I suppose so. Further, the distinction between
> "answer" and "response" may not be obvious to someone reading about "lame
> delegations" when debugging an issue, so it may be worth clarifying what's
> meant, e.g. by referring to the RCODE.)
>

Yah! I think that (personal view) the important bit is that a
(non-recursive) query is hitting a server which cannot provide a meaningful
answer, either because it doesn't have the zone configured, or perhaps
because there are "views" which hide that zone from that query address.


I'll note that this is often not the nameservers fault - as an example,
there are many  domains which are pointed at e.g ns1.google.com which
ns1.google.com has no idea about. This isn't it's fault - people just seem
to include it in their NS set for some reason ¯\_(ツ)_/¯.

  W


> Best,
> Peter
>
> ___
> 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] John Scudder's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)

[Warren Kumari]

On Wed, Apr 26, 2023 at 5:18 PM, John Scudder  wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-dnsop-alt-tld-23: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>
> --
> COMMENT:
> --
>
> One comment -- Section 3.2 has "DNS server operators MAY be aware that
> queries for name ending in .alt are not DNS names, and queries for those
> names were leaked into the DNS context." The RFC 2119 MAY appears misused
> in this context.
>
> (Also, in that quote, s/queries for name/queries for names/)
>


Fair 'nuff - fixed in PR.
W
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dnsdir telechat review of draft-ietf-dnsop-alt-tld-23

[Warren Kumari]

Just a quick more to say thank you for your review.

Warren.


On Mon, Apr 24, 2023 at 11:19 AM, Vladimír Čunát  wrote:

> Reviewer: Vladimír Čunát
> Review result: Ready
>
> There've only been nits between -22 and -23; certainly no objections there
> and thus nothing new for me to say.
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)

[Warren Kumari]

On Mon, Apr 24, 2023 at 10:11 AM, Lars Eggert  wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-dnsop-alt-tld-23: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>
> --
> COMMENT:
> --
>
> # GEN AD review of draft-ietf-dnsop-alt-tld-23
>
> CC @larseggert
>
> Thanks to Behcet Sarikaya for the General Area Review Team (Gen-ART)
> review
> (https://mailarchive.ietf.org/arch/msg/gen-art/1LB6_ujGseyZRWPgTQZrP2pS8zk).
>
>
> ## Comments
>
> ### DOWNREFs
>
> DOWNREF `[RFC8244]` from this Proposed Standard to Informational
> `RFC8244`.
> (For IESG discussion. It seems this DOWNREF was not mentioned in the Last
> Call and also seems to not appear in the DOWNREF registry.)
>
> I think RFC8244 could be cited informatively?
>


It probably could be, but it does quite a lot feel like something very
useful for the readers to, erm, read…


> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit. Some were
> flagged by automated tools (via https://github.com/larseggert/
> ietf-reviewtool), so there will likely be some false positives. There is
> no need to let me know what you did with these suggestions.
>
> ### Grammar/style
>
>  Section 2, paragraph 7
> ```
> performing aggressive use of DNSSEC- validated caches (described in
> [RFC8198
> ^
> ```
> This word seems to be formatted incorrectly. Consider fixing the spacing
> or removing the hyphen completely.
>


Thank you - it was a hidden space in the XML line break - fixed in PR.


>  Section 2, paragraph 8
> ```
> will cover all names under .alt. Currently deployed projects and protocols
> t
> ^
> ```
> A comma may be missing after the conjunctive/linking adverb "Currently".
>


I disagree on this one - we are discussing currently deployed projects, not
describing how things currently are.


>  Section 7.1, paragraph 2
> ```
> and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC
> 9156,
> 
> ```
> Do not mix variants of the same word ("minimisation" and "minimization")
> within a single text.
>

This is an UK vs US spelling difference, but seeing as the RFC uses the 's'
form I've updated it in the editors copy / Pull Request.

Thank you,
W


> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use
> the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> [IRT]: https://github.com/larseggert/ietf-reviewtool
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-alt-tld-23: (with COMMENT)

[Warren Kumari]

On Sun, Apr 23, 2023 at 4:16 PM, Paul Wouters  wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-dnsop-alt-tld-23: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>
> --
> COMMENT:
> --
>
> Some of my comments might be DISCUSS-worthy (my apologies), but I really
> don't want to block this document for any further time. But please do take
> my comments into considerations if you can do a quick ref update.
>
> The term pseudo-TLD as defined here is not how I've seen the term used. A
> pseudo TLD as I've seen it used is a TLD that's one step below a real TLD
> and runs as a general GTLD (open registration), eg "uk.com". I guess I
> would qualify the use in this document more as "fake TLD", but I can see
> how that might come over as even more perogative. So I am fine with the
> current definition and use case. Perhaps a "to be confused with" note could
> be added, but is not strictly required.
>

We've been using this terming this way since at least 2015, and so changing
it now would be very disruptive. Do you have proposed text to clarify that
it's not used to mean something like the public suffix list?


> 4. Caching DNS servers SHOULD NOT recognize names in the .alt pseudo-TLD
> as special and SHOULD NOT perform any special handling with them.
>
> There is value for a recursor to "pre-load" the proof of non-existence of
> ".alt" (the entire branch in the hierarchy) to avoid any potential leakage
> of subdomains within alt. It could potentially also reduce error message
> logs if someone starts using .alt not as a real hierarchy or using non-DNS
> valid characters in their name, eg Ulabel stuff or even binary stuff like
> 0x000100013616c7400. They could also just return NXDOMAIN instead
> of forwarding the query to the root servers to avoid a privacy leak. Or it
> could modify the question foo "foo.alt" and only send "alt" to the root. I
> see no reason such additional protection mechanisms need to violate this
> "SHOULD NOT" clause. Why not flip the statement around?
>
> 4. Caching DNS servers MAY recognize names in the .alt pseudo-TLD as
> special and MAY perform special privacy preserving methods to return
> (DNSSEC signed) NXDOMAIN answers to prevent leaking entries under the .alt
> pseudo-TLD into the global DNS.
>
> 5. Authoritative DNS servers SHOULD NOT recognize names in the
> .alt pseudo-TLD as special and should not perform any special handling
> with them.
>
> Any reason the second "should not" is lowercase ? Note that I do agree
> here, and would even say MUST NOT so that people can use DNS technology
> even if not rooted in the global DNS for their
> .alt names without having to modify existing DNS software (eg run a shadow
> .alt using DNS on port 666 or something)
>
> 6. DNS server operators will treat names in ...
>
> I find the use of "will" here a little odd. Perhaps:
>
> 6. DNS servers and operators, which whave no special handling for the .alt
> pseudo-TLD will end up treating names in ...
>
>
> 7. DNS registries/registrars for the global DNS will never register names
> in the .alt pseudo-TLD because .alt will not exist in the global DNS root
>
> "will never" seems wishful thinking. I've seen some very fraudulent stuff
> happen with DNS registries/registrars. eg what if one of them will support
> pseudo-TLDs along with real DNS domains, and includes bogus .alt
> registrations? Perhaps:
>
> 7. DNS registries/registrars for the global DNS can never legitimately
> register names in the .alt pseudo-TLD because .alt will never exist in the
> global DNS root
>

Oh, good point. Your proposed text still make it sound like they are not
allowed to support non-DNS names, and so I'm proposing:
"7. It is not possible for DNS registries/registrars to register names in
  the .alt pseudo-TLD as the .alt will not exist in the global DNS
root."

This threads the needle of not trying to tell registries and registrar what
they are allowed to do by simply point out that's it's an impossibility for
them to register *DNS* names in an undelegated name.



> Again, my apologies to Warren for not balloting a blanc YES :)
>

Nah, thanks for the comments…. and it's still a YES :-p

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

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-alt-tld-23: (with COMMENT)

[Warren Kumari]

On Mon, Apr 24, 2023 at 4:04 AM, Éric Vyncke  wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-dnsop-alt-tld-23: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>
> --
> COMMENT:
> --
>
> Thanks to the authors and the DNSOP working group, and of course to
> Suzanne for a detailed shepherd's write-up.
>
> Important document to bring some clarity for some use cases.
>
> Just two minor comments:
>
> 1/ I support Paul Wouters' issue with the name "pseudo-TLD", it is both
> too late and a bike-shedding exercice... "ghost-TLD" or "filler-TLD" or
> "dummy-TLD" would have been better
>


We had chosen pseudo-TLD because it acts like a TLD, and quacks like a TLD,
but it isn't actually a TLD because, well, it isn't a Top Level *Domain* —
it's more like a Top Level Reservation. If we'd done this all again,
perhaps we would have selected a different term, but at this point it's
been 9 years, 2 months and 16 days, and changing it now would indeed be too
late…


> 2/ in section 2, s/because .alt, by definition, is not a DNS name./because
> .alt, by this specification, is not a DNS name./ ?
>


Thank you, I've made that change in the editors copy…

W

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

Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)

[Warren Kumari]

On Tue, Apr 25, 2023 at 4:54 PM, Roman Danyliw  wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-dnsop-alt-tld-23: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>
> --
> COMMENT:
> --
>
> Thank you to Linda Dunbar for the SECDIR review.
>
> ** Section 2.
> Currently deployed projects and protocols that are using pseudo-TLDs are
> recommended to move under the .alt pseudo-TLD, but this is not a
> requirement.
>
> I don’t understand the basis of this recommendation. Projects and
> protocols using pseudo-TLDs (outside of https://www.iana.org/domains/
> reserved) are already not following published guidance. Why is there an
> expectation that this document can change behavior?
>

It's not really an expectation, more of an invitation/suggestion. At one
point this had text along the lines of "may choose to", but that was felt
to be a bit weak. There was some discussion about making this "are
RECOMMENDED to move", but that was felt to be too strong (and who the hell
are we to tell 'em what to do anyway?!). This was the happy medium we
settled on.
Good enough?


> Section 3.2. Item #3. Editorial. s/Writers of name resolution
> APIs/Creators of name resolution APIs/. Or “developers”, “implementers, or
> “designers”
>

Thank you - I've updated this to be "Developers" in Pull Request #46.

Backstory:
This section "answers" the questions from RFC6761, and Q 3 was phrased as:
"3.  Name Resolution APIs and Libraries:
   Are writers of name resolution APIs and libraries expected to make
their software recognize these names as special and treat them
differently?  If so, how?"
We'd just sort of followed along from the language.



> ** Section 3.2. Item #7
> 7. DNS registries/registrars for the global DNS will never register names
> in the .alt pseudo-TLD because .alt will not exist in the global DNS root.
>
> Items #4 – 6 on this list use RFC2119 language to make the expected
> behavior clear. This text seems to be written in an aspiration form
> describing what registries/registrars will do, without explicitly
> prohibiting them with normative language. Is there a reason for that?
>


Yup, actually 2 reasons:
1: .alt will not exist in the DNS, and so it's not possible for DNS
registries and registrars to register DNS names. We don't tell pigs that
they MUST NOT fly, and so telling registries and registrars that they MUST
NOT do something that they are unable to  seemed odd. But, Paul Wouters
also pointed at this text in his ballot, and that it is unclear, so I've
suggested (in PR  46) this instead:
"7. It is not possible for DNS registries/registrars to register DNS names
  in the .alt pseudo-TLD as the .alt will not exist in the global DNS
root."

2: there is some sensitivity here. ICANN regulates registries and
registrars, and I was trying to be extra careful to not accidentally step
on toes and imply that the IETF was telling 'em what to do…

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

Re: [DNSOP] [Ext] Meaning of lame delegation

[Warren Kumari]

On Tue, Apr 11, 2023 at 6:57 PM, Paul Hoffman 
wrote:

> On Apr 11, 2023, at 3:06 PM, Paul Wouters  wrote:
>
> No one proposed to retire the term?
>
> Not yet, I believe.
>
> If unclear and additionally inappropriate from an inclusive language point
> of view, why not document the term as is, with a note explaining it is
> incomplete (without trying to fix it) and calling the term historic?
>
> The term is not "historic" in the sense that it is still in active use,
> albeit with somewhat different definitions depending on the speaker or
> reader.
>


Yup, lame delegation and lame server are still in very common use — and
(IMO) it's usually clear from context what is being communicated. If I'm
trying to troubleshoot an issue and say:
"Huh! ns2.example.net is lame for example.com", the person I'm talking to
is likely to grok what I'm saying (and if they don't, they'll ask for
clarification!).

Paul: I think that your addition is a fine one. Also, thank you for dealing
with all this terminology faff; it's a somewhat thankless, but important
document (and if I tried to write RFC8499 most of it would end up like:
"Label: You know, the bits between the dots. Like, um, thingie.example.com -
these are all labels. Oh, and probably LDH.. you know, labels…").

“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it
means just what I choose it to mean—neither more nor less.” “The question
is,” said Alice, “whether you can make words mean so many different
things.” “The question is,” said Humpty Dumpty, “which is to be
master—that’s all.”
 — Lewis Carrol (AKA, Charles L. Dodgson, which is nicely ironic in this
case :-))

W


Ecouraging people to not use it is fine, but maybe out of place for a
> terminology document. If you disagree, please propose the wording you would
> like to see in the document.
>
> --Paul Hoffman
> ___
> 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] Meaning of lame delegation

[Warren Kumari]

On Mon, Apr 10, 2023 at 5:13 PM, Mats Dufberg <
mats.dufberg=40internetstiftelsen...@dmarc.ietf.org> wrote:

>
>
>
> mats> For the *delegation* to be lame it is not enough for one name
> mats> server to be ``broken''. The entire set must be such that the path
> mats> to the child zone content is not available.
>
> mats> For individual name servers it could be meaningful that say that
> mats> it is a *lame name server* in relation to a certain zone.
>
> Paul> I like this distinction. Agree that calling just one server not
> working
> Paul> is a lame name server.
>
> Paul> Still want better clarity for lame delegation on if we really care
> why
> Paul> we aren't getting auth/AA responses from at least one nameserver.
> If no
> Paul> listed nameserver gives auth/AA, I'd call that a clear criteria for
> lame
> Paul> delegation, regardless of the underlying reason, at least as far as
> a
> Paul> recursive server should care.
>
> Paul> Humans debugging may care but I don't see a "better" definition of
> lame
> Paul> server really informs that debugging process.
>
>
>
> I agree with you. The first step is to see that
>
> the delegation is lame or the server is lame. That is
>
> enough to conclude that the service is not provide at
>
> all (lame delegation) or from that server (lame server,
>
> repectively.
>
>
>
> The second step is to analyze why – no IP address avaiable,
>
> the IP address not reachable, server not responding with
>
> a DNS response, unexpect RCODE value or not authoritative.
>


I'm not the sharpest knife in the drawer / brightest bunny in the bunch /
, so I'm trying to make sure that I
actually understand these.

I suspect that we only need a definition that is "good enough", and that
trying to cover all corner cases is a losing proposition, but I'd
appreciate it if y'all can let me know if I've gotten the below correct /
where you disagree….


Let's start with this from the parent side:
$ dig ns example.com
;; ANSWER SECTION:
example.com. 21600 IN NS a.example.net
example.com. 21600 IN NS b.example.com

Ok, fair. Now, let's make up some failures:

Scenario 1 - Unreachable servers:
—-
a.example.net 1800 IN A 10.0.0.1 ;; an unreachable address
b.example.com 1800 IN A 10.0.0.2  ;; another unreachable address

Q: I'm assuming that this is a lame delegation, yes?
But is a.example.net a "lame server"? I have no way of reaching it, so I
cannot tell if it would answer correctly if e.g: I queried from 10.0.0.3.


Scenario 2 - Classically lame:
—-
a.example.net 1800 IN A 192.0.2.1;; a reachable address.
b.example.com 1800 IN A 10.0.0.2  ;; another unreachable address

$ dig example.net @a.example.net
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14273

Q: I'm assuming that this is a lame delegation, yes?
I'm also assuming that a.example.net is a lame server, yes?
Phew.


Scenario 3 - Split views are fun!:
—-
Same as scenario 1 or 2, but let's pretend that the name is something like
foo.corp.example.com, and Example Corp uses split-views. If I query from
inside the enterprise I get an answer of 192.0.2.53, but from the Internet
I get REFUSED, because views…

Q: Is the server "lame"? Can / should we say "it's a lame server from the
Internet, but not lame from specific addresses"?


Scenario 4 - I know a guy who knows a guy...:
—
$ dig NS example.net @a.example.net
;; ANSWER SECTION:
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
…
Doh! Upwards referral.

Q: I'm assuming that the delegation is lame, and the server is lame, yes?


Scenario 5 - ¯\_(ツ)_/¯:
—---
$ dig www.example.net @a.example.net
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58056
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig www.example.net @b.example.com
www.example.net 600 IN A192.0.2.1

Q: I'm assuming that the delegation is not lame, yes?
I'm assuming that b.example.com is not a lame server, yes?
I'm assuming that a.example.net is, erm, well, busticated in some other
way, yes? Or can we call this lame? What if instead of www.example.net, the
name I was querying was www.foo.example.net, and there was an "internal"
delegation from example.net to foo.example.net (with NS of a.example.net and
b.example.com), and b.example.com was correctly configured, but someone
forgot to do that on a.example.net — that makes a.example.net a lame
delegation, doesn't it? (foo.example.com is delegated to it, but it doesn't
"know" that).



I suspect that the proposals are more than good enough, but I was wondering
if we'd all apply them in the same way in all of these cases…

W




>
>
> And the second step is for how to resolve the lameness.
>
>
>
>
>
> Yours,
>
>
>
> Mats
>
>
>
> ---
>
> Mats Dufberg
>
> mats.dufb...@internetstiftelsen.se
>
> Technical Expert
>
> Internetstiftelsen (The Swedish Internet Foundation)
>
> Mobile: +46 73 065 3899
>
> h

[DNSOP] Warren Kumari's Yes on draft-ietf-dnsop-svcb-https-12: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-dnsop-svcb-https-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/



--
COMMENT:
--


This is the second ballot, diff from the previously approved version:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html

Please see the ballot text for reasons.



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

Re: [DNSOP] Additional Working Group Last Call for draft-ietf-dnsop-svcb-http

[Warren Kumari]

On Sun, Mar 19, 2023 at 5:23 AM, Tim Wicinski  wrote:

> All
>
> The 7 day followup WGLC for draft-ietf-dnsop-svcb-https has finished up,
> and I thank folks for their reviews of the changes.
> I've added a comment to the shepherd write up about the reasoning behind
> this and a link to Warren's email to the reasoning.
> I've pushed it back to the IESG and thanks everyone for their patience
>


Indeed - thanks everyone, and sorry that there is so much process wonkery
needed. We are careful about making post-approval changes, and also we have
to coordinate to make sure that documents that rely on/reference SVCB-HTTP
didn't rely on the removed text.

So, thanks again, and also thanks to the chairs,
W


tim
>
>
> On Sat, Mar 11, 2023 at 3:44 PM Tim Wicinski  wrote:
>
>>
>> All
>>
>> The SVCB document has been returned from the RFC Editor, and we thank
>> Warren for doing all the crazy process stuff to make this happen.  The
>> authors have made the changes - removing the references to ECH (and I thank
>> them for doing this quickly and efficiently).   They are creating a
>> separate document describing the ech flags for SVCB, with the plan to
>> submit into the TLS working group.
>>
>> Here is the Diff from the previous version
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-svcb-https-12
>>
>> (it shows a much greater set of changes than what really changed).
>>
>> Because of this, we're starting a week Working Group Last Call on
>> draft-ietf-dnsop-svcb-https, to have the WG confirm the changes removing
>> the references has not caused other issues.
>>
>> What is not on the table to discuss during the WGLC are other changes to
>> the document.  This is from Warren, so if there are issues with that,
>> please include him in any discussions.
>>
>> This WGLC will end on March 18th 2023
>>
>> tim
>>
>> ___
> 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] Breaking the logjam that is draft-ietf-dnsop-svcb-https

[Warren Kumari]

[ Top-post ]


On Thu, Feb 23, 2023 at 12:39 PM, Warren Kumari  wrote:

> Hi there all,
>
> I was really hoping that it wouldn't come to this, but…
>
>
> We approved draft-ietf-dnsop-svcb-https on 2022-05-22, and has been stuck
> in MISREF state ever since[0], waiting on draft-ietf-tls-esni - "TLS
> Encrypted Client Hello"
> <https://datatracker.ietf.org/doc/draft-ietf-tls-esni/> .  This is
> basically as long as it takes to make a whole person…
>
> There are multiple documents in the RFC Editor queue waiting on the
> svcb-https  document: https://www.rfc-editor.org/cluster_info.php?cid=C461
> .
>
> Unfortunately it now seems that tls-esni is not likely to be published
> anytime soon because they want deployment experience before advancing it,
> and that's not going to happen for some months.
>
> This means that the svcb-https document, and, by extension, the other
> documents in the cluster will be stuck for an indeterminate amount of
> time.
>
> The part of svcb-https  that "needs" tls-esni is sort of an optional
> feature, and none of the other documents in this cluster seem to rely on
> it.
>
> Instead of just having all of these document stuck indefinitely, I'm
> proposing that we:
> 1: Ask the RFC Editor to return the document to the IESG & IETF[1].
> 2: I return it to the WG.
> 3: The authors remove the bits that rely on ESNI
> 4: The document progresses "normally" - it gets another WGLC, IETF LC,
> IESG Eval, etc. Hopefully this can be expedited - it's already gone though
> all of these steps once, and the updated document would be very similar to
> the original.
>

Hi there all,

The RFC Editor is still working on some tooling issues in order to
"officially" return to the document to the IETF/WG, but in the mean time
they have assured me that they will not progress it ("I will work on the
fix now — but rest assured we will not work on this document until it
returns.").

So, consider the document returned to the WG. If the authors can implement
the (already discussed) removal of the ESNI dependency then we can do a
(presumably compressed) WGLC on the changes, an IETF LC, IESG eval and hand
it back to the RFC Editor.

When doing the IETF LC I'll request that people restrict their comments to
just the changes, and the IESG will (presumably) do the same. As this is a
returning item, I'm asking the chairs to please prioritize the WGLC.

W

5: If / when tls-esni is published, the svcb-https authors submit a -bis
> (while will likely just be 'git checkout '), and we
> progress this just like any other WG document.
>
> I've discussed this with the authors of the documents, the DNSOP and TLS
> chairs, the relevant ADs and the full IESG.
>
> However, before doing all this, I'd like to confirm that the WG doesn't
> object to the plan….
>
>
> W
> [0]: Possibly modulo the annoyingly painful "AliasMode clarification"
> change: https://author-tools.ietf.org/
> iddiff?url1=draft-ietf-dnsop-svcb-https-10&url2=draft-ietf-dnsop-svcb-https-11&difftype=--html
>
> [1]: While we prefer not do to this sort of thing, we have done it before
> - as an example: https://datatracker.ietf.org/doc/
> draft-ietf-netmod-syslog-model/history/
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9

[Warren Kumari]

Hello authors, chairs and WG,

I was wondering when we'd see an updated version of this document?
The IETF 116 "Internet-Draft submission cut-off" is 2023-03-13 (7 days from
now) - https://datatracker.ietf.org/meeting/116/important-dates/

I think that the requested changes were not particularly major, so
hopefully this can happen soon…


W


On Tue, Jan 24, 2023 at 11:26 AM, Warren Kumari  wrote:

> Hi all,
>
> Thank you to the authors, chairs and WG for wanting to make the document
> as good as it can be, even if that does require some more work.
>
> The chairs have requested that I return it to the WG to get an
> implementation section added, and so I'll do so[0].
>
> Thanks again,
> W
>
> [0]: I'll keep the ballot text, cliffsnotes summary, review notes, etc all
> squirreled away somewhere so that it's easier and faster to progress when
> it returns to me / whoever the next OpsAD is...
>
>
>
>
> On Tue, Jan 24, 2023 at 9:46 AM, Tim Wicinski  wrote:
>
>> The chairs thank all for this feedback, even at this stage.  But it's
>> better to catch these issues now, than
>> later on in the process.
>>
>>
>> On Fri, Jan 20, 2023 at 3:52 PM Ondřej Surý  wrote:
>>
>>> I am indifferent about what label we stick on this, but perhaps the
>>> document should have a section on implementations?
>>>
>>> However, I do feel that the Security Considerations is missing on the
>>> risks of dropping packets, ICMP filtering and dangers of PMTUD.
>>>
>>> Also it feels weird to me that the IP_PMTUDISC_OMIT is used by: BIND 9,
>>> NSD, Unbound, Knot DNS and PowerDNS, but neither the fact nor the reasoning
>>> behind the option is ever mentioned here.
>>>
>>> Hence, I think the Implementors section should be added to the document.
>>
>>
>> an Implementation Section would be useful and generally they appear as an
>> Appendix.
>>
>> Ondrej, if you could suggest some text with what ISC will implement,
>> along with any reasoning, that would be a great start.
>>
>> tim
>>
>> ___
>> 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] AD review of draft-ietf-dnsop-alt-tld-21

[Warren Kumari]

On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton  wrote:

> Hi authors, WG,
>
> Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They
> are all minor/nit comments, meaning that I'll leave it to the authors
> discretion as to how they want to handle these comments.
>
> Minor level comments:
>
> (1) p 3, sec 2. The alt Namespace
>
> Groups wishing to create new alternative namespaces may create their
> alternative namespace under a label that names their namespace under the
> .alt pseudo-TLD. The .alt namespace is unmanaged.
>
> This seems slightly strong given that the ISE draft is planning on setting
> up a registry somewhere. So, perhaps "The .alt namespace is not managed by
> the IETF or IANA"?
>

Good point.

Here is the original with a bit more text for context:
"The .alt namespace is unmanaged. This document does not define a registry
or governance model for the .alt namespace."

I don't really know if GNU creating a registry really counts at "managing"
the .alt namespace, but we can skip that philosophical question by
rewording it like so:

"This document defines neither a registry nor governance model for the .alt
namespace, as it is not managed by the IETF or IANA. "


(2) p 3, sec 2. The alt Namespace
>
>
> This document
> does not define a registry or governance model for the .alt namespace.
> Developers, applications and users should not expect unambiguous mappings
> from names to name resolution mechanisms.
>
>
> Is "Developers, applications, users should not expect unambiguous
> mappings" a bit strong? A possible alternative could be: "Developers,
> applications and users are not guaranteed to have unambiguous mappings from
> names to name resolution mechanisms."
>

Hmmm - I'm not sure if it is actually a bit strong, I think that the issue
is more that we cannot really tell developers or users to "expect" anything
— my auntie might well expect some.name.gns.alt to be an unambiguous
mapping, and telling her that she shouldn't expect this is silly - she
doesn't read RFCs[0]

I changed this to "There is no guarantee of unambiguous mappings from names
to name resolution mechanisms." ? I removed the "Developers, applications
and users" wording as it just opens the question of who should expect this
(cats?), or who might be guaranteed anything (chimps?).

(3) p 3, sec 2. The alt Namespace
>
> Currently deployed projects and protocols that are using pseudo-TLDs may
> choose to move under the .alt pseudo-TLD, but this is not a requirement.
>
> I was wondering whether we could we be slightly stronger here and use
> "recommended to move" rather than "may choose to move"? I.e., I think that
> the IETF position could reasonably be that we would like these to all turn
> up under alt and not squat in the root namespace.
>

This works for me - it's not a requirement, and so people can happily
ignore it. Of course, even if it were a requirement, people can still
happily ignore it… (
https://i.cbc.ca/1.3173445.1438223040!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_780/winnipeg-blue-bombers.jpg
)


> Nit level comments:
>
> (4) p 6, sec Appendix A. Changes / Author Notes.
>
> * During AD review, made a few more requested changes
>
> As a minor nit, I think that these comments were during the WGLC, rather
> than AD review.
>


Fair 'nuff, fixed.

I also added some additional names to the acknowledgement section - *huge*
apologies to anyone we may have missed…

Warren.

[0]: I know this for a fact, as she doesn't actually exist :-P



On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton  wrote:

> Hi authors, WG,
>
> Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They
> are all minor/nit comments, meaning that I'll leave it to the authors
> discretion as to how they want to handle these comments.
>
> Minor level comments:
>
> (1) p 3, sec 2. The alt Namespace
>
> Groups wishing to create new alternative namespaces may create their
> alternative namespace under a label that names their namespace under the
> .alt pseudo-TLD. The .alt namespace is unmanaged.
>
> This seems slightly strong given that the ISE draft is planning on setting
> up a registry somewhere. So, perhaps "The .alt namespace is not managed by
> the IETF or IANA"?
>
> (2) p 3, sec 2. The alt Namespace
>
> This document
> does not define a registry or governance model for the .alt namespace.
> Developers, applications and users should not expect unambiguous mappings
> from names to name resolution mechanisms.
>
> Is "Developers, applications, users should not expect unambiguous
> mappings" a bit strong? A possible alternative could be: "Developers,
> applications and users are not guaranteed to have unambiguous mappings from
> names to name resolution mechanisms."
>
> (3) p 3, sec 2. The alt Namespace
>
> Currently deployed projects and protocols that are using pseudo-TLDs may
> choose to move under the .alt pseudo-TLD, but this is not a requirement.
>
> I was wondering whether we could we be slightly stronger here an

[DNSOP] Breaking the logjam that is draft-ietf-dnsop-svcb-https

[Warren Kumari]

Hi there all,

I was really hoping that it wouldn't come to this, but…


We approved draft-ietf-dnsop-svcb-https on 2022-05-22, and has been stuck
in MISREF state ever since[0], waiting on draft-ietf-tls-esni - "TLS
Encrypted Client Hello"
 .  This is
basically as long as it takes to make a whole person…

There are multiple documents in the RFC Editor queue waiting on the
svcb-https  document: https://www.rfc-editor.org/cluster_info.php?cid=C461.

Unfortunately it now seems that tls-esni is not likely to be published
anytime soon because they want deployment experience before advancing it,
and that's not going to happen for some months.

This means that the svcb-https document, and, by extension, the other
documents in the cluster will be stuck for an indeterminate amount of
time.

The part of svcb-https  that "needs" tls-esni is sort of an optional
feature, and none of the other documents in this cluster seem to rely on
it.

Instead of just having all of these document stuck indefinitely, I'm
proposing that we:
1: Ask the RFC Editor to return the document to the IESG & IETF[1].
2: I return it to the WG.
3: The authors remove the bits that rely on ESNI
4: The document progresses "normally" - it gets another WGLC, IETF LC, IESG
Eval, etc. Hopefully this can be expedited - it's already gone though all
of these steps once, and the updated document would be very similar to the
original.

5: If / when tls-esni is published, the svcb-https authors submit a -bis
(while will likely just be 'git checkout '), and we
progress this just like any other WG document.

I've discussed this with the authors of the documents, the DNSOP and TLS
chairs, the relevant ADs and the full IESG.

However, before doing all this, I'd like to confirm that the WG doesn't
object to the plan….


W
[0]: Possibly modulo the annoyingly painful "AliasMode clarification"
change:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-10&url2=draft-ietf-dnsop-svcb-https-11&difftype=--html

[1]: While we prefer not do to this sort of thing, we have done it before -
as an example:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/history/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9

[Warren Kumari]

Hi all,

Thank you to the authors, chairs and WG for wanting to make the document as
good as it can be, even if that does require some more work.

The chairs have requested that I return it to the WG to get an
implementation section added, and so I'll do so[0].

Thanks again,
W

[0]: I'll keep the ballot text, cliffsnotes summary, review notes, etc all
squirreled away somewhere so that it's easier and faster to progress when
it returns to me / whoever the next OpsAD is...


On Tue, Jan 24, 2023 at 9:46 AM, Tim Wicinski  wrote:

> The chairs thank all for this feedback, even at this stage.  But it's
> better to catch these issues now, than
> later on in the process.
>
>
> On Fri, Jan 20, 2023 at 3:52 PM Ondřej Surý  wrote:
>
> I am indifferent about what label we stick on this, but perhaps the
> document should have a section on implementations?
>
> However, I do feel that the Security Considerations is missing on the
> risks of dropping packets, ICMP filtering and dangers of PMTUD.
>
> Also it feels weird to me that the IP_PMTUDISC_OMIT is used by: BIND 9,
> NSD, Unbound, Knot DNS and PowerDNS, but neither the fact nor the reasoning
> behind the option is ever mentioned here.
>
> Hence, I think the Implementors section should be added to the document.
>
>
> an Implementation Section would be useful and generally they appear as an
> Appendix.
>
> Ondrej, if you could suggest some text with what ISC will implement, along
> with any reasoning, that would be a great start.
>
> tim
>
> ___
> 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] AD Review of: draft-ietf-dnsop-avoid-fragmentation

[Warren Kumari]

Hi there authors (and WG!),

Thank you for this document, I found it clear, useful, and an easy read.

I do have a few comments/nits to (hopefully!) further improve the document;
addressing these now should help the IETF LC and IESG evaluation go more
smoothly.

Please SHOUT LOUDLY once you've had a chance to address these, and I'll
start IETF LC.

Comments / questions:
1: Intro:
"DNS (over UDP) is said to be the biggest user of IP fragmentation."
Q: Is there a citation for this? (I'm sure it is true, but having a
reference would be nice).

2: Recommendations for UDP responders
"UDP responders SHOULD compose response packets fit in path MTU discovery
results (if available) to measure path MTU discovery attacks, … "
C: I'm not fully able to parse this. I think that this is saying that I
should try make my packet fit within the discovered path MTU (if I've
discovered a path MTU), but I get confused why this is being done "to
measure path MTU discovery attacks". I suspect I'm missing something
obvious here. Breaking this into two sentences might help.

3: Recommendations for UDP requestors
3.1: "UDP requestors SHOULD limit the requestor's maximum UDP payload size
to 1400 or smaller size. [ UDP requestors MAY set the requestor's maximum
UDP payload size as 1232. ]"
I'm also having a hard  time parsing this, especially the relationship
between the sentences. The second sentence seems to be a subset of the
first sentence (e.g: "Please choose a number between 1 and 10. You may
choose 7…") I don't really understand what this is trying to say, but
taking a guess, would this work:
"The requestor's maximum UDP payload size SHOULD be to 1400 or less, with
1232 being the RECOMMENDED value"?

3.2: "UDP requestors MAY perform "Path MTU discovery" per destination to
use the requestor's maximum UDP payload size larger than 1400. Then,
calculate their requestors' maximum UDP payload size as …"
I found this somewhat tricky to parse — would "In order to use UDP payload
sizes larger than 1400, UDP requestors SHOULD perform per-destination Path
MTU discovery"? (Note the change from MAY to SHOULD because of the
reordering of the sentence; I *think* that this maintains the intent, but… )


Nits:
1: Abstract:
O: "This document proposes to avoid IP fragmentation in DNS."
P: "This document proposes techniques to avoid IP fragmentation in DNS." or
"This document proposes avoiding IP fragmentation in DNS."
C: Readability, and I think that the first option is better.

2: Intro:
O: "This document proposes to set the "Don't Fragment flag (DF) bit"
[RFC0791] on IPv4 and not to use "Fragment header" [RFC8200] ..."
P: This document proposes that implementations set the "Don't Fragment (DF)
bit" [RFC0791] on IPv4 and not using "Fragment header" [RFC8200] ..."
C: Grammar. Also, I changed "Don't Fragment flag (DF) bit" to "Don't
Fragment (DF) bit", but I think that "Don't Fragment (DF) flag" would also
work.

3: Recommendations for UDP responders
O: "UDP responders RECOMMENDED to set"
P: "UDP responders are RECOMMENDED to set"
C: Grammar

4: Request to zone operators and DNS server operators
I think that this would be better as "Recommendations for zone operators
and DNS server operators" or perhaps "Suggestions for…" (it is unclear who
is "requesting" the change).

4.1: "Notably, the signature size of ECDSA or EdDSA is smaller than RSA."
I think that this is better as "Notably, the signature sizes of ECDSA and
EdDSA are smaller than than those for RSA."

5: Protocol compliance
O: "In prior research ([Fujiwara2018] and dns-operations mailing
list discussions), there are some authoritative …"
P: "Prior research ([Fujiwara2018] and dns-operations mailing
list discussions) has shown that some authoritative …"
C: I'm not really sure that "and dns-operations mailing list discussions"
is a useful citation. I think it might be better to either drop that, or
provide links to specific messages. If you do keep it, I think that you
should at least provide a reference to "dns-operations mailing list" (
perhaps https://lists.dns-oarc.net/mailman/listinfo/dns-operations ?). This
is especially important because it is easy for readers to get confused
between the DNS-OARC dns-operations list and the IETF DNS Operations WG
mailing list…


Thank you again; I know that making edits to address nits can be annoying,
but we are expecting many people to read and review the document, and so
having it polished is important and polite (also, once people start
commenting on nits, they seem to continue :-) )
W
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Warren Kumari's Yes on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-dnsop-dns-catalog-zones-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/



--
COMMENT:
--

[ Trying something new here -- adding commentary in my existing Yes ballot ]

I'd like to thank the authors for responding to the ADs with DISCUSS positions
- it looks like the replies and pull request address most of the comments. I'd
also like to thank David Blacka for the useful DNSDIR review -
https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-catalog-zones-08-dnsdir-lc-blacka-2022-12-27/



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

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

[Warren Kumari]

AD Review: Catalog Zones.

Hi there,

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

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

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

W


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

Sec 1:
O: "... they must also add/remove the
   zone from all secondaries, either manually or via an external
   application."
P: "they must also add/remove the configuration for the zone from all
secondaries"
C: Just above it says that the zone is transferred using [AI]XFR.

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

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

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

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

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

Sec 4:
O: "More than one record in the RRset denotes a broken
   catalog zone..."
C: Can you come up with a better word than "denotes"? To me "denotes"
implies that the user has *chosen* to do this. Perhaps "results in"? Sorry
I don't have a better suggestion.

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

Sec 4.4.2.1.  Example
I think that the example is quite unclear, and it will raise more questions
than it answers -- for example, people are going to ask who exactly parses
"operator-x-sign-with-nsec3", and they will also try and figure out where
these verbs (e.g 'nodnssec') are defined. I think that you need to clarify
that the meaning of the text records are opaque / defined between the
producer and consumer. This is discussed above ("The exact handling of
configuration referred to by the group property value is left to the
consumer's implementation and configuration."), but it's not clear in the
example.

Sec 4.5:
"A custom property is named as follows:
; a global custom property:
   .ext.$CATZ

; a member zone custom property:
   .ext..zones.$CATZ"
  vs
"For
   example by including the name of the implementation in the property,
   e.g. like: ..ext.$CATZ."
So, which is it? '', or ''? If these
are the same thing, then that's not clear (I'd guess that this is that the
 is supposed to show that it can be composed of 
and , but it's really not clear). It's also not really
clear how people should name their properties, and some examples here might
help.

O: "A property description should clearly say what semantics apply, and
whether a property is global, member, or both."
C: Ok, fair enough -- but this is the first mention of property
descriptions. If I write one, I'll happil say what the semantics are, etc
-- but where should I put this? Who do I shate it with? Is this for my own
internal use, or should I publish it externally? If you have this level of
suggestion, then it implies that these will be used somewhere...


Sec 6:
O: "Although any valid domain name can be used for the catalog name
   $CATZ, it is RECOMMENDED to use either a domain name owned by the
   catalog producer, or to use a name u

Re: [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Warren Kumari]

On Fri, Oct 21, 2022 at 2:54 PM, Warren Kumari  wrote:

> On Wed, Oct 19, 2022 at 12:41 PM, Warren Kumari  wrote:
>
>> On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman 
>> wrote:
>>
>>> On Oct 18, 2022, at 7:58 AM, Ron Even  wrote:
>>>
>>> 1. whis is this an informational RFC and not a standard track RFC.
>>>
>>> That's a reasonable question with a simple answer: because the WG
>>> changed its mind on what the status of this protocol should be. RFC 5933
>>> describes a national standard that is thinly deployed. At the time, it was
>>> necessary to have the protocol on standards track; now it no longer is
>>> required.
>>>
>>> 2. What is requested from IANA. ths text you wrote and I copied is not a
>>> directive to IANA that is clear
>>>
>>> You are correct that the IANA Considerations section is quite unclear,
>>> and needs to be clarified before the IESG considers it.
>>>
>>
>>
>> That is a good point.
>>
>> The document says:
>> ---
>> This document updates the RFC IANA registry "Delegation Signer
>> (DS) Resource Record (RR) Type Digest Algorithms" by adding an entry for
>> the GOST R 34.11-2012 algorithm:
>>
>>   Value   Algorithm
>>   TBA2GOST R 34.11-2012
>>
>>The entry for Value 3, GOST R 34.11-94 should be updated to have its
>> Status changed to '-'.
>> 
>>
>> The IANA registry being referenced "DNSSEC Delegation Signer (DS)
>> Resource Record (RR) Type Digest Algorithms" is here: https://www.iana.
>> org/assignments/ds-rr-types/ds-rr-types.xhtml
>>
>> Setting this to '-' does seem incorrect, and from the text I think that
>> it should be either "MUST NOT" or, better yet (for clarity) "DEPRECATED" .
>>
>> In addition, the IANA has a question:
>> --
>> "Third, in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type
>> Digest Algorithms registry located at:
>>
>> https://www.iana.org/assignments/ds-rr-types/
>>
>> a new registration will be made as follows:
>>
>> Value: [ TBD-at-Registration ]
>> Description: GOST R 34.11-2012
>> Status:
>> Reference: [ RFC-to-be ]
>>
>> IANA Question --> What should the entry for "Status" be for this new
>> registration?"
>> 
>>
>>
>>
>>
>> I believe that it is clear (e.g: "6.  Implementation Considerations
>>The support of this cryptographic suite in DNSSEC-aware systems is
>>OPTIONAL.") that it can only be OPTIONAL, but we need to clearly state
>> that.
>>
>> So, I think a new version should be submitted saying:
>> 
>> This document updates the RFC IANA registry "Delegation Signer (DS)
>>Resource Record (RR) Type Digest Algorithms" by adding an entry for
>>the GOST R 34.11-2012 algorithm:
>>
>>   Value:   TBA2
>>   Description: GOST R 34.11-2012
>>   Status: OPTIONAL
>>   Reference: [ RFC-to-be ]
>>
>>The entry for Value 3, GOST R 34.11-94 should be updated to have its
>>Status changed to 'DEPRECATED'.
>>
>
> A new version was submitted (-11), but still says:
> "   The entry for Value 3, GOST R 34.11-94 should be updated to have its
>Status changed to '-'."
>
> The registry is here: https://www.iana.org/assignments/ds-rr-types/
> ds-rr-types.xhtml
>
> '-' to me implies that the codepoint hasn't  been used, but I don't
> actually know if that's true. I think "DEPRECATED" is better, but perhaps
> I'm wrong (anyone seeing '-' will presumably do read the referenced RFC,
> so…_)
>
> I will ask the IANA which they think is best / clearest…
>

Closing the loop:

I reached out to the IANA, and this was their reply:
"Hi Warren,

It makes sense to us to list "DEPRECATED" in the status column. When we're
asked to deprecate a codepoint, the label "deprecated" is usually added to
the registration in some way.

"-" is a bit of a cipher, and doesn't indicate that there's been a change.

thanks,
Amanda
"

If the authors post a new version before the draft cut-off (Monday) with
this addressed I should be able to move it along.

Thank you all,
W




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

Re: [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Warren Kumari]

On Wed, Oct 19, 2022 at 12:41 PM, Warren Kumari  wrote:

> On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman 
> wrote:
>
>> On Oct 18, 2022, at 7:58 AM, Ron Even  wrote:
>>
>> 1. whis is this an informational RFC and not a standard track RFC.
>>
>> That's a reasonable question with a simple answer: because the WG changed
>> its mind on what the status of this protocol should be. RFC 5933 describes
>> a national standard that is thinly deployed. At the time, it was necessary
>> to have the protocol on standards track; now it no longer is required.
>>
>> 2. What is requested from IANA. ths text you wrote and I copied is not a
>> directive to IANA that is clear
>>
>> You are correct that the IANA Considerations section is quite unclear,
>> and needs to be clarified before the IESG considers it.
>>
>
>
> That is a good point.
>
> The document says:
> ---
> This document updates the RFC IANA registry "Delegation Signer
> (DS) Resource Record (RR) Type Digest Algorithms" by adding an entry for
> the GOST R 34.11-2012 algorithm:
>
>   Value   Algorithm
>   TBA2GOST R 34.11-2012
>
>The entry for Value 3, GOST R 34.11-94 should be updated to have its
> Status changed to '-'.
> 
>
> The IANA registry being referenced "DNSSEC Delegation Signer (DS) Resource
> Record (RR) Type Digest Algorithms" is here: https://www.iana.org/
> assignments/ds-rr-types/ds-rr-types.xhtml
>
> Setting this to '-' does seem incorrect, and from the text I think that it
> should be either "MUST NOT" or, better yet (for clarity) "DEPRECATED" .
>
> In addition, the IANA has a question:
> --
> "Third, in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type
> Digest Algorithms registry located at:
>
> https://www.iana.org/assignments/ds-rr-types/
>
> a new registration will be made as follows:
>
> Value: [ TBD-at-Registration ]
> Description: GOST R 34.11-2012
> Status:
> Reference: [ RFC-to-be ]
>
> IANA Question --> What should the entry for "Status" be for this new
> registration?"
> 
>
>
>
>
> I believe that it is clear (e.g: "6.  Implementation Considerations
>The support of this cryptographic suite in DNSSEC-aware systems is
>OPTIONAL.") that it can only be OPTIONAL, but we need to clearly state
> that.
>
> So, I think a new version should be submitted saying:
> 
> This document updates the RFC IANA registry "Delegation Signer (DS)
>Resource Record (RR) Type Digest Algorithms" by adding an entry for
>the GOST R 34.11-2012 algorithm:
>
>   Value:   TBA2
>   Description: GOST R 34.11-2012
>   Status: OPTIONAL
>   Reference: [ RFC-to-be ]
>
>The entry for Value 3, GOST R 34.11-94 should be updated to have its
>Status changed to 'DEPRECATED'.
>

A new version was submitted (-11), but still says:
"   The entry for Value 3, GOST R 34.11-94 should be updated to have its
   Status changed to '-'."

The registry is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

'-' to me implies that the codepoint hasn't  been used, but I don't
actually know if that's true. I think "DEPRECATED" is better, but perhaps
I'm wrong (anyone seeing '-' will presumably do read the referenced RFC,
so…_)

I will ask the IANA which they think is best / clearest…

W



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

Re: [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Warren Kumari]

On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman 
wrote:

> On Oct 18, 2022, at 7:58 AM, Ron Even  wrote:
>
> 1. whis is this an informational RFC and not a standard track RFC.
>
> That's a reasonable question with a simple answer: because the WG changed
> its mind on what the status of this protocol should be. RFC 5933 describes
> a national standard that is thinly deployed. At the time, it was necessary
> to have the protocol on standards track; now it no longer is required.
>
> 2. What is requested from IANA. ths text you wrote and I copied is not a
> directive to IANA that is clear
>
> You are correct that the IANA Considerations section is quite unclear, and
> needs to be clarified before the IESG considers it.
>


That is a good point.

The document says:
---
This document updates the RFC IANA registry "Delegation Signer
(DS) Resource Record (RR) Type Digest Algorithms" by adding an entry for
the GOST R 34.11-2012 algorithm:

  Value   Algorithm
  TBA2GOST R 34.11-2012

   The entry for Value 3, GOST R 34.11-94 should be updated to have its
Status changed to '-'.


The IANA registry being referenced "DNSSEC Delegation Signer (DS) Resource
Record (RR) Type Digest Algorithms" is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

Setting this to '-' does seem incorrect, and from the text I think that it
should be either "MUST NOT" or, better yet (for clarity) "DEPRECATED" .

In addition, the IANA has a question:
--
"Third, in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type
Digest Algorithms registry located at:

https://www.iana.org/assignments/ds-rr-types/

a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: GOST R 34.11-2012
Status:
Reference: [ RFC-to-be ]

IANA Question --> What should the entry for "Status" be for this new
registration?"





I believe that it is clear (e.g: "6.  Implementation Considerations
   The support of this cryptographic suite in DNSSEC-aware systems is
   OPTIONAL.") that it can only be OPTIONAL, but we need to clearly state
that.

So, I think a new version should be submitted saying:

This document updates the RFC IANA registry "Delegation Signer (DS)
   Resource Record (RR) Type Digest Algorithms" by adding an entry for
   the GOST R 34.11-2012 algorithm:

  Value:   TBA2
  Description: GOST R 34.11-2012
  Status: OPTIONAL
  Reference: [ RFC-to-be ]

   The entry for Value 3, GOST R 34.11-94 should be updated to have its
   Status changed to 'DEPRECATED'.

W


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

Re: [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

[Warren Kumari]

On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman 
wrote:

> On Oct 18, 2022, at 7:58 AM, Ron Even  wrote:
>
> 1. whis is this an informational RFC and not a standard track RFC.
>
> That's a reasonable question with a simple answer: because the WG changed
> its mind on what the status of this protocol should be. RFC 5933 describes
> a national standard that is thinly deployed. At the time, it was necessary
> to have the protocol on standards track; now it no longer is required.
>

One or two people had also poked me off-list, asking if the process allows
for an informational document to update a non-informational document. This
appears to be fully allowed by process (and I had checked before advancing
the document).
I checked on a few documents which Update other documents, and here is a
selection of prior instances where this was done.

RFC2026 - "The Internet Standards Process -- Revision 3" (BCP) was updated
by both
RFC7841 - "RFC Streams, Headers, and Boilerplates" (Informational)
and RFC3669 - "Guidelines for Working Groups on Intellectual Property
Issues" (Informational)


RFC9120 - "Nameservers for the Address and Routing Parameter Area ("arpa")
Domain" (Info) updates RFC3172 - "Management Guidelines \& Operational
Requirements for the Address and Routing Parameter Area Domain
("arpa") (Best Current Practice)


RFC7722 - "Multi-Topology Extension for the Optimized Link State Routing
Protocol Version 2 (OLSRv2)" (Exp) updates both RFC7188 - "Optimized Link
State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery
Protocol (NHDP) Extension TLVs" (Standards Track)
and RFC7631 - "TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized
Packet/Message Format" (Standards Track)


RFC7419 - "Common Interval Support in Bidirectional Forwarding
Detection" (Informational) updates  RFC5880 - "Bidirectional Forwarding
Detection (BFD)" (Standards Track).

W


> 2. What is requested from IANA. ths text you wrote and I copied is not a
> directive to IANA that is clear
>
> You are correct that the IANA Considerations section is quite unclear, and
> needs to be clarified before the IESG considers it.
>
> --Paul Hoffman
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Sun, Oct 16, 2022 at 7:20 PM, Paul Wouters  wrote:

> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> One could advance the 6761bis proposal document first, which would remove
> these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>
> I think it draft would be better if it said something along the lines of:
>
> No code changes are required to properly handle leaked queries for .alt
> into the DNS, but:
>
> 1) Implementations MAY handle .alt specially by (pre)fetching the proofs
> of non-existence of .alt and serve these for all .alt queries.
> 2) implementations MAY rely on their query minimalization to accomplish 1)
> 3) or MAY do nothing special, which should work fine but might leak SLD
> queries to the root if the implementation and its querier didn't do query
> minimalization)
> 4) MAY return FORMERR on .alt queries that in some ways violate the DNS
> specification (so that no code changes are mandatory to support the madness
> .alt queries could bring in, eg >63 SLD names)
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me
>
> Me too, I really do believe that the IETF should not do this. It is an
> anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
> Some alternative sysytems might even use .alt without SLD. Basically,
> .alt is what IETF recommends you should not do, and we should not keep a
> registry of entries within it.
>
> But also, IETF maintaining a list might open it up for legal liabilities
> with alternative naming systems. The whole idea of the ICANN/IETF split is
> that ICANN does money and legal stuff, and IETF does codepoints and running
> code (with no money) :P
>
> So I disagree with Eliot who prefered some kind of FCFS registry that
> requires RFCs to get an entry. We do not want alternative naming systems to
> require (and burden) the IETF with RFCs.
>



#include 

I'll note that I was one of the people initially pushing for a registry - I
wanted to be able to lookup 'foo.alt' and see that I should read the
specifications "The foo naming system", available on GitHub at  (and
possibly also "foo-names - the protocol" available at ).

But:
1: as we've already seen, nothing stops people from just using whatever
names they want[0], and so there is no guarantee that registry would be
complete and correct.
2: if this happens to be widely used, we might end up with lots and lots of
names using this, and having e.g the IANA maintain this has costs - even if
they just note "FooNet says that they use foo.alt and their specification
is at https://www.the-foo-project.example/foo-names.html";, this has costs.
I really don't want us to end up with a "success failure".

Having something like a list of what to read to understand how to resolve
bar.foo.alt still seems useful, but it could (IMO) just be a list on GitHub
that someone is willing to manage (similar to the PSL (
https://github.com/publicsuffix/list), but purely informational, and with
no real validation/work. And, no, I'm not volunteering to run this).

W
[0]: I just changed the hostname on my laptop bar.foozle.wobble.alt, and
there is nothing you can do to stop me… (actually I didn't, but I could
have)




> 3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term
> “registered” differently than common usage. Judging from searches on RFC
> 6761 and RFC 8499, it’s ambiguous for DNS naming and resolution, and
> “registered” can definitely mean something different to a registry or
> registrar than it does to a DNS operator. To people who operate TLD
> registries, a name can be “registered” and still may or may not be
> delegated. (“Label” is defined in 8499,
> “register” and “delegate” are not.) And, in the reference to “TLD,” it
> feels strange to expand the acronym to
> “Top-level label” even if “label” is the ri

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

[Warren Kumari]

On Sun, Oct 16, 2022 at 11:44 PM, Eliot Lear  wrote:

> Hi Paul!
>
> Good conversation!  I hope we can discuss some of this "in person"
> (whatever that means these days) at IETF 115.
>
> On 17.10.22 04:20, Paul Wouters wrote:
>
> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> One could advance the 6761bis proposal document first, which would remove
> these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.
>
> If what you are saying is that we shouldn't get hung up on 6761, then I
> agree.  There are, I think, many ways to deal with the issue that Suzanne
> raised.  One possibility not mentioned was to simply slap an
> "Updates" header on this draft if we think it's necessary, but that
> wouldn't be my first choice.
>

Note: I'm at NANOG this week (and also dealing with dayjob and some other
issues), and so I'm likely to be distracted and not able to focus on this
discussion as much as I'd like. Apologies in advance if I'm replying to
threads midway though / am terser than usual...



I really really don't think that "slap an "Updates" header on this draft"
is a good idea — the WG put a large amount of work into RFC 8244
("Special-Use Domain Names Problem Statement"). RFC 8244 lists 21 top level
issues and includes:
"This document has two goals: enumerate all of the problems that have been
identified to which Special-Use Domain Names are a solution and enumerate
all of the problems that have been raised in the process of trying to use
RFC 6761 as it was intended."

The document also notes that there have been cases where we've messed up
the process:
" 11.  In some cases where the IETF has made assignments through the
process defined in RFC 6761, technical mistakes have been made
due to misunderstandings as to the actual process that RFC 6761
specifies (e.g., treating the list of suggested considerations
for assigning a name as a set of requirements, all of which must
be met).  In other cases, the IETF has made de facto assignments
of Special-Use Domain Names without following the process in RFC
6761 (see [RFC7050] and [RFC7788])."
Some of these process issue have included places where the IETF/IESG/IANA
missed that the fact that documents which added to the registry didn't
include the RFC6761 required bits ("The specification also MUST state, in
each of the seven "Domain Name Reservation Considerations" categories
below, what special treatment, if any, is to be applied.")

However, just because we screwed up in the past and added things to the
registry without following the process (and just because we think that some
of the questions are sub-optimal / inconvenient) doesn't mean that the
right thing to do is to just rip-em-out with an Updates tag. This is
especially true because of how much work the WG put into the "Problem
Statement" document - if there had been clear consensus that that was a
good idea we could have done it then.

I'll also note that while I personally think that some of the questions
could be worded better, the very act of filling them out focuses the
discussions and helps frame the answers in a manner which is useful.

Yes, my life as an author would have been easier not having to try and
figure out the answers to things like:
"  4: Are developers of caching domain name servers expected to make
   their implementations recognize these names as special and treat
   them differently?"
(See earlier discussion - differently to what? If the names are in the
Locally Served Zones registry does that count? Is it specifically
"developers" or "operators" (is this a "code vs configuration" question?)

But, the fact that I had to think about and answer them was really useful,
even if the questions themselves could have been better worded.

W

> The bigger issue is below.  IMHO if we can kink that out, we have
> ourselves a ballgame.
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me
>
> Me too, I really do believe that the IETF should not do this. It is an
> anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
> Some alternative sysytems might even use .alt without SLD.
> [...]
> But also, IETF maintaining a list might open it up for legal liabilities
> with alternative naming systems.
>
> Let's please leave Internet lawyering to lawyers.  If people want a legal
> opinion on this draft, the IETF does have resources for that.
>
> So I disagree with Eliot who prefered some kind of FCFS registry that
> requires RFCs to get an entry. We do not want alternative naming systems to
> require (and burden) the IETF with RFCs.
>
> I am struggling to parse that sentence, but tak

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

[Warren Kumari]

On Sun, Oct 16, 2022 at 11:03 AM, Suzanne Woolf  wrote:

> Dear Colleagues,
>
>
> The chairs have gotten a couple of requests, off-list and on, for a WGLC
> on draft-ietf-dnsop-alt-tld.
>
> We’ve reviewed the current draft closely and have some concerns that we
> feel need to be resolved before any effort to move the draft forward.
> (Suzanne wrote this but it’s been discussed among all of the co-chairs.)
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> First, this creates a process problem in that RFC 6761 is the
> standards-track document that specifies how the SUDN registry is to be
> administered, so a request that doesn’t meet the requirements in 6761 can’t
> (or at least shouldn’t) go into the registry.
>
> RFC 6761 section 4 asserts:
>
> The specification also MUST state, in each of the seven "Domain Name
> Reservation Considerations" categories
> below, what special treatment, if any, is to be applied.
>
>
>
> The alt-tld draft ignores this MUST, without explanation (unless I missed
> it).
>
> The substantive issue is that the questions in Section 5 are there to make
> sure there’s a full description of the expected handling of a proposed name
> by the assorted components that take part in DNS operations and protocol.
> The draft answers at least some of the Section 5 questions, but the answers
> are largely implied.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>
> So, the current draft isn’t meeting the requirements for the registry, and
> also doesn’t clearly answer substantive questions about what DNS operators
> are expected to do. This makes me uncomfortable doing a WGLC without a new
> rev. It would be Rob Wilton’s call of course (as AD for this draft,
> substituting for Warren) but I’m really uneasy with a WGLC without those
> changes— they seem rather too large to punt for a post-WGLC version.
>


Yup. The version 2 back (
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-15) has all
of the text / answers, and it would be trivial to put it back. It may
require some minor word-smithing to get the wording to align perfectly, but
that should be simple enough.

On the "what should resolvers do?" question, the prior text said:
"4.  Caching DNS servers SHOULD NOT recognize these names as special
   and should not perform any special handling with them."

This changed from -07  (
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-07), which
said:
"4.  Caching DNS servers SHOULD recognize these names as special and
   SHOULD NOT, by default, attempt to look up NS records for them,
   or otherwise query authoritative DNS servers in an attempt to
   resolve these names.  Instead, caching DNS servers SHOULD
   generate immediate negative responses for all such queries."

This reason for this change was that we had proposed adding this to the
"Locally Served Zones" registry, and so there wasn't expected to be any
"special" handling or knowledge by implementations.
Perhaps we could clarify this somehow….



> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
> basis that having the IETF “recognize” (if only by recording) such
> pseudo-delegations may serve to attract unwanted attention to the IETF’s
> supposed recognition of alternate (non-DNS) namespaces as reservations of
> the namespace from the shared, common DNS root. We’re still being denounced
> in certain corners for .onion. It might be good to have a paragraph calling
> out specifically why .alt is not a delegation of a TLD from the DNS root by
> the IETF, even though it looks like one. (We didn’t invent this problem,
> because we didn’t make the decision that top-level domain labels should be
> used by other protocols in a way that led to confusion. But let’s not
> propagate it.)
>


Yup. This is (IMO) the area of the draft where the consensus was the least
clear. I still think that it would be useful to have a *purely*
informational list saying "Group A says it is using string B and their
documentation is at https://foo.example.com"; and "Group X also says that it
is using string B and their documentation is at https://bar.examp

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt

[Warren Kumari]

On Wed, Oct 05, 2022 at 3:59 PM, Paul Hoffman 
wrote:

> On Oct 5, 2022, at 11:36 AM, Peter Thomassen  wrote:
>
> On 10/5/22 20:25, Paul Hoffman wrote:
>
> On 10/5/22 19:56, Paul Hoffman wrote:
>
>
> I propose to replace that paragraph with:
> What we today call "DNSSEC" is the DNSSEC specification defined in
> {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}. However, earlier incarnations of
> DNSSEC were thinly deployed and significantly less visible than the current
> DNSSEC specification.
>
>
> I think that's much better, but it remains vague in that it leaves open
> what those other versions were.
>
> I know there are some RFCs that defined KEY records etc. Is that's what's
> meant? Perhaps we should add something like:
>
> For the historic record of these, see RFC 2535 and related documents.
>
> (Or whatever is the appropriate set of documents.)
>
> Given that we don't have clear version numbers, I would kinda prefer not
> to do that. Does RFC 2535 represent a clear description of an earlier
> incarnation/version of DNSSEC? It doesn't feel that way to me.
>
> I wasn't around at that time, so I don't know. Based on the fact that the
> current incarnation was dubbed version 3, I assumed that other revisions
> can be pointed to more or less precisely. Apologies if I misunderstood.
>
> My point is precisely that if we can't pinpoint what we mean by "earlier
> incarnations", the text shouldn't sound like they were stable versions that
> were merely thinly deployed.
>
> I fully agree that they shouldn't sound like stable versions, thus my use
> of the vague word "incarnations". I'm happy to use a different word that is
> even less version-like.
>
> So, my suggestion would be that if we know what those incarnations are,
> let's add references so people can dig further if they are interested. If
> we can't point to a specification and/or don't know what those incarnations
> are, I think it would be better to say they "... were not fully specified
> and saw only little deployment" or not talk about them at all.
>
> I think we have to talk about them a bit so that the reader doesn't ask
> the question "how come there are DNSSEC RFCs that vastly pre-date 4033?".
>

Hi all,

I'd like to be able to move this document into IESG Eval state soon;  there
are only a few tele-chats remaining before IETF115, and there are not many
between the end of IETF115 and the end of the year either.

We don't have the exact replacement text for "formally" settled yet, but it
seems like it is really close - might we be able to get that wrapped up
today so that I can move it along? I think that we have general agreement
on the shape of the text, it's just final massaging.


I'm personally fine with Paul's proposed text, minor tweaks on
"incarnations", Peter's modifications, whatever.


W



> --Paul Hoffman
>
>
> ___
> 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] An update on the DNS Directorate.

[Warren Kumari]

Apologies again for the delay - Eric Vynke and I have been traveling and
kept missing each other, but have finally gotten a chance to sync up on the
DNS Directorate.



We have received more than 50 volunteers for the directorate, and are
extremely grateful to everyone who volunteered.



The first step was to select the chairs of the directorate - we wanted to
choose people in differnt timezones, and with differing expertise (and who
we felt would work well together) - we ended up choosing Geoff Huston and
Jim Reid. Thank you very much to Geoff and Jim for accepting this important
role.



Our goal is to have a small directorate (about 20 members) but with a good
balance among technical/policy domains, seniority, location, etc You
should hear more from Eric, the chairs, and I in the coming days.



Thanks again, everyone,
W
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] An Orderly Way Forward on Special Use Names (Yes, again)

[Warren Kumari]

On Sun, Oct 02, 2022 at 10:32 PM, Paul Wouters  wrote:

> Speaking as AD,
>
> This topic came up at the last IESG telechat, partially in response to
> Paul Hoffman’s https://datatracker.ietf.org/doc/draft-hoffman-rfc6761bis/ and
> my concerns about the infinite amount of time this issue has cost and is
> still costing dnsop at the expense of protocol work.
>

Just for clarification, "this topic" was the larger issues around RFC6761 /
Namespaces and writing a follow up document to *RFC8244 - "Special-Use
Domain Names Problem Statement"* .
Paul raised this topic as, in his view,  this topic is taking up too much
DNSOP time.

The IESG concluded that those willing to resolve the 6761 issues should
> conduct a side meeting at IETF 115 and consider further steps.
>

Yes, it was suggested that someone may want to form a side meeting - I
personally would not have worded it as “The IESG concluded that…”

As the chairs’ email also  said:

“We’re well aware not everyone is interested in this work and that the WG
has a chronic issue of a full pipeline of documents to consider.” A side
meeting to discuss the followup to RFC8244 may provide some energy to work
on the problem.

>
> I also believe a side meeting and possibly a bof and working group
> dedicated to this work would be better.
>

It is very unclear that a different WG would attract sufficient mass - yes,
many people in DNSOP are tired of this topic, but it is clearly an
important topic (and in the DNSOP charter), and moving it off to a group
where it doesn’t get the required review is not helpful.

Warren (DNSOP AD)

At least that way, DNSOP can continue doing DNS protocol work.
>
> Reviving it for another round in dnsop seems wrong.
>
> Paul Wouters
>
>
>
> On Oct 2, 2022, at 20:56, Suzanne Woolf  wrote:
>
>
>
>
> Dear colleagues,
>
>
>
> The chairs have been working for some time on a plan to address the
> ongoing issues around special use domain names (described in RFC 6761) and
> the domain namespace. These issues are described in RFC8244 -
> "Special-Use Domain Names Problem Statement"
> .
>
>
>
> WHAT, THIS AGAIN?
>
>
>
> (TL;DR: skip to “WHAT NOW?” below.)
>
>
>
> First what we need: a plan for the WG that will ensure, as best we can,
> that the WG has weighed in on domain namespace issues that affect the
> integrity and usefulness of the DNS, without getting entangled in issues
> that belong to other bodies (or to the users and developers of the Internet
> more generally). As our charter says, we agreed to “Publish documents
> that attempt to better define the overlapping area among the public DNS
> root, DNS-like names as used in local or restricted naming scopes, and the
> 'special names' registry that IETF manages, perhaps including how they
> might interact. This work must take into consideration issues that are
> strictly beyond the operation of the DNS itself, and the working group will
> consult with IETF liaisons to other organizations as appropriate.” (This
> language dates back to at least 2014.)
>
>
>
> Why we need it: In addition to the commitment to the community from our
> charter, this area has continued to provide new drafts, new concerns, and
> new questions. As painful as it may be to attempt to deal with them, it
> does seem better for the WG to try than to ignore the questions and hope
> they’ll go away. At the very least, the IETF needs some guidance on how
> protocols developed within the IETF can implement special use names.
>
>
>
> There is no requirement that a special use domain name be a single-label
> (or “TLD”) name, but as they have significant policy issues (as noted in 
> RFC2860
> - "Memorandum of Understanding Concerning the Technical Work of the
> Internet Assigned Numbers Authority")
>  they generate the most
> discussion and get the most attention.
>
>
>
> The primary value of the DNS protocol and naming conventions is serving as
> a useful and interoperable default for Internet naming. Ambiguity for
> applications in how to resolve domain names undermines interoperability
> across the namespace. The risks include not only explicit collisions but
> also a general erosion of confidence.
>
>
>
> Protecting the usefulness of the DNS may require some kind of coordination
> mechanism so that future developers can avoid ambiguity of resolution for
> Internet names.
>
>
>
> RFC 6761 establishes a registry for special use names, but its direct
> guidance on how to determine a name is appropriate to treat as “special
> use” is unscalable and potentially incomplete.  At one point we had six or
> seven different drafts, requesting a total of more than 40 single-label
> names, submitted for adoption by the WG, and any one of them seemed likely
> to result in controversy.
>
>
>
> The .onion case (RFC 7686) was resolved by making the draft a
> standards-track work item in the WG, but this exposed the d

Re: [DNSOP] draft-ietf-dnsop-alt-tld-17

[Warren Kumari]

On Mon, Oct 03, 2022 at 8:07 AM, Martin Schanzenbach <
mschanzenb...@posteo.de> wrote:

> Hi,
>
> FWIW: Triggered by the ADs mail on this ML and after re-reading -17 I
> would like to make clear that the current draft looks pretty good to me
> with minor nits as mentioned in this thread.
>

Excellent, and thank you very much![0]

W
[0]: One grows accustomed to the normal IETF interaction of "You mistyped
'the' as 'hte' on page 347 of draft-foo-bar-baz. That was dumb and you
should feel dumb" - it's nice to get a supportive email :-)
W


> Br
> Martin
>
> Excerpts from Paul Hoffman's message of 2022-08-23 18:52:18 +:
>
> Thanks again for all the discussion; it is helping the document. You can
> see from the diff at  rfcdiff?url2=draft-ietf-dnsop-alt-tld-17> that we have tightened the
> language, particularly around what is display format and what is wire
> format. More comments are of course welcome.
>
> --Paul and Warren
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS Directorate...

[Warren Kumari]

Just a very quick followup to this.

Thank you everyone who volunteered — Eric Vynke and I were pleasantly
surprised by just how many volunteers we got ( > 40!).
Actually, we seem to have a few too many volunteers; at some point a large
directorate becomes unwieldy, and so he and I are trying to find some time
to chat and figure out how to narrow down the slate some (this has been
made slower by travels and such).

Didn't want to leave y'all hanging, and we hope to have this wrapped up
soon.

Thank you again,
W



On Tue, Sep 13, 2022 at 3:18 AM, Warren Kumari  wrote:

> Hi there all,
>
> At IETF 114 I mentioned that Eric Vynke and I were planning on creating a
> DNS Directorate. Unfortunately  we got a little busy, and so it took a bit
> longer than expected, but we've finally had a chance to write up a
> "charter" (below).
>
> A number of people have already kindly offered to participate, but we'd
> like some more, so, if you are willing, please fill in this form - https:/
> /forms.gle/GDffKp2XuT9acK9T6  - this will add your info to a (private)
> spreadsheet so that Eric and I don't accidentally miss an email. If you
> have already volunteered, please fill it in anyway, just to make sure we
> didn't miss your mail…
>
> As usual, we are not looking only for "the" experts on DNS (even if those
> are welcome), but also for volunteers with good understanding of DNS
> security, privacy, operations, implementing, scalability, ... even if 'new'
> at the IETF. If you are willing to dedicate some time to review early
> drafts for the benefit of the IETF community: please step forward !
>
> Thank you,
> W
>
> -
> # DNS Directorate Charter (draft)
>
> DNS directorate reviewers assist Area Directors, Working Group chairs, and
> document authors with documents containing DNS-related content.
>
> More detailed guidance on DNS directorate process can be found at: http://
> wiki.ietf.org/group/dnsdir
>
> WG chairs or responsible ADs may request a DNS directorate review via the
> draft's Datatracker page. They are encouraged to do so as early in the
> process as possible to ensure that structural concerns are caught early in
> the document development.
>
> The DNS directorate secretaries will assign reviews to reviewers, but they
> are not required to check the list of IETF drafts for DNS-related ones.
>
> The DNS directorate reviews will be sent to the DNS Directorate mailing
> list (dns...@ietf.org), draft authors, WG chairs, and the respective AD.
>
> The DNS directorate reviewers and secretary are volunteers, and serve at
> the pleasure of the INT and OPS area ADs.
> 
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Last Call: (DNS Security Extensions (DNSSEC)) to Best Current Practice

[Warren Kumari]

On Sat, Sep 24, 2022 at 12:44 AM, Paul Hoffman 
wrote:

> On Sep 23, 2022, at 9:34 AM, tom petch  wrote:
>
> Going into the IANA registry by name, as I usually do, I think that from
> Section 6 DNSSEC Algorithm numbers
> DNSSEC NSEC3 parameters
> are groups and not registries whereas
> DNSSEC DS RRtype
> I have yet to find (but have not yet used the URL)
>
> Thanks for the comment. I don't know if there is a strict rule about what
> is an IANA "registry" verus a "group".
>


Yah. Things like this are deep IANA arcana, and I just nod happily and
agree when IANA tells me that I should be requesting X instead of Y (where
Y appears to be almost *exactly* the same thing as X, but subtly different
in some way important to the IANA).

This is a similar tactic to the one that I use with my cardiologist — he
explains in excruciating detail why he wants to change my meds from
$some_long_unpronouncable_name to $some_other_ long_unpronouncable_name,
because something something results something.

In both instances I smile and nod along (because it would be impolite not
to), but I just do what they tell me to, because they a: understand the
goal, b: are competent, and c: knows way more about this stuff than I ever
will (or want to)[0]. ¯\_(ツ)_/¯

W
[0]: The biggest difference is that there *is* advice that I ignore from my
cardiologist, but that's because he seems to be afflicted with some weird
mania around my getting exercise and also not having bacon for breakfast,
lunch and dinner..  It's actually a little odd, my primary care doctor
seems to be afflicted with this same fixation - I wonder if it is some sort
of medical religion thing?!

I do note that all three that are listed are top-level URLs, so I would
> guess that they would all be considered the same type of IANA thing.
>
> --Paul Hoffman
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNS Directorate...

[Warren Kumari]

Hi there all,

At IETF 114 I mentioned that Eric Vynke and I were planning on creating a
DNS Directorate. Unfortunately  we got a little busy, and so it took a bit
longer than expected, but we've finally had a chance to write up a
"charter" (below).

A number of people have already kindly offered to participate, but we'd
like some more, so, if you are willing, please fill in this form -
https://forms.gle/GDffKp2XuT9acK9T6  - this will add your info to a
(private) spreadsheet so that Eric and I don't accidentally miss an email.
If you have already volunteered, please fill it in anyway, just to make
sure we didn't miss your mail…

As usual, we are not looking only for "the" experts on DNS (even if those
are welcome), but also for volunteers with good understanding of DNS
security, privacy, operations, implementing, scalability, ... even if 'new'
at the IETF. If you are willing to dedicate some time to review early
drafts for the benefit of the IETF community: please step forward !

Thank you,
W

-
# DNS Directorate Charter (draft)

DNS directorate reviewers assist Area Directors, Working Group chairs, and
document authors with documents containing DNS-related content.

More detailed guidance on DNS directorate process can be found at:
http://wiki.ietf.org/group/dnsdir

WG chairs or responsible ADs may request a DNS directorate review via the
draft's Datatracker page. They are encouraged to do so as early in the
process as possible to ensure that structural concerns are caught early in
the document development.

The DNS directorate secretaries will assign reviews to reviewers, but they
are not required to check the list of IETF drafts for DNS-related ones.

The DNS directorate reviews will be sent to the DNS Directorate mailing
list (dns...@ietf.org), draft authors, WG chairs, and the respective AD.

The DNS directorate reviewers and secretary are volunteers, and serve at
the pleasure of the INT and OPS area ADs.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

Hi all,

Firstly, and most importantly, thank y'all for keeping this civil, friendly
and productive; I really appreciate it.

I've (informally) checked with the IESG on the proposed change in the
PR and also including Erik's proposed operational note ("Some
implementations may not allow A or  records on names starting with an
underscore due to various interpretations of RFCs. This could be an
operational issue when the TargetName contains an attrleaf label, as well
as using an TargetName of "." when the owner name contains an attrleaf
label.") and everyone seems fine with it.

So, I'm ask the authors to cut a new version with these changes in
(basically, accept the PR and add the proposed text) and I will then email
the IESG with a diff to get "official" consensus on the change.

Dealing with process exception handling is always stressful, so thanks all
again for keeping this moving along nicely.
Also, a reminder that while we *can* make changes after approval (and
before RFC publication) we really really avoid doing so, and so this should
only happen under exceptional circumstances[0].

W

[0]: I'm not convinced that this situation rose to the "exceptional
circumstances" bar, but seeing as I'd already paused it (not knowing what
all the issues were) and because the changes are clarifications, I'm
willing to accepting it.

On Thu, Sep 08, 2022 at 12:34 PM, Erik Nygren  wrote:

> There seem to be two topics:
>
> 1) Victor's clarification makes sense, although the wording is a little
> awkward and perhaps we can improve that sentence.
> The section was already implying that meaning (ie, that the fallback
> addition of the QNAME was for the AliasMode case)
> but clarifying this in a more normative way seems worthwhile and not a
> technical change.
> I'd propose we refine this PR and incorporate it as the "clarifying
> sentence" that Warren was willing to accept.
>
> 2) There is the issue of whether attrleaf labels are valid owner names for
> A/ records.
> This document does not seem like the place to land that, and it seems
> like it may be open for interpretation
> as different implementations may have interpreted it differently.  If
> anything, we might add a non-normative sentence like:
>
>"Some implementations may not allow A or  records on names
> starting with an underscore
> due to various interpretations of RFCs. This could be an
> operational issue when the TargetName contains an attrleaf label,
> as well as using an TargetName of "." when the owner name contains
> an attrleaf label."
>
>This wouldn't be a normative change but just an operational warning ---
> would this be acceptable to include at this stage?
>Further clarification of this seems worth a draft in its own right
> since the existing RFCs are inconsistent
>on this topic and there is room for multiple interpretations, as shown
> in some implementations.
>
>
>
> On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman 
> wrote:
>
>> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni 
>> wrote:
>> > This is a bug fix, the proposed behaviour makes no sense when $QNAME
>> > is the unaltered (attrleaf prefixed) starting point.  The current
>> > meaning was not intended.  If the edit can be made without any
>> > major process, just a note to the RFC editor, it'll save errata,
>> > and possible confusion later.
>>
>> A technical change made after the IESG review requires, at a minimum,
>> another IESG review. The IESG could ask for another IETF review, if they
>> want. It's up to Warren, the responsible AD, to decide if that's "major
>> process".
>>
>> --Paul Hoffman
>>
>> ___
>> 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] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

I chatted with Viktor Dukhovni late last week, and he promised us a
sentence to solve all that ails us… or, at least, a simple, clear, concise
sentence which only clarifies what appears to have been intended.

I suspect that US Labor day vacation got in the way, but I hope to have it
soon.
If not, I think we just stick with the original - 'tis not perfect, but all
can be fixed in a -bis[0].

W
[0]: Quick, someone put that on a t-shirt…



On Wed, Sep 07, 2022 at 5:20 PM, Ben Schwartz  wrote:

> As I noted earlier, changing the non-SVCB fallback recommendation to "MAY"
> would nominally make HTTPS-record deployment riskier.  I'm inclined to take
> the current approach (encouraging fallback when it is safe) for now, and
> perhaps revisit this question in a few years if operational experience
> shows it to be unnecessary.
>
> On Wed, Aug 31, 2022 at 11:00 PM Tommy Pauly  wrote:
>
> I don’t personally find this proposal to be an improvement for clarity.
>
> The fact that a client is SVCB-optional means, somewhat by definition,
> that they allow not using the SVCB results. Saying that the client “MAY”
> doesn’t really help; it’s the very definition of what SVCB-optional is. If
> the client doesn’t use non-SVCB connection modes at that point, then it is
> SVCB-reliant.
>
> Listing out the details of what a non-SVCB connection does (not using the
> information from the SVCB record) also seems redundant. It is more accurate
> to just say “don’t use anything from SVCB if SVCB didn’t work” rather than
> trying to list out what all of those details might be.
>
> Tommy
>
> On Aug 31, 2022, at 4:13 PM, Brian Dickson 
> wrote:
>
> So, here is my suggestion, for "a sentence (or possibly two) which only
> clarify what is already written?":
>
> In section 3:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> becomes:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>
>the authority endpoint's port number, and no SvcParams.
>
> (The original didn't use RFC 2119 language, but the list of failure modes
> in 3.1 leads to "MAY" being the most appropriate choice.)
>
> Let me know if that is good enough.
> (The rest can go into a -bis... how soon are we allowed to start a -bis
> document? The day of RFC publication? I'd like to start that as soon as
> possible, while everything is still fresh.)
>
> Brian
>
> On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  wrote:
>
>
>
>
>
> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson  com> wrote:
>
> Here are some proposed text changes, per Warren's invitation to send text:
>
>
>
> Um, no.  Warren said: "can we craft a sentence (or possibly two) which
> only clarify what is already written?". This is a significantly larger set
> of changes than that. The Section 3 changes in particular are (IMO) much
> more than a clarification.
>
> These may or may not be good changes, but anything approaching that level
> of change would have to be in a -bis document…
>
> W
>
>
>
> In section 1.2, change:
>
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
>
> to:
>
> 2.  TargetName: Either the domain name of the alias target (for
>AliasMode) or the host name of the alternative endpoint (for
> ServiceMode).
>
> In section 2.4.2, change:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
> to:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service
> name,
>although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
>
> In section 2.4.3, change:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
>
> to:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate a

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <
brian.peter.dick...@gmail.com> wrote:

> Here are some proposed text changes, per Warren's invitation to send text:
>


Um, no.  Warren said: "can we craft a sentence (or possibly two) which only
clarify what is already written?". This is a significantly larger set of
changes than that. The Section 3 changes in particular are (IMO) much more
than a clarification.

These may or may not be good changes, but anything approaching that level
of change would have to be in a -bis document…

W



> In section 1.2, change:
>
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
>
> to:
>
> 2.  TargetName: Either the domain name of the alias target (for
>AliasMode) or the host name of the alternative endpoint (for
> ServiceMode).
>
> In section 2.4.2, change:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
> to:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service
> name,
>although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
>
> In section 2.4.3, change:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
>
> to:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters. The TargetName MUST be a host name
>(as defined in [DNSTerm].)
>
> In section 3, the following changes are proposed; they introduce a new
> term LASTNAME to be used to disambiguate the $QNAME reference so as to
> remove ATTRLEAF prefixes from the appended target:
>
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3).
>
> becomes:
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3). Let $LASTNAME be the service name without
> any prefixes.
>
>
>
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes) and loop back to step 2, subject to
>chain length limits and loop detection heuristics (see
>Section 3.1).
>
> becomes:
>
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes), set $LASTNAME to this new $QNAME and
> loop back to step 2, subject to
>chain length limits and loop detection heuristics (see
>Section 3.1).
>
>
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $QNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
>
> becomes:
>
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $LASTNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> becomes:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>
>the authority endpoint's port number, and no SvcParams.
>
>
> One additional suggested addition to the end of section 3.1 is:
>
>If DNS responses are cryptographically protected, and at least
>one HTTPS AliasMode record has been received successfully,
>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
>even when reverting to non-SVCB connection modes. Clients
>
>also MAY 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

On Mon, Aug 29, 2022 at 12:33 PM, Erik Nygren  wrote:

> Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and
> Eric Orth
> that the current behavior makes sense and that no fundamental technical
> change is needed.
>


I've been watching this thread and following along - it has been a
fascinating discussion, but I agree that there are no fundamental technical
changes needed — there is nothing here that falling into the "OMG! That
clearly doesn't work, 1+1 doesn't equal 17…" camp.

With that said, the fact that we have had this robust of a discussion shows
that there is ambiguity / different interpretations possible.

No matter what we do, odd faults and misconfigurations will happen and
> Postel's law applies.
> Client implementers will try and be liberal with what they accept (as long
> as doing so doesn't introduce
> security issues, such as if you know you have bad data), and even then
> some client implementers
> may ignore this and still try to be robust.
>
> On the "how to sell this behavior", beyond giving client implementers the
> ability
> to be robust, there will be clients not implementing SVCB/HTTPS RRs
> behavior for
> a long time to come, so fallbacks will be needed for a long time.  HTTPS
> RR in particular
> is specified as SVCB-optional.
>
> I think some confusion keeps coming from a desire to think of AliasMode
> SVCB RRs
> as "CNAMEs that can live at the apex" which they are not, even if they can
> help solve
> that problem.
>

Yes, that desire / area does seem to be a significant part of the confusion
- but we did already discuss this topic in the WG before WGLC, and nothing
seems to have changed.

Brian, if I understand it right your 301 redirect approach seems like a
> reasonable
> way to address the fallback and legacy client case (and as clients pick
> this up the need
> for those redirects should decrease).
>
> On paths forward on the draft as it stands to clarify without making
> significant technical changes (which I don't think are necessary):
>
> * Are there particular clarifications we can/should add to help make the
> current
>   behavior more clear to readers?  For example, would having some examples
>   of the failure cases (without changing the semantics) help?
>   Note that since the fallback behavior is a SHOULD not a MUST for
> clients,
>   it can't necessarily be relied upon.
>


… and that's what I'm trying to figure out — can we craft a sentence (or
possibly two) which only clarify what is already written? Like "When we
said 'Call me a taxi' we mean "Please summon a taxi", not "Ok, you are a
taxi!" "...



> * This might be too much of a technical change at this point,
>   but would it make sense to change the SHOULD to a MAY on client
>   fallback behavior?  Clients implementations may choose to ignore the
> SHOULD
>   so this doesn't change the contract.
>

Yes, I think that that would be too large of a change. If there was very
strong and clear consensus from the WG that that is *obviously* the right
thing to do we *could* do another WGLC and IETF LC *only* on that point,
but I really really don't see anything approaching that level of consensus
(nor do I think it is needed — SHOULD is very close to MAY in this case).


> * For the rfc1123 section 2 topic, it may make sense to clarify the text
>  to say "domain name" rather than "hostname":
>> An "alternative endpoint" is a hostname, port number, and other
>> associated instructions to the client on how to reach an instance
>> of service.
>   Everywhere else in the normative sections such as 1.2 and 2.1 we
>   say that the TargetName is a "domain name" (aligned with the
> clarification in rfc8499
>   on the difference between host and domain names).
>

I think that the current is clear enough. I agree that it would probably
have been better as 'domain name' if we had caught that at WGLC / IETF LC,
but I think it would be gratuitous / not rise to the level of 'futzing
after approval'...


> On the rfc1123s2 front. a corner-case that might be encountered is that
> Proxies might be confused by "When connecting using a SVCB record,
> clients MUST provide the final TargetName and port to the proxy"
> in the case where proxies don't expect a domain name (eg, with an
> underscore prefix).
> I don't know if there is any warning we should provide about this
> corner-case,
> or cover that in the future if it turns out to be a problem?
>
>
> For the future, there are subsequent drafts that could be introduced:
>
> * We could add an optional "nofallback" SvcParam to AliasMode as Brian
> suggests,
>   but in a future draft. (This would be the first SvcParam on AliasMode,
> but they are allowed
>   and introducing them might help prevent ossification of this extension
> point.)
>


Yup, this seems like a fine thing to consider putting in a -bis / Updates:
document.

* Introducing an optional "Alt-Used" equivalent (eg, "Service-Used")
>   that provides information about the SVCB/HTTPS RR path foll

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Warren Kumari]

On Tue, Aug 23, 2022 at 12:09 PM, Martin Schanzenbach <
mschanzenb...@posteo.de> wrote:

> On 23. Aug 2022, at 16:47, Warren Kumari  wrote:
>
> On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen  wrote:
> On 8/23/22 07:02, Ray Bellis wrote:
>
> There will be a very long tail of systems out there that do not know about
> ".alt".
>
> How would those systems respond when passed a domain-style name that does
> not meet domain-style syntax rules (specifically those for total length and
> label lengths) ?
>
> Designers of that other non-DNS protocol will have to consider all kinds
> of interoperability issues, including what kind of strings are permissible
> under their branch of .alt, and what consequences would arise from that.
>
> IMO, that is within the realm of the specification of that other non-DNS
> protocol, just like any other protocol consideration that occurs when
> evolving a specification while implementing it; we DNS people don't have to
> mandate fences for the general case.
>
> Mandate no, but I do think that we should "helpfully suggest".
>
> There are many ways to refer to a host — for example, I recently had to
> ask someone to swap a drive in a server for me, and I resolved the identity
> with: "it's the Dell server towards the bottom of the rack near the door."
> Clearly this is a pathological case, but putting ".alt" at the end of that
> doesn't really help :-).
>
> Much of the reason for needing something like .alt is that the context
> isn't explicit, and so we expect that these names will be used in places
> that generally expect something like a "DNS name". I think that some text
> suggesting that for interoperability with existing applications (which may
> do some sort of checks or processing on the user input) people may want to
> constrain themselves to LDH / DNS syntax. There are no protocol police, and
> so we cannot actually enforce this even if we wanted to — I can technically
> put  weird looking pyramid thingie emoji>.kumari.net into my zonefile, and
> there is nothing you can to do stop me…  — but it
> sure won't work well…
>
> So, I'd think something like: "For compatibility with existing
> applications and to maximize interoperability, it is recommended that names
> that end in .alt follow DNS name syntax." (or something similar but better
> worded).
>
> Who is this recommendation supposed to be for? The user
> "registering/creating" a name or the protocol? I think that the
> specification of the protocol may recommend to users that they should
> carefully consider the name chosen when it is supposed to be used with
> ".alt".
>


What I put in my pull request is: "To maximize compatiblity with existing
applications, it is suggested that non-DNS protocols using names that end
in .alt follow DNS name syntax." - it is just a suggestion, there is no
"force" behind it...

But my question would still be: Should the registry pose limitations, then,
> on the 2LD? Because you cannot really have the one without the other?
>

I don't think that it can (or should). This is just a suggestion… I had
considered wording it as  "it is recommended that…", but that sounded
stronger and that people might confuse it with "RECOMMENDED".

W


> BR
> Martin
>
> W
>
> Best,
> Peter
>
> --
> https://desec.io/
>
> ___
> 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] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Warren Kumari]

On Tue, Aug 23, 2022 at 11:45 AM, Peter Thomassen  wrote:

> On 8/23/22 11:38, Paul Hoffman wrote:
>
> On Aug 23, 2022, at 7:47 AM, Warren Kumari  wrote:
>
> So, I'd think something like: "For compatibility with existing
> applications and to maximize interoperability, it is recommended that names
> that end in .alt follow DNS name syntax." (or something similar but better
> worded).
>
> An application that understands a non-DNS protocol already is compatible
> with that naming scheme.
>
> I think their point is that the application (e.g. browser) may be agnostic
> of the resolution system (= accept the name), but resolution may fail
> because something switching layer like nsswitch would choke on a
> non-DNS-style name, *even when* the downstream non-DNS resolver would be
> available.
>
> So, by making the non-DNS names DNS-style, one can allow for more agnostic
> intermediate layers in the process that make DNS-like assumptions.
>
> Given that, I can see why a sentence like the one suggested by Warren
> could make sense.
>
> OTOH, it's possible that a given non-DNS protocol comes with its own
> application layer (i.e. no legacy pieces with DNS-like assumptions
> involved), and it's questionable whether a name syntax recommendation would
> cause undue restrictions for these cases.
>
> All in all, I think either way is fine (weak suggestion/recommendation, or
> nothing at all).
>


I think that is helpful to communicate expectations, and also help minimize
people accidentally hurting themselves on sharp corners. I see no downside
to suggesting using names that are more likely to work (I also personally
think that it is cleaner and easier for developers and humans to be able to
more easily recognize names than "oh, here is a string that ends in .alt… I
wonder where it begins :-))

W



> Peter
>
> --
> https://desec.io/
>
> ___
> 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