Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones

[Geoff Huston]

Hi Paul,


> On 15 Dec 2017, at 12:51 pm, Paul Hoffman  wrote:
> 
> Please see . 
> This is a small set of changes that make the draft not treat the root zone as 
> special. It allows the labels to be used for any zone, not just the root.
> 

Could you please elaborate on the motivation here? I am unsure whether this is 
needed, or, perhaps more critically, I’m unsure if this represents a harmless 
general form of information disclosure (that the resolver is using local trust 
keys for some unspecified non-root zone).

I agree the mechanics of the change in the text, and even in the code for 
support this are pretty minor, but I am slightly worried about the intended 
generality of the proposed change being a small step too far, so I am curious 
to understand why you are advocating this change.

regards,

   Geoff


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

Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain

[George Michaelson]

yes. this is good.

-G

On Fri, Dec 15, 2017 at 12:30 PM,   wrote:
> Thanks.
>
> Adding a example as a text is a little complicated.
>
> Adding examples as a table is good ? or too large ?
>
> Delegation  | Parent | Name Server Name   | Type
> | Zone   ||
> +++--
> com | .  | a.gtld-servers.net | in-bailiwick / sibling domain
> net | .  | a.gtld-servers.net | in-bailiwick / in-domain
> example.org | org| ns.example.org | in-bailiwick / in-domain
> example.org | org| ns.ietf.org| in-bailiwick / sibling domain
> example.org | org| ns.example.com | out-of-bailiwick
> example.jp  | jp | ns.example.jp  | in-bailiwick / in-domain
> example.jp  | jp | ns.example.ne.jp   | in-bailiwick / sibling domain
> example.jp  | jp | ns.example.com | out-of-bailiwick
>
> --
> Kazunori Fujiwara, JPRS 
>
>> From: George Michaelson 
>> feels like a concrete example in a.b.c.example.com terms would help
>> define both in-baliwick, and out-of-baliwick, for the cases.
>>
>> On Wed, Dec 13, 2017 at 9:42 PM,   wrote:
>>> Thanks.
>>>
>>> terminology-bis-08:
>>> | In-bailiwick: An adjective to describe a name server whose name is
>>> |either subordinate to or (rarely) the same as the zone origin.
>>>
>>> Ok, In-bailwick in terminology-bis-08 may be restrictive because "the
>>> zone origin" is unclear. I intended that "the zone origin" is the zone
>>> origin of parent zone. The sentence needs more words.
>>>
>>> NEW
>>>
>>>   In-bailiwick: An adjective to describe a name server whose name is
>>>either subordinate to or (rarely) the same as the origin
>>>of the zone that contains the delegation to the name server.
>>>
>>> ... bad english text ... please fix.
>>>
>>> --
>>> Kazunori Fujiwara, JPRS 
>>>
 From: Mark Andrews 
 The text for "in-bailwick" is too restrictive, it doesn’t just cover NS 
 records or
 glue records.

 In-bailwick refers to records that in the normal course of DNS resolution
 would have been requested of by the server the current response is from.
 e.g. if you are querying a .com server then all records in the response 
 that end
 with .com are in-bailwick.

 Mark

> On 5 Dec 2017, at 5:27 am, Paul Hoffman  wrote:
>
> Greetings again.
>
> Some of the new terms added to the terminology-bis draft 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since 
> RFC 7719 can be a bit tricky. This week, we hope you will look at the 
> definitions in the draft for:
> - In-bailiwick
> - Out-of-bailiwick
> - In-domain
> - Sibling domain
> Please review these terms and comment on the list if you think the 
> definitions should change.
>
> --Paul Hoffman
>
> [[ As a reminder, we asked the following last week, but got no reply: For 
> the past many versions of the terminology-bis draft 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), 
> Section 2 has definitions of "Global DNS" and "Private DNS", based on the 
> facets listed in "Naming system". This was discussed heavily on the list 
> earlier, but it is also a pretty big change, so we want to be sure that 
> it is what the WG wants. Please review these terms and comment on the 
> list if you think the definitions should change. ]]
>
> ___
> 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 mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>

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

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

[Michael StJohns]

Below is a java program I wrote to model this stuff.  In the table, SF2 
represents the number of clients that blew past twice the safety factor 
(for aR+aHD+aR), SF1 represents the number of clients that blew past the 
single safety factor.  OF is the number of clients using the 
activeRefreshOffset calculation that finished after the calculated 
interval (e.g. aR+aHD+aRO).  OF+s is the number of clients that finished 
after the activeRefreshOffset + safetyFactor (in the first table these 
are the same because of perfect responses).   In the second table, 
compare SF1 to OF+s - SF1 < OF+s suggesting that activeRefresh is a 
better choice that activeRefreshQuery for the third term of the 
equation.  You can try a lot of different combinations, but I haven't 
found any case where OF+s performs better that SF1.


The difference between lastStart and lAddHoldBegin represents the 
retransmits after the first query.  The differences between lAddHoldEnd 
and lFinalQuery represent retransmits after the last normal query before 
the end of the add hold down time until a valid answer was received 
after the addHoldDown time expired.


Feel free to twiddle with this.

In this table, almost 1/5th of each of the clients exceeds the 
activeRefreshOffset based calculation. Note that the safety factor 
doesn't come into play as this specifies a "0" query failure rate.

java Test5011
Original TTL? (enter dd:hh:mm:ss) 1:4:0:0
New TTL? (enter dd:hh:mm:ss) 1:4:0:0
RRSig expiration interval? (enter dd:hh:mm:ss) 7:0:0:0

Orig TTL: 100800 seconds
New TTL: 100800 seconds
RRSig interval: 604800 seconds
QueryInterval: 50400 seconds
FastQuery: 8640 seconds
AddHoldDown: 2592000 seconds
ActiveRefreshOffset: 21600 seconds
activeRefresh + addHoldDown + activeRefresh: 2692800

Number of trials(-1 to exit) 10
Number of clients(-1 to exit) 25000
Failure rate [0 to .9](-1 to exit) 0
Calculated safety factor: 0 (0.00)
aR + aHD + aR + sF: 2692800

Offset calc - aR + aHD + aRO: 2664000
Offset plus safety: 2664000

Trial  LastStart  lAddHoldBegin lAddHoldEnd  sOffset lFinalQuery SF2 
SF1  OF  OF+s

---
0  50394  50394 2671194   28800 2671194    0    
0    3459  3459
1  50399  50399 2671199   28800 2671199    0    
0    3576  3576
2  50399  50399 2671199   28800 2671199    0    
0    3540  3540
3  50399  50399 2671199   28800 2671199    0    
0    3508  3508
4  50399  50399 2671199   28800 2671199    0    
0    3610  3610
5  50399  50399 2671199   28800 2671199    0    
0    3544  3544
6  50398  50398 2671198   28800 2671198    0    
0    3546  3546
7  50399  50399 2671199   28800 2671199    0    
0    3611  3611
8  50398  50398 2671198   28800 2671198    0    
0    3579  3579
9  50398  50398 2671198   28800 2671198    0    
0    3517  3517







$ !-2
java Test5011
Original TTL? (enter dd:hh:mm:ss) 1:0:0:0
New TTL? (enter dd:hh:mm:ss) 1:0:0:0
RRSig expiration interval? (enter dd:hh:mm:ss) 7:0:0:0

Orig TTL: 86400 seconds
New TTL: 86400 seconds
RRSig interval: 604800 seconds
QueryInterval: 43200 seconds
FastQuery: 8640 seconds
AddHoldDown: 2592000 seconds
ActiveRefreshOffset: 0 seconds
activeRefresh + addHoldDown + activeRefresh: 2678400

Number of trials(-1 to exit) 10
Number of clients(-1 to exit) 10
Failure rate [0 to .9](-1 to exit) .25
Calculated safety factor: 77760 (9.00)
aR + aHD + aR + sF: 2756160

Offset calc - aR + aHD + aRO: 2635200
Offset plus safety: 2712960

Trial  LastStart  lAddHoldBegin lAddHoldEnd  sOffset lFinalQuery SF2 
SF1  OF  OF+s

