Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

[Marcus Grando <[e-mail]>]

Thinking more about this I figure out some things.

First, the resolver query needs to include ECS and can't be a regular
query, that's need to verify end to end ECS support, but I think it's not a
big problem. I think we need a official way to detect if authoritative has
support or not and it need to be automatically, like an SOA query, an TXT
query or another idea, but need to be official. It's important this query
use TTL to revalidate ECS support.

About the manually whitelist, I really think it will be a huge problem and
I'm not a big fan, since the main problem is in the resolver side and not
the authoritative side, but the authoritative side know if support or not
for all domain hosted. It's impossible to know all resolvers around the
world and contact/appy to all those, to whitelist your domain.

Because of that, the idea of an official way to detect if authoritative has
or not support for ECS from a resolver perspective is a good idea. But the
control of this need to be on the authoritative side and the resolver doing
the ECS query to validate end to end and be able to use.

Another point about the SCOPE NETMASK. What you guys think about using
scope netmask to protect resolver resources, an example is: if scope
netmask was 23, authoritative only can use <=23 to scope netmask response.
I know that can be a problem with IPv4 ends, but can save resources on
resolver side.

Best regards
--
Marcus Grando
marcus (at) sbh.eng.br
@marcusgrando

On Thu, Feb 12, 2015 at 11:09 PM, Livingood, Jason <
[e-mail]> wrote:

>   Fair point. IMO whitelisting is a common tactic used early on in
> deployment of new stuff to help manage deployment risk. It was also used in
> early IPv6 days where query access to AAAA RRs was whitelisted (see
> http://tools.ietf.org/html/rfc6589). I suspect it would be similar here;
> that the need for and use of whitelisting fades as deployment levels
> increase.
>
>  - Jason
>
>   On 2/13/15, 12:44 AM, "Marcus Grando" <[e-mail]> wrote:
>
>   The question about whitelist is the problem. I think it need to be
> addressed on this doc.
>
> There's some approaches, like Google does, doing low rate ECS query:
> https://groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM
>
> Or something not so traditional like TXT record on domain record or
> hostname based like "ns1.ECS.domain.tld". It's not an clean way, but can
> optimize latency and can address problems like keep approved domains in
> memory or save on disk.
>
> It's almost impossible to authoritative guys, guess each one resolver that
> support ECS. It's need to be automatically.
>
> The other side of this problem is about resources of DNS resolver. If more
> domains enable ECS, it can increase exponentially memory usage keeping
> approved list and cache itself. With this, the minimum netmask will be
> extremly important.
>
> I don't know if it's a good idea fix the limit of how many different
> answers one authoritative can emit. This can be a problem. It's clear for
> everyone that it's much more easier to implement this on authoritative side
> than resolver side, so it need to be clear and easy for both sides.
>
> Best regards
>
>   On 12Feb15, George Michaelson allegedly wrote:
>> >
>> > we've got two agencies who do DNS, and probably have > 20% worldwide
>> > eyeball share in DNS (I don't know, thats a guesstimate) now doing
>> > edns0_client_subnet albiet with whitelist, so its a permit-list, but its
>> > functionally 'there'
>>
>> Whitelists are my biggest bugbear actually. All my other comments are
>> nice-to-haves. I hear that Google now adaptively whitelist which is a
>> nice strategy but I'd really like to see the whitelist approach
>> deprecated as much as possible. (And yes, I understand MarkA's stats
>> that show some small percentage of auth queries will break).
>>
>> I've been in other conversations lately where it was all about how do
>> we get "pick some larger resolver" to whitelist us? We all know that
>> doesn't scale. So interest appears to be growing.
>>
>> > Its probably already more widely deployed than IPv6...
>>
>> On the auth side I think you're right. It's the client side that's the
>> missing link. But this is a classic alignment-of-interest problem. The
>> relatively small number of auths who care implement, but there is
>> little incentive on the resolver side.
>>
>>
>> Mark.
>>
>
> --
>  Marcus Grando
>
>