Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

[Matthijs Mekking]

On 6/20/23 17:14, John Levine wrote:

It appears that Matthijs Mekking   said:

Hi,

I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed to overloading).


Agreed.


A note on where to send CDS and CSYNC notifications. I sort of
understand why the NOTIFY record includes a RRtype field, but will
parental entities really have a different target for receiving notifies
for CDS and CSYNC?


I've talked to Peter at some length.  The problem is that you will often have
different targets for different children of the same parent, i.e., registrars
rather than registries, and I don't see any good way of putting per-child
info in the parent, particularly a large parent like .ORG or .COM.


If there are different targets for different children of the same 
parent, then a generic NOTIFY record like below won't work anyway.


parent.   IN NOTIFY CDS   scheme port scanner.parent.



The existing NOTIFY for AXFR is perfectly usable without a mechanical
way to say where to send the notifications, so my proposal is to
continue not to have one. All of the existing AXFR NOTIFY receivers I
know have ACLs to only accept notifications from relevant primary
servers, often hidden ones not visible in the DNS, so even if the
proposal in 5.1 didn't have scaling problems, it only addresses half
the problem. So take it out.


I guess if the targets are fairly static, then putting it in the 
configuration rather than sticking it in the DNS will be good enough.


Matthijs




R's,
John

___
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] Multiple drafts discussing the use of DNS NOTIFY

[Matthijs Mekking]

Hi,

On 6/10/23 21:42, Tim Wicinski wrote:

All

The chairs have been looking at two different drafts discussing the use 
of using DNS NOTIFY to update DNSSEC information.  The two drafts are:


https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify-01 


https://datatracker.ietf.org/doc/html/draft-dsawp-notify-00 



Mr Thomassen's draft is a bit more ambitious than Mr. Levine's draft, 
but both appear to work on the problem space of DNSSEC update 
automation.  The chairs are big fans of work around making DNSSEC 
deployment more operationally resilient.


We have some questions for the WG - if DNSOP adopted one of these, would 
DNS server vendors implement it down the road? (We think so)


I would definitely want to implement a CDS notify to the parent. It 
would help getting rid of the wasteful polling and we can reuse existing 
NOTIFY code. It feels like a good Hackathon project :)


It looks to me that this mechanism consists of three parts:

1. Notify the parent of a CDS/CDNSKEY/CSYNC change.
2. Notify a signer in a multi-signer group of DNSKEY/CDS/CDNSKEY change.
3. Locating the server to notify (NOTIFY record).

It seems that John Levine's draft is mainly covering part 1, while the 
draft from Johan and Peter covers all three.


I don't know if all three parts should be covered in one document, 
although they are strongly connected to each other.


I think the part about multi-signer may face the biggest challenges (see 
my comments on the Generalized DNS Notifications draft), so I if that 
turns out to slow down things, I wouldn't mind focusing on DS automation 
first, and perhaps a successor document that can tackle the multi-signer 
scenario.


Best regards,

Matthijs

The ICANN SSAC has been looking at this issue, so the ICANN meeting this 
coming week may be a good time for technical folks to discuss some of 
these ideas.


Feedback Welcome

thanks
tim



___
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-01)

[Matthijs Mekking]

Hi,

I like this draft because of it tackles the issues of wasteful CDS 
polling and it uses NOTIFY, a mechanism that is well known, already 
exists in implementations, and actually feels like a good fit (as 
opposed to overloading).




A note on where to send CDS and CSYNC notifications. I sort of 
understand why the NOTIFY record includes a RRtype field, but will 
parental entities really have a different target for receiving notifies 
for CDS and CSYNC?


For the sender of the notifies, this may be cumbersome to do different 
lookups that probably end up being the same target.


Related to this, when it comes to the multi-signer model, you do not 
only need to send DNSKEY notifications, but also CDS and CSYNC 
notifications to the other signers, especially if you want these RRsets 
to be consistent with each other. Follwing up on the example in Section 
5.1 that would mean we need additional NOTIFY records:


child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerA.
child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerB.
child.parent. IN NOTIFY DNSKEY 1 5361 ctrl.multi-signer.example.
child.parent. IN NOTIFY CDS 1 5361 scanner.signerA.
child.parent. IN NOTIFY CDS 1 5361 scanner.signerB.
child.parent. IN NOTIFY CDS 1 5361 ctrl.multi-signer.example.
child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerA.
child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerB.
child.parent. IN NOTIFY CSYNC 1 5361 ctrl.multi-signer.example.

That becomes quite a set already.

Perhaps we should differentiate on type of server (parent, signer, ...) 
rather than RRtype?




Finally, about the open question for DNSKEY notifications. You say: As 
the number of signers for a particular zone is low, there is no major 
problem caused by not knowing which signer sent the notification and 
instead always check all the signers for updates to the DNSKEY RRset.


How would you identify which is the newer DNSKEY RRset? If the 
multi-signer controller checks two signers and receives the following 
RRsets:


example.nl. 3600 IN DNSKEY 257 3 13 I5Cq...
example.nl. 3600 IN DNSKEY 257 3 13 Hkpb...

example.nl. 3600 IN DNSKEY 257 3 13 I5Cq...
example.nl. 3600 IN DNSKEY 257 3 13 Hkpb...
example.nl. 3600 IN DNSKEY 257 3 13 1Wut...

How would it know if a DNSKEY was added or removed from the RRset. This 
obviously requires some state. And I suspect it works slightly different 
again in a decentralized model.


This likely can all be solved, but it needs to be specified, and cannot 
be dismissed as "probably not a major problem".




Best regards,

Matthijs



On 2/20/23 13:20, Peter Thomassen wrote:

Dear DNSOP,

Thank you for the very helpful feedback provided by several people on 
the -00 revision back in November.


Johan and I made changes to the document that incorporate the insights 
from the crowd, and resolved some other issues. The result is -01, 
attached below. If you are interested, please take a read.


We're looking forward to further feedback here and/or at IETF 116. Thanks!

Best,
Peter



 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-generalized-dns-notify-01.txt

Date: Fri, 10 Feb 2023 08:25:23 -0800
From: internet-dra...@ietf.org
To: Johan Stenstam , Peter 
Thomassen 



A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-01.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:    draft-thomassen-dnsop-generalized-dns-notify
Revision:    01
Title:    Generalized DNS Notifications
Document date:    2023-02-10
Group:    Individual Submission
Pages:    16
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.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-01.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-generalized-dns-notify-01


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 

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

[Matthijs Mekking]

Hi,

From the draft:

   For example, a single provider may (accidentally or
   maliciously) cause another provider's trust anchors and/or
   nameservers to be removed from the delegation.

This is exactly what happened in my test environment when putting BIND 9 
to the multi-signer test where one server chooses to keep the CDS and 
CDNSKEY RRset published, keeping it in sync with the DS RRset, and the 
other removes the CDS and CDNSKEY records as soon as you detect that the 
desired DS RRset is published.


The existing documents lack any words on where specifically to query for 
CDS/CDNSKEY, and also what to do in case of inconsistencies.


Therefor, I support adoption of this draft and am willing to review.

Matthijs


On 6/7/23 17:52, Tim Wicinski wrote:


All,

We've had this document in DNSOP for a bit and Peter has presented three 
different meetings. When I went back and looked at the minutes, the 
feedback was good.  But when the chairs and Warren discussed it, we had 
confused ourselves on this document, which is our bad.  We decided to 
stop confusing ourselves and let the working group help us out.


What I did was to pull the comments on this document from the minutes of 
the meetings and include them below to make it easier to remember what 
was said.



This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency

The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ 



Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 21 June 2023

Thanks,
tim wicinski
For DNSOP co-chairs

Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC is 
Mandatory"




114
     Mark: CDS records are no different than any others
         One NS might be down, which would stop the
         Peter: This is telling the parent how to act when faced with
inconsistent information
     Viktor: There might be hidden masters
         Don't want to get stuck
         Peter: Wording could be changed to allow servers down
     Ben: There is a missing time constant
         When do I recheck if I get an inconsistent set?
         Peter: 7344 doesn't put any time limit
         Ben: Should suggest some time to retry when there is an
inconstancy

115
     Wes: Supports this
         Likes mandating checking everywhere
     Ralf: Supports this
         Can't ask "all" servers in anycast
         What if you don't get a response
         Peter: Ask each provider
             Is willing to add in wording about non responses
         Paul Wouters: This wasn't in CSYNC, our bug
     Viktor: Concern was hidden masters and nameservers that are gone
and are never going to come back


116
     Viktor: Corner case: if someone is moving to a host that doesn't
do DNSSEC
         Peter: Could add a way to turn off DNSSEC on transfer
     Johan Stenstram: Breaks the logic that "if it is signed, it is
good"
         Doesn't like "if this is really important"
         Let's not go there
         Authoritative servers are proxies for the registrant
         Out of sync is reflection on the registrant: business issues
     Wes: CSYNC was for keeping DNS up and running
         CSYNC can't fix the business problems
     Peter: Agrees that one signature should be OK
         Other parts of the spec also suggest asking multiple places


___
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] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Matthijs Mekking]

On 25-11-2021 13:00, Petr Špaček wrote:

On 25. 11. 21 9:33, Matthijs Mekking wrote:



3.2.  Recommendation for validating resolvers

I understand why the new text is here, but I think this now actually 
gives too little advice for operators and vendors.


I know, this is a vague comment, I need to think about it a bit more.


Honestly I can't see anything more specific which will not get out of 
date quickly.


Can we make use of the keyword MAY? This allows I think for text that 
will not get out of date:


   Validating resolvers MAY return an insecure response when processing
   NSEC3 records with iterations larger than 0. Validating resolvers MAY
   also return SERVFAIL when processing NSEC3 records with iterations
   larger than 0. This significantly decreases the requirements
   originally specified in Section 10.3 of [RFC5155]. See the Security
   Considerations for arguments on how to handle responses with non-zero
   iteration count.

Having text that says "MAY do this at value X" is more quantifiable and 
IMO a stronger signal that zone publishers really should not use value X.



Best regards,

Matthijs

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

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Matthijs Mekking]

Hi Wes,

I think the changes are moving the document in the right direction.

Some comments:


3.1.  Best-practice for zone publishers

I wonder if we can make the requirement even stronger by saying "If 
NSEC3 must be used, then an iterations count of 0 MUST be used to 
alleviate computational burdens." (MUST instead of SHOULD).


Or is there a valid reason for zone publishers to set iterations to a 
non-zero value?



3.2.  Recommendation for validating resolvers

I understand why the new text is here, but I think this now actually 
gives too little advice for operators and vendors.


I know, this is a vague comment, I need to think about it a bit more.


3.2.  Recommendation for validating resolvers

   Validating resolvers returning an insecure or SERVFAIL answer because
   of unsupported NSEC parameter values SHOULD return an Extended DNS
   Error (EDE) EDNS0 option of value.

I believe this should be NSEC3 parameter values here (instead of NSEC).


4.  Security Considerations

I appreciate that you added the reasoning for lowering the acceptable 
iteration counts here and in section 3.2 but I miss the argument for not 
lowering. Suggested text:


   On the other hand, zones that are still using high iteration counts
   may become unreachable on some parts of the network when a resolver
   decides to return SERVFAIL above a higher point. Before lowering the
   acceptable iteration count, resolver operators and resolver software
   vendors are encouraged to monitor the used iteration counts and reach
   out to zone publishers to implement this document by setting the
   iteration count to 0.


Appendix E.  Implementation Notes

Note that BIND 9.16.16 and up will treat DNSSEC responses containing 
NSEC3 records with iteration counts greater than 150 are now treated as 
insecure, and the maximum supported number of NSEC3 iterations that can 
be configured for a zone has been reduced to 150.



Best regards,

Matthijs


On 24-11-2021 18:02, Wes Hardaker wrote:

internet-dra...@ietf.org writes:


 Title   : Guidance for NSEC3 parameter settings
 Authors : Wes Hardaker
   Viktor Dukhovni
Filename: draft-ietf-dnsop-nsec3-guidance-02.txt
Pages   : 10
Date: 2021-11-24


This version attempts to take into account the discussion from the WG
meeting at IETF 112.  Concrete text proposals appreciated so we can
finish this work and publish it.



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

Re: [DNSOP] nsec3-parameters opinions gathered

[Matthijs Mekking]

I concur with Benno.

For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.

We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.

But we will likely not implement blindly a maximum that will cause lots
of operational problems.

Best regards,

Matthijs

On 11/5/21 5:09 PM, Benno Overeinder wrote:
> Wes,
> 
> On 05/11/2021 09:40, Vladimír Čunát wrote:
>> On 04/11/2021 23.44, Wes Hardaker wrote:
>>> The most important sticking point is there are 4 implementations (thank
>>> you for the links Matthijs) that have implemented 150.  Since DNSOP
>>> strives for implementations of specs, I think this is the number we
>>> should publish*unless the vendors speak up and say they'll drive lower*.
>>
>> I'm convinced that 150 was just a quick stop-gap compromise and that
>> from the start vendors expected that dnsop might set it lower later.
>> Therefore I don't think this *argument* for keeping 150 is really valid.
>>
>> As for Knot Resolver, I see no problem in setting the hard limit
>> lower, especially if that gets published in this RFC.  From Viktor I
>> gather that 100 shouldn't cause issues even at this moment, especially
>> if it's only a limit for downgrading to insecure (which won't be even
>> noticed by most DNS consumers).  So personally I expected the draft to
>> lower the bound to <=100, though as I said... for us the *overall*
>> performance ratio from e.g. 150 -> 50 isn't that large.
> 
> For Unbound, we have no problem setting the iteration cap to a value
> lower than the current 150.  If Viktor's analysis shows a limit of 100
> is feasible without (m)any problems for operators, and this value will
> be adopted in the soon-to-be-released RFC, we will use the new limit value.
> 
> 
> Cheers,
> 
> -- Benno
> 
> 

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

Re: [DNSOP] How does NSEC record(s) prove the Name Error?

[Matthijs Mekking]

Hi,

The short answer is "find the closest encloser and determine the source
of synthesis.

I can recommend reading RFC 4592 "The Role of Wildcards in the Domain
Name System" to understand better how wildcards work.

I can recommend reading RFC 7129 "Authenticated Denial of Existence in
the DNS" to understand how NSEC proofs work.


On 10/27/21 7:21 AM, Joey Deng wrote:
> Hi Folks,
> 
> I have a very basic question about NSEC record in DNSSEC validation:
> 
> How does NSEC record(s) prove the Name Error?
> 
> In [RFC 4035 5.4. Authenticated Denial of
> Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4
> ), it says:
> 
>>o  If the requested RR name matches the owner name of an
>>   authenticated NSEC RR, then the NSEC RR's type bit map field lists
>>   all RR types present at that owner name, and a resolver can prove
>>   that the requested RR type does not exist by checking for the RR
>>   type in the bit map.  If the number of labels in an authenticated
>>   NSEC RR's owner name equals the Labels field of the covering RRSIG
>>   RR, then the existence of the NSEC RR proves that wildcard
>>   expansion could not have been used to match the request.
>>
>>o  If the requested RR name would appear after an authenticated NSEC
>>   RR's owner name and before the name listed in that NSEC RR's Next
>>   Domain Name field according to the canonical DNS name order
>>   defined in [RFC4034 ], 
>> then no RRsets with the requested name exist
>>   in the zone.  However, it is possible that a wildcard could be
>>   used to match the requested RR owner name and type, so proving
>>   that the requested RRset does not exist also requires proving that
>>   no possible wildcard RRset exists that could have been used to
>>   generate a positive response.
>>
> 
> I can understand the first point, because it is an exact name matching.
> However, what makes me feel confused is the second one:
> 
> If the question name appears in-between the current owner name and the
> next owner name of the NSEC record, which means that there is no exact
> name matching:
> We should prove that
>> no possible wildcard RRset exists that could have been used to generate a 
>> positive response.
> 
> But it does not describe how to prove it,
> 
> What are possible wildcard RRsets for a given name?

For a given name, find the closest encloser and calculate the source of
synthesis: *.. The resource records for the source of
synthesis in the zone give you the possible wildcard RRsets.


> My understanding about possible wildcard RRsets for a given name are all
> the possible sources of synthesis.
> For example, the possible wildcard RRsets that can be used to answer
> question .ietf.org   are:
> *.ietf.org 
> *.org
> * (but I think root can never be a wildcard, so this is impossible)
> 
> Is my understanding correct?

No, in this example it can only answer for *.ietf.org, as "ietf.org" is
the closest encloser for "www.ietf.org".

> 
> 
> For example, if I send a DNS query for .ietf.org
>  with DO/CD bit set, there will be two NSEC
> records returned:
...
> 
> The two returned NSEC records are:
> wwwtest.ietf.org . -> xml2rfc.ietf.org
> .
> ietf.org . -> _dmarc.ietf.org .
> 
> If we follow the steps described by [RFC 4035 5.4. Authenticated Denial
> of Existence](https://datatracker.ietf.org/doc/html/rfc4035#section-5.4
> ), we will
> find that:
> 
> wwwtest.ietf.org . -> xml2rfc.ietf.org
> . tells us that the exact name match for
> .ietf.org  does not exist, since it appears
> in-between the two names. Therefore, the remaining ietf.org
> . -> _dmarc.ietf.org . NSEC
> should be used to prove that “no possible wildcard RRset exists that
> could have been used to generate a positive response” for the name
> .ietf.org .
> 
> Therefore, my question is:
> *How can ietf.org . -> _dmarc.ietf.org
>  NSEC be used to prove that there is no wildcard
> record for the name .ietf.org ?* Do we need to
> prove that all the possible sources of synthesis for .ietf.org
>  appear in-between ietf.org . and
> _dmarc.ietf.org ?

The NSEC record ietf.org -> _dmarc.ietf.org proves that there is no
source of synthesis for ".ietf.org" so we could not have generated a
wildcard response (note there is only ever one source of 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Matthijs Mekking]

Hi,

On 26-10-2021 01:56, Roy Arends wrote:



On 20 Oct 2021, at 14:14, libor.peltan 
wrote:

Hi all,

although for me, as an implementer of an auth server, it's not too
important, I'd like to ask for clarification regarding the foreseen
reporting domain(s) setup in the (usual) case of many secondary
auth servers.

The draft says: "Each authoritative server SHOULD be configured
with a unique reporting agent domain."

I see two possible error situations:

1) the zone itself is wrongly signed, so all secondaries share the
same error 2) some of the secondaries respond wrongly from
correctly signed zone, so the error is slave-specific

IMHO the case (2) is far less common. And the case (1) doesn't
require per-secondary reporting domain, just per-zone.

Is it really recommended (in capitals) that the zone operator
prepares extra reporting domain for each secondary around the world
(it can be hundreds)?


If you have outsourced your secondaries to a company that has hundreds 
of secondaries I guess you can also set up a reporting agent domain like 
"company1.reporting-agent.example". and 
"company2.reporting-agent.example". It won't tell you exactly which 
server caused the problem, but at least it gives you some idea without 
having to set up hundreds of domains.


But I am also not convinced that the recommendation needs to be in capitals.



The domain owner may have contracts with more than one operator. The
operator may operate many authoritative servers, which not all serve
the same set of zones.

If the reporting agent domain is unique, the erroneous server can be
pinpointed faster. If all auth servers for a domain have the same
reporting agent domain, the reporting agent knows there is an error,
just doesn’t know where.


If so, it can cause a disclosure about which secondary the answer
is comming from, dunno if some zone operators are not willing to
conceal this.


In that case, the zone operator doesn’t have to deploy EDE reporting,
right?


The zone operator may still be interested in knowing about resolving 
issues. And DNS error reporting would still work if you have just a 
single reporting agent domain.



Matthijs




Roy



Thanks!

Libor

Dne 27. 04. 21 v 16:47 internet-dra...@ietf.org napsal(a):

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   : DNS Error Reporting Authors : Roy
Arends Matt Larson Filename:
draft-ietf-dnsop-dns-error-reporting-00.txt Pages   : 12 
Date: 2021-04-27


Abstract: DNS Error Reporting is a lightweight error reporting
mechanism that provides the operator of an authoritative server
with reports on DNS resource records that fail to resolve or
validate, that a Domain Owner or DNS Hosting organization can use
to improve domain hosting. The reports are based on Extended DNS
Errors [RFC8914].

When a domain name fails to resolve or validate due to a 
misconfiguration or an attack, the operator of the authoritative 
server may be unaware of this.  To mitigate this lack of

feedback, this document describes a method for a validating
recursive resolver to automatically signal an error to an agent
specified by the authoritative server.  DNS Error Reporting uses
the DNS to report errors.


The IETF datatracker status page for this draft is: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/





There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-dnsop-dns-error-reporting-00



https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-00



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




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

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

[Matthijs Mekking]

IIRC the vendors agreed on 150 for two reasons:

1. There are still a fair amount of zones using this value. Only a 
handful of zones where using above 150.


2. Resolvers could still cope with such numbers pretty confidently.

I agree lower is better, but let's not pick a number randomly, but have 
data to back up that number.


- Matthijs

On 21-10-2021 15:28, Miek Gieben wrote:
[ Quoting  in "Re: [DNSOP] wrapping up 
draft-ietf-..." ]
I don't know what the -right- value is, but I know what I want: 0 
iterations, empty salt, otherwise the NSEC3 gets ignored, presumably 
leading to SERVFAIL. This removes the 'insecure' window completely.


So, I'll support any push to lower the numbers.

Editorial nit, already hinted at above: the text currently has 
"Validating resolvers MAY return SERVFAIL when processing NSEC3 
records with iterations larger than 500." - I suggest changing this 
to "validating resolvers MAY ignore NSEC3 records with iterations 
larger than 500". That way, zones in the middle of a transition from 
1000 to 0 iterations do not get punished. Zones at 1000, not in a 
transition, will still get SERVFAIL by virtue of the NSEC3 proof 
missing (because it is ignored).


In addition, the line just before that says "Validating resolvers SHOULD
return an insecure response when processing NSEC3 records with
iterations larger than 100."

And I suggest to change it to "larger than 150", a value that open
source DNS vendors have been adopting over the last couple of months:


I would recommend against using a limit that happens to be in use at the 
current time, and
would just use 100 (or even lower). Resolvers will continue to work fine 
and can lower their

limit at their leisure.

/Miek

--
Miek Gieben


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

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

[Matthijs Mekking]

On 21-10-2021 13:22, Peter van Dijk wrote:

On Wed, 2021-10-20 at 11:24 -0700, Wes Hardaker wrote:

So, the question: what's the right FINAL value to put in the draft
before LC?


I don't know what the -right- value is, but I know what I want: 0 iterations, 
empty salt, otherwise the NSEC3 gets ignored, presumably leading to SERVFAIL. 
This removes the 'insecure' window completely.

So, I'll support any push to lower the numbers.

Editorial nit, already hinted at above: the text currently has "Validating resolvers MAY 
return SERVFAIL when processing NSEC3 records with iterations larger than 500." - I suggest 
changing this to "validating resolvers MAY ignore NSEC3 records with iterations larger than 
500". That way, zones in the middle of a transition from 1000 to 0 iterations do not get 
punished. Zones at 1000, not in a transition, will still get SERVFAIL by virtue of the NSEC3 proof 
missing (because it is ignored).


In addition, the line just before that says "Validating resolvers SHOULD
return an insecure response when processing NSEC3 records with 
iterations larger than 100."


And I suggest to change it to "larger than 150", a value that open 
source DNS vendors have been adopting over the last couple of months:


https://nlnetlabs.nl/news/2021/Aug/12/unbound-1.13.2-released/

https://blog.powerdns.com/2021/06/09/powerdns-recursor-4-4-4-and-4-5-2-released/

https://www.knot-resolver.cz/2021-03-31-knot-resolver-5.3.1.html

https://bind9.readthedocs.io/en/v9_16_21/notes.html#notes-for-bind-9-16-16

(sorry that this is not pushing for lower numbers)

Best regards,

Matthijs

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

Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)

[Matthijs Mekking]

I am going to assume that the DNSKEY of this zone is not a trust anchor.

So it is going to use the DS RRset, not a cached DNSKEY RRset, to 
authenticate the child zone's apex DNSKEY RRset (the one from the 
response). Then from RFC 4035:


 o  The matching DNSKEY RR in the child zone has the Zone Flag bit
set, the corresponding private key has signed the child zone's
apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
child zone's apex DNSKEY RRset.

I read this as the cached DNSKEY RRset does not come into play when 
validating the DNSKEY RRset from the response, and any implementation 
that does otherwise is not compliant.


- Matthijs

On 24-09-2021 15:01, Paul Wouters wrote:

On Fri, 24 Sep 2021, Matthijs Mekking wrote:

Second, I believe the corner case you mentioned is for Figure 15 (the 
one in Appendix D), and I don't understand the scenario you are 
describing. What do you mean with "the resolver getting the DNKSEY 
RRset for NS_B would not contain a valid key for the DNSKEY RRset of 
NS_B". I think the resolver would get a new DNSKEY RRset with a 
pre-fetch (or if the DNSKEY RRset was expired from cache) and that 
would be validated with the DNSKEY from the response.


