[DNSOP] Re: [v6ops] Re: systemd-resolved not aboiding IPv6 DNS Servers

[Tim Chown]

Hi,

On 03/04/2025, 22:08, "Brian E Carpenter"  wrote:

Hi Tobias,
On 03-Apr-25 21:05, Tobias Fiebig wrote:
> Moin,
>> Good point. So maybe we do need a stand-alone BCP for this? Or
>> perhaps it should be added to section 7 of draft-ietf-6man-rfc8504-
>> bis?
>>
>> "IPv6 addresses for DNS servers SHOULD be preferred over IPv4."
>
>
> This is pretty close to the 3901bis discussion in DNSOP atm; I would
> personally recommend not making this a stand-alone BCP;

I agree.

>
> Things to consider (also for the proposed algorithm in the ticket at:
> https://github.com/timchown/rfc8504-bis/issues/20 ):
>
> - There is no HE for DNS; The proposed text basically creates that for
>stubs
> - RFC3901 (currently) covers authoritative and recursive servers, the
>issue here is about stubs
>
> Technically, the language planned for 3901bis makes v4 and v6 equal
> citizens, i.e., both SHOULD. The translation point is similar to:
> https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/

Fair enough. It seems to me that "host requirements" is the logical place
to specify a preference for IPv6 over IPv4, so personally I now prefer
the 8504bis option, but I wouldn't object to putting it in 3901bis either.

The general principle in 8504 is to be a summary of requirements and to point 
to other RFCs that define them, so doing both is perfectly viable.

Tim


Brian

>
> Even though that draft is again resolver specific.
>
> I see three options for this:
>
> - Add the language independently in 8504bis as planned in the ticket
> - Integrate the part about resolution address selection from the draft
>above into 3901bis and also add stubs to the text
> - Move stubs and recursive servers (or maybe even each) into their own
>documents and bind them via BCP91 (which can also hold other DNS
>transport related things, including transport protocol selection,
>and technically 9715 (The 'big' solution i had mentioned before)
>
> Not arguing for any of the options atm; Just putting them out there to
> see what people think.
>
> With best regards,
> Tobias
>
> ___
> v6ops mailing list -- v6...@ietf.org
> To unsubscribe send an email to v6ops-le...@ietf.org

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

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-must-not-sha1-05

[Florian Obser via Datatracker]

Document: draft-ietf-dnsop-must-not-sha1
Title: Deprecating the use of SHA-1 in DNSSEC signature algorithms
Reviewer: Florian Obser
Review result: Ready

My comments from the dnsdir review for -03 have been addressed.
This document is ready.


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

[DNSOP] Re: [v6ops] Re: systemd-resolved not aboiding IPv6 DNS Servers

[Tim Chown]

Hi,

On 04/04/2025, 10:29, "Tobias Fiebig"  wrote:

Moin,

On Fri, 2025-04-04 at 08:13 +, Tim Chown wrote:
> The general principle in 8504 is to be a summary of requirements and
> to point to other RFCs that define them, so doing both is perfectly
> viable.

Fair point; Question is, though, if one would want to basically create
a dependency for the publication of 8504bis on 3901bis; Something tells
me that it will be a longer road for the latter. ;-)

Yes, in this case that would be the downside.

We had a similar discussion about EH processing for 8504. You’ll see some text 
in there about that, as we thought that better than a dependency on a parallel 
draft.  That “parallel draft” is now only just in IESG review several years on.

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

[DNSOP] Re: [Last-Call] Re: Dnsdir last call review of draft-ietf-dnsop-must-not-sha1-03

[Vladimír Čunát]

On 04/04/2025 04.18, Viktor Dukhovni wrote:

I'd like to suggest a change in section 4:


I agree.  And/or it might reference the algorithm table extended in 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/

(RECOMMENDED in column "use for DNSSEC signing")

--Vladimir | knot-resolver.cz
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] AD review of draft-ietf-dnsop-structured-dns-error

[Eric Vyncke (evyncke)]

Dear authors, dear shepherd, DNSOP WG,

As Mohamed ‘Med’ Boucadair is now the responsible AD for DNSOP, he passed me 
the role of responsible AD for this I-D :-) Therefore, here is my own AD 
review. Before proceeding with the publication process (IETF Last Call and the 
IESG evaluation), I request to have all points below addressed, i.e., by 
changing the text, by replying by email wit explanations, ... (Feel free to 
reject my comments as long as you explain why).

