Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Wes Hardaker]

Mark Andrews  writes:

> > Yes, and that's where I see a problem: when the software doesn't know
> > the agreement has been severed.
> 
> Presumably you won’t get back a server tag and you can log that.

No you may get back a server tag, and you're equally as likely to
misinterpret it just as the server misinterpreted your client tag.
Sure, *sometimes* (many times even) it will cause a parse error.  It's
the cases that don't cause parse errors that concern me.  What if the
client and server *think* they understand each other, but actually are
doing very different things because one side of the "agreement" is no
longer acting the same way.

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Christopher Morrow]

On Mon, Mar 4, 2019 at 11:00 PM Paul Wouters  wrote:

> On Tue, 5 Mar 2019, Mark Andrews wrote:
>
> >> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> >>> can I ask, what happens when a domain is intentionally down though? For
> >>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> >>> master/shadow NS go down, hard. All public auth servers eventually (in
> a
> >>> day or so) went dark too.
>
> "If the recursive server is unable to contact the
>   authoritative servers for a query "
>
> So make the DNS server reachable, but return ServFail or NXDOMAIN. If
> the owner doesn't cooperate and there is legal standing, talk to the
> parent to do this for the delegation.
>
>
this wasn't, near as I could tell, an option for the ccTLD in question.
They lost their IP access, and were 'required' to disable their dns zone,
their master was down hard from the internet's perspective,
keeping anything else up wasn't really an option.

I don't know how long it takes to get ICANN to 'do something creative' for
the root zone, but I'm guessing this isn't always feasible in normal
timelines (hours to a day or so).


> I don't think this draft stops a domain from being brought down
> intentionally.
>
>
i think it prolongs the data being available in a bunch of the cases I can
imagine/have-seen.
I think there's at least one case where it's likely grave harm could have
come to the dns operator. :(

I think what the draft does is attempt to guess at WHY a thing is changed,
without an real data to back up the reasoning. this will mean the decision
is wrong more than a small percent of the time.


> >> i already raised that question, very far up-thread. got no answer.
> >>
> >>> If someone is 'ordered' to make a zone dark, there may be reasons for
> that
> >>> action, and real penalties if the request is not honored.
> >>> Is this draft suggesting that the DNS operations folk go against the
> wishes
> >>> of the domain owner by keeping a domain alive after the auth servers
> have
> >>> become unreachable? How would a recursive resolver know that the auth
> is
> >>> down: "By mistake" vs: "By design" ?
>
> The DNS resolvers who want to accomodate their governments need to
> manually override their resolvers anyway with new (forged) data. This
> draft does not change that.
>
> If the owner itself wants to bring the domain down, they just need to
> make its auth servers reachable.
>
>
sometimes that's not possible :( and the expectation is that 'when the
right ttl sets expire all of our records disappear as you requested"


> If the DNS hoster wants to bring it down, they just need to modify the
> data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records.
>

this is also not always possible :(


>
> I don't think the "4 years" is a realistic problem case.
>
>
is the '4 years' here in reference to the .eg problem?
in my example the '4 yrs' was: "when the incident happened" not "please
keep my dns alive for 4 yrs without talking to me"


> I can see how people want to get a few hours or a few days of usage
> beyond the TTL to accomodate for errors. Although, it is likely that
> moving up the error this way will also delay the error from being
> detected before the extra time has expired, and we are just moving
> the goal post with no effective gain. But in the case of a DDOS
> attack, the draft's feature is surely useful.
>
>
seems unlikely to be useful... even in the case of dos...really.
(to me anyway)

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Mark Andrews]

> On 5 Mar 2019, at 2:59 pm, Paul Wouters  wrote:
> 
> On Tue, 5 Mar 2019, Mark Andrews wrote:
> 
>>> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
 can I ask, what happens when a domain is intentionally down though? For
 instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
 master/shadow NS go down, hard. All public auth servers eventually (in a
 day or so) went dark too.
> 
>   "If the recursive server is unable to contact the
> authoritative servers for a query "
> 
> So make the DNS server reachable, but return ServFail or NXDOMAIN. If
> the owner doesn't cooperate and there is legal standing, talk to the
> parent to do this for the delegation.
> 
> I don't think this draft stops a domain from being brought down
> intentionally.
> 
>>> i already raised that question, very far up-thread. got no answer.
>>> 
 If someone is 'ordered' to make a zone dark, there may be reasons for that
 action, and real penalties if the request is not honored.
 Is this draft suggesting that the DNS operations folk go against the wishes
 of the domain owner by keeping a domain alive after the auth servers have
 become unreachable? How would a recursive resolver know that the auth is
 down: "By mistake" vs: "By design" ?
> 
> The DNS resolvers who want to accomodate their governments need to
> manually override their resolvers anyway with new (forged) data. This
> draft does not change that.
> 
> If the owner itself wants to bring the domain down, they just need to
> make its auth servers reachable.
> 
> If the DNS hoster wants to bring it down, they just need to modify the
> data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records.
> 
>>> this the essence of the argument against utility for this entire proposal. 
>>> no
>>> data should be served beyond its TTL unless some new leasing protocol is 
>>> first
>>> defined, to obtain permission and to provide a cache invalidation method.
> 
> I don't really follow this reasoning. Are you saying that:
> 1) if the domain owner wants their domain to be reachable
> 2) and they have lost their auth servers due to a DDOS attack
> 3) they might prefer to be down over extending the TTL a bit
> 
> In the non-DDOS case, the auth server is reachable and none of the data
> is getting additional TTL added:
> 
>   Answers from authoritative servers that have a DNS Response Code of
>   either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have
>   refreshed the data at the resolver.  In particular, this means that
>   this method is not meant to protect against operator error at the
>   authoritative server that turns a name that is intended to be valid
>   into one that is non-existent, because there is no way for a resolver
>   to know intent.
> 
> Although perhaps it should also explicitely state this regarding
> ServFail ?
> 
>> And one can to that if we add 2 TTLs to each DNS record. One for total time 
>> to
>> live and one for freshness (old client get this).  It will require EDNS to 
>> signal
>> that multiple TTLs are desired and are present in the response and may 
>> require
>> using the last DNS flag bit to move the OPT record to in front of the 
>> question
>> section to make parsing easier (no trial and error).
>> 
>> Yes, this is radical but it will work and is incrementally deployable.
> 
> See above. It seems a bit overkill for a strange corner case. But even
> so, one could specify the maximum ever allowed TTL to be like 3 days? Which
> I think is kind of enforced by most DNS resolvers anyway?
> 
> Adding more TTLs would just make this more complicated and more error
> prone and not lead to reduced outage times which is the goal of this
> draft.

