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

[Mark Andrews]

In message <951801333.6319.1491827382096.javamail.zim...@nic.cz>, 
=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= writes:
> Hi there,
>
> I am seeking clarification on NS RRSet completeness
> in AUTHORITY section as we are tackling one particular
> RPL test from Unbound (iter_pcname.rpl).
>
> Imagine a situation where parent (.net/.com NS) gives this glue:
>
> QUESTION
> .example.com. IN A
> ANSWER
> AUTHORITY
> example.com. IN NS ns.example.net.
> example.com. IN NS ns.example.com.
> ADDITIONAL
> ns.example.net. IN A 10.0.0.1
> ns.example.com. IN A 10.0.0.2
>
> ~~~
>
> ns.example.net. gives
>
> QUESTION
> www.example.com. IN A
> ANSWER
> www.example.com. IN A 10.10.10.1
> AUTHORITY
> example.com. IN NS ns.example.com.
> ADDITIONAL
> ns.example.com. IN A 10.0.0.2
>
> ~~~
>
> ns.example.com. just returns SERVFAIL
>
> ~~~
>
> And resolver is asked to resolve:
>
> Step 1:
> www.example.com. -> OK, returns 10.10.10.1
>
> Step 2:
> mail.example.com. -> SERVFAIL, because the NS RRset has been
> overwritten by www.example.com ANSWER data from AUTHORITY
> due RFC 2181 5.4.1 Ranking:
>
> > Data from the authority section of an authoritative answer,
>
> Thus only ns.example.com. is asked and it SERVFAILs.
>
> ~~~
>
> In my understanding it should be ok to return SERVFAIL,
> because there's no way to honor the 5.4.1 Ranking and
> not fail.  Or am I missing something really obvious?

SERVFAIL is fine.  Why people expect the DNS to "work" when they
do stupidity like this I do not know.

The parent zone administrators should be complaining that the
delegating NS records do not match those served by the zone.

Mark

> Ondrej
> --
>  Ondej Sur -- Technical Fellow
>  
>  CZ.NIC, z.s.p.o.-- Laboratoe CZ.NIC
>  Milesovska 5, 130 00 Praha 3, Czech Republic
>  mailto:ondrej.s...@nic.czhttps://nic.cz/
>  
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Evan Hunt]

On Sat, Apr 08, 2017 at 06:32:12PM -0400, Paul Wouters wrote:
> > Resolvers don't ask for ANAME. They ask for A/, and get an A/
> > answer, along with an ANAME record so they can go directly to the source
> > and get a better answer if they support that.
> 
> If these are the premises for ANAME, and its special handling, wouldn't
> it be better to generalise asking for multiple records (eg A + 
> + ANAME) where ANAME has no special handling on its own? And then do the
> generealised multi-query-at-once using one of the previously suggested
> proposals?

I must have been unclear -- I meant the slash to mean "or". This isn't
about getting back multiple records. I did include a MAY in there saying
that if you query for an A you can get  in the additional section, and
vice versa, but that's not the central point of ANAME at all.

This is a mechanism for redirecting address queries. Because it's limited
to address types, it can, unlike CNAME, be used at the zone apex.

So the initial query is going to be for type A or type . (If we ever
invent a third address family, that would count here as well.)  The
response is going to be an ANAME record plus the address you asked for.
That address has to be looked up by the auth in case the querying resolver
doesn't have ANAME support, but if the resolver *does* have ANAME support,
then it repeats the lookup on its own behalf, just as it would do if it got
back a CNAME.

> Then people who want to ask (A +  + TLSA) or (A++SSHFP) or
> (A++IPSECKEY) could use the same mechanism. And ANAME would just be
> a regular DNS record without any abnormal processing.

Fine idea but not related.  ANAME == CNAME for addresses.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld

[Paul Hoffman]

On 10 Apr 2017, at 7:38, Ralph Droms wrote:

I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of 
the document as Informational, while it is listed in the datatracker 
as "In WG Last Call: Proposed Standard".


