Re: [DNSOP] Minimum viable ANAME

[Dan York]

> On Mar 26, 2019, at 7:23 PM, Brian Dickson  
> wrote:
> 
> We need to start with the base requirements, which is, "I want an apex RR 
> that allows HTTP browser indirection just as if there was a CNAME there”.

Yes, THIS. 

In response to the discussion last November, I put together this draft 
outlining the views of one publisher of a set of websites (me):

https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01

For reasons outlined in that draft, I want to use a CDN in front of my sites, 
but I also want to retain control of operating my own DNS. (I.e. I don’t want 
to have the CDN also do the DNS hosting for me, too.).

To use a CDN while retaining DNS control, most CDNs require you to set up a 
CNAME pointing to some URL they give you.  When a person then visits that URL, 
the CDN does its own magic inside its own DNS services to provide the visitor 
with the A or  record of the edge server closest to the visitor.

This all works perfectly fine if you use a subdomain such as “www.”. You just 
use a CNAME record and all is fine.

But if you want to drop the “www.” and just use the domain name (example.com), 
then we don’t have any standardized way to do a CNAME-like function at the apex 
of the zone. 

Because this is a common business requirement, most DNS hosting providers / 
operators provide some proprietary method of doing this kind of redirection. 
Either that or a company has to create their own redirection server (something 
we did). Either way, you are locked into a proprietary system with issues I 
outlined in that draft.

As Tim Wicinski mentioned in his review of documents today in DNSOP, this is 
not a simple problem to solve and there are some fundamental (and passionate) 
disagreements about the way forward. 

Tim’s suggestion of an interim (presumably virtual?) to focus specifically on 
this issue seems to make sense to me.

As I stated in the draft, I don’t personally have an opinion (yet, anyway) 
about solutions. I just want something that works and can be rapidly deployed 
and used…. so that I can be using a standard RR type instead of proprietary 
solutions.

That’s it,
Dan  (who just last month deployed a new website and immediately had people 
asking him when it would work without the “www.” in front of it… so we had to 
rapidly go and get that set up)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Minimum viable ANAME

[Tony Finch]

> On 26 Mar 2019, at 18:23, Brian Dickson  wrote:
> 
> The options are, new RRtypes that require resolver upgrades, or RRtypes that 
> are handled by the client application (browser), which benefit from (but do 
> not require) resolver upgrades.

The current draft is neither of those (and I think maybe you excluded it from 
your list because you don’t consider it viable, for good reasons, but...)

Whatever new thing we come up with, my view is that it will need sibling 
address records for backwards compatibility, otherwise no-one can deploy it. 
(Or at least, that new thing won’t make my job easier any time soon.) So there 
has to be some kind of provisioning or authoritative hack to make it easy to 
automatically add address records that have the same effect as the ANAME or 
HTTP record that they are supporting. (Remember, the existing non-standard 
alias stuff exists because it is easier than standard DNS.)

Ray Bellis thinks (quite reasonably) that there is a good chance that an HTTP 
specific record can be deployed fairly quickly, because browser upgrades are 
impressively fast these days. I’m less enthusiastic about telling DNS admins to 
look at caniuse.com before they decide whether to put in an HTTP record.

(On the gripping hand, based on the support queries I have answered, an HTTP302 
record [an http redirect in the dns] would be a lot closer to what many 
webmasters expect!)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at


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

Re: [DNSOP] Minimum viable ANAME

[Olli Vanhoja]

On Tue, Mar 26, 2019 at 9:20 PM Brian Dickson
 wrote:
>
>
>
> On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja  wrote:
>>
>> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
>> > We need to start with the base requirements, which is, "I want an apex RR 
>> > that allows HTTP browser indirection just as if there was a CNAME there".
>> > Sibling records do not behave like CNAMEs, no matter what extra hacks get 
>> > applied; CNAME processing is done by the resolver.
>> > The options are, new RRtypes that require resolver upgrades, or RRtypes 
>> > that are handled by the client application (browser), which benefit from 
>> > (but do not require) resolver upgrades.
>> >
>>
>> I see a huge problem there, let's call it IPv6 problem. During the
>> transition phase to this new RR we need to have a fallback, right? How
>> long do we need to have that fallback for old resolvers and browsers?
>
>
> I don't follow you.
>
> I'm advocating the latter of the two options, because it does not require 
> resolver upgrades.
> Thus, the "old resolvers" is a moot issue, as they would continue to be 
> compatible with the new types.
> The only expectation is that new resolvers would be more efficient, thus the 
> incentive (not requirement) is for the resolver operators. Or not, if they 
> don't particularly care.
>
> I also don't follow the "transition phase" logic, either.
>