If it has a valid unexpired DNSKEY RRset, and a resolver fetches that
DNSKEY RRset again, will it use the cached DNSKEY RRset or the DNSKEY RRset
from the fetched record set to validate the signature against the cached
DS RRset ? Or is this implementation specific?

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] [Technical Errata Reported] RFC6781 (6692)

[Matthijs Mekking]

Paul,

On 23-09-2021 15:52, Paul Wouters wrote:

On Thu, 23 Sep 2021, Matthijs Mekking wrote:


You are referring to text that describes Figure 10.

The following text in Section 4.3.5.1 refers to the figure in Appendix D:

   The requirement to exchange signatures has a couple of drawbacks.  It
   requires more operational overhead, because not only do the operators
   have to exchange public keys but they also have to exchange the
   signatures of the new DNSKEY RRset.  This drawback does not exist if
   the Double-Signature KSK rollover is replaced with a Double-DS KSK
   rollover.  See Figure 15 in Appendix D for the diagram.


I don't think that changes my reply regarding the corner case of needing
the RRSIG - but that would be a different errata from the one reported.
I would still be interested to hear from implementers on that corner
case.


See below.


...

 It states "combined with a Double-Signature KSK rollover". So the
 appendix tables does describe what it claims. Wether it is required
 to combine sharing public ZSK's with a Double-Signature KSK is
 another question, and based on some scribbling I think it is better
 to indeed include it:

 A clean cache resolver will get to the parent and obtain NS_A, DS_A and
 DS_B. It then goes to the child at A (because it did not get an NS_B)
 and gets the DNSKEY RRset from Child A. This contains only 1 KSK,
 DNSKEY_K_A. So it must use DS_A to confirm validation. After a while
 for other data in the zone, it might query for data on NS_B and get
 some data signed by DNSKEY_Z_B but the existing DNSKEY RRset covers
 that key, so there is no problem. Even if it needs to re-query for
 the DNSKEY RRset on NS_B and it only gets DNSKEY_K_B (and not
 DNSKEY_K_A), it could match the DNSKEY RRset to DS_B and it would
 be fine.

 What might be a corner case though, is if the first queried DNSEY RRset
 (from NS_A) has not yet expired - eg when it is being pre-fetched. At
 that point, the resolver getting the DNSKEY RRset for NS_B would not
 contain a valid key for the DNSKEY RRset of NS_B (DNSKEY_K_B is missing
 from the set on NS_A). It would be a bit implementation specific on 
what

 would happen (or perhaps this is specified in some DNSSEC RFC?). One
 implementation could decide that since the RRSIG fails, to re-validate
 the DNSKEY RRset using the parent DS RRset. But it could also assume
 it has a valid DNSKEY RRset and this new query is just missing the
 proper signature. So I believe it would be more robust to proceed as
 is specified in Appendix D.


First, I think you mean it would be more robust to proceed as is 
specified in Figure 10, right? The rollover that publishes both DNSKEYs 
of both providers in each version of the zone (Double-Signature KSK 
rollover).


Second, I believe the corner case you mentioned is for Figure 15 (the 
one in Appendix D), and I don't understand the scenario you are 
describing. What do you mean with "the resolver getting the DNKSEY RRset 
for NS_B would not contain a valid key for the DNSKEY RRset of NS_B". I 
think the resolver would get a new DNSKEY RRset with a pre-fetch (or if 
the DNSKEY RRset was expired from cache) and that would be validated 
with the DNSKEY from the response.



- Matthijs

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

Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)

[Matthijs Mekking]

Paul,

You are referring to text that describes Figure 10.

The following text in Section 4.3.5.1 refers to the figure in Appendix D:

   The requirement to exchange signatures has a couple of drawbacks.  It
   requires more operational overhead, because not only do the operators
   have to exchange public keys but they also have to exchange the
   signatures of the new DNSKEY RRset.  This drawback does not exist if
   the Double-Signature KSK rollover is replaced with a Double-DS KSK
   rollover.  See Figure 15 in Appendix D for the diagram.

Best regards,

Matthijs

On 23-09-2021 05:08, Paul Wouters wrote:

On Wed, 22 Sep 2021, RFC Errata System wrote:

Figure 15 in Appendix D is depicting the phases of a double DS KSK 
rollover operator change.  One rationale for applying this approach is 
to avoid the exchange of signatures (RRSIGs) between operators, and 
limit exchanges to the public parts of the ZSKs in use.  In the 
pre-publish phase in the figure, it is shown that Child A publishes a 
signature over the DNSKEY RRset generated by Child B's KSK, and that 
Child B publishes a signature over the DNSKEY RRset generated by Child 
A's KSK.  This is contrary to the rationale given for this method, and 
also not required, since the pre-published double DS RRs at the parent 
zone should enable a validator to validate the signature generated by 
any of the two KSKs in use, thus one RRSIG RR for the DNSKEY RRset is 
sufficient at each child.  Therefore, the RRSIG_K_B(DNSKEY) RR should 
be removed from Child A, and the RRSIG_K_A(DNSKEY) should be removed 
from Child B.


I am not sure you are correct. Your description is slightly different from
the Section 4.3.5.1 this Appendix D belongs to:


    In this environment, the change could be made with a Pre-Publish ZSK
    rollover, whereby the losing operator pre-publishes the ZSK of the
    gaining operator, combined with a Double-Signature KSK rollover where
    the two registrars exchange public keys and independently generate a
    signature over those key sets that they combine and both publish in
    their copy of the zone.


It states "combined with a Double-Signature KSK rollover". So the
appendix tables does describe what it claims. Wether it is required
to combine sharing public ZSK's with a Double-Signature KSK is
another question, and based on some scribbling I think it is better
to indeed include it:

A clean cache resolver will get to the parent and obtain NS_A, DS_A and
DS_B. It then goes to the child at A (because it did not get an NS_B)
and gets the DNSKEY RRset from Child A. This contains only 1 KSK,
DNSKEY_K_A. So it must use DS_A to confirm validation. After a while
for other data in the zone, it might query for data on NS_B and get
some data signed by DNSKEY_Z_B but the existing DNSKEY RRset covers
that key, so there is no problem. Even if it needs to re-query for
the DNSKEY RRset on NS_B and it only gets DNSKEY_K_B (and not
DNSKEY_K_A), it could match the DNSKEY RRset to DS_B and it would
be fine.

What might be a corner case though, is if the first queried DNSEY RRset
(from NS_A) has not yet expired - eg when it is being pre-fetched. At
that point, the resolver getting the DNSKEY RRset for NS_B would not
contain a valid key for the DNSKEY RRset of NS_B (DNSKEY_K_B is missing
from the set on NS_A). It would be a bit implementation specific on what
would happen (or perhaps this is specified in some DNSSEC RFC?). One
implementation could decide that since the RRSIG fails, to re-validate
the DNSKEY RRset using the parent DS RRset. But it could also assume
it has a valid DNSKEY RRset and this new query is just missing the
proper signature. So I believe it would be more robust to proceed as
is specified in Appendix D.

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] [Technical Errata Reported] RFC6781 (6692)

[Matthijs Mekking]

I believe this errata is correct.

On 22-09-2021 16:18, RFC Errata System wrote:

The following errata report has been submitted for RFC6781,
"DNSSEC Operational Practices, Version 2".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6692

--
Type: Technical
Reported by: Jarle Fredrik Greipsland 

Section: Appendix D

Original Text
-
 
 new DS |pre-publish|
 
 Parent:
  NS_ANS_A
  DS_A DS_B   DS_A DS_B
 
 Child at A:Child at A:Child at B:
  SOA_A0 SOA_A1 SOA_B0
  RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)

  NS_A   NS_A   NS_B
  RRSIG_Z_A(NS)  NS_B   RRSIG_Z_B(NS)
 RRSIG_Z_A(NS)

  DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
 DNSKEY_Z_B DNSKEY_Z_B
  DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
  RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
 RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)
 


Corrected Text
--
 
 new DS |pre-publish|
 
 Parent:
  NS_ANS_A
  DS_A DS_B   DS_A DS_B
 
 Child at A:Child at A:Child at B:
  SOA_A0 SOA_A1 SOA_B0
  RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)

  NS_A   NS_A   NS_B
  RRSIG_Z_A(NS)  NS_B   RRSIG_Z_B(NS)
 RRSIG_Z_A(NS)

  DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
 DNSKEY_Z_B DNSKEY_Z_B
  DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
  RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)
 


Notes
-
Figure 15 in Appendix D is depicting the phases of a double DS KSK rollover 
operator change.  One rationale for applying this approach is to avoid the 
exchange of signatures (RRSIGs) between operators, and limit exchanges to the 
public parts of the ZSKs in use.  In the pre-publish phase in the figure, it is 
shown that Child A publishes a signature over the DNSKEY RRset generated by 
Child B's KSK, and that Child B publishes a signature over the DNSKEY RRset 
generated by Child A's KSK.  This is contrary to the rationale given for this 
method, and also not required, since the pre-published double DS RRs at the 
parent zone should enable a validator to validate the signature generated by 
any of the two KSKs in use, thus one RRSIG RR for the DNSKEY RRset is 
sufficient at each child.  Therefore, the RRSIG_K_B(DNSKEY) RR should be 
removed from Child A, and the RRSIG_K_A(DNSKEY) should be removed from Child B.

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.

--
RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
--
Title   : DNSSEC Operational Practices, Version 2
Publication Date: December 2012
Author(s)   : O. Kolkman, W. Mekking, R. Gieben
Category: INFORMATIONAL
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



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

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

[Matthijs Mekking]

I support the document to become a working group document, and I am 
willing to review.


Best regards,

Matthijs

On 10-05-2021 10:55, Benno Overeinder wrote:

Hi all,

As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP 
meeting, we want to start a call for adoption of 
draft-hardaker-dnsop-nsec3-guidance on the mailing list.


With the presentation at the DNSOP meeting on IETF 110, there was a 
sufficient general support in the (virtual) room to adopt the draft as a 
working group document.


Now we will start a period of two weeks for the call for adoption of 
draft-hardaker-dnsop-nsec3-guidance on the mailing list.


The draft is available here: 
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.


Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.


Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 24 May 2021


Thanks,

-- Benno

DNSOP co-chair

___
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-nsec-ttl-03.txt

[Matthijs Mekking]

Peter,

Personally I still think we shouldn't change these SHOULDs to MUSTs. 
Quoting from RFC 2119:


1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I think the text you provided on incremental signers is such a valid 
reason why we should use SHOULD here instead of MUST.


If the WG consensus is that this does need to change to a MUST then I 
would like to request the following adaptations to the draft.


- The text should update the updates to include the exception. For
  example:

   |  The TTL of the NSEC RR that is returned MUST be the lesser of the
   |  MINIMUM field of the SOA record and the TTL of the SOA itself.
   |  This matches the definition of the TTL for negative responses in
   |  [RFC2308]. A signer MAY cause the TTL of the NSEC RR to have a
   |  deviating value after the SOA record has been updated, to allow
   |  for an incremental update of the NSEC chain.

- There should be a reason provided in the document why these SHOULD
  keywords are changed to a MUST.

Best regards,

Matthijs



On 09-02-2021 22:06, Peter van Dijk wrote:

Hello dnsop,

thank you to all who responded in the WGLC thread. After the discussion
I felt I had nothing to ask or add, so instead, here is a draft
revision that I feel addresses everything that was said.

(Matthijs, this revision changes the requirements back to MUST as that
feels like it more closely matches the majority opinion voiced, but I
added a section allowing for the incremental signer situation - please
let me know if this is workable for you.)

My understanding of the discussion is that the document failed to
address various assorted vagueness, and separations between developer
and operator concerns, and role differences between signers,
authoritatives and resolvers/validators, in the original documents.
Paul Hoffman provided a bunch of text clarifying 'what goes where' so
that this document can improve that situation, thanks Paul!

Changes in this version, as listed in the Document History section:

* document now updates resolver behaviour in 8198
* lots of extra text to clarify what behaviour goes where (thanks Paul
Hoffman)
* replace 'any' with 'each' (thanks Duane)
* upgraded requirement level to MUST, plus a note on incremental
signers

Your comments are, again, very much welcome.

On Tue, 2021-02-09 at 12:17 -0800, 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 WG of the IETF.

 Title   : NSEC and NSEC3 TTLs and NSEC Aggressive Use
 Author  : Peter van Dijk
Filename: draft-ietf-dnsop-nsec-ttl-03.txt
Pages   : 9
Date: 2021-02-09

Abstract:
Due to a combination of unfortunate wording in earlier documents,
aggressive use of NSEC and NSEC3 records may deny names far beyond
the intended lifetime of a denial.  This document changes the
definition of the NSEC and NSEC3 TTL to correct that situation.  This
document updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-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/




Kind regards,



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

Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

[Matthijs Mekking]

On 03-02-2021 20:31, Paul Hoffman wrote:

For each of these, I'd recommend specifying what a client does in each of the 
cases, rather than weasel wording the SHOULD with respect to the zone contents 
to turn this into an implementable protocol.


Here, I agree that the draft is unclear. It should say explicitly "resolvers keep 
doing $z, there is no change here". Also, for the text about authoritative servers, 
I agree that changing the SHOULDs from the current standards to MUSTs.


Changing this to MUST means that every time a zone changes its SOA TTL 
or SOA MINIMUM value, the whole chain of NSEC/NSEC3 records need to be 
updated accordingly immediately. That may be undesirable for a large zone.


BIND for example would make such a change incrementally, so there may be 
a period of time where the NSEC/NSEC3 records still have the TTL of the 
previous SOA TTL/MINIMUM value. With a SHOULD keyword we can keep this 
behavior. With a MUST less so, I think.


So I am against changing these SHOULDs to MUSTs.

Best regards,

Matthijs

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

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

[Matthijs Mekking]

Hi Peter,

I reviewed the draft and it mostly looks good. Some minor comments:

1. Perhaps instead of using ".com" as an example, use ".example" (per 
RFC 2606)?


2. Shouldn't this document also update some text parts from RFC 8198?

3. About this paragraph:

   Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is
   only possible for negative (NXDOMAIN/NoData NOERROR) responses, and
   not for wildcard responses.

I think it deserves a separate section or subsection within section 4, 
and not be tucked away in the acknowledgements.


Also this should be a bit more verbose, it took me three times to 
understand what is exactly said here.


Proposed text:


   [RFC 8198] says:

   With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL
   of the NSEC/NSEC3 record and the SOA.MINIMUM field are the
   authoritative statement of how quickly a name can start working
   within a zone.

  Here, the SOA.MINIMUM field cannot be changed to "the minimum of the
  SOA.MINIMUM field and the SOA TTL" because the resolver may not have
  the SOA RRset in cache. However, if authoritative servers follow the
  updates from this document, this should not make a difference, as the
  TTL of the NSEC/NSEC3 record is already set to the minimum value.


Ralph can of course still be acknowledged for the helpful pointer.


- Matthijs




On 23-11-2020 21:16, Peter van Dijk wrote:

Hello,

in
https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017420.html
(and earlier messages in March on the same thread), people realised
that aggressive NSEC caching might use a much longer TTL than the
negative TTL intended by a zone operator.

The initial idea was to correct this in an erratum to RFC 8198
(aggressive use of NSEC/NSEC3), but Ralph Dolmans pointed out to me
that this would not solve the wildcard case.

I did a lightning talk on the topic at OARC 29 (
https://indico.dns-oarc.net/event/29/sessions/98/#20181013), where the
audience feedback, as I recall it, was agreeable to my suggestion of
'issuing operational guidance'.

I have since come to the conclusion that it would be better to also fix
this in software. Hence, please find below my draft that updates one
sentence in 4034 and the ~same sentence in 5155. As far as I can see,
no correction to 8198 is necessary or useful.

Any editorial comments are welcome via GitHub (link is in the draft),
private email, or this WG list. Any functional comments on the content,
please post them to the WG. Thank you.

(Warren, if you feel the wording of my acknowledgement lays blame with
you in a way that you'd rather not see immortalised in an RFC, please
let me know!)

Kind regards,



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

Re: [DNSOP] [Ext] Call for Adoption: draft-vandijk-dnsop-nsec-ttl

[Matthijs Mekking]

Hi,


On 11-12-2020 23:41, Paul Hoffman wrote:

On Dec 11, 2020, at 1:42 PM, Tim Wicinski 
wrote:


So this call should be less controversial.  I read Peter's draft
(thanks for poking us on this) and it does clean up existing
documents.

With this call, we're only looking to *objections* to adopting this
work. Please speak up and if there objections, we can review

This starts a Call for Adoption for draft-vandijk-dnsop-nsec-ttl

The draft is available here:
https://datatracker.ietf.org/doc/draft-vandijk-dnsop-nsec-ttl/


This call for adoption ends: 28 December 2020


Please adopt. I will review, but cannot implement. (It would be grand
if implementers could report whether they are already doing this or,
if not, how much effort it would be for them to change.)


I support adoption. BIND 9 is not yet doing this, but a fix was easily 
made and we will release it early 2021 to version 9.16 and up.


Best regards,

Matthijs

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

Re: [DNSOP] What is the purpose of NSEC3 "closest encloser" proofs?

[Matthijs Mekking]

Hello Nick,

The closest encloser proof is explained in RFC 7129, Section 5.5.

https://tools.ietf.org/html/rfc7129#section-5.5

Best regards,

Matthijs

On 10/9/20 1:46 AM, Nick Johnson wrote:
> I'm reading RFC 5155, and I'm a bit puzzled by the requirement for
> "closest encloser" proofs to prove nonexistence of a domain. Given that
> the RFC requires generating NSEC3 records on empty non-terminals, isn't
> it sufficient to examine a single NSEC3 record to prove nonexistence?
> 
> For example, if I want to prove the nonexistence of a.b.c.example, isn't
> it sufficient to validate an NSEC3 record that covers that name and is
> one level higher (eg, somehash.b.c.example)? Why do I need to prove the
> closest-encloser with a second NSEC3 record?
> 
> -Nick Johnson
> 
> ___
> 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] status of the aname and svcb/httpsvc drafts

[Matthijs Mekking]

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote:
> "DNSOP"  wrote on 02/26/2020 08:34:55:
> 
>> From: "Vladimír Čunát" 
>> To: "dnsop@ietf.org WG" 
>> Cc: "Andrew M. Hettinger" 
>> Date: 02/26/2020 08:35
>> Subject: Re:  [External]  [DNSOP] status of the aname and svcb/httpsvc
> drafts
>> Sent by: "DNSOP" 
>>
>> On 2/25/20 8:07 PM, Andrew M. Hettinger wrote:
>> > Frankly, you've got it exactly the wrong way around: even with httpsvc
>> > speced out completely, it will take time for it to be deployed to
>> > browsers. That's assuming you can get enough buying from (mostly)
>> > google to even make it happen at all.
>>
>> I don't think it's so simple.  The current ANAME draft specifies new
>> behavior for resolvers, and there I'd expect even slower overall
>> upgrades/deployment than in browsers.  Also I'm unsure how big a part of
>> authoritative implementations will want to do ANAME expansion.  (It
>> seems unlikely for "our" Knot DNS, for example.)
>>
> 
> Is there actually a commitment from browser makers to implement it?

ANAME and its proprietary friends try to solve the issue it within the
DNS, so there is no need for commitment from browser makers.

- Matthijs

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

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

[Matthijs Mekking]

Shane,

There has been no discussions and no progress on ANAME since July 2019.
If ANAME is something that (part of) the working group wants to work on,
it requires more interaction, discussion to solve the final issues (see
the github page https://github.com/each/draft-aname/).

Best regards,
  Matthijs

On 2/20/20 10:59 AM, Shane Kerr wrote:
> Matthijs,
> 
> On 20/02/2020 09.29, Matthijs Mekking wrote:
>>
>>
>> On 2/18/20 5:17 PM, Olli Vanhoja wrote:
>>>
>>> On Tue, Feb 18, 2020, 16:20 Klaus Malorny >> <mailto:klaus.malo...@knipp.de>> wrote:
>>>
>>>
>>>  I asked myself about the status of the two drafts. I got the
>>>  impression a little
>>>  bit that the svcb/httpsvc draft successfully killed the aname
>>> draft,
>>>  but is now
>>>  dying slowly itself. It would be great if somebody could give me
>>>  some insight
>>>  whether the one or the other has still a measurable heartbeat, to
>>>  stay with the
>>>  allegories ;-)
>>>
>>>
>>> SVCB is active almost every day of the week in GitHub.
>>>
>>> I can't talk on behalf of the authors of the ANAME draft, but to me it
>>> seems that SVCB is getting more traction and it addresses the core
>>> problems that ANAME was supposed to solve.
>>
>> ANAME was supposed to solve the CNAME at the apex problem and mitigate
>> against DNS vendor lock in. Both SVCB and HTTPSSCV do not fix this
>> problem.
>>
>> But yeah, the draft is pretty much dead due to lack of interest.
> 
> Is there a lack of interest? That's not clear to me. I think rather
> there are DNS folks who don't like ANAME for philosophical reasons and
> actively strive to prevent it moving forward.
> 
> Cheers,
> 
> -- 
> Shane
> 
> ___
> 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] status of the aname and svcb/httpsvc drafts

[Matthijs Mekking]

On 2/18/20 5:17 PM, Olli Vanhoja wrote:
> 
> On Tue, Feb 18, 2020, 16:20 Klaus Malorny  > wrote:
> 
> 
> I asked myself about the status of the two drafts. I got the
> impression a little
> bit that the svcb/httpsvc draft successfully killed the aname draft,
> but is now
> dying slowly itself. It would be great if somebody could give me
> some insight
> whether the one or the other has still a measurable heartbeat, to
> stay with the
> allegories ;-)
> 
> 
> SVCB is active almost every day of the week in GitHub.
> 
> I can't talk on behalf of the authors of the ANAME draft, but to me it
> seems that SVCB is getting more traction and it addresses the core
> problems that ANAME was supposed to solve.

ANAME was supposed to solve the CNAME at the apex problem and mitigate
against DNS vendor lock in. Both SVCB and HTTPSSCV do not fix this problem.

But yeah, the draft is pretty much dead due to lack of interest.

- Matthijs

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

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

[Matthijs Mekking]

On 1/27/20 8:34 PM, Shumon Huque wrote:
> On Tue, Jan 21, 2020 at 11:41 AM Matthijs Mekking
> mailto:matth...@pletterpet.nl>> wrote:
> 
> Shumon,
> On 1/21/20 4:05 PM, Shumon Huque wrote:
> >
> > This also begs the question: should we (in another document)
> update RFC
> > 4035, Section 2.2 (last paragraph) to relax or eliminate the rule,
> if in
> > fact it is being ignored?
> >
> > Frankly, I've always been a bit perplexed by this text, since it
> has no
> > accompanying rationale. The only compelling rationale I see is
> downgrade
> > protection - to detect that someone hasn't stripped away the
> signatures
> > of a stronger algorithm and forced a validator to authenticate
> only the
> > weaker signatures. But that implies that validators have a documented
> > procedure to rank algorithms, which I haven't yet seen. Is a 3072-bit
> > RSASHA256 key stronger or weaker than an ECDSAP256SHA256 key for
> > example, or Ed25519 vs ECDSAP256SHA256?
> 
> Yes, this is exactly the rationale, and it is a valid one. And this is
> how unbound works, see
> https://nlnetlabs.nl/documentation/unbound/info-algo/ for more
> information.
> 
> 
> Thanks for that pointer.
> 
> The downgrade protection rationale is in contradiction with the spec
> though. Unbound is going significantly beyond the spec, although the
> stated rationale is to require all algorithm paths to authenticate,
> rather than the strongest available path.

Not the strongest available path, but all the available paths.

> To quote https://tools.ietf.org/html/rfc6840#section-5.11 (last
> paragraph):
> 
>    This requirement applies to servers, not validators.  Validators
>    SHOULD accept any single valid path.  They SHOULD NOT insist that all
>    algorithms signaled in the DS RRset work, and they MUST NOT insist
>    that all algorithms signaled in the DNSKEY RRset work.

I was part of that discussion advocating against it, but the best I
could do I guess is to make it a SHOULD NOT. This means you can go
against this recommendation for valid reasons and unbound finds the
downgrade protection a valid reason.

> Furthermore, the above paragraph appears to me to be at odds with the
> requirements about signatures being present for every algorithm in
> the DNSKEY/DS RRsets. Given the above rule for validators (which
> incidentally precludes downgrade protection), the only requirement for
> interoperability on the part of authority servers is to ensure that
> one valid authentication path always exists (and not to require signing
> by every algorithm present).
> 
> I'm disregarding for the moment the somewhat outdated wording in the
> specs about algorithms required to "sign the entire zone" - which doesn't
> contemplate the existence of online signers, which only generate signatures
> on demand for queried names. The authority server requirement also causes
> a problem for the case that Steve Crocker raises, about moving a signed
> zone from one operator to another, where the operators support disjoint
> algorithms.

I acknowledge that the specification is focused on offline signing, but
online signers just pretend that they have signed the entire zone. So I
don't see any issue with the phrase "sign the entire zone".

Moving a signed zone between operators with disjoint algorithms is not
much explored yet. The closest to this scenario is perhaps a move
between non-cooperating DNS operators described in RFC 6781, Section
4.3.5.2 and it recommends to go insecure for the duration of the change.


