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

[Marek Vavruša]

On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček  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.

> Petr Špaček  @  CZ.NIC
>
>
>> 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 >>> > 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 >>> > wrote:



 > 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

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

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

[Marek Vavruša]

On Mon, Aug 20, 2018 at 7:31 PM, Ted Lemon  wrote:
> This is why we need to actually think about trust and not just handwave.
> There are a number of serious misconceptions in what you've said, Paul.

I'm still not sure that IETF should define the provider of trust, as
the trust is relative.
But you're right Ted, it should definitely be at written down and formalized
if we want to move forward.

I have to compose my thoughts on this first. I'll try next weekend if I get
some of that bravery or willpower back.

> DHCP _is_ worse than TOFU, because there is an opportunity for attack at
> every lease renewal, not just the first time you ever talk to a particular
> DHCP server.   I actually proposed a protocol that would have worked nicely
> for TOFU, but it didn't get consensus, so we don't even have TOFU-level
> authenticity.
>
> The rest of what you said is nice, but "we have to balance theoretical risk
> versus sane and widespread deployment" is a statement that sounds a lot
> better if we do the math.   If we just decide to do something without doing
> the math, then we aren't really balancing anything.   We're just deciding
> not to do our homework, because math is hard.
>
> On Mon, Aug 20, 2018 at 10:26 PM, Paul Ebersman 
> wrote:
>>
>> ebersman> That may be the consensus at the IETF but it's not even close
>> ebersman> the consensus with ISPs, nor large enterprise. That seems to
>> ebersman> cover most of the eyeball/consumer... DHCP is still how much
>> ebersman> of the world gets connected and that hasn't changed in decades.
>>
>> pusateri> You're misquoting me and arguing against a point I didn't
>> pusateri> make. There was no one saying we don't need DHCP. There was a
>> pusateri> general agreement that DHCP should not be extended.
>>
>> pusateri> The DHC working group never completed the work for DHCP
>> pusateri> authentication. It's not trustworthy enough in its current
>> pusateri> form to add more things to it.
>>
>> And I'd argue that this is also an IETF opinion, not the majority of the
>> internet. There's a reason it's still the most widespread configuration
>> management for devices. "Not trustworthy enough to extend" is a fine
>> academic opinion but doesn't hold water in the marketplace.
>>
>> DHCP is no worse currently than TOFU. We trust that the OFFER packet
>> will be from the DHCP server we're supposed to use. Trust On First
>> Use. Not great but it works more than not. At least that's the argument
>> I kept hearing for TOFU. We actually have operational experience of
>> decades for DHCP and this isn't a wide spread enough problem to kill any
>> innovation forever because it's not perfect.
>>
>> If we want the world to use what the IETF develops, we have to be able
>> to balance theoretical risk vs sane and widespread deployment.
>>
>> If not, someone will just wind up shoving this into yet another DHCP
>> vendor option and every vendor will be different. That will be even less
>> secure.
>>
>> ___
>> 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] Draft for dynamic discovery of secure resolvers

[Marek Vavruša]

On Mon, Aug 20, 2018 at 6:58 PM, Paul Vixie  wrote:
>
>
> Tom Pusateri wrote:
> 
>>
>> 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.
>
>
> that's a cool hack, showing once again DoT's superiority over DoH.

This has been used to detect DoH support in dnscrypt-proxy as well.
One subtle issue with probing is that "it doesn't work" is not the
same as "it's not supported".
It can mean that port/traffic is being blocked, client is
incompatible, crypto is incompatible, etc.,
so it's difficult to distinguish whether the service is being offered
but unavailable for various reasons,
and service not being offered.

> --
> P Vixie
>
>
> ___
> 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

[Marek Vavruša]

Interesting. This approach is similar to the lists curated by Frank
and people from dnscrypt-proxy: https://dnscrypt.info/public-servers

Assuming that separating protocol change from trust model change is a
no-go, then the trust would need to go both ways - the network
operator would need to push the list of resolvers that she considers
trusted, and the client would crosscheck that list to its provisioned
configuration (or list downloaded from a public service such as this
etc.). This is conceptually similar to NPN/ALPN.

Marek

On Sun, Aug 19, 2018 at 11:35 AM, Tom Pusateri  wrote:
>
>
> On Aug 19, 2018, at 9:29 AM, Livingood, Jason 
> wrote:
>
> On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert"
>  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

[Marek Vavruša]

Thanks Tom, this is what I was asking for. I'll take a look!

On Sat, Aug 18, 2018 at 6:09 PM, Tom Pusateri  wrote:
>
>
> On Aug 18, 2018, at 8:53 PM, Marek Vavruša
>  wrote:
>
> On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon  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
> Ted’s talk starts at 33:18.
>
> Willem and my draft is here:
>
> 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] Draft for dynamic discovery of secure resolvers

[Marek Vavruša]

On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon  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

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

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

[Marek Vavruša]

On Sat, Aug 18, 2018 at 5:33 PM, Paul Vixie  wrote:
>
>
> Marek Vavruša wrote:
>>
>> Hi,
>>
>> thanks for comments. This draft has little to do with DoH (the primary
>> focus is DoT), and its comparison to other technologies. It's about
>> network operator being able to advertise that its recursive server
>> supports DNS on more than just port 53. Please let's stay at least a
>> bit on topic.
>>
>> Marek
>
>
> i think stubs should try to negotiate persistent tcp/853 for every address
> they receive from dhcp, and if they can't, they should fall back to doing
> whatever they did before, like try udp/53, and so on.
>
> --
> P Vixie

I agree, this works in the opportunistic profile or with an IP
certificate and trust in CA model.
The pros and cons of this are described in
https://tools.ietf.org/html/rfc8310#section-7.2

It doesn't work for dynamic configuration of ADN or SPKI pins.

Marek

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

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

[Marek Vavruša]

On Sat, Aug 18, 2018 at 5:03 PM, Ted Lemon  wrote:
> Marek, forgive me for being blunt, but your reply was completely
> non-responsive.   DoH and DoT are being used because they address a threat
> model, or because, as Bert rather bluntly put it, they allow content
> providers to study our query stream.   They are not being used "because they
> are standards track documents."   If you don't have any reason other than
> that to use DoH or DoT, then you shouldn't use them.

No worries, I hoped I described the use case, but perhaps not well enough.

> 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

> that whatever configuration the user or service provider has set up be
> replaced by information received by DHCP, and that "DHCP authentication",
> which doesn't exist, be used to validate this information.   This is a

The "DHCP authentication" does exist, I believe you're referring the
deployment status.
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.

> completely different trust model than the current trust model.   Maybe it's
> a good idea, maybe it's a bad idea, but it's completely different.   So you
> need to figure out the existing trust model and figure out how your proposal
> impacts that trust model.   To define a DHCP option before you've done this
> is putting the cart before the horse.

I described one possible way how clients could interpret the
advertised information using a trusted CA bundle.
At the very least, if my ISP or office network advertises resolvers on
port 853, using those is arguably better than
the same resolver on port 53.

> On Sat, Aug 18, 2018 at 5:58 PM, Marek Vavruša 
> wrote:
>>
>> Hi Ted,
>>
>> thanks for comments. As said, the draft doesn't try to change the
>> trust model or fix DHCP authentication, it merely offers network
>> operators the ability to advertise secure resolvers for their network.
>> The added "danger" is that recipient inherently trusts the
>> information.
>>
>> On Sat, Aug 18, 2018 at 2:22 PM, Ted Lemon  wrote:
>> > DHCP authentication doesn't exist.   We already rejected a draft that
>> > described how to set up DoH with DHCP.   Yours is a little more
>> > complicated,
>> > but doesn't seem any less dangerous.   Before you go any farther on
>> > this,
>> > you might ask yourself a couple of questions:
>> >
>> > 1. Why is DoH being used?
>>
>> The DoT and DoH are being used because they're both either standard or
>> on a standards track and have deployed client software.
>>
>> > 2. What is the thread model that DoH is addressing?
>> > 3 How does adding this configuration mechanism impact DoH's ability to
>> > address that threat model?
>>
>> It does not. In both cases, determining whether the resolver (or its
>> capabilities) provided by a DHCP server can be trusted is up to the
>> client.
>> The current model is that either OS or applications like browsers
>> install a curated CA bundle with CA's the client should trust.
>> When a DNS stub resolver receives a request, it looks into the
>> resolv.conf (simplifed) and picks a resolver to send query to.
>> Currently the most common method is to pick first, but it might prefer
>> resolvers with secure capabilities first.
>> If a resolver is advertised as secure, the stub resolver may do a TLS
>> handshake and check the certificate.
>> Now at this step, it may:
>>
>> a) only trust certificates issued by a CA trusted by the application
>> with the resolver IP address in SAN (trust system configuration)
>> b) ditto, but certificates with advertised ADN in SAN or matching
>> SPKI pin (this presumes the client trusts DHCP offering, or is okay
>> with TOFU)
>> c) bail and talk to the resolver over port 53
>>
>> In a), the resolver can be trusted. In both b) and c) the trust in the
>> reso

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

