Subject: Re: [DNSOP] New draft for ALIAS/ANAME type

From: Tony Finch <[email-masked]>
Date: Mon, 3 Apr 2017 12:55:49 +0100

Peter van Dijk <[email-masked]> wrote:
>
> There are PowerDNS ALIAS deployments that signs offline (for some
> stretch of the definition of offline) - every minute. For small zones
> the NOTIFY+XFR overhead is very tolerable, and the public auths do not
> need the private key data.

If you expand ALIAS on the master server like this, I would expect that
most of the time the target addresses won't change very frequently, so the
IXFR rate should be much less than the ALIAS polling frequency.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: South or southwest, veering northwest later, 5 or 6. Slight,
occasionally moderate in Humber. Fog patches, rain later. Moderate,
occasionally very poor.

---

From: Tony Finch <[email-masked]>
Date: Mon, 3 Apr 2017 13:10:58 +0100

Peter van Dijk <[email-masked]> wrote:
> On 31 Mar 2017, at 12:10, Tony Finch wrote:
> >
> > Does the more ambitious version use the NSEC rdata format so that you can
> > have different target names for different alias RR types?
>
> I got this question some time ago when I was working on ALIAS for PowerDNS.
> Back then I said no, as nobody showed me an actual use case for it and I did
> not like the extra complexity. Today I feel the same way and the upcoming
> draft does not have type bitmaps currently.

That's probably sensible :-)

The vague idea I had was ALIAS A AAAA for your web hosting provider and
ALIAS MX TXT for your mail hosting provider. But the latter isn't actually
very useful, since MX and SPF records have built-in indirection, and TXT
is also used for other purposes (domain authorization, quite frequently in
my experience), and it doesn't cover DKIM or MUA SRV records. And other
scenarios stub their toes in similar ways, e.g. for SIP there's a mess of
SRV records plus NAPTR, and a NAPTR RRset can cover multiple unrelated
protocols and providers.

So I think my conclusion is that ALIAS is both unnecessary and unhelpful
for RRtypes other than A and AAAA.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North or northeast 4 or 5, increasing 6 at times. Moderate at first
in east, otherwise rough. Fair. Good.

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2017 19:12:19 -0000

>for RRtypes other than A and AAAA.

Depends.  If you allow what I described, shadowing records from a
server that thinks it's authoritative from the zone but isn't, it's
definitely useful for MX, possibly for others.

R's,
John

---

From: Dan York <[email-masked]>
Date: Mon, 3 Apr 2017 19:40:22 +0000

I very much like the idea of this draft, given that I use multiple DNS hosting providers who all have their own unique (and proprietary) way of doing "CNAME flattening at the apex". I think the reality of today's user experience with domain names is that we are increasingly dropping the "www" or any other kind of second-level domain. So we want to talk about our sites as "example.com<http://example.com>" ... but as the publisher we want to use CDNs, load balancers and other systems that need us to use a CNAME. A standardized way of doing this would be helpful.

One comment...

On Mar 30, 2017, at 7:13 PM, Evan Hunt <[email-masked]<mailto:[email-masked]>> wrote:

(Incidentally, I'm working on a somewhat more ambitious ANAME draft with
Peter van Dijk and Anthony Eden, who has kindly agreed to merge his efforts
with ours. I expect to post it in a few days, stay tuned.)

... I think it would be helpful for the new draft to have a few examples of what the RR would look like in a zone file.  (This was the one component I found missing from Anthony's ALIAS draft.)

Thanks for doing this,
Dan

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
[email-masked]<mailto:[email-masked]>   +1-603-439-0024
Jabber: [email-masked]<mailto:[email-masked]>  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Apr 2017 15:48:49 -0400 (EDT)

On Mon, 3 Apr 2017, Dan York wrote:

> I very much like the idea of this draft, given that I use multiple DNS hosting providers who all have their own unique (and proprietary) way of doing
> "CNAME flattening at the apex". I think the reality of today's user experience with domain names is that we are increasingly dropping the "www" or any
> other kind of second-level domain. So we want to talk about our sites as "example.com" ... but as the publisher we want to use CDNs, load balancers and
> other systems that need us to use a CNAME. A standardized way of doing this would be helpful.
> One comment... 

I hate it :)

As Evan said, there should not be any code in an authoritative server
that requires it to do recursive validation.

> with ours. I expect to post it in a few days, stay tuned.)

Staying tuned :)

Paul

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 03 Apr 2017 21:57:52 +0200