> I agree in principle, that absent other information, algorithm downgrade
> protection is probably a good thing. But in the general case, a validator
> cannot know the intentions of the zone owner's use of multiple algorithms.
> And the distinct-algorithm + multi-provider DNSSEC case is one where this
> can pose a deployment problem.

"cannot know the intentions" is hitting the nail on the head. The lack
of such signalling is why a validator has to make its own decision to be
more relaxed or more strict.


> In any case, I don't think we can quickly resolve this issue in favor
> of an approach that works reliably for our draft. So I will take your
> suggestion and and put in the "must" language about same algorithms.

Thanks.

Best regards,

Matthijs


> If we encounter real deployments in the field that require a solution
> to this problem, we can revisit it in a future revision.
> 
> -- 
> Shumon.
> 

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

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

[Matthijs Mekking]

On 1/21/20 6:03 PM, Tony Finch wrote:
> Matthijs Mekking  wrote:
> 
>> I am not sure how they executed the algorithm rollover precisely.
>> Particularly, were there ever two DS records in the root zone with
>> different algorithms for these zones?
> 
> I can answer that :-)
> 
> Algorithm rollovers have to be double-KSK rollovers because DS records
> have to have a subset of the algorithms of the DNSKEY records. Having both
> algorithms in the DS record can only slow down the rollover so it's hard
> to think of situations where it would make sense (other than Shumon's
> multi-provider disagreement!)

As I suspected, in that case they were never candidate for the multiple
algorithms check.

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

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

[Matthijs Mekking]

Shumon,


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

If so, then technically they were not conform the RFC, but but I am not
sure how they executed the algorithm rollover precisely. Particularly,
were there ever two DS records in the root zone with different
algorithms for these zones?

>From what I could find, both rollovers did actually sign with double
algorithms though:

See https://static.ptbl.co/static/attachments/179548/1529933472.pdf:

Aug 20 .br Algorithm Rollover Begin (all times UTC)at 06:00 Zones
double signed with old and new algorithm

And on this blog
https://www.sidnlabs.nl/en/news-and-blogs/keep-m-rolling-monitoring-ses-dnssec-algorithm-rollover
it looks like .SE was following the RFC 6781 approach.

Please correct me if I am reading this wrong.


> As it turns out, the provider that only supported RSASHA256 exited the
> managed DNS provider business, and the only vendors we are working with
> currently all support our preferred algorithm (ECDSAP256) in common.
> Hence, I am now open to updating the document to prohibit it. But will
> such text cause aggravation for other potential deployers that may run
> into a similar situation with other providers, and do we care?
> 
> This also begs the question: should we (in another document) update RFC
> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in
> fact it is being ignored?
> 
> Frankly, I've always been a bit perplexed by this text, since it has no
> accompanying rationale. The only compelling rationale I see is downgrade
> protection - to detect that someone hasn't stripped away the signatures
> of a stronger algorithm and forced a validator to authenticate only the
> weaker signatures. But that implies that validators have a documented
> procedure to rank algorithms, which I haven't yet seen. Is a 3072-bit
> RSASHA256 key stronger or weaker than an ECDSAP256SHA256 key for
> example, or Ed25519 vs ECDSAP256SHA256?

Yes, this is exactly the rationale, and it is a valid one. And this is
how unbound works, see
https://nlnetlabs.nl/documentation/unbound/info-algo/ for more information.

Best regards,

Matthijs



> Shumon.
> 
> On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
> 
> Hi Shumon,
> 
> On 1/20/20 9:21 PM, Shumon Huque wrote:
> >     4: The document uses one inceanse of RFC2119 language
> (RECOMMENDED) -
> >     please either drop this, or add the 2119 / 8174 boilerplate.
> >
> >
> > Ok, I'm inclined to lowercase it, since we don't use 2119/8174
> keywords
> > anywhere else in this document.
> 
> Did you see my mail related to this? If you are going with the lowercase
> approach, please use the word "must" instead of "should".
> 
> Best regards,
> 
> Matthijs
> 
> 
>  Forwarded Message 
> Subject: Re: [DNSOP] Working Group Last Call for
> draft-ietf-dnsop-multi-provider-dnssec
> Date: Mon, 13 Jan 2020 09:57:50 +0100
> From: Matthijs Mekking  <mailto:matth...@pletterpet.nl>>
> To: dnsop@ietf.org <mailto:dnsop@ietf.org>
> 
> Late to the party, I am sorry.
> 
> I am positive about this document, and support publication. I do have
> one comment on the document, requesting an update.
> 
> In section 4 it is said it is RECOMMENDED that providers use a common
> signing algorithm.  I think this is too weak and it must be a MUST.
> 
> The reason given for RECOMMENDED is that the "liberal approach" works.
> The liberal 

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

[Matthijs Mekking]

Late to the party, I am sorry.

I am positive about this document, and support publication. I do have
one comment on the document, requesting an update.

In section 4 it is said it is RECOMMENDED that providers use a common
signing algorithm.  I think this is too weak and it must be a MUST.

The reason given for RECOMMENDED is that the "liberal approach" works.
The liberal approach says that authoritative zones MUST sign RRsets with
every algorithm in the DNSKEY RRset, but validating resolvers don't have
to enforce this requirement. However, that does not mean the
authoritative server can simply ignore this rule.

Also, if two different providers are using different algorithms, that
means two DS records with different algorithms are distributed to the
parent. And now the algorithm is signaled in the parent and a validator
may execute the multiple algorithms protection check, expecting both
chain of trusts to work.

In other words, please adapt section 4 to be more strict when it comes
to multiple algorithms. If you agree, I am happy to provide the
suggested text.

Again my apologies for bringing this up so late.

Best regards,

Matthijs


On 10/31/19 4:47 PM, Tim Wicinski wrote:
> 
> This starts a Working Group Last Call for
> draft-ietf-dnsop-multi-provider-dnssec
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/
> 
> The Current Intended Status of this document is: Informational
> 
> FYI, I will not shepherd this document, as it was written with several
> of my coworkers.
> Benno Overeinder will be Document Shepherd. 
> 
> 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.
> 
> If there are normative issues, agenda time at IETF106 will be set aside
> to address them
> 
> This starts a two week Working Group Last Call process, and ends on:  15
> November 2019
> 
> thanks
> tim
> 
> 
> ___
> 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] Alissa Cooper's Discuss on draft-ietf-dnsop-obsolete-dlv-01: (with DISCUSS and COMMENT)

[Matthijs Mekking]

Done.

Matthijs

On 10/30/19 5:52 PM, Warren Kumari wrote:
> Hi there authors,
> Do you think that you can get a new version posted by tomorrow morning
> addressing these points?
> W
> 
> On Wed, Oct 30, 2019 at 12:00 PM Alissa Cooper via Datatracker
>  wrote:
>>
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-dnsop-obsolete-dlv-01: Discuss
>>
>> 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-obsolete-dlv/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> This document needs to incorporate the boilerplate about normative keywords
>> from RFC 8174 as well as references to RFC 8174 and RFC 2119.
>>
>>
>> --
>> COMMENT:
>> --
>>
>> A couple of suggestions since this is being written for posterity as a
>> consensus document of the IETF:
>>
>> s/not every validator actually implements DLV/not every validator actually
>> implemented DLV/
>>
>> s/The authors are not aware of any such use of DLV./There are no known uses 
>> of
>> DLV for this./
>>
>>
> 
> 



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

Re: [DNSOP] Obsoleting DLV

[Matthijs Mekking]

Sam,


On 7/25/19 1:22 AM, Samuel Weiler wrote:
> On Tue, 2 Jul 2019, Matthijs Mekking wrote:
> 
>> Here's a draft with discussion why also the protocol should go
>> away. We would like to hear what you think about it.
> 
> The discussion of the private network use case in section 2 has two
> minor errors plus one bit that is unclear.
> 
> When we designed DLV, we certainly considered a private network use
> case.  RFC5074 does not strictly have public trust anchors take
> precedence over ("mask") DLV records [1].

I read text from RFC 6840 (Section C.3):

   When the trust anchors have come from different sources (e.g.,
   automated updates ([RFC5011]), one or more DNSSEC Lookaside
   Validation (DLV) registries ([RFC5074]), and manual configuration), a
   validator may wish to choose between them based on the perceived
   reliability of those sources.  The order of precedence might be
   exposed as a configuration option.


> I suggest replacing the text in section 2 starting with "One other..."
> with:
> 
>    One other possible reason to keep DLV is to distribute trust anchors
>    for private enterprises.  The authors are not aware of any such use
>    of DLV.
> 
> That does not include the argument in the below bullet, which I find
> unclear.  What does "name redirection" mean in this context?
> 
>    o  Since the zones are related to private networks, it would make
>   more sense to make the internal network more secure to avoid name
>   redirection, rather than complicate the DNS protocol.

Thanks, I made the change in the GitHub repository (BTW I also resolved
Paul Wouters nit comments from earlier).


Best regards,

Matthijs



> -- Sam
> 
> 
> [1] Specifically, 5074 says to use public trust anchors first.  If they
> give a validation result other than "Secure", then do DLV processing. 
> I'm not 100% sure of how BIND's logic works here.
> 
> ___
> 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] Can an RRSET remain valid past the expiration timestamp on its signing RRSIG?

[Matthijs Mekking]

RFC 4035 says:

   If the resolver accepts the RRset as authentic, the validator MUST
   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
   a value no greater than the minimum of:

   o  the RRset's TTL as received in the response;

   o  the RRSIG RR's TTL as received in the response;

   o  the value in the RRSIG RR's Original TTL field; and

   o  the difference of the RRSIG RR's Signature Expiration time and the
  current time.

That last bullet point tells that if the signature's expiration time is
smaller than the TTLs received in the response, the RRset is cached for
at most the duration until the signature expires.

On 7/24/19 7:50 AM, Nick Johnson wrote:
> Suppose I receive a response containing an RRSET with records with
> ttl=3600, signed with an RRSIG that has an expiration timestamp 60
> seconds from now.
> 
> After validating the signature, can I cache the RRSET for 3600 seconds,
> or only for 60 seconds? If the former, and the RRSET is a DNSKEY, can I
> rely on it to validate other RRSIGs for the entire 3600 seconds?

In your example, the RRset must be cached for at most 60 seconds.

Best regards,

Matthijs


> 
> -Nick Johnson
> 
> ___
> 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] Fwd: HTTPSSVC record draft

[Matthijs Mekking]

I was too late to join the virtual queue in the dnsop meeting (fighting
with the Meetecho UI), so I'll send a mail to the list:

Slide 5 of the presentation (Alias form) basically covers the ANAME
case, but still relies on the client to chase the target.

The ANAME record is flexible where the target lookup is done (and can be
done at multiple places) at the cost of more complexity.  That
complexity is needed because we cannot assume that the clients will
chase the targets.

But as soon as clients start querying for ANAME (and not address
records) meaning it will chase the target itself, the DNS server
actually does not have to do a target lookup anymore.

Then putting these records in your zone would trigger the same behavior.

example.com.  7200  IN  ANAMEsvc.example.net.
example.com.  7200  IN  HTTPSSVC 0 0 svc.example.net.

It almost feels like we could reuse the HTTPSSVC record and allow for
target lookups at the DNS server (MAY do target lookup) if an address
query comes in and a HTTPSSVC record is on the same name.

But then perhaps a more generic name for the RRtype is needed ;)

Best regards,

Matthijs



On 7/8/19 11:01 AM, Ray Bellis wrote:
> For those not paying attention to the HTTP-bis working group, this DNS
> RR was proposed there last week.
> 
> It appears to subsume the ALT-SVC proposal and also covers the use case
> I had in mind with my HTTP Record draft (i.e. CNAME at the apex).
> 
> Given that it has someone from at least major browser vendor supporting
> it there's some hope that this will actually be implemented by them.  It
> therefore seems my draft is probably no longer required.  Hopefully
> ANAME will follow it the same way ;-)
> 
> Ray
> 
>  Forwarded Message 
> Subject: HTTPSSVC record draft
> Resent-Date: Wed, 03 Jul 2019 18:46:25 +
> Resent-From: ietf-http...@w3.org
> Date: Wed, 3 Jul 2019 14:45:47 -0400
> From: Erik Nygren 
> To: ietf-http...@w3.org Group , Mike Bishop
> , Erik Nygren , Benjamin
> Schwartz , Erik Nygren - Work 
> 
> 
> 
> 
> Ben, Mike, and I have submitted the first version of a proposal for an
> "HTTPSSVC" DNS record.
> 
> TL;DR:  This attempts to address a number of problems (ESNI, QUIC
> bootstrapping, HTTP-to-HTTPS redirection via DNS, SRV-equivalent for
> HTTP, etc) in a holistic manner through a new extensible DNS record,
> rather than in a piecemeal fashion.  It is based on some previous
> proposals such as "Alt-Svc in the DNS" and "Service Bindings" but takes
> into account feedback received in DNSOP and elsewhere.
> 
> Feedback is most welcome and we're looking forward to discussing with
> people in Montreal.
> 
> Draft link:
> 
> https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01
> 
> 
> 
>  From the abstract:
> 
> This document specifies an "HTTPSSVC" DNS resource record type to
> facilitate the lookup of information needed to make connections for
> HTTPS URIs.  The HTTPSSVC DNS RR mechanism allows an HTTPS origin
> hostname to be served from multiple network services, each with
> associated parameters (such as transport protocol and keying material
> for encrypting TLS SNI).  It also provides a solution for the inability
> of the DNS to allow a CNAME to be placed at the apex of a domain name. 
> Finally, it provides a way to indicate that the origin supports HTTPS
> without having to resort to redirects, allowing clients to remove HTTP
> from the bootstrapping process.
> 
> By allowing this information to be bootstrapped in the DNS, it allows
> for clients to learn of alternative services before their first contact
> with the origin.  This arrangement offers potential benefits to both
> performance and privacy.
> 
> This proposal is inspired by and based on recent DNS usage proposals
> such as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to
> have SRV or a functional equivalent implemented for HTTP).  These
> proposals each provide an important function but are potentially
> incompatible with each other, such as when an origin is load-balanced
> across multiple hosting providers (multi-CDN). Furthermore, these each
> add potential cases for adding additional record lookups in-addition to
> /A lookups.  This design attempts to provide a unified framework
> that encompasses the key functionality of these proposals, as well as
> providing some extensibility for addressing similar future challenges.
> 
> -- 
> 
> Some likely FAQs (with some others listed in an appendix):
> 
> Q: Why this is HTTP-specific?
> A: This is because every protocol has different bootstrap requirements. 
> This draft is concerned with improving the efficiency and security of
> bootstrapping HTTPS connections.  This proposal does offer room for
> non-HTTPS protocols, but the nature of DNS requires underscore prefixing
> to support protocol-keyed answers within a single RRTYPE. It's also
> unlikely that a single RR format would be the ideal bootstrap mechanism
> for every protocol, and there's no 

Re: [DNSOP] a CDN perspective on ANAME challenges

[Matthijs Mekking]

On 7/23/19 2:33 PM, Ben Schwartz wrote:
> 
> 
> On Tue, Jul 23, 2019 at 4:39 AM Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
> 
> Hi Erik,
> 
> On 7/22/19 9:31 PM, Erik Nygren wrote:
> > Reading the draft again, I think a challenge with the structure
> relative
> > to the CDN
> > use-case is that requirements on how and where sibling record
> resolution
> > is done are derived from the target of the ANAME, not from the
> > authoritative nameserver.
> >
> > It may make sense to be much more clear on this, as what it means to
> > support ANAME
> > on an Authority  in an interoperable fashion depends on the DNS
> > architecture
> > of the expected targets of ANAMEs.  If the common use-case of ANAME is
> > to provide interoperability between authoritative DNS
> infrastructure for
> > zone apex ANAMEs that point to CDNs not operated by the DNS
> infrastructure,
> > then the common case for ANAME may need to be for authorities
> > to  "recurse with ECS to get the A/ sibling record".
> >
> > Otherwise the interoperability goal won't be achieved.
> > From the perspective I've seen from my $dayjob at Akamai
> > (a large provider of CDN services), I suspect that CDNs
> > may say "we only support being the target of an ANAME
> > for third-party authorities that do X, Y, and Z" then it may
> > be confusing to mutual customers if that set of things
> > is only listed as being an optional variation in an appendix.
> > This seems like it has lots of risk of confusion around
> interoperability
> > and what it means for an authoritative DNS provider to
> > have "implemented ANAME".
> 
> It almost feels like this is a separate document: "Interoperable ANAME
> services for DNS providers". Describe how to implement ANAME for this
> specific (but large) use case.
> 
> Also, how does HTTPSSRVC deal with this?
> 
> 
> HTTPSSVC gives responsibility for out-of-bailiwick lookups to the
> recursive, or the stub if the recursive isn't HTTPSSVC-aware.  The
> authoritative doesn't have to perform recursive-style lookups.

ANAME allows this too, but note that a solution that depends on the
resolver is going to be a deployment issue.

Target lookup for ANAME can be done at any point in time: At the
provisioning, at the authoritative, at the resolver, at the stub. So the
stub could already perform the out-of-bailiwick lookups by querying for
type ANAME and chase it to the target.

Best regards,

Matthijs


>  
> 
> 
> Best regards,
> 
> Matthijs
> 
> 
> >> >     Authoritative resolvers do a mixture of the following, which is
> >> Do you mean authoritative name servers here?
> >
> > Yes, authoritative nameservers, but also ones that effectively have
> > to be resolvers in-order to do inline sibling record resolution (and
> > caching)
> > and sending ECS.
> >  
> >    Erik
> >
> >
> >
> >
> > On Mon, Jul 15, 2019 at 4:56 AM Matthijs Mekking
> mailto:matth...@pletterpet.nl>
> > <mailto:matth...@pletterpet.nl <mailto:matth...@pletterpet.nl>>>
> wrote:
> >
> >     Hi Erik,
> >
> >     Thanks for sharing this perspective.
> >
> >     On 7/12/19 7:52 PM, Erik Nygren wrote:
> >     > One of the intended goals of ANAME is to improve
> interoperability of
> >     > onboarding onto CDNs for URLs at a zone apex, such as
> >     > “http(s)://example.com <http://example.com>
> <http://example.com> <http://example.com>”.  
> >     >
> >     >
> >     > The TL;DR is that ANAME is unlikely to allow
> interoperability here
> >     > unless authorities are willing to effectively and scalablely do
> >     > recursion-with-ECS for all requests (caching keyed by ECS
> prefix and
> >     > obeying short, sub-minute TTLs).  Simply resolving “sibling
> address
> >     > records” on a zone master (per draft-ietf-dnsop-aname-04) is
> likely to
> >     > be declared incompatible and unsupported (or at least severely
> >     > restricted) by at least some (if not many) CDNs.
> >
> >     The document is written in such a way that it is
> inter-operable, and can
> >     work with offline DNSSEC signing, b

Re: [DNSOP] a CDN perspective on ANAME challenges

[Matthijs Mekking]

Hi Erik,

On 7/22/19 9:31 PM, Erik Nygren wrote:
> Reading the draft again, I think a challenge with the structure relative
> to the CDN
> use-case is that requirements on how and where sibling record resolution
> is done are derived from the target of the ANAME, not from the
> authoritative nameserver.
> 
> It may make sense to be much more clear on this, as what it means to
> support ANAME
> on an Authority  in an interoperable fashion depends on the DNS
> architecture
> of the expected targets of ANAMEs.  If the common use-case of ANAME is
> to provide interoperability between authoritative DNS infrastructure for
> zone apex ANAMEs that point to CDNs not operated by the DNS infrastructure,
> then the common case for ANAME may need to be for authorities
> to  "recurse with ECS to get the A/ sibling record".
> 
> Otherwise the interoperability goal won't be achieved.
> From the perspective I've seen from my $dayjob at Akamai
> (a large provider of CDN services), I suspect that CDNs
> may say "we only support being the target of an ANAME
> for third-party authorities that do X, Y, and Z" then it may
> be confusing to mutual customers if that set of things
> is only listed as being an optional variation in an appendix.
> This seems like it has lots of risk of confusion around interoperability
> and what it means for an authoritative DNS provider to
> have "implemented ANAME".

It almost feels like this is a separate document: "Interoperable ANAME
services for DNS providers". Describe how to implement ANAME for this
specific (but large) use case.

Also, how does HTTPSSRVC deal with this?

Best regards,

Matthijs


>> >     Authoritative resolvers do a mixture of the following, which is
>> Do you mean authoritative name servers here?
> 
> Yes, authoritative nameservers, but also ones that effectively have
> to be resolvers in-order to do inline sibling record resolution (and
> caching)
> and sending ECS.
>  
>    Erik
> 
> 
> 
> 
> On Mon, Jul 15, 2019 at 4:56 AM Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
> 
> Hi Erik,
> 
> Thanks for sharing this perspective.
> 
> On 7/12/19 7:52 PM, Erik Nygren wrote:
> > One of the intended goals of ANAME is to improve interoperability of
> > onboarding onto CDNs for URLs at a zone apex, such as
> > “http(s)://example.com <http://example.com> <http://example.com>”.  
> >
> >
> > The TL;DR is that ANAME is unlikely to allow interoperability here
> > unless authorities are willing to effectively and scalablely do
> > recursion-with-ECS for all requests (caching keyed by ECS prefix and
> > obeying short, sub-minute TTLs).  Simply resolving “sibling address
> > records” on a zone master (per draft-ietf-dnsop-aname-04) is likely to
> > be declared incompatible and unsupported (or at least severely
> > restricted) by at least some (if not many) CDNs.
> 
> The document is written in such a way that it is inter-operable, and can
> work with offline DNSSEC signing, but authorities can still implement
> their own "on-the-fly" ANAME processing that takes into account ECS and
> perform online DNSSEC signing.  I suspect that authoritities with CDN
> customers will do so, similar how they provide CNAME-at-the-apex
> functionality now.
> 
> The benefit of ANAME over those vendor specific solutions is that
> customers can have provider diversity and transfer their zone from one
> to another.
> 
> 
> (some more comments below)
> 
> > For some background, Dan York highlights some sample use-cases here:
> >
> >
>  
> https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01
> >
> > For example, web publishers want to do the equivalent of:
> >
> >  example.com <http://example.com> <http://example.com>  300 IN
> CNAME
> > a123qk.example-cdn.net <http://a123qk.example-cdn.net>
> <http://a123qk.example-cdn.net>.
> >
> >
> > Two use-cases (quoted from draft-york above):
> >
> > 1.  users will be able to simply enter "example.com
> <http://example.com>
> > <http://example.com>" into their browser; and
> >
> > 2.  users will only see "example.com <http://example.com>
> <http://example.com>" in their
> > address bar (if URLs are even displayed).
> >
> >
> > Note that for some CDNs, the “*MailScanner heeft een e-mail met

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

[Matthijs Mekking]

Hi Petr,

On 7/22/19 10:21 PM, Petr Špaček wrote:
> Hello,
> 
> this is an attempt to review draft-ietf-dnsop-aname-04 with fresh eyes -

Thanks.


> I've managed to forget the old versions ;-)

Very wise :)

Comments below:


> On 08. 07. 19 22:05, internet-dra...@ietf.org wrote:
>>  Filename: draft-ietf-dnsop-aname-04.txt
> 
>> 4.  ANAME processing by primary masters
>>   o  Otherwise, wait until the target address RRset TTL has expired or
>>   is close to expiring, then repeat.
> 
> TTL handling in section 4 seems to be different than TTL handling in
> section 3 (Substituting ANAME sibling address records), which says "Set
> the TTL to the minimum of the ANAME TTL, the TTL of each intermediate
> record, and the TTL of the target address records."
> 
> Is it intentional?

Section 3 talks about what TTL to use when replacing sibling address
records with the target data.

Section 4 talks about when a primary master should query for target
data, and this interval is based on the TTL of the target data.

These are two different operations and so to answer your question: yes
this is intentional.

Then in Section 4.3 there is a bit more text on TTLs. Rereading those
paragraphs, I think the following lines might be confusing:

   Normally this TTL is expected to be the same as the
   target address records' TTL; ...

   This means that when adding address records into the zone as a result
   of ANAME processing, the TTL to use is at most that of the TTL of the
   target address records.

What is meant with the first line is that in normal cases the TTL of the
substituted sibling address records equals the TTL of the target address
records, but things like ANAME/CNAME chains, policies may affect this.

The second line says that the substituted sibling address records will
have a TTL that is at least not larger than that of the target address
records.


>> 4.  ANAME processing by primary masters
>>Sibling address records are committed to the zone and stored in
>>nonvolatile storage.
> 
> I propose to use this wording:
> "Sibling address records are committed to the zone as if replacement was
> done using dynamic update protocol, including normal zone maintenance
> (e.g. SOA serial update, DNSSEC resigning when applicable etc.)."
> 
> Reasoning:
> - It is better to be explicit and stress out that this is just normal
> zone update including all the maintenance.
> - I would hate to prescribe how servers should store their data in RR
> type spec ("non-volatile storage" etc.).

Yes, it is a normal zone update, but I would not like to require the
Dynamic Update protocol.  This could also be done by a small tool that
edits the zonefile for example.


>> 5.  ANAME processing by resolvers
>> the resolver might
>>   not be able to validate them because of a broken chain of trust,
>>   but its client could have an extra trust anchor that does allow it
>>   to validate them
> 
> I propose to use term "incomplete chain of trust" instead of "broken
> chain of trust". Broken would (at least in my head) imply bogus and
> that's different state than insecure.

Good point. Will change it.


>> 5.  ANAME processing by resolvers
> Editorial nit:
> It seems that current section 5 could be split into two sections:
> "recursive resolvers" and "stub resolvers". Such split would simplify
> the long explanatory paragraphs currently present in parentheses and be
> easier to follow.

I'll make a GitHub issue for this. Please provide text :)


> Semantic problem:
> I think the current section 5 needs to explicitly specify something
> along lines "resolver MUST NOT perform ANAME sibling address record
> substitution if resolver's client queries with DO=1 and the target name
> is signed".

Do you mean "and the sibling address RRset" is signed? Because that
matches the name that is queried for (the target name is referenced by
the right side of the ANAME).


>> 6.1.1.  Address queries
>>When a server receives an address query for a name that has an ANAME
>>record, the response's Answer section MUST contain the ANAME record,
>>in addition to the sibling address queries.
> 
> Are there some statistics showing impact of ANAME in Answer section
> (together with address records)? I've read previous discussion about
> DNAME, but AFAIK DNAME is almost unused on the public Internet which
> implies that DNAME does not give real deployment experience.

What would be good to know if there are statistics showing impact of
other RRtype in answer section together with requested type records.

We have had this discussion see:

 https://github.com/each/draft-aname/issues/62
 https://mailarchive.ietf.org/arch/msg/dnsop/7ZKB4N4kFIXC3SSMVHzA3e-rOJk


> Maybe APNIC could use their test machinery and send ANAME along with
> A/ responses?

Yes please :)


>> 6.1.  Authoritative servers
>> 6.1.2.  ANAME queries
>>
>>When a server receives an query for type ANAME, regardless of whether
>>the ANAME record 

Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang

[Matthijs Mekking]

On 7/16/19 1:49 AM, Joe Abley wrote:
> On Jul 15, 2019, at 19:13, Tim Wicinski  wrote:
> 
>> Also, the current draft enumerates DLV
>> which needs to be removed.
> 
> Can you explain this?
> 
> I can understand a forthcoming clarification on the use of DLV that
> might make it ill-advised to publish such an RRType, but it's not
> obvious that a dictionary of once-used RRTypes in any particular
> format is useless (for example in understanding observed RRTypes in
> order to track the length of a deprecated type's tail).
> 
> Are archaic English worlds redacted from dictionaries?

This may be my fault: I had put text in draft-mekking-dnsop-obsolete-dlv
that the DLV reference in this draft should be removed.

But you are right, the reference to DLV can stay in
draft-lhotka-dnsop-iana-class-type-yang, just like there is a reference
to A6.

The status of A6 in this draft is set to obsolete, as it should be. But
what should the status of DLV be in this document? This question I guess
proves Paul's argument that putting snapshots of IANA registries in an
I-D is a bad idea.


Best regards,

Matthijs


> 
> 
> Joe
> 
> ___
> 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] a CDN perspective on ANAME challenges

[Matthijs Mekking]

Hi Erik,

Thanks for sharing this perspective.

On 7/12/19 7:52 PM, Erik Nygren wrote:
> One of the intended goals of ANAME is to improve interoperability of
> onboarding onto CDNs for URLs at a zone apex, such as
> “http(s)://example.com ”.  
> 
> 
> The TL;DR is that ANAME is unlikely to allow interoperability here
> unless authorities are willing to effectively and scalablely do
> recursion-with-ECS for all requests (caching keyed by ECS prefix and
> obeying short, sub-minute TTLs).  Simply resolving “sibling address
> records” on a zone master (per draft-ietf-dnsop-aname-04) is likely to
> be declared incompatible and unsupported (or at least severely
> restricted) by at least some (if not many) CDNs.

The document is written in such a way that it is inter-operable, and can
work with offline DNSSEC signing, but authorities can still implement
their own "on-the-fly" ANAME processing that takes into account ECS and
perform online DNSSEC signing.  I suspect that authoritities with CDN
customers will do so, similar how they provide CNAME-at-the-apex
functionality now.

The benefit of ANAME over those vendor specific solutions is that
customers can have provider diversity and transfer their zone from one
to another.


(some more comments below)

> For some background, Dan York highlights some sample use-cases here:
> 
>  
> https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01
> 
> For example, web publishers want to do the equivalent of:
> 
>  example.com   300 IN CNAME
> a123qk.example-cdn.net .
> 
> 
> Two use-cases (quoted from draft-york above):
> 
> 1.  users will be able to simply enter "example.com
> " into their browser; and
> 
> 2.  users will only see "example.com " in their
> address bar (if URLs are even displayed).
> 
> 
> Note that for some CDNs, the “*MailScanner heeft een e-mail met mogelijk
> een poging tot fraude gevonden van "a123qk..example-cdn.net" *
> a123qk.example-cdn.net ” target name
> dynamically selects which IP addresses to return based on a wide variety
> of factors (recursive nameserver IP, end-user IP prefix passed via ECS,
> dynamic load and liveness conditions, product, customer security
> requirements, TLS certificate needed for non-SNI-only configurations,
> etc) and often have short TTLs (often in the range of 20s to 60s,
> although sometimes up to 300s).
> 
> 
> Some CDNs have had vertically-integrated solutions for onboarding zone
> apex names for years, allowing example.com  to hand
> back CDN IPs as long as the zone is delegated to the CDN authorities. 
> The need for these to be vertically integrated comes from the level of
> complexity involved in calculating these answers.
> 
> 
> Even these vertically integrated solutions may have limitations.  For
> example, one early vertically-integrated solution had very similar
> functionality to some of the ANAME proposals.  It only covered case #1
> above, handing out a subset of CDN IPs (with limited performance). Along
> with this was a correlated site HTTP configuration that would issue a
> 30[127] redirect to “*MailScanner heeft een e-mail met mogelijk een
> poging tot fraude gevonden van "www.example.com" * www..example.com
> ” which would in-turn use a normal set of CDN
> IPs.  This doesn’t help for the “users will only see ‘example.com
> ’ in their address bar” case due to the need to
> redirect to a hostname that can fully CNAME.  
> 
> 
> More advanced vertically-integrated solutions that can also handle case
> #2 may involve high-volume feeds of proprietary dynamic state and
> configuration being fed to the authoritative nameservers, allowing them
> to construct answers on-the-fly.
> 
> 
> It is unclear if third-party authoritative servers will be able to do
> enough here to be compatible with CDNs, at least until we get to a point
> where most/all recursive servers support ANAME sibling address
> substitution (and there are huge numbers of these around the world run
> by a huge variety of operators!).  
> 
> 
> For third-party authoritative servers wishing to collapse A/ names
> into a zone as signalled by an ANAME, some of the options include:
> 
> 
>  1.
> 
> Primary zone master does sibling address substitution:  Some CDNs
> will declare this to be strictly incompatible.  (ie, all traffic
> would be directed to a small set of IPs associated with where the
> Primary Master is located).  This would defeat the purpose of using
> a non-purely-anycast CDN.   
> 
>  2.
> 
> Zone secondaries do frequent sibling address substitution:  Some
> CDNs may still declare this to be incompatible. Traffic is still
> directed to a small subset of IPs associated with where the zone
> secondaries are located.  If the zone secondaries are widely
> 

Re: [DNSOP] ANAME loop detection

[Matthijs Mekking]

Jan,

On 7/8/19 11:32 AM, Jan Včelák wrote:
> On Thu, Jul 4, 2019 at 4:55 PM Matthijs Mekking wrote:
>> On 7/4/19 2:32 PM, Matthew Pounsett wrote:
>>> I would say they should rely on that.  Why shouldn't they?  Isn't our
>>> goal to get downstream servers to adopt the extension and do their own
>>> lookup?  The server-side lookups and sibling records are bolt-ons to
>>> handle the adoption period.  Remember, this record is geared toward
>>> customers of CDNs being able to do get similar behaviour to:
>>> www.example.com <http://www.example.com>. IN CNAME webfarm.cdn.net
>>> <http://webfarm.cdn.net>.
>>> at the apex of example.com <http://example.com>.  That was the original
>>> problem we're trying to solve.  I read your statement above about "the
>>> service they provide their customers" being about the CDN resolving
>>> webfarm.cdn.net <http://webfarm.cdn.net>, which most CDNs can already do
>>> within their own infrastructure.
>>
>> I am talking about DNS providers that perform CNAME at the Apex like
>> features: a customer goes to them and opts in to this feature. Such a
>> provider wants to make sure that it is providing the behavior the
>> customer expects and thus wants to make sure it hands out appropriate
>> addresses.
>>
>> Also what is wrong with an authoritative server already giving out more
>> optimal answers than just the ANAME and sibling address records?
> 
> I also understand the sibling address records only as a mean to gap
> the adoption period. It should not be a feature.

It's not a feature, its an optimization: If the requester receives a No
Data response to its ANAME query, he can finalize the target lookup with
an address query to the last target in the chain.


> If the DNS provider (i.e. authoritative server) wanted to perform some
> magic to provide more optimal answer than the resolver could get by
> resolving the ANAME then there is no point of involving ANAME. You can
> perform the magic with A/ already.

Not more optimal than the resolver, but more optimal than the default
sibling address records that are put into the zone.  The benefit of that
is that the resolver has more sane addresses to hand out to the client
in case it is unable to perform ANAME target lookup (due to timeout for
example).


>>> Sending out the sibling records in the presence of this EDNS option
>>> might make sense as a backup, since that is low effort on the part of
>>> the authoritative, but a declaration by the querying server that it
>>> understands ANAME and is prepared to do its own lookups should be
>>> trusted by the authoritative server, and it should not to recursive
>>> lookups.  To take that further, why would the authoritative server
>>> believe that the results of any lookups it does would not be thrown away?
>>>
>>> This EDNS option should also be useful to recursive servers that
>>> understand ANAME, and are planning to do their own ANAME resolution.
>>> They can get their answer from the authoritative server much faster this
>>> way.
>>
>> I am not sure if that is true. Perhaps if you do ANAME target lookup on
>> the fly yes, but I think most implementations will have a side process
>> that does the target lookup and the query resolution can get the target
>> addresses just from cache.
> 
> This is speculative. The conditions may be very different in each setup.
> 
>>> This is also a way to measure adoption.  As the ratio of "EDNS do not
>>> follow ANAME" queries to total ANAME queries approaches 1.0, we know
>>> that adoption has been successful.  Maybe we could even begin to
>>> deprecate authoritative resolution (of ANAMEs) at that point, and begin
>>> to get back to something that looks more like plain CNAME.
> 
> This probably makes me like the option #1 the most.
> 
> Jan
> 

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

Re: [DNSOP] ANAME loop detection

[Matthijs Mekking]

On 7/4/19 5:39 PM, Matthew Pounsett wrote:
> 
> 
> On Thu, 4 Jul 2019 at 10:54, Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
> 
> Matthew,
> 
> > I would say they should rely on that.  Why shouldn't they?  Isn't our
> > goal to get downstream servers to adopt the extension and do their own
> > lookup?  The server-side lookups and sibling records are bolt-ons to
> > handle the adoption period.  Remember, this record is geared toward
> > customers of CDNs being able to do get similar behaviour to:
> > www.example.com <http://www.example.com> <http://www.example.com>.
> IN CNAME webfarm.cdn.net <http://webfarm.cdn.net>
> > <http://webfarm.cdn.net>. 
> > at the apex of example.com <http://example.com>
> <http://example.com>.  That was the original
> > problem we're trying to solve.  I read your statement above about "the
> > service they provide their customers" being about the CDN resolving
> > webfarm.cdn.net <http://webfarm.cdn.net> <http://webfarm.cdn.net>,
> which most CDNs can already do
> > within their own infrastructure.
> 
> I am talking about DNS providers that perform CNAME at the Apex like
> features: a customer goes to them and opts in to this feature. Such a
> provider wants to make sure that it is providing the behavior the
> customer expects and thus wants to make sure it hands out appropriate
> addresses.
> 
> 
> And "CNAME at the Apex like feeatures" is to hand out a CNAME and let
> the downstream server process that.  It may include additional
> information from other zones it is authoritative for, but it doesn't do
> side-lookups.  I think that's the behaviour we should be aiming for, and
> to do that some sort of "I understand ANAME" signal would allow the
> authoritative server to behave more like CNAME.

I agree we should be aiming for that, but initial stage will very likely
be that authoritative servers will do the target lookups (otherwise we
could just deploy the HTTP record right now ;))


> Also what is wrong with an authoritative server already giving out more
> optimal answers than just the ANAME and sibling address records?
> 
> 
> Nothing, as long as it's not going to increase the time it takes to
> respond to the query.
> 
> But, you didn't respond to my question.  Let me rephrase it a bit:  If
> the authoritative server knows the client understands ANAME, why would
> the authoritative server not assume that any additional data it supplies
> will be thrown away?    I suggest that it would be wise for an
> authoritative server to assume that a client that understands ANAME will
> resolve its own ANAME and ignore any other data it gets.

I sure hope not that requester will throw away responses, why else is it
 querying the servers in the first place? ;)

The sibling address records that the authoritative server provides are
needed if the requester does its own ANAME target lookup but fails to do
so because of an outage for example. Then it can use the sibling address
records as the response to the client. It would be better if those are
already "ANAME processed" rather than just handing out the sibling
records that were available in the zone file.

So it may be a poor judgment if the requester just throws away the
answer the authoritative server sends.

  
> > Option #2 gets similar behaviour but at the cost of additional
> lookups. 
> > #3 and #4 don't work well in the presence of server farms.
> 
> If addresses are in the response to the ANAME request there is no
> difference in number of lookups between 2 and 3 I think.
> 
> 
> Did you mean "lookups between 1 and 2"?    I didn't say anything about
> the number of lookups required for 3.  I think 3 and 4 are poor choices
> because they won't behave well with most server farms.

Yes, 1 and 2. Sorry.

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

Re: [DNSOP] ANAME loop detection

[Matthijs Mekking]

Matthew,

On 7/4/19 2:32 PM, Matthew Pounsett wrote:
> 
> 
> On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
> 
> >
> > 1. EDNS "do not follow ANAME" option: The requester would indicate
> > that it is capable of following ANAME and that the server receiving
> > the query should not include the ANAME sibling address records. The
> > loop detection would then work exactly the same ways as with CNAMEs.
> 
> This would be an easy addition I think, however I thought the "do not
> follow ANAME" option actually meant "really don't do a target lookup I
> can do it myself".  The authoritative server can still send the sibling
> address records that are placed in the zone, they can be used if the
> requester fails to perform the ANAME target lookup (for example due to a
> network error or outage).
> 
> Furthermore, a service provide receiving such a request might want to
> ignore it if it feels strongly it should hand out more appropriate
> addresses than the sibling records (basically because that is the
> service they provide their customers, will they rely on an EDNS option
> from the requester saying "no really I can do this"?).
> 
> 
> I would say they should rely on that.  Why shouldn't they?  Isn't our
> goal to get downstream servers to adopt the extension and do their own
> lookup?  The server-side lookups and sibling records are bolt-ons to
> handle the adoption period.  Remember, this record is geared toward
> customers of CDNs being able to do get similar behaviour to:
> www.example.com <http://www.example.com>. IN CNAME webfarm.cdn.net
> <http://webfarm.cdn.net>. 
> at the apex of example.com <http://example.com>.  That was the original
> problem we're trying to solve.  I read your statement above about "the
> service they provide their customers" being about the CDN resolving
> webfarm.cdn.net <http://webfarm.cdn.net>, which most CDNs can already do
> within their own infrastructure.

I am talking about DNS providers that perform CNAME at the Apex like
features: a customer goes to them and opts in to this feature. Such a
provider wants to make sure that it is providing the behavior the
customer expects and thus wants to make sure it hands out appropriate
addresses.

Also what is wrong with an authoritative server already giving out more
optimal answers than just the ANAME and sibling address records?


> Sending out the sibling records in the presence of this EDNS option
> might make sense as a backup, since that is low effort on the part of
> the authoritative, but a declaration by the querying server that it
> understands ANAME and is prepared to do its own lookups should be
> trusted by the authoritative server, and it should not to recursive
> lookups.  To take that further, why would the authoritative server
> believe that the results of any lookups it does would not be thrown away? 
> 
> This EDNS option should also be useful to recursive servers that
> understand ANAME, and are planning to do their own ANAME resolution. 
> They can get their answer from the authoritative server much faster this
> way.

I am not sure if that is true. Perhaps if you do ANAME target lookup on
the fly yes, but I think most implementations will have a side process
that does the target lookup and the query resolution can get the target
addresses just from cache.


> This is also a way to measure adoption.  As the ratio of "EDNS do not
> follow ANAME" queries to total ANAME queries approaches 1.0, we know
> that adoption has been successful.  Maybe we could even begin to
> deprecate authoritative resolution (of ANAMEs) at that point, and begin
> to get back to something that looks more like plain CNAME.
> 
> I would suggest that better EDNS semantics would be just "I
> understand/support ANAME".   That gets the desired information across
> without the sense of sending a command to the upstream server.

I am fine with a "understand/support ANAME" signal, I don't like if that
prohibits the receiver to do its own target lookups. So I am in favor of
a signal that says "this query is part of an ANAME target lookup" to
distinguish it from an address query.


> Option #2 gets similar behaviour but at the cost of additional lookups. 
> #3 and #4 don't work well in the presence of server farms.

If addresses are in the response to the ANAME request there is no
difference in number of lookups between 2 and 3 I think.

Best regards,

Matthijs

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

Re: [DNSOP] ANAME loop detection

[Matthijs Mekking]

Shane,

On 7/4/19 2:29 PM, Shane Kerr wrote:
>>> 2. QTYPE=ANAME: According to the current version of the draft, server
>>> answering to ANAME must include the ANAME and should include the
>>> sibling records. Let's modify the behavior and say the server should
>>> not (must not) include the sibling records. Then the server performing
>>> ANAME sibling address resolution could first query for ANAME before
>>> trying A or . We get the same loop detection mechanism as with
>>> CNAMEs at the cost of an extra query per ANAME
>>
>> Again, I think what we should clarify is that it is a signal to not do
>> do ANAME target lookup. Sibling address records are fine and required at
>> some point.
>>
>> I like this option the best, because the requester is interested in the
>> ANAME record in the particular zone, and so there is no need for
>> chasing.  While with address queries the requester is actually
>> interested in the target address, and so chasing makes sense.
>>
>> We could change the specification such that a server that does ANAME
>> target lookups MUST use QTYPE=ANAME and servers receiving ANAME queries
>> MUST NOT chase the target and would solve the loop problem.
> 
> My main concern about this approach is the extra lookup required.
> 
> Keep in mind that most ANAME targets are NOT going to be ANAME
> themselves (although probably many will), so this means that in most
> cases ANAME servers will have to do an extra lookup before moving on to
> usual A/ lookups. These QTYPE=ANAME cannot be done in parallel with
> A/ queries, since those might trigger the ANAME loops that we are
> trying to prevent.

If we change the specification such that sibling address records MUST be
in the response to an ANAME request that extra lookup is not needed.


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

Re: [DNSOP] ANAME loop detection

[Matthijs Mekking]

Jan,

I like something like option 2 the best, I'll react to your options below.

On 7/4/19 11:37 AM, Jan Včelák wrote:
> Hello.
> 
[ ... ]

> We had been thinking about how this could be fixed and here is what we
> have came with:
> 
> 1. EDNS "do not follow ANAME" option: The requester would indicate
> that it is capable of following ANAME and that the server receiving
> the query should not include the ANAME sibling address records. The
> loop detection would then work exactly the same ways as with CNAMEs.

This would be an easy addition I think, however I thought the "do not
follow ANAME" option actually meant "really don't do a target lookup I
can do it myself".  The authoritative server can still send the sibling
address records that are placed in the zone, they can be used if the
requester fails to perform the ANAME target lookup (for example due to a
network error or outage).

Furthermore, a service provide receiving such a request might want to
ignore it if it feels strongly it should hand out more appropriate
addresses than the sibling records (basically because that is the
service they provide their customers, will they rely on an EDNS option
from the requester saying "no really I can do this"?).


> 2. QTYPE=ANAME: According to the current version of the draft, server
> answering to ANAME must include the ANAME and should include the
> sibling records. Let's modify the behavior and say the server should
> not (must not) include the sibling records. Then the server performing
> ANAME sibling address resolution could first query for ANAME before
> trying A or . We get the same loop detection mechanism as with
> CNAMEs at the cost of an extra query per ANAME

Again, I think what we should clarify is that it is a signal to not do
do ANAME target lookup. Sibling address records are fine and required at
some point.

I like this option the best, because the requester is interested in the
ANAME record in the particular zone, and so there is no need for
chasing.  While with address queries the requester is actually
interested in the target address, and so chasing makes sense.

We could change the specification such that a server that does ANAME
target lookups MUST use QTYPE=ANAME and servers receiving ANAME queries
MUST NOT chase the target and would solve the loop problem.

> 3. EDNS "seen names" options: An option with a list of visited ANAMEs
> would be introduced. The requester would add the option into the query
> when resolving an ANAME target. The receiving server would consult the
> list in case another ANAME was encountered and either broke the loop
> or forwarded the updated option to the next server.
> 
> 4. EDNS "nonce" option: Variance on the previous option which would
> include a numeric nonce instead of full domain names. A receiving
> server would break the loop if it has seen their nonce. It would be
> more compact but the question is how to select the nonce pragmatically
> especially if there can be more servers serving the same zone.

These options feel like more work and if one of the earlier options work
I would rather do that.


Best regards,

Matthijs


> Do you have thoughts on the listed options or brand new suggestions?
> 
> It's also worth mentioning that this is an optimization in a sense.
> The timeouts will be the only option to resolve the loop with
> ANAME-unaware resolvers.
> 
> Jan
> 
> ___
> 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] Obsoleting DLV

[Matthijs Mekking]

Hi,


A while back I was asked why BIND 9 still had code to do DLV. Good
question, and we asked our users if they would mind if we remove the
code. Almost everyone was okay with that.

So ISC plans to deprecate the feature in BIND 9.  But also I think it is
time to move the protocol to Historic status as a clear signal to
everyone that it should no longer be implemented or deployed.

Dan Mahoney cleared the only well-known DLV registry almost two years
ago. Here's a draft with discussion why also the protocol should go
away. We would like to hear what you think about it.


Best regards,

Matthijs


 Forwarded Message 
A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
has been successfully submitted by Matthijs Mekking and posted to the
IETF repository.

Name: draft-mekking-dnsop-obsolete-dlv
Revision: 00
Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status
Pages:5
Status:

  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/

Abstract:
   This document obsoletes DNSSEC lookaside validation (DLV) and
   reclassifies RFCs 4431 and 5074 as Historic.

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

Re: [DNSOP] ANAME in answer or additional section [issue #62]

[Matthijs Mekking]

Brian,

On 6/13/19 7:50 PM, Brian Dickson wrote:
> 
> 
> On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
> 
> Brian,
> 
> Thanks for the detailed background on why DNAME worked. There are a few
> things that caught my attention:
> 
> > When a recursive queried an authority server, if it got back a DNAME
> but did not understand it, it ignored the DNAME but processed the CNAME
> (as if only the CNAME existed) (plus any other data like chained CNAMEs
> or A/ records)
> 
> > All of this is unfortunate, because of the fact that there is no
> genuinely backward compatible record similar to ANAME that can be used,
> without a very strong likelihood of breaking things. From authority to
> recursive: You can't return an ANAME and a CNAME (as a
> backward-compatible rewrite signal that corresponds to the ANAME), since
> the CNAME will effectively obscure other RRTYPEs that might coexist
> (e.g. at the zone apex).
> 
> This is fine, because that is not what we want: We would like to add the
> ANAME in the answer section with the A/ records (not a CNAME).
> 
> > The real problem here, is the "other" record for backward
> compatibility isn't a rewrite-type (such as CNAME or DNAME), but is a
> "promoted" A/ record of potentially limited utility and questionable
> provenance (due to geo-ip stuff, TTL stuff, and RRSIG problems).
> 
> I actually see the A/ record as the backward compatibility records:
> An ANAME-aware resolver would understand the ANAME and can act upon it,
> an ANAME-unaware resolver will use the A/ records that the
> authoritative returned.
> 
> 
> So, this is where the analogy to DNAME diverges from reality of ANAME,
> and IMHO is the the crux of one of the main problems with ANAME.
> 
> In the DNAME/CNAME example, the A/ records are returned ONLY IF the
> server that is authoritative for the DNAME is also authoritative for the
> DNAME "target" (right-hand-side/RDATA).
> If the DNAME auth server is not, it will only return DNAME+CNAME records.
> 
> The only "legitimate" (in my opinion) reason that the ANAME
> authoritative server should also return A/ records, is if it is also
> authoritative for the ANAME "target" (right-hand-side/RDATA).

I disagree.  I do think an authoritative should be careful when doing a
target lookup and not recklessly replace its sibling records. But this
is all about how much trust you have in your ANAME resolution.


> (And the reason that having the ANAME authoritative server obtain and
> return A/ records itself leads to what I called:
> 
> potentially limited utility and questionable provenance (due to
> geo-ip stuff, TTL stuff, and RRSIG problems).
> 
> 
> I have elaborated on this problem previously, but will do so again for
> completeness/context:
> 
>   * There can be differences (possibly significant differences) in the
> results returned for resolution of the "target" between the ANAME
> authoritative server, and the querying resolver.
>   o E.g. Any sort of "stupid DNS tricks" that return different
> values based on either physical topology (anycast instance) or
> geo-ip (client-subnet)>   o That discrepancy can direct clients 
> to a suboptimal server,
> where suboptimal can even be, from a user perspective, badly
> broken (e.g. wrong language, illegal content, etc.)>   * The 
> interactions on TTLs and the need for repeated lookups can have
> adverse impacts on both clients, resolvers, and auth servers
>   o An auth server might want to use longer TTLs to reduce query
> volume, for ANAME values that do not change frequently (A/
> TTL set to same as ANAME TTL)
>   o The original A/ TTL (for the "target" owner name's A/
> RRDATA) might be short because it changes frequently (e.g. CDNs)

I agree with these issues, but I also think they are solvable with some
trickery. Perhaps some words in a Considerations section about that make
sense.


>   * If the "sibling" data is only a hint, non-upgraded resolvers will
> serve A/ records that are either poor (longer latency, higher
> loss), wrong (incorrect language due to wrong CDN node), broken
> (long TTL -> wrong server), or slow (requery required)

The sibling data is not a hint, it is the actual answer that the
authoritative hands out for address queries. The ANAME target lookup
process is replacing the sibling address records with the target values.


Best regards,

Matthijs


> I don't have a better suggestion on how to fix this within the context
> of ANAME; IMNSHO it is an intractable issue, a fundamental problem with
> ANAME if sibling records are required.
> 
> Brian

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

Re: [DNSOP] ANAME in answer or additional section [issue #62]

[Matthijs Mekking]

Brian,

Thanks for the detailed background on why DNAME worked. There are a few
things that caught my attention:

> When a recursive queried an authority server, if it got back a DNAME
but did not understand it, it ignored the DNAME but processed the CNAME
(as if only the CNAME existed) (plus any other data like chained CNAMEs
or A/ records)

Following this logic, this suggests that having an ANAME in the answer
section, together with the requested A or  records, the resolver
most likely will ignore the ANAME and use the A/ records.


> All of this is unfortunate, because of the fact that there is no
genuinely backward compatible record similar to ANAME that can be used,
without a very strong likelihood of breaking things. From authority to
recursive: You can't return an ANAME and a CNAME (as a
backward-compatible rewrite signal that corresponds to the ANAME), since
the CNAME will effectively obscure other RRTYPEs that might coexist
(e.g. at the zone apex).

This is fine, because that is not what we want: We would like to add the
ANAME in the answer section with the A/ records (not a CNAME).


> So, I suspect having the ANAME in the Answer section is worth
experimenting (and the history of DNAME suggests it would not break badly)..

This motivates me to write down that the ANAME should go in the answer
section for address type queries.


> The real problem here, is the "other" record for backward
compatibility isn't a rewrite-type (such as CNAME or DNAME), but is a
"promoted" A/ record of potentially limited utility and questionable
provenance (due to geo-ip stuff, TTL stuff, and RRSIG problems).

I actually see the A/ record as the backward compatibility records:
An ANAME-aware resolver would understand the ANAME and can act upon it,
an ANAME-unaware resolver will use the A/ records that the
authoritative returned.


Best regards,

Matthijs






On 6/12/19 5:09 AM, Brian Dickson wrote:
> 
> 
> On Tue, Jun 11, 2019 at 6:35 PM Joe Abley  > wrote:
> 
> On Jun 11, 2019, at 20:04, Evan Hunt  > wrote:
> 
> > MHO, the ANAME is the real answer we're sending; the A and 
> records
> > are just friendly hand-holding for legacy servers.  It doesn't
> make sense
> > to me to demote the real answer into the additional section, any
> more than
> > it would have to move DNAME there. The protocol specificaions are
> clear on
> > this point - the more so considering we've already deployed DNAME
> - and my
> > sympathies for an implementation that got it wrong would be limited.
> 
> I think DNAME provides a useful example. I think emulating DNAME's
> demonstrated success in both being tolerated and interpreted correctly
> is useful.
> 
> 
> I agree that there is much from DNAME that can be useful to learn from.
> 
> I think it helps to articulate what DNAME did, and why it worked (well,
> and at all):
> 
> DNAME returned both DNAME and synthesized CNAME records, for queries
> received below the DNAME "cut" (query longer than the matching label for
> the DNAME).
> When a recursive queried an authority server, if it got back a DNAME but
> did not understand it, it ignored the DNAME but processed the CNAME (as
> if only the CNAME existed) (plus any other data like chained CNAMEs or
> A/ records)
> When a client queried a recursive, there were two possible kinds of
> recursive: DNAME-aware, and DNAME-unaware. The same general answers were
> received, modulo the presence of the DNAME.
> If the client received, and understood, DNAME, it was effectively the
> same as if no CNAMEs had ever been sent or cached. If the client did not
> understand DNAME, then it would ignore any DNAME, and use the CNAME --
> at that point, the question of whether the resolver spoke DNAME was more
> or less moot.
> 
> The elegance of this was due to the fact that a synthesized CNAME was
> compatible with the namespace structure which might include a DNAME, as
> well as additional CNAMEs and/or DNAMEs.
> 
> All of this is unfortunate, because of the fact that there is no
> genuinely backward compatible record similar to ANAME that can be used,
> without a very strong likelihood of breaking things.
> From authority to recursive: You can't return an ANAME and a CNAME (as a
> backward-compatible rewrite signal that corresponds to the ANAME), since
> the CNAME will effectively obscure other RRTYPEs that might coexist
> (e.g. at the zone apex).
> From recursive to client: An ANAME-aware resolver can maybe return a
> fully-resolved A/ record, along with an ANAME (optionally with
> additional ANAME/CNAME/DNAME records chained) -- but I think testing
> this would strongly be advised.
> 
> So, I suspect having the ANAME in the Answer section is worth
> experimenting (and the history of DNAME suggests it would not break badly)..
> 
> The real problem here, is the "other" record for backward compatibility
> isn't 

Re: [DNSOP] ANAME in answer or additional section [issue #62]

[Matthijs Mekking]

On 6/12/19 4:41 AM, Joe Abley wrote:
> On Jun 11, 2019, at 20:11, Anthony Eden
>  wrote:
> 
>> I'm a fan of Michael's suggestion of using EDNS to signal that the 
>> authoritative should return ALIAS vs synthesizing. Any reason this won't 
>> work?
> 
> It won't work unless it's implemented. On a grand scale, then, it
> won't work unless it's implemented everywhere. The combined lifting of
> implementation, Interop and deployment is significant; is it worth it?

Is it worth it? No IMHO.

Matthijs


> 
> 
> Joe
> 
> ___
> 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] ANAME in answer or additional section [issue #62]

[Matthijs Mekking]

All,


While working on the next version of the ANAME draft, one additional
question came up: When querying for A or , we want to include the
ANAME in the response as a signal to anticipate aliasing.  Should we
include the ANAME record in the answer section or the additional section?

The main argument for putting it in the additional section is that given
the experience with DNAME, putting the ANAME in the answer section there
is a risk of interop problems (because there is an unexpected record in
the answer section).

The main argument for putting it in the answer section is that putting
it in the additional section implies a lower trust level, and that the
record is optional and can be removed when minimizing responses.

Does the working group have any thoughts on this?

Issue is tracked here: https://github.com/each/draft-aname/issues/62


Best regards,

Matthijs

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

Re: [DNSOP] question regarding draft-ietf-dnsop-aname: aname section & truncation

[Matthijs Mekking]

Hi Klaus,

On 5/31/19 1:13 PM, Klaus Malorny wrote:
> 
> Hi all,
> 
> thanks for answering my recent questions so far, but I have to bother
> you with another (maybe stupid?) issue.
> 
> I saw that for regular address queries, you moved the ANAME record from
> the "answer" section to the "additional" section in the -02 draft. I
> tried to figure out why, but did not find an answer in the document
> itself or in the github issues.
> 
> This might by a problem, at least theoretically. RFC 2181, section 9,
> says that records may be removed from the additional section without
> setting the TC bit if the message would get too large otherwise. So the
> ANAME record could get lost in some circumstances. I have not checked
> whether this could occur in real, with very long query names, a lot of
> address records, authority records and maybe with signatures (which
> would allow larger responses due to the DNSSEC requirements on the other
> hand).

There is an appendix that discusses this:

What should be in the additional section: ANAME makes
sense, but differs from CNAME logic (where the CNAME is in the answer
section).

And should additional target records that match the query type go in the
answer section? From experience with DNAME there is a risk of interoper
problems if unexpected records are put in the answer section.

There was indeed no github issue for it, so I created it:
https://github.com/each/draft-aname/issues/62

Please dicuss.

Best regards,

Matthijs



> 
> Regards,
> 
> Klaus
> 
> ___
> 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 regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response

[Matthijs Mekking]

Hi Klaus,

On 5/29/19 9:34 AM, Klaus Malorny wrote:
> On 28.05.19 21:14, Matthijs Mekking wrote:
>> Hi Klaus,
>>
> 
> Hi Matthijs,
> 
>> I provided responses inline.
> 
> I too.
> 
>>
>> On 5/28/19 5:49 PM, Klaus Malorny wrote:
>>>
>>>
>>> Hi all,
>>>
>>> [...]
>>
>> I am not sure what text in Section 3 you are referring to, can you quote
>> the specific text?
>>
>> AFAICS there is nothing that says the visited ANAMEs and CNAMEs needs to
>> be set in the Additional section.  Visited ANAME and CNAME records are
>> used to adjust the owner name and the TTL.
> 
> Well, just the two sentences just below the headline of section 3:
> 
>    The requirements in this section apply to both recursive and
>    authoritative servers.
>    ^
> 
>    An ANAME target MAY resolve to address records via a chain of CNAME
>    and/or ANAME records; any CNAME/ANAME chain MUST be included when
>  ^^^
>    adding target address records to a response's Additional section.
> 
> Along with the following requirement of 3.1:
> 
>    o  MAY contain the target address records that match the query type
>   (or the corresponding proof of nonexistence), if they are
>   available and the target address RDATA fields differ from the
>   sibling address RRset.
> 
> So, I can choose to add the target addresses to the additional section,
> but then I have to add the full path of ANAME/CNAME/DNAME(?) also. This
> is my interpretation.

Stupid me, I looked at the work in progress draft in the github, where
the additional section processing sections have been split in
authoritative servers and resolvers.

But yeah, in -03 that seems right.  I was thinking of leaving out this
MAY keyword for authoritative servers because the target address records
are normally not available there, but if there is a caching resolver
inside the authoritative it may have them.  And so perhaps the MAY
keyword should stay for both cases.


Best regards,

Matthijs

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

Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response

[Matthijs Mekking]

Hi Ralf,

On 5/29/19 7:42 AM, Ralf Weber wrote:
> Moin!
> 
> On 28 May 2019, at 21:14, Matthijs Mekking wrote:
>> For authoritative servers that receive A or  requests, the address
>> records shall appear only once: in the answer section.  It is correct
>> that those address records have the owner name and TTL adjusted (to the
>> owner name of the ANAME record and the minimum of the encountered TTLs).
>>
>> There is nothing in the additional section, except for the ANAME record,
>> as described in Section 6.1.1:
>>
>>When a server receives an address query for a name that has an ANAME
>>record, the response's Additional section MUST contain the ANAME
>>record.  The ANAME record indicates to a client that it might wish to
>>resolve the target address records itself.
> So that means an authoritative server could just use the “static” A
> records in the zone and just put in the ANAME in the additional section
> and not do any special processing at all, hoping the resolver does
> follow the ANAME?

Yes, it could do that. But it is not likely that this scenario is
particularly useful in the early stage of ANAME deployment.


>> Note that there is separate additional processing for authoritative
>> servers and resolvers.  For resolvers there is a requirement of having
>> target address records in the additional section.
> Why? They are the same that are in the answer section and for DNSSEC
> the signed ANAME is important and not the unsigned addresses or am I
> missing something?

Why is there a requirement or why is there a difference?

First, the word "requirement" is causing confusion here, I am sorry.
What I meant is that for resolvers the draft has a RFC 2119 keyword
related to adding target address records in the additional section (it's
a MAY). So not required, but optional.

Why is there different additional processing for authoritative servers
and resolvers?  Basically because in a traditional authoritative name
server the target address records are not available (so adding them is
not in scope), but a resolver may have them in the cache (and note these
may be signed address records).


Best regards,

Matthijs



> 
> So long
> -Ralf
> —--
> Ralf Weber
> 

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

Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response

[Matthijs Mekking]

Hi Klaus,

I provided responses inline.

On 5/28/19 5:49 PM, Klaus Malorny wrote:
> 
> 
> Hi all,
> 
> I am working on an experimental implementation of ANAMEs in our
> authoritative name server software, which shall perform its own ANAME
> lookup. I am a bit puzzled what is really expected to be returned for
> regular address (A/) queries.>
> - Is it right that the determined target address records shall appear
> twice, first in the answer section, with the query name as the owner and
> the TTL adjusted (based on the involved records), second in the original
> form in the additional section?

For authoritative servers that receive A or  requests, the address
records shall appear only once: in the answer section.  It is correct
that those address records have the owner name and TTL adjusted (to the
owner name of the ANAME record and the minimum of the encountered TTLs).

There is nothing in the additional section, except for the ANAME record,
as described in Section 6.1.1:

   When a server receives an address query for a name that has an ANAME
   record, the response's Additional section MUST contain the ANAME
   record.  The ANAME record indicates to a client that it might wish to
   resolve the target address records itself.

Note that there is separate additional processing for authoritative
servers and resolvers.  For resolvers there is a requirement of having
target address records in the additional section.


> - It is not yet quite clear to me what the purpose of recording the
> visited ANAMEs and CNAMEs beyond the very first ANAME in the additional
> section, as described in the section 3. Is it of any use for an aware
> resolver? Shall it validate the path to the target addresses in order to
> recognize them as such? And what about DNAMEs? I constructed a nice
> example, despite not knowing whether such a situation would ever occur
> in real life:>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3
> ;; flags: qr aa ; qd: 1 an: 1 au: 0 ad: 5
> ;; QUESTIONS:
> ;;    multi.example., type = , class = IN
> 
> ;; ANSWERS:
> multi.example.    2    IN        fe:dc:ba:98:76:54:32:10
> 
> ;; AUTHORITY RECORDS:
> 
> ;; ADDITIONAL RECORDS:
> multi.example.    86400    IN    ANAME    redir1.target.
> redir1.target.    2    IN    CNAME    redir2.sub.target.
> sub.target.    86400    IN    DNAME    base.target.
> redir2.base.target.    86400    IN    ANAME    redir3.target.
> redir3.target.    3    IN        fe:dc:ba:98:76:54:32:10
> 
> ;; Message size: 223 bytes

I am not sure what text in Section 3 you are referring to, can you quote
the specific text?

AFAICS there is nothing that says the visited ANAMEs and CNAMEs needs to
be set in the Additional section.  Visited ANAME and CNAME records are
used to adjust the owner name and the TTL.


> - if the name server chooses to cache the target address records (and
> the intermediate xNAME records), shall the answer reflect the age of the
> cache entries in the TTLs (i.e. be subtracted) of the records in the
> answer and/or additional section?

There is some guidance in appendix C on this:

- In principle you should use a fixed TTL (no decremented TTLs) to avoid
query bunching (C.1).

- If the ANAME target lookup is done inside the name server, and
implements a cache, may use a decremented TTL in the response to the
client rather than using the original target address records' TTL, but
not a near zero TTL (C.4).

Hope this helps.


> Sorry in case that the questions do not make sense. I have to admit that
> I have not yet fully understood the document in all aspects. But that's
> why I am asking.

No worries, and really: thank you for asking! If the specification is
not clear, we should improve it.  Please do not hesitate to send in text
suggestions on this list or on the github
(https://github.com/each/draft-aname).


Matthijs



> 
> Regards,
> 
> Klaus
> 
> ___
> 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] ANAME TTL considerations [issue #30 #34]

[Matthijs Mekking]

While this mail has received no reactions on the mailing list, there is 
some discussion happening on the GitHub repository.


The changes that are now scheduled for the new draft related to this 
topic are:


* Define what intermediate records are.
* Update the TTL of the final address records to the minimum TTL of the 
ANAME, intermediate records, and target records (add the initial ANAME 
too in this step).

* Add some words about TTL stretching.
* Add an appendix section on ANAME substitution if done inside the name 
server (for informational purposes).


Full diff related to this topic can be found here:

  https://github.com/each/draft-aname/pull/61/files

Best regards,

Matthijs


On 5/2/19 11:21 AM, Matthijs Mekking wrote:

Hi,

Another issue that is still open related to ANAME is the TTL
considerations.

The current draft says that when updating sibling address records
with target address records to reduce the TTL to match the ANAME TTL if
it is greater.

I propose a change that others have expressed as well, that is the TTL
of the sibling address records should be set to the minimum of the
target address records and its intermediate records in case of CNAME
and/or ANAME chains.

The logic is that ANAME is likely to be a more static record, while its
target address records are expected to be more dynamic. Therefor it may
make sense to set different TTLs for the different RRsets, meaning we
should not try to match the ANAME TTL and the TTL of the address records.

This means that when implementing ANAME substitution at the primary,
this will likely stretch the end-to-end TTL (from the authoritative
servers for the target address records to end-user DNS caches) to  near
twice the target address record original TTL.

The suggested change can be found here:

   https://github.com/each/draft-aname/pull/61

I will leave this pull request open for a while to solicit feedback,
counter arguments, approvals, ...


Best regards,

Matthijs

___
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] ANAME TTL considerations [issue #30 #34]

[Matthijs Mekking]

Hi,

Another issue that is still open related to ANAME is the TTL
considerations.

The current draft says that when updating sibling address records
with target address records to reduce the TTL to match the ANAME TTL if
it is greater.

I propose a change that others have expressed as well, that is the TTL
of the sibling address records should be set to the minimum of the
target address records and its intermediate records in case of CNAME
and/or ANAME chains.

The logic is that ANAME is likely to be a more static record, while its
target address records are expected to be more dynamic. Therefor it may
make sense to set different TTLs for the different RRsets, meaning we
should not try to match the ANAME TTL and the TTL of the address records.

This means that when implementing ANAME substitution at the primary,
this will likely stretch the end-to-end TTL (from the authoritative
servers for the target address records to end-user DNS caches) to  near
twice the target address record original TTL.

The suggested change can be found here:

  https://github.com/each/draft-aname/pull/61

I will leave this pull request open for a while to solicit feedback,
counter arguments, approvals, ...


Best regards,

Matthijs

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

Re: [DNSOP] ANAME precedence [issue #58]

[Matthijs Mekking]

Hi,

Jan and everyone else, thanks for your feedback. It feels indeed like we
should continue with the behavior that ANAME will take precedence over A
and  when on the same name. I shall go over the draft and see if the
text is correct in that sense.

Best regards,

Matthijs


On 4/30/19 11:56 AM, Jan Včelák wrote:
> On Fri, Apr 26, 2019 at 8:30 PM 神明達哉 wrote:
>>> Jan Včelák mentioned that at least NS1 uses a different order of
>>> priority: If an sibling address record exists next to the ANAME it takes
>>> precedence and no target lookup is done for that address record type.
>>
>> if there's a specific use case where this behavior is important,
>> either the developer or user of this implementation should be able to
>> clarify that.  At least until we know that I don't see the point of
>> considering this choice.
> 
> The reason for different processing order in our implementation is
> merely historical: ALIAS was intended to solve the problem with CNAME
> in zone apex, our customers were familiar with CNAME processing, and
> therefore we wanted ALIAS to resemble CNAME closely. CNAME is
> practically a fallback record as well. I'm not aware of any specific
> use case where such behavior would be required although it's possible
> that our customers have developed some use case over the years.
> 
> It looks like there is an agreement that ANAME should take precedence
> over A/. That's fine with me. We will figure it out for our
> customers.
> 
> Jan
> 

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

Re: [DNSOP] ANAME precedence [issue #58]

[Matthijs Mekking]

On 4/25/19 8:34 PM, 神明達哉 wrote:
> At Wed, 24 Apr 2019 11:44:37 +0200,
> Matthijs Mekking  <mailto:matth...@pletterpet.nl>> wrote:
> 
>> I would like to start separate threads on the remaining issues of the
>> ANAME draft. One issue that remains to be solved is whether having an A
>> or  record next to the ANAME should take precedence or not.
>>
>>   Draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
>>   Issue: https://github.com/each/draft-aname/issues/58
> [...]
>> Jan Včelák mentioned that at least NS1 uses a different order of
>> priority: If an sibling address record exists next to the ANAME it takes
>> precedence and no target lookup is done for that address record type.
> 
> Is this choice #2 of the github issue #58?

Correct.


>>> sibling address records take precedence, don't to a target lookup for
> an address type next to the ANAME.
> 
> I'm not sure what this means...if this approach is taken and an
> authoritative server has these for an example.com <http://example.com> zone:
> 
> a.example.com <http://a.example.com>. ANAME another.example.org
> <http://another.example.org>.
> a.example.com <http://a.example.com>.  2001:db8::1
> 
> then, does it always just return the  RRset to a query for
> a.example.com/ <http://a.example.com/>, regardless of any
> possible changes to
> another.example.org/ <http://another.example.org/>?

That is exactly what choice #2 does. But it can do a target lookup for
the A RRset.


> How is that  created in the first place?  (Is it taken from
> another.example.org/ <http://another.example.org/> or completely
> up to the example.com <http://example.com>
> maintainer?)..

The  record may initially be added to the example.com zone by the
zone operator. With choice #2 it is not updated by the ANAME (with
choice #1 it is).


> Also, especially if both  and A sibling records are available,
> what's the purpose of ANAME in the first place if it's (effectively)
> not used?
> 
> I'm sure I'm just confused and don't understand the expected usage,
> but I can't figure it out from the available descriptions.  Could you
> clarify it?

Personally I agree that the purpose of ANAME becomes less useful with
choice #2.  The difference is that you can set up ANAME for example for
 only, or for A only. I don't know what the expected usage of that
is, and that is why I am asking on the list. If it turns out there is no
useful case, I think we should put text in the draft that says ANAME
takes precedence over sibling A and  records.


Best regards,

Matthijs



> 
> --
> 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] What should ANAME-aware servers do when target records are verifiably missing?

[Matthijs Mekking]

On 4/12/19 1:05 PM, Tony Finch wrote:
> Matthew Pounsett  wrote:
>>
>> I feel like this is creating an even bigger potential problem.  What
>> happens when the owner of the ANAME target legitimately wants that
>> name to go away, but some other zone owner is leaving an ANAME in
>> place pointing to that now-nonexistent name?  Continuing to serve the
>> sibling records indefinitely seems like serve-stale gone horribly
>> wrong.
> 
> It's worth noting that Oracle's ANAME model does not couple the sibling
> addresses to the ANAME target addresses. As I understand it, they have
> additional "fallback" infrastructure (web servers and whatnot) which is
> used when the ANAME target isn't available.
> 
> I'm not sure how this would work as a replacement for CNAME, when the
> request from the user comes without any information about how to set up a
> fallback server.

I think the logic suggested for ANAME is given this example:

1. Have ANAME and A and  sibling address records.
2. Look up ANAME target A and  target records.
3. If there is no positive answer (SERVFAIL, NXDOMAIN, NODATA) keep
sibling address records.
4. Otherwise replace sibling address records with ANAME target records.

This is different than NS1, that will never replace sibling address
records.  Instead, if there is no sibling address record, it will
perform ANAME resolution.  If that response is a SERVFAIL, NXDOMAIN or
NODATA, that is what will be given to the client (although returning
SERVFAIL won't be a thing in the ANAME specification).

In order to fit both use cases I think we need to relax the steps in the
ANAME resolution logic, but am hesitant to do that: If you make steps
optional it will be unclear what the optional resolver's behavior is
going to do.  I would very much like to see an agreement on the ANAME
resolution logic, especially so that customers can have multiple
providers or switch providers and can expect the same thing in both places.


Best regards,

Matthijs





> 
> Tony.
> 

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

Re: [DNSOP] ANAME discussion

[Matthijs Mekking]

Tony,

Thanks for listing these points.  I converted them to issues (together 
with some other issues that people mentioned last week and on the list).


  https://github.com/each/draft-aname/issues

I am more than happy to take on the editorial work.

Best regards,

Matthijs


On 3/29/19 9:58 PM, Tony Finch wrote:

(Starting a new thread so my mailer doesn't sort the new discussion with
messages from November!)

Thanks to Matthijs Mekking for the good summary this morning. I am happy
for someone else to take over editorial/authorship duties on the draft.

There were several useful points at the mic; thanks Paul Hoffman for
noting them in the minutes (especially because I could not remember who
said what). In no particular order...

Petr Spacek said he thought zone transfers are difficult. In earlier
revisions that is true; in the -02 revision there is nothing special about
zone transfers, they are just the same as in the absence of ANAME. All the
work has been moved to how the records get into the zone. (However the
huge "as if" clause allows implementations to do funky things at zone
transfer time if they want, and you won't be able to tell the difference
from outside.)

Matt Pounsett talked about strategies for polling the DNS at scale
efficiently. Timing was something I worried about a lot when writing the
draft, and I probably over-specified it. I eventually concluded that it
isn't possible in many reasonable implementations to avoid significantly
stretching the TTL of the ANAME target address records by copying them to
the ANAME siblings. Maybe the spec should become more relaxed about this,
and make it a quality-of-implementation issue rather than a requirement.

Regarding geoip, ANAME is no worse than manually configured address
records, and it will eventually become better as resolver support is
deployed. Geoip is the main reason for specifying (optional) ANAME support
in resolvers. (I guess another reason might be to more faithfully respect
the target address TTLs...) Resolver support isn't necessary, though,
provided the ANAME target addresses work everywhere. So it might not be
compatible with all existing geoip implementations, but I don't think
that's a bug in ANAME.

Scalability is definitely a challenge. The worst case is when you have a
very large number of zones sharing the same ANAME target, and that changes
address. If ANAME is implemented using existing standard protocol features
(i.e. UPDATE, NOTIFY, IXFR) as specified, then the change of address is
going to cause a huge volume of modification traffic. But the "as if"
clause exists to allow large scale implementations to do clever things to
mitigate this.

On the list, Brian Dickson and Dan York talked about "just as if there was
a CNAME there”. The -02 draft tries to have semantics very close to CNAME,
but there are other interesting possibilities if we relax that
requirement.

What I had in mind for an -03 revision was to remove any requirements
about how the sibling address records are populated. The remaining
requirement is that the sibling addresses must work the same way as the
target addresses, from the point of view of the end user. The sibling
addresses can freely be replaced by the target addresses at any time
(provided whatever is doing the substitution can sign the records when
that is necessary).

This covers both draft -01 and -02 style implementations, and Oracle Dyn's
notion of fallback addresses, and perhaps even vertically integrated
providers that might prefer to direct client to thei own http 302 server
instead of substituting addresses in the DNS. (Though they risk making too
many assumptions about what the point of view of the end user is!)

Dunno if this is a useful direction or not - argue away :-)

Tony.


___
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] Minimum viable ANAME

[Matthijs Mekking]

On 3/26/19 5:10 PM, Tony Finch wrote:

Matthijs Mekking  wrote:


I think that would be the wrong direction.  I believe there is a need to
standardize the ANAME resolution process and so my suggestion would be to
reduce the scope by focusing just on how to do that on the provisioning side
(and leave secondary servers and resolvers out of scope for now).



From past discussions, I didn't think there was any way we could get

consensus on the provisioning side.

Dynamic lookups on authoritative servers are out, because it has to be
compatible with traditional secondaries.

Updates on the primary are out, because that doesn't scale to large
numbers of zones.

Sometimes a system might have known fallback addresses, but often it won't
(e.g. whether the DNS setup is or isn't coupled to a web provisioning
system).


All these things are contentious which is the reason why removing it 
from the scope will hopefully aid progress.  These can be resolved in a 
follow up document.



But I think it's reasonable to allow whatever provisioning mechanisms
there might be, provided the meaning of answers from auth -> rec have a
consistent meaning that resolvers can use. >
It's also really imortant that ANAME can work in multi-provider setups, so
there needs to be something approaching interoperable semantics for
importing a zone file into a provisioning system. (Though I think the
semantics will have to be very loose in this case, to allow for variations
between existing systems.)

I haven't seen any objections to support for ANAME in recursive servers
so I'm surprised you think that is problematic enough to be removed. My
understanding was that recursive support is seen as better than trying to
do all the tricks on authoritative servers.


Except for the slow deployment issue.



Tony.



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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

I stand corrected indeed, I just went to the mailing list to find the 
latest version of the draft and noticed there were many fundamental 
arguments.


Matthijs

On 3/26/19 5:19 PM, Tony Finch wrote:

Matthijs Mekking  wrote:


The last draft did not see a lot of comments.


I thought there was quite a lot of very informative and robust discussion
in November.

https://mailarchive.ietf.org/arch/msg/dnsop/fmMGXQA0ryaJdtjSCVEsQ9ZiF2M
https://mailarchive.ietf.org/arch/msg/dnsop/lC2ZW0lwME-RrvkpntRpJzWrLuc
https://mailarchive.ietf.org/arch/msg/dnsop/HGld_NMA0kKzcX3r8sNZiayVJRY

Tony.



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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

Hi Tony,

On 3/26/19 4:32 PM, Tony Finch wrote:

I'm overloaded at the moment so I wasn't able to rev the draft in time for
IETF 104. I was planning to (basically) re-focus on the meaning of the
bits on the wire, and remove any requirements about how zone contents are
provisioned. Instead there would be a series of examples of existing
ANAME-like systems.


I think that would be the wrong direction.  I believe there is a need to 
standardize the ANAME resolution process and so my suggestion would be 
to reduce the scope by focusing just on how to do that on the 
provisioning side (and leave secondary servers and resolvers out of 
scope for now).


Matthijs



Tony.



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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

That was me on the mic.

To clarify:

DNS open source implementers discussed it earlier this week to see if 
there is still appetite for ANAME. The last draft did not see a lot of 
comments. To get things moving again we thought it might be a good idea 
to make a document with reduced scope.


Matthijs


On 3/26/19 4:17 PM, Dan York wrote:




On Mar 26, 2019, at 3:35 PM, Olli Vanhoja > wrote:


Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.


I believe it was a comment from someone at the mic that the *authors* 
were going to have a side meeting to talk about simplifying the draft 
and providing a new version.


If it is a larger meeting than just the authors, then there are probably 
a number of us who would be interested.


Dan

--
Dan York
Director of Web Strategy, Internet Society
y...@isoc.org    +1-603-439-0024
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



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

Re: [DNSOP] Fundamental ANAME problems

[Matthijs Mekking]

Follow-up.

tldr:
- The first argument is just an issue of wording.
- Authoritative servers or provisioning scripts that do ANAME processing 
should honor the target address records TTL.
- Sibling address records should be used as a default if ANAME 
processing fails.



On 11/9/18 6:54 PM, Richard Gibson wrote:

Responses inline.

On 11/9/18 11:39, Tony Finch wrote:

Richard Gibson  wrote:

First, I am troubled by the requirement that ANAME forces the zone into a
dynamic zone.

I don't see how it is possible to implement ANAME without some form of
dymamic behaviour, either by UPDATEs on the primary, or on-demand
substitution on the secondaries, or some combination of the two.


I am advocating for the special behavior of ANAME be limited to 
processing of non-transfer queries (i.e., explicitly excluding AXFR and 
IXFR). For example: ANAME-aware authoritative servers MAY attempt 
sibling replacement in response to address or ANY queries and SHOULD add 
records to the additional section in response to address or ANAME 
queries; ANAME-aware resolvers SHOULD do both. But all authoritative 
servers should agree that the sibling records—including their original 
TTLs—are a non-special part of zone contents for the purposes of transfers.


It looks like there is a non-issue: The draft allows you to do ANAME 
resolution however you want:
1. An anamifier script that updates a zone file before loading it into 
the primary.

2. A tool that translates ANAME target lookups into Dynamic Update.
3. An authoritative server that implements ANAME resolution.
4. ...

The point is that we would like to standardize the ANAME resolution, and 
what it means on the wire.


Richard makes a good point though that is: ANAME on zone transfers 
should have no special logic.





Second, and relatedly, I think the TTLs of replacement records established for
non-transfer responses are too high. Respecting the TTL of every record in a
chain that starts with the ANAME requires the TTL of final replacement records
to be no higher than the minimum TTL encountered over the chain, potentially
/reduced/ nondeterministically to mitigate query bunching. I would therefore
add language encouraging resolvers synthesizing those records to engage in
best-effort determination of original TTLs by (e.g., by directly querying
authoritative servers and refreshing at 50% remaining), but *requiring* them
to decrement TTLs of records for which they are not authoritative.

>>>

I'm not sure I understand which TTLs you are worried about here. What are
"non-transfer responses"? There's certainly some rewording needed to make
it more clear, but the TTLs returned by resolvers that do sibling address
record substitution are decremented in the usual way, and resolvers make
no attempt to determine the original TTLs.

>>

non-transfer responses are responses for QTYPE != AXFR or IXFR.


I hope the above clarifies... my TTL concerns relate not to resolvers, 
but to authoritative servers. In particular, I take issue with the 
"/Sibling address records are committed to the zone/" and "/Sibling 
address records are served from authoritative servers with a fixed TTL/" 
text, which stretches the TTL of one or more RRSets along the target 
name's resolution chain.


Richard and I discussed this. In order for me to understand the issue I 
had to look this from the point of the resolver, that does ANAME resolution.


Suppose a resolver has an ANAME in its cache with a high TTL, say 3600, 
but not the target A and  records. It can do the lookup for the 
targets. If successful, it will retrieve the A and/or  records. 
Let's say they have a short TTL, 60. They time out after a minute, but 
the resolver can still use the ANAME record to do its own ANAME resolution.


In other words, if the resolver does ANAME resolution, the TTL of the 
target address records are honored. Now what does that mean for the 
authoritative side? What TTL should they use for the A and  records 
that have been expanded by ANAME? It would only be logical that the 
authoritative side does the same.


This means that when adding A and  records into the zone as a result 
of ANAME processing, the TTL to use is at most that of the TTL of the 
address target records. If you use a higher value, this will stretch the 
TTL which is undesired.





And finally, back on the question of what ANAME sibling address records
actually represent, I think that NXDOMAIN and NODATA results should be treated
as errors for the purposes of ANAME sibling replacement. This position can be
justified on both practical and principled grounds—replacing functional
records with an empty RRSet is undesirable for DNS users (or at least the
sample of them that are Oracle+Dyn customers),

>>>

Maybe so, but that's what happens with CNAME records.

>>
CNAME does not allow for siblings, and therefore its processing is 
incapable of replacing functional records with an empty RRSet. Further, 
clients are required to 

Re: [DNSOP] Fundamental ANAME problems

[Matthijs Mekking]

On 11/9/18 4:27 AM, Richard Gibson wrote:
I have finally reviewed the latest draft directly, and like the overall 
direction but have a small number of issues (however, the issues 
theirselves are somewhat fundamental). They broadly break down into 
concerns about zone transfers and TTL stretching, and ultimately seem to 
stem from a disagreement with my position that the proper conception of 
ANAME sibling address records is as fallback data to be used in cases 
where ANAME target resolution fails or is never attempted.


First, I am troubled by the requirement that ANAME forces the zone into 
a dynamic zone. That a primary master would dynamically replace sibling 
records on its own, update the zone serial, and then propagate that 
dynamic data via zone transfer overrides user conception about the state 
of a zone, induces undesirable churn between authoritative nameservers, 
/and/ stretches the TTLs of ANAME targets on downstream servers by the 
amount of time between successive updates. These consequences are just 
too much for what is supposed to be a low-impact feature. Anyone willing 
to opt-in to them should be updating the ANAME sibling address records 
on their own, not forcing authoritative server implementations to choose 
between taking on that dirty work or being labeled noncompliant.


It seems that everyone thinks that the latest ANAME draft requires DNS 
UPDATE. This is just a use case that Tony provides and would help him in 
his daily operations. However, it is not required to do so: ANAME 
resolution can also happen by updating the zone file before loading it 
into the primary server. Or it may happen in the authority server if 
people desire to implement it there.


I think the draft should be updated to make that absolutely clear. The 
draft should standardize how ANAME resolution is done, and what it means 
to have ANAME and sibling address records in the zone for address rtype 
(A, , ...) and ANAME query lookup.


The customer does not care about the address records, other than it may 
want to provide a default address. So in their provisioning dashboard 
they will only add a domain name that represents their CDN or whatever.


The DNS provider will perform ANAME resolution somewhere between where 
the customer provides the ANAME and hands out the addresses to the DNS 
client.



Second, and relatedly, I think the TTLs of replacement records 
established for non-transfer responses are too high. Respecting the TTL 
of every record in a chain that starts with the ANAME requires the TTL 
of final replacement records to be no higher than the minimum TTL 
encountered over the chain, potentially /reduced/ nondeterministically 
to mitigate query bunching. I would therefore add language encouraging 
resolvers synthesizing those records to engage in best-effort 
determination of original TTLs by (e.g., by directly querying 
authoritative servers and refreshing at 50% remaining), but *requiring* 
them to decrement TTLs of records for which they are not authoritative.


I agree, the TTL language in this document is not ready and needs more 
discussion.



And finally, back on the question of what ANAME sibling address records 
actually represent, I think that NXDOMAIN and NODATA results should be 
treated as errors for the purposes of ANAME sibling replacement. This 
position can be justified on both practical and principled 
grounds—replacing functional records with an empty RRSet is undesirable 
for DNS users (or at least the sample of them that are Oracle+Dyn 
customers), and could inappropriately stretch the maximum specified 
ANAME sibling TTL (on the ANAME record itself) to the SOA MINIMUM value 
(which is doubly bad, because it results in extended caching of the 
/least/ valuable state). And adding insult to injury, resolvers in 
general will not even have the SOA, and will need to perform more 
lookups in order to issue a proper negative response of their own. Let's 
please just eliminate all of that by specifying that ANAME processing 
can never replace something with nothing.


+1


Best regards,

Matthijs


P.S. There is a typographical error in Appendix D; "RRGIG" should be 
"RRSIG".


P.P.S. I think it has been discussed before, but this document should 
also introduce and use a new "Address RTYPE" registry or subregistry, 
rather than forever constraining ANAME exclusively to A and .


On 11/2/18 17:00, Richard Gibson wrote:


I haven't reviewed the full draft yet, but am happy to see some people 
echoing my sentiments from earlier versions [1]. I particularly wanted 
to agree with some statements from Bob Harold.


On 11/2/18 15:20, Bob Harold wrote:
Another option to give users is a non-updating fallback A record, 
that could point to a web redirect.  That saves all the hassle of 
updates.


YES! This means a slightly worse fallback-only experience for users 
behind ANAME-ignorant resolvers that query against ANAME-ignorant 
authoritatives (the introduction of ANAME 

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Matthijs Mekking]

On 11/9/18 1:57 AM, Ray Bellis wrote:



On 09/11/2018 07:14, Tony Finch wrote:

But remember: the goal is to make the DNS easier to use for people
who don’t know about the restrictions on CNAMEs.


I'd say the goal is to make the DNS *possible* to use for people who
don't know about the restrictions on CNAMEs.

I concede that ANAME perhaps makes that easier than HTTP does, but it 
does so at the expense of significant complexity in authority servers by 
still requiring A and  lookups to be somehow "magic", and doesn't 
fix the architectural problem of lack of a service identifier.


Note that the latest draft of ANAME does not require the lookup to be in 
the authority servers.


Best regards,

Matthijs



My long-term goal would be to never have an A or  record appear in 
the DNS other than at the owner name of an actual hostname.


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] Further ANAME minimization /\ Ray convergence

[Matthijs Mekking]

On 11/6/18 6:28 PM, Tony Finch wrote:

But thinking about the discussions from the weekend and yesterday, it
occurs to me that it might make sense to simplify ANAME even further:

   * Make all authoritative processing optional, whether UPDATE style or
 dynamic on-demand.

   * The sibling address records have to be provisioned, to act as fallback
 records for clients/resolvers that don't (yet) do their own ANAME
 processing. (There may be some automated assistance.)


That is indeed what I am aiming at, with the exception that sibling 
records may be provisioned to act as fallback records (they don't 
necessarily have to, but the ANAME algorithm may use them if they exist 
and if resolution of the target address records failed).


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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

As nice and clean the HTTP record draft is, without specifying how to do 
expansion of the record into address records it is not going to solve 
the CNAME-at-the-apex problem that DNS providers have, and we will stick 
with the proprietary solutions (this may solve a different use case though).


Best regards,

Matthijs

On 03-11-18 18:04, Ray Bellis wrote:



On 21/09/2018 20:12, Dan York wrote:

I do think this is a path we need to go.  We need *something* like 
CNAME at the apex.  Either CNAME itself or something that works in the 
same way but might have a different name.


I agree, and earlier today (well, yesterday, now) I wrote it up:

A new version of I-D, draft-bellis-dnsop-http-record-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:    draft-bellis-dnsop-http-record
Revision:    00
Title:    A DNS Resource Record for HTTP
Document date:    2018-11-04
Group:    Individual Submission
Pages:    5
URL: 
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-http-record-00.txt

Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-http-record/
Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-http-record-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-http-record



Abstract:
    This document specifies an "HTTP" resource record type for the DNS to
    facilitate the lookup of the server hostname of HTTP(s) URIs.  It is
    intended to replace the use of CNAME records for this purpose, and in
    the process provides a solution for the inability of the DNS to allow
    a CNAME to be placed at the apex of a domain name.


___
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] Fundamental ANAME problems

[Matthijs Mekking]

Hi Brian,

Thanks for your feedback on ANAME. Comments inline.

On 01-11-18 23:34, Brian Dickson wrote:

Greetings, DNSOP folks.


[...]


First, there is the issue of imposed update frequency.

The requirement on update rate, is imposed externally by whichever 
entity operates the ANAME target. In other words, this is not under the 
direct control of the zone operator, and is potentially a potentially 
(and very likely) UNBOUNDED operational impact/cost.


As John already pointed out: You are in control of the update rate. It 
may be that the target address records are changing frequently, but it 
is up to the one that processes the ANAME to set an appropriate update 
rate. So I don't see this as a particular worry.


The draft uses DNS UPDATE as an example and that may be a useful 
scenario for one, but a red flag for another. However I will use ANAME 
and no DNS UPDATE and I think my implementation of ANAME is still 
compatible with the specification.


What I would like to see be changed in the draft is that were ANAME 
processing occurs is more relaxed: Currently it focuses on this 
happening at zone provisioning time (before the zone is loaded by the 
primary), and mentions an optimization algorithm for resolvers that is 
optional. However, there is some text in section 5.2 Alternatives that 
the ANAME processing can occur on secondary servers which I think may 
fit your DNS infrastructure better.


The point is that this draft should standardize the way ANAME is 
processed, while giving flexibility on where processing can occur.




Second, this issue is compounded by scale.

The issue here is, that the larger the entity is that operates zones 
with ANAMEs is, the larger the resulting impact. This is a new, 
unanticipated, asymmetric cost. It has the definite potential to make 
operating authority servers prohibitively costly.


I don't see any difference with existing proprietary implementations: 
This statement is true for any CNAME-at-the-apex solution.



Third, there is an issue with the impact to anycast operation of zones 
with ANAMEs, with respect to differentiated answers, based on 
topological locations of anycast instances.


There is currently an expectation on resolving a given name, that where 
the name is ultimately served (at the end of a *NAME chain) by an entity 
doing "stupid DNS tricks" (e.g. CDNs), that the answer provided is 
topologically appropriate, i.e. gives the "best" answer based on 
resolver (or in the case of client-subnet, client) location.


[...]

As I said above: I agree that the draft should relax where ANAME 
processing can occur. I don't see any reason why this processing can be 
done at the entity that does the stupid DNS trick.


[...]

ANAME places the authority servers in an anycast cloud, in a "Hobsons 
choice" scenario. Either a single, globally identical sibling value is 
replicated to the anycast instances (which violates the expectation of 
resolvers regarding "best" answer), or each anycast instance needs to do 
its own sibling maintenance (with all that implies, including on-the-fly 
DNSSEC signing), or the anycast cloud now has to maintain its own set of 
divergent, signed answers at the master, and add all the complexity of 
distributing and answering based on resolver topological placement. (The 
last two have significant risk and operational complexity, multiplied by 
the volume of zones served, and impacted by the size of the anycast cloud.)


If you are going to do stupid tricks (aka tailored responses), you will 
have to do on-the-fly DNSSEC signing anyway.



Side-note: we, as a community, have been pushing for wide-scale adoption 
of DNSSEC; this definitely places a significant hurdle to adoption, 
precisely in a wide-scale manner, i.e. to the vast majority of DNS 
registrants. It is a big roadblock to DNSSEC adoption, and a move in the 
wrong direction.


I disagree, I think it works pretty well with DNSSEC given the 
requirement that ANAME processing should happen before DNSSEC signing. 
This requirement is reasonable since ANAME processing is in the business 
of tailoring RRsets and any changes made to the zone contents must 
happen before signing.




What are the alternatives?

Fundamentally, the behavior that is desired that we are collectively 
trying to preserve, is that of resolver-based *NAME chain resolution, 
just with the ability to do so at the apex of a zone.


This points to the only logical places that MUST be part of any 
apex-based chaining of resolution: resolvers, or clients.


John is right: It is very hard to rely on a solution that depends on 
recursive name servers to be updated. Hence we look at a solution that 
can be implemented at authorities.



Kind regards,

Matthijs

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

Re: [DNSOP] ANAME TTL vs GCD

[Matthijs Mekking]

I am still of the opinion that the expanded A and  records should 
use the ANAME TTL*, and the target TTL should be ignored. That TTL is 
only useful for the cache that is used as part of the ANAME expansion 
process.



The ANAME TTL may be subject to decreasing, if sibling A and  
records already exist with a lower TTL.


Best regards,
  Matthijs



On 30-10-18 12:50, Tony Finch wrote:

One of the more complicated aspects of ANAME is working out how TTLs
should work, because there are a bunch of tricky constraints. There's
a fairly long rationale in an appendix about the various issues -
https://tools.ietf.org/html/draft-ietf-dnsop-aname-02#appendix-D

As a design guideline (to help decide choices) I have tried to make ANAME
"like CNAME but only for address records", as much as possible.

So, the current spec says that the TTL of the sibling address records is
the least TTL from the chain of ANAME and CNAME records and the ultimate
target address records. This tries to match the implicit TTL of a CNAME
chain, which is a result of the chain being followed each time on demand,
so the earliest time the result can change is when the record with the
least TTL changes.

As a zone administrator, I prefer not having to care about TTLs too much,
so I prefer the ANAME mechanism to do the sensible thing without
hand-holding. I had a suggestion (from Matthijs Mekking I think?) of just
using the ANAME's TTL to set the TTL of the sibling address records, but
for the zones I look after, this would require a lot of special-case TTLs
and annoying manual work.

However, I just realised the currently specified "least TTL" logic is
going to have interesting effects when the greatest common divisor of the
TTLs is less than the least TTL, when the ANAME processor is querying via
a resolver cache that is outside its control.

e.g. consider what happens when there is an ANAME with TTL 30s and target
address records with TTL 45s.

In the first round, the ANAME processor will choose a 30s TTL.

In the second round, 30s later, it will get the target address records
from the cache with a 15s TTL, so it'll choose a 15s TTL.

The in the third round it'll be back to 30s.

The TTL will flip-flop, and there will be a lot of unwanted zone updates.

This is ugly :-( I'm not sure what the best solution is.

One possibility is to make the ANAME processor keep a bit more state. At
the moment its nearly-stateless algorithm naturally sees through caches to
converges on the target's authoritative TTL, because it re-checks after
the cache expires. If instead it explicitly tracks the TTLs of each link
in the ANAME+CNAME chain and deliberately works out the authoritative
TTLs, then it can avoid the GCD flip-flop. But it would makes the algorihm
and spec quite a lot more complicated, though I think I prefer that to
manual hand-holding...

Tony.



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

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

[Matthijs Mekking]

On 07/05/2018 06:15 PM, Tony Finch wrote:

Tim Wicinski  wrote:


The chairs have decided to set aside some time in Montreal and see if we
can work through this problem.  We've asked Ondřej  from ISC and Willem
from NLnetLabs to help guide the talk.


I was hoping that there would be another revision of the draft following
IETF 101, based on the discussions we had then.


Me too :)

https://github.com/each/draft-aname/pulls

Matthijs



Is there some huge problem that I haven't noticed?

Tony.



___
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] RFC 6781 Errata?

[Matthijs Mekking]

I think the line:

After that DS RR has been
published on all servers authoritative for the parent's zone, the
zone administrator has to wait at least TTL_DS to make sure that
the old DS RR has expired from caches.

Could be part of the 'DS change' step.

It qualifies as an errata IMHO.

Best regards,
Matthijs


On 04/26/2018 04:15 PM, Matthew Pounsett wrote:
I've found some confusing text in the KSK Rollover section of RFC 6781, 
and I'm trying to decide whether to submit it as errata.


In section 4.1.2, which describes the various steps in a KSK rollover, 
the following text is meant to describe the last three steps:


    new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
       generates a second KSK, DNSKEY_K_2.  The key is provided to the
       parent, and the child will have to wait until a new DS RR has
