Re: [DNSOP] [IANA #1285116] expert review for draft-ietf-dnsop-dns-error-reporting (Underscored and Globally Scoped DNS Node Names)

[Frederico A C Neves]

Paul,

On Wed, Nov 01, 2023 at 12:38:09AM +0100, Paul Wouters wrote:
> On Oct 31, 2023, at 19:17, Frederico A C Neves  wrote:
> > 
> > Dear David,
> > 
> > Section 7 of the draft is sufficiently clear, precise, and complete.
> > 
> > This registration at the time it is approved by the IESG, taking in
> > account the fact that currently there is no other request for TXT _er
> > on the "virtual request queue", is reviewed as OK and approved.
> 
> I agree, although I do wonder what “er” stands for. Error Report? Why not use 
> “_err” which is more intuitively an error ?
>

Because of the additive nature of the spec on cascading/concatenating
error situations I would guess that the authors opted for the shortest
node name available to fit as much errors as possible.

> Paul

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [IANA #1285116] expert review for draft-ietf-dnsop-dns-error-reporting (Underscored and Globally Scoped DNS Node Names)

[Frederico A C Neves]

Dear David,

On Tue, Oct 24, 2023 at 07:39:27PM +, David Dong via RT wrote:
> Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG),
> 
> As the designated experts for the Underscored and Globally Scoped DNS Node 
> Names registry, can you review the proposed registration in 
> draft-ietf-dnsop-dns-error-reporting-06 for us? Please see:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
> 
> The due date is November 7th.
> 
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at:
> 
> https://www.iana.org/assignments/dns-parameters/
> 
> Unless you ask us to wait for the other reviewer, we’ll act on the first 
> response we receive.
>

Section 7 of the draft is sufficiently clear, precise, and complete.

This registration at the time it is approved by the IESG, taking in
account the fact that currently there is no other request for TXT _er
on the "virtual request queue", is reviewed as OK and approved.

> With thanks,
> 
> David Dong
> IANA Services Sr. Specialist

Regards,
Frederico Neves

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[Frederico A C Neves]

On Mon, May 01, 2023 at 04:43:11PM +, Wessels, Duane wrote:
> My preferred definition is the one originally given by Paul Vixie, amended by 
> myself, and further amended by Peter Thomassen:
> 
> A lame delegation is said to exist when one or more authoritative
> servers designated by the delegating NS rrset or by the child's apex NS
> rrset answers non-authoritatively for a zone.

+1 for this one.

Fred

> 
> I don’t think it is perfect, but it is an improvement.  I don’t think 
> perfection will be achievable.  
> 
> IMO “[or not at all]” does not belong in the definition.  I don’t think we 
> should allow timeouts to be confused for or considered as lame delegation.
> 
> If something like the above definition is adopted then the document can note 
> there is some historical lack of agreement or consistency in use of the term.
> 
> DW
>  
> 
> 
> > On May 1, 2023, at 9:09 AM, Paul Hoffman  wrote:
> > 
> > Caution: This email originated from outside the organization. Do not click 
> > links or open attachments unless you recognize the sender and know the 
> > content is safe. 
> > 
> > It would be grand if a bunch more people would speak up on this thread.
> > 
> > --Paul Hoffman, wearing my co-author hat
> > 
> > On Apr 27, 2023, at 1:05 PM, Benno Overeinder  wrote:
> >> 
> >> Dear WG,
> >> 
> >> The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
> >> on lame delegation did not find consensus, but two specific suggestions
> >> were put forward.  We would like to include one of them in rfc8499bis if
> >> we can get consensus to do so.
> >> 
> >> The chairs are seeking input on the following two suggestions:
> >> 
> >> * Either we leave the definition of “lame delegation” as it is with the
> >> comment that no consensus could be found, or
> >> 
> >> * alternatively, we include a shorter definition without specific
> >> examples.
> >> 
> >> 1) Leaving the definition of lame delegation as in the current
> >>  draft-ietf-dnsop-rfc8499bis, and including the addition by the
> >>  authors that:
> >> 
> >>  "These early definitions do not match current use of the term "lame
> >>  delegation", but there is also no consensus on what a lame delegation
> >>  is."  (Maybe change to ... no consensus what *exactly* a lame
> >>  delegation is.)
> >> 
> >> 2) Update the definition as proposed by Duane and with the agreement of
> >>  some others (see mailing list 
> >> https://secure-web.cisco.com/1X5AMTQJt2cXj7u31WPDppT_N_lSyi56z_C_stVVEipVVZkqvDApuQPa0iKxw5z8KkYh6lUYaa8WwEbu1lbUw_3U3-oCZDRWfYload0wQnMB3d76sNuzWFVBh7JB6a-2AOK0wOchJz8ErMhve7dpEUAX3u3v-rv-1jqen-3Ar6uMAJe4pFpHNVMWX8RyUI7uPYRUghgCekgBWibFm6LiPtCBLmTeUAdGkHdbCvCQ-SgAe56iNE4EwIGnrBWJTVJZlM-Dv3FrK04mE2gMsQs6HDzz40kt4871oRIkuNMadfKo/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2F4E1AQKGivEHtJDB85gSNhofRuyM%2F):
> >> 
> >>  "A lame delegation is said to exist when one or more authoritative
> >>  servers designated by the delegating NS RRset or by the child's apex
> >>  NS RRset answers non-authoritatively [or not at all] for a zone".
> >> 
> >> The chairs ask the WG to discuss these two alternative definitions of
> >> the term "lame delegation".  We close the consultation period on
> >> Thursday 4 May.
> >> 
> >> Regards,
> >> 
> >> Benno
> > 
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://secure-web.cisco.com/1XVxOCcNMkTcMeadUBQk9SlINRiQvUqtUMpxSKIOYBnT1ERKTnDtcFN1UjyDbfzk5FQqhfy31BXnCbOKFunIXd_OgZghAR9dJnnqlAmKIktWHve95FPY6YA3UinPiPabOUAEi7sOIwtzoF6rScnH_ml4EN5VeCkDj_DbUdU1FINNiKRFrKNlopElAMuHQoV1jehl-oCQtlNNopUy_X-mm_fPAbRNsYgc4S411S5vVePb4M-3xft1EktHXfsQNSe-y_vNR947juf5DmA2OYgq3gw0Efu3o0GxuyisOZ23nNj0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Frederico A C Neves]

On Sat, Apr 15, 2023 at 11:20:13AM +1000, Mark Andrews wrote:
> At this stage I think the only way to force this is to drop negative
> responses without SOA records present.  To have the lookups fail and
> that requires buy in by the large recursive server operators.
> 
> Similarly add an unknown EDNS option (pick a value between 1000 and 1999)
> to every QUERY until 1 Jan 2025 and if it comes back FORMERR with an OPT
> record present, drop the response.  10 years after cleaning up the EDNS
> specification we still have .5% of servers not updated.  BIND is effectively
> doing this with DNS COOKIE but it is painful when people say “but the lookup
> works with large recursive server”. 

+1000 for this one!

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC5155 and hash collision vs RFC9276

[Frederico A C Neves]

On Tue, Jan 17, 2023 at 01:56:04PM +0100, Otto Moerbeek wrote:
> Hi,
> 
> I was wondering about RFC9276 which says: "SHOULD NOT use salt", while
> RFC5155 section 7.1. says:
> 
> "If a hash collision is detected, then a new salt has to be chosen,
> and the signing process restarted."
> 
> Now I know it is *very* unlikely to see a collision when signing a
> zone, but is this perhaps the reason why the iterations count MUST be
> 0, while a salt SHOULD NOT be used, so that a salt remains legal to
> use?
> 
> If so, it would be nice to mention that reason, maybe in an errata (if
> extra explanation is allowed to be added in an errata).
> 
> Are there maybe other considerations why one is a MUST and the other a
> SHOULD NOT?

The use or not of a salt is a considerations taken from the point of
view of the signer. It has nearly zero implications regarding the main
concern of the document. But you do have a very good point, even
though very unlikely, on the mitigation venue of a possible hash
collision.

> Thanks,
> 
>   -Otto

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Frederico A C Neves]