There are arguments in favor of each status.  The relevant text is in 
section 5 of RFC 6761:


   An IETF "Standards Action" or "IESG Approval" document specifying
   some new naming behaviour, which requires a Special-Use Domain Name
   be reserved to implement this desired new behaviour, needs to 
contain
   a subsection of the "IANA Considerations" section titled "Domain 
Name

   Reservation Considerations" giving answers in the seven categories
   listed below.

Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the 
"Standards Action" requirement.  However, Proposed Standard may not be 
appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not 
specify a new protocol, as such.  draft-ietf-dnsop-alt-tld-08 does 
specify certain behaviors for components of the Internet, which could 
be thought of as providing for interoperability so that Proposed 
Standard status would be appropriate.


On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as 
Informational would require an "IESG Approval" document to meet the 
requirements of RFC 6761.  A short sentence added to 
draft-ietf-dnsop-alt-tld-08 is likely all that would be needed, to the 
effect of "The IESG has reviewed this document and approves of the 
request to add .alt to the Special Use Domain Names registry."


In any event, in my opinion the WG needs to express its explicit 
consensus about its choice of intended status for 
draft-ietf-dnsop-alt-tld-08.


Given that most people don't understand the difference between levels, 
it would take less explanation to make this Standards Track to meet 
"Standards Action" in RFC 6761. But if people want to leave this as 
Informational, I agree with Ralph that a sentence like he has given 
(probably at the end of the Introduction) would be needed for clarity.


--Paul Hoffman

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[John Levine]

In article <44ae341f-0424-14c7-2834-656991d40...@bellis.me.uk> you write:
>> Many TLD registries simply don't permit CNAMEs instead of delegations
>> for their customer domains.
>> 
>> The only one I've heard of that does is .de
>
>My real point being that the parent / child relationship can have policy
>rules in place that prevent things that are technically completely possible.

True, but the most common broken CNAME I see is something like this:

example.com MX 0 mail.example.com
example.com CNAME www.example.com

www.example.com A 1.2.3.4

I agree that if we go ahead with this document, a paragraph pointing
to the ways that CNAMEs don't solve the problem would be helpful.

R's,
John

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

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dnssec-sha3-01

[Bob Harold]

On Mon, Apr 10, 2017 at 5:38 AM, Mukund Sivaraman  wrote:

> Hi all
>
> > A new version of I-D, draft-muks-dnsop-dnssec-sha3-01.txt
> > has been successfully submitted by Mukund Sivaraman and posted to the
> > IETF repository.
> >
> > Name: draft-muks-dnsop-dnssec-sha3
> > Revision: 01
> > Title:Use of SHA-3 (Keccak) and RSASSA-PSS in DNSSEC
> > Document date:2017-04-08
> > Group:Individual Submission
> > Pages:26
> > URL:https://www.ietf.org/internet-drafts/draft-muks-dnsop-
> dnssec-sha3-01.txt
> > Status: https://datatracker.ietf.org/
> doc/draft-muks-dnsop-dnssec-sha3/
> > Htmlized:   https://tools.ietf.org/html/
> draft-muks-dnsop-dnssec-sha3-01
> > Htmlized:   https://datatracker.ietf.org/doc/html/draft-muks-dnsop-
> dnssec-sha3-01
> > Diff:   https://www.ietf.org/rfcdiff?
> url2=draft-muks-dnsop-dnssec-sha3-01
> >
> > Abstract:
> >This document specifies the use of SHA-3 (Keccak) hash functions in
> >DNSSEC.  It also specifies the use of the RSASSA-PSS signature scheme
> >for RSA keys.
>
> A new revision of the draft has been uploaded:
>
> - It now uses the RSASSA-PSS signature scheme (based on comments from
>   Paul Hoffman & Francis) and adds RSASSA-PSS/SHA3-256,
>   RSASSA-PSS/SHA3-384 and RSASSA-PSS/SHA3-512 for using SHA-3.
>
> - It adds algorithms for RSASSA-PSS/SHA2-256 and RSASSA-PSS/SHA2-512 to
>   use the SHA-2 algorithms with RSASSA-PSS.
>
> - It adds algorithms for ECDSA/SHA3-256 and ECDSA/SHA3-384.
>
> - It now has a better problem statement in the introduction (based on
>   contents of reply from Paul Hoffman)
>
> - BIND implementation has been updated here:
>   https://github.com/muks/bind9/tree/sha3
>
> - An independently written ldns implementation is here:
>   https://github.com/tjeb/ldns
>
> Mukund
>