[Marek Vavruša]

Hi,

thanks for comments. This draft has little to do with DoH (the primary
focus is DoT), and its comparison to other technologies. It's about
network operator being able to advertise that its recursive server
supports DNS on more than just port 53. Please let's stay at least a
bit on topic.

Marek

On Sat, Aug 18, 2018 at 2:46 PM, Paul Vixie  wrote:
>
>
> Ted Lemon wrote:
>>
>> DHCP authentication doesn't exist.   We already rejected a draft that
>> described how to set up DoH with DHCP.   Yours is a little more
>> complicated, but doesn't seem any less dangerous.   Before you go any
>> farther on this, you might ask yourself a couple of questions:
>>
>> 1. Why is DoH being used?
>> 2. What is the thread model that DoH is addressing?
>> 3 How does adding this configuration mechanism impact DoH's ability to
>> address that threat model?
>
>
> the DoH use case is for web users and web apps who do not trust their
> network operator and who are not trusted by their network operator, so it's
> a policies-in-the-night model where data can be imported from The Web
> without approval or permission or control or observability by a network
> operator. it is in other words a thin DNS-only way to do what Tor does.
>
> as a network operator, i oppose this thinking. i predict a long war in which
> web users and apps who want to use DoH to reach an external DNS resolver
> will be treated as attackers, and either banned or blocked. in some parts of
> the world such use will be illegal and even punishable, much as Tor is
> today.
>
> this is what happened after edward snowden flew to hong kong: the pendulum
> swung so far the other way that many of us saw only absurdity.
>
> the possibility that large CDN operators will colo a DOH endpoint with their
> high-value hosting, in order to discourage network operators from blocking
> it, raises the stakes. _i_ will block it. most corporate networks will block
> it in some form. some countries will block it. no DNS content will enter my
> network without having passed through my RPZ rules. if a CDN operator wants
> to play "chicken", i guess that we will.
>
> --
> P Vixie
>

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

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

[Marek Vavruša]

Hi Ted,

thanks for comments. As said, the draft doesn't try to change the
trust model or fix DHCP authentication, it merely offers network
operators the ability to advertise secure resolvers for their network.
The added "danger" is that recipient inherently trusts the
information.

On Sat, Aug 18, 2018 at 2:22 PM, Ted Lemon  wrote:
> DHCP authentication doesn't exist.   We already rejected a draft that
> described how to set up DoH with DHCP.   Yours is a little more complicated,
> but doesn't seem any less dangerous.   Before you go any farther on this,
> you might ask yourself a couple of questions:
>
> 1. Why is DoH being used?

The DoT and DoH are being used because they're both either standard or
on a standards track and have deployed client software.

> 2. What is the thread model that DoH is addressing?
> 3 How does adding this configuration mechanism impact DoH's ability to
> address that threat model?

It does not. In both cases, determining whether the resolver (or its
capabilities) provided by a DHCP server can be trusted is up to the
client.
The current model is that either OS or applications like browsers
install a curated CA bundle with CA's the client should trust.
When a DNS stub resolver receives a request, it looks into the
resolv.conf (simplifed) and picks a resolver to send query to.
Currently the most common method is to pick first, but it might prefer
resolvers with secure capabilities first.
If a resolver is advertised as secure, the stub resolver may do a TLS
handshake and check the certificate.
Now at this step, it may:

a) only trust certificates issued by a CA trusted by the application
with the resolver IP address in SAN (trust system configuration)
b) ditto, but certificates with advertised ADN in SAN or matching
SPKI pin (this presumes the client trusts DHCP offering, or is okay
with TOFU)
c) bail and talk to the resolver over port 53

In a), the resolver can be trusted. In both b) and c) the trust in the
resolver doesn't really change from current status until DHCP
authentication happens, but the query stream is hidden from other
devices on the same network. Either way, the benefit is that stub
resolver can make a decision based on a multitude of factors. Is there
a merit in this, or am I perhaps missing something?

Marek

>
> On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša
>  wrote:
>>
>> Hi,
>>
>> this is a bit off topic, but I figured it would be useful to solicit
>> some early feedback. The current status is that for secure (as in
>> RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism,
>> and it's also out of scope for [0]. At the same time we're seeing real
>> world deployment of clients which either:
>>
>> a) Probe port 853 and use DoT in opportunistic profile, or probe 443
>> and trust WebPKI
>> b) Statically configure ADN and/or SPKI pins with well known public
>> resolvers
>>
>> This approach works if there's someone maintaining the statically
>> configured information, as with the dnscrypt-proxy stamp lists [1].
>> However in most networks the default resolver configuration is pushed
>> through DHCP, so it's the network operator that's in charge for
>> providing default DNS resolver configuration (unless the user is a DNS
>> aficionado and overrides it), but there's currently no good way to
>> provide information required to identify and securely bootstrap a
>> connection to a resolver using DoT or DoH.
>>
>> This draft adds an option to provide a capability list for each
>> configured resolver. The three defined capabilities are TLS with SPKI
>> pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this
>> information and stores it similarly to resolver list and domain search
>> path for applications to read. Another possible solution for this is
>> to use the system of stamps from dnscrypt-proxy, but it's probably
>> less legible for clients and duplicates information that's already in
>> the recursive DNS nameservers DHCPv4/v6 option.
>>
>> The draft does not change the trust model, an end-user or an
>> application can still disregard DNS recursive nameserver list from
>> DHCP, for better or worse.
>>
>> Here's the draft:
>>
>> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt
>>
>> Marek
>>
>> [0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1
>> [1]:
>> https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-resolvers.md
>>
>> ___
>> 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] Draft for dynamic discovery of secure resolvers

[Marek Vavruša]

Hi,

this is a bit off topic, but I figured it would be useful to solicit
some early feedback. The current status is that for secure (as in
RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism,
and it's also out of scope for [0]. At the same time we're seeing real
world deployment of clients which either:

a) Probe port 853 and use DoT in opportunistic profile, or probe 443
and trust WebPKI
b) Statically configure ADN and/or SPKI pins with well known public resolvers

This approach works if there's someone maintaining the statically
configured information, as with the dnscrypt-proxy stamp lists [1].
However in most networks the default resolver configuration is pushed
through DHCP, so it's the network operator that's in charge for
providing default DNS resolver configuration (unless the user is a DNS
aficionado and overrides it), but there's currently no good way to
provide information required to identify and securely bootstrap a
connection to a resolver using DoT or DoH.

This draft adds an option to provide a capability list for each
configured resolver. The three defined capabilities are TLS with SPKI
pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this
information and stores it similarly to resolver list and domain search
path for applications to read. Another possible solution for this is
to use the system of stamps from dnscrypt-proxy, but it's probably
less legible for clients and duplicates information that's already in
the recursive DNS nameservers DHCPv4/v6 option.

The draft does not change the trust model, an end-user or an
application can still disregard DNS recursive nameserver list from
DHCP, for better or worse.

Here's the draft:
https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt

Marek

[0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1
[1]: https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-resolvers.md

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

Re: [DNSOP] QNAME minimisation on the standards track?

[Marek Vavruša]

I'd like to see this on the standards track as well. Cloudflare has
some operational experience with it (it's enabled by default on
1.1.1.1). It mostly works, but still has to be turned off on several
delegations that either don't respond to non-terminals, respond with
positive answer that's invalid (usually when there's an LB that only
handles final name, but gives out a referral to intermediate name), or
respond with nxdomain (this is the most common one and well known).