For those with long existing TTLs it would allow them to refresh the records
earlier allowing them to exist in caches longer during the DoS event.

For those with short existing TTLs it would allow them to control how long
the records exist past reachability of the DNS servers.  Most of the time
short lived TTLs are there “just in case we need to change them" or they
are doing short term load balancing between a set of servers which are
actually at stable addresses.  This would allow those functions to continue
but keep the addresses in caches longer under error conditions.

> I don't think the "4 years" is a realistic problem case.
> 
> I can see how people want to get a few hours or a few days of usage
> beyond the TTL to accomodate for errors. Although, it is likely that
> moving up the error this way will also delay the error from being
> detected before the extra time has expired, and we are just moving
> the goal post with no effective gain. But in the case of a DDOS
> attack, the draft's feature is surely useful.

Monitoring will detect problems.

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

-- 
Mark Andrews, ISC
1 Seymour 

Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Paul Wouters]

On Tue, 5 Mar 2019, Paul Hoffman wrote:


This makes me very nervous. An edge ISP DNS server could use this to
mark DNS packets from certain users, and applications could use this as
another cookie to track users, especially in light of endusers talking
directly to open resolvers like the Quads, from within the application,
bypassing the operating system.


As the draft says, they can already do this now with unassigned EDNS0 code 
points. There is nothing you can do about it.


We can not facilitate those practises by not giving these practises a
code point ?


There are known cases where bespoke implementations are using experimental EDNS 
option values for this purpose, for example for a front-end load-balancer to 
tell the server whether an incoming connection arrived over TCP or UDP (c.f. my 
XPF draft).


Great. And once experimenting is done, submit a draft and get a real
EDNS code point. Do this as many times as you want. The idea of a
limited experimental space is that you cannot rely on it to be rolled
out into the wild word. That's a feature.


Or a bug. IETF WGs cannot agree on which it is. Some WGs cannot remember which 
they prefer from year-to-year.


Well, it seems we have a registry for EDNS code points with
experimental/local code points. So I'm not sure how your
comment relates to this or other WGs?


A goal of this draft is to assign a common EDNS code-point such that popular 
OSS implementations can support similar features interoperably.


I would much rather see 10 specfic EDNS code points for features, than a
kitchen sink EDNS option that can be abused to send potentially
dangerous tracking identifiers that we cannot distinguish from actual
DNS infrastructure options.


That's a fine preference, but it does not align with the reality that anyone 
can already do that. Not having a standard doesn't prevent abuse.


Sure, but facilitating those general purpose meta-camels is also not required 
action of the WG or implementers.

Paul

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Paul Wouters]

On Tue, 5 Mar 2019, Mark Andrews wrote:


On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:

can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
master/shadow NS go down, hard. All public auth servers eventually (in a
day or so) went dark too.


"If the recursive server is unable to contact the
 authoritative servers for a query "

So make the DNS server reachable, but return ServFail or NXDOMAIN. If
the owner doesn't cooperate and there is legal standing, talk to the
parent to do this for the delegation.

I don't think this draft stops a domain from being brought down
intentionally.


i already raised that question, very far up-thread. got no answer.


If someone is 'ordered' to make a zone dark, there may be reasons for that
action, and real penalties if the request is not honored.
Is this draft suggesting that the DNS operations folk go against the wishes
of the domain owner by keeping a domain alive after the auth servers have
become unreachable? How would a recursive resolver know that the auth is
down: "By mistake" vs: "By design" ?


The DNS resolvers who want to accomodate their governments need to
manually override their resolvers anyway with new (forged) data. This
draft does not change that.

If the owner itself wants to bring the domain down, they just need to
make its auth servers reachable.

If the DNS hoster wants to bring it down, they just need to modify the
data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records.


this the essence of the argument against utility for this entire proposal. no
data should be served beyond its TTL unless some new leasing protocol is first
defined, to obtain permission and to provide a cache invalidation method.


I don't really follow this reasoning. Are you saying that:
1) if the domain owner wants their domain to be reachable
2) and they have lost their auth servers due to a DDOS attack
3) they might prefer to be down over extending the TTL a bit

In the non-DDOS case, the auth server is reachable and none of the data
is getting additional TTL added:

   Answers from authoritative servers that have a DNS Response Code of
   either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have
   refreshed the data at the resolver.  In particular, this means that
   this method is not meant to protect against operator error at the
   authoritative server that turns a name that is intended to be valid
   into one that is non-existent, because there is no way for a resolver
   to know intent.

Although perhaps it should also explicitely state this regarding
ServFail ?


And one can to that if we add 2 TTLs to each DNS record. One for total time to
live and one for freshness (old client get this).  It will require EDNS to 
signal
that multiple TTLs are desired and are present in the response and may require
using the last DNS flag bit to move the OPT record to in front of the question
section to make parsing easier (no trial and error).

Yes, this is radical but it will work and is incrementally deployable.


See above. It seems a bit overkill for a strange corner case. But even
so, one could specify the maximum ever allowed TTL to be like 3 days? Which
I think is kind of enforced by most DNS resolvers anyway?

Adding more TTLs would just make this more complicated and more error
prone and not lead to reduced outage times which is the goal of this
draft.

I don't think the "4 years" is a realistic problem case.

I can see how people want to get a few hours or a few days of usage
beyond the TTL to accomodate for errors. Although, it is likely that
moving up the error this way will also delay the error from being
detected before the extra time has expired, and we are just moving
the goal post with no effective gain. But in the case of a DDOS
attack, the draft's feature is surely useful.

Paul

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Mark Andrews]

> On 5 Mar 2019, at 1:26 pm, Paul Vixie  wrote:
> 
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
>> can I ask, what happens when a domain is intentionally down though? For
>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
>> master/shadow NS go down, hard. All public auth servers eventually (in a
>> day or so) went dark too.
> 
> i already raised that question, very far up-thread. got no answer.
> 
>> If someone is 'ordered' to make a zone dark, there may be reasons for that
>> action, and real penalties if the request is not honored.
>> Is this draft suggesting that the DNS operations folk go against the wishes
>> of the domain owner by keeping a domain alive after the auth servers have
>> become unreachable? How would a recursive resolver know that the auth is
>> down: "By mistake" vs: "By design" ?
> 
> this the essence of the argument against utility for this entire proposal. no 
> data should be served beyond its TTL unless some new leasing protocol is 
> first 
> defined, to obtain permission and to provide a cache invalidation method.
> 
> vixie

And one can to that if we add 2 TTLs to each DNS record. One for total time to
live and one for freshness (old client get this).  It will require EDNS to 
signal
that multiple TTLs are desired and are present in the response and may require
using the last DNS flag bit to move the OPT record to in front of the question
section to make parsing easier (no trial and error).

Yes, this is radical but it will work and is incrementally deployable.

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

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

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Christopher Morrow]

On Mon, Mar 4, 2019 at 9:26 PM Paul Vixie  wrote:

> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> > can I ask, what happens when a domain is intentionally down though? For
> > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> > master/shadow NS go down, hard. All public auth servers eventually (in a
> > day or so) went dark too.
>
> i already raised that question, very far up-thread. got no answer.
>
>
apologies for repeat-asking :( whoops! It'd still be good to hear an answer.
I can think of simple product and not 'life safety' reasons that I might
darken a zone as well, so if you don't want to answer for an abundance of
caution for your fellow folken... think of the product marketing folk who
mistakenly launch a day early, or who would like to retire a service in a
clearly delineated manner.

:)

> If someone is 'ordered' to make a zone dark, there may be reasons for that
> > action, and real penalties if the request is not honored.
> > Is this draft suggesting that the DNS operations folk go against the
> wishes
> > of the domain owner by keeping a domain alive after the auth servers have
> > become unreachable? How would a recursive resolver know that the auth is
> > down: "By mistake" vs: "By design" ?
>
> this the essence of the argument against utility for this entire proposal.
> no
> data should be served beyond its TTL unless some new leasing protocol is
> first
> defined, to obtain permission and to provide a cache invalidation method.
>

this is what I was thinking as well. thanks for more clarity.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Paul Vixie]

On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> can I ask, what happens when a domain is intentionally down though? For
> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> master/shadow NS go down, hard. All public auth servers eventually (in a
> day or so) went dark too.

i already raised that question, very far up-thread. got no answer.

> If someone is 'ordered' to make a zone dark, there may be reasons for that
> action, and real penalties if the request is not honored.
> Is this draft suggesting that the DNS operations folk go against the wishes
> of the domain owner by keeping a domain alive after the auth servers have
> become unreachable? How would a recursive resolver know that the auth is
> down: "By mistake" vs: "By design" ?

this the essence of the argument against utility for this entire proposal. no 
data should be served beyond its TTL unless some new leasing protocol is first 
defined, to obtain permission and to provide a cache invalidation method.

vixie


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Christopher Morrow]

can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
master/shadow NS go down, hard. All public auth servers eventually (in a
day or so) went dark too.

If someone is 'ordered' to make a zone dark, there may be reasons for that
action, and real penalties if the request is not honored.
Is this draft suggesting that the DNS operations folk go against the wishes
of the domain owner by keeping a domain alive after the auth servers have
become unreachable? How would a recursive resolver know that the auth is
down: "By mistake" vs: "By design" ?

-chris


On Mon, Mar 4, 2019 at 6:25 PM Puneet Sood  wrote:

> Tim, Paul,
>
> Thanks for the feedback. Working on clarifying the recommendations.
>
> -Puneet
>
> On Sun, Mar 3, 2019 at 8:34 PM Tim Wicinski  wrote:
>
>> "Proposal: Put all recommendations in Section 4, and talk about them
>> (instead of introducing them) in the other sections. That way, a lazy
>> developer who only reads Section 4 will know all the recommendations."
>>
>> I totally agree here.  It also makes it easier if the document passed
>> WGLC and moves along the standards process train.
>>
>
>> Tim
>>
>>
>> On Fri, Mar 1, 2019 at 2:51 PM Paul Hoffman 
>> wrote:
>>
>>> Following up on my previous message:
>>>
>>> The document is actively confusing about recommendations.
>>>
>>> - Section 4 has the actual update to the RFC 1035, and that update
>>> contains MAY and SHOULD statements.
>>>
>>> - Section 5 is called "Example Method" but also contains recommendations.
>>>
>>> - Section 6, "Implementation Caveats" also has recommendations. A
>>> subsection, "6.1. Implementation Considerations" has more recommendations.
>>>
>>> Proposal: Put all recommendations in Section 4, and talk about them
>>> (instead of introducing them) in the other sections. That way, a lazy
>>> developer who only reads Section 4 will know all the recommendations.
>>>
>>> --Paul Hoffman
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> 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] [Ext] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Paul Hoffman]

