Re: [DNSOP] New mailing list: DNS Delegation

[Ólafur Guðmundsson]

Chairs,
Quick questions
why a new list and what is that lists standing in the IETF?
Is this  precursor for a BOF and possible new working group ?

thanks
Ólafur


On Tue, Feb 6, 2024 at 2:37 PM Paul Hoffman  wrote:

> Greetings. After the DNSOP interim meeting last week, Warren set up a new
> mailing list. Its description is:
>
> =
> There is a desire to have better methods for parent zones in the DNS to
> advertise DNS nameserver capabilities and zone features to resolvers.
>
> This list discusses mechanisms to provide this support within the DNS.
> This includes the ability to provide more information about a DNS
> delegation in record(s) at the parent, as well as additional capabilities
> beyond the DNS's current NS-style delegation.  Examples include aliasing
> delegation with other domain names, delegating DNSSEC management to
> operators, specifying encrypted transports, and so on.
> =
>
> The new mailing list is a good place to discuss both the general idea of
> new types of delegation for the DNS, as well as specific proposals like the
> DELEG proposal which was first discussed at IETF-118.
>
> The list can be found at https://www.ietf.org/mailman/listinfo/dd
>
> Anyone interested in how delegation might work in the future should join.
> Thanks!
>
> ___
> 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] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-00)

[Ólafur Guðmundsson]

Peter,
 I like the concept a lot and this is a good natural evolution,

My comments/issues
 #1 this should cover normal notify as well as there is no reason parent
should have to be updates every time an external DNS provider changes its
distribution "top"
#2 I would love the examples to use a different port than  53 as there is
no need for the notifies to go to that overloaded port
#3 As of new type vs SRV the argument against new type at apex is always
size of ANY, which I do not buy but I like new types :-)
#4 It should be clear that there is no need to run a "nameserver code" as
the target of the NOTIFY messages, similarly there is no real reason why
the issuer of the Notify is a "nameserver code" i.e. both of ends are
front/back ends of provision systems

Olafur


On Tue, Nov 29, 2022 at 7:37 AM Peter Thomassen  wrote:

> Dear DNSOP,
>
> Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation
> maintenance are usually detected through scheduled scans run by the
> consuming party (e.g. top-level domain registry), incurring an
> uncomfortable trade-off between scanning cost and update latency.
>
> A similar problem exists when scheduling zone transfers, where it has been
> solved using the well-known DNS NOTIFY mechanism ([RFC1996]) which enables
> primaries to nudge secondaries when there's a zone update, allowing the
> latter to initiate an out-of-order zone transfer and reset the serial check
> timer.
>
> At the IETF a few weeks back, Johan and I felt a sudden enlightenment when
> it occurred to us that the same approach could be used to reduce scanning
> cost for CDS/CSYNC scans and the like, while maintaining low update
> latency. In fact, the NOTIFY spec already does allow sending NOTIFY message
> of other types. So, we not use that for hinting beyond SOA?
>
> We wrote up a draft, and if you'd like to read how one could make this
> work, feel free to take a look:
> -->
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/
>
> There is also an application in multi-signer setups, where Viktor had
> brought up the problem of ZSK rollovers by one signer, and how the others
> would know about that. That's not as well fleshed-out yet, but we figured
> it shouldn't keep us from circulating the initial idea.
>
> Best,
> Peter
>
>
>  Forwarded Message 
> Subject: New Version Notification for
> draft-thomassen-dnsop-generalized-dns-notify-00.txt
> Date: Mon, 28 Nov 2022 13:10:10 -0800
> From: internet-dra...@ietf.org
> To: Johan Stenstam , Peter
> Thomassen 
>
>
> A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-00.txt
> has been successfully submitted by Peter Thomassen and posted to the
> IETF repository.
>
> Name:   draft-thomassen-dnsop-generalized-dns-notify
> Revision:   00
> Title:  Generalized DNS Notifications
> Document date:  2022-11-28
> Group:  Individual Submission
> Pages:  13
> URL:
> https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/
> Html:
> https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify
>
>
> Abstract:
> Changes in CDS/CDNSKEY, CSYNC, and other records related to
> delegation maintenance are usually detected through scheduled scans
> run by the consuming party (e.g. top-level domain registry),
> incurring an uncomfortable trade-off between scanning cost and update
> latency.
>
> A similar problem exists when scheduling zone transfers, and has been
> solved using the well-known DNS NOTIFY mechanism ([RFC1996]).  This
> mechanism enables a primary nameserver to proactively inform
> secondaries about zone changes, allowing the secondary to initiate an
> ad-hoc transfer independently of when the next SOA check would be
> due.
>
> This document extends the use of DNS NOTIFY beyond conventional zone
> transfer hints, bringing the benefits of ad-hoc notifications to DNS
> delegation maintenance in general.  Use cases include DNSSEC key
> rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY), and quicker
> changes to a delegation's NS record set via NOTIFY(CSYNC).
>
> TO BE REMOVED: This document is being collaborated on in Github at:
> https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-
> dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop-
> generalized-dns-notify).  The most recent working version of the
> document, open issues, etc. should all be available there.  The
> authors (gratefully) accept pull requests.
>
>
>
>
> The IETF Secretariat
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

[Ólafur Guðmundsson]

Parent is authoritative for the existence of the delegation
Child is authoritative for the contents of the delegation

DNS design did not take this into account thus there is no "range" of
Parent only records,
DS is the only record that is explicitly a "violation" of this

IMHO RFC103x should have defined a DEL record in parent and NS in the child
then resolvers could have kept both sides.

Olafur


On Tue, Jul 26, 2022 at 9:22 AM Petr Špaček  wrote:

> 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?
>
> Can people here share their memories of why it is not signed? I wasn't
> doing DNS 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS and SVBC key names.

[Ólafur Guðmundsson]

DoU i.e. DNS over UDP packet size impact,

Olafur


On Wed, Jul 15, 2020 at 1:16 PM Erik Nygren  wrote:

> We landed on 63 in the draft version we just published  (to align with max
> label lengths).
> There's no reason they *need* to be short as they are just in presentation
> form, so their length
> comes down to usability and finding the right words.  The longest
> currently is 15 and it would
> be better to avoid future ones needing to be artificially constrained.  Is
> there a reason we'd
> want to decrease this (eg, to 31)?
>
> On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson 
> wrote:
>
>> How about 2 or 10 ?
>> why do  the names to need to be long ?
>>
>> Olafur
>>
>>
>> On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  wrote:
>>
>>> Or 64?
>>>
>>>
>>>
>>> - Erik
>>>
>>>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>>>
>>> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz >> 40google@dmarc.ietf.org> wrote:
>>>
>>>> How about 255 characters?
>>>>
>>>> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  wrote:
>>>>
>>>>> Can we please have a length limit on key names?  At the moment they
>>>>> could be a billion characters long as they don’t go over the wire.
>>>>> --
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: +61 2 9871 4742 <+61%202%209871%204742>  INTERNET:
>>>>> ma...@isc.org
>>>>>
>>>>> ___
>>>>> 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
>>>
>>
>>
>> --
>> Ólafur Gudmundsson | Engineering Director
>> www.cloudflare.com blog.cloudflare.com
>>
>

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS and SVBC key names.

[Ólafur Guðmundsson]

How about 2 or 10 ?
why do  the names to need to be long ?

Olafur


On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  wrote:

> Or 64?
>
>
>
> - Erik
>
>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>
> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz  40google@dmarc.ietf.org> wrote:
>
>> How about 255 characters?
>>
>> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  wrote:
>>
>>> Can we please have a length limit on key names?  At the moment they
>>> could be a billion characters long as they don’t go over the wire.
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742 <+61%202%209871%204742>  INTERNET:
>>> ma...@isc.org
>>>
>>> ___
>>> 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
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft on delegation revalidation

[Ólafur Guðmundsson]

I read the draft and like it, this is a clear statement of the problem and
good way forward.
I agree with the idea that "all" NS are lame is a good signal to
revalidate,

One idea to throw out here triggered by the first two paragraphs in section
3
Should we recommend that Authoritative servers that are configured for
minimal-response overwrite that on DNSKEY query and include NS RRset if
there is space ?

Olafur



On Fri, Apr 10, 2020 at 9:46 AM Shumon Huque  wrote:

> Hi folks,
>
> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
> consideration:
>
>https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
>
> I mentioned it on the dns-operati...@dns-oarc.net mailing
> list last week, where the topic came up in another thread,
> and there has already been some lively discussion about it
> there. So we recommend reading the thread there:
>
>
> https://lists.dns-oarc.net/pipermail/dns-operations/2020-April/020041.html
>
> There is a range of different behaviors in resolver implementations
> in this respect today, and it would be good if we could agree on
> more commonality.
>
> The main recommendations in the draft are to: (1) deterministically
> prefer the authoritative child NS set over the non-authoritative,
> unsigned, delegating NS set in the parent, (2) revalidate the parent
> delegation at the expiration of the parent NS set TTL, to promptly
> detect when the parent has re-delegated the zone elsewhere (or
> removed the delegation).
>
> These are not new ideas of course. They have been proposed in Vixie
> et. al.'s resimprove draft from 2010, and Wouter Wijngaard's resolver
> mitigations draft from 2009. The Unbound resolver already mostly
> implements this with the 'harden-referral-path' configuration option.
>
> Comments/discussion welcome.
>
> Shumon, Paul, and Ralph.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1

[Ólafur Guðmundsson]

On Tue, Jan 7, 2020, 8:18 AM Viktor Dukhovni  wrote:

> On Tue, Jan 07, 2020 at 02:54:43PM +, Tony Finch wrote:
>
> > The third paragraph of the abstract suggests this is relevant to DNSSEC
> RSASHA1:
> >
> > https://eprint.iacr.org/2020/014
>
> [ I've Bcc'd the authors, perhaps they'll follow up with a comment, or
>   reply to me off-list with permission to quote or repost. ]
>
> > > Therefore, the same attacks that have been practical on MD5 since 2009
> > > are now practical on SHA-1. In particular, chosen-prefix collisions can
> > > break signature schemes and handshake security in secure channel
> > > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those
> type
> > > of applications as soon as possible. We exemplify our cryptanalysis by
> > > creating a pair of PGP/GnuPG keys with different identities, but
> > > colliding SHA-1 certificates. A SHA-1 certification of the first key
> can
> > > therefore be transferred to the second key, leading to a forgery. This
> > > proves that SHA-1 signatures now offers virtually no security in
> > > practice. The legacy branch of GnuPG still uses SHA-1 by default for
> > > identity certifications, but after notifying the authors, the modern
> > > branch now rejects SHA-1 signatures (the issue is tracked as
> > > CVE-2019-14855).
>
> Reading the paper more closely, one finds:
>
> - Section 1.1
>   - Record Computation
> - 2nd paragraph:
>   ... Our attack uses one partial block for the birthday stage,and 9
>   near-collision blocks.
>
> If I'm reading this correctly, the attack requires > 9*160 = 1440 bits
> of complete freedom in the tail of the data to be signed.  But with
> RSASHA1, when a parent domain signs the DS RRset of a child zone, the
>
> https://tools.ietf.org/html/rfc4034#section-3.1.8.1
>
> RR(i) = owner | type | class | TTL | RDATA length | RDATA
>
> elements at the end of the data to be signed have repeating structure in
> the owner, type, class and TTL, which likely mean that just the digest
> of each "DS" RDATA is fully attacker controlled.  This digest must then
> be ~1440 bits long, but that would only be the case if the signer paid
> no attention to the (plausible) validity of the DS RRs, since IIRC none
> of the registered DS digest types produce hashes this long.
>
> https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
>
> If a parent zone does accept arbitrary DS RR payloads in which the hash
> value length is not consistent with the purported digest type, then it
> may well be exposed to the chosen-prefix attack.  Otherwise, it may be
> that checking the hash value to be of the expected length for the digest
> type (160, 256 or 384 bits depending on the digest type) is enough to
> thwart this specific attack.
>
> This does not mean that staying with algorithm 7 (RSASHA1) is a good
> idea, but may buy more time to migrate in an orderly manner.
>
>
Due to the structure of DNS records this is hard to pull off,
the only RR types that are suspect are the ones that can have 1440 of
"garbage" at the end
DS has fixed size so I it can not be used unless someone figures out how
select blocks that include valid DNS record envelopes.
TXT will work if the attacker can encode lengths of the individual strings
into a valid record ==> but who cares about TXT abuse
DNSKEY is with RSA is good candidate for this attack as any DNSKEY RRset
for SHA1 algorithms can be attacked by adding a key that sorts to be last
and is larger than 1440 bits.

Thus anyone that is using RSA algorithm < 8 should think about key or
algorithm rollover

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

Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME

[Ólafur Guðmundsson]

On Thu, Nov 14, 2019 at 6:40 AM Shane Kerr 
wrote:

> Hello,
>
> We just implemented DNAME support on an authoritative server that
> already implements giving an HINFO response to ANY queries, as described
> in RFC 8482.
>
> RFC 8482 is clear about not allowing the HINFO response if there is a
> CNAME record at the name. While no rationale is given in the RFC, it
> seems clear that this is because a CNAME cannot exist with any other
> record, so replying with HINFO might break things, or at least cause
> confusion.
>
> CNAME response is small was the main reason as well as making sure things
keep working.

What is not clear is what to do DNAME subtree responses. (For ANY
> queries that match the name of the DNAME record itself, we apply the
> normal RFC 8482 logic, which seems reasonable.)
>
> I agree not mentioning DNAME in RFC8482 is an omission feel free to file
an errata.


> DNAME provides synthesized CNAME answers, presumably to help resolvers
> that do not support DNAME. On the one hand, if this is important then
> probably performing the normal DNAME logic and returning these
> synthesized records makes sense. On the other hand, it seems unlikely
> that any resolver actually sends ANY queries to authoritative servers.
> However RFC 8482 seems to disagree with this, since the
> resolver/authoritative interaction is specifically called out:
>
> Alternative proposals for dealing with ANY queries have been
> discussed.  One approach proposes using a new RCODE to signal that an
> authoritative server did not answer ANY queries in the standard way.
> This approach was found to have an undesirable effect on both
> resolvers and authoritative-only servers; resolvers receiving an
> unknown RCODE would resend the same query to all available
> authoritative servers rather than suppress future ANY queries for the
> same QNAME.
>
> Our experience at Cloudflare with ANY floods is that most/many resolvers
implement
"exact match" caching i.e. if what is explicitly asked for in this case ANY
then is in cache, then forward.
Thus the only way to shut them down is to give them something to cache in
the "foo.bar. ANY" slot.


> We have chosen to perform CNAME synthesis for ANY queries that match a
> DNAME subtree, based on the logic that if CNAME is special when added by
> hand then it is probably also special when synthesized.
>
> I'm interested in what the DNSOP group thinks the correct behavior is,
> and also if it makes sense to update RFC 8482 to clarify the expected
> behavior for DNAME.
>
> Just file an errata


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


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] proposal: Covert in-band zone data

[Ólafur Guðmundsson]

On Mon, Jul 22, 2019 at 2:00 PM Dan Mahoney  wrote:

