[DNSOP] Last Call: (Fragmentation Avoidance in DNS) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Fragmentation Avoidance in DNS' as Best Current Practice 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-10-27. 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. Abstract EDNS0 enables a DNS server to send large responses using UDP and is widely deployed. Large DNS/UDP responses are fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document proposes techniques to avoid IP fragmentation in DNS. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8899: Packetization Layer Path MTU Discovery for Datagram Transports (Proposed Standard - Internet Engineering Task Force (IETF)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] AD Review of: draft-ietf-dnsop-dns-error-reporting
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
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", "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 there should be some control on it.
>>
>
> The above attack and possible mitigation is discussed in the security
> considerations section of the draft, please see the snip below:
>
>
>A client might choose to display the information in the "c", "j", and
>"o" fields if and only if the encrypted resolver has sufficient
>reputation, according to some local policy (e.g., user configuration,
>administrative configuration, or a built-in list of respectable
>resolvers). This limits the ability of a malicious encrypted
>resolver to cause harm. For example, an end user can use the details
>in the "c" field to contact an attacker to solve the problem of being
>unable to reach a domain. The attacker can mislead the end user to
>install malware or spyware to compromise the device security posture
>or mislead
[DNSOP] dnsop - Requested sessions have been scheduled for IETF 118
Dear Tim Wicinski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnsop Session 1 (1:00 requested) Tuesday, 7 November 2023, Session IV 1700-1800 Europe/Prague Room Name: Congress Hall 3 size: 250 - dnsop Session 2 (2:00 requested) Friday, 10 November 2023, Session I 0930-1130 Europe/Prague Room Name: Congress Hall 2 size: 350 - iCalendar: https://datatracker.ietf.org/meeting/118/sessions/dnsop.ics Request Information: - Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): Number of Attendees: 160 Conflicts to Avoid: Can't meet: Monday morning, Monday early afternoon, Friday morning, Friday early afternoon, Friday late afternoon Participants who must be present: Resources Requested: Special Requests: first session to be early in the week for rootops is on Sunday. prefer not Monday morning as we also like to include hackathon results in our meeting. If need be, can do as 1.5 + 1 hr - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping
I was looking at these two drafts. The first one says that scanning for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The second one says to scan for DS bootstrap. I am experiencing cognitive dissonance. I suggest adjusting the bootstrap draft saying to send NOTIFY(DS) to the parent of a delegated name to tell it to do the bootstrap rather than scanning. The issues in section 3 about why scanning is bad and in section 4 about where to send the notification are exactly the same as what's there now. I suppose you could overload NOTIFY(CDS) and the parent does one or the other depending on whether the zone already is signed but it seems to me that the operations are different so the notification might as well be different too. Bonus update: if we do this, in the bootstrap draft take out section 4.3 on triggers and instead say to use notify. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-bash-rfc7958bis
On 13 Oct 2023, at 17:22, Paul Wouters wrote: > On Thu, 12 Oct 2023, Tim Wicinski wrote: > >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-bash-rfc7958bis/ >> Here is the diff from RFC7958 itself: >> https://author-tools.ietf.org/iddiff?url1=rfc7958=draft-bash-rfc7958bis-01=--html >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and send any comments to the list, clearly stating your view. >> Please also indicate if you are willing to contribute text, review, etc. > > Suitable for adoption. I do find it a little strange the document is > basically IANA publishing policy, and the document containing > non-IANA/ICANN authors :P Well I was actually ICANN staff when I helped write the original :-) If there's something in here that doesn't match reality then there's an IANA review that has to pass before the document gets stamped with a number, and I'm pretty sure that review would not pass if this was all so many contrived lies. Our rationale when we published 7958 was that this information relating to the Internet infrastructure that is relevant to a general audience, and it belongs in the RFC series since we want to represent a specification that people can code against. I think the same argument holds with the successor. A benefit of keeping the changes to the spec in the RFC series is that we retain the whole history and don't have to resort to e-mail archives or the Internet Archive to find out what changed when and why. I don't think you were suggesting otherwise or disagreeing with any of the above, but I thought the context might be useful to others following along. While I think it's also plausible to imagine this document being published as an individual or AD-sponsored submission away from dnsop, I think it'd be much better to have dnsop eyes on it and get the benefit of any suggested improvements for clarity, avoidance of ambiguity, etc. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-bash-rfc7958bis
On Oct 13, 2023, at 08:21, Paul Wouters wrote: > > On Thu, 12 Oct 2023, Tim Wicinski wrote: > >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-bash-rfc7958bis/ >> Here is the diff from RFC7958 itself: >> https://author-tools.ietf.org/iddiff?url1=rfc7958=draft-bash-rfc7958bis-01=--html >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and send any comments to the list, clearly stating your view. >> Please also indicate if you are willing to contribute text, review, etc. > > Suitable for adoption. I do find it a little strange the document is > basically IANA publishing policy, and the document containing > non-IANA/ICANN authors :P The same was true for RFC 7958. Maybe we've mostly forgotten the "OP" part of DNSOP. In order to operate a validating DNS resolver, you need to understand how the trust anchors are published. This describes that. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-bash-rfc7958bis
On Thu, 12 Oct 2023, Tim Wicinski wrote: The draft is available here: https://datatracker.ietf.org/doc/draft-bash-rfc7958bis/ Here is the diff from RFC7958 itself: https://author-tools.ietf.org/iddiff?url1=rfc7958=draft-bash-rfc7958bis-01=--html Please review this draft to see if you think it is suitable for adoption by DNSOP, and send any comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. Suitable for adoption. I do find it a little strange the document is basically IANA publishing policy, and the document containing non-IANA/ICANN authors :P Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-qdcount-is-one-00.txt
Internet-Draft draft-ietf-dnsop-qdcount-is-one-00.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: In the DNS, QDCOUNT is (usually) One Authors: Ray Bellis Joe Abley Name:draft-ietf-dnsop-qdcount-is-one-00.txt Pages: 7 Dates: 2023-10-13 Abstract: This document clarifies the allowable values of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) and specifies the required behaviour when values that are not allowed are encountered. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-qdcount-is-one-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt
On Thu, 12 Oct 2023 at 21:37, Tommy Pauly
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", "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 there should be some control on it.
>
The above attack and possible mitigation is discussed in the security
considerations section of the draft, please see the snip below:
A client might choose to display the information in the "c", "j", and
"o" fields if and only if the encrypted resolver has sufficient
reputation, according to some local policy (e.g., user configuration,
administrative configuration, or a built-in list of respectable
resolvers). This limits the ability of a malicious encrypted
resolver to cause harm. For example, an end user can use the details
in the "c" field to contact an attacker to solve the problem of being
unable to reach a domain. The attacker can mislead the end user to
install malware or spyware to compromise the device security posture
or mislead the end user to reveal personal data. If the client
decides not to display all of the information in the EXTRA-TEXT
field, it can be logged for diagnostics purpose and the client
Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt
Moin! On 12 Oct 2023, at 18:54, Eric Orth wrote: > Advertisements would be annoying, but my biggest concern with this stuff > has always been links to pages that mimic the page the user was trying to > access in the first place. If the user types in social-network.com, I > don't trust users to not click links in the result without reading them and > go with it once they hit a page that looks like the social-network.com > login page. Maybe it could be two step. First have a generic page that is created by the browser telling that something is being blocked by including the organisation name and then have link to “more information here”? So long -Ralf ——- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
