On 07. 05. 24 2:54, C. M. Heard wrote:
On Mon, May 6, 2024 at 6:59 AM Petr Špaček wrote:
Warren asked implementers to provide feedback on the current text, so
I'm doing just that.
[ ... ]
3.1. Recommendations for UDP responders
R1. UDP responders SHOULD NOT use IPv6 fragmentation
lternative transport protocols eventually.
(Heh, and now someone need to rewrite this into a proper English.)
Hope it helps.
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
:00 UTC-5
Co-located with - related industry events, will be confirmed later
Deadline for Submissions - 2024-06-23 23:59 UTC
For further details please see
https://indico.dns-oarc.net/event/51/abstracts/
Petr Špaček, for the DNS-OARC Programme Committee
going to extract useful meaning from the document. If we accept that
to be a reasonable goal then perhaps having a title that seems slightly
intriguing is better than a title that is 100% spoiler.
IMHO intriguing != incorrect.
--
Petr Špaček
___
D
On 16. 02. 24 15:51, Shumon Huque wrote:
On Thu, Feb 15, 2024 at 4:37 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 14. 02. 24 16:45, Shumon Huque wrote:
>
> What colliding keytag limits are other resolver implementers placing?
Right now BIND tolerat
r RFC 5155?
Feel free to propose your own variables to be used, and don't forget to
include back-of-envelope example to support your proposal (using say 6
500 000 SHA1 operations per CPU/second as a base).
--
Petr Špaček
Internet Systems Consortium
___
on't forget ot
include back-of-envelope example to support your proposal (using say
2000 validations per CPU/second as a base).
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
think you describe it accurately, but people who implement resolvers
in this thread (me, Ralf, Brian W.) apparently disagree where the pain
should land - should resolvers suffer from more complex code & work, or
should signers suffer if they do something very unusual?
--
Petr Špaček
In
On 14. 02. 24 15:49, Shumon Huque wrote:
On Wed, Feb 14, 2024 at 8:54 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 14. 02. 24 14:37, Joe Abley wrote:
> Op 14 feb 2024 om 13:46 heeft Edward Lewis
mailto:edward.le...@icann.org>> het
volgende geschreven:
On 14. 02. 24 16:45, Shumon Huque wrote:
On Wed, Feb 14, 2024 at 7:46 AM Edward Lewis <mailto:edward.le...@icann.org>> wrote:
On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček"
mailto:dnsop-boun...@ietf.org> on behalf of
pspa...@isc.org <mailt
On 14. 02. 24 14:37, Joe Abley wrote:
Op 14 feb 2024 om 13:46 heeft Edward Lewis het
volgende geschreven:
On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček" wrote:
In my mind this is good enough reason to outlaw keytag collisions -
without them it would be _mu
dangerous it can be when resolver has to
implement try-and-see approach.
In my mind this is good enough reason to outlaw keytag collisions -
without them it would be _much_ easier to implement reasonable limits
without risk of breaking legitimate clients.
--
Petr Špaček
Internet Systems
Dear WG,
this is a reminder that the virtual meeting is about to start in 3 minutes!
The agenda URL will guide you to document with links for Meetecho etc.
Petr Špaček
On 24. 01. 24 21:54, Benno Overeinder wrote:
Dear WG,
We have published an updated agenda for the interim, see
https
ing to make it *perfect* is "MUST use QDCOUNT=1", or
in other words, banning QDCOUNT=0 usage with DNS COOKIES. It's
unnecessary complexity.
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mai
unsolicited RRs in the AUTHORITY section.
See
https://chat.dns-oarc.net/community/pl/iyw9znj4wbgdfbbwwz1jjezt6o
and the discussion following it.
In case you don't have DNS-OARC chat login yet see
https://www.dns-oarc.net/oarc/services/chat
HTH.
--
Petr Špaček
Internet Systems Consortium
est Current
Practice. The added note in the Security Considerations about DF makes
sense to me - we will have to see if anybody is willing to do the DF
experiment for real, of course.
I agree.
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing
.zoom.us/rec/share/PUZu_QsO_rdY0gavMatzFOSVpZY1oNahNYnPBuy6pgTUJARw-YIOEzWEV11aqaHW.4Cwr3dGRlunUwhD9?startTime=1693897245000
It's unlikely we will produce running code, but hopefully we'll generate
some good ideas and possibly proto-I-Ds.
--
Petr Špaček
Internet Systems Consortium
___
DNSOP
the point I add that
> D.1. BIND 9
> BIND 9 does implement recommendation 2 of Section 3.2.
... does not seem to be correct. None of the values is used, and none of
the MAY methods is employed by BIND (in current versions).
--
Petr Špaček
Internet Sy
[RFC6891] to
elicit the Extended DNS Error option in the DNS response.
I agree. Sending empty EDE in requests seems superfluous to me.
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
thing", see e.g. code 25 here.
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.)
If you can make somehow amplify this advice I might end up owing you
lots and lots of beverages :-)
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 14. 09. 22 16:56, Kazunori Fujiwara wrote:
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.
* UDP requestors
t
that it is enough. Or maybe not, but the presentation formats could be a
corner stone, and are useful by itself.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
measurements to back up
data in this draft. I can't see them at the moment.
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is pretty complex, and so far the sky did not
fall despite resolvers not implementing it.
Based on this observation I think it should not be mandatory, and also
that parent-centric DNS resolver implementations should not be
"outlawed" by this (to-be) RFC.
--
Petr Špaček
Intern
efine missing presentation forma(s) for all known EDNS options [11]
(it's not that many) and then require new RFCs to specify it.
Besides JSON format it would also help with other text representations,
e.g. in test systems which need to describe queries and answers in some
human-reada
ion (responder's behavior which the
I-D describes, in my understanding) relies on requester's timeout /
retransmission strategy and when PMTU cache information expires same
timeout event would occurs again.
This is completely unreliable, I'm afraid.
--
Petr Špaček
__
ats.nic.cz/dashboard/en/DNSSEC.html
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 28. 07. 22 22:05, Edward Lewis wrote:
On 7/26/22, 3:05 PM, "DNSOP on behalf of Petr Špaček" wrote:
Interesting history lesson, thank you.
Can you elaborate on
> therefore only one can be signed.
please?
What is the reasoning behind it?
There were a f
hacks
Well, if you are ready to push more parent-side RRs count me in!
Petr Špaček
Best regards,
-- Yorgos
On 13/07/2022 13:26, libor.peltan wrote:
Hi Willem, Yorgos, Roy, dnsop,
I dare to repeat my support for the ideas in dry-run-dnssec draft.
However, I still don't like the suggested
ment is almost
no-op after https://dnsflagday.net/2020/ .
The default EDNS buffer size have been changed to, sometimes, even lower
values so the fragmentation should not happen anymore.
6.1. Protocol compliance
+1 (or all votes I can possibly hands on!)
--
Petr Špaček
and configuration, or depending on operational conditions.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 26. 07. 22 20:59, Paul Vixie wrote:
Petr Špaček wrote on 2022-07-26 06:21:
On 28. 06. 22 16:20, Bob Harold wrote:
> But the parent NS set is not covered by DNSSEC, and thus could be
spoofed??
> (Wish we could fix that!)
I share your wish.
Does anyone else want to contribute?
S when this was designed and I think it would be good to
understand the motivation before we start proposing crazy things.
Thank you for your time.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ason I believe Wes's proposal is a good one, albeit very generic.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 07. 04. 22 20:31, Hugo Salgado wrote:
On 17:30 07/04, Petr Špaček wrote:
On 07. 04. 22 15:47, Paul Vixie wrote:
Petr Špaček wrote on 2022-04-06 23:54:
Hello,
...
From my perspective, these systems are not rare, quite the contrary:
- PowerDNS with a database backend
- Multi-master
On 07. 04. 22 15:47, Paul Vixie wrote:
Petr Špaček wrote on 2022-04-06 23:54:
Hello,
...
From my perspective, these systems are not rare, quite the contrary:
- PowerDNS with a database backend
- Multi-master flavors of BIND
- Various "cloud" auths with dynamic backends
- W
pe field to distinguish
"traditional" SERIAL vs. backend-specific blob, but I think it is not
really needed.
To me this is very simple addition which increases value of the proposed
protocol.
Opinions?
Petr Špaček
On 06. 04. 22 16:26, Hugo Salgado wrote:
Dear DNSOP.
The authors have jus
it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.
Please also indicate if you are willing to contribute text, review, etc.
This call for adoption ends: 8 April 2022
I think this draft is suitable for adoption. I'm willing to contribute
reviews.
--
Petr
not get any special
treatment would be good enough.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
or registries.
how about adding:
However missing data might make it impossible for a name server to answer with
the correct (referral) glue data.
And maybe add some encouragement or referral ;-) to work that has to be done
elsewhere.
Sounds reasonable to me.
--
Petr Špaček
.
BIND currently does not support the optional "group" property a Knot DNS
and NSD do not support he optional "coo" property, so we did not really
test these.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
bad or frivolous SrvParamValues "registrations".
An Expert Review seems right to me. It's culturally compatible with how we
handle the allocation of new RRtypes.
+1 for Expert Review for reasons stated by Jim. I don't see #3 as really
needed.
--
P
On 07. 03. 22 17:51, internet-dra...@ietf.org wrote:
Filename: draft-ietf-dnsop-nsec3-guidance-06.txt
I have no nits to report.
Such thing have not happened to me for a long time - well done!
--
Petr Špaček
___
DNSOP mailing list
On 28. 02. 22 18:11, Viktor Dukhovni wrote:
On Mon, Feb 28, 2022 at 03:43:59PM +0100, Petr Špaček wrote:
Keep this:
>>> 3.2. Recommendation for validating resolvers
>>> Note that a validating resolver MUST still validate the signature
>>> over
On 26. 02. 22 0:40, Wes Hardaker wrote:
Petr Špaček writes:
First, I perceive a "problem" with the current document structure:
2. Recommendation for zone publishers . . . . . . . . . . . . . 3
2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3
2
point in validating
the RRSIG, I think.
Additionally I've submitted PR#6 with purely editorial nits.
Thank you for your persistence!
--
Petr Špaček @ Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hello everyone,
it seems that we now have two drafts about the same topic - this new one
and draft-moura-dnsop-negative-cache-loop.
Perhaps authors could discuss if they are in agreement and could pick one?
Petr Špaček @ Internet Systems Consortium
On 14. 01. 22 19:14, Wessels, Duane
t as you can see for
yourself someone needs to translate my texts to proper English so I
should not be a document editor.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
great.
It is already implemented in DNSViz since December 2020 (so a year+
before the Slack outage), but it is not shown by default:
https://github.com/dnsviz/dnsviz/issues/76#issuecomment-985331543
--
Petr Špaček
___
DNSOP mailing list
DNSOP
On 27. 11. 21 7:12, Viktor Dukhovni wrote:
On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote:
Also, when we are theorizing, we can also consider that resalting
thwarts simple correlation: After a resalt attacker cannot tell if a set
of names has changed or not. With a constant salt
On 26. 11. 21 11:49, Vladimír Čunát wrote:
On 25/11/2021 13.00, Petr Špaček wrote:
IMHO in the context of NSEC3 the salt would make sense _only_ if it
were rotated faster than attacker was able to walk the zone. Once
attacker has list of hashes available for offline cracking the salt
does
On 26. 11. 21 9:43, Matthijs Mekking wrote:
On 25-11-2021 13:00, Petr Špaček wrote:
On 25. 11. 21 9:33, Matthijs Mekking wrote:
3.2. Recommendation for validating resolvers
I understand why the new text is here, but I think this now actually
gives too little advice for operators
I'm tempted to put the last paragraph first, because all the rest is
justification and I don't want to drown the important piece of
information in it.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ows to use the same trick on per-EDE code basis:
$ORIGIN _er.agent.test.
* TXT "tell me!"
16 TXT "silence" ; 16 = EDE Censored
The question is: Which variant is better?
I don't remember from our previous discussions if the current ordering
in draft was a conscious choice or not, sorry if
motivational
and normative text from draft-reddy-dnsop-error-page. New version at:
https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-01
On 10. 11. 21 17:17, Petr Špaček wrote:
Let's start from the hardest questions:
1. Input from br
will find that useful)
but we should focus on reporting to the zone manager, not to the
client.
Seems like you are talking about a different document? Or are you
suggesting the document to be dropped entirely because it goes in a
completely wrong direction?
--
Petr Špaček
, but someone needs to write a sensible description - which I'm
not capable of.
Have a great day.
Petr Špaček
Thanks,
Manu
There was a request to put the markdown version of the document in
GitHub. This has now been placed here:
https://github.com/RoyArends/draft-ietf-dnsop-d
that in one go
in this document. We have enough RFCs already and wasting more numbers
(and work) on simple deprecation does not sound useful to me.
Petr Špaček
Happy to offer actual text if that seems useful.
Joe
On 11 Nov 2021, at 11:38, Kim Davies wrote:
Colleagues,
I wanted to draw your
as to match the
encrypted DNS server's name and the expanded URIs from the "c" and
"r" will point at the DNS resolver not under the attacker's control.
What attack scenario is this describing? DNS proxy which accepts
encrypted connections but then blindly forwards via insecu
esolvers", which is always PITA. We should declare TTL=0 illegal :-)
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 09. 11. 21 18:57, Viktor Dukhovni wrote
On 9 Nov 2021, at 4:11 am, Petr Špaček wrote:
I don't see need to specify _a_ value here. I think better approach is
acknowledge current state of things. What about something like this?
---
As for November 2021, the limit of 150 iterations
nd avoid
term "negative" caching. In my eyes it is a bit misleading because
"negative" is typically used for different kinds of answers.
I hope this early feedback helps a bit.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 08. 11. 21 14:41, Wes Hardaker wrote:
Petr Špaček writes:
Thanks for the detail notes Petr, very helpful.
From my point of view the RFC does not need to stick to the value
currently implemented in resolvers.
Good point, and maybe the right phrasing I should have used should have
been
8 315| 8 270 | 8 320 |
112 | 1 % | 38 % |
Now I can only hope the tables survive transit.
--
Petr Špaček @ ISC
measure.sh
Description: application/shellscript
___
DNSOP mailing list
DN
off by default, you at least need commitment from
some significant operators - say, I'm not even sure if Quad9 by
themselves would suffice to bootstrap this.
I agree. Mandating "disabled by default" configuration on _resolvers_
sounds like a way to get
entname.nic.cz A
> 3. Wildcard Answer
surelynonexistentname.pages.nic.cz A
> 4. Wildcard No Data.
surelynonexistentname.pages.nic.cz WKS
I hope it helps.
--
Petr Špaček @ ISC
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ds of DoT clients on one resolver (when configured
appropriately, and yes, I did test this claim.)
Maybe this could use a clarification that 150 is good advice only if you
_don't_ have any "TCP-only" clients, like e.g. DoT stubs?
Petr Špaček
For the limit on connections per sourc
On 14. 07. 21 5:13, Brian Dickson wrote:
On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni <mailto:ietf-d...@dukhovni.org>> wrote:
> On 13 Jul 2021, at 6:22 am, Petr Špaček mailto:pspa...@isc.org>> wrote:
>
> As Viktor pointed out in
https://maila
On 13. 07. 21 0:13, Brian Dickson wrote:
On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 08. 07. 21 18:15, Brian Dickson wrote:
>
>
> On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček mailto:pspa...@isc.org>
>
DAP server lookups,
email delivery, ...
Please note I do not object to the method by itself - I agree it might
be useful. My disagreement is limited to using stronger requirement than
MAY. Let vendors have some leeway, please.
Petr Špaček
Of course if the WG cannot come to consensus
middleboxes that might (hopefully!) be fixed in the
future seems like a very wrong direction for the WG.
Oh, thank you for summarizing my thoughts into concise yet easier to
understand message!
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https
On 08. 07. 21 18:00, Viktor Dukhovni wrote:
On 8 Jul 2021, at 10:28 am, Petr Špaček wrote:
With my implementer hat on, I say "no", I don't see a compelling reason to
"mandate" it. Keep it at MAY/optional level and leave it to implementers to decide what's
best for
On 08. 07. 21 18:15, Brian Dickson wrote:
On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 07. 07. 21 19:54, Warren Kumari wrote:
> Hi there all,
>
> I wanted to check the consensus on a point brought up during IETF
On 07. 07. 21 19:54, Warren Kumari wrote:
Hi there all,
I wanted to check the consensus on a point brought up during IETF LC /
OpsDir review of draft-ietf-dnsop-rfc7816bis.
Please see:
https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/
and
ould be gradually getting
rid of the dependency on SOA serial, not increasing it.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
but such filtering is "local policy" and nothing we write into the RFC
can change local policy anyway. For that reason I would not go to great
lengths to explain what to do with unrecognized URLs etc.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@
ursive resolvers
+ to alter their behavior based on its contents, even if the contents are
+ invalid.
This addresses my concern, thank you!
Petr Špaček
On Thu, Apr 8, 2021 at 3:55 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 18. 03. 21 21:53, Tim Wicinski wrote:
>
deems necessary.
Let me be clear:
It would not be very reasonable to believe that HTTPS RR will be in
practice allowed to work as a loophole to A/ filtering on resolvers,
so the question is if WG prefers to have it mentioned in the RFC text or
not.
--
Petr Špaček
__
ich are
unnecesary vast majority of the time.
Are we (as dnsop WG) not concerned with packet bloat anymore?
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e" zone
has 1024 bit RSA + a fancy ECC alg with the new bit set, it still means
nothing security-wise. Attacker can get better return on investment by
attacking the parent zone.
I think it needs discussion if it is worth approaching this problem with
single-zone gra
to see all the details and interactions.
Petr Špaček @ CZ.NIC
On 29. 07. 20 21:54, Ben Schwartz wrote:
> I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to
> make sure that the draft isn't overstating the achievable benefits. To that
> end, I have some quest
as verb and also as name of the key. "optional
mandatory" sounds like a joke.
To clarify this I propose to rename "mandatory" field to "critical", which
terminologically aligns with X.509 and also LDAP.
--
Petr Špaček @ CZ.NIC
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 16. 06. 20 13:00, Petr Špaček wrote:
> On 12. 06. 20 17:12, Tim Wicinski wrote:
>>
>> All,
>>
>> As we stated in the meeting and in our chairs actions, we're going to run
>> regular calls for adoptions over the next few months. We are looking for
&
ing people _who insist on private TLD
anyway_ one of 40-something strings instead of "pick your
not-really-random-TLD" can lead to decrassing traffic to root and easier
monitoring in practice as caching should work better (either with quer
) What should happen if multiple options are present? Answer with FORMERR?
(But see questions c,d above.)
Thank you for opinions!
P.S. Sorry for opening this topic again, but this seems like another example of
RFC which would benefit from more implementation experience prior publication.
--
Pe
ould be afraid to send in Classic DNS anyway (due to the ossification
> issues), eg HTTPSVC, I suppose there's more value of just adding in the
> additional qtype and using the response opportunistically when received.
I agree - making it mandatory seems like reasonable approch (wi
rchitecture to make it more clear that we
> can imagine different optimisations being applied to different parts of it.
I very much agree, we need to clean up this historical mess!
Clear split between stub/forwarding/recursive would help a lot.
--
Petr Špaček @ CZ.NIC
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 25. 05. 20 5:23, Shumon Huque wrote:
> On Thu, May 21, 2020 at 8:24 AM Petr Špaček <mailto:petr.spa...@nic.cz>> wrote:
>
> >
> > https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
>
> I would appreciate a practi
On 28. 05. 20 10:00, Shane Kerr wrote:
> Ray and other DNS operations folks,
>
> On 27/05/2020 10.30, Ray Bellis wrote:
>>
>>
>> On 27/05/2020 07:33, Petr Špaček wrote:
>>
>>> I would much rather spent time on
>>> https://tools.ietf.org/html/dra
nobody asked for (thus wasting resources on
unnecessary work).
I feel that nowadays web browsers have better communication with OS
vendors/stub resolvers (Android and Chrome come to mind). Can we stub resolvers
on board, pretty please?
--
Petr Špaček @ CZ.NIC
On 26. 05. 20 18:00, Roy Arends wrote:
>
>> On 26 May 2020, at 16:06, Petr Špaček wrote:
>>
>> On 02. 05. 20 16:09, Roy Arends wrote:
>>> Hi,
>>>
>>> Ed and I just submitted a new version of our private-use TLD draft.
>>>
>&g
be used as _option of last resort_", or more
verbose "these special TLDs should be used only when other options, e.g.
private subtree under a properly delegated name, were considered and refused."
Thank you.
--
Petr Špaček @ CZ.NIC
_
ing two problems (GHOST domains and NS inconsistency) in
single proposal does not help me to understand reasoning behind the proposal
and its intended effects.
Take care.
--
Petr Špaček @ CZ.NIC
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e not preventing
vendors from implementing practical proposals.
RFCs 7901 (CHAIN extension) and 8094 (DTLS) should serve us as warnings.
Petr Špaček @ CZ.NIC
On 20. 04. 20 20:03, Tim Wicinski wrote:
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're goin
d a note as well about the scope of the document, though I
> think it can be derived from the above sentence:
>
> EDE content is not attempting to address the lack security in DNS
> error messages.
I think both additions would be good and personally I think it is important
enough to warrant some redundancy in the text.
--
Petr Špaček @ CZ.NIC
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, but at the
moment I do not have enough information to be sure.
Petr Špaček @ CZ.NIC
On 14. 04. 20 18:07, Ben Schwartz wrote:
> If I understand correctly, the Powerbind draft is designed to reduce the
> amount of data that must be logged in order to verify appropriate use of a
> DNSKEY "K&quo
the opposite opinion:
DP bit is not *needed* for EDE.
If I'm proven wrong in future we can specify DP bit in a separate document and
update EDE RFC.
(Also I've changed my mind when it comes to TC bit - now I believe that normal
DNS processing is fine and EDE does not need a special case.)
--
Pet
On 19. 11. 19 11:52, Ted Lemon wrote:
> On Nov 19, 2019, at 5:50 AM, Petr Špaček wrote:
>> Please keep RR type name as one lexical unit!
>>
>> Constructing the name from multiple tokens ("SVCB" "-" "HTTPS") will trigger
>> all so
nstructing the name from multiple tokens ("SVCB" "-" "HTTPS") will trigger
all sorts of bugs all over the place. For example the venerable dnspython.org
library would require rework before it would be able to support the new type
named "SVCB
1 - 100 of 228 matches
Mail list logo
