Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

at all. But what we need to do is to properly educate users wishing to enable DNSSEC validation. But that doesn't differ from TLD signing and it's more task for TLD registry to speak to it's users. Ondrej. -- Ondřej Surý technický ředitel/Chief Technical Officer

Re: [DNSOP] I think we may have a solution - DNSCurve

uz51gmc1jjicekrm676rorncvjpale915vhd94bj2fddj1be1ntbg5.root-servers.net make things more simpler. Ondrej. -- Ondřej Surý technický ředitel/Chief Technical Officer - CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:[EMAIL PROTECTED

Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt

why the burden of open resolvers should be put on shoulders of attacked DNS operators. If the answer to both of these questions is no, the document can go forward as is. Ondrej. -- Ondřej Surý technický ředitel/Chief Technical Officer - CZ.NIC, z.s.p.o

[DNSOP] MX 0 . standard way of saying we don't do email ?

Hi, I have just encountered strange thing: security.eu.debian.org mail is handled by 0 . I am not sure if pointing MX record to other peoples zone is good idea. And the root zone has it's own deal of DoS attack even without random MXes pointing into it. MX 0 . is the standard way of

Re: [DNSOP] MX 0 . standard way of saying we don't do email ?

Since it looks like it is already in use (at least in some MTAs) I am willing to help to standardize this. However I lack an experience what to do if there is no smtp working group. Should I send it to apps area ml, or to chairs of apps area? It seems to be overkill to start whole wg just to

Re: [DNSOP] RFC4641bis Editing Status Report.

intervals that is an issue that is probably closely related to http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology which I will address in the next version. -- Ondřej Surý vedoucí výzkumu/Head of RD department --- CZ.NIC, z.s.p.o

Re: [DNSOP] [dnsext] Re: t...@dnssec bar BoF

have tips please mail me privately. So, where will this be a few hours? That's still TBD. Latest conclusion is to meet at registration desk and if we don't have the room at that time, we will find a place. I've changed the BarBOF wiki to include this information. Ondrej -- Ondřej Surý

Re: [DNSOP] Cert Enumeration and Key Assurance With DNSSEC

with the domain name that was used in the DNS query. For additional information, please contact the list administrators. -- Ondřej Surý vedoucí výzkumu/Head of RD department --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC

Re: [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

You are working on wrong assumptions. The DV certs are exactly as strong as your DNS is. You only need to attack DNS to issue a DV cert. Ondrej Sury On 5.10.2010, at 18:32, Kemp, David P. dpk...@missi.ncsc.mil wrote: You are confusing attack surface with vulnerability. Without getting into

[DNSOP] Knot DNS v1.0.0 released

- there is still place for a lot of optimizations, minor tweaks or new features, so stay tuned for next releases. Thank you again for using Knot DNS! -- Ondřej Surý vedoucí výzkumu/Head of RD department --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC

[DNSOP] DNS-NG (Re: Batch Multiple Query Packet)

. And no it is not meant as replacement for dnsext. The WG should do it's job, produce WG document(s) and close. I am not trying to get mad, y'know :-). O. P.S.: I know I am responding to a month-old email, but better now than never... -- Ondřej Surý vedoucí výzkumu/Head of RD department

Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt

___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Ondřej Surý vedoucí výzkumu/Head of RD department --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC Americka 23, 120 00 Praha 2

Re: [DNSOP] CDS and/or CDNSKEY

for this key to be removed from the parent zone. O. -- Ondřej Surý -- Chief Science Officer --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.s...@nic.czhttp://nic.cz/ tel:+420.222745110 fax

Re: [DNSOP] CDS and/or CDNSKEY

the DNS Update mechanism to send DNS UPDATE to parent master (from SOA) server with DNSKEYs + RRSIGs as contents of the DNS UPDATE message. O. -- Ondřej Surý -- Chief Science Officer --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC Americka 23, 120 00

Re: [DNSOP] CDS and/or CDNSKEY

on CSYNC/CDS/CDNSKEY because of some hypothetical problem with registrars not willing to cooperate with registries. O. -- Ondřej Surý -- Chief Science Officer --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic

Re: [DNSOP] CDS and/or CDNSKEY

(as suggested in my previous email) and the rest can be handled via existing provisioning mechanisms. O. -- Ondřej Surý -- Chief Science Officer --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.s

Re: [DNSOP] CDS and/or CDNSKEY

On 9. 10. 2013, at 15:47, Paul Wouters p...@cypherpunks.ca wrote: On Wed, 9 Oct 2013, Ondřej Surý wrote: We also have a signaling mechanism... We can just somewhat abuse the DNS Update mechanism to send DNS UPDATE to parent master (from SOA) server with DNSKEYs + RRSIGs as contents

Re: [DNSOP] CDS and/or CDNSKEY

of the affected object. Thus it seems to me that this paragraph is not needed. Otherwise lgtm. O. -- Ondřej Surý -- Chief Science Officer --- CZ.NIC, z.s.p.o.--Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.s...@nic.cz

[DNSOP] RFC 6891 Clarification (EDNS=1 and higher behaviour)

as a side effect of every response, including error responses and including RCODE=BADVERS. And in fact we think this might be a more forward compatible behaviour than returning an empty response with RCODE=BADVERS. (Sending it here as dnsext is concluded...) Cheers, -- Ondřej Surý -- Chief

Re: [DNSOP] Comments regarding the NSEC5

solution. Cheers, Ondrej -- Ondřej Surý -- Chief Science Officer CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz

[DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

Dear DNS colleagues, this might be of some interest to you. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz

Re: [DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

should not mix these together, since it will be much harder to agree upon the deprecated algorithm list. Cheers, Ondrej -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic

Re: [DNSOP] Fwd: New Version Notification for draft-sury-dnskey-ed25519-03.txt

Hi Viktor, yes, we are waiting exactly for the cfrg to finish the signature schemas. But the rest can get a review early. f.e. it's evident now, we have to add more material about motivation to add new curves into the draft(s). Cheers, Ondrej -- Ondřej Surý -- Technical Fellow

[DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-00.txt

ore that, it would be awesome. Thanks. 1. TL;DR just prepend the prepared data with "DNSSEC SIGNATURE\0" before signing or verifying them. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 P

[DNSOP] Review of draft-ietf-dnsop-no-response-issue-05.txt

nt when slapping and shaming the various networking equipment vendors from tiny (SOHO) to huge (scrubbing, load-balancing, etc.). Nits: a. (nit) Chapter 2, first paragraph; s/known issues know/knows issues now/ b. (nit) Chapter 3.1.5: s/attempts, they should/attempts should/ Che

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

. The consequences of that is that a one more roundtrip would be needed to check the child-side NS. I still don't know how to explain: "You absolutely must fill this in, but it will be never used unless the parent and child resides at the same server." Cheers, Ondrej -- Ondřej Surý --

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

n the paradigm how the domains are resolved. Cheers, Ondrej -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej

Re: [DNSOP] FYI - Added note about ECDSA resolver issue in Sweden - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt

And you can replace "registrars" with "IANA" and your whole paragraph would still be correct. This is another area that hinders deployment of "new" (ehm, ehm) algorithms. Cheers, -- Ondřej Surý -- Technical Fellow ---

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

Bob, - Original Message - > From: "Bob Harold" <rharo...@umich.edu> > To: "fujiwara" <fujiw...@jprs.co.jp> > Cc: "Ondřej Surý" <ondrej.s...@nic.cz>, "dnsop" <dnsop@ietf.org> > Sent: Thursday, 10 November,

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

~~ Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Original Message --

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

- Original Message - > From: "Stephane Bortzmeyer" <bortzme...@nic.fr> > To: "Ondřej Surý" <ondrej.s...@nic.cz> > Cc: "Bob Harold" <rharo...@umich.edu>, "dnsop" <dnsop@ietf.org> > Sent: Tuesday, 15 November, 20

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

- Original Message - > From: "神明達哉" <jin...@wide.ad.jp> > To: "Ondřej Surý" <ondrej.s...@nic.cz> > Cc: "Stephane Bortzmeyer" <bortzme...@nic.fr>, "Bob Harold" > <rharo...@umich.edu>, "dnsop" <

Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

- Original Message - > From: "Edward Lewis" <edward.le...@icann.org> > To: "Ondřej Surý" <ondrej.s...@nic.cz> > Cc: "dnsop" <dnsop@ietf.org> > Sent: Monday, 14 November, 2016 08:31:51 > Subject: Re: [DNSOP] Why 2 caches? d

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

I don't feel very strongly about renaming the draft. I just find a little bit confusing and I imagine I might not be the only one who might feel that way. One way or another I have already reviewed -03 versions of the draft and I think it is ready for publication. Cheers, -- Ondřej Surý

Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt

The IANA Considerations Sections says: This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". And I believe that's the correct language according to https://tools.ietf.org/html/rfc5226#section-5.1 Cheers, Ondrej -- Ondřej Surý -- Techni

Re: [DNSOP] DNSSEC operational issues long term

would be no way how to update neither the firmware nor the trust anchors. And even with the usual 2 year warranty most people would not just bother to return faulty device to the seller, because $20 is not worth it. And that's exactly the reason why those vendors are able to do it. Most people just d

Re: [DNSOP] DNSSEC operational issues long term

hones are supported for 2-3 years and that's only when we are lucky. I strongly believe that you have built an use case to prove something is wrong, but I think it's your use case that's wrong in this case. Cheers, -- Ondřej Surý -- Technical Fellow --

Re: [DNSOP] DNSSEC operational issues long term

ew one; for DNSSEC, that would be the ICANN-CA. Inventing new knobs and workarounds for dusty devices in the DNS protocol won't improve this (much). Cheers, -- Ondřej Surý -- Technical Fellow --

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-03.txt

e ANY" later. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/

Re: [DNSOP] The DNSOP WG has placed draft-wallstrom-dnsop-dns-delegation-requirements in state "Candidate for WG Adoption"

Dear all, I reviewed draft-wallstrom-dnsop-dns-delegation and I think -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz

Re: [DNSOP] DNSSEC operational issues long term

as Informational or let the IANA adopt that as an IANA document. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz

Re: [DNSOP] The DNSOP WG has placed draft-wallstrom-dnsop-dns-delegation-requirements in state "Candidate for WG Adoption"

tion - an language in relevant paragraphs make no distinction. I understand what you are trying to say (legal is about syntax, valid is legal+A or RRSet must exist), others might be confused. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.

Re: [DNSOP] Call for Adoption: draft-dickinson-dnsop-dns-capture-format

+1 for adoption, and I will try to actively review more drafts from now again. Not only this one. O. -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt

f sleep) and I would be happy to review next revision. In case I am silent bug me until I do the review. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej

Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

answer minimization is in effect. And what exactly happens when the NS records expire? It depends - is the resolver prefetching, so it still knows the existing nameservers - possibly pulling the child NS in this TTL round? Or did it expire completely and the resolver has to start from bottom - just

Re: [DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt

;. Cheers, Ondrej -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz/ - Origin

[DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-02.txt

Dear all, a new version of EDDSA for DNSSEC has been posted that resolves most if not all comments received during WGLC in curdle. This is one last chance to review the document, so don't miss it! :) Cheers, -- Ondřej Surý -- Technical Fellow

Re: [DNSOP] [Curdle] Fwd: I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt

It's just a DNS record. It doesn't matter what's inside, so I'll replace the example with something neutral like MX. O. -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

-eddsa.xml TXT: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dnskey-eddsa.txt HTML: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dnskey-eddsa.html O. -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

Simon, thanks for all the comments, I have now culled all the context usage from the draft and the git version should be up to date and ready for -2 upload. Cheers, Ondrej -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře

Re: [DNSOP] [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

And now the examples section contains Ed448 examples as well generated using eddsa2.py from [CFRG-EDDSA] draft. I think now the draft is as good as it gets. Thanks all for providing guidance. O. -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o

[DNSOP] Fwd: [Curdle] I-D Action: draft-ietf-curdle-dnskey-eddsa-01.txt

/doc/draft-irtf-cfrg-eddsa/ Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

- Original Message - > From: "神明達哉" > To: "tjw ietf" > Cc: "dnsop" > Sent: Friday, 2 December, 2016 20:55:15 > Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any > - Section 3 > > 1. A DNS responder can

[DNSOP] Fwd: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard (draft-ietf-curdle-dnskey-eddsa-03.txt)

Dear colleagues, the EDDSA for DNSSEC have been approved by IESG. Ondřej and Robert, co-editors --- Forwarded message --- From: The IESG Date: 9 January 2017 16:23:28 Subject: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-01.txt

Hi, as promised here's copy of my mic comment: The draft is missing TLSA records (RFC 6698). Ondřej On 5 March 2017 18:39:29 internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

I support this. And found a nit, the document says: The most confusing element of the above equation comes from the "3 * (DNSKEY RRSIG Signature Validity) / 2" but the formula just before doesn't include "3 *" anywhere in it. Cheers, Ondrej -- Ondřej Surý

[DNSOP] Clarification: Complete or not-complete RRSets in AUTHORITY section? (non-DNSSEC)

> Data from the authority section of an authoritative answer, Thus only ns.example.com. is asked and it SERVFAILs. ~~~ In my understanding it should be ok to return SERVFAIL, because there's no way to honor the 5.4.1 Ranking and not fail. Or am I missing something really obvious? Ondrej -

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

ess? b) make this draft DNS-SD only, so it can fast forward... c) use the changed paradigm to work on DNSbis without the accident part? Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, C

[DNSOP] UDP fragmentation vs multiple-responses and multi-qtypes

rwise over- >committed. It should be noted, that ECC validation is more CPU intensive than RSA, as as such I find "CPU for validation is cheap compared to bandwidth" quite bold claim that should come with some data. Cheers, -- Ondřej Surý -- Technical Fellow

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

, if it would clearly state, this should be only used in DNS-SD sessions. Cheers, -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.czhttps://nic.cz

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

I support the adoption. Will make an effort to review if enforced with sharp object :) O. -- Ondřej Surý -- Technical Fellow CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.cz

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

stand the value of interoperability between DNS server vendors. * - compare to our synthrecord plugin: https://www.knot-dns.cz/docs/2.5/html/modules.html#synthrecord-automatic-forward-reverse-records Cheers, -- Ondřej Surý -- Technical Fellow CZ.NI

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

> On 7 Jun 2018, at 08:39, Viktor Dukhovni wrote: > > On Tue, Jun 05, 2018 at 09:02:07PM +0200, Ondřej Surý wrote: > >> Could I ask for more reviews, so we can progress this document forward? >> > > A couple of quick comments: > > 1. Perhaps it might

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

”... Ondrej -- Ondřej Surý ond...@isc.org > On 7 Jun 2018, at 17:28, Ondřej Surý wrote: > >> On 7 Jun 2018, at 08:39, Viktor Dukhovni wrote: >> >> On Tue, Jun 05, 2018 at 09:02:07PM +0200, Ondřej Surý wrote: >> >>> Could I ask for more reviews, s

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Oh, what about this? https://tools.ietf.org/html/draft-sury-dnsext-cname-dname-00 :-) O. -- Ondřej Surý ond...@isc.org > On 19 Jun 2018, at 15:18, Petr Špaček wrote: > > Hello dnsop, > > beware, material in this e-mail might cause your head to explode :-) > > T

Re: [DNSOP] SIG(0) useful (and used?)

But is it really used like this? Or will it ever? Ondrej -- Ondřej Surý ond...@isc.org > On 19 Jun 2018, at 23:04, Tony Finch wrote: > > Ondřej Surý wrote: >> >> Do people think the SIG(0) is something that we should keep in DNS and >> it will be used in the futur

Re: [DNSOP] SIG(0) useful (and used?)

But if nobody uses that and nobody else implements this, it sort of beats the usefulness of the feature. Ondrej -- Ondřej Surý — ISC > On 19 Jun 2018, at 23:20, Mark Andrews wrote: > > SIG(0) is much superior for machines updating their own data to TSIG as you > don’t need

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

-update So, if you haven’t deleted your account :), you can also send pull requests. Ondrej -- Ondřej Surý ond...@isc.org > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt > Date: 5 June 2

Re: [DNSOP] Creating a query/record for A and AAAA

tative answer level of RFC 2181 trust. So, instead of adding additional complexity of validating and storing the unsolicited information in additional section, the “prefetch” code in resolvers could be enhanced to pre-fill the cache with additional records

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

Oh, one more thing - I think it would be a good idea that this and attrleaf-fix would come as a bundle. Ondrej -- Ondřej Surý ond...@isc.org > On 26 Jun 2018, at 14:10, Ondřej Surý wrote: > > I read the document and I think it’s good to go. > > Ondrej > -- > Ondřej

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

I read the document and I think it’s good to go. Ondrej -- Ondřej Surý ond...@isc.org > On 25 Jun 2018, at 12:27, Benno Overeinder wrote: > > The chairs have read the email discussions on the DNSOP mailing list and > think that all feedback and comments have been addressed b

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

t be willing to deploy DNS cookies at all. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

> On 26 Mar 2018, at 16:47, Jim Reid <j...@rfc1035.com> wrote: > > On 24 Mar 2018, at 20:20, Ondřej Surý <ond...@isc.org> wrote: >> >>> It might be a different story if one of those zombie RRtypes required >>> additional processing. None spring

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

function). Therefore either you need to exclude the data that changes (hash and its RRSIG) when computing the hash for the BitTorrent and the receiving side would have to reassemble this. Or you would need OOB mechanism to distribute the hash (different part of the tree, CDN, ...). Ondřej -- Ondřej

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

if the places that would benefit the most would be the places where operators would be willing to seed Ondrej -- Ondřej Surý — ISC > On 27 Jul 2018, at 16:57, Bob Harold wrote: > > >> On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews wrote: >> >> >> > On 27 Jul 201

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Mail headers doesn’t have NSEC records. Also any operation where you need to reconstruct the file by combining bits from different places/channels is prone to errors. You need to know the hash is valid before you start the download. Therefore the hash has to be signed. O. -- Ondřej Surý

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

-- Ondřej Surý ond...@isc.org > On 26 Jul 2018, at 18:48, Paul Hoffman wrote: > > On 26 Jul 2018, at 9:43, Ondřej Surý wrote: > >>> On 26 Jul 2018, at 18:40, Wessels, Duane wrote: >>> >>> Ondrej, >>> >>> Thanks, I think thats a f

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

e delegation heavy zones would be especially susceptible to a collision attack. Does it make sense? Ondrej -- Ondřej Surý ond...@isc.org > DW > > >> On Jul 25, 2018, at 8:47 PM, Ondřej Surý wrote: >> >> Hi Matt, and other authors, >> >> with my cryptoplumber

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

records, you might as well cause damage at other levels of the DNS tree. -- Ondřej Surý ond...@isc.org > On 23 May 2018, at 17:32, Weinberg, Matt > wrote: > > Greetings dnsop, > > We’ve posted a new version of draft-wessels-dns-zone-digest. Of note, this > -01 version i

Re: [DNSOP] Incremental zone hash - XHASH

nk it there’s much difference on the implementation level. You need to sort and walk the zone for ZONEMD in the same manner as you would for XHASH. It only differs in an record(s) where you dump and reset the computed hash. Ondrej -- Ondřej Surý ond...@isc.org > On 21 Jul 2018, at 01:38, Wes

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

my original message. O. -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Yes, thank you. Seems like the information context was lost in the translation somewhere along the way. O. -- Ondřej Surý ond...@isc.org > On 31 Jul 2018, at 00:38, Wessels, Duane wrote: > > > >> On Jul 29, 2018, at 2:03 PM, Evan Hunt wrote: >> >> On Sun, Ju

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

. You don’t want SWAT unit knocking down your door because your nameserver downloaded Universal Declaration of Human Rights. Ondřej -- Ondřej Surý — ISC > On 29 Jul 2018, at 23:03, Evan Hunt wrote: > >> On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote: >> You nee

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

sponding RRset is not signed with a valid RRSIG record). This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference? ~~~ In Section: 7. Privacy Considerations s/mechansim/mechanism/ ~~~ That is all folks. Cheers, Ondrej -- Ondřej Surý ond...@isc.org > On 7 Apr 2018, at 08:

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