---
0  43199  108405    2769525   0 2769525    0    1    
54772 31
1  43198  95039 2729831   0 2753326    0    0    
55168 26
2  43199  111816    2725266   0 2740462    0    0    
54697 44
3  43199  90159 2736412   0 2745052    0    0    
54882 31
4  43199  100917    2727795   0 2729947    0    0    
54869 33
5  43199  94115 2726425   0 2740485    0    0    
54978 23
6  43199  117523    2735443   0 2743990    0    0    
55306 27
7  43198  101417    2734743   0 2743383    0    0    
55006 29
8  43199  94634 2728554   0 2747760    0    0    
54943 36
9  43199  85218 2727853   0 2737153    0    0    
55070 33




import java.io.*;
import java.security.SecureRandom;

public class Test5011 {


  static  BufferedReader in = new BufferedReader(new InputStreamReader 
(System.in));




  public static void main (String[] args)
    throws Exception {

    int ttl = getResponse("Original TTL");
    int newTTL = getResponse ("New TTL");
    int rrsigExpi

Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain

[fujiwara]

Thanks.

Adding a example as a text is a little complicated.

Adding examples as a table is good ? or too large ?

Delegation  | Parent | Name Server Name   | Type
| Zone   ||
+++--
com | .  | a.gtld-servers.net | in-bailiwick / sibling domain
net | .  | a.gtld-servers.net | in-bailiwick / in-domain
example.org | org| ns.example.org | in-bailiwick / in-domain
example.org | org| ns.ietf.org| in-bailiwick / sibling domain
example.org | org| ns.example.com | out-of-bailiwick
example.jp  | jp | ns.example.jp  | in-bailiwick / in-domain
example.jp  | jp | ns.example.ne.jp   | in-bailiwick / sibling domain
example.jp  | jp | ns.example.com | out-of-bailiwick

--
Kazunori Fujiwara, JPRS 

> From: George Michaelson 
> feels like a concrete example in a.b.c.example.com terms would help
> define both in-baliwick, and out-of-baliwick, for the cases.
> 
> On Wed, Dec 13, 2017 at 9:42 PM,   wrote:
>> Thanks.
>>
>> terminology-bis-08:
>> | In-bailiwick: An adjective to describe a name server whose name is
>> |either subordinate to or (rarely) the same as the zone origin.
>>
>> Ok, In-bailwick in terminology-bis-08 may be restrictive because "the
>> zone origin" is unclear. I intended that "the zone origin" is the zone
>> origin of parent zone. The sentence needs more words.
>>
>> NEW
>>
>>   In-bailiwick: An adjective to describe a name server whose name is
>>either subordinate to or (rarely) the same as the origin
>>of the zone that contains the delegation to the name server.
>>
>> ... bad english text ... please fix.
>>
>> --
>> Kazunori Fujiwara, JPRS 
>>
>>> From: Mark Andrews 
>>> The text for "in-bailwick" is too restrictive, it doesn’t just cover NS 
>>> records or
>>> glue records.
>>>
>>> In-bailwick refers to records that in the normal course of DNS resolution
>>> would have been requested of by the server the current response is from.
>>> e.g. if you are querying a .com server then all records in the response 
>>> that end
>>> with .com are in-bailwick.
>>>
>>> Mark
>>>
 On 5 Dec 2017, at 5:27 am, Paul Hoffman  wrote:

 Greetings again.

 Some of the new terms added to the terminology-bis draft 
 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since 
 RFC 7719 can be a bit tricky. This week, we hope you will look at the 
 definitions in the draft for:
 - In-bailiwick
 - Out-of-bailiwick
 - In-domain
 - Sibling domain
 Please review these terms and comment on the list if you think the 
 definitions should change.

 --Paul Hoffman

 [[ As a reminder, we asked the following last week, but got no reply: For 
 the past many versions of the terminology-bis draft 
 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), 
 Section 2 has definitions of "Global DNS" and "Private DNS", based on the 
 facets listed in "Naming system". This was discussed heavily on the list 
 earlier, but it is also a pretty big change, so we want to be sure that it 
 is what the WG wants. Please review these terms and comment on the list if 
 you think the definitions should change. ]]

 ___
 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 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] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones

[Paul Hoffman]

Please see 
. This is a 
small set of changes that make the draft not treat the root zone as 
special. It allows the labels to be used for any zone, not just the 
root.


--Paul Hoffman

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

Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

[Paul Vixie]

Robert Edmonds wrote:

Or, put another way, we like existing resolver implementations just
fine, we just wish there were a lot more resolver instances, and closer
to clients:-)


on it. no smiley.

--
P Vixie

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

Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

[Robert Edmonds]

bert hubert wrote:
> On Wed, Dec 13, 2017 at 05:36:32PM +0800, zuop...@cnnic.cn wrote:
> >  so far as i know, many CDNs already use similar methods as you mentioned 
> > in PowerDNS 4.1.1 
> >  but  i think only the  Authoritative Server change is not enough,  support 
> > on the recursive server is also very important .
> >   because the resolver determines the reponse to clients.
> 
> This is true.  A typical resolver will serve around 50,000 to 2,000,000
> users (although this is rare). This means that for 60 seconds, you shift
> around 'a hundred thousand' potential users. 
> 
> In practice, this appears to be good enough from what I hear.
> 
> Or let me put it another way, before we burden the DNS protocol with another
> record type we have to add downgrade/workaround/DNSSEC support for, we
> should have numbers that say it solves a problem.
> 
> CDNs could maybe chime in.

Hi,

With my CDN hat on, I don't see any need to turn over scheduling
decisions to resolvers. Extremely precise amounts of traffic can already
be scheduled to individual CDN nodes because you have a large pool of
owner names to work with, not a single owner name, and every (QNAME,
QTYPE, resolver IP, client subnet [if present], anycast location that
receives the query) tuple is an opportunity to make a unique scheduling
choice. Generally, however, assignments to CDN nodes should be
relatively sticky. You want to be shifting traffic for performance
reasons, not capacity reasons.

Or, put another way, we like existing resolver implementations just
fine, we just wish there were a lot more resolver instances, and closer
to clients :-)

-- 
Robert Edmonds

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

Re: [DNSOP] CLIENT-SUBNET bis appetite?

[Warren Kumari]

On Thu, Dec 14, 2017 at 12:39 PM, Mukund Sivaraman  wrote:
> Any appetite for it? Don't throw things at me.. I ask because the
> current thing is slowly getting more widely deployed and there are
> design issues that can do with a ECS2 that breaks from ECS1 protocol. I
> ask because I'm once again having to deal with myriad implementation
> cases and dislike it.
>


As I'm sure you know / remember, getting the first version though was
quite a slog. I suspect that, seeing as there seems to be good support
for the initial version, getting a new one done will be much simpler,
but the obvious question is:
How would ECS2 differ, and how would it interact with ECS1 / backward
compatibility?

W


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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] CLIENT-SUBNET bis appetite?

[bert hubert]

On Thu, Dec 14, 2017 at 11:09:13PM +0530, Mukund Sivaraman wrote:
> Any appetite for it? Don't throw things at me.. I ask because the
> current thing is slowly getting more widely deployed and there are
> design issues that can do with a ECS2 that breaks from ECS1 protocol. I
> ask because I'm once again having to deal with myriad implementation
> cases and dislike it.

Could you elaborate what you dislike most? The biggest thing we are noticing
is that while it does great things to getting to a server the content
provider likes, it unavoidably drives doen cache hitrates a lot, introducing
a latency penalty.

The operators we see deploying ECS have tens of thousands of subnets
which all need to be mapped to only a few servers. But you still end up
with tens of thousands of cache entries and therefore tiny cache hitrates.

Such things could be addressed by answering with lists of subnet masks to
which this answer would also apply, but this makes little sense
operationally I think. 

Can you share your ideas for ECS2?

Bert

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

[DNSOP] CLIENT-SUBNET bis appetite?

[Mukund Sivaraman]

Any appetite for it? Don't throw things at me.. I ask because the
current thing is slowly getting more widely deployed and there are
design issues that can do with a ECS2 that breaks from ECS1 protocol. I
ask because I'm once again having to deal with myriad implementation
cases and dislike it.

Mukund

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