> After a hallway conversation with Evan yesterday, I wanted to clarify a
> few things that I came across when working on this.  Point one is the
> use-case of NOTE.  Point two is an argument for the general usefulness of
> a COVERT record.
>
> On NOTE:
>
> I am an admin who uses my zone files as a source of truth -- which
> include comments, versioning, and formatting.  (I also commit to version
> control, and there's a $Id: $ tag in my zonefiles.)
>
> I'd like the ability to have some degree of human-intended metadata
> survive an AXFR, to be able to promote a slave copy of a zone to being
> master, promote versioning, and keep my zonefiles readable within my
> processes.  I am not suggesting NOTE be anything but exactly what its name
> implies: not a hook for some kind of inter-server transfers or private
> keys, just things like "remove after 1/1/2020" or "allocated to group foo"
> or even "generated from config DB on $date".  I especially intend to
> state, perhaps with stronger language, that NOTE SHOULD NOT used for
> things intended to be machine-parsed the way we've overloaded TXT.
>
> I'm an operator.  Among my credentials: I operate personal infrastructure,
> ISC's infrastructure, and a nontrivial amount of the infrastructure for
> the root zone.  This is the operational input I'm told the IETF community
> craves and suggests an issue of not getting until after a standard passes..
>
>
Dan,
I think all of this makes sense, what does not make sense is to stuff this
into old "AXFR/IXFR" semantics.
The draft is already changing how "upstream" deals with "downstream" in
this proposal.
My suggestion is to take a step back and say we have outgrown AXFR  and we
need better mechanism to sync
various servers.
Lets start work on a new "SYNC Name servers" protocol that can meet modern
requirements
My list of features that I would like to see:
   -- DNSSEC awareness (MIXFR)
  -- Long lived TLS connections that allow
--- updates of multiple zones
--  adding and removing of zones
-- Configuring service parameters: online-keys, ACL's, logging
status ..
-- even send back logging information

This would allow us to get rid of Notify, catalog zones, and few other
warts that have been added on over the years.

Olafur



> Best,
>
> -Dan
>
> On Sat, 6 Jul 2019, Evan Hunt wrote:
>
> > Colleages,
> >
> > Some years ago, Dan Mahoney and I submitted a draft describing a proposed
> > mechanism for storing confidential zone comments alongside normal zone
> > data - a NOTE RR, which would be transferrable from primary to secondary
> > servers, but not accessible to ordinary DNS queries.  It generated some
> > iniital interest, but not much momentum, and we let the proposal lapse.
> >
> > More recently, Witold Krecicki had a very similar idea for a mechanism to
> > disseminate private key data between primary and secondary servers.  We
> > talked it over and decided to expand the NOTE record semantics into a
> > generic method for storing and transferring covert in-band zone data.
> >
> > The generic mechanism is described in draft-krecicki-dns-covert-00. It
> > calls for the allocation of a range of "Covert-RR" type code values,
> > which would have restrictions on their dissemenination.  A primary server
> > implementing Covert-RR types must not allow them to queried, nor to be
> > transerred to a secondary server unless that server indicates via an EDNS
> > option that it *also* understands Covert record semantics and will not
> > transfer the data to any peer that doesn't.
> >
> > The original NOTE RR draft has been shrunk down and rewritten as a
> > proposed use case for Covert RR's.  Additional use cases will be coming
> > in the future; in particular, draft-pusateri-dnsop-update-timeout seems
> > like it might be a good candidate.
> >
> > Details are below. Please have a look.  Thanks!
> >
> > 
> > Name: draft-krecicki-dns-covert
> > Revision: 00
> > Title:Domain Name System (DNS) Resource Record types for
> transferring covert information from primary to secondaries
> > Document date:2019-07-06
> > Group:Individual Submission
> > Pages:6
> > URL:
> https://www.ietf.org/internet-drafts/draft-krecicki-dns-covert-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-krecicki-dns-covert/
> > Htmlized:   https://tools.ietf.org/html/draft-krecicki-dns-covert-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-krecicki-dns-covert
> >
> >
> > Abstract:
> >The Domain Name System (DNS) Resource Record TYPEs IANA registry
> >reserves the range 128-255 for Q-TYPEs and Meta-TYPEs [RFC6895] -
> >Resource Records that can only be queried for or contain transient
> >data associated with a particular DNS message.
> >
> >This document reserves a range of RR TYPE numbers for Covert-TYPEs -
> >types that are an integral part of 

Re: [DNSOP] RFC 2845bis draft

[Ólafur Guðmundsson]

I think this is a good clarification
Olafur


On Thu, Feb 28, 2019 at 8:53 AM Peter J. Philipp  wrote:

> Hi again,
>
> Well I ended up fixing it myself yesterday through a lot of trial and
> error and finally understanding the
>
> RFC.  I recommend the following change to make it easier for future
> implementors in the 2845bis draft:
>
> Section 6.4 says:
>
> The first envelope is processed as a standard answer, and subsequent
> messages have the following digest components:
>
> I would rewrite that as:
>
> The first envelope is processed as a standard answer (see section 6.2),
> and subsequent messages have the following digest components:
>
> With the referal to section 6.2, a hasty eye can catch what a "standard
> answer" is and assumptions are left out.
>
> BTW I'm working with this draft document:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/?include_text=1
>
> Best Regards,
>
> -peter
>
>
> On 2/27/19 9:21 AM, Peter J. Philipp wrote:
> > Hi,
> >
> > I'm in contact with the original RFC 2845 authors for clarifications
> > on what is meant in section 4.4 for the meaning of "Prior MAC
> > (running)".  In the bis draft this is in section 6.4 and seems
> > unchanged.  I'm having a hard time understanding this as an
> > implementor, this is an area that needs clarification I believe.
> >
> > Would you like to see any results that I glean from the authors so
> > that this can be put on the bis draft?
> >
> > Best Regards,
> >
> > -peter
> >
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Guðmundsson]

Tim,
I have reviewed the document and it is ready for publication

Olafur


On Tue, Oct 2, 2018 at 2:51 PM Tim Wicinski  wrote:

>
> The chairs and the authors of this document feel that the
> document is in solid shape to proceed to WGLC.
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-algorithm-update
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
>
> The Current Intended Status of this document is: Proposed Standard
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  16
> October 2018
>
> thanks
> tim
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Ólafur Guðmundsson]

On Mon, Sep 10, 2018 at 11:27 PM, Mirja Kühlewind 
wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
>
>
> --
> COMMENT:
> --
>
> I'm wondering if it would make sense to provide stronger guidance that the
> conventional ANY response SHOULD be provided if TCP is used as TCP already
> provides a retrun routability proof...? Also maybe provide a refernce to
> RFC7766?


This has nothing to do with "retrun routability"  if big answers are given
to resolver via TCP then the resolver can be used as amplifier and there
Millions of those on the net.

IMHO the only time big ANY answer CAN be returned is when the connection is
authenticated and approved.


> And one smallish comment: Would it make sense to refer
> draft-ietf-dnsop-terminology-bis-09 (or actually the soon to be new RFC)
> instead of RFC7719?
>
>
Hope this happens by RFC-editor or in AUth48

Olafur




-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Ólafur Guðmundsson]

On Tue, Sep 11, 2018 at 10:27 AM, Adam Roach  wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for the work that went into the mechanism, and especially to the
> early
> deployers who found issues to be addressed. I have a small handful of
> comments
> that the authors may wish to address prior to advancing the document to
> publication.
>
> 
> ---
>
> §4.1:
>
> >  A DNS responder which receives an ANY query MAY decline to provide a
> >  conventional ANY response
>
> Nit: "A DNS responder that receives..."
>
Noted


>
> 
> ---
>
>

> §4.2:
>
> >  The CPU field of the HINFO RDATA SHOULD be set to RFC
>
> Then, in §5:
>
> >  A DNS initiator MAY suppress queries with QTYPE=ANY in the event that
> >  the local cache contains a matching HINFO resource record with
> >  RDATA.CPU field, as described in Section 4.
>
> This looks like it's asking for a comparison. If such is the case, I think
> you
> need to indicate whether the value being compared is done so in a
> case-sensitive
> fashion. You probably also want to be pretty explicit about the literal
> string
> value to be used (e.g., be clear that the value doesn't contain a space).
>
>
Good point
it should just return the HINFO no matter what is in it
when we started with this document we had no numbers on usage of HINFO
but now we know it historical use is "almost none"


> 
> ---
>
> §4.2:
>
> >  The
> >  specific value used is hence a familiar balance when choosing TTL for
> >  any RR in any zone, and be specified according to local policy.
>
> Nit: This sentence appears to be missing a word. Perhaps "...and will be
> specified..." or similar.
>
> Noted


> 
> ---
>
> §4.2:
>
> >  In particular, systems SHOULD NOT rely upon the HINFO
> >  RDATA described in this seection to distinguish between synthesised
> >  and non-synthesised HINFO RRSets.
>
> Nit: "section"
>
> More substantive comment: Since the CPU field SHOULD indicate this
> document,
> implementations could reasonably infer that the HINFO RRSet is synthesized
> based
> on its value, right? That seems worth mentioning here.
>

overkill


>
> 
> ---
>
> §5:
>
> >  A DNS initiator which sends a query with QTYPE=ANY and receives a
>
> Nit: "...initiator that sends..."
>
>
> noted




-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Ólafur Guðmundsson]

On Tue, Sep 11, 2018 at 1:48 AM, Benjamin Kaduk  wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
>
>
> --
> COMMENT:
> --
>
> I am balloting YES, because it is good to have these techniques available,
> but
> I also have some comments that I would like to see addressed or rebutted.
>
> The Shepherd writeup does not say why 1034/1035 are not mentioned in the
> Abstract.  Also, the phrase "updates [103x] by" does not appear in the
> Introduction, leaving just section 7 to describe the changes.
>

--->
Section 1 has following text

  The DNS specification [RFC1034] [RFC1035] does not include specific
   guidance for the behaviour of DNS servers or clients in this
   situation.  This document aims to provide such guidance.


Is that sufficient for readers ?


> The document doesn't really make it clear whether the "[t]he operator []
> might choose not to respond to such queries" is restating an existing
> specification from some other document or making a new statement.
>
> It is stating an operating practice

Section 1.1
>
> As Mirja notes, draft-ietf-dnsop-terminology-bis is likely to replace 7719
> by the time this document's publication process finishes.
>
> If that is published I hope RFC editor Auth48 phase will catch it


> Section 2
>
> It seems like the intended takeaway here is that there's a balance or
> tradeoff to had between the "good" uses (efficiency of getting all desired
> data at once) and "bad" ones (amplification), with mining for zone data
> being a "dual-use technology".  The text doesn't really help the reader
> reach that conclusion, though -- a few extra words at the start of each
> paragraph might help, like the "legitmiately used" in the very first one,
> or "On the other hand, ANY queries are frequently abused to [...]" might
> help set the intended tone.
>
>
IMHO there is no "good" use of ANY in the world but by the operator of the
server,
all other uses are based on misunderstanding or abuse,
others disagree.
Since this document was started the abuse of ANY has decreased against the
operators that have adopted the techniques in the document
but at the same time moved more to operators that do not support it.

Section 4
>
> Should "return a conventional ANY response" be listed or mentioned here?
>
> IMHO no


> Section 4.2
>
>[...] The
>specific value used is hence a familiar balance when choosing TTL for
>any RR in any zone, and be specified according to local policy.
>
> nit: Is there a missing word or three before "be"?
>
"to be " ?

>
>DATA described in this seection to distinguish between synthesised
>and non-synthesised HINFO RRSets.
>
> nit: "section"
>
good catch


>
> I'm a little surprised to see a "SHOULD NOT" for relying the RDATA 'CPU'
> contents of "RFC" for the final RFC number, since I can't come up with
> an other reason why that CPU value would be used.  But I do not object to
> it.
>
> thanks


> Section 4.4
>
> Why are we enumerating transports instead of talking about the properties
> they provide?  We've got multiple new transports in the works, and it would
> be a shame to ignore them out of the gate.
>
>
> This is a good point DNS people have in the past only thought in the
context of two transports UDP and TCP
but the world is changing.
We will work on text that replaces TCP with "transport properties" as
Spencer has suggested.



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Ólafur Guðmundsson]

On Thu, Sep 13, 2018 at 7:15 AM, Eric Rescorla  wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
>
>
> --
> COMMENT:
> --
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D5482
>
>
>
> COMMENTS
> S 3.
> >  processing in order to send a conventional ANY response, and
> avoiding
> >  that processing expense might be desirable.
> >
> >   3.  General Approach
> >
> >  This proposal provides a mechanism for an authority server to signal
>
> Nit: authoritative.
>
> Noted,


>
> S 4.3.
> >  applications may be satisfied by this behaviour, the resulting
> >  responses in the general case are larger than the approaches
> >  described in Section 4.1 and Section 4.2.
> >
> >  As before, if the zone is signed and the DO bit is set on the
> >  corresponding query, an RRSIG RRSet MUST be included in the
> response.
>
> This section seems to be one possible algorithm for implementing 4.1.
> What am I missing?
>
> The difference is this approach will frequently return more and larger
answers than 4.1
but you are right 4.3 is an expansion of 4.1



> S 7.
> >  It is important to note that returning a subset of available RRSets
> >  when processing an ANY query is legitimate and consistent with
> >  [RFC1035]; it can be argued that ANY does not always mean ALL, as
> >  used in section 3.2.3 of [RFC1035].  The main difference here is
> that
> >  the TC bit SHOULD NOT be set on the response indicating that this is
> >  not a complete answer.
>
> This is a bit grammatically awkward, perhaps "response, thus
> indicating"
>
>
> Sounds good
 thanks



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alexey Melnikov's No Objection on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Ólafur Guðmundsson]

On Thu, Sep 13, 2018 at 2:56 AM, Alexey Melnikov 
wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
>
>
> --
> COMMENT:
> --
>
> I generally like this document, but I find it to be too wishy washy
> because of
> use of SHOULDs instead of MUSTs. I would have liked a bit more guidance
> early
> on about different choices or at least a statement that this is a rarely
> used
> feature and thus any choice is reasonably good.
>
> Alexey
you have summarized correctly the translation from the earliest version of
the document to something the WG could agree on.
The choices are dictated by capabilities and implementation approaches,
 i.e. HINFO response can be used for all unsigned zones and DNSSEC signed
zones if the server does online-signing,
the "one RRset" response can be used for all zones but is hard for servers
that fetch RRsets from DB.

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[Ólafur Guðmundsson]

Ted,
Would it be acceptable to just do
s/TCP/Connection oriented Transport/

Olafur



On Tue, Aug 21, 2018 at 12:48 PM, Ted Hardie  wrote:

