Re: [Add] DNR and IP hints

[[e-mail]]

Re-,

It uses the parameters for convenience but does not assume that the DNS library is actually supporting SVCB. As you may notice, we don't have any normative language in Section 3.1.6.

As a reminder, we insisted on that in many occasions, e.g., during the IESG review https://mailarchive.ietf.org/arch/msg/add/dtFLSRNR81RKG3isbv08Ju5gxGc/

==
[Med] The normative part of the spec is drawn from the (discovery) perspective of DHCP clients and RA receivers, not DNS clients. This why we are not using the normative language in the text you quoted.
==

Thank you.

Cheers,
Med

De : Ben Schwartz <[e-mail]>
Envoyé : jeudi 5 octobre 2023 16:06
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]
Cc : [e-mail]
Objet : Re: DNR and IP hints

DNR uses SVCB SvcParams, including any relevant SvcParams defined in the future.  It therefore necessarily inherits SVCB's backward compatibility and optionality rules, apart from any documented exceptions (such as IP hints).

DNR Section 3.1.6 ("ADN Only Mode") actually does assume that some clients are SVCB-capable.  There's no indication that the DNR SvcParams conveyed in Section 3.1.5 are different from the (syntactically and semantically identical) SVCB SvcParams conveyed in Section 3.1.6, so they are processed in the same way (apart from documented exceptions).

--Ben
________________________________
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 5, 2023 9:49 AM
To: Ben Schwartz <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DNR and IP hints

Hi Ben, First of all, DNR data does not make any assumption about the DNS library that will consume the data. Whether it is SVCB-capable or not is not the business of the DHCP. Second, the check between hints/ip addresses is to avoid weird
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi Ben,



First of all, DNR data does not make any assumption about the DNS library that will consume the data. Whether it is SVCB-capable or not is not the business of the DHCP.



Second, the check between hints/ip addresses is to avoid weird situations where these two convey diverge. It is better to control and detect the error at the DHCP level.



Cheers,

Med



De : Add <[e-mail]<mailto:[e-mail]>> De la part de Ben Schwartz
Envoyé : jeudi 5 octobre 2023 15:40
À : [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>
Objet : [Add] DNR and IP hints



Somewhat related to our text/wire format discussion, I see a problem with DNR's instruction about IP hints.  In most places, the draft simply says that the option "MUST NOT" contain ipv4hint or ipv6hint, which I interpret as a requirement on the configuration author (not the DHCP server or client).  However, DNR Section 3.1.8 [1] says that the receiver checks that "the service parameters do not include "ipv4hint" or "ipv6hint" service parameters", and if this check fails "the receiver discards the received Encrypted DNS option".



This appears to be based on a misunderstanding of how SVCB clients work. SVCB clients simply ignore SvcParams that they are not using, or discard the record if an unrecognized SvcParam is marked as "mandatory".  This check is very strange: it forces clients to add knowledge of the "ipv4hint" key even though they don't intend to use it, and then artificially fail on any option that contains it.



It also makes implementation much harder on the DNR sender.  In principle, DNR senders should be able to memcpy the SvcParams directly out of the resolver's DDR RDATA.  This simplifies configuration by ensuring a single point of truth, and avoids ossification because the DHCP server does not need to understand the SvcParams.  However, since ipv4hint is not prohibited in DDR, this requirement forces the DHCP server to filter it out.



This filtering can be performed while passing unrecognized SvcParams through, but it represents added complexity for no obvious benefit.



--Ben Schwartz



[1] https://www.ietf.org/archive/id/draft-ietf-add-dnr-16.html#name-dnr-validation-checks

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

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

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