On Mar 4, 2019, at 5:44 PM, Paul Wouters  wrote:
> 
> On Mon, 4 Mar 2019, Ray Bellis wrote:
> 
>> This new draft describes a way for clients and servers to exchange a limited 
>> amount of information where the semantics of that information are completely 
>> unspecified, and therefore determined by bi-lateral agreement between the 
>> client and server operators.
> 
> This makes me very nervous. An edge ISP DNS server could use this to
> mark DNS packets from certain users, and applications could use this as
> another cookie to track users, especially in light of endusers talking
> directly to open resolvers like the Quads, from within the application,
> bypassing the operating system.

As the draft says, they can already do this now with unassigned EDNS0 code 
points. There is nothing you can do about it.

>> There are known cases where bespoke implementations are using experimental 
>> EDNS option values for this purpose, for example for a front-end 
>> load-balancer to tell the server whether an incoming connection arrived over 
>> TCP or UDP (c.f. my XPF draft).
> 
> Great. And once experimenting is done, submit a draft and get a real
> EDNS code point. Do this as many times as you want. The idea of a
> limited experimental space is that you cannot rely on it to be rolled
> out into the wild word. That's a feature.

Or a bug. IETF WGs cannot agree on which it is. Some WGs cannot remember which 
they prefer from year-to-year.

>> A goal of this draft is to assign a common EDNS code-point such that popular 
>> OSS implementations can support similar features interoperably.
> 
> I would much rather see 10 specfic EDNS code points for features, than a
> kitchen sink EDNS option that can be abused to send potentially
> dangerous tracking identifiers that we cannot distinguish from actual
> DNS infrastructure options.

That's a fine preference, but it does not align with the reality that anyone 
can already do that. Not having a standard doesn't prevent abuse.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Paul Wouters]

On Mon, 4 Mar 2019, Ray Bellis wrote:

This new draft describes a way for clients and servers to exchange a limited 
amount of information where the semantics of that information are completely 
unspecified, and therefore determined by bi-lateral agreement between the 
client and server operators.


This makes me very nervous. An edge ISP DNS server could use this to
mark DNS packets from certain users, and applications could use this as
another cookie to track users, especially in light of endusers talking
directly to open resolvers like the Quads, from within the application,
bypassing the operating system.

There are known cases where bespoke implementations are using experimental 
EDNS option values for this purpose, for example for a front-end 
load-balancer to tell the server whether an incoming connection arrived over 
TCP or UDP (c.f. my XPF draft).


Great. And once experimenting is done, submit a draft and get a real
EDNS code point. Do this as many times as you want. The idea of a
limited experimental space is that you cannot rely on it to be rolled
out into the wild word. That's a feature.

A goal of this draft is to assign a common EDNS code-point such that popular 
OSS implementations can support similar features interoperably.


I would much rather see 10 specfic EDNS code points for features, than a
kitchen sink EDNS option that can be abused to send potentially
dangerous tracking identifiers that we cannot distinguish from actual
DNS infrastructure options.

Paul

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Tue, 5 Mar 2019 at 00:45, Mark Andrews  wrote:

8<

Presumably you won’t get back a server tag and you can log that.
>

Not always.

The spec does not require the server to return a server tag in response to
a client tag.
However, a server tag may only be returned in response to a request
containing a client tag.

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

Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

[Paul Wouters]

Ah yes. "imminent" was a reminder of their commitment to volunteer to give
feedback :)

If we do another rev as a result of this call, I'll remove it. Otherwise,
I'll leave a note with the RFC Editor to do so.

Paul

On Mon, Mar 4, 2019 at 7:40 PM Michael Sinatra 
wrote:

> Section 8 - Acknowledgements:
>
> "We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
> Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback."
>
> Paraphrasing one of my colleagues, is the part about "imminent feedback"
> a prediction, or a hint that we are supposed to give more feedback? :-)
>
> My most imminent feedback--right now--is that I think the language in
> Section 3 has come together really nicely and does a good job of
> informing operators of the trade-offs of using the different algorithms,
> and it provides good recommendations.  I certainly support advancing it.
>
> michael
>
> On 2/13/19 11:29 AM, The IESG wrote:
> >
> > The IESG has received a request from the Domain Name System Operations WG
> > (dnsop) to consider the following document: - 'Algorithm Implementation
> > Requirements and Usage Guidance for DNSSEC'
> >as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> final
> > comments on this action. Please send substantive comments to the
> > i...@ietf.org mailing lists by 2019-02-27. Exceptionally, comments may
> be
> > sent to i...@ietf.org instead. In either case, please retain the
> beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >The DNSSEC protocol makes use of various cryptographic algorithms in
> >order to provide authentication of DNS data and proof of non-
> >existence.  To ensure interoperability between DNS resolvers and DNS
> >authoritative servers, it is necessary to specify a set of algorithm
> >implementation requirements and usage guidelines to ensure that there
> >is at least one algorithm that all implementations support.  This
> >document defines the current algorithm implementation requirements
> >and usage guidance for DNSSEC.  This document obsoletes [RFC6944].
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
> >
> > IESG discussion can be tracked via
> >
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> > ___
> > 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-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Mon, 4 Mar 2019 at 23:43, Wes Hardaker  wrote:

