Re: [DNSOP] NSA says don't use public DNS or DoH servers

[Tom Pusateri]

> On Jan 21, 2021, at 8:59 PM, Paul Vixie  wrote:
> 
> On Thu, Jan 21, 2021 at 03:36:41PM -0800, Wes Hardaker wrote:
>> "John Levine"  writes:
>> 
>>> They think DoH is swell, but not when it bypasses security controls
>>> and leaks info to random outside people
>> 
>> At least 15% of network operators seem to agree.
>> 
>> https://www.isi.edu/~hardaker/news/20191120-canary-domain-measuring.html
> 
> i think the makers of canary-respecting DNS stub resolvers are still
> figuring things out, and that if canary domains become prevalent,
> especially among surveillance capitalist ISPs or surveillance
> authoritarian states, the days of canary domains will change or end.
> 
> for my own networks, i won't install a canary domain, because that's
> a late-imposed change, unreliable, and a negative externality. any
> stub resolver who uses any DNS service other than the one i hand out
> in my DHCP assignments will be removed from the network.
> 
> (new behaviour should require new signalling. let networks who want to
> permit DNS bypass either by "use 8.8.8.8" or "use DoH" or otherwise,
> signal this by adding a new canary domain, or a new DHCP option.
> absent new signalling, behaviour should not change.)
> 
> -- 
> Paul Vixie

Would it be ok to allow DNSSEC signed responses from any server? If they’re 
signed and verified, does it matter how you got them?

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

Re: [DNSOP] Authoritative servers announcing capabilities

[Tom Pusateri]

> On Sep 19, 2020, at 5:51 AM, Ray Bellis  wrote:
> 
> 
> 
>> On 14/09/2020 15:32, libor.peltan wrote:
>> Let me leave some personal opnion/comments on this AUTHINFO idea, although I 
>> don't know the background here.
>> There are multiple kinds of "capabilities" of an authoritative server.
>> Some of them are properties of the zone, some are properties of the DNS 
>> server implementation, some are properties of the operational policy. For 
>> examples: DNS algorithm, EDNS version, network MTU, respectively.
>> While it seems reasonable to disclose some properties of the zone by an 
>> extra zone RR (although it would probably require extra query!), the 
>> properties of DNS server will often vary since implementation diversity is a 
>> general recommendation.
> 
> The initial drafts of what became DNS Stateful Operations (RFC 8490) included 
> something akin to a server capabilities exchange / negotiation.
> 
> Personally I think EDNS is the wrong place for negotiating server properties 
> because unless you're using TCP there's no guarantee that the server whose 
> properties you've cached is going to be the one that answers the next query 
> you send to that address.
> 
> The flip side is that RFC 8490 support is currently rare, and is perhaps one 
> of those server capabilities one wants to find out about :p
> 
> Ray

This has been discussed on this list before but the reason we removed 
capabilities negotiation was that there’s no real benefit, only perceived. The 
capabilities flags add potential delay and another vector for additional bugs 
but a client still has to try the feature to see if it works as advertised.

The client should just try the feature directly. This potentially reduces delay 
and code.

Tom

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

[DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-04.txt

[Tom Pusateri]

Tim and I have updated the TIMEOUT RR draft to reflect the feedback we’ve 
received on this list and added some more description and usage patterns, 
including interaction with the EDNS(0) Update Lease option, and a discussion of 
absolute vs. relative timeout values.

Thanks,
Tom & Tim


Begin forwarded message:

> From: internet-dra...@ietf.org
> Date: November 4, 2019 at 11:27:25 AM EST
> To: Tim Wattenberg , Tom Pusateri 
> Subject: New Version Notification for 
> draft-pusateri-dnsop-update-timeout-04.txt
> 
> 
> A new version of I-D, draft-pusateri-dnsop-update-timeout-04.txt
> has been successfully submitted by Tim Wattenberg and posted to the
> IETF repository.
> 
> Name:draft-pusateri-dnsop-update-timeout
> Revision:04
> Title:DNS TIMEOUT Resource Record
> Document date:2019-11-04
> Group:Individual Submission
> Pages:17
> URL:
> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:   
> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-04
> 
> Abstract:
>   This specification defines a new DNS TIMEOUT resource record (RR)
>   that associates a lifetime with one or more zone resource records.
>   It is intended to be used to transfer resource record lifetime state
>   between a zone's primary and secondary servers and to store lifetime
>   state during server software restarts.
> 
> 
> 
> 
> 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] TIMEOUT resource record RDATA format revisited

[Tom Pusateri]

DNSOP,
It’s exciting to see some implementation experience in bind 9 by Mark 
Andrews for TIMEOUT records and during this process several issues have come up 
with the current use of RDATA as the method to match represented records. 
Thanks Mark for all the work and feedback so far!

1. Representing multiple records RDATA within another records RDATA is 
difficult in the presentation format. This happens when written to a zone file 
and read back in. Multiple TXT records RDATA following each other has been 
tricky.

2. This is compounded by lengthy and complicated security records for uses like 
ACME and domain keys which are both time limited and potential uses of TIMEOUT 
records.

3. Creating TIMEOUT records and sending them with the nsupdate utility is also 
challenging with the RDATA method.

4. There is the (theoretical) possibility that a record already has max length. 
In this case it couldn’t be represented in a TIMEOUT record.

In the initial version, we used a HASH in the TIMEOUT RDATA to represent the 
records and it was suggested to fallback to the RDATA because the HASH was a 
“premature optimization”. This was good advice and we followed it. But now with 
the experience we feel the HASH optimization is no longer premature but 
appropriate and would like to change the TIMEOUT RDATA format back to a HASH. 
The HASH also has the advantage of being a fixed length per record which is 
nicer for parsing and presenting in zone files.

This time we are suggesting using the first 128 bits of SHA256 (instead of 
SHAKE128) due to the overwhelming request for this change earlier. Having 
talked to some security experts, we now feel comfortable with using only a 
portion of the calculated HASH without fear of collisions. This makes it the 
same length as an IPv6 address RDATA.

It was suggested that we include both methods (RDATA and HASH) but we would 
prefer to only have a single method in order that we don’t run into problems 
with capability differences between primary and secondary servers.

So hopefully everyone will approve of this change. If you have feedback one way 
or the other, we’d love to hear it.

Thanks,
Tom & Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

[Tom Pusateri]

> On Mar 8, 2019, at 3:00 PM, 神明達哉  wrote:
> 
> At Mon, 4 Mar 2019 19:45:02 -0500,
> Tom Pusateri mailto:pusat...@bangj.com>> wrote:
> 
> > Thanks to the great feedback, we were able to update the document to
> > better match the preferences of the working group and address the
> > outstanding concerns.
> 
> > > A new version of I-D, draft-pusateri-dnsop-update-timeout-02.txt
> > > has been successfully submitted by Tom Pusateri and posted to the
> > > IETF repository.
> 
> I've read draft-pusateri-dnsop-update-timeout-02.  Personally, I'm not
> yet convinced that we need to provide this functionality in an
> "in-band" way (i.e., as a DNS resource record).  But I wouldn't
> be strongly opposed to it if the WG is willing to adopt it.  For now
> I'm just providing some technical comments on the draft content.

That feedback by itself is valuable. We need to make a better case for it. Most 
of the use cases relate to service discovery.

> - general: it's not clear to me when/how a TIMEOUT RR is added to a
>   zone?  Is it assumed that an update client includes it in its update
>   request?  Or is the primary server supposed to internally add/update
>   TIMEOUT(s) on handling update requests?  Or something else?  I think
>   the draft should explain it more clearly.

We list those ways but don’t specifically limit it.

Initially, if authoritative servers don’t yet manage TIMEOUT records, external 
applications could add and remove TIMEOUT records on behalf of the primary 
server.

Eventually, primary servers may want to manage them entirely internal and 
reject all outside interference. In this case, the lease update EDNS(0) option 
can be used to communicate the requested timeout value.

TIMEOUT records may also be included in the UPDATE message along with the 
records added as a hint to the primary server.

> 
> - Section 4
> 
>If the expiry time is the same,
>multiple records can be combined into a single TIMEOUT record with
>the same owner name, class, and record type but this is NOT REQUIRED.
> 
>   'NOT REQUIRED' is not an RFC2119 keyword.  If this is not intended
>   to be a normative keyword, it's better to be lower-cased to avoid
>   confusion; if it's intended to be normative, a valid RFC2119 keyword
>   should be used.

Will fix.

> 
> - Section 4.1
> 
>A 16-bit field containing the resource record type to which the
>TIMEOUT record applies.  Multiple TIMEOUT records for the same owner
>name, class, and represented type can exist.
> 
>   Is there any RR type that must not be specified here?  For example,
>   can TIMEOUT itself be specified?

We want to treat them like any other resource record so there are no special 
rules. Do you see any reason to limit it?

> 
> - Section 4.2
> 
>If an additional TIMEOUT record exists with the same
>owner name, class, and record type, it MUST be ignored and SHOULD be
>removed.
> 
>   It's not clear to me exactly what "it MUST be ignored and SHOULD be
>   removed" means...perhaps it's also related to how TIMEOUT is added
>   to a zone.

Will fix.

> 
> - Section 4.3.2
> 
>The record MUST be in canonical DNSSEC
>form as described in Section 6 of [RFC4034].
> 
>   You might also want to state that the RDATA in TIMEOUT and the RDATA
>   of the actual RR that it covers must be compared in the canonical
>   form (i.e., some types of RRs have to be compared in the
>   case-insensitive manner).

Good point.

> 
> - Section 6
> 
>A TIMEOUT resource record MUST be removed when the last resource
>record it covers has been removed.
> 
>   This statement looks ambiguous about *who* removes the TIMEOUT.
>   According to the paragraph that follows I guess it's the primary
>   server implementation (rather than, e.g., a human administrator of
>   the server).  Perhaps it's better to use the active voice here, too:
> 
> A primary server MUST remove a TIMEOUT resource record...
> 
> - Section 6/general: what should happen if an administrator manually
>   edit the zone file (and reload it to the primary server)?  Is it the
>   administrator's responsibility to adjust TIMEOUT accordingly, or is
>   the primary server implementation supposed to do it automatically?

Ok. I think we can make this more clear while still leaving a little wiggle 
room.

> 
> - Section 6
> 
>As a reminder from Section 3.3.13 of [RFC1035], the MINIMUM field of
>the SOA for the zone is used as a lower bound of the TTL for all
>records in the zone.
> 
>   This is deprecated by RFC2308.

Missed that. Thanks for pointing it out.

> 
> --
> JINMEI, Tatuya

Great feedback!

Thanks,
Tom


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

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

[Tom Pusateri]

> On Mar 5, 2019, at 8:20 AM, Tony Finch  wrote:
> 
> Tom Pusateri  wrote:
>> 
>> Sorry if that freaked you out.
> 
> I wasn't freaked out, I just thought the response was directed to the
> wrong place. I didn't bring up the issue for a two-way discussion, I
> wanted to see what other wg participants thought.
> 
>> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout
>> 
>> and anyone is welcome to open issues if they like so I don’t think we
>> need to replicate this info to the mailing list each time.
> 
> The wg mailing list is where group decisions are supposed to be taken.
> I don't particularly want to have to poll another (counting the dnsop
> drafts) 35 places to find out if maybe some discussion has happened.
> 
> Tony.

I agree with you on this. The issues are  for the authors and including the 
participants was a courtesy for them to be informed when the issue was resolved.

However, since you seem to object, I will discontinue this practice. 

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

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

[Tom Pusateri]

> On Mar 5, 2019, at 7:18 AM, Tony Finch  wrote:
> 
> Tom Pusateri  wrote:
>> 
>> Modify presentation format of date/time to match RRSIG (Mark Andrews)
> 
> I got some mail from github about this issue which was weirdly sent to
> me personally rather than to the WG - see
> 
> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/24
> 
> Tony.

Sorry if that freaked you out. I opened issues on github and included comments 
made on the mailing list to make sure we captured them correctly when the issue 
was resolved. I referenced participants github user names where applicable.

In your case this included:

https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/27
https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/24

I’ve already mentioned on the WG mailing list that the document is being edited 
here:

https://github.com/pusateri/draft-pusateri-dnsop-update-timeout

and anyone is welcome to open issues if they like so I don’t think we need to 
replicate this info to the mailing list each time.

Thanks,
Tom

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

[DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

[Tom Pusateri]

DNSOP,

Thanks to the great feedback, we were able to update the document to better 
match the preferences of the working group and address the outstanding concerns.

To summarize the changes:

Add missing reference (Stuart Cheshire)
Modify presentation format of date/time to match RRSIG (Mark Andrews)
Remove HASH as a premature optimization and replace with actual RDATA (Ted 
Lemon)
Add more motivation for the need of the record (Joe Abley, Paul Wouters).
Allow multiple TIMEOUT records with the same owner name/class and simplify 
TIMEOUT record format to not include multiple expiry times (partly Tony Finch)

Note: going through the list, I realized that I missed the comment that we need 
to explain why individual records need cleaned up and not just the whole RRSet. 
We’ll open an issue for this and handle it in the next version.

Thanks,
Tom


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-pusateri-dnsop-update-timeout-02.txt
> Date: March 4, 2019 at 7:26:58 PM EST
> To: "Tim Wattenberg" , "Tom Pusateri" 
> 
> 
> 
> A new version of I-D, draft-pusateri-dnsop-update-timeout-02.txt
> has been successfully submitted by Tom Pusateri and posted to the
> IETF repository.
> 
> Name: draft-pusateri-dnsop-update-timeout
> Revision: 02
> Title:DNS TIMEOUT Resource Record
> Document date:2019-03-04
> Group:Individual Submission
> Pages:13
> URL:
> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:   
> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-02
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-02
> 
> Abstract:
>   This specification defines a new DNS TIMEOUT resource record (RR)
>   that associates a lifetime with one or more zone resource records
>   with the same owner name, type, and class.  It is intended to be used
>   to transfer resource record lifetime state between a zone's primary
>   and secondary servers and to store lifetime state during server
>   software restarts.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Tom Pusateri]

> On Feb 21, 2019, at 10:19 PM, Tom Pusateri  wrote:
> 
> 
> 
>> On Feb 21, 2019, at 1:29 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>> On Feb 21, 2019, at 2:24 PM, Mark Andrews > <mailto:ma...@isc.org>> wrote:
>>> Implementation details are beyond the scope of RFCs.
>> 
>> Indeed they are.  My point is that if you want to be careful of memory usage 
>> or disk usage, you can be—there is no need to use a hash.   In essence, 
>> requiring us to use a hash is specifying an implementation detail that 
>> needn’t be specified: you can in fact implement this using a hash, although 
>> I wouldn’t.   It would be nice if I were not required to implement it that 
>> way, since I think that’s not actually going to work reliably.
>> 
>>> Also you mentioned caches which basically will never see these records 
>>> unless they are queried for.
>> 
>> 
>> I mentioned caches because they are by far the biggest consumers of 
>> resources—authoritative name servers have much smaller memory footprints.   
>> I assume the reason you think using hashes is a good idea and not a 
>> premature optimization is because you’ve done a lot of work with caching 
>> name servers, and are seeing this discussion through that lens.   That’s the 
>> wrong lens to be seeing it through.   This is only relevant for 
>> authoritative name servers, and in that case, storing the whole 
>> RR-to-be-deleted is fine.
>> 
> 
> I’ve been mostly listening and learning from this discussion which has been 
> great. Thanks for all the input. Let me summarize what I’m hearing and we 
> will open issues to adjust the document.
> 
> 1. We need a motivational section to explain the purpose better
> 
> 2. The HASH was my idea to simplify the records by making them all the same. 
> It appears that simplicity in this form was not noticed or not appreciated. :)
> 
> 3. The HASH algorithm selection was intended to work long term. It was my 
> hope that there would only ever be one algorithm and there would never exist 
> the case when one implementation supported an algorithm that another 
> implementation did not. The HASH algorithm index was only intended to be used 
> if a vulnerability was found in the ONE selected algorithm and it needed 
> replaced. In this case, the old algorithm would be deprecated and everyone 
> would switch to a new single algorithm. I am strongly opposed to having more 
> than one HASH algorithm defined. Not being a security expert and not being 
> able to find any papers proving that I could take an existing algorithm like 
> SHA-256 that was 32 bytes and shorten it to 16 bytes using the first 16 bytes 
> or the last 16 bytes or 16 bytes in the middle, I opted to select an 
> algorithm that was already 16 bytes and proven to have terrific non-collision 
> properties. Since some of the RDATA can be very short (A records), there are 
> cases when there’s not a lot of data from which to base the hash value on. 
> This was another reason to start with a hash like SHAKE128. But from the 
> sounds of it, people prefer SHA-256 and so I will research this more to see 
> about its applicability in this case (if a hash is even needed anymore).
> 
> 4. We are open to using RDATA instead of a hash. Or we can define RDATA as an 
> algorithm index as Mark suggested and define a hash as another algorithm (now 
> or later if it ever becomes a problem). By adding the record type to the 
> TIMEOUT instance, we have eliminated most uses of the hash already and only 
> in rare cases will it be needed so including large RDATA in the TIMEOUT 
> record should be rare.
> 
> 5. Storing the TIMEOUT information as resource records seemed like a 
> convenient way to use an existing database to store timeout information 
> across restarts and to synchronize with secondaries. It can certainly be 
> stored in a proprietary database by each authoritative server vendor but 
> allowing them to interoperate seemed like a feature and when they each 
> already have a database that holds resource records, why create another 
> database type? But if the consensus is that the TIMEOUT info shouldn’t be 
> stored in the existing resource record database but instead authoritative 
> servers should create a new database for this info, then that is fine. This 
> document itself can TIMEOUT. :)
> 

Forgot these:

6. As far as the time format, we were simply following the recommendations of 
RFC 3339 for presentation. But if DNS has it’s own format preferences and the 
IESG is ok with this, so are we. Following RFC 3339 is a SHOULD, therefore, 
there must be exceptions allowed but I’m not aware of the rules here.

7. As far as the timestamp

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Tom Pusateri]