> Howdy,
>
> I note that section 4.4 calls out TCP transport and says this:
>
> 4.4.  Behaviour with TCP Transport
>
>A DNS responder MAY behave differently when processing ANY queries
>received over different transport, e.g. by providing a conventional
>ANY response over TCP whilst using one of the other mechanisms
>specified in this document in the case where a query was received
>using UDP.
>
>Implementers SHOULD provide configuration options to allow operators
>to specify different behaviour over UDP and TCP.
>
> Given that we now have multiple available transports for the DNS (TLS,
> DTLS, HTTPS), it may be worth generalizing the heading and updating the
> text to handle those cases.  I suspect that involves a bit more work than
> just adding the transport names to the paragraph, unfortunately.  All of
> the newer transports provide return routability, which means, as for TCP,
> that ANY doesn't create DNS amplification for them.  But they also have
> other characteristics (e.g. channel confidentiality and/or additional
> caching layers) that may make for other decision points.  Some text on that
> would be useful, at least in my opinion.
>
> regards,
>
> Ted Hardie
>
> On Tue, Aug 21, 2018 at 8:59 AM, The IESG  wrote:
>
>>
>> The IESG has received a request from the Domain Name System Operations WG
>> (dnsop) to consider the following document: - 'Providing Minimal-Sized
>> Responses to DNS Queries that have QTYPE=ANY'
>>as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> i...@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be
>> sent to i...@ietf.org instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>The operator of an authoritative DNS server might choose not to
>>respond to such queries for reasons of local policy, motivated by
>>security, performance or other reasons.
>>
>>The DNS specification does not include specific guidance for the
>>behaviour of DNS servers or clients in this situation.  This document
>>aims to provide such guidance.
>>
>>This document updates RFC 1034 and RFC 1035.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>>
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Guðmundsson]

Support adoption

this is actually a needed document, due to the fact that many "high value
zones" want to use multiple vendors.

   Olafur



On Fri, Jul 6, 2018 at 8:26 PM, 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
>
> The draft is available here: https://datatracker.ietf.org/
> doc/draft-huque-dnsop-multi-provider-dnssec/
>
> 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.
> The authors will be at the next meeting to address questions or concerns.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 20 July 2018
>
> Thanks,
> Tim
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-13.txt

[Ólafur Guðmundsson]

Hi
i read this document over with fresh eyes and tried to ignore any history.

Summary: Publication considered harmful

Reasons: This document calls itself "Security Considerations" but in
reality all it is covering is "Publication considerations by Authority"
the document does not cover at all the consumption of RFC5011 events by
resolvers which IMHO are the more important part of the protocol.

 Olafur


On Mon, Jul 16, 2018 at 8:49 AM,  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 Operations WG of the
> IETF.
>
> Title   : Security Considerations for RFC5011 Publishers
> Authors : Wes Hardaker
>   Warren Kumari
> Filename: draft-ietf-dnsop-rfc5011-
> security-considerations-13.txt
> Pages   : 20
> Date: 2018-07-16
>
> Abstract:
>This document extends the RFC5011 rollover strategy with timing
>advice that must be followed by the publisher in order to maintain
>security.  Specifically, this document describes the math behind the
>minimum time-length that a DNS zone publisher must wait before
>signing exclusively with recently added DNSKEYs.  This document also
>describes the minimum time-length that a DNS zone publisher must wait
>after publishing a revoked DNSKEY before assuming that all active
>RFC5011 resolvers should have seen the revocation-marked key and
>removed it from their list of trust anchors.
>
>This document contains much math and complicated equations, but the
>summary is that the key rollover / revocation time is much longer
>than intuition would suggest.  This document updates RFC7583 by
>adding an additional delays (sigExpirationTime and
>timingSafetyMargin).
>
>If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to
>advertise this DNSKEY as a new Secure Entry Point key for use as a
>trust anchor, you probably don't need to read this document.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-
> security-considerations/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-
> security-considerations-13
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-
> considerations-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-
> security-considerations-13
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?

[Ólafur Guðmundsson]

It is a random label on the left that some random resolvers may generate
answers for,
thus it is not SUN (i.e. answer B)

Olafur


On Mon, May 14, 2018 at 2:10 PM, Warren Kumari  wrote:

> Dear DNSOP,
>
> The KSK-Sentinel document (
> https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-12) makes
> use
> of the (leftmost) labels root-key-sentinel-is-ta- and
> root-key-sentinel-not-ta-. If a validating recursive resolver
> sees
> these labels, it performs special handling.
>
> Great, everyone is nodding along so far...
>
> Gulp. Now for the question: Is root-key-sentinel-is-ta- an
> RFC6761
> "Special-Use Domain Name"?
>
> The authors are in disagreement - RFC6761 talks about "Special-Use Domain
> *Names*", not "Special-Use Domain *Labels*", but Stuart has said that it
> wasn't intended to be only for TLDs / pseudo-TLDs / things starting at the
> top of the tree.
> My view is that this probably is a SUN; it is a name which requires special
> handling.
> My co-authors (rightly) point out that "name" is poorly defined, this is a
> label not a name, RFC6761 is vague in it's use of terminology, and all of
> the examples and entries are right-anchored.
>
> We've crafted answers to "the 7 questions" from RFC 6761 below; we don't
> care which option the WG selects (we have the text and revisions are free),
> but we (and I'm assuming the WG!) desperately don't want this to turn into
> another extended discussion on SUN / names vs identifiers vs identities vs
> contexts / who has policy control over root / internet governance / etc.
>
> So, please, *clearly* state if you think that this:
> A: is a SUN
> B: is not a SUN
>
> RFC 8244 [0] was fun, but I'm not sure how much more fun I can handle; we'd
> love *clear* guidance by next Friday (May 25th)
>
> 'So don't delay, act now, supplies are running out
> Allow, if you're still alive, six to eight years to arrive
> And if you follow, there may be a tomorrow
> But if the offer's shunned
> You might as well be walking on the SUN"
>  -- Smash Mouth
>
>
> Note: We are answering the questions as asked, and so use 6761 terminology:
> --
> IANA Considerations
>
> The IANA is requested to make the following entries in the Special Use
> Domain Names registry
> (https://www.iana.org/assignments/special-use-domain-names/special-use-
> domain-names.xhtml) referencing this RFC
>
> root-key-sentinel-is-ta-.*  RFC 
> root-key-sentinel-not-ta-.* RFC 
>
> Domain Name Reservation Considerations
>
> This refers to the set DNS names where the left-most label matches the
> specified patterns.
> The answers to the seven questions listed in [RFC6761] are as follows:
>
> 1: Users:
> Human users are not expected to use or recognize these names as
> special, other than those who wish to perform testing of their DNS
> resolution environment. It is expected that the majority of the testing
> will be performed through automated means (e.g: using JavaScript to
> cause the user's browser to trigger a DNS lookup), and so the majority
> of users will never see these.
>
> 2.  Application Software:
> No specified behavior is expected of application software.
>
> 3. Name Resolution APIs and Libraries:
>Name resolution libraries are not expected to recognize these names as
>special.
>
> 4.  Caching DNS Servers:
>Caching DNS servers which perform DNSSEC validation are
>expected to treat these labels specially, as described in this document.
>
> Caching DNS servers which are NOT performing DNSSEC
> validation are not expected to treat these names as special.
>
> 5.  Authoritative DNS Servers:
> Authoritative domain name servers are not expected to undertake any
> altered behaviour for these names.
>
> 6.  DNS Server Operators:
> These reserved Special-Use Domain Name have no potential impact on
> DNS server operators.
>
>
> 7.  DNS Registries/Registrars:
> These names have a special behaviour only when used as the
> left-most
> label in a name resolution query. They have no special significance
> in any other context and are not required to be treated differently
> in the context of registeries and registrars.
> --
>
>
> W
>
> [0]: The Abstract of RFC 8244 says:
> "The policy defined in RFC 6761 for IANA registrations in the
> "Special-Use Domain Names" registry has been shown, through
> experience, to present challenges that were not anticipated when RFC
> 6761 was written.
> 
> This document should be considered required reading for IETF
> participants who wish to express an informed opinion on the topic of
> Special-Use Domain Names."
>
> --
> I don't think the execution is relevant when it was obviously a bad idea in
> the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
> ---maf
>
> 

Re: [DNSOP] Phishing? was Fwd: nthpermutation

[Ólafur Guðmundsson]

Mike,

This is a domain extortion attempt, they want you to buy the domain at
inflated price
https://security.stackexchange.com/questions/56290/is-this-domain-registration-service-email-a-scam#56304

Olafur


On Sun, Mar 25, 2018 at 11:04 PM, Michael StJohns 
wrote:

> Apologies for dumping this here, but I figured if anyone had a clue they'd
> probably be on this list. Is anyone familiar with mopo-io.com.cn?   Is
> this a legitimate email (or company)?  If not, its one of the better
> phishing emails I've seen.
>
> Thanks - Mike
>
>
>  Forwarded Message 
> Subject: nthpermutation
> Date: Thu, 22 Mar 2018 11:59:50 +0800
> From: Sharon Han  
> To: msj  
>
> (Letter to the President or Brand Owner, thanks)
>
> Dear Sir/Madam,
>
> We are the department of Asian Domain Registration Service in China. I
> have something to confirm with you. We formally received an application on
> March 22, 2018 that a company which self-styled "Gulf East Ltd " were
> applying to register "nthpermutation" as their Brand Name and some domain
> names through our firm.
>
> Now we are handling this registration, and after our initial checking, we
> found the name were similar to your company's, so we need to check with you
> whether your company has authorized that company to register these names.
> If you authorized this, we will finish the registration at once. If you did
> not authorize, please let us know within 5 workdays, so that we will handle
> this issue better. After the deadline we will unconditionally finish the
> registration for "Gulf East Ltd ". Looking forward to your prompt reply.
>
>
>
> Best regards,
>
> Sharon Han
> Tel: 0086.5516349 1192
> Fax: 0086.5516349 1192
> Address:No.313, Changjiang Zhonglu, Hefei 23 China
>
> ___
> 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] Question about usage of ip6.arpa and in-addr.arpa

[Ólafur Guðmundsson]

On Tue, Mar 13, 2018 at 11:16 AM, Joe Abley 
wrote:

> On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker <
> rol...@letsencrypt.org> 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.
>
> ^^ Joe spoke the truth

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Ólafur Guðmundsson]

On Thu, Jan 11, 2018 at 11:26 AM, 神明達哉 <jin...@wide.ad.jp> wrote:

> At Wed, 10 Jan 2018 17:05:00 -0800,
> Ólafur Guðmundsson <ola...@cloudflare.com> wrote:
>
> > >That is, it answers as if it is authoritative and the DS record does
> > >not exist.  DS-aware recursive nameservers will query the parent
> zone
> > >at delegation points, so will not be affected by this.
> > >
> > I hate having my own RFC thrown at me,
> > but it may or may not apply as there is another corner case that I/WG did
> > not consider,
> > what if the NameServer is authoritative for a zone above the parent.
> > In this case it has to select does it answer from the closest zone that
> can
> > answer DS record or
> > from the zone it self.
> >
> > In the spirit of being helpful to recursive resolvers the right answer
> IMHO
> > is the referral from the
> > zone above the query name.
>
> I'm not sure if I understand you so please let me be more explicit.
> Are you talking about the so-called grandparent problem case, like the
> case of this thread?
>

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Ólafur Guðmundsson]

On Fri, Jan 5, 2018 at 10:27 AM, 神明達哉  wrote:

> At Thu, 4 Jan 2018 08:12:26 +1100,
> Mark Andrews  wrote:
>
> > The reply also has to work for STD13 clients which already know
> > about the child zone. The NODATA response is the correct one despite
> > it requiring more work for a DNSSEC client.
>
> Section 2.2.1.1 of RFC 3658 also explains that point:
>
>[...]  As these queries are only expected to originate
>from recursive nameservers which are not DS-aware, the authoritative
>nameserver MUST answer with:
>
>   RCODE: NOERROR
>   AA bit:set
>   Answer Section:Empty
>   Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
>
>That is, it answers as if it is authoritative and the DS record does
>not exist.  DS-aware recursive nameservers will query the parent zone
>at delegation points, so will not be affected by this.
>
>
I hate having my own RFC thrown at me,
but it may or may not apply as there is another corner case that I/WG did
not consider,
what if the NameServer is authoritative for a zone above the parent.
In this case it has to select does it answer from the closest zone that can
answer DS record or
from the zone it self.

In the spirit of being helpful to recursive resolvers the right answer IMHO
is the referral from the
zone above the query name.

  Olafur


> --
> JINMEI, Tatuya
>
> ___
> 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] Measuring DNS TTL Violations in the wild

[Ólafur Guðmundsson]

On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane <dwess...@verisign.com>
wrote:

>
> > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson <ola...@cloudflare.com>
> wrote:
> >
> > I strongly disagree with your "terminology", TTL is a hint about maximum
> caching period, not a demand or a contract.
>
> You say its just a hint.  If you put a TTL of 1 hour on your data, and I
> have a recursive name server that reuses it for 2 hours, 12 hours, 5
> days... thats okay?
>
> If its just a hint then we are we spending all this effort on "serve
> stale"?
>
> DW
>
>
Strictly speaking yes, it is the same as when a Secondary does not update
the zone for a long time.
DNS is not a strict coherency protocol, thus playing  loose with the time
things are with in reason is ok.
Stretching TTL from 1 Hour to 1 day is IMHO BAD, doing it for 10% or 10
minutes is fine.
We are getting into religion here, the original poster called people that
cap TTL's Heretics,
I disagree with that labeling of myself and others that are applying sane
caps.

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

Re: [DNSOP] Measuring DNS TTL Violations in the wild

[Ólafur Guðmundsson]

I strongly disagree with your "terminology", TTL is a hint about maximum
caching period, not a demand or a contract.
A resolver can at any time for any reason discard cached entries.
Many Authoritative operators have "unreasonable" TTL's like less than 10
seconds or multiple days and I see no reason why resolvers do not
apply minimal and/or max caching rules that are reasonable.

Olafur




On Fri, Dec 1, 2017 at 3:48 PM, Giovane C. M. Moura 
wrote:

> Hi,
>
> In the light of the recent discussions on TTL violations and server
> stale here on the list, I decided to take a look on how often resolvers
> perform TTL violations in the wild.
>
> To do that, I used almost 10K Ripe Atlas probes. You can find a report
> and datasets at:
>
> https://labs.ripe.net/Members/giovane_moura/dns-ttl-
> violations-in-the-wild-with-ripe-atlas-2
>
> Now, what was more scary were the violations that *increased* the TTL of
>  of RR some more than 10x. That may put users at risk of service domains
> that may have been already taken down.
>
> /giovane
>
> ps: related thread on oarc list at :
> https://lists.dns-oarc.net/pipermail/dns-operations/2017-
> November/017039.html
>
> ___
> 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] [Ext] Re: Resolver behaviour with multiple trust anchors

[Ólafur Guðmundsson]

On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters  wrote:

> On Wed, 8 Nov 2017, Edward Lewis wrote:
>
> This is why the guidance in "Protocol Modifications for the DNS Security
>> Extensions" leads to "any" chain. "Clarifications and Implementation Notes
>> for DNS Security (DNSSEC)" opens the possibility that knobs can be
>> included, which is the prerogative of the implementer to build and the
>> operator to use (local policy).  I see these two documents as compatible.
>>
>
> "prerogative of the implementer" canont apply to how one defines trust
> in a protocol. You can't have two implementations make different
> trust decisions, especially as most endusers don't control their
> resolver.
>
>
Paul,

I have been thinking about what you said and why it is perfectly valid, but
that I think it is wrong.
The issue here is three fold IMHO
Operator is using split-DNS i.e. internal and external
Operator is using the SAME name space for both views  i.e. foo.example.com
can exist in both name spaces with different values.
Operator is using DIFFERENT keys to sign the two namespaces.