Looking at the diff
https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dnssec-sha3-01
is difficult because some of the DNSSEC example lines are not wrapped.
I don't know if that can be fixed.

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

Re: [DNSOP] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld

[Ralph Droms]

I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of the 
document as Informational, while it is listed in the datatracker as "In WG Last 
Call: Proposed Standard".  

There are arguments in favor of each status.  The relevant text is in section 5 
of RFC 6761:

   An IETF "Standards Action" or "IESG Approval" document specifying
   some new naming behaviour, which requires a Special-Use Domain Name
   be reserved to implement this desired new behaviour, needs to contain
   a subsection of the "IANA Considerations" section titled "Domain Name
   Reservation Considerations" giving answers in the seven categories
   listed below.

Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the 
"Standards Action" requirement.  However, Proposed Standard may not be 
appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not specify a 
new protocol, as such.  draft-ietf-dnsop-alt-tld-08 does specify certain 
behaviors for components of the Internet, which could be thought of as 
providing for interoperability so that Proposed Standard status would be 
appropriate.

On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as Informational 
would require an "IESG Approval" document to meet the requirements of RFC 6761. 
 A short sentence added to draft-ietf-dnsop-alt-tld-08 is likely all that would 
be needed, to the effect of "The IESG has reviewed this document and approves 
of the request to add .alt to the Special Use Domain Names registry."

In any event, in my opinion the WG needs to express its explicit consensus 
about its choice of intended status for draft-ietf-dnsop-alt-tld-08.

- Ralph

> On Apr 7, 2017, at 9:38 AM, Suzanne Woolf  wrote:
> 
> Hi,
> 
> We had initially scheduled the WGLC on this document to be over by now. 
> However, the flurry of activity around the review we were asked to do on the 
> homenet-dot draft, and the general traffic level on the list during IETF 98, 
> suggested to the chairs that we should extend the WGLC.
> 
> We’re hereby formally extending it to next Wednesday, April 12.
> 
> As always for WGLC— we need to hear both support and opposition for taking 
> this draft to the next step in the process.
> 
> thanks,
> Suzanne  & TIm
> 
> 
>> On Apr 1, 2017, at 4:17 PM, Stephane Bortzmeyer  wrote:
>> 
>> On Sun, Mar 12, 2017 at 07:20:55PM -0400,
>> Suzanne Woolf  wrote 
>> a message of 92 lines which said:
>> 
>>> This message opens a Working Group Last Call for:
>>> 
>>> "The ALT Special Use Top Level Domain"
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
>>> 
>> 
>> I've read -08 and I believe I understand this draft. I'm not convinced
>> it's useful (most users of alternative resolution systems won't use it
>> and, anyway, I'm not even sure it will be added in the Special-Use
>> registry, which was wrongly frozen by the IESG) but I don't see big
>> issues with the draft, it seems to me it correctly describes the new
>> TLD.
>> 
>> Editorial :
>> 
>> Section 1:
>> 
>> "and that should not be resolved" I cannot parse it. Missing "it"?
>> 
>> Section 5 :
>> 
>> After "and anyone watching queries along the path", add a reference to
>> RFC 7626?
>> 
>> Normative references:
>> 
>> Why is RFC 6303 a normative reference? It is no longer used.
>> 
>> Why is RFC 7686 a normative reference? It is just an example.
>> 
> 
> ___
> 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 ANAME draft: draft-hunt-dnsop-aname-00.txt

