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
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
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, ...)
--
mendations on "unrelated" name server names.
I submitted "draft-fujiwara-dnsop-unrelated-name-server-00" as a first step.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-unrelated-name-server/
I prposed that
the domain names that host the name server names MUST be resolva
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
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
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
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
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
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
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
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
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
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
> 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
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
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
> 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.
>>
>&
> 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
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
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
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:
-dnsop-glue-is-not-optional. Please add them as references.
I proposed similar idea "Delegation Information (Referrals) Signer for
DNSSEC" at IETF 109 dnsop WG and it was not preferred at the time.
See:
https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-sig
eve path MTU value to a destination from
applications
Appendix D. How to retrieve minimal MTU value to a destination
Appendix E. Minimal-responses
5. Added some names in Acknowledgeent section
--
Kazunori Fujiwara, JPRS
___
D
limit default DNS/UDP payload size
1232 or other smaller value.
When full-service resolvers support this draft,
changing stub resolvers are not necessary, I think.
--
Kazunori Fujiwara, JPRS
> From: Brian Dickson
> In my comments regarding section 3.3 of the
> draft-ietf-dnsop-avoid-fragment
Thanks very much.
I will refer to your suggestions and try to shorten the introduction
section.
--
Kazunori Fujiwara, JPRS
> From: Brian Dickson
> Fujiwara-san,
>
> I have a suggestion on tweaking the wording of Section 1, Introduction.
> The intent is to simplify it a
nus
UDP header size (8).
Details of default maximum DNS/UDP payload size is Appendix C.
-----
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
payload size for IPv4 is .
(Choose 1232, 1400, 1452 or other good values before/at WGLC)
Regards,
--
Kazunori Fujiwara, JPRS
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operat
gt;> And the idea may offer the signature for root priming data.
>
> It can’t. There is no requirement for addresses records for nameservers
> for a zone to exist in the zone, as glue or not, even if the nameservers
> are below top of zone. Glue is only
ailiwick", "in-domain", "sibling".
Please propose new names.
# And I missed a term related to domain name: Occluded Name [(RFC6936].
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
both "child.example.net NS a.sub.child.example.net"
and glue "a.sub.child.example.net A 1.2.3.4",
and validate child.example.net DiS RR.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
validate "child.example.net NS a.sub.example.net".
Validating resolver can accept the sibling glue "a.sub.example.net A 1.2.3.4".
Or,
validating resolver may reject the sibling glue "a.sub.example.net A 1.2.3.4",
and treat it similar to out-of-bailing domain name,
the
2001:dc8::53
example.com.IN DS 12345 8 2 (hash of DNSKEY RR)
example.com.IN DS 0 0 100 (hash of (example.com IN NS | ns.example.com
IN ))
example.com.IN RRSIG DS (signature of DS RRSet (2 DSes))
DNSSEC signer may generate DiS RR and signature of DS RRSet (including DiS RR).
--
I submitted draft-fujiwara-dnsop-delegation-information-signer-00.
Name: draft-fujiwara-dnsop-delegation-information-signer
Revision: 00
Title: Delegation Information (Referrals) Signer for DNSSEC
Document date: 2020-11-03
Group: Individual Submission
Pages
(with path MTU discovery),
they need to calculate EDNS0 size from path MTU size.
However, many people wants static recommendaton value for EDNS0 size.
I'm wondering if it's better to write a recommended MTU value or a
recommended EDNS0 size.
--
Kazunori Fujiwara, JPRS
> From: internet-
gt; * should listen for ICMP frag needed packets, and react by re-sending the
> response (which is embedded in the ICMP packet) with a TC bit set
It is a part of path MTU discovery.
> Network:
>
> * should send rate-limited ICMP frag needed messages to DNS servers when
> appropriate
I
d and in IPv6 1184 bytes. This
> is enough context to build another response, without having to wait
> for any timeout.
In my opinion, the captured PTB data is similar to IP_MTU/IPV6_MTU
socket options.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
DNSOP WG,
Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-00.
Please review it.
> https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-00
I may have some mistakes, I could not find links to show differences
from draft-fujiwara-dnsop-avoid-fragmentation-03.
Please
n
additional section. Then, adding new text that "authoritative servers
MAY add A/ RRs related to HTTPSSVC RR in additional section".
Recent resolvers reject/accept additional section data.
(If they have RRSIGs, then they may be accepted).
--
Kazunori Fujiwara, JPRS
_
Hello,
Paul Vixie and I submitted draft-fujiwara-dnsop-avoid-fragmentation-03.txt
Please review it.
Changes from 01 to 03 are:
- Changed title as Fragmentation Avoidance in DNS
- Refer draft-ietf-intarea-frag-fragile
- Fixed: Minimum MTU forIPv4 is 68 (from 576)
- Added: DNS flag day 2020
Dear dnsop WG,
Please review draft-fujiwara-dnsop-avoid-fragmentation-01.
https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-01
Main differences are:
- New Co-author
- Refer RFC 8085 UDP Usage Guidelines
- SHOULD send DNS responses with IP_DONTFRAG / IPV6_DONTFRAG [RFC3542
Dear DNSOP,
I submitted draft-fujiwara-dnsop-avoid-fragmentation-00.
https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00
It proposes avoid IP fragmentation operation in DNS.
I removed details of attack to path MTU discovery and cache poisoning
attacks using IP
e servers ?
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> From: 神明達哉
>>https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01
>>
>> It summarized DNS cache poisoning attack using IP fragmentation
>> and countermeasures.
>>
>> If the draft is interested, I will request timeslot at IETF 104.
Dear DNSOP,
I submitted draft-fujiwara-dnsop-fragment-attack-01.
https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01
It summarized DNS cache poisoning attack using IP fragmentation
and countermeasures.
If the draft is interested, I will request timeslot at IETF 104.
I think
r root and TLD servers they know have
> installed the
> the well known key. This is easy to test with tools like dig.
Do you mean TSIG protects from second fragmentation attacks ?
Regards,
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
machines, I would like to drop fragmented response packets.
We can write IP filter that drop fragmented packet to resolvers,
but it is not beautiful.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
e can plan.
Regards,
--
Kazunori Fujiwara, JPRS
> From: fujiw...@jprs.co.jp
> WGLC comment to draft-ietf-dnsop-algorithm-update-02
>
> Section 3.2 is "recommendations for operators".
>
> There is texts that discuss ECDSAP256SHA256 only in section 3.2.
> However, RSASH
| MUST NOT
RSASHA256 usable | usable/consider change to EC*/Ed*
ECDSAP256* usable | usable
Ed25519 MAY | usable
Regards,
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSO
d into two type of name server names:
"in-domain" names and "sibling domain" names.
In-domain:
sibling domain:
examples
-
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
/session/11/contribution/46/material/slides/0.pdf
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
| ns.example.com | out-of-bailiwick
example.jp | jp | ns.example.jp | in-bailiwick / in-domain
example.jp | jp | ns.example.ne.jp | in-bailiwick / sibling domain
example.jp | jp | ns.example.com | out-of-bailiwick
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
> Fro
... bad english text ... please fix.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
> From: Mark Andrews <ma...@isc.org>
> The text for "in-bailwick" is too restrictive, it doesn’t just cover NS
> records or
> glue records.
>
> In-bailwick refers to records t
NAMEXs can control traffic ratio among several CDN
> providers;
You can add many SRV RRs. (merge SRV RRs from multi-CDN).
> (2) RFC2782 requires browser's support;
> Using this method, a browser has no idea about weighted AX/Xs.
> It requires no change of browsers.
Hello,
I submitted another multiple response proposal.
https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00
It is similar to draft-wkumari-dnsop-multiple-responses, however, it
proposes authoritative DNS server software developers choose
additional resource records.
# Many
ause the
qname is only one.
draft-wkumari-dnsop-multiple-responses does not have the problem
because the main query is one.
We would like to compare all idea before proceeding.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
will update the parts.
> Line 407 is would be great to indicate since which version of Unbound
> support has been in place.
It is my edit mistake. Unbound does not implement "Aggressive use of
DNSSEC-validated Cache" now.
See: https://mailarchive.ietf.org/arch/msg/dnsop/Iv1mxko
Thanks very much for submitting IPR infomation.
The idea is not new and I heard that Nominum and some software implemented.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
> From: Andreas Gustafsson <g...@araneus.fi>
> fujiw...@jprs.co.jp wrote:
>> I also receive
Ondrej.Sury-san,
> From: Ondřej Surý <ondrej.s...@nic.cz>
> Fujiwara-san,
>
> I was strongly opposed to the idea after your DNS-OARC presentation
> and I am glad you are continuing the effort :).
>
> I had some private conversation with Ralf Weber from Nominum
> From: Stephane Bortzmeyer <bortzme...@nic.fr>
> fujiw...@jprs.co.jp <fujiw...@jprs.co.jp> wrote
> a message of 61 lines which said:
>
>> I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to
>> improve resolver algorithm.
>
> I see the p
>However, people sets different NS RRSets with mistakes, or
>intentionally.
>
> Specifically what kind of intent does this "intentionally" mean?
I considered "intentionally means "malicious idea".
next version will relfect your excellent comment.
Hello,
I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to
improve resolver algorithm.
Please read it and comment.
I also made a presentation of the same topic
at previous DNS-OARC workshop.
https://indico.dns-oarc.net/event/25/session/6/contribution/19/material/slides/2.pdf
answers may need NSEC RR.
# Non-existent pseudo RDATA may be useful, however, RDLENGTH=0 is not reserved.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_443._tcp.NAME TLSA
>>NAME A + NAME + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ...
>>
>
> Dear Fujiwara-san,
>
> Your points/scenarios fall in the Draft
>
> https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-00.txt
Thanks.
I
section may be possible.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
sive use of NSEC is enabled, the aggressive
> use of cached deduced wildcard will be more effective as the
> aggressive NSEC use helps prove more names wouldn't exist without
> the wildcard through fewer external queries.
Thanks.
I used these texts.
--
Kazunori Fujiwara, JPRS <fu
not find the definition of "source of synthesis".
>
> It's here: https://tools.ietf.org/html/rfc4592#section-3.3.1
Thanks.
I added these key words in terminology section and I will add them to
rfc7719bis.
I rewrote pseudo code easier.
--
Kazunori Fujiwara, JPRS <fujiw...@jpr
t; "send a positive response immediately when the name in question
> matches a NSEC/NSEC3 RRs in the negative cache."? Especially about
> how "a positive response" is derived from negative cache information?
I will update the part to be expressed well.
If nonexistence of a domain
nse without validating them. Luckily the draft already
> highly recommends that it should do validation. I would like to make it
> even stronger and remove the MAY key word here, and perhaps use the
> formal key word SHOULD do validation.
Yes. I agree.
--
Kazunori Fujiwara, JPRS <
security problems.
>
> Specifically what does "without DNSSEC validation" mean? Something
> like a case where a validating resolver receives an NSEC/NSEC3 and
> uses that information without DNSSEC-validating it? If so, it's
> simply invalid per protocol whether th
P uses NSEC3 with OUT-OUT.
hidden) delegations between NSEC3 range.
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> From: Bob Harold <rharo...@umich.edu>
>>> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
> I support adoption. Will read and review.
Thanks.
> Section 7.3 concerns me. If the range is expanded enough to be useful,
> would it then allow zo
> From: Shane Kerr <sh...@time-travellers.org>
>> Last week, Kato and I submitted -03 version of
>> draft-fujiwara-dnsop-nsec-aggressiveuse draft. It improved the
>> structure of the document for readability and made minor corrections
>> but essential idea has
Last week, Kato and I submitted -03 version of
draft-fujiwara-dnsop-nsec-aggressiveuse draft. It improved the
structure of the document for readability and made minor corrections
but essential idea has not been changed.
We are appreciated if you read and commet it.
Regards,
--
Kazunori Fujiwara
ey may be "caching DNS servers".
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
# It may be listed in draft-ietf-dnsop-root-loopback
# as a different approach.
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
From: Bob Harold rharo...@umich.edu
On Tue, Jul 7, 2015 at 5:20 AM, fujiw...@jprs.co.jp wrote:
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
...
--
Kazunori Fujiwara, JPRS fujiw
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
* Added reference to DLV {{RFC5074}} and imported some sentences.
* Added Aggressive Negative Caching Flag idea.
* Added detailed algorithms
Aggressive use of NSEC/NSEC3 resource records may decrease
queries to Root DNS servers. in
draft-fujiwara-dnsop-nsec-aggressiveuse-00 as a side effect.
Is it related to root-loopback document?
# I will update the draft soon.
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse.
If you have interests, please comment.
Subject: New Version Notification for
draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt
From: internet-dra...@ietf.org
Date: Mon, 09 Mar 2015 10:20:47 -0700
A new version of I-D, draft
will be used if the
negative DS answer is cached.
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
domain will see increased DS traffic for unsigned child domains
Agree.
I would like to know whether the increase of DS queries are observed
commonly or not. (with small NCACHE TTL value)
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
___
DNSOP mailing list
Dear Chairs and WG participants,
I updated draft-fujiwara-dnsop-ds-query-increase this Janurary.
http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase
Recent DS traffic increase seems not high, I did not request time slot
of WG meeting. However, Increasing is a fact.
Recent DS
if you can make the newer script available too (the one
using Net::DNS::SEC).
I put the script on my page as is.
http://member.wide.ad.jp/~fujiwara/v6rsec-dnslab.pl
I run it as 2001:200:132:6::/64 reverse mapping DNS server.
It is very limited prototype. It does not have many necessary
are ...
- No good code (writing better code solves this problem.)
- Performance (better code and new hardware solve this problem.)
- Private keys are shared on each authoritative server.
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
___
DNSOP mailing
90 matches
Mail list logo