> Dick Franks  writes:
>
> > As the man said, "[semantics are] determined by bi-lateral agreement".
> > If the counter-party decides to do something different, it has
> repudiated the
> > agreement.
>
> Yes, and that's where I see a problem: when the software doesn't know
> the agreement has been severed.
>

Non-performance by one party to the agreement will inevitably cause
something to fail,
which will be directly observable by the [singular] counter-party.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Mark Andrews]

> On 5 Mar 2019, at 10:43 am, Wes Hardaker  wrote:
> 
> Dick Franks  writes:
> 
>> As the man said, "[semantics are] determined by bi-lateral agreement".
>> If the counter-party decides to do something different, it has repudiated the
>> agreement.
> 
> Yes, and that's where I see a problem: when the software doesn't know
> the agreement has been severed.

Presumably you won’t get back a server tag and you can log that.

> -- 
> Wes Hardaker
> USC/ISI
> 
> ___
> 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] 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] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

[Michael Sinatra]

Section 8 - Acknowledgements:

"We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback."

Paraphrasing one of my colleagues, is the part about "imminent feedback"
a prediction, or a hint that we are supposed to give more feedback? :-)

My most imminent feedback--right now--is that I think the language in
Section 3 has come together really nicely and does a good job of
informing operators of the trade-offs of using the different algorithms,
and it provides good recommendations.  I certainly support advancing it.

michael

On 2/13/19 11:29 AM, The IESG wrote:
> 
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Algorithm Implementation
> Requirements and Usage Guidance for DNSSEC'
>as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2019-02-27. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>The DNSSEC protocol makes use of various cryptographic algorithms in
>order to provide authentication of DNS data and proof of non-
>existence.  To ensure interoperability between DNS resolvers and DNS
>authoritative servers, it is necessary to specify a set of algorithm
>implementation requirements and usage guidelines to ensure that there
>is at least one algorithm that all implementations support.  This
>document defines the current algorithm implementation requirements
>and usage guidance for DNSSEC.  This document obsoletes [RFC6944].
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> ___
> 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-bellis-dnsop-edns-tags-00.txt

[Wes Hardaker]

Dick Franks  writes:

> As the man said, "[semantics are] determined by bi-lateral agreement".
> If the counter-party decides to do something different, it has repudiated the
> agreement.

Yes, and that's where I see a problem: when the software doesn't know
the agreement has been severed.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Dick Franks]

On Mon, 4 Mar 2019 at 23:03, Wes Hardaker  wrote:

> Ray Bellis  writes:
>
> > This new draft describes a way for clients and servers to exchange a
> > limited amount of information where the semantics of that information
> > are completely unspecified, and therefore determined by bi-lateral
> > agreement between the client and server operators.
>

8<

What happens when the upstream software changes?  Or the upstream server
> is taken over by a new company that deploys entirely new semantics?  How
> is that change communicated to all the clients?  What if the new bits
> mean something entirely different, potentially the exact opposite?  How
> are conflicts like this handled?
>

The conflict never arises.
As the man said, "[semantics are] determined by bi-lateral agreement".
If the counter-party decides to do something different, it has repudiated
the agreement.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Wes Hardaker]

Ray Bellis  writes:

> This new draft describes a way for clients and servers to exchange a
> limited amount of information where the semantics of that information
> are completely unspecified, and therefore determined by bi-lateral
> agreement between the client and server operators.

Hmmm..  very interesting idea, but I'm having a hard time seeing how
this will be used in the real world in a scalable and interoperable
way.

Let's take an example from the draft (which is a good/interesting one, btw):

   o  client-controlled selection of a DNS-based security filter

So, my client knows the upstream resolver has published two flags/bits
for this:

  0x01 - don't filter out malware
  0x02 - please filter out ad servers

This is all well and good if the client knows what it's talking to.  How
does it know which resolvers support it?  This has to be custom config
in clients I assume?

So let's assume the (roaming) client has a pre-configured list of IP
addresses that know how to send or interpret particular tags.

What happens when the upstream software changes?  Or the upstream server
is taken over by a new company that deploys entirely new semantics?  How
is that change communicated to all the clients?  What if the new bits
mean something entirely different, potentially the exact opposite?  How
are conflicts like this handled?

There are cases for this type of behavior already, and they do work.  As
an example, BGP communities distribute routing policies in a fairly
similar way.  But BGP connections are small in number, contracts or MOUs
at the least are put in place to ensure communication can happen, etc.

The problem with a generic mechanism like this for DNS is that the
number of clients per server are potentially gigantic.  And there is
often not a documented relationship or even a known contact mechanism to
signal changes taking place.  This all makes communication of agreed
upon semantics of bits not exactly impossible, but likely between
difficult to extremely difficult.  And misconfiguration could be
potentially be dangerous, depending on the meaning of the bits.  Imagine
if the new bit for some flipped software suddenly switched to "I trust
MD5, go ahead and believe MD5 DS records".

But maybe, and hopefully, I'm just misunderstanding how this will be
used safely in deployments.

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[Mark Andrews]

You specify a well known TSIG key (e.g. name=“.”, algorithm=hmac-sha256, 
key=<32-zero-bytes>)
then you use it when you don’t have a more specific key.  If the server support 
the WKK you
will get back a TSIG signed response that can’t have been forged by a off path 
attacker if it
matched the response.  There should be enough entropy in a TSIG query without 
add more but one
can add more by putting random data in the other field prior to generating the 
request’s hmac.
Otherwise you should get back a BADKEY error if the server supports TSIG and 
FORMERR, NOTIMP
(without a TSIG record) or a non-TSIG response if the server does not implement 
TSIG.  Clients
can remember of they get a TSIG response and reject non-TSIG responses in the 
future or treat
each transaction as independent.  I would expect public DNS resolvers to 
formally state when
they support this.