[Jan Včelák]

On Fri, Apr 7, 2017 at 8:11 PM, Evan Hunt wrote:
> Here's the new ANAME draft I mentioned last week.

Hey, thanks for this one! I support the attempt to define a record
type that would cover the existing vendor-specific types that
synthesize A/ records in zone apex. If this gets adopted by the
vendors, it means possible zone transfers between these providers. On
the other hand, I don't like the part which moves ANAME processing to
resolvers. I'll comment on that separately.

Besides that, The Security Section should warn DNS operators that
ANAME may be misused to leak data from any internal networks the
server is part of. This was so far concern for resolvers, but with
ANAME it may become a concern for authoritative servers as well.

Jan

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

[DNSOP] Registration requirement (Was: Re: I-D Action: draft-ietf-dnsop-attrleaf-02.txt)

[Dave Crocker]

On 3/31/2017 8:52 AM, Stephane Bortzmeyer wrote:

On Wed, Mar 29, 2017 at 08:15:45AM -0700,
  internet-dra...@ietf.org  wrote
  a message of 43 lines which said:


 Title   : DNS Scoped Data Through Global '_Underscore' Naming 
of Attribute Leaves
 Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-02.txt


Section 5 "IANA considerations" does not use the names of standard
policies. draft-leiba-cotton-iana-5226bis, currently in the RFC editor


Thanks.  I hadn't registered that issue...



queue, says "It is not strictly required that documents use these
terms [the standard policies]; the actual requirement is that the
instructions to IANA be clear and unambiguous.  However, use of these
terms is strongly recommended because their meanings are widely
understood."

Therefore, I suggest to replace "have been specified in any published
RFC, or are documented by a specification published by another
standards organization" by "specification required (RFC 5226bis,
section 4.6).


Hmm. The IANA draft's 'Specification Required' (Section 4.6) imposes a 
requirement both for a designated expert AND the existence of a publicly 
published spec.


My original thought was that this registry should have a concern for 
stability of the reference using it, but not impose much of a barrier in 
terms of quality.  (I figured that the other document's standards 
criteria would suffice for that.)


While some registries do need careful quality control for each entry, 
this doesn't seem like it should be one of them.  The namespace is 
essentially infinite, so we don't have to worry about exhaustion, and I 
don't see much downside in letting the market decide whether the entry 
is useful.


So on reflection, I'm starting to wonder about instead going to the 
lesser First Come First Served (Section 4.4 of the IANA draft).  This 
should encourage early (pre-standards) registration.


It also should cover established practice that doesn't provide the level 
of documentation one would wish for.  Which fact you've nicely 
documented next...



Thoughts?



Also, the proposed initial registry includes:

  SPF| _spf | "TXT" | [RFC7372]

RFC 7372 contains *nothing* about that, and SPF (RFC 7208) does not
use undesrscore names.


(Yeah.  RFC 7372 is wrong.  It should be RFC 7208.  However...)


1. RFC 7208 notes the TXT ambiguity problem

   3.  SPF Records
   ...
   Since TXT records have multiple uses, beware of other TXT records
   published there for other purposes.  They might cause problems with
   size limits (see Section 3.4), and care has to be taken to ensure
   that only SPF records are used for SPF processing.

2. It requires use of TXT

   3.1.  DNS Resource Records

   SPF records MUST be published as a DNS TXT

4.  All of the examples that explicit show the TXT RR show domain names 
that do NOT use a _spf node name.  (sigh)


5.  However the document also is littered with examples of using ._spf. 
(sigh)


6.  And finally, industry documentation for SPF is loaded with 
directions for use of ._spf.  E.g.,


 http://www.openspf.org/FAQ/Common_mistakes

 Sometimes an ISP will create a special SPF record that customers
 can include with their record, such as _spf.example.com.


So we have extensive, established practice, though one could wish for a 
(much) better specification.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Sara Dickinson]