On Fri, May 07, 2021 at 01:39:56PM -0400, John Levine wrote:
> It appears that Hugo Salgado   said:
> >-=-=-=-=-=-
> >
> >I'll upload a new version to revive it, and ask for a slot
> >in IETF111 for further discussion!
> 
> It looks like it's worth considering, but I also wonder how
> relevant it is for DNS servers that don't use AXFR/IXFR and SOA
> serial numbers to keep versions in sync.

In that case not much, but for many that uses in-band zone transfer
mechanisms it is very relevant. Specially in the case that the serial
in a zone is time deterministic.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

[Frederico A C Neves]

Hi Shumon,

On Tue, Jan 21, 2020 at 10:05:56AM -0500, Shumon Huque wrote:
> Hi Matthijs,
> 
> Sorry, I did miss your original note on this point. Now that I've seen it,
> I'm copying back dnsop@ietf.org to see if there are other comments on your
> proposal.
> 
> When the Algorithm Considerations section was originally written, I
> intentionally did not prohibit the use of multiple algorithms across
> providers (even though we recommended against it) for a very
> pragmatic reason: I was actually working with 2 DNS providers that
> supported disjoint algorithms (one RSASHA256 and the other ECDSAP256), and
> was seriously contemplating deploying such a multi-signer configuration in
> production. It would be a bit strange to deploy a configuration on the one
> hand, and at the same time write a document that explicitly forbid that
> configuration.
> 
> You mention that authoritative servers cannot simply ignore the rule that
> they must sign all RRsets in the zone with every algorithm in the DNSKEY
> RRset. However, in practice it is clearly being ignored. Neither .SE or .BR
> double signed their zone data during their algorithm rollovers and there
> are other cases.

Actually the algorithm rollover, following the liberal approach, is a
pure double signing process. With TTLs tuned it is during a short
interval but still double signing the zone.

ftp://ftp.registro.br/pub/gts/gts32/01-br-algorithm-rollover.pdf

> 
> As it turns out, the provider that only supported RSASHA256 exited the
> managed DNS provider business, and the only vendors we are working with
> currently all support our preferred algorithm (ECDSAP256) in common. Hence,
> I am now open to updating the document to prohibit it. But will such text
> cause aggravation for other potential deployers that may run into a similar
> situation with other providers, and do we care?
> 
> This also begs the question: should we (in another document) update RFC
> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
> it is being ignored?

I guess 6840 sec 5.11 already clarifies it. 4035 sec 2.2 is talking
about signers.

Fred

> 
> Frankly, I've always been a bit perplexed by this text, since it has no
> accompanying rationale. The only compelling rationale I see is downgrade
> protection - to detect that someone hasn't stripped away the signatures of
> a stronger algorithm and forced a validator to authenticate only the weaker
> signatures. But that implies that validators have a documented procedure to
> rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
> stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
> ECDSAP256SHA256?
> 
> Shumon.
> 
> On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking 
> wrote:
> 
> > Hi Shumon,
> >
> > On 1/20/20 9:21 PM, Shumon Huque wrote:
> > > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED) -
> > > please either drop this, or add the 2119 / 8174 boilerplate.
> > >
> > >
> > > Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords
> > > anywhere else in this document.
> >
> > Did you see my mail related to this? If you are going with the lowercase
> > approach, please use the word "must" instead of "should".
> >
> > Best regards,
> >
> > Matthijs
> >
> >
> >  Forwarded Message 
> > Subject: Re: [DNSOP] Working Group Last Call for
> > draft-ietf-dnsop-multi-provider-dnssec
> > Date: Mon, 13 Jan 2020 09:57:50 +0100
> > From: Matthijs Mekking 
> > To: dnsop@ietf.org
> >
> > Late to the party, I am sorry.
> >
> > I am positive about this document, and support publication. I do have
> > one comment on the document, requesting an update.
> >
> > In section 4 it is said it is RECOMMENDED that providers use a common
> > signing algorithm.  I think this is too weak and it must be a MUST.
> >
> > The reason given for RECOMMENDED is that the "liberal approach" works.
> > The liberal approach says that authoritative zones MUST sign RRsets with
> > every algorithm in the DNSKEY RRset, but validating resolvers don't have
> > to enforce this requirement. However, that does not mean the
> > authoritative server can simply ignore this rule.
> >
> > Also, if two different providers are using different algorithms, that
> > means two DS records with different algorithms are distributed to the
> > parent. And now the algorithm is signaled in the parent and a validator
> > may execute the multiple algorithms protection check, expecting both
> > chain of trusts to work.
> >
> > In other words, please adapt section 4 to be more strict when it comes
> > to multiple algorithms. If you agree, I am happy to provide the
> > suggested text.
> >
> > Again my apologies for bringing this up so late.
> >
> > Best regards,
> >
> > Matthijs
> >

> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec

[Frederico A C Neves]

Shane,

On Wed, Nov 20, 2019 at 04:52:22PM +0100, Shane Kerr wrote:
> Benno and all,
> 
> Overall the document is clear and I hope helpful to organizations 
> pursuing a multi-DNS vendor setup who want to use DNSSEC (as all do, I 
> am sure).
> 
> One minor thing I noticed while looking through the document. It 
> mentions the Brazilian ccTLD as background why using a liberal rollover 
> is workable:
> 
>In fact, testing by the .BR Top Level
>domain for their recent algorithm rollover [BR-ROLLOVER],
>demonstrates that the liberal approach does in fact work with current
>resolvers deployed on the Internet.
> 
> However, the BR-ROLLOVER reference is to a presentation which discusses 
> the plans to try a liberal rollover in Brazil, but doesn't actually 
> claim that it works. Was there further published research that can 
> support this idea?

There is a presentation I gave at ICANN-63 with the rollover report.

 * ICANN 63 - Oct/2018  

https://static.ptbl.co/static/attachments/191746/1540217948.pdf 

 Audio (English): starting at 57min50s  

http://audio.icann.org/meetings/bcn63/bcn63-OPEN-2018-10-24-T0636-113-en-DNSSEC-Workshop-1-of--3.m3u
 

This was previously reported at dns-operations,

https://lists.dns-oarc.net/pipermail/dns-operations/2018-October/018029.html

Besides of this I think there may be already published references of
this on works of Moritz Muller and Taejoong Chung. They greatly helped
us with the monitoring of the rollover.

> 
> Cheers,
> 
> --
> Shane
> 

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Frederico A C Neves]

On Mon, Mar 25, 2019 at 04:30:01PM +0100, Ray Bellis wrote:
> 
> 
> On 25/03/2019 16:08, Puneet Sood wrote:
> 
> > you mean lots of changes or lots of agreement with the quoted text?
> > They mean very different things.
> 
> I was agreeing with the quoted text - I believe that any serving of 
> stale records must be predicated on the presence of a valid delegation 
> from the parent zone.
> 
> Serve stael must not become a vector whereby malware can keep its C 
> systems artificially alive even if the parent has removed the C domain 
> name.

+1

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

[Frederico A C Neves]

On Fri, Jul 06, 2018 at 08:26:59PM -0400, Tim Wicinski wrote:
> We've had some interest in moving this document forward, and the chairs
> wanted to kick off this Call for Adoption before Montreal so if there
> are concerns there will be some meeting time to address.
> 
> This document is label as: Informational.  The document is attempting
> to document operational deployment models on deploying DNSSEC signed
> zones across multiple platforms.
> 
> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec

I support the adoption of this document

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[Frederico A C Neves]

On Thu, May 03, 2018 at 10:27:30PM +, David Huberman wrote:
> Mark Andrews stated:
> 
> >It’s amazing how fast people can fix lame delegations once email and other 
> >services stop flowing. The only reason you think it is un- winnable is that 
> >you 
> >are unwilling to remove the delegation for failing to maintain a properly 
> >working configuration. 
> 
> Ideally, yes – of course.
> 
> But in practical terms, when any type of registry strips away a lame 
> delegation
> attached to a real, operating network with users behind it, and things break
> as a result, it has a high potential of affecting the innocent 3rd parties 
> using that
> network.  Especially at scale, the legal liability issues implicated by such 
> an action
> are frightening, and quickly outweigh the ‘for the common good’ arguments. 

As long as there is community support Mark's observation works as
expected.

Slightly variatios of this policy are in place for LACNIC and APNIC
regions and is very effective.

http://www.lacnic.net/686/2/lacnic/6-lame-delegation-policy
https://www.apnic.net/manage-ip/manage-resources/reverse-dns/lame-dns-reverse-delegation/

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Frederico A C Neves]

Hi Matthijs,

On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:
> Hi Frederico,
> 
> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
> > I was looking at our server to evaluate the MIXFR implementation and
> > it seams to me that the current text covering dnssec aware client
> > logic don't take in account that a posterior record at the addition
> > section, by an MIXFR DNSSEC aware server, will implicitly replace the
> > RRSIG RRset.
> 
> I am unclear what case you are covering.

Any situation that you have an updated RRset. It is implicit that
you'll have to update the signature, so I was arguing that this is
afterward covered by 3.6 Replace a RRset. My "simplified" logic take
this in account to don't impose this extra logic at the client for
updated RRsets, only for removed RRsets, explicit or when a removal of
RR causes it.

So the actual difference on the wire is one server replacing the RRSIG
and the other adding it. For the client processing is RRSIG removal
logic only at RRset removal in one case and at any change for the
other. Bellow a zone at serial 1 and 2 and the two MIXFR versions.

example.IN  SOA serial=1
example.IN  RRSIG SOA
a.example.  IN  A   192.0.2.1
a.example.  IN  RRSIG A
b.example.  IN  A   192.0.2.2
b.example.  IN  A   192.0.2.3
b.example.  IN  RRSIG A

example.IN  SOA serial=2
example.IN  RRSIG SOA
b.example.  IN  A   192.0.2.3
b.example.  IN  A   192.0.2.4
b.example.  IN  RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A


# "simplified MIXFR"
example.IN  SOA serial=2
example.IN  SOA serial=1
a.example.  ANY A
b.example.  IN  A   192.0.2.2
example.IN  SOA serial=2
b.example.  IN  A   192.0.2.4
b.example.  ANY RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A
example.IN  SOA serial=2