The pairwise table I generated was to show what current servers do when 
presented with a
unknown, unexpected TSIG key.  There are a number of mis-implementation of TSIG 
shown.  A
few underspecified parts of the TSIG specification which I raise earlier.  
There are firewalls
that unnecessarily block requests with TSIG present and there are 
mis-implementations of STD 13
shown.

If we proceed down this path we will need to get CVE’s issues against all the 
firewalls and
nameserver implementation that block/drop requests with TSIG presents they 
should be issued 
for firewalls anyway as it they break the ability to use TSIG.  Servers that 
mis-implement
TSIG or STD 13 need to be identified and fixed.  A date for removal of 
workarounds for the
mis-implementations needs to be set (+5 years from publishing should be enough 
time) along
with a campaign to find at inform the server operators of broken servers.  
Tests for WKK
behaviour should be added to delegated server tests and if we don’t go down 
this path vendors
that implement TSIG at least should be add BADKEY tests to their QA procedures, 
similarly
vendors that don’t implement TSIG need to add TSIG queries to their QA 
procedures.

The raw data for the table is available at https://ednscomp.isc.org and is 
regenerated towards
the end of the month.

Mark

> On 4 Mar 2019, at 10:52 pm, fujiw...@jprs.co.jp wrote:
> 
>> From: Mark Andrews 
>> Or one can use TSIG with a well known key to get a cryptograph hash of the 
>> response.  Below is how
>> how the servers for the Alexa to 1 Million handle unexpected TSIG.  It’s 
>> well under a day to add
>> this to a recursive server that supports TSIG already.  It’s a couple of 
>> minutes of configuration
>> time to add it to a authoritative server that supports TSIG already.
> 
> Do you mean adding new method like DNS Cookies ?
> 
> I have a question.
> 
> If a resolver want to take measures,
> does the resolver configure TSIG to communicate all authoritative servers ?
> 
> --
> Kazunori Fujiwara, JPRS 
> 

-- 
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] [Ext] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ted Lemon]

On Mar 4, 2019, at 1:47 PM, Paul Hoffman  wrote:
> Yes: the DNS state specification is necessarily complicated to implement 
> because it is doing much more than what is proposed here. It is OK for 
> someone to propose a simple mechanism for a simple need.

No argument, just curious if this had been considered.

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

Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[神明達哉]

At Mon, 04 Mar 2019 20:43:14 +0900 (JST),
fujiw...@jprs.co.jp wrote:

> > - Section 3
> >
> >Linux 2.6.32, Linux 4.18.20
> >and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and
> >path MTU decreased to 1280.
> >
> >   I suspect this often doesn't matter much in practice.  Since IPv6
> >   doesn't allow fragmentation and PMTU discovery isn't very effective
for
>   ^
>   on-path fragmentation ?

Oops, sorry for the confusing text.  I meant "IPv6 doesn't allow
fragmentation at intermediate nodes" (or, yes, I meant "on-path
fragmentation").

> >   DNS responders, the server implementation should set
> >   IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations
> >   actually set this option; some others don't, but they are just lucky
> >   to not encounter the problem or receive complaints about it).
>
> If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU
value ?

Yes.  Or more accurately, if IPV6_USE_MIN_MTU is set the path MTU
value (if known) is just ignored.

> Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ?

Yes (if IPV6_USE_MIN_MTU is specified).

> I observed many fragmented IPv6 DNS responses whose packet size are
> 1496 or 1500.

Those should be sent from a server that doesn't set IPV6_USE_MIN_MTU
or from a system that doesn't support the option (sadly a very widely
deployed OS doesn't support it: Linux).

> # What I was interested in was that many implementations accept
> # crafted "ICMPv6 Packet Too Big".

Sure, but unless it matters in the larger context of the draft, it's
just a distraction.

--
JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Paul Hoffman]

On Mar 4, 2019, at 10:06 AM, Ted Lemon  wrote:
> 
> On Mar 4, 2019, at 11:27 AM, Ray Bellis  wrote:
>> This new draft describes a way for clients and servers to exchange a limited 
>> amount of information where the semantics of that information are completely 
>> unspecified, and therefore determined by bi-lateral agreement between the 
>> client and server operators.
> 
> Any reason not to use DNS Stateful Operations for this?

Yes: the DNS state specification is necessarily complicated to implement 
because it is doing much more than what is proposed here. It is OK for someone 
to propose a simple mechanism for a simple need.

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ted Lemon]

On Mar 4, 2019, at 11:27 AM, Ray Bellis  wrote:
> This new draft describes a way for clients and servers to exchange a limited 
> amount of information where the semantics of that information are completely 
> unspecified, and therefore determined by bi-lateral agreement between the 
> client and server operators.

Any reason not to use DNS Stateful Operations for this?

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

Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Paul Hoffman]

On Mar 4, 2019, at 8:27 AM, Ray Bellis  wrote:
> This new draft describes a way for clients and servers to exchange a limited 
> amount of information where the semantics of that information are completely 
> unspecified, and therefore determined by bi-lateral agreement between the 
> client and server operators.
> 
> There are known cases where bespoke implementations are using experimental 
> EDNS option values for this purpose, for example for a front-end 
> load-balancer to tell the server whether an incoming connection arrived over 
> TCP or UDP (c.f. my XPF draft).
> 
> A goal of this draft is to assign a common EDNS code-point such that popular 
> OSS implementations can support similar features interoperably.

I have read the draft (which is thankfully succinct!) and think it makes good 
sense. It could be adopted by DNSOP because it directly affects DNS operations.

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

Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

[Warren Kumari]

On Mon, Mar 4, 2019 at 11:05 AM Paul Wouters  wrote:

> On Mon, 4 Mar 2019, Warren Kumari wrote:
>
> > So, my plan is to 1: ask the authors to please swap the Y to an N as
> below and 2: progress the document with the hope that this
> > section will survive the publication process.
>
> But I do not hope that.
>
> > The March telechats are often really full - ADs who are leaving the IESG
> try and get old / stuck work finished and off their
> > plate - and so this would likely only show up on the 2019-04-11 telechat
> -- so if anyone really objects to this being (attempted
> > to be) left in, please shout.
>
> I think it should not be in the document. For one, it will be quickly
> outdated information over the years as implementations release new
> versions. Second, it will lead to people putting these sections in for
> marketing. I think RFCs should avoid naming products whenever possible.
>
> I'm happy to do a new rev that includes an improved "remove me" note to
> IANA and the pdns update.
>
>
That works for me too...
W



> Paul
>


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

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

[Ray Bellis]

DNSOP,

This new draft describes a way for clients and servers to exchange a 
limited amount of information where the semantics of that information 
are completely unspecified, and therefore determined by bi-lateral 
agreement between the client and server operators.


There are known cases where bespoke implementations are using 
experimental EDNS option values for this purpose, for example for a 
front-end load-balancer to tell the server whether an incoming 
connection arrived over TCP or UDP (c.f. my XPF draft).


A goal of this draft is to assign a common EDNS code-point such that 
popular OSS implementations can support similar features interoperably.


Ray

 Forwarded Message 
Subject: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Date: Mon, 04 Mar 2019 08:14:24 -0800
From: internet-dra...@ietf.org
To: Ray Bellis , Alan Clegg 


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

Name:   draft-bellis-dnsop-edns-tags
Revision:   00
Title:  DNS EDNS Tags
Document date:  2019-03-04
Group:  Individual Submission
Pages:  6
URL: 
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-edns-tags-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bellis-dnsop-edns-tags/

Htmlized:   https://tools.ietf.org/html/draft-bellis-dnsop-edns-tags-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-edns-tags



Abstract:
   This document describes EDNS Tags, a mechanism by which DNS clients
   and servers can transmit an opaque data field which has no defined
   semantic meaning other than as previously agreed between the client
   and server.

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

Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

[Paul Wouters]

On Mon, 4 Mar 2019, Warren Kumari wrote:


So, my plan is to 1: ask the authors to please swap the Y to an N as below and 
2: progress the document with the hope that this
section will survive the publication process. 


But I do not hope that.


The March telechats are often really full - ADs who are leaving the IESG try 
and get old / stuck work finished and off their
plate - and so this would likely only show up on the 2019-04-11 telechat -- so 
if anyone really objects to this being (attempted
to be) left in, please shout.


I think it should not be in the document. For one, it will be quickly
outdated information over the years as implementations release new
versions. Second, it will lead to people putting these sections in for
marketing. I think RFCs should avoid naming products whenever possible.

I'm happy to do a new rev that includes an improved "remove me" note to
IANA and the pdns update.

Paul

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

Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

[Peter van Dijk]

Hi Warren,

On 4 Mar 2019, at 16:23, Warren Kumari wrote:

On Thu, Feb 28, 2019 at 10:13 AM Peter van Dijk 


wrote:


As this pertains to a section that will apparently be removed for
publication, only posting it here on dnsop@ for historical reasons:


So, RFC7942 (the one about "The Implementation Status" section) says 
that
this section should contain a note asking for it to be removed (and 
even
includes boilerplate to copy and paste) -- this document instead says 
"The

following table contains the status of support in the open-source DNS
signers and validators in the current released versions as of the time
writing this document." which implies it will be left in the document. 
I
personally think that this is good / helpful, but am not sure how the 
rest

of the IESG will feel about this...


I always found the removal a very unhelpful idea. A different draft 
comes to mind where the implementation section mentioned the ways in 
which almost every implementation, consistently, deviated from the 
draft, which would be very useful information to future implementors!


I indeed also noticed that this draft lacked that note, but Paul Wouters 
replied this via Twitter:


letoams: @oerdnj @Habbie ohh. well that whole section will be cut anyway 
before RFC :) If we do another rev based on IETF LC, I will update it 



As of 28-Feb-2019 14:02 I see pdns-4.2.0-beta1 available for download, 
so I

think that doing what Peter requests is fine.

So, my plan is to 1: ask the authors to please swap the Y to an N as 
below
and 2: progress the document with the hope that this section will 
survive

the publication process.

The March telechats are often really full - ADs who are leaving the 
IESG
try and get old / stuck work finished and off their plate - and so 
this
would likely only show up on the 2019-04-11 telechat -- so if anyone 
really

objects to this being (attempted to be) left in, please shout.


If it turns out the section is going to be removed before publication, 
then of course, don’t bother with the change. If the section will 
survive, and it is felt that this small change will hold up publication, 
then please also do not bother.


Otherwise, if it turns out we can easily get this change in, please do.

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

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

Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

[Warren Kumari]

On Thu, Feb 28, 2019 at 10:13 AM Peter van Dijk 
wrote:

> On 13 Feb 2019, at 20:29, The IESG wrote:
>
> > The IESG has received a request from the Domain Name System Operations
> > WG
> > (dnsop) to consider the following document: - 'Algorithm
> > Implementation
> > Requirements and Usage Guidance for DNSSEC'
> >as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final
> > comments on this action. Please send substantive comments to the
> > i...@ietf.org mailing lists by 2019-02-27. Exceptionally, comments may
> > be
> > sent to i...@ietf.org instead. In either case, please retain the
> > beginning of
> > the Subject line to allow automated sorting.
>
> As this pertains to a section that will apparently be removed for
> publication, only posting it here on dnsop@ for historical reasons:
>
>
So, RFC7942 (the one about "The Implementation Status" section) says that
this section should contain a note asking for it to be removed (and even
includes boilerplate to copy and paste) -- this document instead says "The
following table contains the status of support in the open-source DNS
signers and validators in the current released versions as of the time
writing this document." which implies it will be left in the document. I
personally think that this is good / helpful, but am not sure how the rest
of the IESG will feel about this...