> On 6 Apr 2017, at 19:42, Bob Harold  wrote:
> 
> 
> On Tue, Mar 28, 2017 at 4:34 PM, IETF Secretariat 
> > 
> wrote:
> 
> The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in
> state
> Candidate for WG Adoption (entered by Tim Wicinski)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/ 
> 
> 
> 
> I support adoption

+1

> and will review.

Me too. 

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

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

[Ondřej Surý]

Hi there,

I am seeking clarification on NS RRSet completeness
in AUTHORITY section as we are tackling one particular
RPL test from Unbound (iter_pcname.rpl).

Imagine a situation where parent (.net/.com NS) gives this glue:

QUESTION
.example.com. IN A
ANSWER
AUTHORITY
example.com. IN NS ns.example.net.
example.com. IN NS ns.example.com.
ADDITIONAL
ns.example.net. IN A 10.0.0.1
ns.example.com. IN A 10.0.0.2

~~~

ns.example.net. gives

QUESTION
www.example.com. IN A
ANSWER
www.example.com. IN A 10.10.10.1
AUTHORITY
example.com. IN NS ns.example.com.
ADDITIONAL
ns.example.com. IN A 10.0.0.2

~~~

ns.example.com. just returns SERVFAIL

~~~

And resolver is asked to resolve:

Step 1:
www.example.com. -> OK, returns 10.10.10.1

Step 2:
mail.example.com. -> SERVFAIL, because the NS RRset has been
overwritten by www.example.com ANSWER data from AUTHORITY
due RFC 2181 5.4.1 Ranking:

> Data from the authority section of an authoritative answer,

Thus only ns.example.com. is asked and it SERVFAILs.

~~~

In my understanding it should be ok to return SERVFAIL,
because there's no way to honor the 5.4.1 Ranking and
not fail.  Or am I missing something really obvious?

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

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-wireformat-http-01.txt

[Shane Kerr]

Petr,

At 2017-04-07 09:38:05 +0200
Petr Špaček  wrote:

> Hello,
> 
> On 28.3.2017 16:58, 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   : DNS wire-format over HTTP
> > Authors : Linjian Song
> >   Paul Vixie
> >   Shane Kerr
> >   Runxia Wan
> > Filename: draft-ietf-dnsop-dns-wireformat-http-01.txt  
> 
> Version draft-ietf-dnsop-dns-wireformat-http-01 is the first one I
> reviewed and it is a good read. No objections to current version.
> 
> Are there any implementations?

There are two and a half implementations, one in C by Paul Vixie and one
in Go by BII, plus a client-side version in Javascript (ug) by me.

https://github.com/BII-Lab/DNSoverHTTP
https://github.com/BII-Lab/DNSoverHTTPinGO
http://www.blij.tk:/

Cheers,

--
Shane


pgpK4VZmNn7Qs.pgp
Description: OpenPGP digitale handtekening
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Ray Bellis]

On 10/04/2017 11:39, I wrote:

> Many TLD registries simply don't permit CNAMEs instead of delegations
> for their customer domains.
> 
> The only one I've heard of that does is .de

My real point being that the parent / child relationship can have policy
rules in place that prevent things that are technically completely possible.

Ray

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Ray Bellis]

On 10/04/2017 11:04, Peter van Dijk wrote:

> Why this is not possible seems obvious to me, but we’ll see what we can
> write.

Many TLD registries simply don't permit CNAMEs instead of delegations
for their customer domains.

The only one I've heard of that does is .de

Ray

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Peter van Dijk]

On 10 Apr 2017, at 11:29, Florian Weimer wrote:


On 04/07/2017 08:11 PM, Evan Hunt wrote:

Title:  Address-specific DNS Name Redirection (ANAME)


I think the introduction should discuss why it is not possible to push 
the CNAME to the parent zone, replacing the entire zone with an alias.


Why this is not possible seems obvious to me, but we’ll see what we 
can write.


Section 3 is currently written in such a way that a recursive DNS 
lookup must be performed at the authoritative server side.  I don't 
think it is necessary to require that.  A recursive DNS lookup of the 
target is just one way to implement this.