Benno, the shepherd’s write-up needs to be revised:

  1.  In point 1), there is an unfinished sentence “The status of Proposed 
Standard will”
  2.  Change the responsible AD to a guy name “Éric Vyncke” ;-)

### Section 1

I am unsure whether firewalls and IPS do use DNS filtering rather than content 
inspection.

Is it worth defining “Users of DNS service”, is it the app or the user using 
the app ? The text also uses “end user”, is the same human being ?

` the DNS server`is a little ambiguous here, should it rather be “recursive DNS 
resolver“ ?

### Section 3

` In order to return a block page over HTTPS, man in the middle (MITM)` should 
“without triggering an invalid TLS server authentication” be added ? Please 
refrain from using “MITM”, favor “on path attack” or simply “interception” in 
this case.

` The HTTPS server will have access` unsure which HTTPS server is referred 
to... is it the expected or the spoofed reply servers ?

s/Enterprise networks do not assume/Enterprise networks do not always assume/

Should there be text in the DNSSEC bullet that if the filtering DNS server is 
also the DNSSEC validator, then all is good ?

Should bullet (4) be merged in bullet (3) ?

### Section 4

Does this text add any value ` Note that 
[RFC7493] was based on 
[RFC7159], but 
[RFC7159] was replaced by 
[RFC8259].`?

s/ This field is structured as an array of contact URIs, using/ This field is 
structured as an array of contact URIs that MUST use/ ?

Can the “l” name occur in the absence of “j” or “o” names ?
As I live in a country with 3 (+ English) languages, I sincerely regret that 
only one language can be used... IMHO, “j” should be an array of  especially when the end user is residential.

Did the WG consider using a single URI pointing to a possibly larger JSON file ?

Did the WG consider using CBOR for encoding ? It may be useful to justify in 
the I-D why JSON was preferred to CBOR.

### Section 5.2

S/ A or  record query/ A or  resource record query/

The 2 seconds for TTL seems very short to me. I would avoid using this value 
even as an example.

### Section 5.3

As the I-D states `following ordered actions`, please use a numbered list.

Also, I wonder about the actual order as the channel considerations should 
probably be first, before the JSON syntax.

In ` If the "c" field contains any URI scheme not registered in the Section 
10.3
 registry, it MUST be discarded` it is unclear what the “it” refers to.

s/ In such a case, the content of the "c" attribute can be ignored/ In such a 
case, the content of the "c" attribute MAY be ignored/

The last two bullets (DNS forwarder and app) are not really part of this list 
but should probably appear as stand alone.

### Section 6

Is worth explaining why value = 0 is there and why there are no values for 1 to 
4 ?

### Section 7

It is unclear whether the original reply is forwarded as it is received, i.e., 
is the information specified in this document also forwarded ?

### Section 10.1

I am not an application expert, but is this registration required ?

### References

draft-ietf-add-ddr-10 is now RFC 9642

draft-ietf-add-resolver-info-13 is now RFC 9606 (the authors should know ;-) )

DNS terminology is no more RFC 8499 but RFC 9499




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

[DNSOP] Re: [Last-Call] Re: Dnsdir last call review of draft-ietf-dnsop-must-not-sha1-03

[Mark Elkins]

I'd also add a date into the text for this suggestion - which I 
completely agree with... then review it in several years from now.


On 2025/04/04 09:36, Vladimír Čunát wrote:

On 04/04/2025 04.18, Viktor Dukhovni wrote:

I'd like to suggest a change in section 4:


I agree.  And/or it might reference the algorithm table extended in 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/

(RECOMMENDED in column "use for DNSSEC signing")

--Vladimir | knot-resolver.cz


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

--

Mark James ELKINS  -  Posix Systems - (South) Africa


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

[DNSOP] Re: [v6ops] Re: systemd-resolved not aboiding IPv6 DNS Servers

[Tobias Fiebig]

Moin,

On Fri, 2025-04-04 at 08:13 +, Tim Chown wrote:
> The general principle in 8504 is to be a summary of requirements and
> to point to other RFCs that define them, so doing both is perfectly
> viable.

Fair point; Question is, though, if one would want to basically create
a dependency for the publication of 8504bis on 3901bis; Something tells
me that it will be a longer road for the latter. ;-)

With best regards,
Tobias

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