> On 26 Mar 2018, at 23:36, Paul Vixie wrote: > > i've had my symbolics 3640 online quite a bit in the last 30 years, This is certainly a fair piece of computer archaelogy, But it is similar to the situation if a museum would insist on providing narrow-wide tracks across the

Re: [DNSOP] Current DNS standards, drafts & charter

ting RFCs while adding more stuff at the same time tend to not reach the finish line. Ondrej -- Ondřej Surý ond...@isc.org > On 27 Mar 2018, at 01:26, Suzanne Woolf <suzworldw...@gmail.com> wrote: > > Hi all, > > First, thanks for running with this. > > Top-post

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

pping down the existing RFCs one-by-one, then just documenting what we already have without changing the content and producing the one “core” document obsoleting 1034,1035 is reasonable approach that could lead to an actionable work plan. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

Hi Michael, > On 27 Mar 2018, at 02:30, Michael Sinatra <mich...@brokendns.net> wrote: > > > > On 03/22/18 08:08, Ondřej Surý wrote: > >> * Separate operational recommendations for default algorithm to >> ECDSAP256SHA256 >> * Deprecation of ECC-GOS

Re: [DNSOP] Current DNS standards, drafts & charter

Definitely. I didn’t mean to rewrite 1:1, but take existing content and do m:n including splitting and combining existing RFCs into new document(s). Ondřej -- Ondřej Surý — ISC > On 27 Mar 2018, at 18:19, Matthew Pounsett <m...@conundrum.com> wrote: > > > >> O

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

