Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Mark Andrews]

In message 

Re: [DNSOP] ECDSA woes

[Mark Andrews]

In message <20161016223109.6856756c8...@rock.dv.isc.org>, Mark Andrews writes:
> 
> In message 
> , 
> =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= writes:
> > I will be happy to do that,  stay tuned as I need to create a special
> > signer for it :-)
> > 
> > Olafur
> 
> dnssec-signzone + awk + dnssec-dsfromkey works well.
> 
> e.g.
> awk '$4 == "RRSIG" && $6 == 8 { $6 = 99 }
>  $4 == "DNSKEY" && $7 == 8 { $7 = 99}
>  { print }'
> 
> Mark

Which by the way is what we do in our system tests for BIND 9.

#
# A zone with a unknown DNSKEY algorithm.
# Algorithm 7 is replaced by 100 in the zone and dsset.
#
zone=dnskey-unknown.example.
infile=dnskey-unknown.example.db.in
zonefile=dnskey-unknown.example.db

keyname=`$KEYGEN -q -r $RANDFILE -a NSEC3RSASHA1 -b 768 -n zone $zone`

cat $infile $keyname.key >$zonefile

$SIGNER -P -3 - -r $RANDFILE -o $zone -O full -f ${zonefile}.tmp $zonefile > 
/dev/null 2>&1

awk '$4 == "DNSKEY" { $7 = 100; print } $4 == "RRSIG" { $6 = 100; print } { 
print }' ${zonefile}.tmp > ${zonefile}.signed

$DSFROMKEY -A -f ${zonefile}.signed $zone > dsset-${zone}

> 
> > On Sun, Oct 16, 2016 at 4:16 AM, Mikael Abrahamsson 
> > wrote:
> > 
> > > On Sat, 15 Oct 2016, =C3=93lafur Gu=C3=B0mundsson 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
> > >
> > 
> > --94eb2c0cd28c3de9dd053efdf57f
> > Content-Type: text/html; charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> > 
> > I will be happy to do that, =C2=A0stay tuned as I need to =
> > create a special signer for it 

Re: [DNSOP] ECDSA woes

[Mark Andrews]

In message 
, 
=?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= writes:
> I will be happy to do that,  stay tuned as I need to create a special
> signer for it :-)
> 
> Olafur

dnssec-signzone + awk + dnssec-dsfromkey works well.

e.g.
awk '$4 == "RRSIG" && $6 == 8 { $6 = 99 }
 $4 == "DNSKEY" && $7 == 8 { $7 = 99}
 { print }'

Mark

> On Sun, Oct 16, 2016 at 4:16 AM, Mikael Abrahamsson 
> wrote:
> 
> > On Sat, 15 Oct 2016, =C3=93lafur Gu=C3=B0mundsson 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
> >
> 
> --94eb2c0cd28c3de9dd053efdf57f
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> I will be happy to do that, =C2=A0stay tuned as I need to =
> create a special signer for it 

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 
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

[DNSOP] Soliciting feedback for draft-kristoff-dnsop-dns-tcp-requirements

[John Kristoff]

Friends,

If I could trouble you to consider reviewing this and provide any
comments you might have about it, that would be appreciated.  Thank you.

  DNS Transport over TCP - Operational Requirements
  

Abstract

   This document encourages the practice of permitting DNS messages to
   be carried over TCP on the Internet.  It also describes some of the
   consequences of this behavior and the potential operational issues
   that can arise when this best common practice is not applied.

John

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

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett]

On 9 October 2016 at 21:32, Mark Andrews  wrote:

>
> In message  mail.gmail.com>, Matthew Pounsett writes:
> >
> > My first impression of this document is that it is still in need of some
> > extreme editing – mostly for grammar and syntax, but also for clarity and
> > readability.  I've included many of the early problems I found in a list
> > of nits at the end of this email, but at two and three errors per
> paragraph
> > (and occasionally per sentence) it's just too much to cover this way, so
> I
> > stopped noting nits after the first couple of sections.  I suggest such
> > sweeping changes to later sections that any nits I noted there may end up
> > being rewritten anyway.
> >
> > The draft still suffers from inconsistent approaches to the content.  In
> > any given section it might shift from a problem description, to
> > admonishment, to advice for workarounds, and back again without a clear
> or
> > consistent structure.  This makes it difficult to figure out what the
> > intended takeaway is in places.  I've tried to point out specifics below,
> > and suggest better approaches where I can.
> >
> > Don't let my criticism of the document give you the wrong impression.  I
> > think this is useful work, and I'm very appreciative of the work that has
> > gone into it so far.  I just happen to think that there is still work
> left
> > to be done.
> >
> >
> > As for the meat of the matter...
> >
> >
> > In the Introduction, in the paragraph which begins "Unless a nameserver
> is
> > under attack" would it make sense to replace "broken delegations" with
> > "lame delegations"?   We have a term for delegating to a name server
> which
> > is not authoritative for the delegation... we should probably use it.
>
>
>
> > Section 2, "Consequences," seems out of place to me.  It makes a number
> of
> > assertions that seem to follow no particular flow, or pattern.  The line
> > of
> > reasoning or evidence that lead to these assertions has not appeared yet
> > in
> > the document, and so they seem unsupported.  If I'm interpreting the
> > author's intent correctly, perhaps this section should be split up and
> > interspersed into the current section 3 as the direct or indirect
> > consequences of each type of dropped response.
> >
> >
> > The way section 3 is titled and introduced I expect to just see a survey
> > of
> > commonly dropped queries, but the content seems to be inconsistent as to
> > whether it's just a survey, or a survey and advice to client authors
> about
> > working around problems, or just advice without a clear description of
> the
> > problem behaviour.  It seems to me that if the section is intended to be
> > advice to authors, then it should be introduced that way.  Also,
> > clarification for server authors on how they should respond–instead of
> > dropping queries–should probably come before any advice on how to work
> > around dropped queries.
> >
> > If the goal here is to help implementors fix what's broken, then I would
> > suggest each subsection start with a clear description of an observed
> > broken behaviour, followed up with a description of how that behaviour
> > should change (possibly only as a short summary with external references,
> > as we don't want to reproduce whole RFCs here) and then follow that with
> > advice for client authors for working around existing brokenness.
> > Sticking
> > to a pattern–either the one I've suggested or some other–for every query
> > type would make the entire section easier to read.  It will also make it
> > easier for the working group to go through the section item by item and
> > discuss whether we agree on the problem descriptions and proposed
> > remediation.
> >
> > RFC 2119 language is conspicuously absent from this section and SHOULD be
> > added.
> >
> >
> > Section 4, "Remediating", is very problematic.  I think the biggest
> issues
> > stem from two false assertions:
> > 1) "TLD operators are being asked to do this as they...have access to a
> > large numbers of nameserver names as well as contact details for the
> > registrants of those nameservers."
> >
> > This is incorrect.  Or, at least, frequently incorrect.  TLD registries
> > fall into one of two categories: thick or thin.   Thick registries do
> have
> > this information, but a significant number of thin registries exist,
> which
> > delegate the responsibility for maintaining registrant contact
> information
> > to the registrar.  All thin registries know is that a delegation should
> > exist, which name servers are currently supposed to be authoritative for
> > the subzone, and which registrar asked them to create the delegation.
> >
> > This false assertion leads the author down the path of making the TLD
> > registry responsible for contacting registrants.  The third paragraph
> > backpedals a bit on the question of who should be doing what, but then
> the
> > rest of the section goes on to 

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett]

On 10 October 2016 at 12:33, Viktor Dukhovni  wrote:

> On Tue, Oct 11, 2016 at 01:56:42AM +1100, Mark Andrews wrote:
>
> > If the IETF was setting servers that went and checked DNS servers
> > and informed the operators then the IETF would be in the business
> > of enforcing protocols.  At this stage I don't see the IETF doing
> > that nor is this document asking the IETF to do that.
> >
> > The is a difference between innovation and not exercising care /
> > lazyness.
> >
> > Returing FORMERR because you see a EDNS flag you don't understand
> > is not innovation.
> >
> > Returing FORMERR because you see a EDNS option you don't understand
> > is not innovation.
> >
> > Returing FORMERR because you see a EDNS version you don't understand
> > is not innovation.
> >
> > If there was anything innovative in what I'm seeing I'd be all for
> > it but there isn't.
>
> Amen.  This draft documents widely problematic behaviour that is
> seen much too often.  It is good to have it all written down in
> one place.
>

I agree.  It is very useful in that respect.

The specific issue we're discussing here is whether the draft can/should
require certain actions from DNS operators based on the behaviour of child
zones.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ECDSA woes

[Mikael Abrahamsson]

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

[Mikael Abrahamsson]

On Sun, 16 Oct 2016, Geoff Huston wrote:


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.


Ok, thanks! It seems to me that anyone not loading A or B, but loads C, is 
of high interest. They're obviously behind a broken resolver.


Could you please try to create two buckets out of the "does not do ECDSA", 
one being "doesn't understand ECDSA, loads invalid resources" and "doesn't 
load ECDSA resources regardless of valid or not".


I'm very interested in the last of these two, because they're hindering 
rollout of new algorithms. I'd like to understand how big this breakage 
is.


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop