choices are 1400, 1232 or others
- Need static configuration parameters at authoritative, recursive resolvers,
stub rsolvers ?
Regards,
--
Kazunori Fujiwara, JPRS
> From: internet-dra...@ietf.org
> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-07.txt
> Date:
se the
| default maximum DNS/UDP payload size 1400.
----
Regards
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ion/
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-08
Regards,
--
Kazunori Fujiwara, JPRS
> From: internet-dra...@ietf.org
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name Sy
Abley-san, thanks very much for your comments.
> From: Joe Abley
> Fujiwara-san,
>
> On Sep 22, 2022, at 11:05, Kazunori Fujiwara wrote:
>
>> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and
>> they often don't work as expected.
&g
v6 address record
available for the name servers of any child delegations within the
zone.
----
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> From: Petr Špaček
> On 15. 08. 22 12:18, Kazunori Fujiwara wrote:
>>
>>> I assume section 3.2 means the EDNS bufsize in the request when it
>>> says
>>> "their payload size", but I am not sure. The text could be clearer on
>>> that.
&g
ative. The only I know for certain
> is that we had multiple iterations in BIND, are not happy with any of
> them, and and it is order of magnitude more complex than we thought.
At least, I would like to disable IPv6 fragmentation.
and I would like to make "avoid IPv4 fragmetion" our goal.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ating
> for potential breakage we can imagine. So, I suggest this would at most
> be a MAY, or a lowercase "can retry using ...".
Ok, change to "MAY".
>>The proposed method supports incremental deployment.
>
> In its current shape, this document does not r
> that there isn’t such a mechanism at the
> application layer. Additionally, we are working on a mechanism at the UDP
> layer (UDP options) that may be useful in
> the future (not to recommend now, of course).
I will consider removing Appenxding C. (and aosl D).
--
Kazunori Fujiwara, JPRS
> From: Mukund Sivaraman
> Subject: Re: [DNSOP] [Int-area] Please review
> draft-ietf-dnsop-avoid-fragmentation
> Date: Tue, 16 Aug 2022 10:58:04 +0530
> On Tue, Aug 16, 2022 at 01:07:34PM +0900, Kazunori Fujiwara wrote:
>> Thanks very much for your review.
>>
>&
abstract.
>> Currently, DNS is known to be the largest
>>user of IP fragmentation.
And I will remove this line.
because the text is only present in the abstract.
> Compared to what? I would just drop this sentence because it doesn’t
> add anything to the document and it’s tr
ast 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 lis
ntions glue, it might be
better to remove the appendix or refer to glue-is-not-optional draft.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e.
Address records attached with "SVCB/HTTPS" RR are considered the same
as "MX" RRs.
Section 4.1 of RFC1035:
the additional records section contains RRs which relate to the
query, but are not strictly answers for the question.
Then, it is not glue.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
g SVCB/HTTPS target A/
# to the additional section.
In 2017, 2018, QDCOUNT>1 or multiple qtypes were discussed in dnsop WG.
At the time, I proposed draft-fujiwara-dnsop-additional-answers-01
and compared 5 proposals.
At the time, all proposals avoided QDCOUNT>1.
--
Kazunori Fujiwara
rl2=draft-ietf-dnsop-avoid-fragmentation-14
--
Kazunori Fujiwara, JPRS
> From: Vladimír Čunát via Datatracker
> Reviewer: Vladimír Čunát
> Review result: Ready
>
> (assigned review) I re-read the whole text, and noticed nothing that I'd
> consider wrong or missing. (I didn't
Mukund-san,
Thanks very much.
I updated my local version.
http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html
--
Kazunori Fujiwara, JPRS
> From: Mukund Sivaraman
> Fujiwara-san, Vixie-san,
>
> On Thu, Jan 19, 2023 at 12:13:02AM -0800, internet-dra...@ietf.org wrote:
Thanks very much.
I updated my local version.
http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html
--
Kazunori Fujiwara, JPRS
> From: Peter van Dijk
> PowerDNS Authoritative Server, PowerDNS Recursor, PowerDNS dnsdist:
>
> * IP_PMTUDISC_OMIT with fallback to IP_P
t; delegation.
Then, other delegations are "inperfect"/"incomplete" delegation.
"lame" may have the discriminatory meaning.
Then, how about we stop using "lame delegation" and use terms like
"imperfect delegation" or "incomplete delegation
prposed draft-fujiwara-dnsop-resolver-update and
draft-fujiwara-dnsop-delegation-information-signer.
(They are too old and need to be updated.)
Or, I would like to read complete version of draft-dnsop-deleg
that have alpn and tlsa parameters.
Regards,
--
Kazunori Fujiwara, JPRS
I made a mistake in my previous mail.
> From: Kazunori Fujiwara
> Sorry for too late reply.
> Authors submitted -17 today.
>
>> From: Martin Duke via Datatracker
>> Date: Tue, 02 Jan 2024 11:44:09 -0800
>
>> Martin Duke has entered the following ballot posit
e of SHOULD.
Changed as
"R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF)
bit" [RFC0791] on IPv4.
> (2) Section 3.1, R1 says that responders SHOULD omit the fragment header.
> Under
> what circumstances would it be reasonable to keep it?
Change
OULD observe [RFC8961] in
setting their timeout.
"MAY" was changed as "SHOULD".
However, all recent implementations do some retries.
The details are left to the implementations.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ble by
delegations using one or more in-domain name server names.
I'm not able to write well, I'm looking for good text.
Let's improve the current DNS before DELEG RR.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
like good texts.
As Shumon pointed that many DNS providers offer in-domain name server names,
however, there are many "unrelated" name server names in use.
I know that many DNS hosting providers use in-domain name servers
in their infrastructure. (For example, Amazon/AWS, Cloudflare, ...)
--
olution error or no validation.
Rather than writing a draft for each limitation,
I think it would be better to compile them all into one draft.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
to decide
whether to use "Additional information",
but I don't like to blindly trust data
that has been successfully validated.
I believe many recursive resolver implementations have already
discarded unnecessary responses.
Stub resolvers: accept all responses from the recursive resolver.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
27 matches
Mail list logo