We have no way at the moment to express  which namespace a "name" comes
from thus you want to give preference to the "internal" namespace for users
of that namespace

The purist in me says this is bad setup, the practical part of me says "you
get what you ask for" i.e. IETF failed to write guidelines for Spit-DNS
thus we should expect things like this.
Either way I think the use of Different Key is what we should strongly
discourage as that makes the other problems go away.

The bottom line is that one can choose to abide by a rule of "if a trust
>> anchor is there, ignore other chains" but recall that the choice is made by
>> the validator operator, not the zone administrator, as the validator
>> operator is also responsible for keeping the trust anchors current and
>> accurate, it is their own failure if that is not the case, and they
>> exclusively have the ability to fix a conflict.
>>
>> The bottom line is that the zone administrator doesn't get a say - it's
>> all up to the validator operators.
>>
>
> It's up to neither. You cannot retroactively argue that hardcoding trust
> anchors is an option can that be ignored by an implementation.
>
> knot had a bug some people thought would be a nice fallback recovery
> feature to a failed rollover procedure. knot should just be fixed. This
> really does not require an RFC update.
>
> Paul
>
> Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Resolver behaviour with multiple trust anchors

[Ólafur Guðmundsson]

There are three ways to treat this case:
Any-TruestedKey-works
ConfiguredKey-trumps-DS
DS-trumps-configuredKey

I think the Last one is the "most" correct from an operational expectation,
but the first one is least likely to run into errors,
But I suspect the middle one is implemented

Olafur


On Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller 
wrote:

> Hi,
>
> Together with my colleagues I have been stumbling upon a, for me, unclear
> case when validating trust anchors.
>
> Assuming that a resolver has enabled DNSSEC validation and has the root
> keys configured.
> Additionally, it has configured manually a trust anchor for a TLD (that
> has also published its DS in the root zone).
> Now, for example due to a key rollover at the TLD, the manually configured
> trust anchor of the TLD does not match the DS in the root anymore.
>
> How should a resolver treat the signatures of this TLD?
> The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures
> of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035
> that describe how resolvers should behave in this case.
> Knot resolver treats them as NOERROR (according to the developers).
> If we interpret section 4.3 of RFC 4035 then we would have assumed that
> the signature must be treated as secure.
>
> Did we miss something, or is there indeed clarification needed?
>
> — Moritz
>
>
>
>
> ___
> 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-refuse-any - why not NOTIMP?

[Ólafur Guðmundsson]

This was the original proposal,
the drawback is that resolvers to not cache the answer, and to make things
worse they ask ALL NS addresses for listed domain
thus it acts as a DDoS against the domain in question.

Olafur


On Mon, Aug 7, 2017 at 7:14 AM, Ray Bellis  wrote:

> Having looked at this a few months ago when one of our partners was
> (briefly) returning NOTIMP for ANY queries, I find myself wondering why
> this isn't discussed in the draft?
>
> The draft does talk about *new* RCODEs, but not existing ones.
>
> My reading of RFC 1035 is that it would be a perfectly appropriate
> response from a server that doesn't support ANY.
>
> Unfortunately the retry semantics of DNS are not well specified and
> therefore implementation differences may occur.  If as a result NOTIMP
> is really not usable then IMHO this should also be documented.
>
> Ray
>
> ___
> 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 draft: Algorithm Negotiation in DNSSEC

[Ólafur Guðmundsson]

On Thu, Jul 20, 2017 at 10:45 AM, Shumon Huque <shu...@gmail.com> wrote:

> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson <
> ola...@cloudflare.com> wrote:
>>
>>
>> I disagree, if a zone operator selects "less-than" common algorithm they
>> do that at their own risk,
>> if the risk is not acceptable then it should dual sign
>>
>
> Yes. The point I was trying to make is that DANE sites (and probably
> others if they care about security) cannot afford to fail open. So they
> have to dual sign if they can stomach the costs, or delay deploying new
> algorithms for a long time. This draft is intended to (eventually) make the
> dual signing case easier to deal with operationally.
>


The point I'm making is that the proposed medicine is worse than the
ailment.

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

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

[Ólafur Guðmundsson]

On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque <shu...@gmail.com> wrote:

> On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson <ola...@cloudflare.com
> > wrote:
>
>> Shumon,
>>
>> In section 5 your draft says:
>>
>>If an Authoritative Server has no algorithms in common with the
>>Preferred Algorithms list in the incoming query, it MUST send back a
>>SERVFAIL response (Response Code 2).  This response MUST contain the
>>list of algorithms supported by the server in the EDNS0 Preferred
>>Algorithms option.
>>
>>
>>
>> This is a HORRIBLE violation of the DNSSEC spirit. All validators are
>> supposed to fail to open when they can not validate algorithm the signature
>> is generated by.
>>
>
> As I tried to explain in my previous note to Paul Wouters - fail open is
> horrible for DANE. Protocols can evolve. If DNSSEC had algorithm
> negotiation from the beginning, fail open would not have been necessary.
> This fail open behavior frequently takes people not in the DNSSEC club by
> complete surprise. I've lost track of how many "WTF" moments I've had to
> explain to other people about this behavior. This proposed behavior change
> is also signaled, not unilateral. But let's debate ...
>
>
I disagree, if a zone operator selects "less-than" common algorithm they do
that at their own risk,
if the risk is not acceptable then it should dual sign


> Section 6
>> This is hopeless algorithm, that goes against the justification of the
>> document.
>> basically it may force validating resolvers to fetch the answers multiple
>> times for each TTL; once without DNSSEC, then for first algorithm, then for
>> all algorithms ==> right now validating resolvers only fetch once with
>> DNSSEC enabled.
>>
>
> There has to be some initial fallback behavior with costs. This is not
> uncommon in new protocols. Think about longer term benefits.
>

After thinking about this a few times,  I still see no future benefits.

>
>
>> This is a HORRIBLE violation of the DNSSEC spirit. All validators are
>> supposed to fail to open when they can not validate algorithm the signature
>> is generated by.
>>
>
> See previous discussion.
>
>
>>
>> overall this draft main idea: DNS publishers should sign with more
>> algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set
>> ==> better for DDoS
>>
>
> DNSSEC already has a DDoS reputation - this isn't going to make things
> that much worse. Also DNSSEC has already been way surpassed in this area by
> NTP/SNMP etc. What we should be working on is deployment of proper protocol
> level mitigations, like Cookies, etc.
>
>

I'm not sold on Cookies solving real problems.
The way to get away from that reputation  is online signing of negative
answers and retirement of all RSA signatures (no I'm not promoting NSEC5),
Online signing with NSEC works just fine.

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

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

[Ólafur Guðmundsson]

Shumon,

In section 5 your draft says:

   If an Authoritative Server has no algorithms in common with the
   Preferred Algorithms list in the incoming query, it MUST send back a
   SERVFAIL response (Response Code 2).  This response MUST contain the
   list of algorithms supported by the server in the EDNS0 Preferred
   Algorithms option.



This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

Section 6
This is hopeless algorithm, that goes against the justification of the
document.
basically it may force validating resolvers to fetch the answers multiple
times for each TTL; once without DNSSEC, then for first algorithm, then for
all algorithms ==> right now validating resolvers only fetch once with
DNSSEC enabled.


This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

overall this draft main idea: DNS publishers should sign with more
algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set
==> better for DDoS

Olafur



On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque  wrote:

> Hi folks,
>
> We've posted a new draft on algorithm negotiation which we're hoping to
> discuss at IETF99 (and on list of course). I've discussed this topic with
> several folks at DNS-OARC recently.
>
> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Algorithm Negotiation in DNSSEC
> Authors : Shumon Huque
>   Haya Shulman
>  Filename: draft-huque-dnssec-alg-nego-00.txt
>  Pages   : 9
>  Date: 2017-07-03
>
> Abstract:
>This document specifies a DNS extension that allows a DNS client to
>specify a list of DNSSEC algorithms, in preference order, that the
>client desires to use.  A DNS server upon receipt of this extension
>can choose to selectively respond with DNSSEC signatures using the
>most preferred algorithm they support.  This mechanism may make it
>easier for DNS zone operators to support signing zone data
>simultaneously with multiple DNSSEC algorithms, without significantly
>increasing the size of DNS responses.  It will also allow an easier
>way to transition to new algorithms while still retaining support for
>older DNS validators that do not yet support the new algorithms.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-huque-dnssec-alg-nego/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00
> https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-00
>
> --
> Shumon Huque
>
>
> ___
> 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] [Technical Errata Reported] RFC8078 (5049)

[Ólafur Guðmundsson]

The errata is correct.

Ólafur

sent from phone

On Jun 23, 2017 11:54, "RFC Errata System" 
wrote:

> The following errata report has been submitted for RFC8078,
> "Managing DS Records from the Parent via CDS/CDNSKEY".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5049
>
> --
> Type: Technical
> Reported by: Ondřej Caletka 
>
> Section: 4
>
> Original Text
> -
>The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
>contain the exact fields as shown below.
>
>   CDS 0 0 0 0
>
>   CDNSKEY 0 3 0 0
>
>The keying material payload is represented by a single 0.  This
>record is signed in the same way as regular CDS/CDNSKEY RRsets are
>signed.
>
>Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the
>DNSKEY algorithm is what signals the DELETE operation, but for
>clarity, the "0 0 0 0" notation is mandated -- this is not a
>definition of DS digest algorithm 0.  The same argument applies to
>"CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by
>[RFC4034], Section 2.1.2.
>
>
> Corrected Text
> --
>The contents of the CDS or CDNSKEY RRset MUST contain one RR and only
>contain the exact fields as shown below.
>
>   CDS 0 0 0 00
>
>   CDNSKEY 0 3 0 AA==
>
>The keying material payload is represented by a single octet with
>the value 00. This record is signed in the same way as regular
>CDS/CDNSKEY RRsets are signed.
>
>Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the
>DNSKEY algorithm is what signals the DELETE operation, but for
>clarity, the "0 0 0 00" notation is mandated -- this is not a
>definition of DS digest algorithm 0.  The same argument applies to
>"CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
>[RFC4034], Section 2.1.2.
>
> Notes
> -
> RFC 7344 defines both CDS and CDNSKEY record wire and presentation format
> to be identical to DS and DNSKEY wire and presentation format defined in
> RFC 4034.
>
> In case of CDNSKEY record, RFC 4034 section 2.2 requires that:
> > The Public Key field MUST be represented as a Base64 encoding of the
> Public Key.
>
> As Base64 encoding encodes 6 bits into one character, one character alone
> can never be a valid Base64 sequence. The proper encoding of one-byte long
> sequence with binary value of 00 is AA==.
>
> In case of CDS record, RFC 4034 section 5.3 requires that:
> > The Digest MUST be represented as a sequence of case-insensitive
> hexadecimal digits
>
> Although the value of a single 0 fulfils this requirement per se, it's not
> properly parsable by many implementations since it is expected to be even
> number of hex digits to align with octet boundaries in the wire format. So
> proper form of CDS record should contain two zeroes in place of the digest.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8078 (draft-ietf-dnsop-maintain-ds-06)
> --
> Title   : Managing DS Records from the Parent via CDS/CDNSKEY
> Publication Date: March 2017
> Author(s)   : O. Gudmundsson, P. Wouters
> Category: PROPOSED STANDARD
> Source  : Domain Name System Operations
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft for ALIAS/ANAME type

[Ólafur Guðmundsson]

Anthony,

Good writeup

Section 3.4 is in conflict with Refuse-Any draft (in WGLC)
IMHO there is no need to say that there is special processing for ANY
query;  so drop section 3.4

Olafur


On Wed, Mar 29, 2017 at 9:51 AM, Anthony Eden 
wrote:

> After attending the dnsop meeting on Monday I decided it was time I
> submitted my first ID for review:
>
> https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/
>
> This draft describes the ALIAS/ANAME record (aka CNAME-flattening)
> that numerous vendors and DNS providers are now supporting in
> proprietary fashions. I hope that this draft will eventually lead to a
> good mechanism for interop of ALIAS/ANAME records.
>
> Sincerely,
> Anthony Eden
>
> --
> DNSimple.com
> http://dnsimple.com/
> Twitter: @dnsimple
>
> ___
> 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] [Errata Verified] RFC8027 (4877)

[Ólafur Guðmundsson]

I will be happy to take it over

Olafur


On Tue, Mar 28, 2017 at 12:03 PM, Stephane Bortzmeyer <
bortzmeyer+i...@nic.fr> wrote:

> On Sun, Mar 26, 2017 at 11:36:08AM -0700,
>  RFC Errata System  wrote
>  a message of 42 lines which said:
>
> > The following errata report has been verified for RFC8027,
>
> OK, so, now, what do we do with this domain? Does anyone has a project
> for it or should I let it expire?
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Guðmundsson]

On Mon, Feb 13, 2017 at 9:50 AM, Richard Gibson  wrote:

> On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds  wrote:
>
>> You think this would actually provide any sort of useful information? No
>> operator would understand what "MBZ: 0x" means without re-training,
>> and if you're re-training operators you may as well point them to this
>> document.
>
>
> I think it would be _very_ useful. People easily forget new information,
> but seeing unexpected data like that would provide the necessary trigger
> for remembering this document and e.g. retrying with +tcp.
>

Richard,

HINIFO is such a signal :-)
thus your request applies only to Send-one and Send-useful responses.
I do not think adding complexity will help at all.

 ... you want an overhead cost forever just because of "muscle memory"
learning curve for few people.

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

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

[Ólafur Guðmundsson]

Thank you for your comments

Q: why do you think it is useful to complicate things with a EDNS0 flag ?

Olafur



On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson  wrote:

> With full realization that this is coming very late in the game, we had a
> great deal of internal conversation within Dyn about implementing
> refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
> approaches—the latter because of reasons that have already been covered,
> and the former for lacking in-band signaling of non-"conventional"
> incompleteness to aid legitimate use.
>
> I believe there is sufficient cause to reserve a new OPT record EDNS
> header flag bit
> 
> for indicating "partial response" (as distinct from "truncation"). It will
> be safely ignored by current clients, but convey the desired information to
> those in the know.
>
> P.S. Our discussion also raised some more minor points:
>
>- Insisting that the HINFO OS field SHOULD be empty ("set to the null
>string") seems a little too strong; there's room in it for (and value
>from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please
>stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer
>text like "The OS field of the HINFO RDATA SHOULD be short to minimize
>the size of the response, and MAY be empty or MAY include a summarized
>description of local policy."
>- "Conventional [ANY] response" is used but not defined.
>- "ANY does not mean ALL" is misleading—RFC 1035
> is clear about
>QTYPE=255 being "a request for *all* records" (emphasis mine). That
>said, the proposed *response* behavior is consistent with that RFC.
>
>
> On Thu, Feb 9, 2017 at 12:56 AM,  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 Operations of the
>> IETF.
>>
>> Title   : Providing Minimal-Sized Responses to DNS
>> Queries that have QTYPE=ANY
>> Authors : Joe Abley
>>   Olafur Gudmundsson
>>   Marek Majkowski
>> Filename: draft-ietf-dnsop-refuse-any-04.txt
>> Pages   : 10
>> Date: 2017-02-08
>>
>> Abstract:
>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>The operator of an authoritative DNS server might choose not to
>>respond to such queries for reasons of local policy, motivated by
>>security, performance or other reasons.
>>
>>The DNS specification does not include specific guidance for the
>>behaviour of DNS servers or clients in this situation.  This document
>>aims to provide such guidance.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> 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

Re: [DNSOP] Review of draft [draft-ietf-dnsop-refuse-any-04.txt]

[Ólafur Guðmundsson]

John,

Thanks for the review
you are spot on, I should not edit while watching a soccer game :-(

I will post an updated version in the next few days.

how about for section 4.1:
I was trying to cover the case where the RRSET selected has Multiple
RRSIG's not

About 4.2.
Implementation may choose this when it can, if it can not for a zone then
fall back on 4.1

as for the guidance, I tried, but there are strong opinions out there and
.

Olafur



On Thu, Feb 9, 2017 at 12:53 AM, Woodworth, John R <
john.woodwo...@centurylink.com> wrote:

> Olafur,
>
> This is my first draft review so apologies if it seems harsh, I
> really like the concept of this draft.
>
>
> Comments:
>
> --
> Section 4.1 "Select one RRSet mode" -
>
> The section including "...choose a small one(s) to..." seems
> confusing, a single RRSet is expected why the possibility of
> multiple RRsets?
>
>
> --
> Section 4.2 "Synthesised HINFO RRset" -
>
> I do not follow the section including "...query includes DO=1...".
> Should the implementation fall back to the one-RRSet-mode?  If the
> only RRSet returned is a synthesized HINFO one, what does the
> returned RRSIG correspond to?
>
>
> --
> General -
>
> I would personally like to see more direction for implementers
> provided in the draft, e.g. expected configurable features.
> I realize this is a matter of personal taste.
>
>
> Thanks and good luck,
> John
>
> -- THESE ARE THE DROIDS TO WHOM I REFER:
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Guðmundsson]

This version addresses all the comments that the chair's determined needed
addressing.

Olafur


On Wed, Feb 8, 2017 at 9:56 PM,  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 Operations of the IETF.
>
> Title   : Providing Minimal-Sized Responses to DNS Queries
> that have QTYPE=ANY
> Authors : Joe Abley
>   Olafur Gudmundsson
>   Marek Majkowski
> Filename: draft-ietf-dnsop-refuse-any-04.txt
> Pages   : 10
> Date: 2017-02-08
>
> Abstract:
>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>The operator of an authoritative DNS server might choose not to
>respond to such queries for reasons of local policy, motivated by
>security, performance or other reasons.
>
>The DNS specification does not include specific guidance for the
>behaviour of DNS servers or clients in this situation.  This document
>aims to provide such guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt

[Ólafur Guðmundsson]

Yes I agree,
Push a new version if Tim agrees ?

Olafur



On Tue, Jan 10, 2017 at 12:53 PM, Paul Wouters  wrote:

> On Tue, 10 Jan 2017, Matthijs Mekking wrote:
>
> I personally think the simplification of using all zero's is good. If
>>> someone accidentally changes the wrong number in the DS record when
>>> changing parameters, it will prevent a mistaken delete request. While,
>>> the zone might still fail, at least it won't be forced to go through a
>>> period of insecure while the parental DS gets repopulated.
>>>
>>
>> I am fine with using all zero's. I just don't think the change in
>> resource record format is a good idea, dropping the last RDATA field
>> from the CDS record.
>>
>
> Ohh, I think Matthijs actually found a bug:
>
> The CDS RDATA is identical to the DS RDATA format, which is
> according to RFC 4034:
>
> 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Key Tag |  Algorithm|  Digest Type  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>/   /
>/Digest /
>/   /
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> The draft states:
>
> The keying material payload is represented by a single 0.
>
> So the CDS delete entry currently specified as:
>
>CDS 0 0 0
>
> Should in fact be:
>
>CDS 0 0 0 0
>
>
> And similarly, the CDNSKEY is currently specified as:
>
>CDNSKEY 0 3 0
>
> and should be:
>
>CDNSKEY 0 3 0 0
>
>
> Olafur, do you agree? Should we push a new draft version with this fix?
>
>
> Paul
>
> ___
> 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] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...

[Ólafur Guðmundsson]

On Wed, Jan 4, 2017 at 12:33 PM, Nicholas Weaver 
wrote:

> Any system which prevents zone enumeration requires online signing,
> https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html
>
> But NSEC5 is almost certainly not going to be adopted, simply because of
> the partial deployment problem.
>
> NSEC3 lies work today, but people worry that NSEC3 might have server
> compromise compromise the ZSK.
>
>
>
> So why not simply add a new DNSKEY record flag: NSEC3-only.  This flag
> means that the key in question can only be used to sign an NSEC* record
> when presenting NXDOMAIN.
>

I used to think that was a good idea, but  given that this will add
keys to the DNSKEY set I think it is not worth it with RSA the DNSKEY sets
are too large in most cases.
With ECC keys on the other hand this might be reasonable.

What is the problem you are solving by having a NSEC-only key ?
is it key management,  sharing keys with DNS operators, or something else.


At Cloudflare we sign a all DNSEC answers on the fly with the exception of
DNSKEY/CDS/CDNSKEY which we have to do centrally.
This is working and we do not worry too much about ZSK compromise, as we
can roll them when we need.
 We just use Minimally covering NSEC records (no need to do NSEC3),
we are looking into adoption that on the fly when under random prefix DDoS
attacks, to resolvers that we know support agressive NSEC processing.


> This way, you can deploy this solution today using white lies, and as
> resolvers are updated, this reduces the potential negative consequence of a
> key compromise to “attacker can only fake an NXDOMAIN”, allowing everything
> else to still use offline signatures.
>
>
Why is key compromise in DNS more worrying than in HTTPS ?
HTTP servers have keys online all the time.


> Combine with caching of the white lies to resist DOS attacks and you have
> a workable solution that prevents zone enumeration that is deployable today
> and has improved security (key can only fake NXDOMAIN) tomorrow.
>
>
The problem with a FLAG is that it will require
a) validator/resolver support
b) have a workable key management

I think we can do this w/o the flag

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

Re: [DNSOP] search for reference

[Ólafur Guðmundsson]

Those numbers are not allocated they are just an artifact of bad design
from the 199x's

Olafur


On Fri, Dec 30, 2016 at 6:00 AM, A. Schulze  wrote:

> Hello,
>
> I'm searching for a reference (IANA?) that define the DNSSEC hash
> algorithm hmac-sha256
> has assigned the number 159
> ( see http://git.nlnetlabs.nl/ldns/tree/ldns/keys.h#86 )
>
> I only found https://www.iana.org/assignments/tsig-algorithm-names/tsig-
> algorithm-names.xhtml
> defining the /name/ but no /number/
>
> Thanks,
> Andreas
>
>
> ___
> 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] I-D Action: draft-ietf-dnsop-refuse-any-03.txt

[Ólafur Guðmundsson]

On Thu, Nov 17, 2016 at 11:48 AM, Ondřej Surý <ondrej.s...@nic.cz> wrote:

> Section 7 (nit): s/implimentations/implementations/
>
> Applied


> Otherwise I have reviewed the document and I believe it's ready to be put
> in the oven.
>
> ~~~
>
> There's a small procedural thing - the last name of the draft
> appears on both datatracker.i.o and tools.i.o.  I believe it
> would be better to reupload the draft with name changed to
>
> draft-ietf-dnsop-minimal-any
>
> to prevent the people who might thing the name of the draft
> bears any significance.  As this requires almost no effort
> I think it would be better to this now than fend of the
> questions "why is this refuse-any while it doesn't refuse
> ANY" later.
>
>
I in principle support this but this has to be the chairs call

Olafur


> 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 -
> > From: "Ólafur Guðmundsson" <ola...@cloudflare.com>
> > To: "dnsop" <dnsop@ietf.org>
> > Sent: Wednesday, 16 November, 2016 06:47:43
> > Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-03.txt
>
> > Dear colleagues
> >
> > This version addresses all the outstanding requests for changes.
> > The editors believe this version is ready for WGLC.
> >
> > thanks
> > Olafur
> >
> >
> > On Wed, Nov 16, 2016 at 2:44 PM, < [ mailto:internet-dra...@ietf.org |
> > 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 Operations of the
> IETF.
> >
> > Title : Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY
> > Authors : Joe Abley
> > Olafur Gudmundsson
> > Marek Majkowski
> > Filename : draft-ietf-dnsop-refuse-any-03.txt
> > Pages : 9
> > Date : 2016-11-15
> >
> > Abstract:
> > The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
> > The operator of an authoritative DNS server might choose not to
> > respond to such queries for reasons of local policy, motivated by
> > security, performance or other reasons.
> >
> > The DNS specification does not include specific guidance for the
> > behaviour of DNS servers or clients in this situation. This document
> > aims to provide such guidance.
> >
> >
> > The IETF datatracker status page for this draft is:
> > [ https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ |
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ ]
> >
> > There's also a htmlized version available at:
> > [ https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-03 |
> > https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-03 ]
> >
> > A diff from the previous version is available at:
> > [ https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-03 |
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-03 ]
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at [
> http://tools.ietf.org/ |
> > tools.ietf.org ] .
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > [ ftp://ftp.ietf.org/internet-drafts/ | ftp://ftp.ietf.org/internet-
> drafts/ ]
> >
> > ___
> > DNSOP mailing list
> > [ mailto:DNSOP@ietf.org | DNSOP@ietf.org ]
> > [ https://www.ietf.org/mailman/listinfo/dnsop |
> > 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

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

[Ólafur Guðmundsson]

Dear colleagues

This version addresses all the outstanding requests for changes.
The editors believe this version is ready for WGLC.

thanks
Olafur


On Wed, Nov 16, 2016 at 2:44 PM,  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 Operations of the IETF.
>
> Title   : Providing Minimal-Sized Responses to DNS Queries
> with QTYPE=ANY
> Authors : Joe Abley
>   Olafur Gudmundsson
>   Marek Majkowski
> Filename: draft-ietf-dnsop-refuse-any-03.txt
> Pages   : 9
> Date: 2016-11-15
>
> Abstract:
>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>The operator of an authoritative DNS server might choose not to
>respond to such queries for reasons of local policy, motivated by
>security, performance or other reasons.
>
>The DNS specification does not include specific guidance for the
>behaviour of DNS servers or clients in this situation.  This document
>aims to provide such guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] FYI - Added note about ECDSA resolver issue in Sweden - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt

[Ólafur Guðmundsson]

Registrars/IANA/Registries/Resellers ==> Parents or Parental Agents


Olafur


On Mon, Nov 7, 2016 at 7:22 AM, Ondřej Surý  wrote:

> 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
>  
>  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 -
> > From: "George Michaelson" 
> > To: "Dan York" 
> > Cc: "dnsop" 
> > Sent: Monday, 31 October, 2016 05:22:43
> > Subject: 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
>
> > It is only my personal opinion, but I believe registrars are incorrect
> > in performing crypto alg checks on proffered DS, and this is an
> > entirely unwarranted, and incorrect understanding of their role. It
> > conflates one public good (checking) with another public good
> > (registry of data into the DNS) and assumes one out-ranks the other:
> > It doesn't, and the inability to track crypto alg change, makes the
> > checking wrong. Its the lesser of two evils to stop checking, and
> > permit unknown algorithms through.
> >
> > I think this needs to be flagged up. Either they should be told to
> > stop, or the requirements for algorithm agility which their role
> > places on them should be made explicit.
> >
> > -George
> >
> > On Mon, Oct 31, 2016 at 1:49 PM, Dan York  wrote:
> >> FYI, I submitted a new version of this draft that added some text in the
> >> section about "Resolvers" that mentions the case Mikael Abrahamsson
> brought
> >> to us about how they had to disable DNSSEC validation in the CPE they
> >> deployed to their customers because the resolver software was not
> following
> >> RFC 4035 and was not ignoring signatures with unknown algorithms.
> >>
> >> Comments are of course welcome.
> >>
> >> For those who are interested in writing I-D's with markdown, I also
> >> transitioned the source of this version of the document to the flavor of
> >> markdown that works with Miek Gieben's 'mmark' processor. Paul Jones
> nicely
> >> packaged mmark and xml2rfc into a Docker container that works extremely
> >> well. This document and other links can be found in my Github repo at:
> >> https://github.com/danyork/draft-deploying-dnssec-crypto-algs
> >>
> >> Dan
> >>
> >> Begin forwarded message:
> >>
> >> From: 
> >> Subject: New Version Notification for
> >> draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
> >> Date: October 30, 2016 at 11:37:13 PM EDT
> >> To: Ondrej Sury , Olafur Gudmundsson
> >> , Dan York , " y...@isoc.org
> "
> >> , Paul Wouters 
> >>
> >>
> >> A new version of I-D, draft-york-dnsop-deploying-
> dnssec-crypto-algs-02.txt
> >> has been successfully submitted by Dan York and posted to the
> >> IETF repository.
> >>
> >> Name: draft-york-dnsop-deploying-dnssec-crypto-algs
> >> Revision: 02
> >> Title: Observations on Deploying New DNSSEC Cryptographic Algorithms
> >> Document date: 2016-10-31
> >> Group: Individual Submission
> >> Pages: 9
> >> URL:
> >> https://www.ietf.org/internet-drafts/draft-york-dnsop-
> deploying-dnssec-crypto-algs-02.txt
> >> Status:
> >> https://datatracker.ietf.org/doc/draft-york-dnsop-
> deploying-dnssec-crypto-algs/
> >> Htmlized:
> >> https://tools.ietf.org/html/draft-york-dnsop-deploying-
> dnssec-crypto-algs-02
> >> Diff:
> >> https://www.ietf.org/rfcdiff?url2=draft-york-dnsop-
> deploying-dnssec-crypto-algs-02
> >>
> >> Abstract:
> >>   As new cryptographic algorithms are developed for use in DNSSEC
> >>   signing and validation, this document captures the steps needed for
> >>   new algorithms to be deployed and enter general usage.  The intent is
> >>   to ensure a common understanding of the typical deployment process
> >>   and potentially identify opportunities for improvement of operations.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >> --
> >> Dan York
> >> Senior Content Strategist, Internet Society
> >> y...@isoc.org   +1-802-735-1624
> >> Jabber: y...@jabber.isoc.org
> >> Skype: danyork   http://twitter.com/danyork
> >>
> >> http://www.internetsociety.org/
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> DNSOP mailing list
> >> DNSOP@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dnsop
> >>
> >
> > 

Re: [DNSOP] ECDSA woes

[Ólafur Guðmundsson]

I will be happy to do that,  stay tuned as I need to create a special
signer for it :-)

Olafur


On Sun, Oct 16, 2016 at 4:16 AM, Mikael Abrahamsson <swm...@swm.pp.se>
wrote:

> On Sat, 15 Oct 2016, Ólafur Guðmundsson wrote:
>
> I have domains signed by all combinations of signing algorithms and DS
>> digests as well as Nsec variants
>> Ds-n.alg-m-nsec.dnssec-test.org
>>
>> Replace n with 1..4
>> M with 1..14
>> Nsec is one of Nsec nsec3 none
>>
>
> I'd be veryinterested if you could create an algorithm called "99" (or
> something), and we could test that. Anyone not loading the "99" resource is
> violating the "SHOULD", even if they understand ECDSA.
>
> This would investigate ratio of problems when we want to introduce a new
> algorithm in the future.
>
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ECDSA woes

[Ólafur Guðmundsson]

I have domains signed by all combinations of signing algorithms and DS
digests as well as Nsec variants
Ds-n.alg-m-nsec.dnssec-test.org

Replace n with 1..4
M with 1..14
Nsec is one of Nsec nsec3 none

Ólafur

sent from phone

On Oct 15, 2016 17:29, "Geoff Huston"  wrote:

>
> > On 16 Oct. 2016, at 2:53 am, Mikael Abrahamsson 
> wrote:
> >
> > On Sat, 15 Oct 2016, Ralf Weber wrote:
> >
> >> Geoff Houston did some research here some years ago and just did an
> update to his findings. You might want to look at:
> >>  http://www.potaroo.net/ispcol/2016-10/ecdsa-v2.html
> >
> > Do we know how many experiments failed because the resolver erroneously
> reported error for ECDSA signed domains?
> >
> >> From reading Geoffs text, it's not obvious to me that this error case is
> > caught by his tests?
>
> so I have three tests:
>
> A: a validly-signed ECDSA P-256 domain
>
> B: an invalidly-signed ECDSA P-256 domain
>
> C: an unsigned control
>
> now if the resolver does NOT recognise ECDSA we should see a fetch for A,
> B and C  (as they treat both A and B as if they were unsigned)
>
> if the resolver recognises ECDSA we will see a fetch of A and C but not B
>
> and if the resolver incorrectly returns SERVFAIL when it sees ECDSA (which
> I presume is what DNSMASQ 2.71 is doing) then we should see only C and not
> A or B
>
> The report generated uses these definitions to determine if a user is
> passing their queries to ECDSA-aware resolvers
>
> So thats the long answer to yes, this error is caught by these tests, and
> the error is put into the “does not do ECDSA” bucket.
>
> thanks,
>
>Geoff
>
>
>
>
> ___
> 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] Where in a CNAME chain is the QNAME?

[Ólafur Guðmundsson]

On Mon, Sep 26, 2016 at 8:33 AM, Peter van Dijk  wrote:

> Hello,
>
> On 23 Sep 2016, at 10:22, Stephane Bortzmeyer wrote:
>
> On Tue, Sep 20, 2016 at 06:13:50PM +0200,
>>  Stephane Bortzmeyer  wrote
>>  a message of 68 lines which said:
>>
>> This issue was spotted by Peter van Dijk. It is about
>>> draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The
>>> problem is the definition of "QNAME" when there is a CNAME chain.
>>>
>>
>> OK, after reading the discussion, my opinion, as an author (but I'll
>> of course defer the decision to the working group, the WG chairs, the
>> RFC editor and the flying spaghetti monster):
>>
>> The re-definition of QNAME by RFC 2308 is awkward and does not match
>> the general usage, or the previous definitions. Therefore, I prefer to
>> keep the "common sense" usage "QNAME is the owner name of the record
>> in the Question Section". Which means that, in my example, the QNAME
>> is "www.afnic.fr" and the current text of
>> draft-ietf-dnsop-nxdomain-cut-05 is correct.
>>
>
> 2308 does not “redefine” QNAME. It clarifies that the usage in 1034 4.3.2
> is the definition we use in RFCs. 1035 4.1(.2) does not conflict with this;
> the QNAME there is just the initial QNAME.
>
> Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 5155,
> 6147, 6672 and most likely several others rely on the 2308 definition of
> QNAME. Without 2308, each of these RFCs would need extra text such as the
> text your draft has now. It is simply not necessary.
>
>
> Peter, is right
but the root cause is the role of "CNAME" and to lesser extent "DNAME".
Both is what I have part of DNS Navigation records that act like
"rewriters".
1034 was light on detail, 2308 might have uses a better notation but the
effect would have been the same,
The RCODE applies to the RRSET pointed to by the last CNAME in answer
section (or the missing one).

In hindsight the use of single RCODE with limited enumeration is the root
cause.
If one was designing this again one would allow multiple Questions in the
header and each RRset would have a header that says what its ReturnCode is,
but that is the advantage of hindsight.

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

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

[Ólafur Guðmundsson]

This version contains minor text and structure improvements suggested by
TimW.

Editors think the document is ready for WGLC

Olafur

On Mon, Jul 25, 2016 at 6:38 AM,  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 Operations of the IETF.
>
> Title   : Providing Minimal-Sized Responses to DNS Queries
> with QTYPE=ANY
> Authors : Joe Abley
>   Olafur Gudmundsson
>   Marek Majkowski
> Filename: draft-ietf-dnsop-refuse-any-02.txt
> Pages   : 9
> Date: 2016-07-21
>
> Abstract:
>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>The operator of an authoritative DNS server might choose not to
>respond to such queries for reasons of local policy, motivated by
>security, performance or other reasons.
>
>The DNS specification does not include specific guidance for the
>behaviour of DNS servers or clients in this situation.  This document
>aims to provide such guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] DS records and validating resolvers

[Ólafur Guðmundsson]

One DS +DNSKEY is sufficient, others are ignored as they can be for past or
future keys.
The only exception is when the DS records are for multiple algorithms some
implementations demand that all algorithms are working

Olafur


On Thu, Jul 14, 2016 at 12:20 PM, Einar Bjarni Halldórsson 
wrote:

> Hi,
>
> I’ve looked and could not find an answer to my question anywhere.
>
> If there are multiple DS records in a parent, with different key tags,
> where only one of the DS records has a corresponding DNSKEY record in the
> child zone that correctly signs the DNSKEY RRSET, will validating resolvers
> ignore the other DS records or could they cause responses from the child to
> become invalid?
>
> .einar
> ISNIC
> ___
> 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] I-D Action: draft-ietf-dnsop-maintain-ds-03.txt

[Ólafur Guðmundsson]

Dear colleagues

This version addresses all comments received during the WGLC,
The main changes are clarifications requested by reviewers.
In addition some reordering was done to fit better with the model that
operations are "Introduction Maintainance Deletion"
In the IANA section there is a new paragraph (section 6.1) that elevates
RFC7344 to standards track to avoid down reference.

Olafur

On Fri, Jun 10, 2016 at 11:40 AM,  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 Operations of the IETF.
>
> Title   : Managing DS records from parent via CDS/CDNSKEY
> Authors : Olafur Gudmundsson
>   Paul Wouters
> Filename: draft-ietf-dnsop-maintain-ds-03.txt
> Pages   : 9
> Date: 2016-06-10
>
> Abstract:
>RFC7344 specifies how DNS trust can be partially maintained in-band
>between parent and child.  There are two features missing in that
>specification: initial trust setup and removal of trust anchor.  This
>document addresses both these omissions.
>
>Changing a domain's DNSSEC status can be a complicated matter
>involving multiple unrelated parties.  Some of these parties, such as
>the DNS operator, might not even be known by all the organizations
>involved.  The inability to disable DNSSEC via in-band signalling is
>seen as a problem or liability that prevents some DNSSEC adoption at
>large scale.  This document adds a method for in-band signalling of
>these DNSSEC status changes.
>
>Initial trust is considered in general to be a hard technical
>problem, this document sets forth reasonable policies that clarify
>and simplify the initial acceptance policy.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] Working Group Last Call for draft-ietf-dnsop-maintain-ds

[Ólafur Guðmundsson]

On Tue, Apr 26, 2016 at 5:13 AM, Matthijs Mekking 
wrote:

> All,
>
> Matthijs thanks for the review
sorry for the delay in response.


> I have read it and I like it. Still there are I think some things that
> need to be addressed:
>
> - On enabling DNSSEC via CDS/CDNSKEY: most of the policies assume some
> sort of communication channel between the child zone operator and parent
> zone operator, while in fact RFC 7344 registers new resource records
> because we assume there is no such channel. CDS/CDNSKEY records are put
> in the child zone to signal the desired DS RRset in the parent. The
> child can only hope that the parent will pick it up and the only way to
> get confirmation is to query the parent zone. So how would the parent
> "send a notification requesting a confirmation" (section 3.2) or
> "instruct the requestor to insert some record into the child domain"
> (section 3.4)?
>

Ok the current text is sub-optimal  added:
"for example by sending email to the registrant requesting a confirmation."


>
> It could use the same CDS approach and put it in some new resource
> records in the parent zone (just stick it in the DNS ;)).
>
That is even bigger change :-) sorry no go

>
> Anyway, if we assume there is no other communication channel, the
> document should provide more details on where to put this notification
> or challenge such that the child can pick it up. If we say there is a
> different communication channel, there needs to be more details about
> how that channel looks. Or we should just keep saying it is a hard
> problem and leave it out of scope (and solve it in yet another document).
>
In general we envision three confirmation approaches
  - A proof of change control of zone by requesting record insertion
(covered)
  - A delay in acceptance, i.e. a stability check (covered)
  - A email to registrant asking for confirmation. (just added)
While there might be more this is all we envision.



>
> - On using 0 as the DNSSEC Delete Algorithm in CDS and CDNSKEY records,
> I think that is fine and is a cleaner approach then using a non-zero
> algorithm number. The document could perhaps make it explicit it is
> meant only to be used in CDS and CDNSKEY records, not DS/DNSKEY.
>

done

>
> - The document suggests that when disabling DNSSEC, only the fixed
> fields should appear in the records. Do you mean fixed length fields?
>

changed "fixed fields" to "exactly the fields"

>
> - Leaving out the Digest/Public Key field changes the definition of the
> CDS and CDNSKEY records: No longer are their formats identical to the
> DS/DNSKEY records. So at minimal this updates RFC 7344. Existing
> versions of DNS server that support RFC 7344 will likely not be able to
> load a CDS record as described in section 4 and consider it malformed.
>

Good point, making this clearer in text


>
>
> Finally, two nits:
>
> - Nit: The abstract gives the reader the feeling that initial trust is a
> very hard problem, but then section 1.2 says it can be easily solved
> with some simplifying assumptions :) Perhaps you meant to say that it is
> hard to solve technically unless some reasonable policies can be assumed.
>
> - Nit: The first use mentioned in section 2 is just KSK Rollover. What
> does explaining the different operations add to the document?
>
> Basically setting the stage and expectations


>
> Best regards,
>   Matthijs
>
>
> thanks again
Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Ólafur Guðmundsson]

On Fri, Mar 25, 2016 at 10:51 PM, John Levine  wrote:

> >As I think many here know, I am not of the get-off-my-lawn persuasion
> >for DNS innovations.  I don't think it's a bad idea in principle.  I'm
> >just aware that we have this long history, and that history was based
> >on a certain kind of conservatism that is arguably appropriate to a
> >technology quite as fundamental to the Internet functioning as the DNS
> >is.  If we're going to abandon that conservatism, I think it needs
> >quite a lot more early IETF buy-in than we might get by developing
> >this work here in DNSOP.  The more signal we can get to suggest that
> >DNS actors are ok with the innovation, the lower I think that bar gets.
>
> I'd be a lot more comfortable if we had some field test data about
> what real DNS caches do with the extra  records.  In theory
> nothing bad should happen, in practice ...
>
> John
The next step is experimentation, we wanted to see if the community thought
this was a stupid idea before going forward.
There are 3 possible outcomes when a DNS querier gets an aswer like this
#1 It accepts everything from authority section
#2 It tosses the non queried RRset
#3 it Rejects the answer and tries again

If the result is #1 nothing needs to be done
For #2 that means convincing the software vendors to adopt more relaxed
approach
On the other hand if #3 is the case for a significant part of the
infrastructure we can not do this w/o signaling


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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Ólafur Guðmundsson]

On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews  wrote:

>
> In message <2016030345.29993...@pallas.home.time-travellers.org>,
> Shane Kerr writes:
> > Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> > killed ANY and then gave us ANYA ("any address"). ;)
>
> You would then need to do ANYA, A and  queries or you have to
> have signaling to indicate if the server supports ANYA with fallback
> to A and  on no support.  Now for named you go from NOTIMP ->
> NOERROR/NXDOMAIN introducing a meta type but for other servers you
> start at NOERROR/NXDOMAIN so explicit signaling of support for a
> meta type is needed.
>
>
There are two ways to approach the address distribution problem,
a) from the client side
b) from the server side
our proposal is strictly in camp b) i.e. just servers put this out.

The OPEN question is what will resolvers do
#1 Accept but RRsets
#2 Discard non QTYPE covered set
#3 discard the answer

If it is #3 then this is a horrible idea,
if is #2 then there is no loss and resolvers will improve over time.
if it is #1 then it is a win without any resolver changes.

Tony,
Same questions apply if  set is put in the additional section.

Andrew,
We need data to determine if this is feasible.


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

Re: [DNSOP] Introducing draft-wouters-sury-dnsop-algorithm-update

[Ólafur Guðmundsson]

On Sun, Mar 20, 2016 at 2:55 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:

> On 20 Mar 2016, at 10:55, Ólafur Guðmundsson wrote:
>
> On Sat, Mar 19, 2016 at 4:04 PM, Paul Hoffman <paul.hoff...@vpnc.org>
>> wrote:
>>
>> [[ Dropping CURDLE because these discussions should only be in one WG ]]
>>>
>>>ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for
>>>signature size than RSASHA256 and RSASHA512 variants.  It is expected
>>>to be raised to MUST once they have been deployed more widely for
>>>DNSSEC Signing.  ECDSAP256SHA256 has seen raise in the deployment, so
>>>it's set to MUST level for DNSSEC Validation.
>>>
>>> Even though I was a strong proponent of ECDSA, I think this is the wrong
>>> move. ECDSA has had many years to garner interest, and it hasn't. Within
>>> a
>>> year, we will have EDDSA in DNSSEC, and the operational crypto properties
>>> of EDDSA are noticeably better than those of ECDSA. It would be much
>>> better
>>> if the community just standardized on EDDSA instead of a mixture of the
>>> two
>>> algorithms. Proposal: drop them from this document. They will remain in
>>> the
>>> IANA registry, of course.
>>>
>>> --Paul Hoffman
>>>
>>> Paul for the record
>>>
>> There are tens of thousands of domains signed with ECDSAP256SHA256 world
>> wide.
>> ECDSA is currently the only viable algorithm for anyone that wants to do
>> OnLine signing in low latency environments.
>>
>
> Yes, but that doesn't change what I said. Most of those domains are signed
> by one entity who can change easily if the operational market thinks that
> is a good idea.


Right now there are two options for on-line signers GOST-ECC and
ECDSAP256SHA256
no other alternative will be useful for many years, so our choice was
signing pain or deployment pain.
We picked the deployment pain due to size and signature strength factors.

Your statement can be read to mean that ECC should not be used because
ECDSA has no advantages over
RSA with 1024 bit keys, I know that was not what you wanted to say.

There are at least 2 other parties that I'm aware that are working on their
own online signing systems using the same
algorithm as we are.


> There are significant issues related to deploying a new DNSSEC algorithm
>> world wide, most related to stuff actual operating environments.
>>
>
> Sure.