Hi Dan,

On 3 Apr 2017, at 21:40, Dan York wrote:

> I very much like the idea of this draft, given that I use multiple DNS 
> hosting providers who all have their own unique (and proprietary) way 
> of doing "CNAME flattening at the apex". I think the reality of 
> today's user experience with domain names is that we are increasingly 
> dropping the "www" or any other kind of second-level domain. So we 
> want to talk about our sites as "example.com<http://example.com>" ... 
> but as the publisher we want to use CDNs, load balancers and other 
> systems that need us to use a CNAME. A standardized way of doing this 
> would be helpful.

Thank you for your kind words. As I said in another post indeed, I hope 
this draft (assuming it becomes an RFC) will remove one point of 
suffering for those who use multiple DNS providers.

> One comment...
>
> On Mar 30, 2017, at 7:13 PM, Evan Hunt 
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> ... I think it would be helpful for the new draft to have a few 
> examples of what the RR would look like in a zone file.  (This was the 
> one component I found missing from Anthony's ALIAS draft.)

Our current draft-draft does not have that yet but I fully agree. I find 
many published RFCs are lacking in examples and test vectors, and I’ll 
make sure we do better on this.

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Apr 2017 20:00:56 +0000

On Monday, April 3, 2017 7:48:49 PM GMT Paul Wouters wrote:
> ...

in the internet dns as practiced, our choice is not whether an idea thought by 
some to be "bad", as in, "a bad idea", will be widely implemented.

our only choice is whether such ideas are documented, interoperable, and 
subject to fine tuning by the rest of the community.

as someone who finds most ideas bad, i often wish this weren't so. as someone 
whose ideas are often thought to be bad by others, i am often glad that this 
is so.

in any case, it is so. ideas, good or bad, plus implementation, creates 
relevance. that relevance stands independent of the perceived goodness or 
badness of the ideas themselves.

with or without an applicability statement, the underlying message of an rfc 
from the dnsop working group is not "we think this is good engineering" but 
rather "if you want to do this in a way that interoperates with others who are 
also doing it, here is one way to achieve that result."

so, phrases like "should not be" are irrelevant in this place at this time.

vixie

---

From: Dave Crocker <[email-masked]>
Date: Mon, 3 Apr 2017 13:33:39 -0700

> so, phrases like "should not be" are irrelevant in this place at this time.

There's a legitimate substitute for the should(not) statements: 
Statements of implication.

Along with describing the how, describing what will ensue, is likely to 
ensue, or is at least a possibility.  These might even be labeled 
'downsides' or 'upsides' if the authors want to get frisky.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Evan Hunt <[email-masked]>
Date: Mon, 3 Apr 2017 22:25:31 +0000

> that requires it to do recursive validation.

I said what now?  Had I recently had dental surgery?  I don't remember
this.

If you mean the comment I made on the ANAME thread, I was just saying
that it's possible to implement CNAME flattening without a built-in
resolver; several implementations already do.

(I do believe an authoritative server should be *able* to operate without
built-in recursive code, and enabling such operation is on my list of
things to get around to someday in BIND: if auth servers could be
configured to use external resolvers, then security bugs affecting
only the recursive code wouldn't be any risk to them. But I definitely
wouldn't phrase that as "there should not be any code".)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Apr 2017 23:13:13 -0400 (EDT)

> I said what now?  Had I recently had dental surgery?  I don't remember

Sorry about misremembering what you said.

> built-in recursive code

> But I definitely wouldn't phrase that as "there should not be any code".)

I'll await the new draft :)

Paul

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Apr 2017 15:30:06 +0000

On 4/3/17, 16:00, "DNSOP on behalf of Paul Vixie" <[email-masked] on behalf of [email-masked]> wrote:

    > that requires it to do recursive validation.
    
I'm going to squat on Paul Vixie's subject line but not respond to anything he says, in part because something crossed my mind, based, ironically enough, in a conversation Paul and I had not long ago (at an ICANN meeting venue).

We reminisced about client-subnet-id.  There was a way-back time when I spoke of a q-trinity - qname, qtype, qclass - being the three things needed to get a specific response from DNS.  Including any other information was a pollutant.

Paul pulled that out when my name was on an early version of the client-subnet-id document (as a caretaker editor).  The reason I was participating in that was seeing how the implementation of "stupid DNS tricks" (as one side of the war might call them) or "tailored DNS responses" (as the other side of the war might call the same battle) got carried out in specific contexts.  They "worked" despite some flaws and dire predictions.

It isn't that it's a sin to pollute the query with other information, there's a cost of doing so.  In some cases, the cost is worth the benefit, in others, not.  It's not a binary "do it or not" but a sliding scale of "is the cost less than the benefit?" I say sliding because "cost" and "benefit" are not fixed values over time.  (Moore's law, Kaminsky's BlackHat presentation change cost and benefit calculations.)

Back to the quote above.  In general, an authority server having to do lookups will have scaling implications, suck performance, present a potential for abusive loading (think DoS/DDoS).  (Related but different, DNSSEC once required the server verify signatures on load - that slowed loading zones, so it was dropped with the consequence of having to carefully define the AD bit in a response.)  But in specific, managed and contained contexts, having authorities look up data to improve an answer can be worth the cost.

Question hard-and-fast rules from the past.  Things change.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Apr 2017 09:00:28 -0700

> Question hard-and-fast rules from the past.  Things change.

rather than death or taxes, the hard and fast inevitability here (which
things will change and in what ways?) is increasing complexity and
associated reductions in diagnostic capability and general correct
understanding.

see also:

http://queue.acm.org/detail.cfm?id=1242499

-- 
P Vixie

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 4 Apr 2017 12:32:05 -0400

> IXFR rate should be much less than the ALIAS polling frequency.

I believe that's a faulty assumption.   Here's some data:

One of our registrars has ~3.6 million zones hosted on its name servers.
We have historically allowed end users to put CNAMEs wherever they want in
the UI, but have a CNAME "emulator" in the publishing path replaces the
illegal ones before they're inserted in a zone.

During the month of February, the CNAME emulator initiated 872k changes to
28k zones, with an average of 31 changes per zone.  The minimum/maximum
changes per zone were 1 and 231 respectively.

A change is updating one or more replaced CNAME records in a single action,
so this doesn't count individual CNAMEs updated.  It's also possible actual
changes occurred on authoritative servers more often, since we avoid DoSing
upsteam authoritatives.

Here's the distribution of the  number of zones per number of changes.
I've used a LOG scale, since there's a spike of 10k zones with 42 changes,
which makes a linear graph unreadable.

<http://imgur.com/RzuHgks>

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Apr 2017 18:21:06 +0100

Matthew Pounsett <[email-masked]> wrote:
> [...] During the month of February, [...] an average of 31 changes per zone. [...]

That seems to agree with what I meant, though I probably should have said
"per-zone" somewhere :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Faeroes, Southeast Iceland: Northwesterly gale 8 to storm 10, backing
southwesterly 5 to 7 later. High or very high becoming very rough,
occasionally rough later. Squally showers, drizzle later. Moderate or poor.

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 4 Apr 2017 13:30:36 -0400

On 4 April 2017 at 13:21, Tony Finch <[email-masked]> wrote:

> That's the average, but there's a not-insignificant number there being
updated many times per day.    Most of the time, you're right, there are
few changes, but one can't assume that any given alias will have a low rate
of change.

---

From: Petr Špaček <[email-masked]>
Date: Fri, 7 Apr 2017 08:44:44 +0200

On 4.4.2017 19:30, Matthew Pounsett wrote:
> On 4 April 2017 at 13:21, Tony Finch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> few changes, but one can't assume that any given alias will have a low
> rate of change.

Numbers, that really helps!

If I consider the numbers above and the fact that IXFR is able to deal
even dynamically updated zones, I conclude that pushing ANAME logic to
provisioner side is reasonable approach and that added complexity in
name server itself is not warranted.

-- 
Petr Špaček  @  CZ.NIC

---

From: Bryan Hughes <[email-masked]>
Date: Fri, 7 Apr 2017 12:12:39 -0400

In many cases, DNS Made Easy is seeing ANAME records requiring synthesized
A record updates every 90 seconds or so. Also, it is surprising to me that
our non-apex ANAME record count has surpassed apex ANAME record count by a
significant amount. We have approximately 25% fewer apex ANAME records than
non-apex, however apex ANAME records account for over 75% of ANAME zone
update activity. We currently process around 50,000 distinct ANAME records
and we are seeing an average of 60, max of 925, and min of 0 zone updates
per zone per day with an average of 1.74 synthesized A records per non-apex
ANAME record and 1.41 synthesized A records per apex ANAME record.

On Fri, Apr 7, 2017 at 2:44 AM, Petr Špaček <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>