been
       generated that points to DNSKEY_K_2.  After that DS RR has been
       published on all servers authoritative for the parent's zone, the
       zone administrator has to wait at least TTL_DS to make sure that
       the old DS RR has expired from caches.

    DS change:  The parent replaces DS_K_1 with DS_K_2.

    DNSKEY removal:  DNSKEY_K_1 has been removed.


The text for the "new DNSKEY" step seems to contain text that belongs in 
the other two..  Even though rearranging it wouldn't change the meaning, 
it's not clear to me that this qualifies as simple errata.. it's 
obviously too big a change to just be fixing a typo.


Thoughts on whether I should submit it?

Or maybe we just put it on the pile of things that have come up recently 
that speak to a 6781-bis document.





___
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] mixfr - issue #10 - Client RRSIG logic simplification

[Matthijs Mekking]

Mark,

On 04/04/2018 03:52 PM, Mark Andrews wrote:


Note that implicit RRSIG deletion is idempotent, so it does not matter if two 
RRs in the MIXFR trigger it.


Not if you are processing the additions on a RR by RR basis. You can add a new 
RRSIG
before you add the covering RR.  You need to perform two passes over the 
addition section.
1 - to perform implicit deletions.
2 - to perform explicit additions.


If I removed the existing RRSIGs covering "example. A" from the zone, 
now process the next "example A" RR in the MIXFR, that triggers removing 
the same existing RRSIGs, those are already gone and stay gone. That 
seems idempotent to me.


Note that an IXFR client, should only replace an older version with a 
newer version after all the differences have been successfully processed 
(RFC 1995).


The same will be true for MIXFR.



Note there are some RR deletions / addition pairs that DO NOT change RRSIGs. 
e.g. case changes
in domain names that are subject to canonicalisation.  There is no requirement 
to regenerate
RRSIGs for such changes though most implementations will do so.


It might be good to add some text for that case. Thanks for bringing it up!

Best regards,
  Matthijs

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

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

[Matthijs Mekking]

Joe,

Thanks for sharing your concerns.

On 04-04-18 05:31, Joe Abley wrote:

On Apr 3, 2018, at 21:32, Frederico A C Neves <fne...@registro.br>
wrote:


On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking
wrote: Hi Frederico,


On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was
looking at our server to evaluate the MIXFR implementation and 
it seams to me that the current text covering dnssec aware

client logic don't take in account that a posterior record at
the addition section, by an MIXFR DNSSEC aware server, will
implicitly replace the RRSIG RRset.


I am unclear what case you are covering.


Any situation that you have an updated RRset. It is implicit that 
you'll have to update the signature, so I was arguing that this is 
afterward covered by 3.6 Replace a RRset. My "simplified" logic

take this in account to don't impose this extra logic at the client
for updated RRsets, only for removed RRsets, explicit or when a
removal of RR causes it.


I have not been reading this thread in depth and so I have not
commented up until now. But I sense that there is a proposed shift of
responsibility for coherency in the contents of a zone, specifically
with resapect to DNSSEC. Quite possibly I am wrong, in which case I
will enjoy being told as much.


I am happy to entertain you by telling that there is no shift in 
responsibility for coherency in the contents of a zone.


We are merely trying to come up with a more sophisticated syntax such 
that the primary has to use less bytes to achieve zone consistency.




If I am a zone administrator, responsible for the self-consistent
contents of my zone, and I make a mistake, the behaviour today (with
zones distributed by AXFR, IXFR, rsync, ftp, avian carrier) is that a
DNS zone is a DNS zone and the RRSets contained within are simply
that, no appreciation, understanding or accommodation of DNSSEC
required.


I see your argument. On the other hand, if you make a mistake with 
DNSSEC you are in trouble anyway.




The line of thinking inherent in the lowest quoted paragraph above
suggests that distribution of sets of RRSets (together forming a
zone) must with this new transfer mechanism be completed with
semantic appreciation for the relationship between non-RRSIG-type
RRSets and the corresponding RRSIG-type RRSets that accompany them in
a signed zone. This worries me.

The protocol requirements for DNSSEC as described in RFC 4035 are
non-trivial to implement already (cf. the treatment of RRSets in a
response with their accompanying RRSIG RRSets as an atomic unit in
the cache, to be expired together regardless of differences in TTL)
and I don't think we want to extend them without good reason.


Note that this does not affect resolvers and caches: zone transfers are 
between authoritative name servers only.


I am determined to back the specification with an implementation, 
especially after the camel is our new favorite animal, so hopefully that 
will take away your concerns regarding implementation complexity.




If we expect MIXFR (or whatever it is eventually called) to behave
differently in this respect to AXFR, IXFR or any number of
out-of-band transfer mechanisms, we should have a good reason for it.
I don't know that I see one, yet.


It is zone transfer size. It can be quite large with DNSSEC (zone 
re-sign, NSEC3 resalt). To quote someone: Reducing the amount of data, 
is the only way to keep up with our current and future workloads.


Best regards,
  Matthijs





Joe ___ 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] mixfr - issue #10 - Client RRSIG logic simplification

[Matthijs Mekking]

Hi Frederico,

On 04-04-18 03:32, Frederico A C Neves wrote:

Hi Matthijs,

On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:

Hi Frederico,

On 03/29/2018 08:45 PM, Frederico A C Neves wrote:

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


I am unclear what case you are covering.


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


I get it now, thanks for clarifying.

Still, I think the savings in complexity is minimal, since the logic 
should exist for RR deletion, so it's a small effort to also enable it 
for RR addition.


Looking at your examples, there is very little difference on the wire. 
So it would only be for client logic purposes I assume. I doubt that the 
logic is simplified though:


If you want to prevent implicit RRSIG deletion in the "Replace RRset" 
case, you now have to have logic to verify there is no RR in the 
addition section of the MIXFR.


Note that implicit RRSIG deletion is idempotent, so it does not matter 
if two RRs in the MIXFR trigger it.


Best regards,

Matthijs



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

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

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


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

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




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


No, also if there is an RR addition, it means the RRset has changed, so
existing RRSIG records can be implicitly removed.



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

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


Note there is no such thing as an RRSIG RRset. I tried to clarify this
in the terminology bis document:


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



https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html

Note that adding an RRSIG is different than replacing an RRSIG.


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




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

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


I think it makes more sense to keep the text as is, that is when
changing an RRset implicitly remove the corresponding RRSIG records. I
am opposed to only removing corresponding RRSIG on a RR deletion.



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

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

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

[Matthijs Mekking]

On 03-04-18 15:22, Mark Andrews wrote:


-- Mark Andrews

On 3 Apr 2018, at 22:37, Matthijs Mekking<matth...@pletterpet.nl>
wrote:

Hi Frederico,


On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was looking
at our server to evaluate the MIXFR implementation and it seams
to me that the current text covering dnssec aware client logic
don't take in account that a posterior record at the addition 
section, by an MIXFR DNSSEC aware server, will implicitly replace

the RRSIG RRset.

I am unclear what case you are covering.



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

No, also if there is an RR addition, it means the RRset has
changed, so existing RRSIG records can be implicitly removed.

>

Poor logic. Take the case where you add a new algorithm to the DNSKEY
RRset there is no requirement to update existing RRSIG.


If I add a DNSKEY record to the RRset, I would definitely want a new 
RRSIG because the data changed, so the existing signature is no longer 
useful.




Even when re-signing you can’t remove RRSIG with the same key id
unless you know that the server prevents duplicate key ids.  For the
general case you need to validate the RRset against the RRSIG to give
the DNSKEY then you can delete RRSIGs generated from that DNSKEY.


Implicit RRSIG deletion is only for RRSIG records covering the RRset 
that has changed. It is not meant for re-signing purposes, nor is it 
meant for sophisticated DNSKEY tracking.



- Matthijs



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

Note there is no such thing as an RRSIG RRset. I tried to clarify
this in the terminology bis document:

https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html

Note that adding an RRSIG is different than replacing an RRSIG.


This is documented as issue #10 and includes proposed text. 
https://github.com/matje/mixfr/issues/10

I think it makes more sense to keep the text as is, that is when
changing an RRset implicitly remove the corresponding RRSIG
records. I am opposed to only removing corresponding RRSIG on a RR
deletion.

Best regards, Matthijs



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




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

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

[Matthijs Mekking]

Hi Frederico,

On 03/29/2018 08:45 PM, Frederico A C Neves wrote:

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


I am unclear what case you are covering.



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


No, also if there is an RR addition, it means the RRset has changed, so 
existing RRSIG records can be implicitly removed.




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


Note there is no such thing as an RRSIG RRset. I tried to clarify this 
in the terminology bis document:


  https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html

Note that adding an RRSIG is different than replacing an RRSIG.



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

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


I think it makes more sense to keep the text as is, that is when 
changing an RRset implicitly remove the corresponding RRSIG records. I 
am opposed to only removing corresponding RRSIG on a RR deletion.


Best regards,
  Matthijs




Fred

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



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

Re: [DNSOP] raising the bar: requiring implementations

[Matthijs Mekking]

I can agree with the argument that if implemented in a major open-source 
DNS implementation it would weigh in more to the discussion, but 
limiting to is far too restricting in my opinion.


Best regards,
  Matthijs


On 03/28/2018 09:48 PM, Mukund Sivaraman wrote:

On Wed, Mar 28, 2018 at 05:29:18PM +0200, Matthijs Mekking wrote:

As mentioned in the meeting, I am in favor of requiring implementations
before drafts become standards.

However, I would be opposed to limit acceptable implementations to the few
major open source DNS implementations (define major). It should be
acceptable for other organizations or just persons to contribute a reference
implementation.


It depends on the topic of the draft of course, esp. where in operations
it applies. If it is nameserver territory, I absolutely want to see an
implementation in *any* of the major DNS implementations. By major, I
mean the popular ones (e.g., PowerDNS, NSD, Unbound, Knot, etc.) This is
because:

* A full-fledged nameserver is somewhat different from a toy
   implementation in performance and scalability (this point is from
   experience with a bad implementation of a draft)

* The rest of us want to see proof that it can be implemented (not just
   a promise or mention of implementation) and play with it and observe
   operational characteristics _freely_, and determine whether a draft
   will really improve things in the way it says it will. E.g., take all
   the multiple-answer drafts that are making the rounds.. in Singapore
   there was a presentation of a grand matrix of them, but who knows how
   they actually perform?

It's 2018. We aren't living in the dark ages with a single DNS
implementation.

If a draft is for nameserver software to implement, and if the authors
cannot implement it by themselves, they can persuade one of the open
source vendors to do so. If they are unable to persuade any, that should
be enough consensus about how significant that draft is. Speaking for
myself, we in our DNS implementation add support for several drafts
early in the draft stage because they look necessary or interesting, or
because we want to know how they behave early on.

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] A new version of mixfr

[Matthijs Mekking]

Frederico,

On 03/28/2018 05:06 PM, Frederico A C Neves wrote:

Hi Matthijs,

On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:

All,

It's been a while, but I have put up a new version of the MIXFR draft:

  https://tools.ietf.org/html/draft-mekking-mixfr-02

The IETF 101 Hackathon lead to the revival of this draft.

Changes after the three year sleep:

- I removed the IXFR Gone Wild section. This document should focus in
the in-band transfer improvements. I know there are others who like to
see and work on a new DNS transfer protocol, but one does not exclude
the other.
- Intended status: Standards track.
- Added a clarification from Bob Harold about class ANY (from 2015).
- Remove ambiguous "Delete All RRsets of a Type".
- Affiliation changes.



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


Thank you.



One comment,

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

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

3.1 Implicit DNSSEC deletions

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


I agree that with the current syntax NSEC3 resalting is still a hassle. 
But I am not sure if this implicit NSEC3 deletion is the right solution: 
One can have multiple chains in the zone, the NSEC3PARAM just signals 
that the chain is complete. Signers may have incomplete chains as an 
intermediate step of NSEC3 resalting.


I shall add a GitHub issue for this. Thanks for bringing it up!



One clarification question,

At 3.6, last paragraph, what is the practical case that a updated
record has an RDLENGTH of zero bytes?


It is as Richard pointed out not required, but I would like to clarify 
the difference between deleting an RRset and replacing an RRset.


Best regards,

Matthijs


  

Who would like to contribute, review, and all that great fun?

Github is here: https://github.com/matje/mixfr

Best regards,
Matthijs


Fred



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

Re: [DNSOP] A new version of mixfr

[Matthijs Mekking]

Richard,

On 03/28/2018 04:44 PM, Richard Gibson wrote:

I really like this document, especially the changes to version 02.


Thanks:)

One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH 
must be non-zero" _and_ that "The same syntax is used to delete an RRset 
and to replace an RRset with an RR whose RDLENGTH is zero". I think the 
former should be dropped; replacing an RRset with a new record having 
zero RDLENGTH is disambiguated by containing section so there is no 
reason to prohibit it.


Right. But we use RDLENGTH must be zero in the case to delete a whole 
RRset. So I do like to have some words to clarify it. But you are right 
that it is not a requirement.



Best regards,

Matthijs





On 03/28/2018 09:31 AM, Matthijs Mekking wrote:

All,

It's been a while, but I have put up a new version of the MIXFR draft:

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmekking-2Dmixfr-2D02=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=9E3JS209vJp6dQBpJJBXlr32ZbLYLOLNNAiovQ1iAnY= 



The IETF 101 Hackathon lead to the revival of this draft.

Changes after the three year sleep:

- I removed the IXFR Gone Wild section. This document should focus in 
the in-band transfer improvements. I know there are others who like to 
see and work on a new DNS transfer protocol, but one does not exclude 
the other.

- Intended status: Standards track.
- Added a clarification from Bob Harold about class ANY (from 2015).
- Remove ambiguous "Delete All RRsets of a Type".
- Affiliation changes.

Who would like to contribute, review, and all that great fun?

Github is here: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_matje_mixfr=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=9jcbJIa5DBxRHlL2wVDEwCWBJXvbZffQobFtQvjEMH0= 



Best regards,
  Matthijs

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=n1GMn0ZrYJoVbOVyFWt2A2n2n6d5T3xoCwjdK8xsbiw= 





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

Re: [DNSOP] raising the bar: requiring implementations

[Matthijs Mekking]

On 03/28/2018 05:19 PM, Mukund Sivaraman wrote:

On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:

I would say that most things we have adopted in the past few years do have
some implementations to reference.
Not when drafts are adopted, but generally before we head to WGLC I've
always wanted to see someone
who implemented the option in some manner.

But yes, agree.


I'd raise the bar even higher, to see complete implementation in a major
open source DNS implementation when it applies. Sometimes implementation
problems are very revealing (client-subnet should have gone through
this).


As mentioned in the meeting, I am in favor of requiring implementations 
before drafts become standards.


However, I would be opposed to limit acceptable implementations to the 
few major open source DNS implementations (define major). It should be 
acceptable for other organizations or just persons to contribute a 
reference implementation.


Best regards,

Matthijs





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] A new version of mixfr

[Matthijs Mekking]

Pieter,

On 03/28/2018 04:43 PM, Pieter Lexis wrote:

Hi Matthijs,

On Wed, 28 Mar 2018 15:31:57 +0200
Matthijs Mekking <matth...@pletterpet.nl> wrote:


It's been a while, but I have put up a new version of the MIXFR draft:

  https://tools.ietf.org/html/draft-mekking-mixfr-02


The draft speaks of an OPCode in the IANA section and of a meta
RRType in the examples and Introduction section, which is it?


Probably copy paste error from a different draft. MIXFR is a new query 
type, so that's an error in the IANA section. The intention is to 
request a new RRtype. Thanks for catching this.




If it is an RRType, some words need to be added about the fact that
current resolvers will pass through the MIXFR query and not reply with
NOTIMPL. In a similar vein, unaware auths will respond with an NXDOMAIN
or (more likely) a NODATA in that case.


IXFR solved this by saying "If the query type is not recognized by the 
server, an AXFR (preceded by a UDP SOA query) should be tried, ensuring 
backward compatibility." Probably MIXFR can say something similar.


A resolver should behave similar for MIXFR as it does for AXFR and IXFR. 
I can't find words about this in RFC 1995 or RFC 5936, so I am not sure 
if this document should add something about that.



Groeten,

Matthijs



Best regards,

Pieter



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

Re: [DNSOP] A new version of mixfr

[Matthijs Mekking]

Tony,

On 03/28/2018 04:08 PM, Tony Finch wrote:

Matthijs Mekking <matth...@pletterpet.nl> wrote:


It's been a while, but I have put up a new version of the MIXFR draft:

 https://tools.ietf.org/html/draft-mekking-mixfr-02


I've had a quick skim and it looks nice.


Thanks.



Suggestions for 2nd paragraph of intro:

To keep the deltas small in zone transfers, we need to have a richer
change syntax. This specification re-uses syntax from DNS UPDATE,
[RFC2136].  It introduces a new query type MIXFR (minimal
incremental zone transfer) that allows a client to request this richer
syntax.  The goal of this proposal is to allow small changes to be
communicated over UDP, and remove as much redundant information from
the zone transfer as possible.


I am happy take this. Thanks for contributing text!



I still prefer the name "UXFR (update-style IXFR)" :-)


I guess we can start a vote ;)



Is UDP support supposed to be required? (I believe BIND requires TCP for
IXFR even if the delta could fit in UDP.)


According to RFC 1995: Transport of a query may be by either UDP or TCP.

Best regards,
  Matthijs



Tony.



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

Re: [DNSOP] DNS Camel Viewer

[Matthijs Mekking]

Nice viewer :)

What immediately catches my eye is that the DNSSEC RFCs 4033-4034-4035 
are a Proposed Standard, and RFC 5011 is an Internet Standard. In fact, 
RFC 5011 is the only DNSSEC Internet Standard. That can't be right, 
right? :)


Matthijs



On 24-03-18 17:51, bert hubert wrote:

Hi everyone,

[tl;dr, check out https://powerdns.org/dns-camel/ ]

As a first step in attempting to not only whine about a glut of DNS
standards, I've made an easy to update viewer of all DNS relevant standards.

The good news is, if we filter out obsoleted, historical, informational and
BCP documents, we are left with a lot less pages. The bad news is, 1403
pages remain.

I took the set of RFCs from https://www.isc.org/community/rfcs/dns/ and
augmented this with the recent RFCs published by DNSOP and DPRIVE.

The page is on https://powerdns.org/dns-camel/ - it is a bit slow to load
because it sources the 12MB IETF XML file describing all RFCs. It should do
this only once and then be fast.

The goal is to augment this view with all drafts that are currently active,
so we can also see "what is coming".

If you know of RFCs that should or should not be on the list, please edit
dns-rfcs.js on https://github.com/ahupowerdns/dns-camel/

It is my hope that this view will be helpful in determining:

1) What to obsolete
2) The "must read" list for:
a) stub resolvers
b) dns caches / resolvers
c) authoritative servers
3) The "must not read" list - documents not worth it to obsolete, but
considered confusing or misguided
4) Perhaps take a good look at the drafts we are currently working on

Bert

___
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] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Matthijs Mekking]

On 24-03-18 14:48, Joe Abley wrote:

On Mar 24, 2018, at 13:49, Jared Mauch  wrote:


isc/bind can and perhaps should implement logging for these
rrtypes that say they may be going away so folks can see the impact.


I'm actually surprised to see that support for rarely-used RRTypes is
really upsetting the camel.


To me this deprecating obsolete records is more an exercise of picking 
the low hanging fruit. Start with an easy task, gain experience for more 
difficult "unloading the camel".


Best regards,
  Matthijs



A combinatorial explosion of annoying workarounds for the inability of
middleboxes or upstream authority servers to implement EDNS(0)
properly seems like a much more plausible camel irritant to me. I'm
sure there are many more like that.

I can see why you could strip out lines of code by eliminating the
need to parse the canonical formatting of WKS and friends, but I'm
surprised that it's a notable source of complexity. It is, after all,
complexity that I heard is causing the camel strain, not just lines of
code.

If future-BIND stops parsing an archaic RRType that I happen to use,
I'm going to have to change whatever code or processes that depend on
it. Maybe someone (ISC, even) is going to publish a filter that will
turn all the old RRs in canonical syntax into TYPE representation,
and back again. New RRTypes might then need to get implemented in both
BIND (because presumably they are camel-friendly) and also in the
filter or filters, because perhaps we are targeting multiple
nameserver implementations with our zone file.

This all sounds like we're just sharing the complexity around. It
doesn't sound any simpler. Maybe it's a silly example? I don't know.
Could be. But I think brushing the grains RRType parsing dust off the
camel is not going to do much for its posture.


Joe

___
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] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Matthijs Mekking]

Other candidates: MD, NXT, MAILA - They are obsolete too according to 
the IANA DNS parameters.


Also, if you want to deprecate MB, MG, you might want to consider 
deprecating MAILB too.


- Matthijs


On 23-03-18 13:11, Ondřej Surý wrote:

Heya,

this is a first attempt to start reducing the load on DNS Implementors 
and actually remove the stuff from DNS that’s not used and not needed 
anymore.


There’s github for the draft: 
https://github.com/oerdnj/draft-sury-dnsop-deprecate-obsolete-resource-records


Ondrej
--
Ondřej Surý
ond...@isc.org 


Begin forwarded message:

*From: *internet-dra...@ietf.org 
*Subject: **New Version Notification for 
draft-sury-deprecate-obsolete-resource-records-00.txt*

*Date: *23 March 2018 at 12:09:19 GMT
*To: *"Ondrej Sury" >


A new version of I-D, 
draft-sury-deprecate-obsolete-resource-records-00.txt

has been successfully submitted by Ondrej Sury and posted to the
IETF repository.

Name:draft-sury-deprecate-obsolete-resource-records
Revision:00
Title:Deprecating obsolete DNS Resource Records
Document date:2018-03-22
Group:Individual Submission
Pages:4
URL: 
https://www.ietf.org/internet-drafts/draft-sury-deprecate-obsolete-resource-records-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-sury-deprecate-obsolete-resource-records/
Htmlized: 
https://tools.ietf.org/html/draft-sury-deprecate-obsolete-resource-records-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-sury-deprecate-obsolete-resource-records



Abstract:
  This document deprecates Resource Records that are neither being used
  for anything meanigful nor already made obsolete by other RFCs.  This
  document updates [RFC1035].




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



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

Re: [DNSOP] Multi Provider DNSSEC Models

[Matthijs Mekking]

I agree, model 1 and model 2 seems doable. Note that RFC 6781 has some 
text for model 2 on rollover when changing DNS operators.


https://tools.ietf.org/html/rfc6781#section-4.3.5

Matthijs

On 22-03-18 13:50, Tony Finch wrote:

Olafur Gudmundsson  wrote:


I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS
RRset's are signed by zone publisher but rest signed by operator on the
fly.



From the provider point of view, I think there are a couple of models:


(a) provider has KSK and ZSK; zone owner needs to be able to import other
provider public keys into this provider's DNSKEY RRset, and export signed
DNSKEY RRset.

(b) provider only has ZSK; zone owner needs to be able to export public
keys, and import signed DNSKEY RRsets.

Given this, I think a zone owner can implement either model 1 or
model 2 from the draft. Model 3 requires sharing private keys.

Tony.



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

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

[Matthijs Mekking]

On 19-03-18 20:08, Matthew Pounsett wrote:



On 19 March 2018 at 08:21, Matthijs Mekking <matth...@pletterpet.nl 
<mailto:matth...@pletterpet.nl>> wrote:


I and some others have been using the term 'Negative response' to
indicate that the response does not contain any records in the
Answer section. Current definition seems to imply that this is only
the case if the RCODE is NXDOMAIN, NOERROR, SERVFAIL or if there was
a timeout (unreachable). The definition I have been using includes
responses with other RCODEs too, for example FORMERR or REFUSED. 



I wonder if this is just me and my bubble or if others also a
slightly different meaning of 'Negative response' as it is defined
now. If there are others, is it worth spending a line or two about
this here?


I would suggest that only NXDOMAIN and NOERROR+ANCOUNT=0 are negative 
responses.   SERVFAIL, FORMERR, and REFUSED are error responses; you do 
not know as a result of those responses whether the name/type tuple 
queried about exists.


Fair enough, just note that RFC 2308 defines SERVFAIL as (Other) 
Negative Response.


Best regards,
  Matthijs



___
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] Status of draft-ietf-dnsop-terminology-bis

[Matthijs Mekking]

Hi,


While I was not waiting for WG last call, it is a while ago since I have 
read this draft. Positive is that I read it without it leading to a lot 
of confusion or outrage.


I have some small comments though.


Negative response:

I and some others have been using the term 'Negative response' to 
indicate that the response does not contain any records in the Answer 
section. Current definition seems to imply that this is only the case if 
the RCODE is NXDOMAIN, NOERROR, SERVFAIL or if there was a timeout 
(unreachable). The definition I have been using includes responses with 
other RCODEs too, for example FORMERR or REFUSED.


I wonder if this is just me and my bubble or if others also a slightly 
different meaning of 'Negative response' as it is defined now. If there 
are others, is it worth spending a line or two about this here?



RRsets:

Raised by a discussion I had at the Hackathon, I think it would be 
useful to add some clarification about RRSIGs and their role with 
respect to RRsets. Perhaps a quote from RFC4035 will do:


   An RRset MAY have multiple RRSIG RRs associated with it.  Note that
   as RRSIG RRs are closely tied to the RRsets whose signatures they
   contain, RRSIG RRs, unlike all other DNS RR types, do not form
   RRsets.  In particular, the TTL values among RRSIG RRs with a common
   owner name do not follow the RRset rules described in [RFC2181].


Last, I don't fully understand the meaning of the cryptic comment about 
QTYPE=ANY that is under the RRset definition:


   (This definition is definitely not the same as "the
   response one gets to a query for QTYPE=ANY", which is an
   unfortunate misunderstanding.)

Can you explain why this comment is here?


Thanks, best regards,

Matthijs




On 05-03-18 17:14, Paul Hoffman wrote:
Greetings. As you can see, draft-ietf-dnsop-terminology-bis-09.txt is 
out. Reading the diff might be a bit difficult because of the 
reorganization of some sections that y'all asked for, but I think the 
result is worth the extra effort.


We're still not done yet. I took a hiatus from finishing the list of 
definitions that people wanted more scrutiny on, but will start that 
again soon. I hope we'll be done with that list by mid-April and then be 
ready for WG last call.


As a side note, some of the changes in this version came from people 
reading the document fresh. I encourage folks who were maybe waiting for 
WG Last Call to do a first deep reading of the document to instead do so 
now. The work that everyone is doing on this document will go a long way 
to making the final RFC more valuable for lots of folks entering the field.


--Paul Hoffman

___
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] RFC6781 (5273)

[Matthijs Mekking]

All,

I think this errata is incorrect: For an algorithm rollover it is 
intended that at the "DNSKEY removal" step, the DNSKEYs are removed from 
the zone, but the signatures stay. This is to play nicely with 
conservative validators:


   The conservative approach interprets this section very strictly,
   meaning that it expects that every RRset has a valid signature for
   every algorithm signaled by the zone apex DNSKEY RRset, including
   RRsets in caches.

However, looking into this errata I do think there is an error in Figure 
8 in section 4.1.4:


The figure should have the signature of the old KSK, called 
RRSIG_K_1(DNSKEY) in the "DNSKEY removal" step.


Because a conservative validator may have the DNSKEY RRset cached that 
includes DNSKEY_K_1, DNSKEY_K_2, DNSKEY_Z_1, and DNSKEY_Z_2.



Regarding the notes on this errata:

> because:  I just don't think you can sign a zone without the
> corresponding ZSK's.

It is certainly possible to sign zones and not publish the corresponding 
DNSKEY.


Best regards,
  Matthijs


On 03-03-18 15:03, RFC Errata System wrote:

The following errata report has been submitted for RFC6781,
"DNSSEC Operational Practices, Version 2".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5273

--
Type: Technical
Reported by: Peter J. Philipp 

Section: 4.1.4

Original Text
-
Figure 8 on page 30.

Corrected Text
--
The figure should have the second ZSK DNSKEY, called DNSKEY_Z_10 under
DNSKEY removal because SOA_3 is doubly signed.

or

The figure should not have the second RRSIG for SOA_3 that is derived
from DNSKEY_Z_10.

because:  I just don't think you can sign a zone without the
corresponding ZSK's.







Notes
-
It looks wrong to me.  A small technicality.  I'll let the authors decide if 
it's really wrong.

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.

--
RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
--
Title   : DNSSEC Operational Practices, Version 2
Publication Date: December 2012
Author(s)   : O. Kolkman, W. Mekking, R. Gieben
Category: INFORMATIONAL
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



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

Re: [DNSOP] 5011-security-considerations and the safetyMargin

[Matthijs Mekking]

Wes,

My preference is to include safetyMargin and have text to explain it 
exists because of network delays etcetera, and also reference to RFC 
5011's retryTime. So that's some mix of 1B 1C or 2B I guess :)


Best regards,
  Matthijs

On 15-11-17 02:49, Wes Hardaker wrote:


The discussion has been long with respect to the safetyMargin in the
5011 security considerations document.  There hasn't been a huge
conclusion and many different ideas have been floated by, and we're now
at the point where we need to pick between them.  Below, I try to lay
out the primary and sub-options available based on discussions so far.
Please provide your opinions on your preference so I can wrap up this
draft.

Background: This document is not intended to provide operational
guidance on what you SHOULD do.  It's intended to draw the timing line
below which you MUST NOT venture.  The safetyMargin was introduced to
prevent race conditions based on network delays, eg, which can mean that
a RFC5011 Resolver operating at the same time as a PEP Publisher making
a change at exactly at the minimum addWaitTime or addWallClockTime
values would lead to a failure.  So the primary question today is "how
do we want to deal with this issue of real-world speed-of-light and
other issues?".  To complicate this a bit further, packets are never
guaranteed to be delivered and network losses can entirely prevent a
5011 Resolver from succeeding at all for a given operation.

Option 1.  Include a safetyMargin of some value.

1A) safetyMargin = MAX(2*TTL, 1.5Hr)   -- current draft

1B) safetyMargin = something based on the retryTime,
(an example solution was suggested by MSJ)

1C) Your value here

Option 2.  Don't include a safetyMargin

2A) Just ignore the issues entirely

2B) Explain that this document does not cover operational
complexities like retries (already in the -07 version),
network delays and other operational issues.


After thinking about this for far far too long, I've now switched my own
opinion to that of 2C for the principal reason that this is the
line-in-the-sand document, and to be honest people should be using
values much larger than this, per MSJ's guidance on how 5011 should be
used.  Thus, it makes more sense to define this as the "MUST NOT go
below this line" without trying to be precise about a value that can never be
perfectly accurate, by definition.

But, forget my opinion.  What's yours?  If nothing else, pick one of the
[12][ABC] options above please, even without any text defining why you
think so (until someone pokes you).



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

Re: [DNSOP] [Technical Errata Reported] RFC6781 (5174)

[Matthijs Mekking]

Hi,

This errata appears to be valid. In addition, the following text must 
also be corrected, from:


   The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_14.

to:

   The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_15.

Best regards,
  Matthijs

On 29-10-17 13:12, RFC Errata System wrote:

The following errata report has been submitted for RFC6781,
"DNSSEC Operational Practices, Version 2".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5174

--
Type: Technical
Reported by: Andreas Cudok 

Section: Appendix B.

Original Text
-
is reduced to the following representation:

 SOA_2005092303
 RRSIG_Z_14(SOA_2005092303)
 DNSKEY_K_14
 DNSKEY_Z_15
 RRSIG_K_14(DNSKEY)
 RRSIG_Z_15(DNSKEY)

Corrected Text
--
is reduced to the following representation:

 SOA_2005092303
 RRSIG_Z_14(SOA_2005092303)
 DNSKEY_Z_14
 DNSKEY_K_15
 RRSIG_Z_14(DNSKEY)
 RRSIG_K_15(DNSKEY)

Notes
-


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.

--
RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
--
Title   : DNSSEC Operational Practices, Version 2
Publication Date: December 2012
Author(s)   : O. Kolkman, W. Mekking, R. Gieben
Category: INFORMATIONAL
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



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

Re: [DNSOP] requesting WGLC for 5011-security-considerations

[Matthijs Mekking]

Wes,

On 06-09-17 18:05, Wes Hardaker wrote:
> Matthijs Mekking <matth...@pletterpet.nl> writes:
> 
> Thanks for all your points, and I've gone through and handled them all
> in the text (including discussing that we update 7583 per your request).
> 
>> 2. waitTime only adds one queryInterval, while Itrp adds two. I believe
>> to be safe on the publishing side, two queryIntervals is needed. RFC
>> 7583 explains:
>>
>>A validator will treat it as a trust anchor the next
>>time it retrieves the RRset, a process that can take up to another
>>queryInterval (the third term).
> 
> This is the one that had me think with a whiteboard for a while.  If I
> can sum it up differently, the problem is that 30 days may not be a
> factor of the queryInterval.  Thus:

But it is:

queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
   1/2*RRSigExpirationInterval))

Since the 5011-enabled resolver should see at least two queries with the
new trust anchor, the 15 days (30/2) is in the above equation defined in
RFC 5011.


> N * queryInterval >= >
> Where N is the number of queries to get somewhere over 30 days.

Sure, but N does not need to be higher than two, and in that case:

2 * queryInterval = MAX(2 hr, MIN (30 days, OrigTTL,
RRSigExpirationInterval))

In other words, never more than 30 days.


> So Irtp is waiting an extra queryInterval to account for this
> possibility.

Right, and since it is a possibility, it should be taken into account.

An important observation is that once the add hold-down timer expires,
the new key will be added as a trust anchor *only* the next time the
validated RRset with the new key is seen at the resolver.

This is the reason why the second queryInterval must be part of the
equation.


> Mathematically, I think the actually time needed to wait is 30 %
> queryInterval, which may actually be 0 in some cases and just shy of
> queryInterval in others.  Sound about right?

I am sorry, I don't understand this logic, can you elaborate?

The way I see it, queryInterval is always at minimal 1 hr and at most 15
days (not taking into account retryTime).


Best regards,
  Matthijs



>> 4. Both definitions (Itrp and waitTime) don't really take into
>> consideration the retryTime defined in RFC 5011. Perhaps that can be
>> used for defining the extra safety margin.
> 
> I'll have to add some text about that.  I don't think we can solve the
> case for broken networks, though.  But it's an important point to bring up.
> 

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

Re: [DNSOP] requesting WGLC for 5011-security-considerations

[Matthijs Mekking]

Wes,

It's been a while since I have had a look at this draft, my apologies.

I don't think it is ready for WGLC because I am not convinced the math
is correct. Section 6 defines the waitTime:

 waitTime = addHoldDownTime
+ (DNSKEY RRSIG Signature Validity)
+ MAX(MIN((DNSKEY RRSIG Signature Validity) / 2,
  MAX(original TTL of K_old DNSKEY RRSet) / 2,
  15 days),
  1 hour)
+ 2 * MAX(TTL of all records)

Which is the same as:

 waitTime = addHoldDownTime
+ (DNSKEY RRSIG Signature Validity)
+ queryInterval
+ 2 * MAX(TTL of all records)

but reads better.

This should be the same as Itrp as defined in RFC 7583:

  Itrp >= queryInterval + AddHoldDownTime + queryInterval

Basically these two differ at the following points:

1. Itrp does not include (DNSKEY RRSIG Signature Validity). It does
mention that the validator should not see a validly signed DNSKEY RRset
without the new key in that period. So adding (DNSKEY RRSIG Signature
Validity) is a good update.

2. waitTime only adds one queryInterval, while Itrp adds two. I believe
to be safe on the publishing side, two queryIntervals is needed. RFC
7583 explains:

   A validator will treat it as a trust anchor the next
   time it retrieves the RRset, a process that can take up to another
   queryInterval (the third term).

3. waitTime adds two MAX(TTL of all records) (margin). The draft says
that it probably not needed, and I agree, and that explains why it is
missing from the Itrp definition.

4. Both definitions (Itrp and waitTime) don't really take into
consideration the retryTime defined in RFC 5011. Perhaps that can be
used for defining the extra safety margin.

5. Itrp actually is defined with a modifiedQueryInterval which excludes
the RRSIG expiration interval. Now this is recognized to be the time
between inception and expiration of the RRSIG, I actually think it does
not need to be removed from the equation. So Itrp could have worked with
just queryInterval.

Given these points I think the correct definition of waitTime is:

 margin = 2 * MAX(TTL)

 waitTime = addHoldDownTime
+ signatureValidity(DNSKEY)
+ 2 * queryInterval
+ margin

I think slop needs to be separated and it should be documented that this
is a suggested value for the slop.

Furthermore, this document should also give guidance on the wait time
before a revoked DNSKEY can be removed from the zone:

 waitRemoveTime = signatureValidity(DNSKEY)
+ queryInterval
+ margin

This document should probably update RFC 7583 because it is giving a
better definition of Itrp and Irev.

For readability of the document I would like to suggest to move the
Attack example and breakdown to the Appendix.


Kind regards,
  Matthijs


On 05-07-17 19:11, Wes Hardaker wrote:
> 
> Folks,
> 
> We believe that the latest draft-rfc5011-security-considerations
> document is ready for WGLC, and would like the chairs to start that
> process unless anyone thinks it's not ready to go forward.  In
> particular, we believe all outstanding issues with it have been
> resolved.
> 
> Objections?
> 

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

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt

[Matthijs Mekking]

On 04-07-17 10:35, Mukund Sivaraman wrote:

BIND's resolver ECS does not cache SOA against an address prefix, but on
the authoritative side, note that there is no master file or zone
representation for zones with ECS. It is quite possible that if the auth
side is using different zone sources for different address prefixes,
they may well have different SOA serials. The problem is that none of
these is defined.


Which makes it hard to rely on it.

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

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt

[Matthijs Mekking]

Hi,

I already said this in private, but will also mention it here: I like
this idea.

Some initial comments:


1. Why actually define a new option for this. Since the option only uses
one bit to request/acknowledge opportunistic refresh, can't we use one
bit from the Z field from the OPT Record TTL Field?


2. The draft says:

  If Client Subnet [RFC7871] is enabled, resource records in the
  cache may be associated with a subnet.  In these cases, the
  resolver MUST ensure that the zone serial number associated with
  such records is obtained from an SOA record associated with the
  identical subnet.

But a SOA record is not associated with a subnet, and most likely will
return with a SCOPE of 0 since the option is not actually used to
generate the response. Typically with Client Subnet only address records
(A, ) will result in a tailored response. Also, an authoritative
name server may generate a different response for QTYPE= while the
SOA record has not changed.

It would be tricky to make opportunistic refresh work with Client
Subnet. It would definitely require more thought, but I would also be
fine with just specifying it does not work with ECS.


3. Security Considerations

I think this could use some words on the risk that an adversary tries to
make a record stick in the cache for longer than it is allowed, by
spoofing a response with an additional SOA record (this can be stopped
with DNSSEC obviously).


Best regards,
  Matthijs




On 03-07-17 13:36, Stephen Morris wrote:
> Hi
> 
> We have submitted a new draft which attempts to formalize an idea that
> has been kicking around for a couple of years, namely to use serial
> number information from DNS responses to determine whether stale records
> in a cache can be refreshed without the need for an upstream query.
> 
> Please send comments and feedback to the list.
> 
> Stephen
> 
> 
> 
>  Forwarded Message 
> Subject: New Version Notification for
> draft-muks-dnsop-dns-opportunistic-refresh-00.txt
> Date: Fri, 30 Jun 2017 13:41:45 -0700
> From: internet-dra...@ietf.org
> To: Mukund Sivaraman , Shane Kerr
> , Stephen Morris 
> 
> 
> A new version of I-D, draft-muks-dnsop-dns-opportunistic-refresh-00.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
> 
> Name: draft-muks-dnsop-dns-opportunistic-refresh
> Revision: 00
> Title:DNS Opportunistic Refresh for Resolvers
> Document date:2017-06-29
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-opportunistic-refresh-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-opportunistic-refresh/
> Htmlized:
> https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-opportunistic-refresh-00
> 
> 
> Abstract:
>This document describes a mechanism whereby a DNS resolver can
>opportunistically refresh the TTLs of cached records of a zone using
>serial number information carried in responses from the zone's
>nameservers.  As well as improving resolver response time by reducing
>the need to make upstream queries, the mechanism can also reduce the
>workload of authoritative servers.
> 
> 
> 
> 
> 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
> 

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

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

[Matthijs Mekking]

On 27-06-17 14:28, Dick Franks wrote:
> 
> On 26 June 2017 at 15:30, Matthijs Mekking <matth...@pletterpet.nl
> <mailto:matth...@pletterpet.nl>> wrote:
> 
> 
> 
> On 26-06-17 13:29, Dick Franks wrote:
> 
> You misunderstood: Variable length in octets, but not variable in
> number of RDATA elements
> 
> 
> I did.
> 
> Am I correct in thinking that you want some acknowledgement that 4
> fields exist, but do not really care what the final item is?

RFC 7344 specifies that the CDS RDATA format is the same as DS RDATA
format. RFC 4034 speficies the DS RDATA format contains 4 fields. So by
definition the CDS RDATA contains 4 fields. Same logic applies for
DNSKEY/CDNSKEY.

I suggested indeed one time that we should ignore the Digest (or Public
Key in case of CDNSKEY) if Algorithm is 0, but that is unrelated to this
issue. Since "0" is not valid base64, I would like to see this erratum
accepted to fix the notation in RFC 8078.

Best regards,
  Matthijs


> So an implementer has little choice but to make CDS/CDNSKEY work
> in accordance with the standard as written until IESG approves
> something else.
> 
> 
> Sure, but that is why we are discussing it, not?
> 
> 
> That is what we should be discussing, but this erratum seems to be
> steering us along a road full of potholes that I certainly do not want
> to fall into. IMHO this is based on a misunderstanding of your "mandated
> notation" argument.
>  
>  
> 
> And when that something else arrives, users will be mightily
> upset if RFC8078 CDS/CDNSKEY suddenly stops working, so the code
> will need to cope with both versions.  The only realistic way to
> achieve that is to determine the entire content of the DELETE
> CDS/CDNSKEY from the zero algorithm field. Beyond that, the
> content of the "mandated notation" is irrelevant because it can
> be left unparsed.
> 
> 
> My first suggestion for the draft was indeed: In case the DNSSEC
> algorithm is 0, the Digest/Public Key MUST be ignored.
> 
> 
> I would go further, and say that all fields (except algorithm) MUST be
> ignored
> 
>  
> 
> But there were concerns that if someone mistyped the algorithm field
> the DS accidentally gets removed. So now the RFC says that the
> contents of the CDS or CDNSKEY RRset MUST contain one RR and the "0
> [0,3] 0 0" notation is mandated.
> 
> 
> The one RR requirement is not in dispute.
> 
> Let us make a start with the following 3 use cases, to see if we can
> come to some common understanding of what we are trying to achieve.
> 
> (1)  CDS arrives on the wire
> 
> cds.example. IN CDS  \# 5 1234 00 56 78  ; silly numbers in most fields
> 
> RDATA as received:
> 
>  'algorithm' => 0,
>  'digestbin' => 'x',
>  'digtype' => 86,
>  'keytag' => 4660,
> 
> Algorithm = 0, so presentation format uses "RFC8078 mandated notation":
> 
> cds.example.INCDS0 0 0 0

> (2)  DELETE CDS read from zone file, transmitted to parent
> 
> cds.example.INCDS0 0 0 0
> 
> Algorithm = 0, so this is a DELETE CDS.
> 
> Check that RDATA string matches "mandated notation".
> 
> Coerce all RDATA numerical fields to zero, digest empty.
> 
> Transmitted CDS RR:
> 
> cds.example. IN CDS  \# 4  00 00
> 
> 
> (3)  Normal CDS read from zone file, but with accidental 0 in algorithm
> field
> 
> cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118
> 
> Algorithm = 0, so this is apparently a DELETE CDS.
> 
> Exception raised - RDATA does not match "mandated notation"
> 
> DS saved from accidental deletion:-)
> 
> 
> Obviously, similar logic applies to CDNSKEY.
> 
> --Dick

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

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

[Matthijs Mekking]

On 26-06-17 13:29, Dick Franks wrote:


On 26 June 2017 at 09:39, Matthijs Mekking <matth...@pletterpet.nl 
<mailto:matth...@pletterpet.nl>> wrote:


I raised the specific issue because the to be RFC 8078 was going to
change the CDS and CDNSKEY RDATA format from a fixed length RDATA to
a variable length: In case of the DELETE operation, the Digest in
presentation format was omitted.


CDS and CDNSKEY are both variable length. There is no length component 
in the RDATA itself. The length of the digest (or key) is calculated 
(RDLENGTH - 4) so whether there is one byte or none at all makes not a 
scrap of difference. So that explanation can be dismissed immediately.


You misunderstood: Variable length in octets, but not variable in number 
of RDATA elements.



While I agree with Paul in that thread that we should use all zeros
for the DELETE operation, I believe it was an oversight that the
proper encodings (hexadecimal, base64) should be used.


Not just an oversight. Now it is an oversight baked into an IESG 
approved standards track document.


So an implementer has little choice but to make CDS/CDNSKEY work in 
accordance with the standard as written until IESG approves something else.


Sure, but that is why we are discussing it, not?

And when that something else arrives, users will be mightily upset if 
RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to 
cope with both versions.  The only realistic way to achieve that is to 
determine the entire content of the DELETE CDS/CDNSKEY from the zero 
algorithm field. Beyond that, the content of the "mandated notation" is 
irrelevant because it can be left unparsed.


My first suggestion for the draft was indeed: In case the DNSSEC 
algorithm is 0, the Digest/Public Key MUST be ignored.


But there were concerns that if someone mistyped the algorithm field the 
DS accidentally gets removed. So now the RFC says that the contents of 
the CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" 
notation is mandated.


Best regards,
  Matthijs

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

Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

[Matthijs Mekking]

Hi,

On 24-06-17 17:45, Ondřej Caletka wrote:

Hello,

Dne 24.6.2017 v 15:25 Dick Franks napsal(a):

I beg to disagree.

In each case,

   CDS 0 0 0 0

   CDNSKEY 0 3 0 0

the final "0" is a conventional token representing a zero-length key
field. In neither case is it an attempt to specify a single octet key value.


I believe this has been discussed between 04 and 06 versions of the
draft in this thread:

https://mailarchive.ietf.org/arch/msg/dnsop/PsRIQOtd1bxFSEEm9lfv0WaHKeE >
The result that made it to the RFC is that there should be indeed one
byte with value of 00 in the Digest/Public key field instead of no data
at all.


To be precise: We actually agreed that there should be *one field with 
the value of 0* instead of no data at all.



This avoids the need of defining new format and updating all the
deployed software. It's not only about parsers of the wire format but
also about zone file parsers, that would need an update as the single
zero is not conformant with currently defined presentation format of
CDS/CDNSKEY RRs.


I raised the specific issue because the to be RFC 8078 was going to 
change the CDS and CDNSKEY RDATA format from a fixed length RDATA to a 
variable length: In case of the DELETE operation, the Digest in 
presentation format was omitted.


While I agree with Paul in that thread that we should use all zeros for 
the DELETE operation, I believe it was an oversight that the proper 
encodings (hexadecimal, base64) should be used.


So to me this errata is valid.

Best regards,
  Matthijs



I believe changing RRdata format just for this one purpose would add an
unnecessary complexity.

--
Best regards,
Ondřej Caletka



___
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

[Matthijs Mekking]

Thanks, and my apologies for failing to express myself clearer in an
earlier stage.

If next to the Key Tag, Algorithm, Digest Type, the Digest MUST also be
0, there is no longer a change in record *format* and this line
can/should be removed from the draft:

  This is a change in format from strict interpretation of [RFC7344]
  and may cause problems with some deployed software.

Best regards,
  Matthijs


On 11-01-17 03:47, tjw ietf wrote:
> Thanks Paul, and double thanks to Matthijs for his diligence in wisely
> forcing this.
> 
> The new version is minor, but significant.  I don't feel that it needs a
> new WGLC, but I want to put the diff between the two versions here so
> folks may take a second look. 
> 
> 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06.txt=draft-ietf-dnsop-maintain-ds-04.txt
> 
> 
> I'm going back over all the emails I have during the IETF LC process,
> just to make sure everything has been addressed. 
> 
> However, I think it's ready to move forward 
> 
> thanks
> tim
> 
> 
> 
> On Tue, Jan 10, 2017 at 7:02 PM, Paul Wouters  > wrote:
> 
> On Tue, 10 Jan 2017, Paul Wouters wrote:
> 
> Ohh, I think Matthijs actually found a bug:
> 
> 
> Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs
> for being so persistent in bringing this up. My apologies that
> I did not understand your concern before.
> 
> Chairs, it is up to you to decide on redoing a LC on this or not.
> 
> The diff between 04 and 06 that contains all changes since IETF LC:
> 
> 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-06.txt=draft-ietf-dnsop-maintain-ds-04.txt
> 
> 
> 
> 
> 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] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt

[Matthijs Mekking]

On 10-01-17 17:50, Paul Wouters wrote:
> On Tue, 10 Jan 2017, Matthijs Mekking wrote:
> 
>> I see that IESG has approved this document, but I am still wondering
>> this:
>>
>> On 01-12-16 13:20, Matthijs Mekking wrote:
>>>  Hi,
>>>
>>>  I read this again. I still wonder if in the case of DNSSEC Delete
>>>  Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is
>>>  0, the Digest/Public Key MUST be ignored.
>>>
>>>  This way, you don't have to change the CDS/CDNSKEY format defined in
>>> RFC
>>>  7344, most likely causing less problems with deployed software.
> 
> 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.

Matthijs


> 
> 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] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt

[Matthijs Mekking]

I see that IESG has approved this document, but I am still wondering this:

On 01-12-16 13:20, Matthijs Mekking wrote:

Hi,

I read this again. I still wonder if in the case of DNSSEC Delete
Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is
0, the Digest/Public Key MUST be ignored.

This way, you don't have to change the CDS/CDNSKEY format defined in RFC
7344, most likely causing less problems with deployed software.


Best regards,
  Matthijs

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