# "implicit RRSIG removal at any change"
example.IN  SOA serial=2
example.IN  SOA serial=1
a.example.  ANY A
b.example.  IN  A   192.0.2.2
example.IN  SOA serial=2
b.example.  IN  A   192.0.2.4
b.example.  IN  RRSIG A
c.example.  IN  A   192.0.2.5
c.example.  IN  RRSIG A
example.IN  SOA serial=2

> 
> > Logic could be simplified only to Deletions of RRs, when they conclude
> > a removal of a RRset, or RRsets by itself.
> 
> No, also if there is an RR addition, it means the RRset has changed, so 
> existing RRSIG records can be implicitly removed.
> 

That is true but in this case you imply that it will be later added. I
was proposing to replace it.

> > All the other cases, addition or replacement, will be covered
> > automatically by an addition or replace of a RRSIG RRset. There is no
> > need to extra client logic to remove RRSIG, at addition of a RR, and
> > at deletion of a RR if it not remove the RRset.
> 
> Note there is no such thing as an RRSIG RRset. I tried to clarify this 
> in the terminology bis document:

So how do you call, two RR for the same name, type and class in a
double signed zone? Never mind I was not aware of this, thanks! Change
"a RRSIG RRset" by "any RRSIGs" and the logic still stands.

> 
>https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html
> 
> Note that adding an RRSIG is different than replacing an RRSIG.

Ok, but we could achive the same end result with both logics and
operations.

> 
> > This is documented as issue #10 and includes proposed text.
> > 
> > https://github.com/matje/mixfr/issues/10
> 
> I think it makes more sense to keep the text as is, that is when 
> changing an RRset implicitly remove the corresponding RRSIG records. I 
> am opposed to only removing corresponding RRSIG on a RR deletion.
> 

I think my version is easyer imposing less checks on clients but I can
live with the current text

I just realized the draft needs a new example for 4.2. The current one
is based on "Delete All RRsets of a Type". This operations was removed
in the current version of the draft.

> Best regards,
>Matthijs

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Frederico A C Neves]

I was looking at our server to evaluate the MIXFR implementation and
it seams to me that the current text covering dnssec aware client
logic don't take in account that a posterior record at the addition
section, by an MIXFR DNSSEC aware server, will implicitly replace the
RRSIG RRset.

Logic could be simplified only to Deletions of RRs, when they conclude
a removal of a RRset, or RRsets by itself.

All the other cases, addition or replacement, will be covered
automatically by an addition or replace of a RRSIG RRset. There is no
need to extra client logic to remove RRSIG, at addition of a RR, and
at deletion of a RR if it not remove the RRset.

This is documented as issue #10 and includes proposed text.

https://github.com/matje/mixfr/issues/10

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

[Frederico A C Neves]

On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote:
> 
> > On 29 Mar 2018, at 9:05 am, Frederico A C Neves <fne...@registro.br> wrote:
> > 
> > On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> >> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> >>> No. You can have multiple nsec3 chains in a zone at the same time. Only 
> >>> one is active.  Some may be incomplete. 
> >>> 
> >>> Named builds and destroys chains incrementally to avoid large changes. 
> >>> 
> >>> Timely ness of changes is more  important than volume of changes.
> >> 
> >> As I stated down on this thread this behaviour is the one that is
> >> already supported by IXFR. For large zones, on large anycast networks,
> >> the volume of changes on the wire is important. The current aproach is
> >> impractical.
> > 
> > Perhaps this text is more specific and address the incremental re-salt
> > scenario and even improve it after the new chain in already in place
> > at the time of the removal of the old one.
> > 
> > 3.1 Implicit DNSSEC deletions
> > 
> > When an NSEC3PARAM is deleted or replaced, the MIXFR client MUST also
> > remove all existing NSEC3 records on the zone that form the chain
> > related to the deleted or replaced salt.
> > 
> > Fred
> 
> Firstly we should just say “DO NOT CHANGE NSEC3PARAM” as it is POINTLESS
> 
> Secondly you lose the ability to determine is the MIXFR is still in sync if 
> you do that.
> 
> Currently named requires that all delete operations in IXFR MUST find the 
> record in the
> zone and that all add operations MUST NOT find a existing record.  If either 
> condition
> fails then named falls back to a full AXFR of the zone as we know the zone 
> contents are
> no longer in sync.
> 
> That property needs to be preserved by this implementation.

AFAIK there is nothing on the current logic that a compliant server
implementation would not preserve this property for a compliant client
that expects it.

> You also need to be able to extract a MIXFR stream from a IXFR stream (as 
> that is what
> gets recorded to disk).  I don’t believe that will be possible from a 
> arbitrary IXFR
> stream.  

You are right if what you have is only the stream of IXFRs. But a
compliant server implementation at the time it updates the zone -
being looking for differences of a zonefile, processing Dynamic
Updates or reading an adequate jornal of updates - it will accordingly
produce the IXFR and the MIXFR to be recorded on disk.

Starting with the current zone representation and a stream of backward
IXFRs allow you do first get to the past zone representation, I mean
applying the IXFRs backward, and then start to produce the respective
MIXFRs. Awkward, very unlikely implementation for a compliant MIXFR
server, but possible.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

[Frederico A C Neves]

On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote:

> > One comment,
> > 
> > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text
> > regarding NSEC3PARAM update as well.
> > 
> > For that I suggest to change 3.1 section name and include an extra
> > paragraph.
> > 
> > 3.1 Implicit DNSSEC deletions
> > 
> > When an NSEC3PARAM is modified, the MIXFR client MUST also remove all
> > existing NSEC3 records on the zone.
> 
> I agree that with the current syntax NSEC3 resalting is still a hassle. 
> But I am not sure if this implicit NSEC3 deletion is the right solution: 
> One can have multiple chains in the zone, the NSEC3PARAM just signals 
> that the chain is complete. Signers may have incomplete chains as an 
> intermediate step of NSEC3 resalting.
> 
> I shall add a GitHub issue for this. Thanks for bringing it up!

This is documented at issue #8 with an updated proposed text after
discussion down this thread.

https://github.com/matje/mixfr/issues/8

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

[Frederico A C Neves]