What other ways did you have in mind?

In particular, the suggested recursive DNS lookup needs some form of 
distributed loop detection.  Otherwise, a malicious customer could 
publish two zones with ANAME records and achieve significant traffic 
amplification, potentially taking down the DNS hoster.  A hop count in 
an EDNS option or an “ANAME lookup in progress” indicator would be 
one way to implement this.  Another approach would impose restrictions 
on the owner name of an ANAME record and its target, and restrict 
where CNAMEs can appear, so that a valid ANAME can never point to 
another valid ANAME.


I’m not sure it’s feasible to forbid chaining ANAMEs. I do agree 
there is a vector for DoS here. Section 6 currently cowardly says 
“Both authoritative servers and resolvers that implement ANAME should 
carefully check for loops and treat them as an error condition.” but I 
am aware that more words are needed.


Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

[DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dnssec-sha3-01

[Mukund Sivaraman]

Hi all

> A new version of I-D, draft-muks-dnsop-dnssec-sha3-01.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
>
> Name: draft-muks-dnsop-dnssec-sha3
> Revision: 01
> Title:Use of SHA-3 (Keccak) and RSASSA-PSS in DNSSEC
> Document date:2017-04-08
> Group:Individual Submission
> Pages:26
> URL:
> https://www.ietf.org/internet-drafts/draft-muks-dnsop-dnssec-sha3-01.txt
> Status: https://datatracker.ietf.org/doc/draft-muks-dnsop-dnssec-sha3/
> Htmlized:   https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dnssec-sha3-01
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dnssec-sha3-01
>
> Abstract:
>This document specifies the use of SHA-3 (Keccak) hash functions in
>DNSSEC.  It also specifies the use of the RSASSA-PSS signature scheme
>for RSA keys.

A new revision of the draft has been uploaded:

- It now uses the RSASSA-PSS signature scheme (based on comments from
  Paul Hoffman & Francis) and adds RSASSA-PSS/SHA3-256,
  RSASSA-PSS/SHA3-384 and RSASSA-PSS/SHA3-512 for using SHA-3.

- It adds algorithms for RSASSA-PSS/SHA2-256 and RSASSA-PSS/SHA2-512 to
  use the SHA-2 algorithms with RSASSA-PSS.

- It adds algorithms for ECDSA/SHA3-256 and ECDSA/SHA3-384.

- It now has a better problem statement in the introduction (based on
  contents of reply from Paul Hoffman)

- BIND implementation has been updated here:
  https://github.com/muks/bind9/tree/sha3

- An independently written ldns implementation is here:
  https://github.com/tjeb/ldns

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Florian Weimer]

On 04/07/2017 08:11 PM, Evan Hunt wrote:

Title:  Address-specific DNS Name Redirection (ANAME)


I think the introduction should discuss why it is not possible to push 
the CNAME to the parent zone, replacing the entire zone with an alias.


Section 3 is currently written in such a way that a recursive DNS lookup 
must be performed at the authoritative server side.  I don't think it is 
necessary to require that.  A recursive DNS lookup of the target is just 
one way to implement this.


In particular, the suggested recursive DNS lookup needs some form of 
distributed loop detection.  Otherwise, a malicious customer could 
publish two zones with ANAME records and achieve significant traffic 
amplification, potentially taking down the DNS hoster.  A hop count in 
an EDNS option or an “ANAME lookup in progress” indicator would be one 
way to implement this.  Another approach would impose restrictions on 
the owner name of an ANAME record and its target, and restrict where 
CNAMEs can appear, so that a valid ANAME can never point to another 
valid ANAME.


Thanks,
Florian

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

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Peter van Dijk]

On 10 Apr 2017, at 1:04, Richard Gibson wrote:

On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk 


wrote:

This section calls for limiting the TTL of cached address records to 
the
lesser of the ANAME TTL and the TTL of the retrieved address 
records, but
section 3 requires servers to follow chained responses. Are the TTLs 
of

intermediate records in a chain supposed to be ignored?



What was the response on this point?


Oh, right. I suppose the right answer would be to take the lowest of all 
involved TTLs.


Right; I definitely think there should be text explicitly defining 
behavior
for timeouts, nonzero RCODEs, and bogus responses received when 
looking up
ANAME targets. Section 4 covers part of it (for recursive servers 
only),
but doesn't define how to determine when "resolution fails" or what to 
do
when not opting to use the accompanying records as a fallback, and 
there is

no guidance at all for authoritative servers.


Agreed.


*Section 3.2*


The wording of this section could use some improvement. It seems to
prohibit secondary servers from resolving ANAME targets when they 
are
present at the same domain as address types... do I understand 
correctly?




Yes, that is correct. We went through a few iterations and thought
exercises and this seemed like the optimal behaviour.



Dyn went another way with our ALIAS functionality, reserving 
same-domain
address record sets for fallback data to be used whenever target 
resolution

doesn't yield records of the appropriate type (including, perhaps
controversially, NXDOMAIN and NODATA empty responses). Assuming a 
secondary
server predating ANAME, the Dyn behavior would be slightly better when 
the
primary server is ignorant of that gap (i.e., the secondary would 
always

serve fallback data) and identical behavior when it is not (i.e., the
authoritative would pre-expand as the draft specifies in Section 5). 
It
also provides support for multi-type host names with single-type 
targets,
e.g. static  records sharing a domain with an ALIAS targeting a 
name
providing only A records. Where it really shines, though, is in 
handling

error cases like those discussed above—it was very important to our
customers that they could prevent us from ever issuing cacheable 
negative

responses. What thought exercises took you in this direction?


Working back from the premise that there -will- be ANAME unaware 
secondaries, we allow primaries to do the ANAME expansion during 
outgoing AXFR (or on load, but in any case the secondary gets actual 
(signed!) A/ records). Thus, such a secondary will simply serve the 
A/. To keep things simple, we decided that an ANAME aware auth will 
do the same, so behaviour is consistent.


The alternative, of defining those records as fallback, means that ANAME 
aware slaves that -do- receive a pre-expanded A/ set, need 
configuration knobs to figure out if they should look up the ANAME 
target or not. We could automate this to a limit - say, if you are a 
slave, you understand ANAME, and you do not have the private key for the 
zone, then obviously you have to use what you find in the zone. However, 
it was my feeling that this would yield more complexity than we want.


Anyway, I will ponder your use case.

As for ‘ from config, A from ANAME’, we’ve been discussing 
allowing multiple ANAMEs at a node, and then you could do something like 
this:


www.example.com. ANAME www-v6.example.com.
www.example.com. ANAME example.com.my-cdn.com
www-v6.example.com.  2001:db8::80

Are such address records still subject to TTL decrementing 
(presumably
starting at the time of zone transfer)? And when only a single 
address

type
is present (e.g., just ANAME and A), does that still prevent 
resolution of

the ANAME target for the other type?



(1) Yes, they are still subject to TTL decrementing, but if the slave 
is
not ANAME-aware, no decrementing will happen and the draft allows 
this, if

we wrote it all down correctly.
(2) Yes, when any address records are present, the ANAME is deemed to 
have
already been expanded. If A is there and no , then this means 
that

there is in fact no  to be had.


I understand the motivation, but there's an interesting wrinkle with
respect to forward compatibility... what happens when a new address 
type is
added to the DNS? The assumption that pre-expansion of any address 
type
implies pre-expansion of all address types seems like it could lead to 
some

dramatic changes in behavior as primary servers, secondary servers,
resolvers, and targeted zones become aware of the new type in a 
nonuniform

fashion. Has any consideration been given to that concern?


Not by me so far, I’ll readily admit. Will ponder.

On a related note, should recursive resolvers query for ANAME targets 
even

when they *don't* correspond to A or  QTYPEs?


Probably not.

It is also mute on the use of DNSSEC for resolving ANAME target 
records,

but that should