”, but “how useful it is”. This would just lead into the situation that we would have two categories: “oh, that's too simple to remove” and “oh, that’s too difficult to remove” and nothing in between. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing l

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

e listing of all services at a particular host address, since the WKS RR type is not often used by Internet sites. To confirm that a service is present, simply attempt to use it. While the special processing was added to RFC 2136 (9 years later) i

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

stuff that was declared either OBSOLETE or EXPERIMENTAL already in RFC1035. I’ll elaborate more about why I think we locked ourselves into this when I am not typing on small phone screen in reply to Jared’s message later today. Cheers, Ondrej -- Ondřej Surý — ISC > On 24 Mar 2018, at 14:48,

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

s also seeking more feedback from the DNS people on that matter. Currently, there are RR Types already marked as “OBSOLETE” in the IANA registry without clear understanding what that does really mean. I guess the document might be able to specify what “OBSOLETE” means for RR Types

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Thanks to you both. I updated the draft with Evan’s text and merged some of Michael’s text to: https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records Cheers, -- Ondřej Surý ond...@isc.org > On 26 Mar 2018, at 16:57, Evan Hunt <e...@isc.org> wrote: > >

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

No, I am claiming that no current Internet standard is using those records and they were already marked as EXPERIMENTAL or OBSOLETE 30 years ago. Ondřej -- Ondřej Surý — ISC > On 26 Mar 2018, at 17:19, Paul Vixie <p...@redbarn.org> wrote: > > > > Ondřej Surý wr

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