On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> > No. You can have multiple nsec3 chains in a zone at the same time. Only one 
> > is active.  Some may be incomplete. 
> >  
> > Named builds and destroys chains incrementally to avoid large changes. 
> > 
> > Timely ness of changes is more  important than volume of changes.
> 
> As I stated down on this thread this behaviour is the one that is
> already supported by IXFR. For large zones, on large anycast networks,
> the volume of changes on the wire is important. The current aproach is
> impractical.

Perhaps this text is more specific and address the incremental re-salt
scenario and even improve it after the new chain in already in place
at the time of the removal of the old one.

3.1 Implicit DNSSEC deletions

When an NSEC3PARAM is deleted or replaced, the MIXFR client MUST also
remove all existing NSEC3 records on the zone that form the chain
related to the deleted or replaced salt.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

[Frederico A C Neves]

On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> No. You can have multiple nsec3 chains in a zone at the same time. Only one 
> is active.  Some may be incomplete. 
>  
> Named builds and destroys chains incrementally to avoid large changes. 
> 
> Timely ness of changes is more  important than volume of changes.

As I stated down on this thread this behaviour is the one that is
already supported by IXFR. For large zones, on large anycast networks,
the volume of changes on the wire is important. The current aproach is
impractical.

Fred

> 
> -- 
> Mark Andrews
> 
> > On 29 Mar 2018, at 02:06, Frederico A C Neves <fne...@registro.br> wrote:
> > 
> > Hi Matthijs,
> > 
> >> On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
> >> All,
> >> 
> >> It's been a while, but I have put up a new version of the MIXFR draft:
> >> 
> >> https://tools.ietf.org/html/draft-mekking-mixfr-02
> >> 
> >> The IETF 101 Hackathon lead to the revival of this draft.
> >> 
> >> Changes after the three year sleep:
> >> 
> >> - I removed the IXFR Gone Wild section. This document should focus in 
> >> the in-band transfer improvements. I know there are others who like to 
> >> see and work on a new DNS transfer protocol, but one does not exclude 
> >> the other.
> >> - Intended status: Standards track.
> >> - Added a clarification from Bob Harold about class ANY (from 2015).
> >> - Remove ambiguous "Delete All RRsets of a Type".
> >> - Affiliation changes.
> >> 
> > 
> > Thanks for bringing this back. I like the simplification with the
> > removal of the wild section.
> > 
> > One comment,
> > 
> > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text
> > regarding NSEC3PARAM update as well.
> > 
> > For that I suggest to change 3.1 section name and include an extra
> > paragraph.
> > 
> > 3.1 Implicit DNSSEC deletions
> > 
> > When an NSEC3PARAM is modified, the MIXFR client MUST also remove all
> > existing NSEC3 records on the zone.
> > 
> > 
> > One clarification question,
> > 
> > At 3.6, last paragraph, what is the practical case that a updated
> > record has an RDLENGTH of zero bytes?
> > 
> >> Who would like to contribute, review, and all that great fun?
> >> 
> >> Github is here: https://github.com/matje/mixfr
> >> 
> >> Best regards,
> >>   Matthijs
> > 
> > Fred
> > 
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] raising the bar: requiring implementations

[Frederico A C Neves]

On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote:
> bert hubert  wrote:
> >
> > Well to allow the one remaining closed source DNS implementation some room,
> 
> authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign
> recursive services: Google OpenDNS Quad9
> COTS: Nominum
> 
>  ... I have probably missed several ...

MS

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

[Frederico A C Neves]

Hi Matthijs,

On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
> All,
> 
> It's been a while, but I have put up a new version of the MIXFR draft:
> 
>  https://tools.ietf.org/html/draft-mekking-mixfr-02
> 
> The IETF 101 Hackathon lead to the revival of this draft.
> 
> Changes after the three year sleep:
> 
> - I removed the IXFR Gone Wild section. This document should focus in 
> the in-band transfer improvements. I know there are others who like to 
> see and work on a new DNS transfer protocol, but one does not exclude 
> the other.
> - Intended status: Standards track.
> - Added a clarification from Bob Harold about class ANY (from 2015).
> - Remove ambiguous "Delete All RRsets of a Type".
> - Affiliation changes.
>

Thanks for bringing this back. I like the simplification with the
removal of the wild section.

One comment,

[3.1] As section 3 states that MIXFR is DNSSEC aware we need text
regarding NSEC3PARAM update as well.

For that I suggest to change 3.1 section name and include an extra
paragraph.

3.1 Implicit DNSSEC deletions

When an NSEC3PARAM is modified, the MIXFR client MUST also remove all
existing NSEC3 records on the zone.


One clarification question,

At 3.6, last paragraph, what is the practical case that a updated
record has an RDLENGTH of zero bytes?
 
> Who would like to contribute, review, and all that great fun?
> 
> Github is here: https://github.com/matje/mixfr
> 
> Best regards,
>Matthijs

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

[Frederico A C Neves]

On Wed, Mar 28, 2018 at 04:43:53PM +0200, Pieter Lexis wrote:
> Hi Matthijs,
> 
> On Wed, 28 Mar 2018 15:31:57 +0200
> Matthijs Mekking  wrote:
> 
> > It's been a while, but I have put up a new version of the MIXFR draft:
> > 
> >  https://tools.ietf.org/html/draft-mekking-mixfr-02
> 
> The draft speaks of an OPCode in the IANA section and of a meta
> RRType in the examples and Introduction section, which is it?
> 
> If it is an RRType, some words need to be added about the fact that
> current resolvers will pass through the MIXFR query and not reply with
> NOTIMPL. In a similar vein, unaware auths will respond with an NXDOMAIN
> or (more likely) a NODATA in that case.

Draft's samples use regular QUERY opcode and I suppose a new met
RRType MIXFR.

Does current auth server have any special processing for meta RRTypes?
If not your are correct regarding the unaware server and this needs to
be stated and handled by clients.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07

[Frederico A C Neves]

Paul,