As of 28-Feb-2019 14:02 I see pdns-4.2.0-beta1 available for download, so I
think that doing what Peter requests is fine.

So, my plan is to 1: ask the authors to please swap the Y to an N as below
and 2: progress the document with the hope that this section will survive
the publication process.

The March telechats are often really full - ADs who are leaving the IESG
try and get old / stuck work finished and off their plate - and so this
would likely only show up on the 2019-04-11 telechat -- so if anyone really
objects to this being (attempted to be) left in, please shout.

W



> PowerDNS has removed all GOST support as of version 4.2, which is due to
> be released any day now, so please change that cell in section 6.1 to N.
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
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] draft-fujiwara-dnsop-fragment-attack-01.txt

[fujiwara]

> From: Mark Andrews 
> Or one can use TSIG with a well known key to get a cryptograph hash of the 
> response.  Below is how
> how the servers for the Alexa to 1 Million handle unexpected TSIG.  It’s well 
> under a day to add
> this to a recursive server that supports TSIG already.  It’s a couple of 
> minutes of configuration
> time to add it to a authoritative server that supports TSIG already.

Do you mean adding new method like DNS Cookies ?

I have a question.

If a resolver want to take measures,
does the resolver configure TSIG to communicate all authoritative servers ?

--
Kazunori Fujiwara, JPRS 

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

Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

[fujiwara]

> From: 神明達哉 
>>https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01
>>
>> It summarized DNS cache poisoning attack using IP fragmentation
>> and countermeasures.
>>
>> If the draft is interested, I will request timeslot at IETF 104.
> 
> I've read the draft.  I think it's generally well written and contains
> useful information.

Thanks very much.

> Some specific comments follow:
> 
> - general: I wonder whether the effect of this problem can be
>   substantially different between IPv6 and IPv4.  As the draft itself
>   discusses, IPv6 has a much larger ID space for fragmentation (the
>   existence of implementations that generate predictable IDs is an
>   implementation issue; in the case of IPv4 it's a protocol issue).
>   IPv6 also has a much larger minimum MTU.  In practice, I suspect
>   most (unsigned) important responses can fit in the minimum MTU,
>   substantially affecting the practical severity of the attack.  I'm
>   not saying that we don't have to take any measure for the IPv6 case,
>   but I think this difference is worth noting in the draft explicitly.

I agree and need to consider how to update.

> - general: the draft the term "full-service resolver" in Abstract and
>   throughout the document.  It may be only me, but I always feel this
>   term is confusing and misleading, even after the publication of
>   RFC8499.  It's not very clear to me whether "full-service" excludes
>   "forwarding only" resolvers.  RFC8499 refers to RFC1123, and its
>   definition is also unclear to me in this sense.  If this confusion
>   is not only mine, I think the use of the term is rather harmful,
>   since the issue discussed in this draft shouldn't exclude forwarding
>   only resolvers.  What matters here is a resolver with a cache, and
>   in that sense I'd rather suggest just saying "(recursive) resolver";
>   it should be obvious that it's about a resolver with the cache from
>   the context.

I will consider the comment.

> - general: on a related point, I suspect the discussion about
>   authoritative servers is not actually specific to authoritative
>   servers; consider the case of a recursive server that takes queries
>   from forwarding only resolvers.  It should be generally applicable
>   to any DNS "responder", and I'd suggest revising the draft
>   accordingly.

DNS forwarders and stub resolvers may be target of cache poisoning attacks.
Then, path MTU attack targets are DNS responders (auth/resolver servers).

> - general: since this is about off-path cache poisoning attacks, you
>   may also want to refer to DNS cookies (RFC7873) as a possible measure.

I agree.

> - Section 3
> 
>Linux 2.6.32, Linux 4.18.20
>and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and
>path MTU decreased to 1280.
> 
>   I suspect this often doesn't matter much in practice.  Since IPv6
>   doesn't allow fragmentation and PMTU discovery isn't very effective for
  ^
  on-path fragmentation ?

>   DNS responders, the server implementation should set
>   IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations
>   actually set this option; some others don't, but they are just lucky
>   to not encounter the problem or receive complaints about it).

If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU value ?
Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ?

I observed many fragmented IPv6 DNS responses whose packet size are
1496 or 1500.

# What I was interested in was that many implementations accept
# crafted "ICMPv6 Packet Too Big".

> - Section 4.2
> 
>Limiting EDNS0 requestor's UDP payload size [RFC6891] to 1220/1232 on
>IPv6 is a measure of path MTU attacks on IPv6 because minimal MTU
>size of IPv6 is 1280 and most of implementations ignore ICMPv6 packet
>too big packets whose MTU size is smaller than 1280.
> 
>   I suggest removing "and most of implementations..." since even if an
>   implementation accepts ICMPv6 PMTU with MTU < 1280, it doesn't mean
>   they fragment packets at that size.
> 
> - Section 4.8
> 
>Some operators that support [RFC8078] said that they use TCP only for
>transport to avoid cache poisoning attacks.
> 
>   It's not clear (to me at least) how RFC8078 is related to a TCP-only
>   operation.  Some more explanation may help.
> 
> - Section 5
> 
>o  Full-service resolvers may retry name resolution by TCP.
> 
>   I don't get exactly what this means...in which case does it suggest
>   the retry with TCP?

I will add texts.

--
Kazunori Fujiwara, JPRS 

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