that in this discussion, instead of saying “RR Types” we should talk about specific RR Types we want to remove from DNS. Saying “removing RR Types” is scary. Saying “removing MB RR Type” is less scary as most people even don’t remember what it was used for. Cheers, -- Ondřej Surý ond...@isc.org > On 26 Mar 2

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

needed for the RR Types I have proposed to be removed? I am specifically trying to not create a generic mechanism to remove any RR Type, just those under MAILA, MAILB umbrella and MINFO. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing l

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Thanks Dick, this is very helpful suggestion and I’ll use it. Ondrej -- Ondřej Surý ond...@isc.org > On 24 Mar 2018, at 00:06, Dick Franks <rwfra...@gmail.com> wrote: > > > On 23 March 2018 at 12:11, Ondřej Surý <ond...@isc.org> wrote: > > this is a first atte

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

ecause it is causing operational problems because of name compression in RDATA and RDATA canonicalisation (RFC 4034 Section 6.2). Here’s the example that triggered me to write the I-D: https://github.com/PowerDNS/pdns/issues/5687 Regards, Ondrej -- Ondřej Surý ond...@isc.org > I think what P

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

> On 24 Mar 2018, at 22:55, Mukund Sivaraman <m...@isc.org> wrote: > > Hi Ondrej > > On Sat, Mar 24, 2018 at 09:20:06PM +0100, Ondřej Surý wrote: >>> It might be a different story if one of those zombie RRtypes required >>> additional processing. None

  1   2   >