On Fri, Mar 23, 2018 at 11:00:03AM -0700, Paul Vixie wrote:
> i'm concerned about the age-old human protocol being employed here.
> 
> first one guy shouts bikeshed! (usually somebody who's been bikeshedding.)
> 
> nextly, some folks say "the details don't matter, only uniqueness."
> 
> then there's a bunch of back and forth about whether and which details 
> matter.
> 
> then there's a lot of folks saying, "personally i would go with..." or 
> "i prefer ..." or "my vote is for..."
> 
> then somebody inevitably says "this is taking too long, let's just pick 
> something."
> 
> it's how ipv6 and dnssec were standardized, with sweepingly bad results 
> that our great grandchildren will no doubt shake their heads about, in 
> wonder.
> 
> i request a different protocol.
> 
> can the co-chairs convene a design team made up of people from each camp 
> named above, and lock them in a room and shove pizza under the door 
> until they have a proposal that can be accepted on its _merits_?
> 

This doesn't seams to be the case. The document is being reviewed by
the WG for a while and just adjusting the label and the document's
name, closing their use only for the root, is a good move.

This expansion in scope was included in the beginning of the
discussion just to make the point that the root is not different from
any other zone and this mechanism could be expanded for other
cases... perfect and over engineered. The reality is this is only
needed for the root that has no parent. Please no one start the
argument of local configure anchors any zone down the tree. If this is
the case for an enterprise or Mil. network they have their ways of
controlling/distributing those anchors.

The document is good on it's own merits.

> vixie

Fred

> re:
> 
> Joao Damas wrote:
> > I am happy with whatever the wg agrees but let’s agree, otherwise time 
> > keeps sliding and the only label that is going to be accurate for the next 
> > generations will be “ksk-roll-that-never-was” ;)
> >
> > Joao
> >
> >> On 23 Mar 2018, at 16:13, Ondřej Surý  wrote:
> >>
> >> I also prefer #2
> >>
> >> Personally, I would go with rzksk-sentinel because it’s shorter and more 
> >> accurate, but #2 will make me happy.
> >>
> >> Ondrej
> >> --
> >> Ondřej Surý — ISC
> >>
> >>> On 23 Mar 2018, at 15:20, Wessels, Duane  wrote:
> >>>
> >>>
>  On Mar 23, 2018, at 5:13 AM, Warren Kumari  wrote:
> 
>  Dear DNSOP,
> 
>  Please clearly express a preference for:
>  1: Keeping the current label -- kskroll-sentinel-is-ta-20326.example.com
>  2: Changing it to the new label -- 
>  root-key-sentinal-is-ta-20326.example.com
> 
> >>> I prefer #2.
> >>>
> >>> DW
> >>>
> >>> ___
> >>> DNSOP mailing list
> >>> DNSOP@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dnsop
> >> ___
> >> DNSOP mailing list
> >> DNSOP@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dnsop
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> P Vixie
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
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

[Frederico A C Neves]

On Fri, Mar 23, 2018 at 03:58:02PM +, Viktor Dukhovni wrote:
> On Thu, Mar 22, 2018 at 01:27:38PM -0400, Paul Wouters wrote:
> 
> > I think this text also needs an update:
> > 
> > RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones
> > deploying it are recommended to switch to ECDSAP256SHA256 as there is
> > an industry-wide trend to move to elliptic curve cryptography.
> > 
> > They should switch away from SHA1 as SHA1 is being deprecated industry
> > wide. Even if we recommend to move away from RSA (which I'm not sure if 
> > there
> > is consensus on) to ECC, I would like to move them to ED25519/ED448 over
> > the ECDSA* variants.
> 
> I think it is, unfortunately, much too early for such a move.  For
> example, on Unix systems the requisite OpenSSL 1.1.x libraries that
> provide the Edwards EC algorithms, are not yet out of beta!  It
> will be some years before Ed25519 and Ed448 can be expected to be
> widely supported by resolvers.  Therefore, I would still strongly
> recommend ECDSA, which is widely supported.
> 
> We should certainly encourage the implementation of Ed25519/Ed448
> in resolver and nameserver implementations, but it is much too
> early for adoption, beyond dual DS/KSKs one ECDSA and another
> Ed25519, with the client choosing whichever it prefers.  ZSKs should
> IMHO migrate to ECDSA for now to alleviate packet size issues.

This is exactly one of our, .br. reasonings for moving forward to EC
now.

Talking this conversation to the root, all this rollover hurdles would
be much smaller, if any. We could leave with a Double signing for a
long time. With ECDSAP256/Ed25519 the keyset would be much smaller
than the current one, aparently we're about to roll the zsk, ~ 1/4 of
the size. And the signature would be ~ 1/2 of the current single
RSA2048 size.

Fred

___
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

[Frederico A C Neves]

On Thu, Mar 22, 2018 at 05:47:58PM +, Ondřej Surý wrote:
... 
> > They should switch away from SHA1 as SHA1 is being deprecated industry
> > wide. Even if we recommend to move away from RSA (which I'm not sure if 
> > there
> > is consensus on) to ECC, I would like to move them to ED25519/ED448 over
> > the ECDSA* variants.
> 
> I don’t think this is currently feasible to do so, so we need to have a 
> feedback from WG.
> 
> > If it is too soon for that now, I would simply not
> > recommend moving away from RSA. And maybe make ECDSAP256SHA256 a MAY
> > instead of a MUST.
> 
> What would be the technical/security reason for skipping ECDSA?
> 
> Ondrej

Besides of this question this is a recommendation to be change in the
future. Current ED25519/ED448 deployment is negligible if any. It will
take at least 5 year for the situation to improve.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question about usage of ip6.arpa and in-addr.arpa

[Frederico A C Neves]

On Tue, Mar 13, 2018 at 11:16:56AM -0400, Joe Abley wrote:
> On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker  
> wrote:
> 
> > After a number of discussions I’m interested in returning to the original 
> > concept as it simplifies a number of use cases that this document is 
> > intended to support but am still not sure whether or not this would be 
> > widely considered ‘ok’ by DNS folks. Obviously it’s entirely possible to do 
> > this as these child zones are delegated to users and they _can_ put 
> > whatever they want in them. Does this WG have strong opinions on whether we 
> > should/shouldn’t do this for technical reasons or we just being a bit too 
> > strict in our reading of 3172?
> 
> I think that if Tony can be d...@dotat.at, surely I can be 
> jab...@90.212.199.in-addr.arpa.
> 
> A zone is a zone. ARPA is only special by convention, not by protocol.
> 