On Tue, Jul 17, 2018 at 10:01 AM, tjw ietf  wrote:
> I’d like to see a more fleshed out operational considerations section.
>
> Tim
> As chair
>
> From my high tech gadget
>
>> On Jul 17, 2018, at 08:14, Stephane Bortzmeyer  wrote:
>>
>> Greetings. With more resolvers implementing QNAME minimisation, and
>> even turning it on by default, we thought that this is a good time to
>> update RFC 7816 and make it a standard. In order to get things moving,
>> we have published a very early draft draft-bortzmeyer-rfc7816bis-00
>> that is mostly the original RFC but with a few questions and holes
>> added (see the text near the strings "TODO"). If folks in the WG is
>> interested, feel free to comment in the non-GitHub repo listed in the
>> draft, or here on the list.
>>
>>
>>
>> ___
>> 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] Blog Post: DNS over TLS support in Android P Developer Preview

[Marek Vavruša]

This is great, well done.

On Fri, Apr 13, 2018 at 12:49 PM, Warren Kumari  wrote:
> Hi all,
>
> As Erik Kline and Ben Schwartz seem to be too modest to toot their own
> horn, I'll do it for them:
> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
>
> Snippet from the above:
> "The Android P Developer Preview includes built-in support for DNS
> over TLS. We added a Private DNS mode to the Network & internet
> settings.
>
> By default, devices automatically upgrade to DNS over TLS if a
> network's DNS server supports it. But users who don't want to use DNS
> over TLS can turn it off."
>
> W
>  (Also posted to dprive)
> --
> 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Marek Vavruša]

That's a good point. Personally, I'd favour a referral response since
it saves resolver a round trip (at least for resolvers not doing QNAME
minimisation), it seems in conflict with 3.1.4.1 though as you pointed
here.

Marek

On Wed, Jan 3, 2018 at 10:31 AM, Peter van Dijk
 wrote:
> Output edited for brevity:
>
> $ dig ds root-servers.net @d.root-servers.net
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17643
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.  IN  DS
>
> ;; AUTHORITY SECTION:
> root-servers.net.   360 IN  SOA a.root-servers.net.
> nstld.verisign-grs.com. 2017111600 14400 7200 1209600 360
>
> $ dig ds root-servers.net @e.root-servers.net
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.  IN  DS
>
> ;; AUTHORITY SECTION:
> net.172800  IN  NS  a.gtld-servers.net.
> net.172800  IN  NS  b.gtld-servers.net.
> .. ..
>
> ;; ADDITIONAL SECTION:
> a.gtld-servers.net. 172800  IN  A   192.5.6.30
> b.gtld-servers.net. 172800  IN  A   192.33.14.30
> .. ..
>
>
>
> When running the query in the Subject, these are the two possible outputs I
> have observed from various root servers (with some variation from the same
> letter, presumably because of dual vendor strategies).
>
> From 4035 3.1.4.1, the NODATA response should be sent when:
>
>o  The name server has received a query for the DS RRset at a zone
>   cut.
>
>o  The name server is authoritative for the child zone.
>
>o  The name server is not authoritative for the parent zone.
>
>o  The name server does not offer recursion.
>
>
> Points 1, 2 and 4 are clear. It is point 3 that hurts here. The root servers
> are authoritative for root-servers.net. and for . , but not for net - and
> they know this because they can see the delegation in the root zone.
>
> It is my suspicion that 3.1.4.1 was not written with this edge case in mind,
> and I think that while 3.1.4.1 favours the NODATA response, the referral is
> much more useful. As a data point, the PowerDNS validator currently gets in
> trouble with the NODATA response:
> https://github.com/PowerDNS/pdns/issues/6138
>
> I think an erratum to 4035 is in order, clarifying the language such that
> servers would return the referral in this case. I have not figured out the
> exact wording yet (but I will).
>
> What does dnsop think?
>
> 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

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

Re: [DNSOP] draft-ietf-dnsop-dns-rpz

[Marek Vavruša]

Hi Vernon,

There's a functionality [1] to do all these things (and more), you
just can't read/write complicated rules from RPC compatible format
(DNS zone files). Feel free to contribute of course.

Marek

[1]: 
http://knot-resolver.readthedocs.io/en/stable/modules.html#dns-application-firewall

On Fri, Oct 6, 2017 at 9:38 AM, Vernon Schryver  wrote:
>> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= 
>
>> The current very limited implementation of RPZ in knot-resolver [1] is
>> done via a couple dozen lines of lua code, i.e. only JIT-compiled.  The
>> approach might remain similar, perhaps a bit more modularized, but in
>> any case I expect it would be included by default, so I wouldn't fear
>> about users having to recompile.
>>
>> [1]
>> https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294
>
> I wish I wouldn't offend people when I point out that a mechanism
> that uses local zone files is not a very limited response policy
> zone implementation.  Such things might be far better than real
> "rpz", but they're not "rpz".  (I can make a case for them being
> better although I don't buy it, perhaps because I'm biased.)
>
> Overwriting public DNS data triggered by qnames has always been trivial,
> but that is not "rpz."  Simply fire up a local authority server with
> your own "DNS lies" and point your resolvers to it, perhaps with custom
> "hints" files.  If you're running combined authority/resolver code
> such as BIND, simply add some local zone files.  But such ad hoc
> authority server schemes as well as the new so called "rpz" schemes
> of adding local zone files to resolvers the lack features that motiviated
> the original implementation of real RPZ including:
>
>   - distributed policy zones, including from external organizations
>   This sounds minor, but it is major.  It's related to why so few
>   organizations maintain their own anti-spam DNS blacklists.
>   You could use FTP, rsync, HTTP, etc. and a cron job, but in
>   practice you won't.  And if you did, it updates would have
>   latencies of hours or days instead of seconds with real RPZ.
>
>   - dynamically combine policy from multiple sources
>   In theory this could be done with some perl, awk, or even
>   Bourne shell code, but not in practice at scale.
>
>   - policies triggered by the contents of A and  responses or by
>  the names or IP addresses of authorities
>   The bad guys can and do register new domains faster than you can
>   update your local blacklist, faster than they can hijack new IP
>   addresses for those new domains, and faster than they'd like to
>   establish new authorities serving those new domains.
>
>   - no need to restart the resolver to reload the zone
>   This not only minimizes end user disruption when the zones
>   are reloaded but allows organization-wide policy changes with
>   latencies measured in seconds.
>
> In other words, hacking local zone file qname overrides into a
> resolver is not hard (including CNAME and DNAME chains).  The horrid
> code involves triggering on A or  contents and authority names
> and addresses...well there're also SOA timers, IXFR, AXFR, Notify,
> and TSIG, but that code is less horrid than voluminous.
>
> Please don't misunderstand me as saying no one else can or should
> write real RPZ code.  Many people could and I really wish they
> would.  That's why I spent a lot effort outside my comfort zone on
> the I-D.  What bugs me are implementations of so called RPZ and RRL
> that share only the acronyms with the BIND stuff.
>
>
> Vernon Schryverv...@rhyolite.com
>
>
> ___
> 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] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[Marek Vavruša]

I support the adoption of this document. Was there a discussion of any
actual downsides besides "I'd like to know if it's stale" and
monitoring?