> On Feb 21, 2019, at 1:29 PM, Ted Lemon  wrote:
> 
> On Feb 21, 2019, at 2:24 PM, Mark Andrews  > wrote:
>> Implementation details are beyond the scope of RFCs.
> 
> Indeed they are.  My point is that if you want to be careful of memory usage 
> or disk usage, you can be—there is no need to use a hash.   In essence, 
> requiring us to use a hash is specifying an implementation detail that 
> needn’t be specified: you can in fact implement this using a hash, although I 
> wouldn’t.   It would be nice if I were not required to implement it that way, 
> since I think that’s not actually going to work reliably.
> 
>> Also you mentioned caches which basically will never see these records 
>> unless they are queried for.
> 
> 
> I mentioned caches because they are by far the biggest consumers of 
> resources—authoritative name servers have much smaller memory footprints.   I 
> assume the reason you think using hashes is a good idea and not a premature 
> optimization is because you’ve done a lot of work with caching name servers, 
> and are seeing this discussion through that lens.   That’s the wrong lens to 
> be seeing it through.   This is only relevant for authoritative name servers, 
> and in that case, storing the whole RR-to-be-deleted is fine.
> 

I’ve been mostly listening and learning from this discussion which has been 
great. Thanks for all the input. Let me summarize what I’m hearing and we will 
open issues to adjust the document.

1. We need a motivational section to explain the purpose better

2. The HASH was my idea to simplify the records by making them all the same. It 
appears that simplicity in this form was not noticed or not appreciated. :)

3. The HASH algorithm selection was intended to work long term. It was my hope 
that there would only ever be one algorithm and there would never exist the 
case when one implementation supported an algorithm that another implementation 
did not. The HASH algorithm index was only intended to be used if a 
vulnerability was found in the ONE selected algorithm and it needed replaced. 
In this case, the old algorithm would be deprecated and everyone would switch 
to a new single algorithm. I am strongly opposed to having more than one HASH 
algorithm defined. Not being a security expert and not being able to find any 
papers proving that I could take an existing algorithm like SHA-256 that was 32 
bytes and shorten it to 16 bytes using the first 16 bytes or the last 16 bytes 
or 16 bytes in the middle, I opted to select an algorithm that was already 16 
bytes and proven to have terrific non-collision properties. Since some of the 
RDATA can be very short (A records), there are cases when there’s not a lot of 
data from which to base the hash value on. This was another reason to start 
with a hash like SHAKE128. But from the sounds of it, people prefer SHA-256 and 
so I will research this more to see about its applicability in this case (if a 
hash is even needed anymore).

4. We are open to using RDATA instead of a hash. Or we can define RDATA as an 
algorithm index as Mark suggested and define a hash as another algorithm (now 
or later if it ever becomes a problem). By adding the record type to the 
TIMEOUT instance, we have eliminated most uses of the hash already and only in 
rare cases will it be needed so including large RDATA in the TIMEOUT record 
should be rare.

5. Storing the TIMEOUT information as resource records seemed like a convenient 
way to use an existing database to store timeout information across restarts 
and to synchronize with secondaries. It can certainly be stored in a 
proprietary database by each authoritative server vendor but allowing them to 
interoperate seemed like a feature and when they each already have a database 
that holds resource records, why create another database type? But if the 
consensus is that the TIMEOUT info shouldn’t be stored in the existing resource 
record database but instead authoritative servers should create a new database 
for this info, then that is fine. This document itself can TIMEOUT. :)

Thanks,
Tom





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

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Tom Pusateri]

Mark,

> Just closing the issue isn’t addressing it.

That’s not a fair point about closing issue #19.

Your main concern was that SHA-3 algorithms might not be easily available but, 
luckily, they shipped with TLS 1.3 in OpenSSL 1.1.1 and so I thought #19 was a 
solved issue.

Regardless, sooner or later, someone will be the first to use a SHA-3 algorithm 
that’s better than the SHA-2 algorithms DNS uses today. It’s only a matter of 
time. SHA-3 has been out since 2015. As soon as you support TLS 1.3, you’ll 
have all the SHA-3 algorithms with a simple API call and it should be available 
everywhere because TLS 1.3 will be needed everywhere.

I will reopen this issue for discussion but I don’t see yet how this is a 
problem.

Thanks,
Tom

> On Feb 18, 2019, at 7:27 PM, Mark Andrews  wrote:
> 
> I have yet to seen a justification for using SHAKE128 vs any of the existing
> hash algorithms used in DNS.  You really need to justify this choice on 
> security
> concerns.  DNS server implementers need to support multiple crypto backends 
> and
> adding yet another algorithm is not as easy as just calling OpenSSL.  It’s 
> writing /
> expanding a shim layer.  It’s checking for the existence on all the platforms
> the server is built on.  
> 
> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/19
> 
>> On 19 Feb 2019, at 10:34 am, Tom Pusateri  wrote:
>> 
>> DNSOP,
>> 
>> We have updated the TIMEOUT resource record draft based on the great 
>> feedback from Mark Andrews, Joe Abley, Ted Lemon, and Paul Vixie. I think we 
>> have addressed all of the comments except for the Date format concern from 
>> Mark. That is still an outstanding issue. Please comment on it if you have 
>> an opinion or feel free to open other issues against the document or send 
>> comments to the list.
>> 
>> The TIMEOUT RR is just like any other resource record now with no special 
>> handling.
>> 
>> Issues are on Github:
>> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues
>> 
>> Thanks,
>> Tom & Tim
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: internet-dra...@ietf.org
>>> Subject: New Version Notification for 
>>> draft-pusateri-dnsop-update-timeout-01.txt
>>> Date: February 18, 2019 at 6:26:35 PM EST
>>> To: "Tim Wattenberg" , "Tom Pusateri" 
>>> 
>>> 
>>> 
>>> A new version of I-D, draft-pusateri-dnsop-update-timeout-01.txt
>>> has been successfully submitted by Tom Pusateri and posted to the
>>> IETF repository.
>>> 
>>> Name:   draft-pusateri-dnsop-update-timeout
>>> Revision:   01
>>> Title:  DNS TIMEOUT Resource Record
>>> Document date:  2019-02-18
>>> Group:  Individual Submission
>>> Pages:  13
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-01.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
>>> Htmlized:   
>>> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-01
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
>>> Diff:   
>>> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-01
>>> 
>>> Abstract:
>>>  This specification defines a new DNS TIMEOUT resource record (RR)
>>>  that associates a lifetime with one or more zone resource records
>>>  with the same owner name, type, and class.  It is intended to be used
>>>  to transfer resource record lifetime state between a zone's primary
>>>  and secondary servers and to store lifetime state during server
>>>  software restarts.
>>> 
>>> 
>>> 
>>> 
>>> 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
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

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

[DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

[Tom Pusateri]

DNSOP,

We have updated the TIMEOUT resource record draft based on the great feedback 
from Mark Andrews, Joe Abley, Ted Lemon, and Paul Vixie. I think we have 
addressed all of the comments except for the Date format concern from Mark. 
That is still an outstanding issue. Please comment on it if you have an opinion 
or feel free to open other issues against the document or send comments to the 
list.

The TIMEOUT RR is just like any other resource record now with no special 
handling.

Issues are on Github:
https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues

Thanks,
Tom & Tim


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-pusateri-dnsop-update-timeout-01.txt
> Date: February 18, 2019 at 6:26:35 PM EST
> To: "Tim Wattenberg" , "Tom Pusateri" 
> 
> 
> 
> A new version of I-D, draft-pusateri-dnsop-update-timeout-01.txt
> has been successfully submitted by Tom Pusateri and posted to the
> IETF repository.
> 
> Name: draft-pusateri-dnsop-update-timeout
> Revision: 01
> Title:DNS TIMEOUT Resource Record
> Document date:2019-02-18
> Group:Individual Submission
> Pages:13
> URL:
> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:   
> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-01
> 
> Abstract:
>   This specification defines a new DNS TIMEOUT resource record (RR)
>   that associates a lifetime with one or more zone resource records
>   with the same owner name, type, and class.  It is intended to be used
>   to transfer resource record lifetime state between a zone's primary
>   and secondary servers and to store lifetime state during server
>   software restarts.
> 
> 
> 
> 
> 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] DNS JSON (RFC 8427) schema

[Tom Pusateri]

DNSOP/Paul:

I am working on an application that will have DNS filters or 
translators in the config file. My current design uses Paul Hoffman's RFC 8427 
JSON DNS format to allow the filters to make packet alterations. As an example, 
think about an older printer service with SRV/TXT records that do not support 
AirPrint. However, with a few tweaks, the TXT record could be changed to make 
it compatible with AirPrint devices. Therefore, I want to validate the output 
of the filter before accepting it since anyone could add these types of filters 
to the config file.

There is work in the IETF for JSON schemas 
(https://tools.ietf.org/html/draft-handrews-json-schema-validation-01) and 
(http://json-schema.org) and I have started creating a schema for the RFC 8427 
JSON DNS definitions.

It will be something similar to what is below (but more complete). Before I go 
to all the trouble of getting this exactly right, I wanted to make sure no one 
else had already done this. I will publish it when I finish for others to use.

If anyone has already generated a JSON schema for RFC 8427, please contact me.

If you are interested in this and want to help, please contact me.

Thanks,
Tom



  1 {
  2   "definitions": {},
  3   "$schema": "http://json-schema.org/draft-07/schema#";,
  4   "$id": "http://dnsdisco.com/rfc8427.json";,
  5   "type": "object",
  6   "title": “RFC 8427 Schema",
 11   "properties": {
 12 "queryMessage": {
 13   "$id": "#/properties/queryMessage",
 14   "type": "object",
 15   "title": "The Querymessage Schema",
 16   "required": [
 17 "ID",
 18 "QR",
 19 "Opcode",
 20 "AA",
 21 "TC",
 22 "RD",
 23 "RA",
 24 "AD",
 25 "CD",
 26 "RCODE",
 27 "QDCOUNT",
 28 "ANCOUNT",
 29 "NSCOUNT",
 30 "ARCOUNT",
 31 "QNAME",
 32 "QTYPE",
 33 "QCLASS"
 34   ],
 35   "properties": {
 36 "ID": {
 37   "$id": "#/properties/queryMessage/properties/ID",
 38   "type": "integer",
 39   "title": "The Id Schema",
 40   "default": 0,
 41   "examples": [
 42 32784
 43   ]
 44 },
 45 "QR": {
 46   "$id": "#/properties/queryMessage/properties/QR",
 47   "type": "integer",
 48   "title": "The Qr Schema",
 49   "default": 0,
 50   "examples": [
 51 0
 52   ]
 53 },
 54 "Opcode": {
 55   "$id": "#/properties/queryMessage/properties/Opcode",
 56   "type": "integer",
 57   "title": "The Opcode Schema",
 58   "default": 0,
 59   "examples": [
 60 0
 61   ]
 62 },
 63 "AA": {
 64   "$id": "#/properties/queryMessage/properties/AA",
 65   "type": "integer",
 66   "title": "The Aa Schema",
 67   "default": 0,
 68   "examples": [
 69 0
 70   ]
 71 },
 72 "TC": {
 73   "$id": "#/properties/queryMessage/properties/TC",
 74   "type": "integer",
 75   "title": "The Tc Schema",
 76   "default": 0,
 77   "examples": [
 78 0
 79   ]
 80 },
 81 "RD": {
 82   "$id": "#/properties/queryMessage/properties/RD",
 83   "type": "integer",
 84   "title": "The Rd Schema",
 85   "default": 0,
 86   "examples": [
 87 0
 88   ]
 89 },
 90 "RA": {
 91   "$id": "#/properties/queryMessage/properties/RA",
 92   "type": "integer",
 93   "title": "The Ra Schema",
 94   "default": 0,
 95   "examples": [
 96 0
 97   ]
 98 },
 99 "AD": {
100   "$id": "#/properties/queryMessage/properties/AD",
101   "type": "integer",
102   "title": "The Ad Schema",
103   "default": 0,
104   "examples": [
105 0
106   ]
107 },
108 "CD": {
109   "$id": "#/properties/queryMessage/properties/CD",
110   "type": "integer",
111   "title": "The Cd Schema",
112   "default": 0,
113   "examples": [
114 0
115   ]
116 },
117 "RCODE": {
118   "$id": "#/properties/queryMessage/properties/RCODE",
119   "type": "integer",
120   "title": "The Rcode Schema",
121   "default": 0,
122   "examples": [
123 0
124   ]
125 },
126 "QDCOUNT": {
127   "$id": "#/properties/queryMessage/properties/QDCOUNT",
128   "type": "integer",
129   "title": "The Qdcount Schema",
130   "default": 0,
131   "examples": [
132 1
133   ]
134 },
135 "ANCOUNT": {
136   "$id": "#/properties/queryMessage/properties/ANCOUNT",
1

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Sep 3, 2018, at 8:58 PM, Mark Andrews  wrote:
> 
> SHAKE128 does not meet these requirements.  In OPENSSL it is only
> available in pre-release code.  It will be years before OPENSSL-1.1.1
> is the OPENSSL release for most operating systems.
> 
> We (ISC) haven’t started working out what OPENSSL-1.1.1 breaks yet.
> OPENSSL-1.1.0 broke lots of existing code.  Lots of code required
> re-writing to work with OPENSSL-1.1.0 as it broke backwards compatibility
> with OPENSSL-1.0.x.

While I understand your point, OpenSSL 1.1.1 is the first release that will 
contain TLS 1.3. It is binary backward compatible with 1.1.0. Aside from our 
trivial use of SHAKE128, everyone is going to be upgrading to 1.1.1 as soon as 
possible to get TLS 1.3 support. See

https://wiki.openssl.org/index.php/TLS1.3

> 
> Please pick hash algorithms that are already USED by DNS.  The results
> can be truncated if you are worried about space.
> 
> And no it isn’t as easy as just calling OPENSSL.  PKCS#11 providers
> also need to support the hash algorithm.
> 

Ok, thanks for this extra info. I will look into it.

Tom

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

Not true. You have PTR records with the same service name from multiple clients 
each with different RDATA and unique timeouts as I demonstrated yesterday in 
the example.

Tom


> On Aug 27, 2018, at 3:27 PM, Ted Lemon  wrote:
> 
> For service instance names, there is only one service. So there shouldn’t be 
> a problem. 
> 
> On Mon, Aug 27, 2018 at 2:28 PM Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> Because even if you add TYPE, you have multiple PTR records (instance names) 
> with the same owner name, class, and type that can timeout differently.
> 
> Tom
> 
>> On Aug 26, 2018, at 11:20 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>> If we do that, why do we need a hash at all?
>> 
>> On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews > <mailto:ma...@isc.org>> wrote:
>> I would add a covered type field to TIMEOUT (c.f. RRSIG).  I also wouldn’t 
>> have more than
>> a single timeout per record.  I’m tempted to say a single hash as well.  If 
>> there is multiple
>> timeouts per record then the blocks need to be sorted in timeout order.
>> 
>> Covered is there to reduce the number of RR’s that need to be hashed to 
>> remove a record.
>> It will also reduce the size of IXFR’s as you don’t need to re-construct a 
>> new TIMEOUT
>> record that covers every timeout at a name on each change.
>> 
>> For all records at a name is often more expensive that for all records of 
>> type covered.
>> Name servers are optimised for looking up  tuples rather 
>> than 
>> tuples.
>> 
>> Sorting of timeout blocks is so that you can look at the first timeout when 
>> working out
>> which TIMEOUT needs to be processed first in a zone.
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia 
>> <https://maps.google.com/?q=1+Seymour+St.,+Dundas+Valley,+NSW+2117,+Australia&entry=gmail&source=g>
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org 
>> <mailto:ma...@isc.org>
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 27, 2018, at 2:25 PM, Tom Pusateri  wrote:
> 
> 
> Sorting the timeouts is a good idea.
> 

Well, maybe sorting timeouts is a good idea. Depending on how they are 
represented internally, it makes no difference. I would like to hear from 
implementors whether this even matters.

Thanks,
Tom


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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

Because even if you add TYPE, you have multiple PTR records (instance names) 
with the same owner name, class, and type that can timeout differently.

Tom

> On Aug 26, 2018, at 11:20 PM, Ted Lemon  wrote:
> 
> If we do that, why do we need a hash at all?
> 
> On Sun, Aug 26, 2018 at 10:51 PM Mark Andrews  > wrote:
> I would add a covered type field to TIMEOUT (c.f. RRSIG).  I also wouldn’t 
> have more than
> a single timeout per record.  I’m tempted to say a single hash as well.  If 
> there is multiple
> timeouts per record then the blocks need to be sorted in timeout order.
> 
> Covered is there to reduce the number of RR’s that need to be hashed to 
> remove a record.
> It will also reduce the size of IXFR’s as you don’t need to re-construct a 
> new TIMEOUT
> record that covers every timeout at a name on each change.
> 
> For all records at a name is often more expensive that for all records of 
> type covered.
> Name servers are optimised for looking up  tuples rather 
> than 
> tuples.
> 
> Sorting of timeout blocks is so that you can look at the first timeout when 
> working out
> which TIMEOUT needs to be processed first in a zone.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia 
> 
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org 
> 
> 

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 26, 2018, at 10:51 PM, Mark Andrews  wrote:
> 
> I would add a covered type field to TIMEOUT (c.f. RRSIG).  I also wouldn’t 
> have more than
> a single timeout per record.  I’m tempted to say a single hash as well.  If 
> there is multiple
> timeouts per record then the blocks need to be sorted in timeout order.
> 
> Covered is there to reduce the number of RR’s that need to be hashed to 
> remove a record.
> It will also reduce the size of IXFR’s as you don’t need to re-construct a 
> new TIMEOUT
> record that covers every timeout at a name on each change.
> 
> For all records at a name is often more expensive that for all records of 
> type covered.
> Name servers are optimised for looking up  tuples rather 
> than 
> tuples.
> 
> Sorting of timeout blocks is so that you can look at the first timeout when 
> working out
> which TIMEOUT needs to be processed first in a zone.
> 
> -- 
> Mark Andrews, ISC

We didn’t anticipate multiple lifetimes per record (although the current draft 
doesn’t prevent this). Things get tricky with multiple lifetimes on a record 
because if you keep the most future date only and then that record disappears, 
you may need to restore a less future date but if you didn’t keep it, you 
can’t. So keeping all the lifetimes is the only way to ensure you handle 
changes correctly.

Sorting the timeouts is a good idea.

Adding TYPE would increase the number of blocks but reduce the number of hashes 
needed. This might simplify SRP complexity. Some analysis is required to 
determine if this is a net benefit.

Thanks,
Tom


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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

I’m not sure I understand your comment.

I believe I just showed you how SRP does work in the existing draft. If I’ve 
somehow mis-understood how SRP works, please let me know.

Tom

> On Aug 26, 2018, at 10:48 PM, Ted Lemon  wrote:
> 
> SRP has to work.   We updated the DNS update lease spec to account for the 
> different lease times; there may be further work to do there.   But the lease 
> on the name and service instance name KEY records has to be able to be 
> different than the lease on the other data—we want that data to expire 
> quickly, but for the KEY to stick around for a while so that the name can't 
> be claimed by a rogue service just because e.g. the printer is powered off 
> right now.
> 
>> On Aug 26, 2018, at 10:22 PM, Tom Pusateri  wrote:
>> 
>> 
>>> On Aug 26, 2018, at 8:12 PM, Ted Lemon  wrote:
>>> 
>>> The timeout isn't the same for DNSSD Registration Protocol.
>> 
>> Ok, this is a little detailed but let's take what the current draft says and 
>> be explicit about your particular SRP case. I think I am representing SRP 
>> correctly but if not, please correct me.
>> 
>> 
>> [1. One thing that’s not clear about SRP is if the same host registers more 
>> than one service, does your particular form of UPDATE (which isn’t standard 
>> UPDATE) have to contain the same A and/or  records in both registrations 
>> and if so, what is the server to do about different lifetimes?]
>> [2. Also, does SRP recommend including PTR records for name registrations of 
>> A &  names? It doesn’t appear to but should it?]
>> [3. I think you’re going to run into trouble having non-standard UPDATE 
>> rules.]
>> (These are separate discussions about SRP for another forum and if you want 
>> to follow up on these, we should follow up on the dns-sd list.)
>> 
>> 
>> At the end, I’ll do the more simple case of just A &  records.
>> 
>> Let’s assume 3 clients, all with the same service type (different service 
>> types will have different owner names). We will use _ipp._tcp.example.com as 
>> an example.
>> 
>> Client A sends a registration at time Ta with lease life L1a for PTR, SRV, 
>> A, , TXT records, lease life L2a for KEY record.
>> Client B sends a registration at time Tb with lease life L1b for PTR, SRV, 
>> A, TXT records (no ), lease life L2b for KEY record.
>> Client C sends two different instances of the same service (different 
>> instance names) at time Tc with lease life L1c for PTR, SRV, A, , TXT 
>> records, lease life L2c for KEY record.
>> 
>> Client A’s UPDATE contains:
>> 
>> _ipp._tcp.example.com PTR p1._ipp._tcp.example.com
>> p1._ipp._tcp.example.com SRV 0 0 631 p1.example.com
>> p1._ipp._tcp.example.com TXT paper=A4
>> p1.example.com  A  192.0.2.1
>> p1.example.com    2001:db8::1
>> p1.example.com  KEY “key material here"
>> 
>> Client B's UPDATE contains:
>> 
>> _ipp._tcp.example.com PTR p2._ipp._tcp.example.com
>> p2._ipp._tcp.example.com SRV 0 0 631 p2.example.com
>> p2._ipp._tcp.example.com TXT paper=A4
>> p2.example.com  A  192.0.2.2
>> p2.example.com  KEY “key material here”
>> 2.2.0.192.in-addr.arpa.   PTR   p2.example.com.
>> 2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. PTR   p2.example.com. (using 
>> bytes instead of nibbles for compactness)
>> 
>> Client C's UPDATE contains two services at the same time with the same lease 
>> lifes:
>> 
>> _ipp._tcp.example.com PTR p3._ipp._tcp.example.com
>> p3._ipp._tcp.example.com SRV 0 0 631 p3.example.com
>> p3._ipp._tcp.example.com TXT paper=A4
>> p3.example.com  A  192.0.2.3
>> p3.example.com    2001:db8::3
>> p3.example.com  KEY “key material here”
>> 
>> _ipp._tcp.example.com PTR p4._ipp._tcp.example.com
>> p4._ipp._tcp.example.com SRV 0 0 631 p4.example.com
>> p4._ipp._tcp.example.com TXT paper=A4
>> p4.example.com  A  192.0.2.4
>> p4.example.com    2001:db8::4
>> p4.example.com  KEY “key material here”
>> 
>> The TIMEOUT records on the server would look like the following:
>> (owner_name TIMEOUT count algorithm expire hash_list, count algorithm expire 
>> hash_list, etc.)
>> 
>> _ipp.tcp.example.com TIMEOUT 1 1 Ta+L1a (#hash for p1._ipp._tcp.example.com 
>> PTR record)
>>1 1 Tb+L1b (#hash for p2._ipp._tcp.example.com 
>> PTR record)
>>2 1 Tc+L1c (#hash for p3._ipp._tcp.example.com 
>> PTR record) (#hash for p4._ipp._tcp.example.com PTR recor

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

By the way, the SRP case looks messy because SRP chooses to have different 
lease lifetimes for KEY records. If the lease lifetimes were all the same, as I 
would expect for most UPDATES, everything would be simpler.

Tom

> On Aug 26, 2018, at 10:22 PM, Tom Pusateri  wrote:
> 
> 
>> On Aug 26, 2018, at 8:12 PM, Ted Lemon  wrote:
>> 
>> The timeout isn't the same for DNSSD Registration Protocol.
> 
> Ok, this is a little detailed but let's take what the current draft says and 
> be explicit about your particular SRP case. I think I am representing SRP 
> correctly but if not, please correct me.
> 
> 
> [1. One thing that’s not clear about SRP is if the same host registers more 
> than one service, does your particular form of UPDATE (which isn’t standard 
> UPDATE) have to contain the same A and/or  records in both registrations 
> and if so, what is the server to do about different lifetimes?]
> [2. Also, does SRP recommend including PTR records for name registrations of 
> A &  names? It doesn’t appear to but should it?]
> [3. I think you’re going to run into trouble having non-standard UPDATE 
> rules.]
> (These are separate discussions about SRP for another forum and if you want 
> to follow up on these, we should follow up on the dns-sd list.)
> 
> 
> At the end, I’ll do the more simple case of just A &  records.
> 
> Let’s assume 3 clients, all with the same service type (different service 
> types will have different owner names). We will use _ipp._tcp.example.com as 
> an example.
> 
> Client A sends a registration at time Ta with lease life L1a for PTR, SRV, A, 
> , TXT records, lease life L2a for KEY record.
> Client B sends a registration at time Tb with lease life L1b for PTR, SRV, A, 
> TXT records (no ), lease life L2b for KEY record.
> Client C sends two different instances of the same service (different 
> instance names) at time Tc with lease life L1c for PTR, SRV, A, , TXT 
> records, lease life L2c for KEY record.
> 
> Client A’s UPDATE contains:
> 
> _ipp._tcp.example.com PTR p1._ipp._tcp.example.com
> p1._ipp._tcp.example.com SRV 0 0 631 p1.example.com
> p1._ipp._tcp.example.com TXT paper=A4
> p1.example.com  A  192.0.2.1
> p1.example.com    2001:db8::1
> p1.example.com  KEY “key material here"
> 
> Client B's UPDATE contains:
> 
> _ipp._tcp.example.com PTR p2._ipp._tcp.example.com
> p2._ipp._tcp.example.com SRV 0 0 631 p2.example.com
> p2._ipp._tcp.example.com TXT paper=A4
> p2.example.com  A  192.0.2.2
> p2.example.com  KEY “key material here”
> 2.2.0.192.in-addr.arpa.   PTR   p2.example.com.
> 2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. PTR   p2.example.com. (using 
> bytes instead of nibbles for compactness)
> 
> Client C's UPDATE contains two services at the same time with the same lease 
> lifes:
> 
> _ipp._tcp.example.com PTR p3._ipp._tcp.example.com
> p3._ipp._tcp.example.com SRV 0 0 631 p3.example.com
> p3._ipp._tcp.example.com TXT paper=A4
> p3.example.com  A  192.0.2.3
> p3.example.com    2001:db8::3
> p3.example.com  KEY “key material here”
> 
> _ipp._tcp.example.com PTR p4._ipp._tcp.example.com
> p4._ipp._tcp.example.com SRV 0 0 631 p4.example.com
> p4._ipp._tcp.example.com TXT paper=A4
> p4.example.com  A  192.0.2.4
> p4.example.com    2001:db8::4
> p4.example.com  KEY “key material here”
> 
> The TIMEOUT records on the server would look like the following:
> (owner_name TIMEOUT count algorithm expire hash_list, count algorithm expire 
> hash_list, etc.)
> 
> _ipp.tcp.example.com TIMEOUT 1 1 Ta+L1a (#hash for p1._ipp._tcp.example.com 
> PTR record)
> 1 1 Tb+L1b (#hash for p2._ipp._tcp.example.com 
> PTR record)
> 2 1 Tc+L1c (#hash for p3._ipp._tcp.example.com 
> PTR record) (#hash for p4._ipp._tcp.example.com PTR record)
> 
> p1._ipp._tcp.example.com TIMEOUT 0 0 Ta+L1a
> 
> p2._ipp._tcp.example.com TIMEOUT 0 0 Tb+L1b
> 
> p3._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c
> 
> p4._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c
> 
> p1.example.com  TIMEOUT  2 1 Ta+L1a (#hash for 192.0.2.1 A record) (#hash for 
> 2001:db8::1  record)
> 1 1 Ta+L2a (#hash for p1.example.com KEY record)
> 
> p2.example.com  TIMEOUT  1 1 Tb+L1b (#hash for 192.0.2.2 A record)
> 1 1 Tb+L2b (#hash for p2.example.com KEY record)
> 
> p3.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.3 A record) (#hash for 
> 2001:db8::3  record)
> 1 1 Tc+L2c (#hash for p3.example.com KEY record)
> 
> p4.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.4 A record) (#hash for 

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 26, 2018, at 8:12 PM, Ted Lemon  wrote:
> 
> The timeout isn't the same for DNSSD Registration Protocol.

Ok, this is a little detailed but let's take what the current draft says and be 
explicit about your particular SRP case. I think I am representing SRP 
correctly but if not, please correct me.


[1. One thing that’s not clear about SRP is if the same host registers more 
than one service, does your particular form of UPDATE (which isn’t standard 
UPDATE) have to contain the same A and/or  records in both registrations 
and if so, what is the server to do about different lifetimes?]
[2. Also, does SRP recommend including PTR records for name registrations of A 
&  names? It doesn’t appear to but should it?]
[3. I think you’re going to run into trouble having non-standard UPDATE rules.]
(These are separate discussions about SRP for another forum and if you want to 
follow up on these, we should follow up on the dns-sd list.)


At the end, I’ll do the more simple case of just A &  records.

Let’s assume 3 clients, all with the same service type (different service types 
will have different owner names). We will use _ipp._tcp.example.com as an 
example.

Client A sends a registration at time Ta with lease life L1a for PTR, SRV, A, 
, TXT records, lease life L2a for KEY record.
Client B sends a registration at time Tb with lease life L1b for PTR, SRV, A, 
TXT records (no ), lease life L2b for KEY record.
Client C sends two different instances of the same service (different instance 
names) at time Tc with lease life L1c for PTR, SRV, A, , TXT records, lease 
life L2c for KEY record.

Client A’s UPDATE contains:

_ipp._tcp.example.com PTR p1._ipp._tcp.example.com
p1._ipp._tcp.example.com SRV 0 0 631 p1.example.com
p1._ipp._tcp.example.com TXT paper=A4
p1.example.com  A  192.0.2.1
p1.example.com    2001:db8::1
p1.example.com  KEY “key material here"

Client B's UPDATE contains:

_ipp._tcp.example.com PTR p2._ipp._tcp.example.com
p2._ipp._tcp.example.com SRV 0 0 631 p2.example.com
p2._ipp._tcp.example.com TXT paper=A4
p2.example.com  A  192.0.2.2
p2.example.com  KEY “key material here”
2.2.0.192.in-addr.arpa.   PTR   p2.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. PTR   p2.example.com. (using 
bytes instead of nibbles for compactness)

Client C's UPDATE contains two services at the same time with the same lease 
lifes:

_ipp._tcp.example.com PTR p3._ipp._tcp.example.com
p3._ipp._tcp.example.com SRV 0 0 631 p3.example.com
p3._ipp._tcp.example.com TXT paper=A4
p3.example.com  A  192.0.2.3
p3.example.com    2001:db8::3
p3.example.com  KEY “key material here”

_ipp._tcp.example.com PTR p4._ipp._tcp.example.com
p4._ipp._tcp.example.com SRV 0 0 631 p4.example.com
p4._ipp._tcp.example.com TXT paper=A4
p4.example.com  A  192.0.2.4
p4.example.com    2001:db8::4
p4.example.com  KEY “key material here”

The TIMEOUT records on the server would look like the following:
(owner_name TIMEOUT count algorithm expire hash_list, count algorithm expire 
hash_list, etc.)

_ipp.tcp.example.com TIMEOUT 1 1 Ta+L1a (#hash for p1._ipp._tcp.example.com PTR 
record)
 1 1 Tb+L1b (#hash for p2._ipp._tcp.example.com PTR 
record)
 2 1 Tc+L1c (#hash for p3._ipp._tcp.example.com PTR 
record) (#hash for p4._ipp._tcp.example.com PTR record)

p1._ipp._tcp.example.com TIMEOUT 0 0 Ta+L1a

p2._ipp._tcp.example.com TIMEOUT 0 0 Tb+L1b

p3._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c

p4._ipp._tcp.example.com TIMEOUT 0 0 Tc+L1c

p1.example.com  TIMEOUT  2 1 Ta+L1a (#hash for 192.0.2.1 A record) (#hash for 
2001:db8::1  record)
 1 1 Ta+L2a (#hash for p1.example.com KEY record)

p2.example.com  TIMEOUT  1 1 Tb+L1b (#hash for 192.0.2.2 A record)
 1 1 Tb+L2b (#hash for p2.example.com KEY record)

p3.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.3 A record) (#hash for 
2001:db8::3  record)
 1 1 Tc+L2c (#hash for p3.example.com KEY record)

p4.example.com  TIMEOUT  2 1 Tc+L1c (#hash for 192.0.2.4 A record) (#hash for 
2001:db8::4  record)
 1 1 Tc+L2c (#hash for p4.example.com KEY record)

2.2.0.192.in-addr.arpa.   TIMEOUT 0 0 Tb+L1b
2.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. TIMEOUT 0 0 Tb+L1b (using bytes 
instead of nibbles for compactness)


So, in general, for any one service registration without PTR records for 
addresses, you will create:
3 TIMEOUT records, 2 with a hash and 1 without a hash

or with PTR records for names included, you will create:
5 TIMEOUT records, 2 with a hash and 3 without a hash.


For the simpler case, a host sending a name registration at time Tn for A & 
 records with lease lifetime Ln would have an UPDATE that contains:

name_n.example.comA 192.0.2.5
name_n.example.com  2001:db8::5
5.2.0.192.in-

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 26, 2018, at 7:07 PM, Paul Vixie  wrote:
> 
> Tom Pusateri wrote:
>> 
>> There’s no attack vector here. And a collision would have to be
>> another valid RR already in the database with the same owner name and
>> class. This is literally impossible. Probably not even with md5!
> 
> as i wrote when the discussion of catalog zone hashing got to this point, "if 
> collisions are impossible even with md5, then please use md5, and include a 
> security considerations paragraph or two as to how this is not a problem. for 
> that matter, if md4 or md3 will work, use those. unnec'y hash complexity is a 
> form of security theater."
> 
> -- 
> P Vixie

You may be ok with that but no one from the security area will be. That’s just 
a fact of the times. The code in OpenSSL is identical no matter which hash you 
pick except for the hash name so it’s no more complex to implement. 

My approach was to pick the best hash available with a small output length.

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 26, 2018, at 6:54 PM, Paul Vixie  wrote:
> 
> 
> 
> Tom Pusateri wrote:
> ...
>> SHAKE128 as well as other SHA-3 algorithms have been found to be
>> quitecollision resistant.
> 
> right. they all are, at first. we're building for our grandkids though.
> 
> -- 
> P Vixie

There’s no attack vector here. And a collision would have to be another valid 
RR already in the database with the same owner name and class. This is 
literally impossible. Probably not even with md5!

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 26, 2018, at 3:59 PM, Paul Vixie  wrote:
> 
>> On Sunday, August 26, 2018 5:47:43 PM UTC Tom Pusateri wrote:
>> ...
>> Nice properties of the hash:
>> 
>> 1. the length of the output value is consistent across varying input lengths
>> of any RR type (128 bits in the case of the algorithm specified in the
>> draft) making it easy to sequence through. 2. it’s independently verifiable
>> between servers and across time on the same server 3. it’s independent of
>> position of the RR it covers 
>> 4. it works the same for all existing RR’s as well as RR’s yet to be defined
>> 
>> Other methods may share some of these properties but I’m just listing all of
>> the ones I can think of.
> 
> as i wrote about a hash that was proposed in part of zone catalog work, there 
> are two things that are really bad about these. 
> 
> 1. the resulting design is not collision-resilient
> 
> 2. the hash will have to change some day, invoking rollover complexity cost
> 
> while DHT is a better example of "use a hash because it's magic and makes it 
> look like our coherency problems have gone away", in fact all non-security-
> related hash uses should be suspected of the same. you won't want to use a 
> hash in a distributed system (where hash values have to be portable) unless 
> every alternative has a vastly higher cost.
> 
> -- 
> Vixie

SHAKE128 as well as other SHA-3 algorithms have been found to be quite 
collision resistant.

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

I actually think the hash won’t be needed as much as you think. If the timeout 
is the same, even though the record types are different, you still don’t need 
the hash.

Is this straightforward?

//
//  main.c
//  requires OpenSSL 1.1.1 or later
//
//  Created by Tom Pusateri on 8/26/18.
//  Copyright © 2018 !j.
//
//  MIT LICENSE as specified here: https://opensource.org/licenses/MIT
//

#include 
#include 
#include 

int main(int argc, const char * argv[]) {
EVP_MD_CTX *mdctx;
const EVP_MD *md;
char msg[] = "This is a test";
unsigned char md_value[EVP_MAX_MD_SIZE];
u_int md_len, i;

md = EVP_shake128();
if (md == NULL) {
printf("Unknown message digest %s\n", argv[1]);
exit(1);
}

mdctx = EVP_MD_CTX_new();
EVP_DigestInit_ex(mdctx, md, NULL);
EVP_DigestUpdate(mdctx, msg, strlen(msg));
EVP_DigestFinal_ex(mdctx, md_value, &md_len);
EVP_MD_CTX_free(mdctx);

printf("Digest is: ");
for (i = 0; i < md_len; i++)
printf("%02x", md_value[i]);
printf("\n");

exit(0);
}


> On Aug 26, 2018, at 3:42 PM, Ted Lemon  wrote:
> 
> You haven't specified how the hash is done, so I can't confirm the truth of 
> your assertion that it's straightforward. :)
> 
> The "only if there are multiple record types" bit doesn't actually help, 
> because I can't actually think of a case where it doesn't apply.   That is, 
> every RR will require a hash, as far as I can tell, in practice.
> 
> 128 bits is 16 bytes—the size of an IPv6 address.   It's probably true that 
> that's shorter than the record in most cases, but I doubt it's enough shorter 
> to make a difference.   And we already know how to compare records—we need 
> that for update.
> 
> On Sun, Aug 26, 2018 at 1:58 PM Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> 
> 
>> On Aug 26, 2018, at 1:47 PM, Tom Pusateri > <mailto:pusat...@bangj.com>> wrote:
>> 
>> 
>> 
>>> On Aug 26, 2018, at 12:58 PM, Ted Lemon >> <mailto:mel...@fugue.com>> wrote:
>>> 
>>> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri >> <mailto:pusat...@bangj.com>> wrote:
>>> I think I already agreed with you here.
>>> 
>>> My main point was that the primary needs a database and it already has one 
>>> and probably doesn’t want another one. Because of the added benefit that 
>>> Paul points out with promoting a secondary to primary after an extended 
>>> outage, and the points that Joe makes about treating all records the same, 
>>> it seems logical to store the lease lifetime information as actual resource 
>>> records and transfer them to the secondary.
>>> 
>>> FWIW, I think the database storage argument is actually the best argument 
>>> for this proposal: we need a way to represent  the data structure on disk, 
>>> and what we know how to store are RRs.
>>> That said, I think that it's worth asking the question of what the right 
>>> format is, and not just assuming that it's a hash.
>> 
>> Nice properties of the hash:
>> 
>> 1. the length of the output value is consistent across varying input lengths 
>> of any RR type (128 bits in the case of the algorithm specified in the 
>> draft) making it easy to sequence through.
>> 2. it’s independently verifiable between servers and across time on the same 
>> server
>> 3. it’s independent of position of the RR it covers
>> 4. it works the same for all existing RR’s as well as RR’s yet to be defined
>> 
>> Other methods may share some of these properties but I’m just listing all of 
>> the ones I can think of.
> 
> Also, remember the hash is only needed if there are multiple records types 
> with the same owner name / class having different timeouts (including no 
> timeout).
> 
> So in the case of a unique name being added for a delegated address, the NO 
> HASH value can be used and no hash needs to be calculated. In the case of 
> both an IPv4 and IPv6 address being delegated and subsequently sending an 
> UPDATE with the same owner name, as long as the lease time is the same, 
> again, there is no need for the hash.
> 
> If, however, an RRSIG is dynamically generated for the owner name, then the 
> hash will be needed. (You won’t want to timeout RRSIGs but instead timeout 
> the A/ and then recalculate the RRSIG/NSEC/NSEC3/NSEC5 records.)
> 
> Tom
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 26, 2018, at 1:47 PM, Tom Pusateri  wrote:
> 
> 
> 
>> On Aug 26, 2018, at 12:58 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri > <mailto:pusat...@bangj.com>> wrote:
>> I think I already agreed with you here.
>> 
>> My main point was that the primary needs a database and it already has one 
>> and probably doesn’t want another one. Because of the added benefit that 
>> Paul points out with promoting a secondary to primary after an extended 
>> outage, and the points that Joe makes about treating all records the same, 
>> it seems logical to store the lease lifetime information as actual resource 
>> records and transfer them to the secondary.
>> 
>> FWIW, I think the database storage argument is actually the best argument 
>> for this proposal: we need a way to represent  the data structure on disk, 
>> and what we know how to store are RRs.
>> That said, I think that it's worth asking the question of what the right 
>> format is, and not just assuming that it's a hash.
> 
> Nice properties of the hash:
> 
> 1. the length of the output value is consistent across varying input lengths 
> of any RR type (128 bits in the case of the algorithm specified in the draft) 
> making it easy to sequence through.
> 2. it’s independently verifiable between servers and across time on the same 
> server
> 3. it’s independent of position of the RR it covers
> 4. it works the same for all existing RR’s as well as RR’s yet to be defined
> 
> Other methods may share some of these properties but I’m just listing all of 
> the ones I can think of.

Also, remember the hash is only needed if there are multiple records types with 
the same owner name / class having different timeouts (including no timeout).

So in the case of a unique name being added for a delegated address, the NO 
HASH value can be used and no hash needs to be calculated. In the case of both 
an IPv4 and IPv6 address being delegated and subsequently sending an UPDATE 
with the same owner name, as long as the lease time is the same, again, there 
is no need for the hash.

If, however, an RRSIG is dynamically generated for the owner name, then the 
hash will be needed. (You won’t want to timeout RRSIGs but instead timeout the 
A/ and then recalculate the RRSIG/NSEC/NSEC3/NSEC5 records.)

Tom


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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 26, 2018, at 12:58 PM, Ted Lemon  wrote:
> 
> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> I think I already agreed with you here.
> 
> My main point was that the primary needs a database and it already has one 
> and probably doesn’t want another one. Because of the added benefit that Paul 
> points out with promoting a secondary to primary after an extended outage, 
> and the points that Joe makes about treating all records the same, it seems 
> logical to store the lease lifetime information as actual resource records 
> and transfer them to the secondary.
> 
> FWIW, I think the database storage argument is actually the best argument for 
> this proposal: we need a way to represent  the data structure on disk, and 
> what we know how to store are RRs.
> That said, I think that it's worth asking the question of what the right 
> format is, and not just assuming that it's a hash.

Nice properties of the hash:

1. the length of the output value is consistent across varying input lengths of 
any RR type (128 bits in the case of the algorithm specified in the draft) 
making it easy to sequence through.
2. it’s independently verifiable between servers and across time on the same 
server
3. it’s independent of position of the RR it covers
4. it works the same for all existing RR’s as well as RR’s yet to be defined

Other methods may share some of these properties but I’m just listing all of 
the ones I can think of.

Thanks,
Tom


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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

I think I already agreed with you here.

My main point was that the primary needs a database and it already has one and 
probably doesn’t want another one. Because of the added benefit that Paul 
points out with promoting a secondary to primary after an extended outage, and 
the points that Joe makes about treating all records the same, it seems logical 
to store the lease lifetime information as actual resource records and transfer 
them to the secondary.

Thanks,
Tom


> On Aug 25, 2018, at 2:13 PM, Ted Lemon  wrote:
> 
> Well, okay, but isn't this just for garbage collection?   Why is it a problem 
> if the garbage collection is delayed?   If the primary is down, it's not like 
> some other device could claim that name anyway.
> 
> On Sat, Aug 25, 2018 at 2:11 PM Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> This is a valid question.
> 
> In most cases, having the primary remember the lease lifetime should be 
> enough. But if the outage is longer than the lease lifetime, it would better 
> if the secondary would also have that information.
> 
> But more importantly, the primary has to store the lease lifetimes for it’s 
> own use for protection against restarts, reboots, and crashes. Keeping the 
> lease lifetime closest to the records they reference is a good principle and 
> so storing them as records along with the records they reference seems not 
> only reasonable, but preferred.
> 
> Whether or not they are transferred to the secondary is of secondary 
> importance. But having them treated as regular records has been recommended 
> so having them transferred during AXFR/IXFR will be looked upon with favor.
> 
> Thanks,
> Tom
> 
> 
> 
>> On Aug 25, 2018, at 11:11 AM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>> Right; my question is, is this an operational problem people are having IRL? 
>>   If it is, then it makes sense to do something about it.   If it's not, it 
>> doesn't.   I've never seen people do what you're describing in practice; 
>> that's why I'm asking..   And we definitely agree that there needs to be a 
>> cleanup process; the question is, does it have to be done this way.   E.g., 
>> if the lease isn't part of the zone, is that actually a problem?   Does the 
>> lease need to be part of the zone transfer, or is it enough that the primary 
>> has it?   For my part, it seems unnecessary for the secondaries to have it, 
>> since they can't update the zone anyway.   As long as the primary remembers 
>> that there's a lease, the right thing will happen.
>> 
>> On Sat, Aug 25, 2018 at 10:30 AM Mark Andrews > <mailto:ma...@isc.org>> wrote:
>> It avoids leaving dangling records published longer than necessary.
>> 
>> Network dies so the machine can’t do the cleanup it was intending.
>> 
>> Last second cleanup as the lid closes doesn’t get through. 
>> 
>> It’s relatively easy to implement, no more difficult than resigning for 
>> DNSSEC at the cost of a small amount of space.  It also transfers the 
>> necessary state to all the slaves allowing them to take over if the master 
>> server fails presuming they have the keying material for DNSSEC. 
>> 
>> -- 
>> Mark Andrews
>> 
>> On 25 Aug 2018, at 22:53, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>>> I'm not saying nobody does it.   I'm trying to understand how this helps.
>>> 
>>> On Fri, Aug 24, 2018 at 11:24 PM Mark Andrews >> <mailto:ma...@isc.org>> wrote:
>>> Ted stop being daft. People have been registering addresses of machines in 
>>> the public DNS for decades.   SLAAC. Is just one source of addresses. DHCP 
>>> is another. Come up with a third method and they will do it with it. 
>>> 
>>> Also DHCP servers from ISPs don’t have authority to update DNS servers for 
>>> my machines. Only those machines have such authority so don’t discount DHCP 
>>> derived addresses. 
>>> 
>>> -- 
>>> Mark Andrews
>>> 
>>> On 25 Aug 2018, at 12:53, Ted Lemon >> <mailto:mel...@fugue.com>> wrote:
>>> 
>>>> When would that happen?
>>>> 
>>>> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews >>> <mailto:ma...@isc.org>> wrote:
>>>> Registering slaac derived addresses in the DNS.  These are tied to prefix 
>>>> lifetimes. 
>>>> 
>>>> 
>>>> -- 
>>>> Mark Andrews
>>>> 
>>>> On 25 Aug 2018, at 05:02, Tom Pusateri >>> <mailto:pusat...@bangj.com

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 25, 2018, at 2:53 PM, Paul Vixie  wrote:
> 
> On Saturday, August 25, 2018 6:11:48 PM UTC Tom Pusateri wrote:
>> ...
>> 
>> In most cases, having the primary remember the lease lifetime should be
>> enough. But if the outage is longer than the lease lifetime, it would
>> better if the secondary would also have that information.
> 
> you seem to be proposing that the "secondary" servers, by which i mean those 
> not the primary master, alter the zone contents in a way that's visible to 
> query initiators, independently. if so, i oppose this, in the form proposed.
> 
> to have more than one source of DNS truth requires "multi-master", so that 
> zone identity can be partitioned and healed, following partitions and 
> healings 
> of the connectivity of each responder and its cloud of reachable clients. one 
> of the hard problems here is split horizon. another is incompatible deltas at 
> heal time. the database world has grappled with this topic, having varying 
> degrees of success, for as long as there have been computer networks.
> 
> i would like to see DNS add "multi-master". several proprietary vendor 
> extensions do various parts of this -- though none of them that i know of can 
> handle split horizon or incompatible deltas. and tellingly, none has been 
> opened to the community in the form of a standardization effort.
> 
> if on the other hand you only intend to carry the timeout information as zone 
> data transferred in AXFR/IXFR in case a sysop decides that the primary master 
> will be offline indefinitely and wants to manually promote one of the 
> "secondary" servers to the role of primary master, then i have no objection. 
> that's why the TUU and TUD RR's of my 1996 "defupd" proposal are in-zone data 
> rather than stored in some ancillary location reachable only by the primary 
> master.
> 
> can you verify that you do not intend secondary servers to automatically 
> expire records, independent of hearing IXFR/AXFR updates from the primary 
> master, after the primary master applies its own copy of your TIMEOUT RR's?
> 
> -- 
> Vixie
> 

I agree that the secondary servers should not expire records. In the case of 
promotion, I also agree that this sounds like a good strategy.

Thanks for pointing out this distinction.

Tom


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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

This is a valid question.

In most cases, having the primary remember the lease lifetime should be enough. 
But if the outage is longer than the lease lifetime, it would better if the 
secondary would also have that information.

But more importantly, the primary has to store the lease lifetimes for it’s own 
use for protection against restarts, reboots, and crashes. Keeping the lease 
lifetime closest to the records they reference is a good principle and so 
storing them as records along with the records they reference seems not only 
reasonable, but preferred.

Whether or not they are transferred to the secondary is of secondary 
importance. But having them treated as regular records has been recommended so 
having them transferred during AXFR/IXFR will be looked upon with favor.

Thanks,
Tom



> On Aug 25, 2018, at 11:11 AM, Ted Lemon  wrote:
> 
> Right; my question is, is this an operational problem people are having IRL?  
>  If it is, then it makes sense to do something about it.   If it's not, it 
> doesn't.   I've never seen people do what you're describing in practice; 
> that's why I'm asking.   And we definitely agree that there needs to be a 
> cleanup process; the question is, does it have to be done this way.   E.g., 
> if the lease isn't part of the zone, is that actually a problem?   Does the 
> lease need to be part of the zone transfer, or is it enough that the primary 
> has it?   For my part, it seems unnecessary for the secondaries to have it, 
> since they can't update the zone anyway.   As long as the primary remembers 
> that there's a lease, the right thing will happen.
> 
> On Sat, Aug 25, 2018 at 10:30 AM Mark Andrews  <mailto:ma...@isc.org>> wrote:
> It avoids leaving dangling records published longer than necessary.
> 
> Network dies so the machine can’t do the cleanup it was intending.
> 
> Last second cleanup as the lid closes doesn’t get through. 
> 
> It’s relatively easy to implement, no more difficult than resigning for 
> DNSSEC at the cost of a small amount of space.  It also transfers the 
> necessary state to all the slaves allowing them to take over if the master 
> server fails presuming they have the keying material for DNSSEC. 
> 
> -- 
> Mark Andrews
> 
> On 25 Aug 2018, at 22:53, Ted Lemon  <mailto:mel...@fugue.com>> wrote:
> 
>> I'm not saying nobody does it.   I'm trying to understand how this helps.
>> 
>> On Fri, Aug 24, 2018 at 11:24 PM Mark Andrews > <mailto:ma...@isc.org>> wrote:
>> Ted stop being daft. People have been registering addresses of machines in 
>> the public DNS for decades.   SLAAC. Is just one source of addresses. DHCP 
>> is another. Come up with a third method and they will do it with it. 
>> 
>> Also DHCP servers from ISPs don’t have authority to update DNS servers for 
>> my machines. Only those machines have such authority so don’t discount DHCP 
>> derived addresses. 
>> 
>> -- 
>> Mark Andrews
>> 
>> On 25 Aug 2018, at 12:53, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>>> When would that happen?
>>> 
>>> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews >> <mailto:ma...@isc.org>> wrote:
>>> Registering slaac derived addresses in the DNS.  These are tied to prefix 
>>> lifetimes. 
>>> 
>>> 
>>> -- 
>>> Mark Andrews
>>> 
>>> On 25 Aug 2018, at 05:02, Tom Pusateri >> <mailto:pusat...@bangj.com>> wrote:
>>> 
>>>> 
>>>> 
>>>>> On Aug 24, 2018, at 2:59 PM, Ted Lemon >>>> <mailto:mel...@fugue.com>> wrote:
>>>>> 
>>>>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri >>>> <mailto:pusat...@bangj.com>> wrote:
>>>>>> It seems odd to take the position that the authoritative server 
>>>>>> shouldn’t need to clean up stale entries because it assumes the client 
>>>>>> will do it for you. I can’t imagine you taking this position under any 
>>>>>> other scenario.
>>>>> 
>>>>> The issue here is that this is a pretty major change to the DNS.   If we 
>>>>> really want something this heavy, we should have a good reason for 
>>>>> wanting it.   That's all.
>>>>> 
>>>>> The idea that some unnamed DHCP server somewhere doesn't do the right 
>>>>> thing with cleaning up stale entries doesn't seem like a good enough 
>>>>> reason, particularly given that the DHCID record tags the thing as having 
>>>>> been added by t

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

Right, prefix delegation over DHCPv6 is a similar case that gets a prefix 
lifetime. I still use the WIDE dhcp6c client for PD and it has no means to 
update DNS. I haven’t found specific documentation from ISC DHCPv6 or KEA that 
describes creating DNS entries (PTR records) from delegated prefixes.

Tom

> On Aug 24, 2018, at 10:53 PM, Ted Lemon  wrote:
> 
> When would that happen?
> 
> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews  <mailto:ma...@isc.org>> wrote:
> Registering slaac derived addresses in the DNS.  These are tied to prefix 
> lifetimes. 
> 
> 
> -- 
> Mark Andrews
> 
> On 25 Aug 2018, at 05:02, Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> 
>> 
>> 
>>> On Aug 24, 2018, at 2:59 PM, Ted Lemon >> <mailto:mel...@fugue.com>> wrote:
>>> 
>>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri >> <mailto:pusat...@bangj.com>> wrote:
>>>> It seems odd to take the position that the authoritative server shouldn’t 
>>>> need to clean up stale entries because it assumes the client will do it 
>>>> for you. I can’t imagine you taking this position under any other scenario.
>>> 
>>> The issue here is that this is a pretty major change to the DNS.   If we 
>>> really want something this heavy, we should have a good reason for wanting 
>>> it.   That's all.
>>> 
>>> The idea that some unnamed DHCP server somewhere doesn't do the right thing 
>>> with cleaning up stale entries doesn't seem like a good enough reason, 
>>> particularly given that the DHCID record tags the thing as having been 
>>> added by the DHCP server, and considering that there are several open 
>>> source implementations that do automatically delete records when the lease 
>>> expires.
>>> 
>>> I think it might make sense to just wait on this.  I agree that it's an 
>>> interesting idea for completeness, but we don't have enough operational 
>>> experience yet to know whether we have a problem worth solving.   With 
>>> respect to the DHCP use case, I'm certain we don't.
>>> 
>>> The good news is that if we do need this, you've done a design, and we also 
>>> have Paul's design to look at.   So if operational experience a few years 
>>> down the road shows us that we have a gap here, we can move on it pretty 
>>> easily. I just don't see any reason to rush into it.
>> 
>> Ok, great. Hopefully others have some use cases they can share. In the mean 
>> time, back to learning Rust…
>> 
>> Thanks,
>> Tom
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> <https://www.ietf.org/mailman/listinfo/dnsop>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 3:46 AM, Mark Andrews  wrote:
> 
> This is unnecessary.  All the rule does is limit the process to class IN 
> zones.  UPDATE, IXFR and AXFR are class agnostic.
> 
> 1.  TIMEOUT resource records are only defined for CLASS IN.

Ok, we will make them applicable to all classes.

> 
> This seems overly restrictive.  I would allow TIMEOUT records that
> match added records to be accepted.
> 
> 5.  TIMEOUT resource records cannot be directly added, modified, or
>   deleted through DNS Update.

This restriction is another consequence of not being able to query TIMEOUT 
records. In order to allow UPDATE of TIMEOUT records, the client has to be able 
to retrieve the record and merge changes before UPDATING it. The server can’t 
do the merging or the record would change underneath the client that created it 
when another client added a record with the same owner name.

We haven’t been able to think of any significant downsides to allowing QUERY of 
TIMEOUT records and by doing so, it solves Joe’s issues so unless you can think 
of any, we’ll make that change in the next version and then be able to support 
UPDATE of TIMEOUT records.

> 
> Secondary servers that are TIMEOUT aware should ignore TIMEOUT records
> beyond storing them in case the server get promoted to being the master.
> 
> Is the secondary going to be able regenerate the RRset as the records are
> removed as well as generate and sign NSEC and NSEC3 records?

I would expect a secondary server to treat them the same as it does any other 
record type.

> 
> Sources of TIMEOUT Expiry Time
> 
> Add matching TIMEOUT records added via UPDATE.

Ok.

Thanks!

Tom

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 2:59 PM, Ted Lemon  wrote:
> 
> On Aug 24, 2018, at 2:43 PM, Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
>> It seems odd to take the position that the authoritative server shouldn’t 
>> need to clean up stale entries because it assumes the client will do it for 
>> you. I can’t imagine you taking this position under any other scenario.
> 
> The issue here is that this is a pretty major change to the DNS.   If we 
> really want something this heavy, we should have a good reason for wanting 
> it.   That's all.
> 
> The idea that some unnamed DHCP server somewhere doesn't do the right thing 
> with cleaning up stale entries doesn't seem like a good enough reason, 
> particularly given that the DHCID record tags the thing as having been added 
> by the DHCP server, and considering that there are several open source 
> implementations that do automatically delete records when the lease expires.
> 
> I think it might make sense to just wait on this.  I agree that it's an 
> interesting idea for completeness, but we don't have enough operational 
> experience yet to know whether we have a problem worth solving.   With 
> respect to the DHCP use case, I'm certain we don't.
> 
> The good news is that if we do need this, you've done a design, and we also 
> have Paul's design to look at.   So if operational experience a few years 
> down the road shows us that we have a gap here, we can move on it pretty 
> easily. I just don't see any reason to rush into it.

Ok, great. Hopefully others have some use cases they can share. In the mean 
time, back to learning Rust…

Thanks,
Tom

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

It seems odd to take the position that the authoritative server shouldn’t need 
to clean up stale entries because it assumes the client will do it for you. I 
can’t imagine you taking this position under any other scenario.

Thanks,
Tom


> On Aug 24, 2018, at 2:33 PM, Tom Pusateri  wrote:
> 
> Sorry, I never surveyed the set of inconsiderate DCHP servers.
> 
> Thanks,
> Tom
> 
> On Aug 24, 2018, at 2:04 PM, Ted Lemon  <mailto:mel...@fugue.com>> wrote:
> 
>> Can you give us an example?
>> 
>> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri > <mailto:pusat...@bangj.com>> wrote:
>> Sure. It’s not the thoughtful, well-behaved implementations that we worry 
>> about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND 
>> suspenders..)
>> 
>> Thanks,
>> Tom
>> 
>> 
>>> On Aug 24, 2018, at 1:36 PM, Ted Lemon >> <mailto:mel...@fugue.com>> wrote:
>>> 
>>> The DHCP case isn't actually a problem today.   DHCP servers automatically 
>>> remove these records.   The ISC server has been doing this for 20 years, 
>>> and I'm pretty sure all the other servers that compete with it do too.
>>> 
>>> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri >> <mailto:pusat...@bangj.com>> wrote:
>>> 
>>> 
>>>> On Aug 24, 2018, at 9:54 AM, Ted Lemon >>> <mailto:mel...@fugue.com>> wrote:
>>>> 
>>>> On Aug 24, 2018, at 9:52 AM, Tom Pusateri >>> <mailto:pusat...@bangj.com>> wrote:
>>>>> Yes, it was intended to be more general than for service registration. 
>>>>> It’s directly applicable to name registration for IP addresses. I can add 
>>>>> a section on other uses if more motivation is desired. Mark Andrews had 
>>>>> some uses as well that hopefully, he can share. If others have uses in 
>>>>> mind that this solves I would love to hear about them.
>>>> 
>>>> The reason I'm asking is not that I don't think there are theoretical use 
>>>> cases for what you are proposing.   I'm asking if there are actual use 
>>>> cases.   How would this be used in practice?   What can't someone do right 
>>>> now that they need to do and that this new technology enables?
>>> 
>>> Specifically, there are two applications mentioned in the draft.
>>> 
>>> 1. When a DNS server receives a dynamic DNS Update from a client 
>>> registering its name after having received an IP address from an DHCP 
>>> lease, the length of the DHCP lease can be tied to the length that the DNS 
>>> address/PTR records stay in the authoritative server.
>>> 
>>> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT 
>>> records), these records can timeout according to the lease lifetime 
>>> contained in the update lease EDNS(0) option.
>>> 
>>> These are not theoretical. They solve practical problems that exist today. 
>>> I think there are others associated with existing problems for sleeping 
>>> devices and IoT devices that I need to research to more clearly answer your 
>>> specific question but I think these two already fulfill that requirement.
>>> 
>>> Tom
>>> 
>>> 
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/dnsop 
>>> <https://www.ietf.org/mailman/listinfo/dnsop>
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> <https://www.ietf.org/mailman/listinfo/dnsop>

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

Sorry, I never surveyed the set of inconsiderate DCHP servers.

Thanks,
Tom

> On Aug 24, 2018, at 2:04 PM, Ted Lemon  wrote:
> 
> Can you give us an example?
> 
>> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri  wrote:
>> Sure. It’s not the thoughtful, well-behaved implementations that we worry 
>> about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND 
>> suspenders..)
>> 
>> Thanks,
>> Tom
>> 
>> 
>>> On Aug 24, 2018, at 1:36 PM, Ted Lemon  wrote:
>>> 
>>> The DHCP case isn't actually a problem today.   DHCP servers automatically 
>>> remove these records.   The ISC server has been doing this for 20 years, 
>>> and I'm pretty sure all the other servers that compete with it do too.
>>> 
>>> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri  wrote:
>>>> 
>>>> 
>>>>> On Aug 24, 2018, at 9:54 AM, Ted Lemon  wrote:
>>>>> 
>>>>>> On Aug 24, 2018, at 9:52 AM, Tom Pusateri  wrote:
>>>>>> Yes, it was intended to be more general than for service registration.. 
>>>>>> It’s directly applicable to name registration for IP addresses. I can 
>>>>>> add a section on other uses if more motivation is desired. Mark Andrews 
>>>>>> had some uses as well that hopefully, he can share. If others have uses 
>>>>>> in mind that this solves I would love to hear about them.
>>>>> 
>>>>> The reason I'm asking is not that I don't think there are theoretical use 
>>>>> cases for what you are proposing.   I'm asking if there are actual use 
>>>>> cases.   How would this be used in practice?   What can't someone do 
>>>>> right now that they need to do and that this new technology enables?
>>>> 
>>>> Specifically, there are two applications mentioned in the draft.
>>>> 
>>>> 1. When a DNS server receives a dynamic DNS Update from a client 
>>>> registering its name after having received an IP address from an DHCP 
>>>> lease, the length of the DHCP lease can be tied to the length that the DNS 
>>>> address/PTR records stay in the authoritative server.
>>>> 
>>>> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & 
>>>> TXT records), these records can timeout according to the lease lifetime 
>>>> contained in the update lease EDNS(0) option.
>>>> 
>>>> These are not theoretical. They solve practical problems that exist today. 
>>>> I think there are others associated with existing problems for sleeping 
>>>> devices and IoT devices that I need to research to more clearly answer 
>>>> your specific question but I think these two already fulfill that 
>>>> requirement.
>>>> 
>>>> Tom
>>>> 
>>>> 
>>> 
>>> ___
>>> 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] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

Sure. It’s not the thoughtful, well-behaved implementations that we worry 
about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND 
suspenders..)

Thanks,
Tom


> On Aug 24, 2018, at 1:36 PM, Ted Lemon  wrote:
> 
> The DHCP case isn't actually a problem today.   DHCP servers automatically 
> remove these records.   The ISC server has been doing this for 20 years, and 
> I'm pretty sure all the other servers that compete with it do too.
> 
> On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> 
> 
>> On Aug 24, 2018, at 9:54 AM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>> On Aug 24, 2018, at 9:52 AM, Tom Pusateri > <mailto:pusat...@bangj.com>> wrote:
>>> Yes, it was intended to be more general than for service registration. It’s 
>>> directly applicable to name registration for IP addresses. I can add a 
>>> section on other uses if more motivation is desired. Mark Andrews had some 
>>> uses as well that hopefully, he can share. If others have uses in mind that 
>>> this solves I would love to hear about them.
>> 
>> The reason I'm asking is not that I don't think there are theoretical use 
>> cases for what you are proposing.   I'm asking if there are actual use 
>> cases.   How would this be used in practice?   What can't someone do right 
>> now that they need to do and that this new technology enables?
> 
> Specifically, there are two applications mentioned in the draft.
> 
> 1. When a DNS server receives a dynamic DNS Update from a client registering 
> its name after having received an IP address from an DHCP lease, the length 
> of the DHCP lease can be tied to the length that the DNS address/PTR records 
> stay in the authoritative server.
> 
> 2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT 
> records), these records can timeout according to the lease lifetime contained 
> in the update lease EDNS(0) option.
> 
> These are not theoretical. They solve practical problems that exist today. I 
> think there are others associated with existing problems for sleeping devices 
> and IoT devices that I need to research to more clearly answer your specific 
> question but I think these two already fulfill that requirement.
> 
> Tom
> 
> 
> 
> ___
> 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-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 9:54 AM, Ted Lemon  wrote:
> 
> On Aug 24, 2018, at 9:52 AM, Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
>> Yes, it was intended to be more general than for service registration. It’s 
>> directly applicable to name registration for IP addresses. I can add a 
>> section on other uses if more motivation is desired. Mark Andrews had some 
>> uses as well that hopefully, he can share. If others have uses in mind that 
>> this solves I would love to hear about them.
> 
> The reason I'm asking is not that I don't think there are theoretical use 
> cases for what you are proposing.   I'm asking if there are actual use cases. 
>   How would this be used in practice?   What can't someone do right now that 
> they need to do and that this new technology enables?

Specifically, there are two applications mentioned in the draft.

1. When a DNS server receives a dynamic DNS Update from a client registering 
its name after having received an IP address from an DHCP lease, the length of 
the DHCP lease can be tied to the length that the DNS address/PTR records stay 
in the authoritative server.

2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT 
records), these records can timeout according to the lease lifetime contained 
in the update lease EDNS(0) option.

These are not theoretical. They solve practical problems that exist today. I 
think there are others associated with existing problems for sleeping devices 
and IoT devices that I need to research to more clearly answer your specific 
question but I think these two already fulfill that requirement.

Tom


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

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 10:11 AM, Joe Abley  wrote:
> 
> Hi Tom,
> 
>> On Aug 24, 2018, at 09:52, Tom Pusateri  wrote:
>> 
>>> If a zone is signed, are the TIMEOUT records signed?
>> 
>> No. The draft says they are skipped.
> 
> New RRTypes are supposed to be handled by old software that pre-dates them 
> because they can be treated as opaque types. That's not the case if new 
> RRTypes are encumbered with requirements for special handling at query or 
> signing time (as described in your section 2).
> 
> This seems like a significant architectural change that in effect updates 
> 1034 and 1035 as well as 3597. This would be a much more straightforward and 
> uncontroversial proposal if it was simply a specification for use of a new 
> RRType that made no changes at all to the rest of the protocol.
> 
> I have not read your draft in detail but I think you probably would also need 
> to spend more time considering the cases of old, non-TIMEOUT authority 
> servers that wind up serving zones that contain TIMEOUT RRSets (e.g. 
> third-party hosting services). Client handling of rogue RRSIGs, RCODE=NOERROR 
> with ANSWER sections containing TIMEOUT RRSets, etc.

Yes, the draft says the primary has to agree to send them to the secondary and 
the secondary has to agree to accept them (administratively). This prevents old 
authority servers from having to deal with them.

The position of not having them signed is a consequence of not having them 
returned in a query. If you can’t see them in a query, you can’t do 
NSEC/NSEC3/NSEC5 next record semantics so we skip them.

By simply making them returned in a query, we can avoid most of your 
objections. Mark Andrews suggested they not be returned in a query in a hallway 
discussion and I’m happy to change if that’s the preferred approach.

Thanks for the feedback!

Tom

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

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

> On Aug 24, 2018, at 9:11 AM, Ted Lemon  wrote:
> 
> On Aug 23, 2018, at 11:44 PM, Tom Pusateri  wrote:
>> An RRset isn’t granular enough because the components of the set could come 
>> from different clients with different timeout values.
>> Therefore, a unique identifier is needed for each record. The hash provides 
>> that unique identifier since it is calculated over the entire record 
>> including the unique RDATA.
> 
> The hash stuff seems like a premature optimization.   I can think of two 
> other ways to do this: either just send the contents of the RR, or use an 
> index into the RRset and define a sorting order.   Bearing in mind that 
> there's no reason for any server to store this data internally as anything 
> other than an additional tuple in the RR itself, hashes may be the least 
> efficient way to implement this.   Remember that for zone transfers, either 
> you transfer the whole zone, or you transfer the differences, and in either 
> case the zone contents for any zone serial number should always be the same.

We thought about sorting and indexing but that seemed way more error prone and 
not as general. The hash is a general solution that works well for these 
immediate uses and for any future uses that we can’t anticipate. It also 
provides the basis of a unique identifier that could be used for other 
non-related DNS extensions that need a unique identifier, so this code could be 
re-used. With the current libraries available, it’s not particularly 
complicated or onerous. 

> Another question to ask here is, what is the application for this?   If it's 
> just for DNSSD Registration, then it might be better to implement it in a 
> less general way.  It would be worth scoping this before saying that it has 
> to be done this way.   When Stuart and I talked about this, we had a much 
> simpler model in mind; your model is certainly more general, but who's the 
> customer?   I'm not saying your model is wrong, just that we ought to discuss 
> it explicitly.
> 

Yes, it was intended to be more general than for service registration. It’s 
directly applicable to name registration for IP addresses. I can add a section 
on other uses if more motivation is desired. Mark Andrews had some uses as well 
that hopefully, he can share. If others have uses in mind that this solves I 
would love to hear about them.

> If a zone is signed, are the TIMEOUT records signed?
> 

No. The draft says they are skipped.

Thanks,
Tom

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

I don’t think there is a TTL issue because, as we proposed it, the record is 
never returned in a query. The TTL could always be set to 0 for our purposes 
since it never leaves the authoritative servers.

Tom


> On Aug 23, 2018, at 11:44 PM, Tom Pusateri  wrote:
> 
> Paul,
> 
> Thanks for the feedback!
> 
> An RRset isn’t granular enough because the components of the set could come 
> from different clients with different timeout values.
> Therefore, a unique identifier is needed for each record. The hash provides 
> that unique identifier since it is calculated over the entire record 
> including the unique RDATA.
> 
> The contents of the TIMEOUT RDATA field are not encrypted. The list of hashes 
> are the list of unique identifiers. If each record had a unique identifier, 
> we could use that instead but because they don’t, we create one with the hash.
> 
> The ._TIMEOUT.FSI.IO idea is a neat one that we hadn’t thought of but it 
> isn’t unique to a record with a potentially different timeout value from a 
> different client and only works if all the members of the RRset have the same 
> timeout.
> 
> We’ll take a look at your TTL concern and your previous draft.
> 
> Thanks!
> 
> Tom
> 
> 
>> On Aug 23, 2018, at 9:23 PM, Paul Vixie  wrote:
>> 
>> tom, tim, thanks for this. i have two concerns, and three observations.
>> 
>> concern #1 is about this text:
>> 
>>>  3.  TIMEOUT resource records are not automatically sent in AXFR, IXFR
>>>  zone transfer requests.  Both primary and secondary servers
>>>  should be configured on a per zone basis to transfer TIMEOUT
>>>  resource records to ensure they are supported.
>> 
>> this is impractical given the high automation usually now involved in 
>> primary/secondary AXFR and IXFR relationships. i suggest negotiating for 
>> this with an OPT RR in the AXFR or IXFR request, indicating whether the 
>> initiator ("secondary" in this document) supports TIMEOUT or not.
>> 
>> concern #2:
>> 
>> you don't appear to have addressed TTL overrun here. it's necessary for a 
>> record which will expire to have a declining TTL as that expiry time nears. 
>> if it's always been 3600, then when you're within one hour of expiry time, 
>> returned TTL has to be reduced to whatever time remains.
>> 
>> observation #1:
>> 
>> none of the crypto seems nec'y. i would not quibble about it except that 
>> since it is crypto it will have to morph over time to become stronger 
>> against growing brute-force attacks and vuln research. this puts a 
>> maintainance burden on the community every time we encode crypto into a 
>> protocol. can you explain why the TIMEOUT RDATA isn't in clear text?
>> 
>> observation #2:
>> 
>> might you arrange for an _-related schema, so that each RRset having a 
>> TIMEOUT can have those records as a niece/nephew domain? for WWW.FSI.IO 
>> , the TIMEOUT would be at ._TIMEOUT.FSI.IO, in this case.
>> 
>> observation #3:
>> 
>> this was all considered previously. most recently it was the subject of an 
>> apple patent (EP1759516) by cheshire and sekar. first and foremost it was 
>> proposed in the old DNSIND working group by myself, in 1996. you don't have 
>> to worry about the patent, due to my prior art. since the draft is expired, 
>> i've put a copy online here:
>> 
>> http://family.redbarn.org/~vixie/defupd.txt
>> 
>> the IETF DNSIND WG rejected this draft on the basis of its complexity. the 
>> idea of a zone having timers inside it, for self-modification, was just a 
>> bridge too far at that time. given what is now called "the camel" i think 
>> pendulum has swung _well_ away from that point of view, but is now in the 
>> process of swinging back. if i had hope, i would submit DEFUPD again, 
>> exactly as it was in 1996, because it still deftly threads the needle posed 
>> by UPDATE. your needs may differ.
>> 
>> "good luck storming the castle, boys!" (_The Princess Bride_)
>> 
>> vixie
>> 
>> re:
>> 
>> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-00.txt
>> 
>> ___
>> 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] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

Paul,

Thanks for the feedback!

An RRset isn’t granular enough because the components of the set could come 
from different clients with different timeout values.
Therefore, a unique identifier is needed for each record. The hash provides 
that unique identifier since it is calculated over the entire record including 
the unique RDATA.

The contents of the TIMEOUT RDATA field are not encrypted. The list of hashes 
are the list of unique identifiers. If each record had a unique identifier, we 
could use that instead but because they don’t, we create one with the hash.

The ._TIMEOUT.FSI.IO idea is a neat one that we hadn’t thought of but it 
isn’t unique to a record with a potentially different timeout value from a 
different client and only works if all the members of the RRset have the same 
timeout.

We’ll take a look at your TTL concern and your previous draft.

Thanks!

Tom


> On Aug 23, 2018, at 9:23 PM, Paul Vixie  wrote:
> 
> tom, tim, thanks for this. i have two concerns, and three observations.
> 
> concern #1 is about this text:
> 
>>   3.  TIMEOUT resource records are not automatically sent in AXFR, IXFR
>>   zone transfer requests.  Both primary and secondary servers
>>   should be configured on a per zone basis to transfer TIMEOUT
>>   resource records to ensure they are supported.
> 
> this is impractical given the high automation usually now involved in 
> primary/secondary AXFR and IXFR relationships. i suggest negotiating for this 
> with an OPT RR in the AXFR or IXFR request, indicating whether the initiator 
> ("secondary" in this document) supports TIMEOUT or not.
> 
> concern #2:
> 
> you don't appear to have addressed TTL overrun here. it's necessary for a 
> record which will expire to have a declining TTL as that expiry time nears. 
> if it's always been 3600, then when you're within one hour of expiry time, 
> returned TTL has to be reduced to whatever time remains.
> 
> observation #1:
> 
> none of the crypto seems nec'y. i would not quibble about it except that 
> since it is crypto it will have to morph over time to become stronger against 
> growing brute-force attacks and vuln research. this puts a maintainance 
> burden on the community every time we encode crypto into a protocol. can you 
> explain why the TIMEOUT RDATA isn't in clear text?
> 
> observation #2:
> 
> might you arrange for an _-related schema, so that each RRset having a 
> TIMEOUT can have those records as a niece/nephew domain? for WWW.FSI.IO , 
> the TIMEOUT would be at ._TIMEOUT.FSI.IO, in this case.
> 
> observation #3:
> 
> this was all considered previously. most recently it was the subject of an 
> apple patent (EP1759516) by cheshire and sekar. first and foremost it was 
> proposed in the old DNSIND working group by myself, in 1996. you don't have 
> to worry about the patent, due to my prior art. since the draft is expired, 
> i've put a copy online here:
> 
> http://family.redbarn.org/~vixie/defupd.txt
> 
> the IETF DNSIND WG rejected this draft on the basis of its complexity. the 
> idea of a zone having timers inside it, for self-modification, was just a 
> bridge too far at that time. given what is now called "the camel" i think 
> pendulum has swung _well_ away from that point of view, but is now in the 
> process of swinging back. if i had hope, i would submit DEFUPD again, exactly 
> as it was in 1996, because it still deftly threads the needle posed by 
> UPDATE. your needs may differ.
> 
> "good luck storming the castle, boys!" (_The Princess Bride_)
> 
> vixie
> 
> re:
> 
> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-00.txt
> 
> ___
> 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] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Tom Pusateri]

This is a new draft for your review.

It is aimed at authoritative servers that handle DNS Update messages. It 
provides a way for the authoritative server to put a bounds on the lifetime of 
the added records and a way to share that lifetime with secondary servers.

If you run an Update server, we would love to have your feedback as to the 
usefulness of this new record type. If you maintain authoritative server 
software, we would love to have your feedback on whether this is something you 
would consider implementing or taking a pull request for.

Thanks,
Tom & Tim

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-pusateri-dnsop-update-timeout-00.txt
> Date: August 23, 2018 at 8:47:39 PM EDT
> To: "Tim Wattenberg" , "Tom Pusateri" 
> 
> 
> 
> A new version of I-D, draft-pusateri-dnsop-update-timeout-00.txt
> has been successfully submitted by Tom Pusateri and posted to the
> IETF repository.
> 
> Name: draft-pusateri-dnsop-update-timeout
> Revision: 00
> Title:DNS TIMEOUT Resource Record
> Document date:2018-08-23
> Group:Individual Submission
> Pages:10
> URL:
> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/
> Htmlized:   
> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout
> 
> 
> Abstract:
>   This specification defines a new DNS TIMEOUT resource record (RR)
>   that associates a lifetime with one or more zone resource records
>   with the same owner name and class.  It is intended to be used to
>   transfer resource record lifetime state between a zone's primary and
>   secondary servers and to store lifetime state during server software
>   restarts.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 21, 2018, at 3:30 PM, Paul Vixie  wrote:
> 
> this, joyfully, is a very good question.
> 
> Tom Pusateri wrote:
> 
>> Ok, so as Vladimír said, getting back to DHCP…
>> 
>> 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re
>> comfortable with DNS over UDP/53 as long as DNS Cookies are present
>> and using the existing DHCP DNS options 3. You seem happy with the
>> Android approach of just trying DoT with the IP address learned via
>> standard DHCP DNS options
>> 
>> Why do you care about additional DHCP options?
> 
> in my previous explaination as to the security model i follow, i noted that 
> the network paths to my dhcp server and my rdns servers were different, and 
> that in the dhcp case i have far more observability and control than in the 
> rdns case.
> 
> it should follow therefore that i do NOT want to use UDP/53 + Cookies unless 
> there is no alternative. DoT will be preferred. (DTLS or SCTP would be even 
> better, but i'm only picking from items now-on-menu.)

Since you can already do DoT today without an additional DHCP DNS option and 
adding that option will indisputably also come with a DoH URI option too, I 
would think you would be arguing against any new DHCP options for consistency.

Tom

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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 21, 2018, at 2:54 PM, Paul Vixie  wrote:
> 
> 
> 
> David Conrad wrote:
>> Vittorio,
>> 
>> ...
>> 
>> Perhaps I’m misunderstanding: are you saying the folks who provide
>> resolution services in a DoH world would have incentive to not follow
>> basic security measures?
> 
> noting that i am not vittorio, i will punch in as follows.
> 
> i do not expect CF to block resolution of its free-tier of CDN 
> pseudo-customers; if they thought those folks didn't deserve DNS, they would 
> probably think they didn't deserve CDN services either.
> 
> i block quite a few free-tier CF CDN pseudo-customers here, because that 
> service tier is widely abused. since the addresses associated with these 
> low-value pseudo-customers are shared by their paying customers, i can't 
> block them at the IP layer. so i block them using DNS RPZ. (i do not publish 
> this RPZ because in 1997 or so i got tired of lawsuits.)
> 
> anyhow, this is but one of many reasons why i don't want control-plane 
> information injected into my network, bypassing my security perimeter. while 
> CF is a special case, the general case is where my policies are aligned 
> somewhat differently than the user's policies or the content provider's 
> policies or the "public DoH" server operator's policies.
> 
> my network, my rules. one rule is, no bot-on-bot violence in my house.
> 
> -- 
> P Vixie

Ok, so as Vladimír said, getting back to DHCP…

1. You obviously don’t need a DoH URI option for DHCP.
2. You’re comfortable with DNS over UDP/53 as long as DNS Cookies are present 
and using the existing DHCP DNS options
3. You seem happy with the Android approach of just trying DoT with the IP 
address learned via standard DHCP DNS options

Why do you care about additional DHCP options?

Thanks,
Tom


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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 21, 2018, at 7:33 AM, Tony Finch  wrote:
> 
> Tom Pusateri  wrote:
> 
>> Come to think of it, DNSSEC validation in the stub resolver or browser
>> is really a place DoH could shine. Instead of all the round trips
>> required for validating up (down) the chain,
> 
> With DNS to a recursive server (UDP, TCP, or TLS) as currently deployed,
> you only need 1 round trip in simple cases or 2 round trips if there's a
> CNAME or SRV (etc.) because you know ahead of time all the queries you
> need to make to get the validation chain and they can trivially be
> pipelined.
> 
> Tony.

Yes, and with CHAIN Query Requests in DNS it’s even better. But this still 
can’t beat the fore knowledge the web/DoH server has about the page you’re 
viewing. The web/DoH server can HTTP/2 Push all of validation records for links 
you MAY click on in the future while you’re reading the page, taking into 
account the scroll position of your page. The validation can then be done in 
the browser before you click on the link and once you do, the browser knows the 
address and has validated it.

Tom


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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 21, 2018, at 3:30 AM, Marek Vavruša 
>  wrote:
> 
> On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček  <mailto:petr.spa...@nic.cz>> wrote:
>> On 21.8.2018 04:38, Tom Pusateri wrote:
>>> Come to think of it, DNSSEC validation in the stub resolver or browser
>>> is really a place DoH could shine. Instead of all the round trips
>>> required for validating up (down) the chain, the webserver could package
>>> up all those validated records and push them so the client/stub could do
>>> the validation quickly for all of the links in a page in an order that
>>> the user is most likely to need based on previous statistics and
>>> scrolling position.
>> 
>> Could you elaborate how DOH helps here? I can't see it now.
>> 
>> We already have RFC 7901 (Chain Query requests in DNS) which allows
>> resolvers to get all RRs required for DNSSEC validation in one round
>> trip even over "classic" DNS.
>> 
>> This haven't been implemented because up to know browser vendors have
>> not been interested in DNSSEC which consequently lead us (resolver
>> vendors) to ignore complex RFC with no demand.
>> 
>>> From my point of view DOH does not change anything in this regard,
>> complexity on stub & resolver side is the same no matter what transport
>> is used.
>> 
>> What am I missing? How does DOH help with this complexity when compared
>> to classical DNS?
> 
> I think Tom is referring to the h/2 push semantics. The resolver can
> push the trust chain records
> ahead of time, so the forwarder will already have them in cache when
> revalidating the final answer.

Yes, plus the fact that the web/DoH server already knows all of the questions 
you might ask because it just fed you a page of content with links.

The Chain Query Requests in DNS (RFC 7901) are awesome for the stub resolver. 
But the web/DoH server has more knowledge that the stub doesn’t have yet and so 
it can benefit from this knowledge in a way that the stub resolver can’t.

Tom



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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

Come to think of it, DNSSEC validation in the stub resolver or browser is 
really a place DoH could shine. Instead of all the round trips required for 
validating up (down) the chain, the webserver could package up all those 
validated records and push them so the client/stub could do the validation 
quickly for all of the links in a page in an order that the user is most likely 
to need based on previous statistics and scrolling position.

Tom

> On Aug 20, 2018, at 10:31 PM, Tom Pusateri  wrote:
> 
> Sure. My point was that there could be legitimate uses of DoH.
> 
> You have to move DNSSEC validation from the resolver to the client in order 
> to really validate the answers if you can’t trust the resolver.
> 
> Tom
> 
> 
>> On Aug 20, 2018, at 10:28 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>> 
>> Of course, the question is, how does the consumer of that data decide what 
>> is okay and what's not?   We can't just say that the server has to behave 
>> correctly: someone has to enforce it.
>> 
>> On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri > <mailto:pusat...@bangj.com>> wrote:
>> 
>> 
>> > On Aug 20, 2018, at 10:21 PM, Paul Vixie > > <mailto:p...@redbarn.org>> wrote:
>> > 
>> > 
>> > 
>> > Tom Pusateri wrote:
>> >> ... I don’t know if it’s generally accepted that DoH will replace
>> >> UDP/53 or DoT in the stub resolver or DoH will just end up in the
>> >> browsers as a way to speed up web pages. But if DoH stays in the
>> >> browser and DoT is tried and used on all DNS servers, there’s not a
>> >> problem to solve.
>> > 
>> > if DOH is widely used by criminals, botnets, and malware to bypass 
>> > perimeter security policy, then there will be a big problem and we will be 
>> > solving it for many years to come, even if the browser is the only thing 
>> > using it. browsers are where most modern vulns have occurred, and i expect 
>> > that trend to accelerate. "because that's where the money was.”
>> 
>> I can see good use cases and bad ones.
>> 
>> If web servers did DNSSEC validation and only served addresses for names 
>> that were validated, I wouldn’t have a problem with that at all.
>> 
>> If web servers only served addresses for names within the domain of the web 
>> server, I wouldn’t have a problem with that either.
>> 
>> if they start serving non DNSSEC validated addresses for names outside their 
>> domain, I think they’re overreaching.
>> 
>> Tom
>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> <https://www.ietf.org/mailman/listinfo/dnsop>
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

Sure. My point was that there could be legitimate uses of DoH.

You have to move DNSSEC validation from the resolver to the client in order to 
really validate the answers if you can’t trust the resolver.

Tom


> On Aug 20, 2018, at 10:28 PM, Ted Lemon  wrote:
> 
> Of course, the question is, how does the consumer of that data decide what is 
> okay and what's not?   We can't just say that the server has to behave 
> correctly: someone has to enforce it.
> 
> On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> 
> 
> > On Aug 20, 2018, at 10:21 PM, Paul Vixie  > <mailto:p...@redbarn.org>> wrote:
> > 
> > 
> > 
> > Tom Pusateri wrote:
> >> ... I don’t know if it’s generally accepted that DoH will replace
> >> UDP/53 or DoT in the stub resolver or DoH will just end up in the
> >> browsers as a way to speed up web pages. But if DoH stays in the
> >> browser and DoT is tried and used on all DNS servers, there’s not a
> >> problem to solve.
> > 
> > if DOH is widely used by criminals, botnets, and malware to bypass 
> > perimeter security policy, then there will be a big problem and we will be 
> > solving it for many years to come, even if the browser is the only thing 
> > using it. browsers are where most modern vulns have occurred, and i expect 
> > that trend to accelerate. "because that's where the money was.”
> 
> I can see good use cases and bad ones.
> 
> If web servers did DNSSEC validation and only served addresses for names that 
> were validated, I wouldn’t have a problem with that at all.
> 
> If web servers only served addresses for names within the domain of the web 
> server, I wouldn’t have a problem with that either.
> 
> if they start serving non DNSSEC validated addresses for names outside their 
> domain, I think they’re overreaching.
> 
> Tom
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop 
> <https://www.ietf.org/mailman/listinfo/dnsop>
> 

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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 20, 2018, at 10:21 PM, Paul Vixie  wrote:
> 
> 
> 
> Tom Pusateri wrote:
>> ... I don’t know if it’s generally accepted that DoH will replace
>> UDP/53 or DoT in the stub resolver or DoH will just end up in the
>> browsers as a way to speed up web pages. But if DoH stays in the
>> browser and DoT is tried and used on all DNS servers, there’s not a
>> problem to solve.
> 
> if DOH is widely used by criminals, botnets, and malware to bypass perimeter 
> security policy, then there will be a big problem and we will be solving it 
> for many years to come, even if the browser is the only thing using it. 
> browsers are where most modern vulns have occurred, and i expect that trend 
> to accelerate. "because that's where the money was.”

I can see good use cases and bad ones.

If web servers did DNSSEC validation and only served addresses for names that 
were validated, I wouldn’t have a problem with that at all.

If web servers only served addresses for names within the domain of the web 
server, I wouldn’t have a problem with that either.

if they start serving non DNSSEC validated addresses for names outside their 
domain, I think they’re overreaching.

Tom


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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 20, 2018, at 9:40 PM, Paul Ebersman  wrote:
> 
> pusateri> Another point I remember most clearly is that DHCP has fallen
> pusateri> out of favor for communicating all but the most minimal
> pusateri> network bootstrap configuration information. There was general
> pusateri> agreement in the room that you only should use DHCP in IPv4
> pusateri> for address/router info and then use trusted sources for
> pusateri> everything else. In IPv6, SLAAC generally provides this.
> 
> That may be the consensus at the IETF but it's not even close the
> consensus with ISPs, nor large enterprise. That seems to cover most of
> the eyeball/consumer... DHCP is still how much of the world gets
> connected and that hasn't changed in decades.
> 

You’re misquoting me and arguing against a point I didn’t make. There was no 
one saying we don’t need DHCP. There was a general agreement that DHCP should 
not be extended.

The DHC working group never completed the work for DHCP authentication. It’s 
not trustworthy enough in its current form to add more things to it.

> 
> Saying this is all broken and that we need to protect the world from
> themselves by not having a DHCP option simply means that vendors will
> have a slew of non-standard ways of doing it and we've helped noone.
> 
> Let's just give the option, document the security holes and risks and at
> least offer much of the world a standard way of doing this if they so
> choose.

Again, some better understanding of DoH deployment would help. I don’t know if 
it’s generally accepted that DoH will replace UDP/53 or DoT in the stub 
resolver or DoH will just end up in the browsers as a way to speed up web 
pages. But if DoH stays in the browser and DoT is tried and used on all DNS 
servers, there’s not a problem to solve.

Tom

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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 20, 2018, at 9:11 PM, Paul Hoffman  wrote:
> 
> On 20 Aug 2018, at 17:47, Tom Pusateri wrote:
> 
>>> On Aug 20, 2018, at 12:42 PM, Tony Finch  wrote:
>>> 
>>> Marek Vavruša  wrote:
>>>> 
>>>> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive..txt
>>> 
>>> This is interesting to me because I want to support DoTH on my campus
>>> resolvers.
>>> 
>>> Regarding DoH, the DHCP option ought to include a URI template (there
>>> isn't a .well-known for DoH). I plan to set up my servers so that
>>> misdirected attempts to get web pages from the DoH server are redirected
>>> to the relevant documentation; that's much easier if the DoH endpoint
>>> isn't at the server root.
>> 
>> Our variant of this same idea that Willem Toorop and I presented at the DRIU 
>> BOF in Montréal has a URI for the DoH case:
>> 
>> https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 
>> <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00><https://tools..ietf.org/html/draft-pusateri-dhc-dns-driu-00
>>  <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00>>
>> 
>> But let me remind everyone that there was a lot of people agreeing with Ted 
>> in Montréal and so far, Ted appears to be standing all by himself.
>> 
>> Where are all the other folks that shot down this idea earlier? :)
> 
> Judging what was said at an excited mic line is always challenging. :-) Two 
> issues are being conflated here:
> 1) a DHCP option to include a URI template
> 2) how the DHCP client in an OS would use that option
> 
> DHCP options are easy and cheap. However #2 was vexing. The proposal that an 
> OS say "oh look, there is a DoH server, I'll use that because it is more 
> secure than Do53" was what was controversial because of the utter lack of 
> DHCP security. Some of the folks on the mic line disagreed with the 
> assumption that, given two pieces of insecurely-acquired information (a Do53 
> address and a DoH template) that the latter would result with a more secure 
> connection. A network admin can see the port 53 traffic and see if there's 
> crap in there; they can't see the inner DoH traffic.
> 
> --Paul Hoffman

Yes, this was one good point.

Another point I remember most clearly is that DHCP has fallen out of favor for 
communicating all but the most minimal network bootstrap configuration 
information. There was general agreement in the room that you only should use 
DHCP in IPv4 for address/router info and then use trusted sources for 
everything else. In IPv6, SLAAC generally provides this.

One more point (from the Android crowd) was that they are going to try to 
connect to the DNS server’s IP address using port 853 using DoT at the same 
time they are trying to resolve names over port 53 with UDP. If they’re able to 
make a DoT connection, they’ll use it. This doesn’t provide for a way to have 
an ADN to verify the certificate but a PTR query can give you a name to do 
certificate validation and/or DANE validation. So they seemed to be making the 
point that no DHCP extensions were necessary.

Tom




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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 20, 2018, at 12:42 PM, Tony Finch  wrote:
> 
> Marek Vavruša  wrote:
>> 
>> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive..txt
> 
> This is interesting to me because I want to support DoTH on my campus
> resolvers.
> 
> Regarding DoH, the DHCP option ought to include a URI template (there
> isn't a .well-known for DoH). I plan to set up my servers so that
> misdirected attempts to get web pages from the DoH server are redirected
> to the relevant documentation; that's much easier if the DoH endpoint
> isn't at the server root.

Our variant of this same idea that Willem Toorop and I presented at the DRIU 
BOF in Montréal has a URI for the DoH case:

https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 


But let me remind everyone that there was a lot of people agreeing with Ted in 
Montréal and so far, Ted appears to be standing all by himself.

Where are all the other folks that shot down this idea earlier? :)

Thanks,
Tom


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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 19, 2018, at 9:29 AM, Livingood, Jason  
> wrote:
> 
> On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert"  on behalf of bert.hub...@powerdns.com> wrote:
>Especially when such a move will incidentally kill intranets, VPNs, split
>horizon, DNS monitoring & DNS malware detecion and blocking. 
> 
> It seems to me that the underlying protocol is separable from the operational 
> implementation, and the latter case is likely where most of the concerns lie. 
> Thus, the issue is likely less DoH itself but rather how it is likely to be 
> deployed.
> 
> I am considering starting work on a draft along the lines of 'potential 
> impacts of DoH deployment' to try to document some of this, if for nothing 
> else than to organize my own thinking on the matter. This is because I also 
> share concern, given the apparent deployment model, around what may break in 
> enterprise networks, malware detection & remediation, walled garden portals 
> during service provisioning, parental controls, and the impacts of 
> eliminating other local policies. The CDN-to-CDN competition case is an 
> interesting one as well, with respect to passing EDNS client subnet or not. 
> 
> JL

In the DRIU BOF, I mentioned establishing a reputation service for public DNS 
resolvers. With a JSON interface, this could lead to users conveying some trust 
of a public service or more likely, the inverse of trust for operating systems 
or stub resolvers to whitelist/blacklist public DNS resolvers.

I tried to summarize it here:

https://dnsdisco.com/reputation-post.html 


Or you could go listen to the proceedings of the DRIU BOF.

Thanks,
Tom


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

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Tom Pusateri]

> On Aug 18, 2018, at 8:53 PM, Marek Vavruša 
>  wrote:
> 
> On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon  <mailto:mel...@fugue.com>> wrote:
>> On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša 
>> wrote:
>>> 
>>>> You say that your proposal does not impact DoT's ability to address the
>>>> threat model or use case that is the reason it is being used.   But this
>>>> is
>>>> doesn't make sense to me.   The trust model for DoT and DoH right now is
>>>> that they are configured by the user for the user's reasons, or by the
>>>> service provider for the service provider's reasons.   You are proposing
>>> 
>>> This is the issue that the draft is trying to solve. The service
>>> provider doesn't have a way
>>> to configure DoT on the stub resolver. This problem is described in
>>> https://tools.ietf.org/html/rfc8310#section-6.7
>>> What I'm trying to address more specifically is
>>> https://tools.ietf.org/html/rfc8310#section-7.3
>> 
>> 
>> The document explicitly says that it doesn't have a trust model for DHCP.
>>> 
>>> 
>>> The "DHCP authentication" does exist, I believe you're referring the
>>> deployment status.
>> 
>> 
>> No, I'm referring to it doesn't exist.   There is no deployable DHCP
>> authentication.   The DHC working group tried to come up with one, and
>> ultimately concluded that it was not worth it, because the only thing that
>> should ever be trusted from a DHCP server is information about the local
>> network.   DoH and DoT are out of scope for DHCP according to this
>> reasoning.   Bear in mind that we were more optimistic about authentication
>> when we did RFC 3315.   RFC 8415, which is in AUTH48, and which supersedes
>> RFC3315, is not as optimistic, and only provides for authentication using
>> IPsec between server and relay, and authentication for the purpose of doing
>> Reconfigure; this authentication is not sufficient to provide assurances of
>> trustworthiness.   It's about as secure as a TCP sequence number.
>> 
>>> 
>>> I'm happy if we say the draft must depend on RFC3315, or discuss the
>>> trustworthiness of the responses,
>>> but surely there must be a way forward if we want to keep the
>>> recursive DNS (last mile) decentralized and free from tampering.
>> 
>> 
>> There is a way forward: seriously figure out the threat model.   Tom
>> Pusateri and another author already did a DHCP document; the reason we
>> didn't advance it is that we weren't able to come up with a threat model
>> where configuring DoT or DoH made sense.   Until someone does that, there is
>> no point in doing further work on a DHCP option.   If we do do further work
>> on a DHCP option, Tom's document is more complete than yours.
> 
> Can you share the link for the draft for a reference?
> 
> Marek

Marek,
I sympathize with your desire to deploy DNS over TLS. That was the 
motivation for Willem Toorop and I to go down this road and present it at 
Montréal IETF DRIU BOF. Ted challenged me as well but I didn’t understand his 
point before I presented our work. Ted gave an excellent rebuttal talk after 
mine that was very clear about how DHCP should really only be used to bootstrap 
configuration information enough to then talk to more trusted services due to 
lack of authentication and lack of trustworthiness when connecting to unknown 
networks.

You should first of all go listen to Teds talk (not a TED Talk) from the DRIU 
BOF. The video is here: https://www.youtube.com/watch?v=cfEX8zuoRAA 
<https://www.youtube.com/watch?v=cfEX8zuoRAA>
Ted’s talk starts at 33:18.

Willem and my draft is here:

https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 
<https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00>

My talks on threats and this draft are in the archives of the DRIU BOF and in 
the same video as Ted.

Aside from Ted, there was a strong consensus in the room to not adopt our 
draft. You can listen to the comments at the microphone for more information.

Thanks,
Tom





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

Re: [DNSOP] Moving forward with DNS Stateful Operations

[Tom Pusateri]

> On Aug 2, 2018, at 11:32 AM, Ted Lemon  wrote:
> 
> We got some really good review during the IESG last call process.   Thanks to 
> the IESG members (bcc) who read the document thoroughly and gave so many 
> thoughtful comments.
> 
> I believe that we have addressed all of the comments that were made during 
> the review adequately.  However, this hasn't been thoroughly reviewed; we 
> should do a thorough review of these changes.   In order to facilitate that, 
> I've submitted a -14 (on top of last night's -13), so the diffs to look at 
> are between -12 and -14, not, e.g., just -13 and -14.   You can get the diffs 
> here: 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-14&url1=draft-ietf-dnsop-session-signal-12
>  
> 
> 
> Note that because I added an applicability section, all of the IESG comments 
> about sections after 4 are off by one.
> 
>  The one remaining nit is that at least two and possibly three of the ADs 
> commented that the terminology section has a lot of normative language in it 
> and generally talks a lot about things that are really specification, not 
> terminology.
> 
> I responded to this by saying that we'd discussed this as a group, agreed it 
> wasn't great, and decided it was more work to fix than it was worth.   
> However, at the moment I actually have a lot of state on this document in my 
> head, and I think I could fix this without it being too much work or 
> introducing errors.   But doing so would impose extra workload at least on 
> the authors, and maybe on the working group, to review the changes I make and 
> make sure I don't screw something up.
> 
> Is there appetite for doing this?   I think it would significantly improve 
> the document, but I am mindful of the expense.

I could go either way on this. I don’t mind doing another review if others 
think this is worthwhile but I also don’t think it’s a problem as is.

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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Tom Pusateri]

Ted,
Those clarifications look good.

Thanks,
Tom


> On Aug 2, 2018, at 10:53 AM, Ted Lemon  wrote:
> 
> On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk  > wrote:
> > We specifically didn’t want to reference DoH since HTTP is unsuitable for 
> > long lived connections and DSO wouldn’t apply here. We didn’t want to imply 
> > that DoH was suitable by referencing it.
> 
> Hmm.  I think DoH is clearly a non-UDP transport for DNS, and it is hard to
> argue that it is not being specified.  My parenthetical suggestion was
> probably a bit unclear -- I was proposing to add DNS over HTTP to the list
> in the first sentence, and change the second sentence to start as "Some
> such transports can offer persistent[...]".  Does that still seem like it
> runs the risk of implying that DoH is suitable, to you?
> 
> Rr.   Okay, I agree with you and when I went to do this, it occurred to me 
> that we are being silly here—this document has no applicability section.   
> Adding one will really clean this up a lot.   So I've done that:
> 
> @@ -106,9 +106,11 @@ This document updates RFC 1035 by adding a new DNS 
> header opcode and result code
>  
>  # Introduction
>  
> -The use of transports for DNS other than UDP is being increasingly specified,
> -for example, DNS over TCP {{!RFC1035}} {{!RFC7766}} and DNS over TLS 
> {{?RFC7858}}.
> -Such transports can offer persistent, long-lived sessions and therefore when
> +This document specifies a mechanism for managing stateful DNS connections.
> +DNS most commonly operates over a UDP transport, but can also operate over
> +streaming transports; the original DNS RFC specifies DNS over TCP 
> {{!RFC1035}}
> +and a profile for DNS over TLS {{?RFC7858}} has been specified.
> +These transports can offer persistent, long-lived sessions and therefore when
>  using them for transporting DNS messages it is of benefit to have a mechanism
>  that can establish parameters associated with those sessions, such as 
> timeouts.
>  In such situations it is also advantageous to support server-initiated 
> messages
> @@ -399,43 +401,40 @@ and to assure client and server that they still have 
> connectivity to each other.
>  
>  ***
>  
> +# Applicability {#applicability}
> +
> +DNS Stateful Operations are applicable in cases where it is useful to 
> maintain an open session
> +between a DNS client and server, where the transport allows such a session 
> to be maintained, and
> +where the transport guarantees in-order delivery of messages, on which DSO 
> depends.  Examples of
> +transports that can support session signaling are DNS-over-TCP {{?RFC1035}} 
> {{?RFC7766}} and
> +DNS-over-TLS {{?RFC7858}}.
> +
> +Note that in the case of DNS over TLS, there is no mechanism for upgrading 
> from DNS-over-TCP
> +to DNS-over-TLS (see {{?RFC7858}} section 7).
> +
> +DNS Stateful Operations are not applicable for transports that cannot 
> support clean session
> +semantics, or that do not guarantee in-order delivery.   While in principle 
> such a transport
> +could be constructed over UDP, the current DNS specification over UDP 
> transport {{RFC1035}}
> +does not provide in-order delivery or session semantics, and hence cannot be 
> used..  Similarly,
> +DNS-over-HTTP {{?I-D.ietf-doh-dns-over-https}} cannot be used because HTTP 
> has its own
> +mechanism for managing sessions, and this is incompatible with the mechanism 
> specified here.
> +
> +No other transports are currently defined for use with DNS Stateful 
> Operations.  Such transports
> +can be added in the future, if they meet the requirements set out in the 
> first paragraph of this
> +section.
> +
>  # Protocol Details {#details}
>  
>  ## DSO Session Establishment {#establishment}
>  
> -DSO messages MUST NOT be carried in protocols and
> -environments where a session can't be established.   For example,
> -DNS over plain UDP {{?RFC0768}} is not appropriate since it does not provide
> -in-order message delivery, and, in the presence of NAT gateways and firewalls
> -with short UDP timeouts, it cannot provide a persistent bi-directional
> -communication channel unless an excessive amount of DSO keepalive traffic is 
> used.
> -UDP also doesn't provide a way to mark the start of a session and the end
> -of a session.
> -
> -At the time of publication, DSO is specified only
> -for DNS over TCP {{!RFC1035}} {{!RFC7766}}, and
> -for DNS over TLS over TCP {{?RFC7858}}.
> -Any use of DSO over some other connection technology needs to be
> -specified in an appropriate future document.
> -
> -Determining whether a given connection is using DNS over TCP, or DNS
> -over TLS over TCP, is outside the scope of this specification, and
> -must be determined using some out-of-band configuration information.
> -There is no provision within the DSO specification to
> -turn TLS on or off during the lifetime of a connection.
> -For service types where the service instance is discovered
> -using a DNS SRV record {{?RFC2782}},
> -th

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Tom Pusateri]

> On Jul 31, 2018, at 3:53 PM, Tom Pusateri  wrote:
> 
>> 
>>   If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
>>   ([TBA2] tentatively 11), then the client MUST assume that the server
>>   does not implement DSO at all.  In this case the client is permitted
>>   to continue sending DNS messages on that connection, but the client
>>   SHOULD NOT issue further DSO messages on that connection.
>> 
>> I'm confused how the server would still have proper framing for subsequent
>> DNS messages, since the DSO TLVs would be "spurious extra data" after a
>> request header and potentially subject to misinterpretation as the start of
>> another DNS message header.
> 
> Yes, this is a serious oversight. I think we are going to need to encode 
> differently to make all the TLVs look like an RR externally so the RDLEN can 
> be used to skip them and add a single count or switch the TLV syntax back to 
> RR syntax. The existing DNS header format / RR format is less than ideal...
> 

My co-authors reminded me about the TCP framing for DNS which gives the length 
of the DNS message so it can easily be skipped so this isn’t a problem.

Thanks,
Tom

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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Tom Pusateri]

> On Jul 27, 2018, at 11:24 AM, Benjamin Kaduk  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-session-signal-12: 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-session-signal/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Hopefully this first point is simple to resolve (whether by changing text or 
> merely
> un-confusing me).  The other ones may require some actual discussion,
> though.
> 
> Section 6.6.1.2 has:
> 
>   After a DSO Session is ended by the server (either by sending the
>   client a Retry Delay message, or by forcibly aborting the underlying
>   transport connection) the client SHOULD try to reconnect, to that
>   service instance, or to another suitable service instance, if more
>   than one is available.
> 
> which seems to contradict the text from Section 3:
> 
> %  [...] Given that these fatal error
> %  conditions signify defective software, and given that defective
> %  software is likely to remain defective for some time until it is
> %  fixed, after forcibly aborting a connection, a client SHOULD refrain
> %  from automatically reconnecting to that same service instance for at
> %  least one hour.
> 
> Given some other mentions in the document about aborting the connection, it
> may be that I am just reading the "refrain from reconnecting for an hour"
> more strongly than I should be.

Section 3 discusses fatal errors on the server side that aren’t likely to 
change until the software is modified so there’s no use having the client retry 
quickly (hence the one hour). Section 6.6.1.2 is about receiving a Retry Delay 
message and the server having the close the connection because the client 
didn’t follow the spec and close the connection when asked.

I think the difference can be described as Section 3 talks about how the client 
deals with server bugs and Section 6.6.1.2 describes how the server deals with 
client bugs.

Does that help?

> 
> Is Section 5.1.2 expected to be considered an "application protocol
> profile" that defines the use of TLS 1.3 0-RTT data for DSO?  (If so, I do
> not personally feel that it provides adequate treatment to be considered as
> such.)
> 
> 
> I should probably leave this to my (transport-area?) colleagues to discuss
> further, but I'm not sure that the interaction of this mechanism with
> high-RTT connections is fully covered -- for example, the inactivity
> timeout in Section 6.4(.x) could behave poorly when the timeout is set to a
> smaller value than the RTT, as the server would potentially end up starting
> the "forcibly abort" process (and potentially causing the client to lose
> for an hour) because the server's timer starts when it sends the DSO
> response that initiates its idea of the session, and would not recieve
> graceful shutdown messages from a properly-behaving client in time.
> 

The 0 RTT discussion is also happening in another thread so I will not address 
it here.

> 
> I'm not sure that the behavior specified in Section 7.1.2 is entirely safe.
> Consider when a client sends a DSO keepalive to try to request a DSO
> session, but subsequently sends EDNS(0) TCP Keepalive (whether "just in
> case" or for some other reason).  The Server will receive the DSO keepalive
> and respond, creating a session, but the EDNS(0) TCP Keepalive is already
> in flight.  I don't remember seeing any text that prevents this client
> behavior explicitly, but that seems like the right sort of thing to do.

Ok, is this more clear?

The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has similar 
intent to the edns-tcp-keepalive EDNS0 Option [RFC7828] 
.
 A client/server pair that supports DSO MUST NOT use the edns-tcp-keepalive 
EDNS0 Option within any message after a DSO Session has been established. A 
client that has sent a DSO message to establish a session MUST NOT send an 
edns-tcp-keepalive EDNS0 Option from this point on. Once a DSO Session has been 
established, if either client or server receives a DNS message over the DSO 
Session that contains an edns-tcp-keepalive EDNS0 Option, this is a fatal error 
and the receiver of the edns-tcp-keepalive EDNS0 Option MUST forcibly abort the 
connection immediately.

> 
> 
> --
> COMMENT:
> --
> 
> Six authors exceeds five, so "there is likely to be discussion" about this
> b

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 21, 2018, at 1:40 PM, Shumon Huque  wrote:
> 
> On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
>> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát > <mailto:vladimir.cunat+i...@nic.cz>> wrote:
>> 
>> On 06/20/2018 04:59 PM, Tom Pusateri wrote:
>>> DNSSEC will tell you the answer you get is correct but it could be a > to a 
>>> different question or be incomplete.
>> Can you elaborate on that point.  I believe in signed zones you are able
>> to verify almost everything, in particular existence of the queried-for
>> RRset and its exact value, except for details like current TTL.
>> 
>> --Vladimir
>> 
> 
> I’ve been thinking about the case when you are given a DNS recursive resolver 
> over DHCP and you don’t necessarily trust it.
> 
> SIG(0) can't really protect you from an untrustworthy resolver. It can ensure 
> that the question you sent and the answer you got back from the recursive 
> server was not tampered with in-flight. But it can't detect whether the 
> recursive server modified any data in its response before it signed it with 
> SIG(0). If the response contained DNSSEC signed data and the stub was 
> validating, then those pieces of the response could be authenticated. But not 
> anything in the header, question etc - all of that could have been modified 
> by the recursive server without detection.
>  
> If you send a query with the DO bit set to a recursive resolver for the A 
> record for foo.example.com <http://foo.example.com/> and the recursive 
> resolver modifies this query to foo.exampl.com <http://foo.exampl.com/>, you 
> can get back a validated DNSSEC response with the A record answer, RRSIG, 
> NSEC(3) records all for the wrong question. The resolver code in the OS or 
> application would get back the matching DNS header identifier and if it 
> lazily just grabbed the A record answer without comparing the RR name, it 
> could be misled. You can detect this without SIG(0) so maybe that was a bad 
> example. But if you always sent a SIG(0) signed question and got a signed 
> answer, you could detect this and possibly other future attacks and drop it 
> before even parsing the answers.
> 
> Most competent resolvers will check that the response that they got back was 
> for the question they asked. So I don't think they would "lazily just grab 
> the A record answer without comparing the RR name".
> 
> I don't think SIG(0) really helps much here. The response signature has to 
> include the entire query message, but the actual response can contain 
> anything the recursive server puts in there.
>  
> In the case of missing answers, I was thinking that if there were multiple A 
> records in the response and some were filtered, you could not detect this 
> without a SIG(0) signed response from the authoritative server. This would be 
> important if one server was compromised and the recursive resolver filtered 
> the response to exclude the other A records pointing to servers that weren’t 
> compromised directing you to the compromised server.
> 
> DNSSEC is really the solution to this problem. DNSSEC signatures cover the 
> entire RRset, so authoritative (or recursive) servers cannot strip away some 
> of the RRs without detection by a downstream validator.
> 
> Shumon.
> 

Thanks. In the case where a zone isn’t signed but the authoritative server 
supports SIG(0), the response could be verified that it includes exactly what 
the server sent. But the KEY would need to be DNSSEC validated or it probably 
can’t be trusted to verify the SIG(0) response.

Tom


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

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát  
> wrote:
> 
> On 06/20/2018 04:59 PM, Tom Pusateri wrote:
>> DNSSEC will tell you the answer you get is correct but it could be a > to a 
>> different question or be incomplete.
> Can you elaborate on that point.  I believe in signed zones you are able
> to verify almost everything, in particular existence of the queried-for
> RRset and its exact value, except for details like current TTL.
> 
> --Vladimir
> 

I’ve been thinking about the case when you are given a DNS recursive resolver 
over DHCP and you don’t necessarily trust it.

If you send a query with the DO bit set to a recursive resolver for the A 
record for foo.example.com <http://foo.example.com/> and the recursive resolver 
modifies this query to foo.exampl.com <http://foo.exampl.com/>, you can get 
back a validated DNSSEC response with the A record answer, RRSIG, NSEC(3) 
records all for the wrong question. The resolver code in the OS or application 
would get back the matching DNS header identifier and if it lazily just grabbed 
the A record answer without comparing the RR name, it could be misled. You can 
detect this without SIG(0) so maybe that was a bad example. But if you always 
sent a SIG(0) signed question and got a signed answer, you could detect this 
and possibly other future attacks and drop it before even parsing the answers.

In the case of missing answers, I was thinking that if there were multiple A 
records in the response and some were filtered, you could not detect this 
without a SIG(0) signed response from the authoritative server. This would be 
important if one server was compromised and the recursive resolver filtered the 
response to exclude the other A records pointing to servers that weren’t 
compromised directing you to the compromised server.

If I’m wrong about the second case, then I concede.

Thanks,
Tom



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

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 20, 2018, at 3:23 PM, Shane Kerr  wrote:
> 
> Ondřej,
> 
> Ondřej Surý:
>> as far as I could find on the Internet there are only SIG(0) implementation 
>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I 
>> haven’t found; no mentions of real deployment was found over the Internet 
>> (but you can blame Google for that)...
>> 
>> Do people think the SIG(0) is something that we should keep in DNS and it 
>> will be used in the future or it is a good candidate for throwing off the 
>> boat?
> 
> My guess is that any time you ask this working group if a feature is
> important in DNS, the answer will be "yes", even if not a single system
> is using it anywhere on the Internet and beyond.
> 
> I wonder if there is any metric that dnsop would agree on to determine
> whether a DNS feature is useful or not?
> 
> Cheers,
> 
> —
> Shane

To be fair, he asked if it would be used in the future and that’s hard to 
measure. But given that the community hasn’t concentrated on security as much 
in the past as it will in the future, it seems that throwing security measures 
off the boat is premature.

Tom

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

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 19, 2018, at 4:48 PM, Ondřej Surý  wrote:
> 
> 
> Do people think the SIG(0) is something that we should keep in DNS and it 
> will be used in the future or it is a good candidate for throwing off the 
> boat?
> 
> Ondrej

As far as I can tell, SIG(0) is the only mechanism in DNS to ensure the 
question you asked is being answered as well as ensuring that all of the 
responses from the server are included.

DNSSEC will tell you the answer you get is correct but it could be a to a 
different question or be incomplete.

This would seem to be an important tool in the toolbox as we move forward into 
more private and secure DNS.

Tom


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

Re: [DNSOP] Fwd: Last Call: (DNS Stateful Operations) to Proposed Standard

[Tom Pusateri]

> On Jun 12, 2018, at 10:28 AM, Job Snijders  wrote:
> 
> Dear Ted,
> 
> On Tue, Jun 12, 2018 at 3:09 PM, Ted Lemon  wrote:
>> Yes.   I'm using it right now to implement draft-ietf-dnssd-mdns-relay, and
>> that implementation is working and interoperating.   I don't know of another
>> independent implementation yet, unfortunately.
> 
> Can you elaborate a bit more? What is the name of the implementation?
> This is an implementation in progress? I don't fully understand how
> there can be interoperating if there is no other implementation.
> 
> I see roughly 150 (!) BCP14  keywords in this draft. Can you specify
> for your implementation for each of these normative keywords whether
> your implementation is complaint, or not, and if not why not?
> 
> Kind regards,
> 
> Job

I did an initial implementation of a client and server for DNS push 
notifications which is based on Stateful Operations. This code isn’t public and 
I haven’t looked at it for about 6 months. But it did identify some issues 
early on in the draft that we corrected for.

Thanks,
Tom


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-10.txt

[Tom Pusateri]

> On Jun 7, 2018, at 1:56 PM, Bob Harold  wrote:
> 
> 
> On Thu, Jun 7, 2018 at 1:43 PM Tom Pusateri  <mailto:pusat...@bangj.com>> wrote:
> This updated version adds some minor changes requested by Warren including 
> anycast clarifcation, a new RFC reference, and IANA helpers.
> 
> Tom
> 
> Minor nit:
> 
> In the added paragraph, the line:
> "If after the connection is, the client's assumption"
> 
> Needs another word, like 'resumed' or 'recreated' or such:
> "If after the connection is recreated, the client's assumption"
>  
> -- 
> Bob Harold

Thanks! Fixed on github. We’ll wait for more feedback from the review process 
to submit a new version.

Tom

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-10.txt

[Tom Pusateri]

This updated version adds some minor changes requested by Warren including 
anycast clarifcation, a new RFC reference, and IANA helpers.

Tom


> On Jun 7, 2018, at 1:38 PM, 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   : DNS Stateful Operations
>Authors : Ray Bellis
>  Stuart Cheshire
>  John Dickinson
>  Sara Dickinson
>  Ted Lemon
>  Tom Pusateri
>   Filename: draft-ietf-dnsop-session-signal-10.txt
>   Pages   : 53
>   Date: 2018-06-07
> 
> Abstract:
>   This document defines a new DNS OPCODE for DNS Stateful Operations
>   (DSO).  DSO messages communicate operations within persistent
>   stateful sessions, using type-length-value (TLV) syntax.  Three TLVs
>   are defined that manage session timeouts, termination, and encryption
>   padding, and a framework is defined for extensions to enable new
>   stateful operations.  This document updates RFC 1035 by adding a new
>   DNS header opcode and result code which has different message
>   semantics.  This document updates RFC 7766 by redefining a session,
>   providing new guidance on connection re-use, and providing a new
>   mechanism for handling session idle timeouts.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-10
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] AD review of draft-ietf-dnsop-session-signal

[Tom Pusateri]

I made all of these suggested changes on github except for the Section 3 “same 
server instance” pandora’s box.

The authors can discuss how they want to change this one or leave it for later.

If I don’t hear anything in a day or two, I’ll push out another version.

Thanks,
Tom


> On Jun 2, 2018, at 11:08 AM, Warren Kumari  wrote:
> 
> Hi there,
> 
> Thank you for writing this document, I found it clear and well written. 
> 
> I do have a few comments that I’d like addressed before I start IETF LC — 
> addressing these now will avoid issues later in the process.
> The majority of these are nits, but one is more of a (very easily addressed) 
> substantive / editorial / process issue.
> 
> Firstly the "substantive" issue:
> Throughout the document you say things like:
> "This document defines a new DNS OPCODE, DSO (tentatively 6),..."
> 
> Can you please go through and change this to something like ([TBA1], 
> tentatively 6)?
> I realize that that isn't quite as readable for "normal" reading, but this is 
> sufficiently close to the end of the process that the IANA will read it soon 
> and I don't want any occurrences to be missed. An exmaple of where this could 
> have been an issue is in the table on page 16. If some number other than 11 
> were assigned for DSOTYPENI it might not get caught here.
> Sorry for the process wonkery.
> 
> 
> Nits / questions:
> Section 3.  Terminology
> 1: "The term has no relationship to the "session layer" of the OSI 
> "seven-layer model" popularized in the 1980s."
>  -- I don't really get the purpose of the phrase "popularized in the 1980s." 
> - it feels like it breaks the flow and feels like it will simply distract 
> people into side arguments about if it was the 80's or 90's when this was 
> "popularized". Note that this is truly a minor nit.
> 
> Section 3.  Terminology
> 2: "This document uses the term "same server instance" as follows:
> o  In cases where a server is specified or configured using an IP
> address and TCP port number, two different configurations are
> referring to the same server instance if they contain the same IP
> address and TCP port number."
> 
> Because you opened this Pandora's box -- in many Anycast deployments this 
> isn't really true -- if you make a TCP connection to linkedin.com 
>  on port 80 (or 8.8.8.8 on 53) you are likely to hit 
> the same "server instance" for a while, but at some point routing will change 
> and you may hit some completely other location (and server). In many cases 
> this will be sticky over long timeframes (a good slidedeck is the 
> https://www.slideshare.net/shawnzandi/how-linkedin-used-tcp-anycast-to-make-the-site-faster
>  
> 
>  ). Anyway, since you mention IP:PORT-> "same server instance" you might want 
> to toss in some weasel words that the protocol does deal with this case (by 
> falling over and reconnecting).
> 
> "The term "long-lived operations" refers to operations such as Push
> Notification subscriptions [I-D.ietf-dnssd-push], Discovery Relay
> interface subscriptions [I-D.ietf-dnssd-mdns-relay], and other future
> long-lived DNS operations that choose to use DSO as their basis, that
> establish state that persists beyond the lifetime of a traditional
> brief request/response transaction."
> This sentence is somewhat hard to read - I *think* the repeated use of "that" 
> in "... that choose to use DSO as their basis, that establish.." is part of 
> the issue. Not sure if it can be simplified?
> 
> 
> "Section 5.1.3.  Middlebox Considerations"
> The second paragraph of this section makes me slightly uncomfortable. I 
> understand why it is here, but the tone of it sounds supportive of DSO-aware 
> middleboxes being created. This might just be my personal bias (and so feel 
> free to ignore it), but I'd think that on the whole we'd prefer that 
> middleboxes don't monkey with DSO traffic. If they *do*, definitely there 
> should be advice on how not to get it wrong, but the tone of this sounds more 
> supportive / permissive than I (personally) would have expected.
> 
> Section 5.2.2.  DSO Data
> "Similarly, after an mDNS Relay client..."
> I think that this is the first use of mDNS - please expand the acronym.
> 
> Section 5.4.  DSO Response Generation
> "Possible mitigations for this problem include:..."
> This doesn't mention the mitigation of "just padding the packet until it is a 
> full sized segment". While anti-social, it is a mitigation (trading increased 
> bandwidth for performance).
> 
> 
> Having now finished writing these up, I realize that while I'd *prefer* a new 
> version before starting IETF LC, I'm also fine with kicking it off with the 
> current text and the (minor) fixes can be addressed after IETF LC / with the 
> RFC Ed.
> 
> Please let me know how you'd like to proceed.
> W

___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-08.txt

[Tom Pusateri]

> On May 16, 2018, at 4:44 PM, 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   : DNS Stateful Operations
>Authors : Ray Bellis
>  Stuart Cheshire
>  John Dickinson
>  Sara Dickinson
>  Ted Lemon
>  Tom Pusateri
>   Filename: draft-ietf-dnsop-session-signal-08.txt
>   Pages   : 53
>   Date: 2018-05-16
> 
> Abstract:
>   This document defines a new DNS OPCODE for DNS Stateful Operations
>   (DSO).  DSO messages communicate operations within persistent
>   stateful sessions, using type-length-value (TLV) syntax.  Three TLVs
>   are defined that manage session timeouts, termination, and encryption
>   padding, and a framework is defined for extensions to enable new
>   stateful operations.  This document updates RFC 1035 by adding a new
>   DNS header opcode and result code which has different message
>   semantics.  This document updates RFC 7766 by redefining a session,
>   providing new guidance on connection re-use, and providing a new
>   mechanism for handling session idle timeouts.
> 

This update contains minor changes in response to the ID nits checking tool at 
the request of the chair.

Thanks,
Tom


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

Re: [DNSOP] Complexity and innovation in the DNS protocol: the work of DNSOP

[Tom Pusateri]

> On Apr 18, 2018, at 5:07 PM, Suzanne Woolf  wrote:
> 
> Hi,
> 
> The chairs have been discussing next steps after IETF 101, particularly the 
> very lively WG input on the complexity and stability of the DNS protocol.
> 
> There are many aspects to the questions that came up. Some are not going to 
> be resolved within the IETF or the standards process, but it sounds to us 
> like there are things the IETF and DNSOP can do that could improve the 
> situation.
> 
> We heard significant support in the WG for slowing down on adoption of new 
> work, with more attention by the chairs and in WG discussion for a couple of 
> factors:
> 
> First, what's the applicability of this work? what problem does it solve, and 
> for whom?
> 
> Second, does this work add significantly to the complexity of the DNS 
> protocol, or the work of implementers and operators?
> 
> Finally, what implementation experience exists with the technology?
> 
> We're not trying to create unnecessary barriers to new work; previous 
> generations of DNS working groups have arguably tried to preserve stability 
> of the protocol at the expense of innovation, with the result that people 
> simply proceeded to innovate outside of the standards process.
> 
> However, we want to see these issues discussed as part of WG consideration 
> for adoption of new work in the future, and will explicitly consider them 
> when deciding whether new work has adequate support to advance in the working 
> group.
> 

I have only been in the DNS community for a few years but spent many years in 
the IETF community in routing before that.

My experience is that the DNS protocol with all of it’s new submissions and 
feature proposals is not very complex in comparison to routing.

I am not in favor of slowing innovation or slowing the adoption of new work. I 
think each submitted proposal should stand on it’s own merits and we should be 
able to have discussions about each proposal to decide if it’s a benefit to the 
community without fear of being sidelined or slow-tracked.

Thanks,
Tom


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

[Tom Pusateri]

> On Aug 18, 2017, at 11:12 AM, Petr Špaček  wrote:
> 
> We can certainly call TLVs "extension" but renaming it does not remove
> the fundamental problem:
> TLVs are largely incompatible with the code we already have widely
> implemented and deployed everywhere in all the DNS implementations and
> tools. As a consequence, it is increasing engineering cost for all
> involved parties.
> 

There were two main reasons we chose to use TLVs instead of the EDNS(0) RR 
format for Session Signaling (soon to be called DNS Stateful Operations) and it 
was quite intentional:

1. Given the fact that we were using a new Opcode, we had the opportunity to 
change the packet format for the better (at the suggestion of Mark Andrews). 
There has been a lot of people in DNSOP saying EDNS(0) OPT RRs were a mistake. 
To be fair, some people like it or are agnostic but we’ve heard more complaints 
than support. Using a new Opcode created an unusual and infrequent opportunity 
to switch to TLVs without a backlash since all the code would be doing new 
things.

2. Since EDNS(0) is per packet and not per session, and Session Signaling is 
defined per session over a reliable, ordered transport, we think it will be 
less confusing and simpler for implementors to have separate code to deal with 
session semantics over the existing per packet datagram semantics that don’t 
mean the same thing.

* When I say we, I am saying what I understand to be the consensus of the 
authors. I don’t mean to speak directly for the other authors and I will let 
them correct me if there is disagreement that I am not aware of.

Thanks,
Tom


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