Perhaps I misunderstood you. That's exactly what I'm hoping for,
compatibility with the old resolvers.

> I'm not sure how you see this involving DoH; it is an issue orthogonal to the 
> transport or the choice of recursive.

I mean, if there is something new that the client side needs to do to
get an IP address for a domain, then it could be implemented on a DoH
server. Though maybe in that case the client is updated already. Maybe
it would happen at an ISP instead over traditional DNS.

> An upgraded browser (which understands the new RRtype) would be able to 
> resolve the new type using an old resolver.
> Resolvers do not require upgrades to serve new types, as long as the new 
> types don't require special handling.
> These new types would not require special handling by the resolver, but 
> rather would have the special handling done by the browser.
> (That's kind of the whole point - eliminate the need for resolver upgrades.)
>

Well that's my point, if you need to do something new on the client
side, is it a resolver change or a browser change, it will make it
much slower transition. Would a big multinational company change to
this new way of resolving an IP address (and stop serving A records on
selected names) any time soon and risking losing possible customers?
The fallback here would be to just somehow serve a normal A record
that a client already understands.

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

Re: [DNSOP] Minimum viable ANAME

[Brian Dickson]

On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja  wrote:

> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
> > We need to start with the base requirements, which is, "I want an apex
> RR that allows HTTP browser indirection just as if there was a CNAME there".
> > Sibling records do not behave like CNAMEs, no matter what extra hacks
> get applied; CNAME processing is done by the resolver.
> > The options are, new RRtypes that require resolver upgrades, or RRtypes
> that are handled by the client application (browser), which benefit from
> (but do not require) resolver upgrades.
> >
>
> I see a huge problem there, let's call it IPv6 problem. During the
> transition phase to this new RR we need to have a fallback, right? How
> long do we need to have that fallback for old resolvers and browsers?
>

I don't follow you.

I'm advocating the latter of the two options, because it does not require
resolver upgrades.
Thus, the "old resolvers" is a moot issue, as they would continue to be
compatible with the new types.
The only expectation is that new resolvers would be more efficient, thus
the incentive (not requirement) is for the resolver operators. Or not, if
they don't particularly care.

I also don't follow the "transition phase" logic, either.

Clearly, there would not be compatibility between old browsers and new
RRtypes, since the support for the new types would be in the new browsers
exclusively.

The use of the new types would be controlled by the apex owners of each
individual domain.
Each domain would be free to switch to the new type whenever they wished; I
would expect it to follow the traditional curve of early adopters through
laggards...

This would be a case where there would be a need for deployment of new
browsers first, in order to enable the new record type.
Once there was a critical mass of deployed browsers, I'd expect uptake on
zone owners to follow, eventually creating pressure on laggards to upgrade
their browsers.

Non-upgraded browsers would lose access to names at zone apexes which use
the new type(s).


> I'd say approximately until DNS has been replaced by some other tech.
> If we are lucky DoH would solve it by doing what those previously
> mentioned companies are doing now on their servers, but then we would
> cry again that it's the wrong solution.
>

I'm not sure how you see this involving DoH; it is an issue orthogonal to
the transport or the choice of recursive.

An upgraded browser (which understands the new RRtype) would be able to
resolve the new type using an old resolver.
Resolvers do not require upgrades to serve new types, as long as the new
types don't require special handling.
These new types would not require special handling by the resolver, but
rather would have the special handling done by the browser.
(That's kind of the whole point - eliminate the need for resolver upgrades.)

In this context, "DoH would solve it" is both ambiguous, and largely
redundant, or erroneous.

If by DoH, you mean upgraded resolvers, then upgraded resolvers would be
doing "it"; DoH doesn't enter the picture at all, except as an optional
transport path. Except that without upgrading the browsers, the new RRtypes
would not be requested, and "it" would not work at all. With upgraded
resolvers and browsers both, the new RRtypes would work and have better
performance, but again, the DoH piece is unrelated and not required.

If by DoH, you mean upgraded browsers, then upgraded browsers would be
doing "it"; again, DoH doesn't enter the picture. At best, DoH would be
orthogonal to the new RRtype usage. It would be the support for the RRtype,
not the support for DoH, that would enable the new apex dns record type for
HTTP-specific aliasing.

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

Re: [DNSOP] Minimum viable ANAME

[Olli Vanhoja]

On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
> We need to start with the base requirements, which is, "I want an apex RR 
> that allows HTTP browser indirection just as if there was a CNAME there".
> Sibling records do not behave like CNAMEs, no matter what extra hacks get 
> applied; CNAME processing is done by the resolver.
> The options are, new RRtypes that require resolver upgrades, or RRtypes that 
> are handled by the client application (browser), which benefit from (but do 
> not require) resolver upgrades.
>

I see a huge problem there, let's call it IPv6 problem. During the
transition phase to this new RR we need to have a fallback, right? How
long do we need to have that fallback for old resolvers and browsers?
I'd say approximately until DNS has been replaced by some other tech.
If we are lucky DoH would solve it by doing what those previously
mentioned companies are doing now on their servers, but then we would
cry again that it's the wrong solution.

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

Re: [DNSOP] Minimum viable ANAME

[Brian Dickson]

On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja  wrote:

> On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát 
> wrote:
> >
> > I'm not convinced that the resolver parts will be important, regardless
> of what exact mechanism will be chosen.  My reasoning is that you can't
> rely on any changes there being widely deployed soon, and there might not
> be enough incentive to implement and deploy.  On the authoritative side, on
> the other hand, it's enough to just get support on all servers *you* use,
> and the incentives seem much stronger, too.
> >
> > --Vladimir
>
> I think it's totally wrong to *choose* here what we think is the best
> method to solve the issue. Note that ANAME/ALIAS/whatever is already
> widely deployed on the authoritative side i.e. DNS providers like AWS,
> PointDNS, DNSMadeEasy, Constellix, Cloudflare (on enterprise plans),
> and probably many others.
>

The problem with this assessment, is that those providers are *not* DNS
providers.
They are providers of incompatible, vertically integrated walled gardens.

As far as I understand it, even most of those providers would prefer a
standardized solution.

There are a number of problems around the current solutions, including
lock-in, inability to go multi-provider (on DNS), scalability, and a bunch
of other things.

Doing anything that looks and feels like taking any/all of their solutions,
putting them in an opaque box, wrapping it up, and putting a bow on it,
does nothing to address those issues.
That activity may be many things, but it is not the design of standards, it
is not interoperability, and it most certainly is not "DNS operations".

So, I have to say specifically, "I beg to differ."

We need to start with the base requirements, which is, "I want an apex RR
that allows HTTP browser indirection just as if there was a CNAME there".
Sibling records do not behave like CNAMEs, no matter what extra hacks get
applied; CNAME processing is done by the resolver.
The options are, new RRtypes that require resolver upgrades, or RRtypes
that are handled by the client application (browser), which benefit from
(but do not require) resolver upgrades.

(The above is the "Cliff Notes" version. If you want the long version, go
back in your email or on the WG mailing list archives, and look at the
thread from November of last year.)

BTW, I am happy to actually work on future drafts on this stuff, and even
to contribute code for PoC work. My coding is probably not quite up to
snuff for full implementation, but PoC, sure.

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

Re: [DNSOP] Minimum viable ANAME

[Vladimír Čunát]

On 3/26/19 6:01 PM, Olli Vanhoja wrote:

I think it's totally wrong to*choose*  here what we think is the best
method to solve the issue.


I think it goes the direction you'll like.  My understanding of the 
current plan (of open-source implementors) is to have an RFC specifying 
*as little* as possible, so that it can go through more easily while 
improving interoperability of different (authoritative-only) 
implementations.  In the first RFC at least. After we (dnsop) see 
experience from that, it may be clearer where to go next, if anywhere at 
all.


Please correct me if I'm wrong; I know there are people who know "the 
plan" in more detail.


--Vladimir

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

[DNSOP] ROOM CHANGE to TYROLKA - Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00

[Alexander Mayrhofer]

Hello everybody,

(sorry for crossposting, but the side meeting was mentioned during today's 
dnsop session).

I was able to organize a bigger room - the meeting will be held in TYROLKA. 
Date and Time remain unchanged (Wed, 2019-03-27, 14:00-15:00)

Thanks & enjoy your evening,
Alex


Von: Alexander Mayrhofer
Gesendet: Dienstag, 26. März 2019 11:13
An: reg...@ietf.org
Betreff: Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00, Room Paris

Hello everyone,

as mentioned during the regext WG session, i've organized a "SecurityLock / 
RegistryLock" side meeting. Meeting details are as follows:


-  Date: Wed, 2019-03-27

-  Time: 14:00 - 15:00

-  Location: Room "Paris" at the IETF venue

Unfortunately, remote participation won't be possible. I do understand that a 
beamer is available, though.

My plan for the Agenda would be as follows:


-  Security Lock / Registry Lock "problem space" introduction (Alex, 
10m)

-  Tour de Table of current/planned "Security Lock" features, brief 
description (2m each), eg:

o   How does the locking work (Who locks, how?)

o   How does the "approval" of changes work (Who approves, what happens to 
transactions?)

o   How does the "unlocking" work (Who unlocks, and how?)

o   Forms of authentication

-  Which areas could benefit from standardization? Discussion (20m)

-  Wrapup and next steps (10m)

I'm looking forward!

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

Re: [DNSOP] Minimum viable ANAME

[Olli Vanhoja]

On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát  wrote:
>
> I'm not convinced that the resolver parts will be important, regardless of 
> what exact mechanism will be chosen.  My reasoning is that you can't rely on 
> any changes there being widely deployed soon, and there might not be enough 
> incentive to implement and deploy.  On the authoritative side, on the other 
> hand, it's enough to just get support on all servers *you* use, and the 
> incentives seem much stronger, too.
>
> --Vladimir

I think it's totally wrong to *choose* here what we think is the best
method to solve the issue. Note that ANAME/ALIAS/whatever is already
widely deployed on the authoritative side i.e. DNS providers like AWS,
PointDNS, DNSMadeEasy, Constellix, Cloudflare (on enterprise plans),
and probably many others. Surely their implementations differ from
each other and what is exactly supported varies a lot, but regardless
of that these providers and their customers are already in consensus
about the key details. Me and many others will be using those
providers no matter whether there will be an RFC or not. Zone
transfers will be hard and feature parity will be lacking but at least
it somewhat works while we keep designing the perfecting Internet that
nobody else has time to wait for.

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

Re: [DNSOP] Minimum viable ANAME

[Vladimír Čunát]

On 3/26/19 5:10 PM, Tony Finch wrote:

I haven't seen any objections to support for ANAME in recursive servers
so I'm surprised you think that is problematic enough to be removed.


I'm not convinced that the resolver parts will be important, regardless 
of what exact mechanism will be chosen.  My reasoning is that you can't 
rely on any changes there being widely deployed soon, and there might 
not be enough incentive to implement and deploy.  On the authoritative 
side, on the other hand, it's enough to just get support on all servers 
*you* use, and the incentives seem much stronger, too.


--Vladimir

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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

On 3/26/19 5:10 PM, Tony Finch wrote:

Matthijs Mekking  wrote:


I think that would be the wrong direction.  I believe there is a need to
standardize the ANAME resolution process and so my suggestion would be to
reduce the scope by focusing just on how to do that on the provisioning side
(and leave secondary servers and resolvers out of scope for now).



From past discussions, I didn't think there was any way we could get

consensus on the provisioning side.

Dynamic lookups on authoritative servers are out, because it has to be
compatible with traditional secondaries.

Updates on the primary are out, because that doesn't scale to large
numbers of zones.

Sometimes a system might have known fallback addresses, but often it won't
(e.g. whether the DNS setup is or isn't coupled to a web provisioning
system).


All these things are contentious which is the reason why removing it 
from the scope will hopefully aid progress.  These can be resolved in a 
follow up document.



But I think it's reasonable to allow whatever provisioning mechanisms
there might be, provided the meaning of answers from auth -> rec have a
consistent meaning that resolvers can use. >
It's also really imortant that ANAME can work in multi-provider setups, so
there needs to be something approaching interoperable semantics for
importing a zone file into a provisioning system. (Though I think the
semantics will have to be very loose in this case, to allow for variations
between existing systems.)

I haven't seen any objections to support for ANAME in recursive servers
so I'm surprised you think that is problematic enough to be removed. My
understanding was that recursive support is seen as better than trying to
do all the tricks on authoritative servers.


Except for the slow deployment issue.



Tony.



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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

I stand corrected indeed, I just went to the mailing list to find the 
latest version of the draft and noticed there were many fundamental 
arguments.


Matthijs

On 3/26/19 5:19 PM, Tony Finch wrote:

Matthijs Mekking  wrote:


The last draft did not see a lot of comments.


I thought there was quite a lot of very informative and robust discussion
in November.

https://mailarchive.ietf.org/arch/msg/dnsop/fmMGXQA0ryaJdtjSCVEsQ9ZiF2M
https://mailarchive.ietf.org/arch/msg/dnsop/lC2ZW0lwME-RrvkpntRpJzWrLuc
https://mailarchive.ietf.org/arch/msg/dnsop/HGld_NMA0kKzcX3r8sNZiayVJRY

Tony.



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

Re: [DNSOP] Minimum viable ANAME

[Brian Dickson]

I think the one proposal was very client-specific, which kind of ruled it
out for a generic "aname" type.
That was Ray's "HTTP" RRtype, that I did a deep dive on.

Basically, you are correct; the easiest path forward would be for client
software upgrades to get actual DNS records (rather than rely on
getaddrinfo), and do the indirection following (similar to and inclusive of
CNAME and DNAME, in addition to the new "HTTP" type.)

It avoids requiring recursives do the extra handling (analogous to CNAME
chaining and ultimately returning A/, based on the original QTYPE)
It definitely is the case that there is anti-consensus on the original
ANAME spec which requires sibling records provisioned/populated/maintained
by authority servers -- which is basically fatal to the original ANAME
draft.

I would definitely be willing to work on a true reset of ANAME that goes in
the other direction. I suspect that's what Ray's reset will involve, and I
believe that any effort on the current ANAME before the reset, would likely
be wasted effort. I really want to avoid the issue where those who have, in
good faith, contributed significant effort, want to hold onto that work,
even if that work is ultimately counter-productive.

Please see the discussion on the list from November 2018 timeframe, on the
major issues

Thanks,
Brian

On Tue, Mar 26, 2019 at 5:10 PM Tony Finch  wrote:

> Matthijs Mekking  wrote:
> >
> > I think that would be the wrong direction.  I believe there is a need to
> > standardize the ANAME resolution process and so my suggestion would be to
> > reduce the scope by focusing just on how to do that on the provisioning
> side
> > (and leave secondary servers and resolvers out of scope for now).
>
> >From past discussions, I didn't think there was any way we could get
> consensus on the provisioning side.
>
> Dynamic lookups on authoritative servers are out, because it has to be
> compatible with traditional secondaries.
>
> Updates on the primary are out, because that doesn't scale to large
> numbers of zones.
>
> Sometimes a system might have known fallback addresses, but often it won't
> (e.g. whether the DNS setup is or isn't coupled to a web provisioning
> system).
>
> But I think it's reasonable to allow whatever provisioning mechanisms
> there might be, provided the meaning of answers from auth -> rec have a
> consistent meaning that resolvers can use.
>
> It's also really imortant that ANAME can work in multi-provider setups, so
> there needs to be something approaching interoperable semantics for
> importing a zone file into a provisioning system. (Though I think the
> semantics will have to be very loose in this case, to allow for variations
> between existing systems.)
>
> I haven't seen any objections to support for ANAME in recursive servers
> so I'm surprised you think that is problematic enough to be removed. My
> understanding was that recursive support is seen as better than trying to
> do all the tricks on authoritative servers.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> safeguard the balance of nature and the environment
>
> ___
> 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] Minimum viable ANAME

[Tony Finch]

Matthijs Mekking  wrote:
>
> The last draft did not see a lot of comments.

I thought there was quite a lot of very informative and robust discussion
in November.

https://mailarchive.ietf.org/arch/msg/dnsop/fmMGXQA0ryaJdtjSCVEsQ9ZiF2M
https://mailarchive.ietf.org/arch/msg/dnsop/lC2ZW0lwME-RrvkpntRpJzWrLuc
https://mailarchive.ietf.org/arch/msg/dnsop/HGld_NMA0kKzcX3r8sNZiayVJRY

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Variable,
mainly west or northwest, 3 or 4. Smooth or slight. Fair. Good.

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

Re: [DNSOP] Minimum viable ANAME

[Tony Finch]

Matthijs Mekking  wrote:
>
> I think that would be the wrong direction.  I believe there is a need to
> standardize the ANAME resolution process and so my suggestion would be to
> reduce the scope by focusing just on how to do that on the provisioning side
> (and leave secondary servers and resolvers out of scope for now).

>From past discussions, I didn't think there was any way we could get
consensus on the provisioning side.

Dynamic lookups on authoritative servers are out, because it has to be
compatible with traditional secondaries.

Updates on the primary are out, because that doesn't scale to large
numbers of zones.

Sometimes a system might have known fallback addresses, but often it won't
(e.g. whether the DNS setup is or isn't coupled to a web provisioning
system).

But I think it's reasonable to allow whatever provisioning mechanisms
there might be, provided the meaning of answers from auth -> rec have a
consistent meaning that resolvers can use.

It's also really imortant that ANAME can work in multi-provider setups, so
there needs to be something approaching interoperable semantics for
importing a zone file into a provisioning system. (Though I think the
semantics will have to be very loose in this case, to allow for variations
between existing systems.)

I haven't seen any objections to support for ANAME in recursive servers
so I'm surprised you think that is problematic enough to be removed. My
understanding was that recursive support is seen as better than trying to
do all the tricks on authoritative servers.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
safeguard the balance of nature and the environment

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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

Hi Tony,

On 3/26/19 4:32 PM, Tony Finch wrote:

I'm overloaded at the moment so I wasn't able to rev the draft in time for
IETF 104. I was planning to (basically) re-focus on the meaning of the
bits on the wire, and remove any requirements about how zone contents are
provisioned. Instead there would be a series of examples of existing
ANAME-like systems.


I think that would be the wrong direction.  I believe there is a need to 
standardize the ANAME resolution process and so my suggestion would be 
to reduce the scope by focusing just on how to do that on the 
provisioning side (and leave secondary servers and resolvers out of 
scope for now).


Matthijs



Tony.



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

Re: [DNSOP] Minimum viable ANAME

[Tony Finch]

I'm overloaded at the moment so I wasn't able to rev the draft in time for
IETF 104. I was planning to (basically) re-focus on the meaning of the
bits on the wire, and remove any requirements about how zone contents are
provisioned. Instead there would be a series of examples of existing
ANAME-like systems.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
the widest possible distribution of wealth

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

Re: [DNSOP] Minimum viable ANAME

[Matthijs Mekking]

That was me on the mic.

To clarify:

DNS open source implementers discussed it earlier this week to see if 
there is still appetite for ANAME. The last draft did not see a lot of 
comments. To get things moving again we thought it might be a good idea 
to make a document with reduced scope.


Matthijs


On 3/26/19 4:17 PM, Dan York wrote:




On Mar 26, 2019, at 3:35 PM, Olli Vanhoja > wrote:


Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.


I believe it was a comment from someone at the mic that the *authors* 
were going to have a side meeting to talk about simplifying the draft 
and providing a new version.


If it is a larger meeting than just the authors, then there are probably 
a number of us who would be interested.


Dan

--
Dan York
Director of Web Strategy, Internet Society
y...@isoc.org    +1-603-439-0024
Jabber: y...@jabber..isoc.org   
Skype: danyork http://twitter.com/danyork


http://www.internetsociety.org/

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



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

Re: [DNSOP] Minimum viable ANAME

[Dan York]

On Mar 26, 2019, at 3:35 PM, Olli Vanhoja mailto:o...@zeit.co>> 
wrote:

Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.

I believe it was a comment from someone at the mic that the *authors* were 
going to have a side meeting to talk about simplifying the draft and providing 
a new version.

If it is a larger meeting than just the authors, then there are probably a 
number of us who would be interested.

Dan

--
Dan York
Director of Web Strategy, Internet Society
y...@isoc.org   +1-603-439-0024
Jabber: y...@jabber.isoc.org  Skype: danyork   
http://twitter.com/danyork

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

Re: [DNSOP] Minimum viable ANAME

[tjw ietf]

No

I said I want to reset and work toward an interim. 

>From my high tech gadget

> On Mar 26, 2019, at 15:35, Olli Vanhoja  wrote:
> 
> Did someone say that there will be a side meeting about mvp ANAME
> during this week? If so, I couldn't find that from the calendar.
> 
> ___
> 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] Minimum viable ANAME

[Olli Vanhoja]

Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.

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

[DNSOP] draft-livingood-dnsop-dont-switch-resolvers & draft-livingood-dnsop-auth-dnssec-mistakes

[Paul Ebersman]

I support these as a combined draft to be worked on by the DNSOP WG and
I'm willing to contribute editing/verbage.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Olli Vanhoja]

On Tue, Mar 26, 2019 at 2:19 PM Dave Lawrence  wrote:
>
> On the other hand I have direct operational experience that says if a
> problem is being caused not by a generalized DOS or other transient
> network issue, then it can indeed take multiple days to resolve.
> Start of a long weekend?  Trying to reach the right people to fix it?
> Surely you've experienced customers not responding quite as quickly to
> fix their problems as you'd like.
>
> So I'm not so keen on one day, but could see dropping the
> recommendation to 3.  It is, after all, still just a recommendation
> and one that should be configurable.
>

Yes, I remember that this has happened a few times at large scale during
the last few years. I'm a bit worried if it would still cause more problems
than it would solve.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Dave Lawrence]

On Tue, Mar 26, 2019 at 12:48 PM Tony Finch  wrote:
>> I think the suggested max stale timer of 7 days is excessive. The aim is
>> to cope with an outage, so I think 1 day is much more reasonable (though I
>> have configured my servers with a 1 hour limit).

Olli Vanhoja writes:
> I agree. At least based on my own experience, all the network or other
> downtime issues I have experienced last only few minutes. 

Okay, I agree a little that 7 days is probably excessive as a
recommendation, though not harmful.  I also agree that in most
instance where serve-stale has already proven itself to be useful, 
the events are fairly short-lived.

On the other hand I have direct operational experience that says if a
problem is being caused not by a generalized DOS or other transient
network issue, then it can indeed take multiple days to resolve.
Start of a long weekend?  Trying to reach the right people to fix it?
Surely you've experienced customers not responding quite as quickly to
fix their problems as you'd like.

So I'm not so keen on one day, but could see dropping the
recommendation to 3.  It is, after all, still just a recommendation
and one that should be configurable.

> If there is a downtime longer than that and it's only affecting DNS,
> I would seriously consider changing my service providers and
> vendors, whatever is the issue.

Right!  But in the meantime, until that change is done ...

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Olli Vanhoja]

On Tue, Mar 26, 2019 at 12:48 PM Tony Finch  wrote:
>
> Dave Lawrence  wrote:
> > Ray Bellis writes:
> > > Serve stael must not become a vector whereby malware can keep its C&C
> > > systems artificially alive even if the parent has removed the C&C domain
> > > name.
> >
> > I wholeheartedly agree with this ideal, and am very open to
> > considering text improvements.
>
> I think the suggested max stale timer of 7 days is excessive. The aim is
> to cope with an outage, so I think 1 day is much more reasonable (though I
> have configured my servers with a 1 hour limit).
>

I agree. At least based on my own experience, all the network or other
downtime issues I have experienced last only few minutes. If there is
a downtime longer than that and it's only affecting DNS, I would
seriously consider changing my service providers and vendors, whatever
is the issue.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Tony Finch]

Dave Lawrence  wrote:
> Ray Bellis writes:
> > Serve stael must not become a vector whereby malware can keep its C&C
> > systems artificially alive even if the parent has removed the C&C domain
> > name.
>
> I wholeheartedly agree with this ideal, and am very open to
> considering text improvements.

I think the suggested max stale timer of 7 days is excessive. The aim is
to cope with an outage, so I think 1 day is much more reasonable (though I
have configured my servers with a 1 hour limit).

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shetland Isles: West or southwest 5 or 6, decreasing 3 or 4 for a time,
occasionally 7 at first. Moderate in sheltered east, otherwise rough,
occasionally very rough at first in west. Occasional rain. Moderate or good,
occasionally poor.

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

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[tirumal reddy]

On Tue, 26 Mar 2019 at 10:48, Paul Vixie  wrote:

>
>
> Ian Swett wrote on 2019-03-25 01:28:
> > One way DoH may be faster than DoT in the near future is that DoH can go
> > over HTTP/3 via QUIC and avoid head of line blocking like Do53.
> Do53/UDP has no HoL prolem.
>
> nor does Do853/TCP.
>

TCP suffers from network head-of-line blocking.

-Tiru


>
> only Do53/TCP had an HoL problem, so, it was never widely used, and has
> been replaced by Do853/TCP.
>
> --
> P Vixie
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Extended DNS Errors (implementation) feedback

[Ralph Dolmans]

Hi all,

I made an Extended DNS Errors implementation in Unbound during the
IETF104 hackathon. Implementing the code that handles the errors was
rather straightforward, the difficult part is (as Stéphane already
pointed out) finding the right locations in the code for the individual
errors. Some remarks regarding the draft:

Since it is possible to have multiple extended error options, is it
expected to return all errors that match the result, or only the most
specific one? For example: if a DNSSEC signatures is expired should both
the "DNSSEC bogus" (SERVFAIL/Extended error 1) and the "Signature
expired" (SERVFAIL/Extended error 2) be returned?

I am not sure whether linking the info code to the rcode is a good idea.
Some info codes can happen for different rcodes. It is in Unbound for
example possible to block a domain by sending a REFUSED rcode, while the
document list blocking only for the NXDOMAIN rcode. If the
rcode/info-code coupling will remain then I would like to have the same
info code for a specific error under different rcodes, for example
always use info-code 1 for blocking.

Since EDNS is hop-by-hop, only error information from the resolver you
are talking to is returned. There are cases when the interesting
information is not in the first resolver. For example: if a resolver
forwards queries to another one and the last one does DNSSEC validation
then the resolver you are talking to does not generate the interesting
information. Is it maybe an idea to add some text stating that extended
error-aware resolvers should forward the received EDNS option?

I think having the extra information provided by this document is useful
for debugging, and only for that. This extra information should not be
used to make any DNS resolving decision, which makes the retry flag a
bad idea. At the moment I don't have to trust all my secondaries as long
as my zone is DNSSEC signed. The worst thing they can do is not return
my data or tamper with it, in which case the validating resolver will
ignore it and try another nameserver. Giving a nameserver the power to
instruct a resolver to not try at another nameserver gives them the
power to make my zone unavailable. This completely changes the current
trust model. Please remove the retry flag from the document.

-- Ralph

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

Re: [DNSOP] I-D Action: draft-livingood-dnsop-dont-switch-resolvers-04.txt

[Stephane Bortzmeyer]

On Mon, Feb 18, 2019 at 02:06:59PM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 48 lines which said:

> Title   : In Case of DNSSEC Validation Failures, Do Not 
> Change Resolvers
> Author  : Jason Livingood
>   Filename: draft-livingood-dnsop-dont-switch-resolvers-04.txt
>   Pages   : 8
>   Date: 2019-02-18

Good for me. Useful document. One suggestion:

> independent third party sites or tools that can confirm whether or
> not a DNSSEC-related error is present, of which several exist today
> (e.g.  DNSViz [1], Verisign DNSSEC Debugger [2]).

I suggest to add Zonemaster  to this list.

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

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

[Paul Vixie]

Puneet Sood wrote on 2019-03-25 08:07:

Hi Paul,

On Sun, Mar 24, 2019 at 12:37 PM Paul Vixie  wrote:


i object to serve-stale as proposed. my objection is fundamental and
goes to the semantics. no editorial change would resolve the problem.

i would withdraw that objection if this draft incorporates section 2 of
https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit:


I went back and read the discussion on this draft and I could not find
consensus on adopting it at that time.


noone understood it. there was no reply, positive or negative, to my 
proposal that the WG adopt it. it dropped like a brick, in silence.


i believe that the issues are, now, nine years later, better understood.


... I do not think adding it to the
serve-stale draft will make path for adoption for either the
serve-stale draft or these recommendations easier.


understood. we disagree, but, i understand your position.


https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-04 section 5
(page 6, paragraph 2) talks about refreshing the delegation. Quote:

+ When no authorities are able to be reached during a resolution
+   attempt, the resolver SHOULD attempt to refresh the delegation and
+   restart the iterative lookup process with the remaining time on the
+   query resolution timer.  This resumption should be done only once
+   during one resolution effort.

Maybe there are fewer, specific bits from your draft which would be
appropriate in the serve-stale context? Would you be willing to
discuss those?


yes, certainly. the text i quoted from the 2010 resimprove draft was the 
result of implementation experience, and touches on necessary details, 
which are at the moment missing from serve-stale. i'll be very happy to 
discuss these, though regrettably, i could only be in prague for sunday, 
and so i'll miss any side meetings or working group discussions this 
time. no disrespect is intended by my absence, i had other obligations.


--
P Vixie

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

Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[tirumal reddy]

On Mon, 25 Mar 2019 at 16:05, Tony Finch  wrote:

> Ted Lemon  wrote:
>
> > This is equally an argument for doing DNS over DTLS. This would give
> > similar performance to DoH over QUIC.
>
> If I understand it correctly, DTLS leaves MTU and fragmentation up to the
> application protocol. The DNS has horrible packet size problems, so it
> needs a lot more help than DTLS provides. QUIC is much better.
>

We had a proposal in our draft
https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-02#section-9 to
handle fragmentation and reassembly but due to lack of support, it was
removed in the next revision.
If there is renewed interest in DNS-over-DTLS, we can submit a new draft
discussing the fragmentation and reassembly procedure.

Cheers,
-Tiru



> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> The Minch: Westerly 4 or 5, backing southwesterly 5 or 6, occasionally 7
> later
> in north. Rough in far north and in far south, otherwise slight or
> moderate.
> Occasional drizzle. Good, occasionally poor.
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

[Willem Toorop]

I support adoption too and have (the version in this draft) of ZONEMD
provisioned already in the net-dns.org. zone.
Dick Franks worked on a ZONEMD verifier for Net::DNS during the
Hackathon last Saturday/Sunday (remotely).

On 10-03-19 15:31, Tim Wicinski wrote:
> 
> The chairs feel the document has been updated to address 
> several issues raised from the last meeting, including 
> some implementations.   
> 
> If there is pushback during this call for adoption, we can 
> take the topic up in Prague. 
> 
> This starts a Call for Adoption for draft-wessels-dns-zone-digest
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 24 March 2019
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> 
> ___
> 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] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator

[Paul Vixie]

Ian Swett wrote on 2019-03-25 01:28:
One way DoH may be faster than DoT in the near future is that DoH can go 
over HTTP/3 via QUIC and avoid head of line blocking like Do53.

Do53/UDP has no HoL prolem.

nor does Do853/TCP.

only Do53/TCP had an HoL problem, so, it was never widely used, and has 
been replaced by Do853/TCP.


--
P Vixie

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