>
>
> My current
>> best guess is that it takes about 5-10years after IETF standardizes new
>> algorithm, before the algorithm is globally "useful".
>>
>
> And yet you chose to deploy sooner:


See above, and I did not know at the beginning how hard it is to move the
ecosystem,
so consider this a service to future vanity algorithms.


>
> We are still inside
>> the 5 year window, working out the issues in deploying new algorithms with
>> ECDSA can only help the algorithms that will follow.
>>
>
> Right, particularly because EDDSA has notable *operational* advantages
> over ECDSA.


define operational!!!
>From my point operational is all about the running systems, and how data
gets into those systems.
I fail to see how crypto advantages help that. If it is faster that might
be an advantage.


>
> I see no evidence of use of ECDSAP384SHA384 except in test setups, so I
>> have no problem not mentioning that  algorithm in the document.
>>
>
> The 256/384 issue is a separate one, but one worth discussing. FWIW, I
> agree that mentioning it, maybe even suggesting against its use, would be
> good.


For the record I never wanted ECDSAP384SHA384 defined, will support having
it obsoleted.
Fewer algorithms are better for DNSSEC.

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

Re: [DNSOP] Introducing draft-wouters-sury-dnsop-algorithm-update

[Ólafur Guðmundsson]

On Sat, Mar 19, 2016 at 4:04 PM, Paul Hoffman  wrote:

> [[ Dropping CURDLE because these discussions should only be in one WG ]]
>
>ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for
>signature size than RSASHA256 and RSASHA512 variants.  It is expected
>to be raised to MUST once they have been deployed more widely for
>DNSSEC Signing.  ECDSAP256SHA256 has seen raise in the deployment, so
>it's set to MUST level for DNSSEC Validation.
>
> Even though I was a strong proponent of ECDSA, I think this is the wrong
> move. ECDSA has had many years to garner interest, and it hasn't. Within a
> year, we will have EDDSA in DNSSEC, and the operational crypto properties
> of EDDSA are noticeably better than those of ECDSA. It would be much better
> if the community just standardized on EDDSA instead of a mixture of the two
> algorithms. Proposal: drop them from this document. They will remain in the
> IANA registry, of course.
>
> --Paul Hoffman
>
> Paul for the record
There are tens of thousands of domains signed with ECDSAP256SHA256 world
wide.
ECDSA is currently the only viable algorithm for anyone that wants to do
OnLine signing in low latency environments.

There are significant issues related to deploying a new DNSSEC algorithm
world wide, most related to stuff actual operating environments. My current
best guess is that it takes about 5-10years after IETF standardizes new
algorithm, before the algorithm is globally "useful". We are still inside
the 5 year window, working out the issues in deploying new algorithms with
ECDSA can only help the algorithms that will follow.
I see no evidence of use of ECDSAP384SHA384 except in test setups, so I
have no problem not mentioning that  algorithm in the document.

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

Re: [DNSOP] TSIG algorithm registry

[Ólafur Guðmundsson]

https://www.iana.org/assignments/tsig-algorithm-names/tsig-algorithm-names.xhtml

Olafur


On Tue, Mar 8, 2016 at 8:48 AM, Mukund Sivaraman  wrote:

> Hi all
>
> There doesn't seem to be a registry of TSIG algorithm identifiers (at
> least I am not able to find it):
>
> https://tools.ietf.org/html/rfc4635#page-5
>
> There's no registry here:
>
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
>
> Mukund
>
> ___
> 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] Fracturing the protocol - was Re: Updated cheese-shop.

[Ólafur Guðmundsson]

On Wed, Mar 2, 2016 at 9:10 AM, Shane Kerr 
wrote:

> Evan,
>
> I think that moving Fujiwara's fuller proposal forward will likely take
> an extra year and don't see any conflict with the cheese shop approach
> really. However since the cheese shop won't likely result in any
> running code, I also agree with the suggestion to focus on the general
> case.
>
>
Why?
 Everything we need is in the current draft, if anything there is only
cutting of text to do.
I think the indicator Flag that I (and others) proposed is a bad idea and
should either removed or put in
the OPT record

If we keep it simple then the world will look like this:
  - resolver MAY apply ANC when it suits them, CD bit is ignored for
caching when ANC is in use
  - Auth operators MUST assume they have no control over if resolvers use
ANC and are limited to pleading for help when under attack.

In this world we are no worse off than today. Large Auth server operators
can only hope that the big resolver farms like Google, OpenDNS, Verisign,
Level3, and  do ANC.
For the record the local-root-zone operation does exactly what the Cheese
shop wants to do just requires two processes in some cases.

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

Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

[Ólafur Guðmundsson]

On Wed, Mar 2, 2016 at 6:49 AM, Evan Hunt  wrote:

> On Wed, Mar 02, 2016 at 08:06:39AM +1100, Mark Andrews wrote:
> > ANC does not work for zones using OPTOUT.  This is just about all
> > TLDs and similar zones.
>
> To be pedantic, it doesn't work for optout ranges. I don't actually know
> offhand of any zones that mix optout and non-optout, though, so it's a
> fairly pointless quibble.
>
>

> > That then leaves leaf zones.  Here sites will not want ANC for their
> > own zones internally.  Externally there is only real benefit if you
> > are under a random prefix DoS attack.
>
> Random prefix DoS attacks are prevalent enough nowadays to make
> this seem like a rather significant exception.
>

+1

>
> The downsides should be manageable. We can implement ANC so that it's
> separately enabled or disabled for different namespaces, and put a TTL
> cap on NSEC/NSEC3 records in zones that have ANC enabled.
>

I personally think we should start up a conversation on good practices for
TTL's
based on the fact we have reliable, fast, dynamic Internet.


>
> I agree with the suggestion upthread that we address the general case
> instead of the root-only solution.
>
> We agree
Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

[Ólafur Guðmundsson]

On Mon, Feb 29, 2016 at 4:03 PM, Warren Kumari  wrote:

>
>
> On Mon, Feb 29, 2016 at 10:04 AM Shane Kerr 
> wrote:
>
>> Ed,
>>
>> At 2016-02-29 14:34:39 +
>> Edward Lewis  wrote:
>> > I don't think I was clear - this is only about the DNS protocol.  This
>> > document proposes that the DNS protocol behave differently depending on
>> > the data being carried (QNAME) in it's own messages.
>>
>> [...]
>>
>> > This isn't about processing different values differently, this is about
>> > changing the behavior of the protocol based on environmental factors.
>>
> Ah. So you don't like identifying magic zones (other than in-addr.arpa,
>> ip6.arpa, .example, .local, ...). Fair enough.
>>
>> But AIUI, the proposal is an observation that Fujiwara's
>> NXDOMAIN-from-NSEC proposal can be implemented safely today for the root
>> zone, so we may as well go ahead and do that while considering wider
>> usage.
>>
>
>
> Yup. I believe we should still pursue Fujiwara's document, but that is
> likely to take a significant time, and there are hurdles to overcome. This
> document limits things to a subset where we know things work correctly (and
> seem OK within 4035) - once we have demonstrated that things work OK here,
> it paves the way for more aggressive NSEC.
>
>
Warren,

Can you list the issues you think need addressing in Fujiwara's document
other than saying that zones signed with "Opt-out" there will be gaps where
the technique can be applied, but gaps with opt-out bit set can not be
protected.

Thus I consider your document a distraction, we should push the general
solution not a special case

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

Re: [DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

[Ólafur Guðmundsson]

On Mon, Feb 22, 2016 at 9:21 PM, George Michaelson  wrote:

>
>
> On Tue, Feb 23, 2016 at 3:05 PM, Paul Wouters  wrote:
>>
>> Face to face time is rare. It also does not include everyone that's on
>> the list. So where possible, discussion on the lists is always preferred.
>
>
> A good bar. A high bar. A high bar, which I don't think the "design team"
> output can meet because I've checked the archives, to match my memory, and
> substantive discussion on the qualities of the idea of having a registry
> are few: there are nits on the words of the revision, but we've yet to
> actually broach "do we want to do this" in any real form.
>
> So consider the door open on that discussion:
>
> Folks: Do we *really* want to do this? Do we really *want* to revise
> RFC6761? Can we talk about this a bit?
>

RFC6761 in the context of root zone was a huge MISTAKE,
please push document though.
We have wasted enough time on 6761 fallouts, it is time for the misery to
end.


>
> Me? I don't want to do this. I want a process that is so rarely invoked,
> you have to be a lot taller to get on the ride, than at present. I want a
> substantive IETF-wide technically understood reason that is breaking
> architecture, avoiding URI methods, requiring code, that we all understand.
>
> And certainly not "because a lot of users now depend on it, because we
> squatted"
>
> George, thanks for writing this up
I support this document and want to see the mistake named RFC6761 erased

We should have something to point squatters to and that is where ".alt"
fits in.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Ólafur Guðmundsson]

On Sun, Feb 7, 2016 at 2:16 PM, Tony Finch  wrote:

> Another question:
>
> In order to minimize responses even further, I have made my code omit or
> include signature records depending on whether DO=0 or DO=1. That is, and
> ANY query with DO=0 gets one arbitrary unsigned RRset in response, and an
> ANY query with DO=1 gets one arbitrary signed RRset.
>
> Is this sensible, and if do should it be suggested by the draft?
>
>
Tony: the draft says right now:

A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, and MAY instead send a response with a single
   RRSet in the answer section.

   The RRSet returned in the answer section of the response MAY be a
   single RRSet owned by the name specified in the QNAME.  Where
   multiple RRSets exist, the responder MAY choose a small one to reduce

   its amplification potential.

Is that not sufficient ?

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

Re: [DNSOP] DNS Delegation Requirements

[Ólafur Guðmundsson]

Jakob, Patrik
thanks for writing this up, a great start.

On first read this document seems to be duplicating what is in
https://tools.ietf.org/html/rfc1912
It is hard to see what is new and what is the same.

There are number of assumptions in the current draft, that only apply when
the DNS contents  are distributed as zone in "files or axfr"  which not all
operators use.
There are few other examples of "rules" that show this document is written
from a TLD's perspective which is different from what Domain operators may
want to practice.

So before we start working on exactly what is in the current draft, can we
have a discussion about what should be in the document.

For example the document omits all discussion on TTL's is that
good/bad/separate ?
Do we want to talk about how many addresses are associated with a name
server name. (common practice is 1 A and/or 1  but will more work?)
Are the "current" naming rules still something we want to promote, i.e. can
we get rid of the Hostname rules from https://tools.ietf.org/html/rfc953

IMHO this should be a BCP candidate that obsoletes all prior guidance, no
matter what RFC the guidance came from.

Olafur



On Mon, Feb 8, 2016 at 8:57 AM, Jakob Schlyter  wrote:

> As we've seen to good summary on requirements for on a well-behaved DNS
> delegation of a domain name, Patrik Wallström and myself has written an
> Internet-Draft [1] describing such requirements. The requirements were
> developed within the CENTR Test Requirements Task Force (TRTF) and m ost of
> the original requirements and text originate from the Zonemaster [2][3]
> project.
>
> At this point, we're seeking more public comments - on this mailing list
> (unless the chairs disapproves), on the our issue tracker [4] or via email
> to the authors.
>
>
> jakob
>
>
> [1]
> https://www.ietf.org/id/draft-wallstrom-dnsop-dns-delegation-requirements-00.txt
> [2] https://zonemaster.net/
> [3] https://github.com/dotse/zonemaster
> [4] https://github.com/CENTRccTLDs/TRTF/issues
>
> ___
> 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-refuse-any and QTYPE=RRSIG

[Ólafur Guðmundsson]

On Fri, Feb 5, 2016 at 10:10 PM, Tony Finch  wrote:

> Last weekend one of our authoritative name servers
> (authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
> rather unhappy. Over the last week I have developed a patch for BIND to
> implement draft-ietf-dnsop-refuse-any which should allow us to handle
> ANY flood attacks better. http://fanf.livejournal.com/140566.html
>
> I still have a potential problem with RRSIG queries, which work a lot like
> ANY queries. Cloudflare's approach is to simply refuse them, which makes a
> lot of sense because RRSIG queries don't have the same interop concerns as
> ANY queries. However, in an attack like the ones we had last weekend where
> the queries arrived at our authoritative servers from lots of real
> recursive servers, a refusal will cause retries and make the attack worse.
>
> Would it be reasonable as an alternative to follow the refuse-any approach
> and just return the RRSIG(s) for one RRset? If so, I think this suggestion
> should be included in the draft.
>
>
For all you care you an even return a forged RRSIG/SIG i.e. one that is
made up on the fly
just make sure it covers a non existing TYPE :-)

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

Re: [DNSOP] Fwd: code points for brainpool curves for DNSSEC

[Ólafur Guðmundsson]

Stephen,

Sorry for being so blunt below.

The document totally content free as to why this makes any sense in an
operational context.
DNSSEC algorithms should not be given out lightly as there is a significant
COST to deploy support for each additional algorithm.

While I strongly support having better ECC algorithm that the currently
specified curves, adding a new ones SHOULD take place via a performance
oriented process.
Thus I strongly advocate that this publication be held up until we can
compare this curve with other curves being proposed.

Background I'm currently fighting an multifaceted battle to have various
entities adding support for ECDSAP256, specified over 3 years ago.

Adding and deploying a new DNSKEY algorithm does not just require changes
to
-- DNS servers, libraries and resolvers.

That is just the top of the iceberg,  but also to
-  DNS provisioning systems, DNSSEC signing systems, DNS testing tools,
 - user interfaces for registrars, hosting providers, third party DNS
operators, CDN's,  etc.
 - TLD and ccTLD policy documents, EPP implementations, plus in some cases
security evaluations,
 - not to mention firewalls, network monitoring tools 
 and number of other things I had no idea existed and majority of which is
not maintained anymore.

There are only so many times that one can get everyone's attention to
upgrade DNS stuff, thus requiring the change process to be run should not
be taken lightly.
If on the other hand if the editors are only interested in vanity algorithm
assignment without any deployment then ...

Olafur


On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell 
wrote:

>
>
>
>  Forwarded Message 
> Subject: code points for brainpool curves for DNSSEC
> Date: Wed, 9 Dec 2015 18:00:18 +
> From: Stephen Farrell 
> To: s...@ietf.org
>
>
> Hiya,
>
> The brainpool folks have written an I-D [1] that they are pushing
> through the rfc editor's independent stream. [2]
>
> That I-D wants to register code points for using their curves for
> DNSSEC.
>
> For documents that come through the independent stream, the IESG
> does an RFC 5742 [3] conflict review. The purpose of that review
> is to check that the RFC doesn't conflict with ongoing work in
> the IETF.
>
> If you have thoughts on this, please let me know before Dec 17th.
> I'll forward this to the dnsop, cfrg and curdle mailing lists
> to check there too. Apologies if you get >1 copy of this. Please
> try follow up on the saag list if you can.
>
> Thanks,
> Stephen.
>
>
> [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec
> [2] https://www.rfc-editor.org/pubprocess/
> [3] https://tools.ietf.org/html/rfc5742
>
>
>
> ___
> 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] Question on RRtypes in RFC 4034 Section 6.2

[Ólafur Guðmundsson]

The reasoning is in https://tools.ietf.org/html/rfc3597

On Tue, Dec 8, 2015 at 10:09 AM, Paul Wouters  wrote:

>
> Hi,
>
> Section 6.2 of 4034 talks about canonicalization of the RR Form
>
> Item 3 states:
>
> 3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
>HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
>SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
>the DNS names contained within the RDATA are replaced by the
>corresponding lowercase US-ASCII letters;
>
> My questions:
>
> a) What was the purpose of listening these and not all RRtypes?
>(It seems perhaps it wanted to say "All except A/")
>
All these types contain "domain names" as a field, and name compression is
allowed in the RDATA.
After the publication of RFC3597 no name compression is allowed in new
types.

b) What should be done with new RRtypes like OPENPGPKEY or SMIMA?
> c) Why the hell - hardcoded lists and not IANA registry?
>

Finite list as 3597 outlawed name-compression in new types


> d) Does this need updating or an errata?
>
HINFO and TXT is a mistake and there is errata on that
https://www.rfc-editor.org/errata_search.php?rfc=3597

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

[Ólafur Guðmundsson]

On Mon, Nov 9, 2015 at 12:52 PM, Evan Hunt  wrote:

> On Mon, Nov 09, 2015 at 04:55:24PM +, Tony Finch wrote:
> > With the current DNS protocol, a stub resolver can get all the records it
> > needs to validate a response in 1RTT, by sending multiple concurrent
> > queries for all the possible delegation points in the QNAME.
>
> But has to retain state for all those active queries, which adds a fair
> bit of complexity.  I would expect it to be a lot more straightforward to
> code a stub validator using CHAIN.
>

In deep zones like the reverse zones the stub has no idea where the zone
cuts are thus
this idea is work reduction for the stub

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Ólafur Guðmundsson]

On Tue, Oct 13, 2015 at 11:00 PM, Evan Hunt  wrote:

> On Tue, Oct 13, 2015 at 10:10:39PM +0100, Ólafur Gušmundsson wrote:
>
>
> > Is reference to RFC4770 security considerations good enough  ?
>
> Sorry, which RFC?  "vCard Extentions for Instant Messaging" doesn't
> seem likely to be what you meant here, but my brain is failing to
> figure it out from context.
>
>
Sorry for the typo : RFC4470

  Minimally Covering NSEC Records and DNSSEC On-line Signing


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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Ólafur Guðmundsson]

On Tue, Oct 13, 2015 at 7:28 PM, Evan Hunt  wrote:

> Hi Joe,
>
> I think you need some more text in the description of pick-one-rrset,
> something like:
>
>
>   A DNS responder which receives an ANY query MAY decline to provide
>   a complete response, and MAY instead choose to return only one of
>   the the RRsets present at the node specified in QNAME, and the
>   associated RRSIGs if any.
>
>
Fine


>   If this approach is chosen, the following limitations apply:
>
>- If there is an NS, CNAME, or DNAME RRset present, then the
>  responder MUST return those RRsets. (Note that DNAME can
>  coexist with NS; if this is the case, both RRsets MUST be
>  returned.) *
>
>
Having DNAME and NS below a zone apex is non-sensical as both are
"delegation records" i.e.
NS says where to find more specific name,
DNAME how to write a more specific name to another name.

NS and DNAME can co-exist at zone apex, and if the ANY query is for
the apex then it should not matter which RRset is returned from the APEX is
returned.
If this is a delegation point I think the server SHOULD return a referral,
i.e. NS record in Authority section.

For names where there is a CNAME either the CNAME is the only RRset or
there is a NSEC/NSEC3 RRset
I think for backwards compatibility CNAME should be returned in this case.

   - Otherwise, when multiple RRsets exist, the responder SHOULD
>  select an RRset to return using a deterministic mechanism,
>  so that subsequent queries of type ANY to the same server will
>  continue to receive the same data so long as the contents of
>  the node remain unchanged.  For example, the responder MAY
>  choose the smallest RRset, in order to reduce the amplification
>  potential of a type ANY query.
>
> This is an over specific recommendation and can not be enforced,
think about the case where an operator uses any-cast and different software
running on
various servers.
IMHO there is nothing wrong with picking always the same one or return
random one,
I think returning NSEC in answer section is fine for online signed zones if
there is no HINFO record, with the
exception of names where there is CNAME.
Similarly if there is a HINFO record it MAY take precedence over any other
records by the selection algorithms.

   - The responder MUST NOT choose to return an RRset of type RRSIG,
>  but MUST include the covering RRSIG RRs for whichever RRset is
>  chosen.
>
>
Fine.


>
> I'd suggest breaking this into a separate subsection of section 5.
>
> I would also mention in security considerations that synthesizing
> responses from a signed zone requires the private signing key to be online
> and available to every responder; offline signing, or signing on the master
> server only, are not possible.
>

Is reference to RFC4770 security considerations good enough  ?


> * I'm not completely certain DNAME needs to be mentioned in the first
>   bullet point, but I'm concerned there may be unintended consequences
>   if it's present but omitted.)


see above.

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Ólafur Guðmundsson]

On Sun, Oct 4, 2015 at 7:32 AM, Dave Lawrence  wrote:

> A couple of quick observations:
>
> * The draft says that the answer in a signed zone MAY be unsigned.
>   Since this will ultimately cause a SERVFAIL for validating
>   resolvers, it is not really acceptable.
>

You and Evan,
 are right we will update the document to reflect this, as returning
unsigned answers is only
accepted by non-validating resolvers and figuring out if resolver is
validating requires tracking resolver behavior
thus it is simpler and cheaper to sign.
Servers with Off-line signed zones have more to gain from this
functionality.


>
> * The draft does not describe at all what the proper behaviour is for
>   an owner name that has a CNAME record.  Since CNAMEs require special
>   handling, this should be addressed.  Personally I think the CNAME
>   should be returned in this case.
>
> good point, we will address it

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Ólafur Guðmundsson]

On Wed, Sep 30, 2015 at 10:08 PM, Evan Hunt  wrote:

> On Wed, Sep 30, 2015 at 11:28:45PM -0400, Joe Abley wrote:
> > 1. Return an unsigned response. This will be marked as bogus, and
> > trigger a QTYPE=HINFO re-query that will either return an actual signed
> > HINFO from the zone or a signed proof of non-existence. We think. I
> > haven't actually tested that a re-query will happen, but Olafur is
> > confident. :-)
>
> I haven't tested it either, but that is not what I would expect.
>

Only validating resolver will send follow up query,



>
> If the resolver gets a bogus response to a query of type ANY, I
> would expect it to try the same query at another name server,
> until it had exhausted all authoritative name servers, and then
> reply with SERVFAIL.
>

Here is the deal there are 3 sources of ANY queries to authoritative
servers
a) Malicious ones  both direct or reflected flood via open resolvers
b) Someone debugging or trying to zone walk
c) Resolver forwarding a ANY query because the cache for that name was
EMPTY.

We need to look at each one  and
for a) what we return does not matter but it should be small as it is just
noise
for b) we need them to comprehend the answer
for c) we need the resolver to accept the answer and not send followup
queries when a)  or b) is the reason they got the query

HINFO meets all the goals for a) and b).
This leaves us with c) in the case when query source is a legitimate
application, but in this case the HINFO is a useless
information and the application should realize that this attempt at getting
something for free failed and fall back on queries for what it wants i.e.
MX and A +  records.

I used to be in the camp for TC bit but that was before I realized that
open resolvers/forwarders are quite happy to do TCP, meaning you get a
flood of TCP connections. TC only addresses the issue of direct forged
floods.


> > 2. Sign the HINFO RR as it is synthesised (or pre-sign one, to avoid the
> > edge authority servers needing access to a signing key).
>
> Pre-signing essentially reduces to adding an empty HINFO to every node in
> every zone, then using the pick-one-RRset method, but ensuring that HINFO
> is always selected first.
>
> > That is true. However, one of the use-cases for this approach is a
> > nameserver for which a search for records present at a particular owner
> > name (as would normally be performed when responding to an ANY query) is
> > expensive.
>
> It's not at all obvious to me that this is cheaper.
>

There is NO need to sign, unsigned HINFO returned for ANY query looks to an
validating resolver just like an
incomplete answer thus it can either return the HINFO or ask the followup
question for the HINFO and get a signed
denial that the HINFO exists ==> which looks like the HINFO was just
deleted from the zone i.e. temporal inconsistency.

The draft optimizes against a) and b) the the  cost of the possible extra
queries for c) when there is a validating resolver, which most of the time
might be a be answering out of cache thus it is not  forwarding ANY query.
The goal of the draft is to give resolvers something to cache. thus getting
help from the resolvers in deflecting the flood.
We wanted to optimize defending against the misuse of ANY query in attacks.
It is up to each operator to decide what to do and when.
Not having a well documented way to deal with this is  the main problem.

For off-line signed zones the auth server can copy this behavior of
"forging" unsigned HINFO and then dealing with the verification triggered
extra queries.

>
> With either method, you have to search down through the zone to find out
> whether the node exists (otherwise you'd be returning NXDOMAIN, rather than
> a minimized response).  Since you're doing that search anyway, choosing an
> RRset to return is pretty cheap.  And actually, you really *should* also
> look through the RRsets at the node to make sure there isn't a non-empty
> HINFO record before you synthesize an empty one, and if you're doing *that*
> anyway, choosing an RRset wouldn't cost any more and could well cost less.
>

Given the assumption that we are optimizing for defense there is no need
for an authoritative resolver to know if it is authoritative for the zone
the query was for, it can just return HINFO as an negative answer to the
ANY query type.

The whole question is around the following equation "ANY == ALL"
 I say ANY != ALL, your proposal was so say stop after first RRset found so
we agree on the core question the
only difference is on what to return.
In our proposal you are optimizing for c) without knowing if the type you
return is of value to the originator of the query,
furthermore your answer is likely to be larger.

For me answering few hundred ANY queries a second is not a problem (steady
state) ,
answering few millions a second is a problem (regular events) is.
Simple forwarders will keep asking thus what is returned does not matter,


> Assuming we aren't 

[DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

[Ólafur Guðmundsson]

FYI,
this is latest incarnation of of how to give out minimal answer to ANY
query without breaking anything and being friendly to resolvers.
Comments,

Olafur

-- Forwarded message --
From: 
Date: Wed, Sep 30, 2015 at 12:04 PM
Subject: New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

A new version of I-D, draft-jabley-dnsop-refuse-any-00.txt
has been successfully submitted by Joe Abley and posted to the
IETF repository.

Name:   draft-jabley-dnsop-refuse-any
Revision:   00
Title:  Providing Minimal-Sized Responses to DNS Queries with
QTYPE=ANY
Document date:  2015-09-30
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-jabley-dnsop-refuse-any-00.txt
Status:
https://datatracker.ietf.org/doc/draft-jabley-dnsop-refuse-any/
Htmlized:   https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00


Abstract:
   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification does not include specific guidance for the
   behaviour of DNS servers or clients in this situation.  This document
   aims to provide such guidance.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

[Ólafur Guðmundsson]

On Mon, Sep 28, 2015 at 9:53 PM, Mukund Sivaraman  wrote:

> Hi Paul
>
> On Mon, Sep 28, 2015 at 02:36:25PM -0400, Paul Wouters wrote:
> > On Mon, 28 Sep 2015, Paul Vixie wrote:
> >
> > >those things should also be done in the short term.
> > >
> > >but it's the internet. it'll outlive us all. we ought to have a long
> > >term plan as well.
> >
> > It's called DNSSEC.
>
> Zone data validation and DNS message validation are two different
> concepts. DNSSEC will not protect against DNS message modifications.
>
> DNSSEC provides support for end-to-end security (complete chain-of-trust
> signature verification), something that a DNS message checksum/signature
> cannot provide. On the other hand, DNSSEC requires signatures for each
> RRset bloating messages, whereas a DNS message checksum/signature is
> usually smaller as there is 1 per message.
>
> Anyway, I'll explain with an example why DNSSEC is not sufficient to
> protect against DNS message modifications. Assume a company provides a
> service in different countries. They want users in each country to use
> the local CDN only, let's assume because users have no route to other
> CDNs outside the country or because it's too expensive to service data
> from other countries. They use views in DNS, each serving a different
> country and the A/ records returned by the authoritative server
> provides the correct IP address for that country. Assume that zones in
> these views are signed using the same KSK/ZSK.
>
> This will work fine, but an attacker who has access to country A's
> response may succeed in poisoning a message in country B with A's data
> and DNSSEC validation will not catch it. DNSSEC protects each RRset, but
> not the DNS message.
>

This is accepted risk signatures can be reused for the interval specified,
for any purpose.


> Also, there are other items in a DNS message aside from just signed zone
> data.
>
> As your schema is useless against on-path attacker I recommend you take a
look at
making TKEY +TSIG easier to use, then we get the good property of message
integrity.

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

Re: [DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-ds-remove-00.txt

[Ólafur Guðmundsson]

On Tue, Aug 25, 2015 at 11:02 PM, Shane Kerr sh...@time-travellers.org
wrote:

 Paul,

 On Tue, 25 Aug 2015 18:15:02 -0400 (EDT)
 Paul Wouters p...@nohats.ca wrote:

  On Tue, 25 Aug 2015, Ólafur Guðmundsson wrote:
 
   This is a proposed update the CDS/CDNSKEY processing to address the
 omission in RFC7344.
   Comment please,
 
  As you state, it was an omission on purpose. The document wanted to
  ensure the security state was never changed from insecure - secure.
  I believe it is useful to specify a method for those who can or are
  willing to use it to do so.

 I agree completely.

 Perhaps we can add blinking red letters of warning to the draft for
 users? ;)



 Going from insecure to secure does not have the same property. You can
 bootstrap trust, but it is from a different kind of thing. IIRC, Joao
 added code to the soon-to-be-expired DLV registry which used a nonce
 TXT record to confirm that the person adding to DLV could add TXT
 records to the domain. But there are several attacks which could be
 made that allow this (not likely, but also not possible). DNSSEC trust
 is not the same as ability to update a zone.



I think writing a document on acceptable ways to establish trust  a useful
document but that at this point has no protocol implications for
CDS/CDNSKEY that I can see, thus I prefer to not include that in this
simple protocol document.
Establishing the initial trust is one of the goals of the auto-DS work that
some of us are experimenting with.


 To be clear, I fully support adding such a way to bootstrap DNSSEC
 trust, just pointing out that it is not the same as *removing* DNSSEC
 trust.


 I would also add a note that if you lose the private key, this document
  does not help you go insecure, as an out-of-band method will have to be
  used to signal that.

 True. Seems obvious but probably worth a note. :)

 Will add a note to that extent basically list cases in where you can not
use this to go unsigned.


  IANA would also need to update the algo number 0 from RESERVED to
  something else - eg NO DIGEST.


You are right I need to update the document to reflect the use of 0 as
digest algorithm in DS as the examples stand, not
just the DNSKEY algorithm number.

I guess we could say CDS 0 0 X where X is the algorithm in the current DS
record, but that makes limited sense.
Q: is it better to use DNSKEY algorithm 0 as:  DELETE flag in CDS/CDNSKEY
or should we reserve a different Algorithm code that for that?

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