On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold  wrote:
>
> On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews  wrote:
>>
>>
>> Part of the problem is that we have one TTL value for both freshness
>> and don't use beyond.
>>
>> This is fixable.  It is possible to specify two timer values.  It
>> does require adding signaling between recursive servers and
>> authoritative servers, on zone transfers and update requests.
>>
>> You basically add a additional timer field to every record immediately
>> after the TTL field.  This is only returned if the client has
>> signalled support for the extended field, I suggest using the last
>> DNS header bit for this as you can determine how you will parse the
>> response base on whether the bit is set in the response or not.
>> This field is used to expire records from the cache and its value
>> is set to the TTL field if the server has learnt the record from
>> server that doesn't support the extension.
>>
>> The existing TTL field is used for freshness checking.  When a query
>> comes in after that value has expired a freshness check is performed
>> similar to the existing prefetches that happen today.  A TTL of 1
>> is returned unless the original TTL was 0 in which case 0 is returned.
>>
>> New client - new recursive server - new authservers
>>
>> example.com. 300 86400 IN A 1.2.3.4
>>
>> +300 seconds
>>
>> example.com. 1 86100 IN A 1.2.3.4
>>  (background query is in process)
>>
>> Old client - new recursive server - new authservers
>>
>> example.com. 300 IN A 1.2.3.4
>>
>> +300 seconds
>>
>> example.com. 1 IN A 1.2.3.4
>>  (background query is in process)
>>
>> New client - new recusive server - old auth servers
>>
>> example.com. 300 300 IN A 1.2.3.4
>>
>> +300 seconds
>>  (record has expired from cache,
>>   new query is performed)
>>
>> example.com. 300 300 IN A 1.2.3.4
>>
>> For UPDATE a replacement opcode would be cleanest way to signal the
>> new format is being used.  NOTIMP should be returned by servers
>> that don't support the new opcode.
>>
>> There will be a few broken servers that just echo back the new
>> header bit.
>>
>> This way the authoritative servers still control how long records
>> are stored for.  Dead servers will get a little bit of traffic until
>> the the refresh completes.  If the authorative servers are under
>> attack the clients still see a answer.
>>
>> The alternative is to perform the refresh query and if it fails to
>> complete within X milliseconds return the cached data rather than
>> returning the cached data and doing the refresh in the background.
>>
>> Mark
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
>
> While I like the idea of a  "don't use beyond" timer, I think it will be a
> very long time before it is widely deployed (and actually configured by zone
> owners), and therefore won't solve our immediate need.  It would be great if
> clients could opt-in, but again I don't see that happening anytime soon.  So
> I would start with resolver-operators deciding what seems best for their
> clients (which is hat is happening whether we like it or not).  Adding
> client opt-out/opt-in would be good.   Signalling to say that a response is
> stale would be good.  Adding the second timer (both per-RR and as a zone
> default value, like TTL is handled) would be good.
>
> On a related note - the SOA "expire" timer tells a slave how long to keep
> serving "stale" zone data when the master cannot be reached.  Would that be
> a reasonable default value for how long a resolver should serve "stale" data
> when the authoritative servers cannot be reached?   (Currently I think most
> people set a very high value compared to the TTL.)
>
> --
> Bob Harold
>
>
>
> ___
> 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] ECDSA woes

[Marek Vavruša]

Hi,

not sure if it's exactly what you're looking for, but there's
https://github.com/CZ-NIC/deckard for (generic) resolver testing.
It mocks the environment for the tested binary, so you'll have to
provide a configuration template for dnsmasq.

Marek

On Fri, Oct 14, 2016 at 11:22 PM, Mikael Abrahamsson  wrote:
>
> Hi,
>
> we have a deployment of home gateways, based on OpenWrt BB that uses dnsmasq
> v2.71 as resolver, with DNSSEC validation turned on. It seems some
>
> Dnsmasq v2.71 does not support ECDSA. A rather large CDN uses ECDSA only. I
> also found bug reports for Debian with same problem, because they also used
> dnsmasq.
>
> Breakage occured, for instance www.ietf.org was not resolvable.
>
> Our plan is now to disable DNSSEC validation on all of these HGWs.
>
> So I read some documents:
>
> https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update-02
> https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-01
>
> I via these found RFC4035:
>
> "If the resolver does not support any of the algorithms listed in an
>authenticated DS RRset, then the resolver will not be able to verify
>the authentication path to the child zone.  In this case, the
>resolver SHOULD treat the child zone as if it were unsigned."
>
> So obviously dnsmasq doesn't implement this SHOULD, because it treats these
> zones as bogus and doesn't respond back to the client.
>
> (btw, what happens if the entire child zone and all its RRs are signed with
> an unknown algoritm, is that even covered in the above paragraph?)
>
> It took us a while to figure out why things didn't work. We even fault
> reported this to the CDN who never at any time (during their prompt and
> friendly communication) indicated that they had any knowledge of resolvers
> that didn't support their chosen algorithm, or pointed me in that direction.
>
> So... my question to you fine people is:
>
> Is there any (existing and freely available) testing suite I can run against
> my chosen resolver that tests all the SHOULDs and MUSTs regarding DNSSEC
> validation, including future proofing for new algorithms?
>
> If not, I would like to call upon for instance ccTLD registrys, ISOC and
> others, to develop a test suite for this, maintain it over time, and make it
> freely available.
>
> I like DNSSEC and want to see it widely deployed. It's an important part of
> Internet plumbing. These kinds of problems that I've had last weeks mean
> people who oppose it with FUD actually have concrete breakage to point at
> that means it's not "Uncertain" anymore.
>
> Thanks.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
> ___
> 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-ietf-dnsop-no-response-issue-03

[Marek Vavruša]

On Thu, Aug 25, 2016 at 9:23 AM, Tony Finch  wrote:
> william manning  wrote:
>
>> On Thursday, 25 August 2016, Tony Finch  wrote:
>>
>> > william manning > wrote:
>> >
>> > > I'm with Ed here,  A valid response is silence.
>> >
>> > I think it is important for people producing and deploying DNS server
>> > software and DNS-interfering middleboxes to understand the bad
>> > consequences of dropping queries or responses. If you understand these
>> > effects and still think you can improve things by dropping packets, then
>> > maybe go ahead. But it isn't a simple valid / invalid binary choice.
>>
>> Where does the "badness" occur? The server or resolver?
>
> Both. The resolver suffers extra latency; the server suffers extra traffic
> - even a well-behaved resolver has to retry in this situation.
>
>> The rational for a server to silently ignore a query often revolves
>> around malformed queries ...  Should a server attempt to answer
>> malformed queries or silently drop them?
>
> See section 7 of the draft. It would be reasonable to rate-limit
> responses.
>
> This kind of nuance is what this draft should discuss.
>
> Tony.

+1, there are other implications besides performance. For example
attacker can silence
the NS for victim (either on path or off path with spoofed source
subnet). If successful,
the attacker doesn't have to race NS->victim RTT anymore for
successful cache poisoning.

Marek

> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Trafalgar: In southeast, cyclonic, mainly easterly 6 to gale 8. In northwest,
> northerly or northeasterly 5 or 6, occasionally 7 later. Moderate or rough. In
> southeast, showers. In northwest, thundery showers. In southeast, moderate or
> good. In northwest, good occasionally poor.
>
> ___
> 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] The Larger Discussion on Differences in Response Drafts

[Marek Vavruša]

Very interesting, so BIND already pushes records for the obvious
optimisation cases.
Did you do any research on how many clients use these records (thus
don't follow up with an extra query) ?

Perhaps it would be helpful to look at the it from different perspectives.
As an authoritative DNS implementor, I'd like to be able to add
related records. Since auths are relatively well maintained, I'd feel
more comfortable experimenting here. Signalisation is not strictly
required, but perhaps a flag similar to "DO" to signalise "I want
related records" would be helpful. So both PUSH and PULL are viable
options. PUSH would be nicer if the deployed recursors already
accepted these records, however I don't have any data on this.

As a recursive DNS implementor, I can't trust everything in the
answers. I'd prefer to signalise when I want related records (PULL) to
be conservative, because the recursors are not that well maintained.
I'd like to have a better guideline on what records should be accepted
from the answers.

As a stub resolver DNS implementor, I don't want to change anything
because this code will live forever.

Marek

On Thu, Aug 18, 2016 at 7:32 PM, Mark Andrews  wrote:
>
> Named returns associated
>
> * A/ records with MX lookups if available
> * A/ records with SRV lookups if available
> * SRV/A/ records with NAPTR lookups if available
> * A/ records with NAPTR lookups if available
>
> As of 9.11 named returns associated
>
> * A//TLSA records with MX lookups if available
> * A//TLSA records with SRV lookups if available
> * SRV/A//TLSA records with NAPTR lookups if available
> * A/ records with NAPTR lookups if available
>
> Now for all of these the original lookup could be stalled for cache
> misses and the related data fetched if the server is offering
> recursive service to the clients.
>
> It would also be possible when offering recursive service to perform
> prefetching on cache misses.
>
> It would also be possible to return A on  and  on A.
>
> It's up to the client to accept or ignore the records.
>
> Mark
> --
> 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] The Larger Discussion on Differences in Response Drafts

[Marek Vavruša]

On Thu, Aug 18, 2016 at 12:52 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> On 18 Aug 2016, at 11:29, Marek Vavruša wrote:
>
>> Or SRV.
>
>
> I disagree that a user, when asking for a SRV record, doesn't know that it
> is likely that they would want the results for the information that comes
> back in the RDATA.