Sure. Extra data, people in less stocked address networks have being
following BCP20 with the extra trick of putting delegations and
associated glue inside the same in-addr.arpa zone for ages.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

[Frederico A C Neves]

On Mon, Nov 13, 2017 at 03:45:30PM +, Edward Lewis wrote:
> On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt"  behalf of e...@isc.org> wrote:
> 
> >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote:
> >> Nice write-up Edward! You have nicely summarized why Mark and me agree
> >> that validator should use longest suffix match when selecting TA to
> >> validate data.
> >
> >+1.
> 
> Hmmm, that wasn't my intent. ;)  I had been trying to justify the other 
> conclusion.  But, if my work is leading you towards this "other" conclusion, 
> I've been taking time to understand why.
> 
> I'm beginning to have a new understanding on this.  The overlooked (by me) 
> point is that we are focusing on a situation where the local operator has 
> chosen to explicitly configure a trust anchor.  Beside code distributions 
> shipping with the IANA managed KSK (or its DS form) for the global public 
> Internet's root zone, if any operator wants another trust anchor point, they 
> have to take explicit action to configure it.  The question is - what is the 
> expectation of the operator in doing this?
> 
> There was a time when TLDs were signed but the root zone was not.  Then 
> operators had to configure trust anchors for the TLDs to enable validation.  
> When the root zone was signed in 2010, the TLDs had to remind all those with 
> trust anchors to remove them (before the TLD could change it's KSK).  I can 
> no longer find reports of the efforts to undo TLD trust anchors (Sweden and 
> maybe CzechRep?) that I thought were once floating around.  "Fears" 
> surrounding this would lead one to favor the more open "any" policies, on the 
> other hand, mass migration from TLDs to root for the top of the trust chain 
> was probably a one-time event as a result of the on-set of DNSSEC in the root 
> zone.
> 

Yes. And add to that cases were TLDs rolled just before adding to the
root.

https://eng.registro.br/pipermail/gter/2010-May/027981.html
https://eng.registro.br/pipermail/gter/2010-June/028053.html
https://eng.registro.br/pipermail/gter/2010-July/028138.html

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

[Frederico A C Neves]

Jakob,

On Tue, Mar 14, 2017 at 09:04:53AM +0100, Jakob Schlyter wrote:
> This draft should be of interest to this WG, providing an alternative to 
> draft-wouters-sury-dnsop-algorithm-update.
> 
>   jakob
> 

> > https://tools.ietf.org/html/draft-arends-dnsop-dnssec-algorithm-update-00

This is a cleaner guidance to implementers but I would like to see the
new curves, ED25519 ED448, included at least as recommended to
implement.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated NSEC5 protocol spec and paper

[Frederico A C Neves]

On Fri, Mar 10, 2017 at 01:15:42PM -0500, Shumon Huque wrote:
...
> 
> Apparently there are many folks in the community who think so, otherwise
> NSEC3 would not have been developed. I personally don't care for any zones

I know others have already stated this but zone enumeration, at least
at that time, was never the real reason for NSEC3, size of signing
zones with mostly unsigned delegations was. This was only needed
because of the wg lack of management and sensibility to operators
needs leading to the historical debacle of opt-in. We changed the
name, and voila opt-out ;-)

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Asking TLD's to perform checks.

[Frederico A C Neves]

On Wed, Nov 11, 2015 at 07:25:39AM +0100, Patrik Fältström wrote:
...
> 
> That said, initiatives like the one I did run did push errors (for some 
> definition of errors) from 22% to maybe 17% in .SE and my inspection of the 
> rest say that getting errors down to 15% is possible, but more is very hard.
> 

Enforcing at delegation and change time and checking and reporing on a
regular basis, weekly and montly respectively, brought us to 5%.

http://registro.br/estatisticas.html

Look at the botton "Status das Delegações" and follow the total error
links to trending graphics.

> And, having a BCP or such that give suggestions on what can be viewed as 
> "correct" would not be bad, but how to use it must be up to the reader.
> 

Agree,

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

[Frederico A C Neves]

On Fri, Jan 16, 2015 at 09:58:32AM -0800, Paul Vixie wrote:
 
  Olafur Gudmundsson mailto:o...@ogud.com
  Friday, January 16, 2015 7:51 AM
  ...
  One of the oldest ideas on that was from Andreas Gustafsson was to wrap
  XFR transmission inside compressed transmission.
 
 late BIND4 and early BIND8 had something called ZXFR that did this. it
 never worked out of the box, but frederico neves in brazil fixed it and
 had it running in production for his inter-site synchronization some
 time in the mid/late 1990's. it's worth asking him if it was worthwhile

This was late 1990's, in a time that we didn't have registry backend
journals, way before bind started providing ixfr-from-differences on
9.3, OSs still struggled with the long fat pipe problem and we happen
to have some secondaries on the 350ms vicinity... it was definitely
worthwhile. But today I guess in the same scenario a vpn based
transport solution would be easier.

 (noting, this was before incompressible DNSSEC signatures were added.)

True only for individual records. I guess the authors are aiming at
small zones and Olafur had this in mind when doing this comment. For a
even a few thousand records signed zone I see quite good compression
only taking in account RRSIGs RDATA.

Taking synchronization efficiency in perspective, reducing the amount
of redundant information, explicitly suppressing it, is the best
approach. MIXFR ideas are worth pursuing.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-eastlake-dnsext-cookies

[Frederico A C Neves]

On Thu, Nov 13, 2014 at 04:55:36PM -1000, Tim WIcinski wrote:
 
 DNSOP WG,
 
 This starts a call for adoption for draft-eastlake-dnsext-cookies.
 
 The draft is available here:
 
 https://datatracker.ietf.org/doc/draft-eastlake-dnsext-cookies/
 
 Please review this draft to see if you think 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.

I support the adoption by the WG and I'm willing to review it.

This advance is an effective way of adding much more bits to defend
against of path attacks in the absence of DNSSEC.

This is an effective way to maintain DNS transport over UDP in the
face of the current threats of amplification attacks.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] key lengths for DNSSEC

[Frederico A C Neves]

Nicholas,