No question about that, but she doesn't know what the target name is.
Expressing "I want SRV type for this name, and A/ for the SRV
record targets" is doable, at the cost of additional complexity on
both client and server.

>> These are cases where authoritative/resolver adding
>> interesting records as additionals works better.
>> Authoritatives have been doing that with extra SOA/NS in authority for
>> a while (for positive answers), but now
>> resolvers can hardly use them if these records are not secure.
>
>
> Security of additional data is important, but orthogonal to what can be
> asked for or pushed.
>
>> Regardless of which draft is going to be adopted,
>
>
> This thread is not about "which draft", it is about what is needed.

Thank you, I should have phrased that differently.

> --Paul Hoffman

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

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

[Marek Vavruša]

Or SRV. These are cases where authoritative/resolver adding
interesting records as additionals works better.
Authoritatives have been doing that with extra SOA/NS in authority for
a while (for positive answers), but now
resolvers can hardly use them if these records are not secure.

Regardless of which draft is going to be adopted, it should be
explicitly stated which records should client accept.
e.g. pushed A+ matching QNAME could be accepted even from insecure
zones, but records matching SRV target shouldn't be.

Marek

On Thu, Aug 18, 2016 at 10:57 AM, John Levine  wrote:
>>Are there QTYPEs that, when I ask for them, I won't know that I should
>>also ask for the related info?
>
> NAPTR
>
> ___
> 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] Working Group Last Call draft-ietf-dnsop-resolver-priming

[Marek Vavruša]

On Sun, Aug 14, 2016 at 4:27 PM, Paul Hoffman  wrote:
> On 5 Aug 2016, at 2:45, Shane Kerr wrote:
>
>> First, we have:
>>
>>   "If a priming query does not get a response within 2 seconds, the
>>   recursive resolver SHOULD retry with a different target address from
>>   the configuration."
>>
>> The "2 seconds" seems a bit arbitrary. I'm not sure why any
>> recommendations need to be made at all. The document already says that
>> these are basically normal DNS queries elsewhere - surely that is enough?
>> (And maybe if we do want to recommend a retry then we need to be clear
>> that if an answer comes from an earlier query that the resolver may
>> accept it?)
>
>
> It's sounding like people don't like the mention of a time at all. Proposed
> replacement:
>
> If a priming query does not get a response within a short time, the
> recursive resolver needs to retry the query with a different target address
> from the configuration.
>
> (I am avoiding saying "within a configured time" because I don't think this
> is easily configured in some common recursors.)

Since root-servers.net is not signed, recursor also has to deal with
compatibility problems, such as EDNS stripping for example. I wonder
how much should be clarified. I was a bit surprised the
root-servers.net is still unsigned, is this deliberate or what would
it take to sign it? It's a critical zone, and signing it would make
this draft much shorter.

Marek

>> Second, a possible additional security consideration is that a priming
>> query typically signals a resolver starting with an empty cache
>> (although not always - the Knot resolver has a persistent cache, for
>> example). This may be an especially vulnerable time for a resolver for
>> cache poisoning. I don't know what can be done to mitigate this though
>> aside from requiring TCP or DNS cookies for a time after startup, so
>> perhaps this can be left out.
>
>
> Proposed wording:
>
> An on-path attacker who sees a priming query coming from a resolver can
> inject false answers before a root server can give correct answers. If the
> attacker's answers are accepted, this can set up the ability to give further
> false answers for future queries to the resolver. False answers for root
> servers are more dangerous than, say, false answers for TLDs because the
> root servers are the highest node of the DNS.
>
> --Paul Hoffman
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Possible issues with DNS over HTTP wire format draft

[Marek Vavruša]

Hi,

On Mon, Aug 8, 2016 at 6:41 AM, Shane Kerr  wrote:
> Hello,
>
> There are a few suggestions about the DNS over HTTP draft made off-list,
> which I will try to characterize here:
>
> * We should expand the motivations to explain why DNS over HTTP makes
>   sense at all.
>
> * We should restrict the protocol to TLS.
>
> I am happy to expand the motivation section, although I am beginning to
> wonder if it will ever be enough. :)

There is enough motivation why someone would want DNS/HTTP, but not why does
it warrant a standard. The Section 1 in -00 said: "It simply serves as
a sort of DNS VPN" which is
quite accurate. We don't have a standard for DNS over IPSec or OpenVPN because
the carrier is not DNS agnostic (or doesn't have to be), like in this case.
While this draft solves a legitimate problem, it's still a blessed workaround.

> As for a requirement for TLS... the document currently says that
> implementers SHOULD use TLS. My own feeling is that this should be
> enough; apparently the recommendation to require TLS was made in the
> HTTP/2 working group and rejected, so I am not sure that we need to
> re-visit the entire discussion around the DNS over HTTP protocol.
>
> https://http2.github.io/faq/#does-http2-require-encryption
>
> Note that I do not have a strong preference here. This is a working
> group document, so if there is consensus for requiring TLS then that's
> how it is.
>
> A final oversight that occurred to me is that there should be a privacy
> section. This is because since the DNS over HTTP serves as a DNS
> resolver that all of the privacy considerations of a normal DNS
> resolver apply, and should be mentioned (probably referencing RFC 7626).
>
> Cheers,
>
> --
> Shane

Best,
Marek

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

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

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

[Marek Vavruša]

On Tue, Jul 12, 2016 at 11:03 AM, John R Levine  wrote:
>>> The reason to use TCP framing is so that you can send multiple DNS
>>> requests
>>> in a single http request and get back multiple answers.  Recent messages
>>> here suggest that's of considerable interest, and if you're only sending
>>> one
>>> request, the two bytes of TCP length are tiny compared to the http
>>> headers.
>
>
>> Maybe I'm still missing something - so you pack multiple DNS requests in
>> single HTTP request, answer#1 takes 5s, answer#2 timeouts, the rest is
>> answered from cache. How do you send back the fast answers first without
>> blocking when you have just a single HTTP request outstanding?
>
>
> The obvious way would be to send chunked http responses as the answers come
> back.  See section 4 of RFC 7230.  The DNS responses don't have to be in
> order.

Great, so you get a couple of queries from DNS/TCP stream and batch
them into HTTP request,
now you get additional query but your HTTP connection is already
blocked and you have to start a new one
or wait. After all this is just an optimisation game, perhaps I'm
foolish to pursue it, but (for me) it's important to define the
requirements before we end up with a long tail of weak
implementations.

> I don't think anyone sees DNS over http as a general replacement for
> ordinary DNS.  I see two plausible scenarios:
>
> * The most likely is javascript apps that want to look up SRV or NAPTR or
> something, but can only make http/s requests back to the place the js files
> came from.
>
> * The other is an application that wants to make it hord to observce its DNS
> queries, so it uses https to a trusted proxy.
>
> This should be fine for both of those.
>
> R's,
> John

I hope these would be the cases, I thought about search engine results
page pushing resolved addresses (secured) for search results ahead of
time, but using packed DNS wire format for this is not terribly great.
It looks like the motivation is to get around DNS firewalls and
filters, which implies deploying a scattered
set of "open" resolvers similar to dnscrypt to get around IP blocking.
Performance should matter in this case.

Marek

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

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

[Marek Vavruša]

On Tue, Jul 12, 2016 at 8:45 AM, John R Levine  wrote:
>>> My main suggestion is to lose the Proxy-DNS-Transport header and
>>> always have the request and response in TCP format.
>>
>>
>> The HTTP payload should always be unframed (like DNS over UDP) regardless
>> of the upstream DNS transport, since HTTP already provides content-length
>> framing so there's no need to repeat the message length. Like TCP, the
>> EDNS0 UDP buffer size is irrelevant for HTTP.
>
>
> The reason to use TCP framing is so that you can send multiple DNS requests
> in a single http request and get back multiple answers.  Recent messages
> here suggest that's of considerable interest, and if you're only sending one
> request, the two bytes of TCP length are tiny compared to the http headers.

Maybe I'm still missing something - so you pack multiple DNS requests
in single HTTP request,
answer#1 takes 5s, answer#2 timeouts, the rest is answered from cache.
How do you send back
the fast answers first without blocking when you have just a single
HTTP request outstanding?

> It occurs to me that this crock is not inherently much slower than regular
> TCP over DNS.  In both cases the client opens a connection and sends out the
> request, and the server sends back the answer.  In both DNS and most
> versions of http you can leave the connection open and reuse it, probably
> more important in http since you're likely reusing the TLS negotiation too.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

[Marek Vavruša]

On Mon, Jul 11, 2016 at 10:39 PM, John R Levine  wrote:
>> for a web to DNS proxy to decide to send a reply back, it would need to
>> consider it complete?
>>
>> Or are you proposing that the http server would start streaming back the
>> payload as it received the (possibly out of order) replies?
>
>
> I was thinking that the proxy would get all the queries from the DNS
> request, deal with them however it wants, maybe stuff them to a nearby DNS
> cache with TCP if it pipelines properly, or split them up into separate
> requests if it doesn't, then collect the responses and send them back when
> it has them, which I guess would constitute streaming.  RFC 7766 says that
> out-of-order is fine.

Without HTTP/2 each request, clients would need to start a separate
connection to get parallel processing, which means TCP handshake and
potentially a TLS and more bookkeeping code. So client makes requests
to proxy over HTTP/2 to mitigate the costs (here 7766 doesn't apply).
Then proxy translates incoming HTTP/2 multiplexed requests into either
DNS/TCP queries to origins (here 7766 helps)  or plain old DNS
(additional costs and bookkeeping). Server sends back DNS responses to
proxy, which in turn translates them to DNS/HTTP answers. So both
DNS/TCP out-of-order processing and DNS/HTTP out-of-order processing
is desirable here.

> I suppose with http/2 we get two-way streaming more or less for free.
>
> R's,
> John

Yep, the proxy can also push DNS answers to client ahead of time,
which is interesting and something DNS servers can't do right now. On
another note - this proposal kind of competes with DNS over HTTP
encoded in JSON. While that one doesn't transport exact byte-by-byte
DNS messages, it's much more consumer-friendly and elegant than
piggybacking binary data. I wonder why that one is not getting more
attention.

Marek

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

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

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

[Marek Vavruša]

RFC 7766 is about DNS/TCP not about DNS/HTTP, the order of processing
has to be determined by the wrapping protocol. You would get it for
free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but
it's not.

Marek


On Mon, Jul 11, 2016 at 10:32 PM, John R Levine  wrote:
>>> Don't you get this automatically if it's treated as a TCP DNS
>>> connection?  You stuff a bunch of requests down the pipe, and you get
>>> back a bunch of responses.
>>> See RFC 7766.
>
>
>> You get queueing for free, but not pipelining and out-of-order
>> responses, that has to be defined.
>
>
> RFC 7766 says you should get pipelining and out-of-order responses on TCP
> DNS.  Take a look.
>
> Even if the underlying DNS server that the proxy is using can't do it, any
> newly written proxy should provide TCP DNS the way 7766 says it should.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.

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

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

[Marek Vavruša]

On Mon, Jul 11, 2016 at 10:06 PM, John Levine  wrote:
>>So I suggest some thought should be given to reducing round-trips by
>>allowing for multiple DNS request payloads in a single HTTP request
>>message, and multiple DNS response payloads in an HTTP response message.
>
> Don't you get this automatically if it's treated as a TCP DNS
> connection?  You stuff a bunch of requests down the pipe, and you get
> back a bunch of responses.
>
> See RFC 7766.
>
> R's
> John

You get queueing for free, but not pipelining and out-of-order
responses, that has to be defined.
The draft mentions this, but I think at this point it should just
depend on HTTP/2,
as it's the only way to get decent performance from resolvers but high
variance in response time,
and request semantics in both is different and needs to be defined,
i.e. what happens when client cancels
in-flight query, what happens when server resolver pushes response.

Marek


> ___
> 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] Working Group Last Call: draft-ietf-dnsop-nxdomain-cut

[Marek Vavruša]

On Wed, Jun 22, 2016 at 1:52 AM, Mark Andrews  wrote:
>
> In message 
> 

Re: [DNSOP] naming and shaming broken implementations

[Marek Vavruša]

Naming and shaming is not the only mechanism for change, and it's not
effective when things "work". Sunsetting and deprecating parts of
protocols (like IQUERY or TYPE=ANY) is more important as it helps not
only to keep the protocol concise, but also forces evolution of
protocol implementations (or at least brings implementors back for
discussions).

Marek

On Wed, Jun 22, 2016 at 3:36 AM, Jim Reid  wrote:
>
>> On 22 Jun 2016, at 11:13, Stephane Bortzmeyer  wrote:
>>
>> It is not "fun", it is the only way to have broken implementations
>> (Akamai, djbdns) fixed. If we do not name them, they will continue
>> forever.
>
> I doubt that will help Stephane. djbdns has been broken for ~20 years -- no 
> AXFR, no EDNS0, no TCP/53, no DNSSEC, no TSIG, etc, etc -- and likely to be 
> that way forever. DJB no longer supports or maintains the software, apart 
> from fixing security vulnerabilities IIUC. So the DNS is probably always 
> going to be stuck with that abandonware being in the state it was in at its 
> last "stable release" in 2001.
>
> The best we can hope from naming and shaming is to encourage people to keep 
> away from implementations that are broken and/or cause serious 
> interoperability issues. Whether that advice will get heard and acted on is 
> another matter of course. Darwinism will eventually take care of the poor DNS 
> deployment choices anyway.
>
>
> ___
> 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] Root server tar pitting? Is there a better way?

[Marek Vavruša]

Why not run a local copy of the root? It should be a good practice for
large recursives, plus you get better latency.

Marek

On Mon, May 16, 2016 at 2:34 PM, Wessels, Duane  wrote:
> Hi Brian,
>
> I think what you're suggesting has already been proposed.  See 
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ and 
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/
>
> DW
>
>
>> On May 16, 2016, at 2:23 PM, Brian Somers  wrote:
>>
>> Hi folks,
>>
>> I work at OpenDNS.  We saw a DoS attack in Miami on Friday night around 
>> 10-11:00pm PST, consisting of UDP DNS requests for AAA.BBB.CCC.DDD where 
>> each of AAA, BBB, CCC and DDD are three digit numbers not greater than 500.
>>
>> Each query was answered with an NXDOMAIN by the root servers,   Although our 
>> resolvers cached the NXDOMAIN for 1 hour (we cap negative responses at 1 
>> hour despite the larger SOA MINIMUM) it was ineffective in reducing the load 
>> on the root servers as every varying query was another root server request.
>>
>> We eventually blackholed all TLDs from 000 to 500 to stifle the problem 
>> (locally delegating them to 127.0.0.1 where we don’t listen).
>>
>> However, during the attack, we also saw a huge number of TCP sockets in 
>> TIME_WAIT talking to root servers (probably all root servers).  I’m curious 
>> if
>>
>> 1.  Are root servers doing some sort of tar pitting where they send a TC and 
>> then firewall port 53?
>> 2.  Has anyone ever considered a better way than responding with NXDOMAIN?
>>
>> The second is a loaded question, but it occurs to me that a new type of 
>> negative response to (say) 111.222.333.444/IN/A might be an NXDOMAIN with an 
>> SOA record (as we do now) but also with an indicator that 444 and below are 
>> NXDOMAINs.  I’m not sure what that might look like, maybe "444/IN/NS .” in 
>> the AUTHORITY section where “.” is the NS value meaning that 444 is actually 
>> delegated to nobody.
>>
>> Thoughts/comments?
>>
>> —
>> Brian
>> ___
>> 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] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Fri, Mar 25, 2016 at 7:51 PM, John Levine  wrote:

> >As I think many here know, I am not of the get-off-my-lawn persuasion
> >for DNS innovations.  I don't think it's a bad idea in principle.  I'm
> >just aware that we have this long history, and that history was based
> >on a certain kind of conservatism that is arguably appropriate to a
> >technology quite as fundamental to the Internet functioning as the DNS
> >is.  If we're going to abandon that conservatism, I think it needs
> >quite a lot more early IETF buy-in than we might get by developing
> >this work here in DNSOP.  The more signal we can get to suggest that
> >DNS actors are ok with the innovation, the lower I think that bar gets.
>
> I'd be a lot more comfortable if we had some field test data about
> what real DNS caches do with the extra  records.  In theory
> nothing bad should happen, in practice ...
>
> R's,
> John


I agree, working on it.

Marek

___
> 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] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Hi Andrew, first of all - thanks for being constructive.

On Wed, Mar 23, 2016 at 6:07 AM, Andrew Sullivan <a...@anvilwalrusden.com>
wrote:

> Hi,
>
> On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> > Me and Olafur wrote a draft on adding  records to A answers and
> > treating them as authoritative.
>
> The last time this was proposed, in DNSEXT when Olafur was co-chair,
> the proposal was rejected on the following grounds:
>
> 1.  We had no idea what resolvers who weren't expecting the 
> in the Answer section would do.  This draft says what is "more
> likely", but I have no way of evaluating that claim.  Without an
> EDNS0 signal, I think this proposal is pretty dangerous.


We have a way of measuring DNSSEC algorithms penetration, QNAME
minimisation-enabled resolvers etc., thus also a way to evaluate this
claim. I'm setting up a special domain using this I-D and then we can use
RIPE Atlas or 1x1 test, should Google or someone be interested in testing
this.

2.  It isn't clear what a cache is supposed to do when it gets an
> A and has a  already in cache, particularly if there isn't an
> A record.  This draft is far too sketchy on that case.  Can the
>  satisfy queries for ?  (I think section 4 says yes, but
> it's a little terse.)
>

The draft suggests following 2181 and all these records should be treated
as authoritative.
I'm comfortable with shoving the  into authority/additional which would
lower their rank and
 query would replace them.


>
> 3.  This amounts to special server-side processing, and there'd
> been a traditional resistance to
>

I'm happy to back this with patches.


>
> 4.  The proposal had been made several times before, and always
> rejected; what's different this time?  (This argument always
> seemed the weakest to me.)
>

With all respect, I'm not in a position to be an IETF librarian.
I'm happy to discuss this draft and whether it has any merit or not.
If it's coming back then it means the idea is probably interesting,
as for me the proposition of cutting query rate for most sought-after
QTYPEs in half is too good to be ignored.

Making it optional behaviour the way this proposal does seems to
> introduce quite a lot of confusion.  Is a happy-eyeballs resolver
> supposed to take the non-existence of the  in the answer as some
> sort of evidence that the  is never coming?  (I think this
> proposal says, "No," but I'm sceptical that's what will happen.)  Why
> doesn't happy eyeballs do what is necessary here?
>

For TTL, yes, if the authoritative provides non-existence proof.
"Happy eyeballs" means a resolver will maybe get both answers in ~ same RTT,
this I-D means it will have to send only half of the queries to get this
information.
Talking to upstream is the most expensive operation for resolver next to
signature
verification.


> I think I'd feel a lot more comfortable with anything along these
> lines if there were a signal from the resolver stating that it knows
> what to do, but that still brings up server-side processing.
>
> Best regards,
>
> A
>

I admit I'm not a big fan of EDNS, but I'm okay with using it if I'm proven
that resolvers will panic
on a sight of different record in any of the packet sections. Shoving the
records into NS/AR and thus
degrading their 2181 trustworthiness rank would be a better compromise to
explore first.

Best,

M



>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> 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] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Tue, Mar 22, 2016 at 2:03 PM, Shane Kerr <sh...@time-travellers.org>
wrote:

> Marek,
>
> At 2016-03-22 12:12:08 -0700
> Marek Vavruša <mvavr...@cloudflare.com> wrote:
>
> > 2. Behavior of stubs is not explicit in the draft
> >
> > I should have stated this explicitly, the draft doesn't update behaviour
> of
> > stub resolvers. In my opinion, they should use the most basic form of DNS
> > and work only over local or trusted network, hence no latency issues.
>
> 8.8.8.8 isn't local or trusted, and is the largest resolver in the
> world. ;)
>
> One other important issue is that that the resolver main bottleneck is
> in packets/second, so reducing the total number of queries - potentially
> by half, but conservatively by a quarter - seems like too big of a win
> to ignore.
>
> Specifying resolver behavior when answering queries would be more
> difficult. Not impossibly so, but more complex.


Fair enough. As I wrote in the previous email, I meant stub as in
getaddrinfo() not forwarders, so hopefully that answers the question.
Public resolvers in 2016 are bizarre but that's what we got.


>
> > 2. Stubs and recursors during NS resolution issue parallel queries
> >
> > That is correct, the draft expects software changes if accepted. Saying
> > that it doesn't have any effect is not entirely true though. The latency
> is
> > max(rtt_a, rtt_) in the best case and one of the queries time out or
> is
> > blocked in the worst case. In addition, this doubles query rate on
> > authoritatives and requires more logic on clients (which is error prone -
> > see latest glibc bug), especially when one of the replies gets
> ratelimited,
> > truncated or answered from different node. On the contrary, waiting for
> > single answer is simple.
>
> I don't think this makes things too much more complicated on the
> client, especially with happy eyeballs being best practice these days.
> We kind of expect clients to do all kinds of crazy asynchronous shit,
> both with DNS and other network traffic.
>

It's all dandy until the resolution path diverges :)


> Anyway, this (parallel A and ) is the main reason that people have
> always argued against combined A and  queries, and it seemed to
> make sense. However, since a resolver can remember which authoritative
> servers combine A and  answers, there should be a gain here (I mean,
> resolvers have to remember all kinds of stuff about authoritative
> servers anyway).
>
> > 3.  query doesn't offer A records
> >
> > That is a valid point. Long answer: I think the logic of clients asking
> for
> > IPv6 is flawed from the get-go. For a smooth protocol version upgrade,
> > authoritatives should have had a way to push IPv6 on clients instead of
> > waiting for them to ask for it. The A record is unfortunately defined as
> a
> > 32-bit Internet address. I think it should be redefined as "Internet
> > address". This way, if a client wants to ask a server about IP address,
> it
> > would _always_ use an A query and get a list of A,  and possibly
> > something new. It would be up to client's discretion to pick an address
> > version that it understands. The benefit of this is that it doesn't
> require
> > additional queries or major client-side changes. Somebody has said IPv6
> is
> > here to stay, I'd like to share this certainty. Meta-types (sort of what
> I
> > want an A to become) are considered bad, but DNS was built around name to
> > address translation so optimising for this case might be worth it.
> Offering
> > A records for  drags the need for backward compatibility (even more
> if
> > we ever have a newer address record) and more code exceptions.
>
> Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> killed ANY and then gave us ANYA ("any address"). ;)
>
> Cheers,
>
> --
> Shane
>

Right, it sounds a bit ironic doesn't it? Semantics of ANY isn't really
great a differs per type of server,
more so it is expensive as DNS gravitates towards key-value type storage. I
was hoping to get away
with a simple semantic change for A as it keeps the original meaning (get
an IPv4 address) untouched, while
extending it with harmless "throw in any other IP addresses as well". I
could be wrong though.

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Tue, Mar 22, 2016 at 1:20 PM, Mark Andrews  wrote:

>
> In message 

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Thanks everybody for comments! It's a lot so I'll try to rephrase and
answer the questions below.

1. No signalling to client when  is unavailable

I didn't want to include it in the beginning but I see it has a merit.
DNSSEC has means to provide authenticated non-existence for free, so I
think it's worth for auth server to add either data or non-existence proof
for any applicable RR.
e.g. if it has , but not A, it would provide  RRs and NSECX for A;
if it has A but not , it would provide A RRs and NSECX for 

For legacy case of no DNSSEC, an SOA in the authority indicates that no
record matching QNAME+QTYPE exists, but can't effectively signalise
non-existence of the additional address records. Which is not great, but
I'm not in for legalising yet-another EDNS option, and it also would
require client to signalise that it can handle such option before an auth
server raises it in the answer. For this case specifically, I am okay with
client making additional  query to recheck.
To defense: resolvers keep track of auth functionality (ability to do EDNS,
IPv6 availability, ...), this is not any different. If the auth shows that
it either supports this (by at least one positive case) or not (this case),
resolver will remember it and act accordingly next time.

2. Behavior of stubs is not explicit in the draft

I should have stated this explicitly, the draft doesn't update behaviour of
stub resolvers. In my opinion, they should use the most basic form of DNS
and work only over local or trusted network, hence no latency issues.

2. Stubs and recursors during NS resolution issue parallel queries

That is correct, the draft expects software changes if accepted. Saying
that it doesn't have any effect is not entirely true though. The latency is
max(rtt_a, rtt_) in the best case and one of the queries time out or is
blocked in the worst case. In addition, this doubles query rate on
authoritatives and requires more logic on clients (which is error prone -
see latest glibc bug), especially when one of the replies gets ratelimited,
truncated or answered from different node. On the contrary, waiting for
single answer is simple.

3.  query doesn't offer A records

That is a valid point. Long answer: I think the logic of clients asking for
IPv6 is flawed from the get-go. For a smooth protocol version upgrade,
authoritatives should have had a way to push IPv6 on clients instead of
waiting for them to ask for it. The A record is unfortunately defined as a
32-bit Internet address. I think it should be redefined as "Internet
address". This way, if a client wants to ask a server about IP address, it
would _always_ use an A query and get a list of A,  and possibly
something new. It would be up to client's discretion to pick an address
version that it understands. The benefit of this is that it doesn't require
additional queries or major client-side changes. Somebody has said IPv6 is
here to stay, I'd like to share this certainty. Meta-types (sort of what I
want an A to become) are considered bad, but DNS was built around name to
address translation so optimising for this case might be worth it. Offering
A records for  drags the need for backward compatibility (even more if
we ever have a newer address record) and more code exceptions.

Marek

On Tue, Mar 22, 2016 at 8:55 AM, Shumon Huque <shu...@gmail.com> wrote:

> On Tue, Mar 22, 2016 at 7:41 AM, Tony Finch <d...@dotat.at> wrote:
>
>> Marek Vavruša <mvavr...@cloudflare.com> wrote:
>> >
>> > there was an interest in reducing latency for address record lookups.
>> > Me and Olafur wrote a draft on adding  records to A answers and
>> > treating them as authoritative. This fixes latency issues with NS
>> > A/ discovery in resolvers and improves caching for clients (
>> > already cached by the time client comes asking for it).
>>
>> Regarding NS discovery, you should be aware that BIND queries for name
>> server A and  concurrently. So this draft would just make packets
>> bigger without helping latency.
>>
>
> It's worth noting that several "happy eyeballs" style APIs issue
> concurrent
> /A queries also, like the Apple connect-by-name APIs. Also getdns
> does this.  and A go out back to back, put typically  is put out
> on the wire first.
>
> --
> Shumon Huque
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

I see the point but I don't really want to go down the EDNS route.
So presuming that this draft catches on and Alexa 1M NSs publish at least
one  record,
there would be no need for two queries in most cases and no need for
additional signalisation.
If they don't publish  records, then the resolver will still have to do
the same thing as today,
however that also means that IPv6 adoption is stalled and possibly
irrelevant.

TL;DR the draft optimises first case, if the second case proves to be valid
then we can always amend the draft but I don't want to overengineer it from
the start and it's always much easier to add than to remove.

Marek


On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews  wrote:

>
> Or we could defined the "aaa" (A and ) {E}DNS bit where the
> server guarantees that the response contains both the A and 
> answers for A or  queries if aaa=1 in the response.
>
> Recursive servers would lookup A/ records if cache is missing
> them before returning a response.
>
> If the A /  does not fit into the additional section then TC=1
> is set.
>
> NOERROR NODATA is valid for both types if aaa=1 in the response.
>
> This way you could signal that you want both A and  records and
> if you don't want both then the response does not have the other
> type added.
>
> Yes, we would have to nuke the stupid servers that reflect back
> {E}DNS flags.  We would also have nuke the stupid firewalls that
> block {E}DNS queries with a unknown flag bit set.
>
> Mark
>
> Mark Andrews writes:
> >
> > Well we really want to get rid of A lookups.   Why don't we just
> > recommend that we publish mapped A records in  RRsets and have
> > master servers update  RRsets if they are inconsitent with the
> > A RRsets.
> >
> > We also need a way to signal that there are no A records in the
> >  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> > sensible records to indicate this.
> >
> > Mark
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> --
> 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] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters <p...@nohats.ca> wrote:

> On Mon, 21 Mar 2016, Marek Vavruša wrote:
>
> there was an interest in reducing latency for address record lookups. Me
>> and Olafur wrote a draft on adding  records to A answers and treating
>> them as authoritati
>> ve. This fixes latency issues with NS A/ discovery in resolvers and
>> improves caching for clients ( already cached by the time client comes
>> asking for it).
>>
>> Comments, feedback and snarky remarks would be great!
>>
>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>>
>
> I think this draft is a good idea. It does need some more writing out of
> the use case and the possible interaction with some of the answer
> sections. And some additional guidance with CNAME's with and without
> DNSSEC.
>

Agreed, thanks for taking time commenting.


> Some comments/questions:
>
>
> What happens with the Answer Count for QTYPE=A when there are no A
> records and only  records? And can the examples also clarify this?
>
>
That's an example 5.3


> What is the logic behind:
>
>However, if there is a direct answer to the original question, but no
>records for other address protocols, the authoritative DNS server
>SHOULD NOT prove their non-existence.  In this respect, they are
>treated as additional data.
>
> Are you just afraid of packet size to include the proofs? Because now
> a client cannot distinguish between an old auth server not supporting
> this draft and a new server supporting this draft (when no additional
> A/ exist to add). So if it wants to know about the other QTYPE,
> it will need to make another query, even for auth servers implementing
> this draft. Which is exactly what this draft is trying to prevent.
>

The proposal is opt-in, if the authoritative decides to throw in 
addresses
then client should accept them. If it doesn't then it should requery. This
is of course
going to reduce the effectiveness in the transition period for names that
have A, but don't have 
which is something I expect to change.

The rationale is not to carry unnecessary payload when most authoritatives
support it, but you make a good point
that it might be better to mandate denial of non-existence proof now, and
amend the draft later.


> What is SNAME? Did you mean QNAME?
>

SNAME as in RFC1034, either QNAME or CNAME chain terminal name.

I'm also a little confused that section 3 auth servers only talks about A
> and section 4 recursive servers only talks about . I like short
> documents but I think you need to write this out a bit more :)
>
>
>and it MUST reject any such records if the validation
>fails, and the zone is not provably secure.
>
> That's awkwardly written. If the zone is not provably secure (which is a
> term you should not use, and instead use Bogus, Indeterminate. Insecure
> or Secure) then there is nothing to validate - if you meant Insecure. If
> you meant Indeterminate or Bogus, other text is warranted.
>
> I think you mean to say if the zone _is_ secure, then any records in it
> must be proven secure too.
>

Fair enough!

   other IP address records
>
> You mean other QTYPE's for IP addresses :P
>
>
> I don't think the Security Considerations use case mentioned is worth
> mentioning. What is worth mentioning is if this involves CNAMEs,
> because that leads to out of bailiwick data. And complications with
> DNSSEC (chains to other zones?) and without (free Kaminsky attack)
>
> Paul
>

The CNAMEs should be covered by the SNAME part, owner has to either match
QNAME or terminal of CNAME chain just as a direct answer would. Maybe it
needs a clarification.

Thanks!

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Who wants to get rid of A lookups? "A" is going to be here for a while and
using it as a generic mean to get all addresses of given protocol
(regardless of version) gives servers a way to smoothly transition over
versions.
If the A was updated to have a variable address length, then it could be
used to hand out any address with different RDLEN instead of making new
type. I'm dreading of a day when somebody implements A,, and 
lookup in glibc stub in parallel.

On Mon, Mar 21, 2016 at 4:58 PM, Mark Andrews  wrote:

>
> Well we really want to get rid of A lookups.   Why don't we just
> recommend that we publish mapped A records in  RRsets and have
> master servers update  RRsets if they are inconsitent with the
> A RRsets.
>
> We also need a way to signal that there are no A records in the
>  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> sensible records to indicate this.


Do we need that? I'd be happy if clients use just A for IP lookups, and
then use
 if only  falls out of cache. Can't think of a good use case.


>
> Mark
>
> --
> 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] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Hi,

there was an interest in reducing latency for address record lookups.
Me and Olafur wrote a draft on adding  records to A answers and
treating them as authoritative. This fixes latency issues with NS
A/ discovery in resolvers and improves caching for clients (
already cached by the time client comes asking for it).

Comments, feedback and snarky remarks would be great!
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/

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