On Wed, Apr 02, 2014 at 04:25:10PM -0400, Nicholas Weaver wrote:
 
... 
 And please don't discount the psychology of the issue.  If DNSSEC
 wants to be taken seriously, it needs to show it.  Using short keys
 for root and the major TLDs, under the assumptions that it can't be
 cracked quickly (IMO, we have to assume 1024b can be.) and that old
 keys don't matter [1], is something that really does draw criticism.

 [1] IMO they do until validators record and use a 'root key
 ratchet': never accept a key who's expiration is older than the
 inception date of the RRSIG on the youngest root ZSK seen, or have
 some other defense to roll-back-the-clock attacks.

What do you mean by ..key who's expiration is..? A new propertie
recorded at this ratchet, btw what is this?

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02

[Frederico A C Neves]

On Fri, Mar 07, 2014 at 03:03:40AM +0900, fujiw...@jprs.co.jp wrote:
...
 I would like to know whether the increase of DS queries are observed
 commonly or not. (with small NCACHE TTL value)

We are observing around the same % of qps but still need to confirm
the other characteristics.

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Frederico A C Neves]

On Fri, Mar 30, 2012 at 10:19:43AM +, Ray Bellis wrote:
 
 On 30 Mar 2012, at 12:09, Ond??ej Surý wrote:
 
  Hi Joseph,
  
  since I am not sure if you understood my point (I am not sure if I was able
  to understand it myself :), I am summarizing it to the mailing list.
  
  I like the direction of your work, but I miss a way how to put more stuff 
  under
  the named prefix.
  
  I would like you to update RFC2317 together with your document, so the end
  customers don't have two distinct trees in their DNS infrastructure.
 
 +1

I'm not quite sure 2317 can be used for shorter prefixes but it's
actually only seen in the wild for /25 onwards. The proposed idea
works for any prefix outside the 8 or 4 bit boundary depending on what
family we are talking.

  F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have 
  delegate
  it to the customer, how do I put my PTRs in?  The block owner would still 
  have
  to delegate another dummy prefix with CNAMEs and you have to handle it in
  separate zone.
  
  BTW one more observation.  Since you don't have to do any zone cuts in the 
  binary
  part, why not merge them into just one label?  E.g. something like 
  10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa.
 
 With the current scheme it's possible to delegate longer prefixes, and this 
 is a necessary feature.
 
 The stuff Dan was saying about two alternate representations concerns me, 
 though.  As written, by default:
 
   192.168.64/18 is 1.0.m.168.192
 
 but
 
   192.168.64/24 is 64.168.192
 
 which is not a sub-domain of the enclosing /18 representation.
 
 This way lies dragons, I think...

If your parent have't made their mind I agree with you, but this is
very unlekely.

 Ray

Fred
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A different question

[Frederico A C Neves]

On Thu, Aug 21, 2008 at 09:47:38AM -0700, David Conrad wrote:
...
 If the root zone were to strobe between signed and unsigned, what  
 minimum duration of signed, and what
 maximum duration of unsigned would be likely to not cause  
 operational problems for the aforementioned
 DNSSEC-configured caching, validating resolvers?
 
 I'm unclear how going from a signed root zone to an unsigned root zone  
 would work.  If you've configured your root trust anchor and you get  
 back a response that isn't signed, wouldn't that be treated as a  
 validation failure?

Yes. This behavior is actually very clear, the dns tree will vanish
for theses validating caching resolvers.

You have the option of doing this smoothly by revoking the key (5011)
but it'll not bring any value to the deployment effort as you'll need
to re-anchor again.

Fred
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Frederico A C Neves]

On Fri, Aug 15, 2008 at 11:29:13AM -0700, David Conrad wrote:
 Hi,
 
 On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote:
 But until we have root and .com signed, and until the average end- 
 user is protected by a validating resolver, we aren't done yet, and  
 I don't really get any actual benefit from my efforts.   Which,  
 tragically, is why it's taking so long.
 
 There are people who appear to think deploying DNSSEC as soon as  
 possible would be a good thing.  There are also people who appear to  
 think deploying DNSSEC is a fools errand, that it won't get  
 significant use because it makes things too hard, too complicated, too  
 prone to failure, etc.
 
 However, because of DO, folks who don't configure their resolvers to  
 do DNSSEC shouldn't ever see any DNSSEC goop.
 
 Given this, does anyone see any DNS security and/or stability concerns  
 if a miracle were to happen and the root were to be signed tomorrow?

Having signed a large delegation centric zone and as expected not
seeing any security/stability issue for a significant amount of time I
would say NO.

 That is, if you don't care about DNSSEC, do you think it would be  
 bad(tm) if the root were to be signed (for the sake of argument,  
 ignore the time waste, administrative overhead, etc. associated with  
 DNSSEC-signing)?  If so, why?

Ok, I do care but the answer is still NO. Besides the large amount of
statements accusing if of being a pig-protocol it is really well
thought on incremental deployment for clients.

 Thanks,
 -drc

Fred
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt

[Frederico A C Neves]

Mr. Anderson,

On Sat, Jun 28, 2008 at 05:36:04PM -0400, Dean Anderson wrote:
 A number of the points you raise have already been addressed.
 
 The IPV6 Reverse resolution question has been discussed at length in
 DNSEXT previously. In fact, it was proposed to remove reverse resolution
 entirely from IPV6 for just the reason Dr. Huang notes.  A 128 bit IPV6
 address is 16 octets. To perform reverse resolution requires traversing
 16 levels of DNS tree. 

Not exactly. The reverse delegation is at the 4 bits boundary, so the
correct is 32 possible levels, but this possibility doesn't impose all
these levels. Half of the levels are unlikely to be used and the other
half you'll see normally the average of 3 to 4 as we see it today for
IPv4. The amount of delegations levels are driven by the IP
distributions layers (IANA-RIR-NIR-ISP), not by the address space.

Fred
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AS112 for TLDs

[Frederico A C Neves]

On Fri, Apr 04, 2008 at 11:19:58AM -0400, Andrew Sullivan wrote:
 On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote:
...
 I can just imagine the hue and cry that would happen when new top
 level domains don't work for everybody.

Or in a future, actually very far from today, when DS records are not
updated during a rollover.

Fred
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop