Subject: [DNSOP] Fundamental ANAME problems

From: Brian Dickson <[email-masked]>
Date: Thu, 1 Nov 2018 15:34:22 -0700

Greetings, DNSOP folks.

First, a disclaimer and perspective statement:
These opinions are mine alone, and do not represent any official position
of my employer.
However, I will note that it is important to have the perspective of one
segment of the DNS ecosystem, that of the authority operators (are also
known as DNS hosting operators.)
IMNSHO, authority operators provide a critical element of the DNS
ecosystem, operating DNS zones for the vast majority of DNS registrants.

The important element of this perspective is, that changes to how DNS
operates and scales, if they have an adverse impact on authority operators
(at scale), have potential knock-on impact to everyone.
If (and I realize this is a big "if") changes are made which adversely
affect the operation cost (regardless of whether it is direct or
indirect/consequential) of operating authority services, this puts at risk
the ability of registrants to operate their own zones (e.g. if there are
fewer authority operators, or if prices skyrocket).
This further puts at risk, the ongoing volume of DNS registrations, which
impacts the viability of everyone else whose business relies on
registration fees, directly or indirectly, including TLDs, CDNs, (non-DNS)
hosting, and even ICANN itself.
Caveat dnsops.

Given the above, I feel it is important to point out several problems that
are rooted in the requirement to dynamically update the sibling records
that is present in the current design of ANAME. (This is the only real
problem I see, but it's a doozie.)

(The introduction text mentions some of these, but IMHO doesn't adequately
address their impact.)

First, there is the issue of imposed update frequency.

The requirement on update rate, is imposed externally by whichever entity
operates the ANAME target. In other words, this is not under the direct
control of the zone operator, and is potentially a potentially (and very
likely) UNBOUNDED operational impact/cost.

Second, this issue is compounded by scale.

The issue here is, that the larger the entity is that operates zones with
ANAMEs is, the larger the resulting impact. This is a new, unanticipated,
asymmetric cost. It has the definite potential to make operating authority
servers prohibitively costly.

Third, there is an issue with the impact to anycast operation of zones with
ANAMEs, with respect to differentiated answers, based on topological
locations of anycast instances.

There is currently an expectation on resolving a given name, that where the
name is ultimately served (at the end of a *NAME chain) by an entity doing
"stupid DNS tricks" (e.g. CDNs), that the answer provided is topologically
appropriate, i.e. gives the "best" answer based on resolver (or in the case
of client-subnet, client) location.
When done using CNAMEs, the resolver is the entity following the chain, and
does so in a topologically consistent manner. Each resolver instance
querying a sequence of anycast authorities which return respective CNAMEs,
gets its unique, topologically-appropriate answers, and there is no
requirement or expectation that resolvers in topologically distinct
locations have any mutual consistency.
ANAME places the authority servers in an anycast cloud, in a "Hobsons
choice" scenario. Either a single, globally identical sibling value is
replicated to the anycast instances (which violates the expectation of
resolvers regarding "best" answer), or each anycast instance needs to do
its own sibling maintenance (with all that implies, including on-the-fly
DNSSEC signing), or the anycast cloud now has to maintain its own set of
divergent, signed answers at the master, and add all the complexity of
distributing and answering based on resolver topological placement. (The
last two have significant risk and operational complexity, multiplied by
the volume of zones served, and impacted by the size of the anycast cloud.)

To summarize:
The requirement to maintain sibling records (A/AAAA) itself is absolutely a
"camel back breaking" requirement. The issues are: frequency of updates
required is externally imposed; either the correctness required by ANAME
targets is broken (using single A/AAAA value regardless of anycast
location), or the complexity of performing A/AAAA updates is compounded by
at least NxM (N anycast locations of authority operatior, M disparate
values provided in response to A/AAAA queries to the ANAME target); plus
the added requirement of on-the-fly DNSSEC signing is a non-scalable and
security-challenging non-starter.

Side-note: we, as a community, have been pushing for wide-scale adoption of
DNSSEC; this definitely places a significant hurdle to adoption, precisely
in a wide-scale manner, i.e. to the vast majority of DNS registrants. It is
a big roadblock to DNSSEC adoption, and a move in the wrong direction.

What are the alternatives?

Fundamentally, the behavior that is desired that we are collectively trying
to preserve, is that of resolver-based *NAME chain resolution, just with
the ability to do so at the apex of a zone.

This points to the only logical places that MUST be part of any apex-based
chaining of resolution: resolvers, or clients.
(I include clients as an option, since it is at least feasible to include
client-based multiple-lookups as an alternative to "additional processing"
that would otherwise be needed in resolvers.)

Ultimately, this means any solution that has this characteristic, can only
provide backwards compatibility to clients, if resolvers are updated, or
alternatively, if clients are updated to do whatever is required that
resolvers which aren't updated won't do. (Sorry for the badly written
logic, english is not really well suited for branching logic.)

There would still be a requirement on authority servers, but it would not
provide a transparent backwards compatibility without updates to resolvers
or clients. There would need to be SOME response to give to resolvers,
telling them where to go and what to do. The only differences are, on the
non-providing of sibling records, and the changes to response processing in
which the new record type(s) are selected and returned. On the plus side,
in this different model, the RRs would be basically constant, allowing the
scaling of authority operators to be unaffected, and there would not be a
requirement for dynamic updates or frequent/on-the-fly DNSSEC signing.

There are several choices, and dependent on what those are, is what the
logic change needed would be, where the new RRtype(s) could be used, and
how resolvers and/or clients would handle the new responses.

If the current limited ANAME (without sibling) is used, the logic would be
to return it only if the corresponding query types (A or AAAA) are seen,
there is no RRset of that type at the owner name, and there is an ANAME
record. The processing on the authority, and resolver or client, would be
pretty much as in the current draft, modulo not having the sibling record.
If the response to an A/AAAA query is an ANAME, follow the chain until an
A/AAAA record is found, or the chain breaks. If this is done by the
resolver, special handling on TTL and new client queries would be necessary.

Another option would be a similar type, maybe ACNAME (address CNAME), which
could co-exist with other types, and could occur both at an apex and
anywhere else in a zone. Same basic processing logic.

A third option would be, for lack of a better term, WCRR, wildcard RR type,
whose RDATA is an FQDN. The logical processing would be to add handling at
the point where "NOERROR, NODATA" would otherwise be returned, right above
the WILDCARD in the resolution process. If no match for QTYPE is found,
check for WCRR type, and return that it found. Resolver handling would be
the same; if a WCRR type is returned, replace the QNAME with the RDATA and
re-start query processing.

Client handling of these could be done via simultaneous queries for A (or
AAAA) and ANAME (or WCRR), and following ANAME/WCRR replies to their target
if no A/AAAA response is received and an ANAME/WCRR is received.

(IMHO, the WCRR is a bit cleaner to implement on both authority and
resolver, and is more forward-looking, i.e. handles other aliasing at other
RRtypes as well, if needed.)

The last option would be handling all of this junk in the browser, with
either SRV, or whatever new RRTYPE is required that fixes the problem(s)
with SRV that the HTTP folks require.

Brian

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2018 08:14:30 +0800

I can't help but note that people all over the Internet do various
flavors of ANAME now, and the DNS hasn't fallen over.  Let us not make
the same mistake we did with NAT, and pretend that since we can't find
an elegant way to do it, we can put our fingers in our ears and it
will go away.

>likely) UNBOUNDED operational impact/cost.

"Something very bad will happen if I do that."  "OK, so don't do
that."  My aname-ish code has a maximum update rate, and I expect
everyone else's does too.  Yeah, the ANAMEs won't be in sync with
the hostile remote server, but I can't get too upset about that.

>locations of anycast instances.

How is this different from CNAMEs via to 8.8.8.8 and other anycast
caches?  The cache has no relation to the location of the client unless
you use one of the client location hint hacks.

I'm not wedded to the current ANAME spec but we have plenty of experience
showing that it's possible to implement without causing disasters?

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Thu, 1 Nov 2018 18:38:17 -0700

> an elegant way to do it, we can put our fingers in our ears and it
Did you not read my full message?
I didn't say don't do that, I said let's do it in an elegant way.
Then I provided a few examples of how to do that.

What is being done now is not ANAME by any stretch; it is
vertically-integrated apex CNAME flattening.
Yes, there are several providers doing it.
Their customers are locked in to a single provider, precisely because of
that vertical integration.
None of their customers can have multi-vendor redundancy with feature
parity.
While not a prime motivation for ANAME or its alternatives, it is certainly
(or should be) one of its goals.

The fact that each existing vendor's solution is, and requires, vertical
integration, means each is fundamentally a closed system, with no interop
possible.

What ANAME, and the other suggested things, are doing is figuring out how
to do interoperable stuff that allows something kind of like a CNAME, to
co-exist at an apex.

Can you point me to a non-closed, non-vertically-integrated ANAME-like
thing that offers interoperable multi-vendor support?

I think you are confusing "dynamic update of A based on
meta-data-configured FQDN" with actual ANAME.

So, DNS not having fallen over yet, has nothing at all to do with ANAME.

> In article <
> [email-masked]> you
> write:

How many zones do you operate this way?
What is the maximum update rate?
Are those zones you operate on behalf of paying customers?
If those were paying customers, and the records got out of sync, don't you
think the customers would get upset?

That's the primary point; when non-toy situations with paying customers are
considered, it isn't up to you to decide what the update rate is, and you
don't have the luxury of not caring.

It isn't whether it works for you; it's whether it works for EVERYBODY.
If it doesn't, then we need to work harder on the problem.

> you use one of the client location hint hacks.

Because authority servers for the same zone, when not doing stupid DNS
tricks, are in sync.
This is by design, and is the expectation of clients, resolvers, and
registrants.

Anycast caches do not have any expectation or requirement to be sync'd, and
in particular, due to stupid DNS tricks, are typically topologically sync'd
to regional answers.

Anycast caches with smaller footprint or odd customer bases, might do those
hacks, but even without them, there will be significant differences in the
contents of those caches, in different locations.

The problem is the ANAME *target* -- that will typically also be
topologically diverse, e.g. answers supplied will involve stupid DNS tricks.

You can't have your ANAME use only a single view and push that SAME answer
to all anycast nodes.
Doing so would break the client->resolver->(anycast auth)->ANAME-target
model of diversified answers.
If client/resolver are supposed to hit ANAME-targets (which are themselves
anycast, but which do stupid DNS tricks to give different answers) and get
DIFFERENT answers, then having only one instance of the ANAME-target
returned by the anycast auth (regardless of location) will be an
"#EpicFail".

Example:

   - client in Los Angeles -> resolver somewhere in California -> ??? ->
   AWS obfuscated-name -> California IP address (based on resolver IP, or
   maybe client-subnet)
   - client in Boston -> resolver somewhere in New England -> ??? -> AWS
   obfuscated-name -> New York IP address (based on resolver IP, or maybe
   client-subnet)
   - If ??? is an ANAME, which does a tracking query FROM ONE LOCATION, and
   mirrors that out to many anycast instances, then one of two results will be
   seen in the mini-example case:
      - The client in Los Angeles will receive the New York IP address, or
      - The client in Boston will receive the California IP address
      - According to the HTTP folks, neither of those is "acceptable".

The alternative is having EACH anycast instance for the auth server (which
has an ANAME target of the AWS blob) doing its OWN tracking, which requires:

   - Widely distributed DNSSEC signing (which requires placing the ZSKs
   everywhere)
   - Even more costly load out in every anycast location (multiply the
   original Master lookups, by the number of anycast instances, times the
   number of zones)

> showing that it's possible to implement without causing disasters?
The issue isn't whether it is possible to IMPLEMENT, it is whether it is
feasible to OPERATE at scale.

I don't doubt your implementation is easy, or any singular (non-anycast)
implementation equally easy.

The question is, would the incremental operational load, if you upped the
zone count to O(10^6), be within reason?
Or, how about the complexity of implementing the anycast stuff, especially
differentiated answers?

I submit that currently, in the face of possible externally-imposed update
rates, it isn't possible to guarantee that the incremental operational cost
would be negligible.

On the other hand, the impact on resolvers (whose scaling is determined by
actual query load, not the authority-update side of things), would be
definitely marginal, if a solution that placed the burden on them was
agreed-upon.

Resolver operators can trivially shoulder the burden.

Here's why: The operation difference would be, when QTYPE=A, Answer
includes ANAME or WCRR, do another query for the RDATA, exactly as if the
Answer had been a CNAME. Functionally identical, load-wise identical, to
having an actual apex CNAME.

For authority operators, scale is the problem, along with disproportionate
load. The cost of tracking the siblings to ANAME records is the same,
regardless of zone popularity. Amortized over a large query volume, and a
small number of zones, it is easy to ignore the cost. However, when
multiplied by a large number of zones, in the commodity range of domain
names, it is not the case. You can't lose money on each and expect to make
it up on volume.

Brian

---

From: "John R Levine" <[email-masked]>
Date: 2 Nov 2018 16:03:50 +0800

> Then I provided a few examples of how to do that.

I'll defer to other people, but it seems to me that anything that depends 
on recursive DNS servers being updated isn't a realistic solution.  We're 
still waiting for DNSSEC, after all.

> vertically-integrated apex CNAME flattening.

My version periodically fetches the remote A and AAAA records, invents 
local A and AAAA records, and signs them.  It's a kludge, but it gets the 
job done.

With respect to the whole anycast and CDN thing, it is not my impression 
that ANAME hacks are widely used for big sophisticated sites.  Mine are 
used for small biz sites where my user wants to use my mail but someone 
else's web service.

> thing that offers interoperable multi-vendor support?

Of course not.  That's why we're talking about ANAME.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Paul Vixie <[email-masked]>
Date: Fri, 02 Nov 2018 08:21:01 +0000

i think an ANAME whose only purpose was to inform some outer process that AAAA 
and A RRsets should be copied from somewhere periodically using RFC 2136 
UPDATE messages, could be useful if some name server implementors decided to 
offer the feature of doing this internally, "as if UPDATE had been done" but 
not actually requiring a cron job and perl script and so on. it would likely 
be seen as a reasonable compromise by the CNAME flattening DNS hosters of the 
era, and may lead to interoperability.

for better dynamicism we should be pushing SRV. and there's no reason why an 
FYI document couldn't explain how to use an apex SRV to inform an UPDATE of 
apex AAAA and A RRsets. this, too, could be added as a nonstandard enhancement 
to authority servers who could do it internally, without cron or perl.

it's very likely that the high volume sites of the world will just go on using 
CDN as before, where every apex AAAA or A query is crafted by load estimating 
or triangulation software, no matter what we do here. however, something like 
ANAME, or something like ANAME but based on apex SRV, could be used to inform 
that estimation/triangulation, and could lead to greater interoperability. i'm 
not sure CDN's currently want interoperability, due to competition concerns, 
but i expect that their customers would like a multi-CDN option to avoid lock-
in.

in other words i don't think there's a glaring need for elegance on this one.

vixie

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 2 Nov 2018 09:36:30 +0100

Hi Brian,

Thanks for your feedback on ANAME. Comments inline.

> Greetings, DNSOP folks.

[...]

> The requirement on update rate, is imposed externally by whichever 
> entity operates the ANAME target. In other words, this is not under the 
> direct control of the zone operator, and is potentially a potentially 
> (and very likely) UNBOUNDED operational impact/cost.

As John already pointed out: You are in control of the update rate. It 
may be that the target address records are changing frequently, but it 
is up to the one that processes the ANAME to set an appropriate update 
rate. So I don't see this as a particular worry.

The draft uses DNS UPDATE as an example and that may be a useful 
scenario for one, but a red flag for another. However I will use ANAME 
and no DNS UPDATE and I think my implementation of ANAME is still 
compatible with the specification.

What I would like to see be changed in the draft is that were ANAME 
processing occurs is more relaxed: Currently it focuses on this 
happening at zone provisioning time (before the zone is loaded by the 
primary), and mentions an optimization algorithm for resolvers that is 
optional. However, there is some text in section 5.2 Alternatives that 
the ANAME processing can occur on secondary servers which I think may 
fit your DNS infrastructure better.

The point is that this draft should standardize the way ANAME is 
processed, while giving flexibility on where processing can occur.

> The issue here is, that the larger the entity is that operates zones 
> with ANAMEs is, the larger the resulting impact. This is a new, 
> unanticipated, asymmetric cost. It has the definite potential to make 
> operating authority servers prohibitively costly.

I don't see any difference with existing proprietary implementations: 
This statement is true for any CNAME-at-the-apex solution.

> Third, there is an issue with the impact to anycast operation of zones 
> with ANAMEs, with respect to differentiated answers, based on 
> topological locations of anycast instances.
> 
> There is currently an expectation on resolving a given name, that where 
> the name is ultimately served (at the end of a *NAME chain) by an entity 
> doing "stupid DNS tricks" (e.g. CDNs), that the answer provided is 
> topologically appropriate, i.e. gives the "best" answer based on 
> resolver (or in the case of client-subnet, client) location.

[...]

As I said above: I agree that the draft should relax where ANAME 
processing can occur. I don't see any reason why this processing can be 
done at the entity that does the stupid DNS trick.

[...]

> the volume of zones served, and impacted by the size of the anycast cloud.)

If you are going to do stupid tricks (aka tailored responses), you will 
have to do on-the-fly DNSSEC signing anyway.

> Side-note: we, as a community, have been pushing for wide-scale adoption 
> of DNSSEC; this definitely places a significant hurdle to adoption, 
> precisely in a wide-scale manner, i.e. to the vast majority of DNS 
> registrants. It is a big roadblock to DNSSEC adoption, and a move in the 
> wrong direction.

I disagree, I think it works pretty well with DNSSEC given the 
requirement that ANAME processing should happen before DNSSEC signing. 
This requirement is reasonable since ANAME processing is in the business 
of tailoring RRsets and any changes made to the zone contents must 
happen before signing.

> Fundamentally, the behavior that is desired that we are collectively 
> trying to preserve, is that of resolver-based *NAME chain resolution, 
> just with the ability to do so at the apex of a zone.
> 
> This points to the only logical places that MUST be part of any 
> apex-based chaining of resolution: resolvers, or clients.

John is right: It is very hard to rely on a solution that depends on 
recursive name servers to be updated. Hence we look at a solution that 
can be implemented at authorities.

Kind regards,

Matthijs

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Nov 2018 16:39:09 +0000

It's really good to see more discussion about ANAME.

The current draft doesn't discuss scaling issues because my main concern
was to get the rewrite done, so there are a number of gaps, e.g. I deleted
the "operational considerations" section. But that doesn't mean I was
unaware of the problem :-)

Brian Dickson <[email-masked]> wrote:

> "camel back breaking" requirement.

I think this is the meat of your objection.

I'm aware that most existing ANAME-like implementations are tailored
for target addresses that are controlled by the DNS hosting provider,
which makes it a lot easier :-) I think that's what you were referring to
on your other message about vertical integration.

Next most common is dynamic lookups of arbitrary targets. This is probably
easier to scale to a very large number of zones with ANAMEs than an
UPDATE-style implementation, but I gather from talking to various people
that it's still fiendish. (And that's why the WG consensus is not to
require a dynamic implementation style.)

(BTW, I live in the same city as Hobson did, so as a pedant I must point
out that Hobson's choice was one option, take it or go without. At least
for ANAME there are multiple implementation strategies, however
unpalatable they all are!)

> the ability to do so at the apex of a zone.

I'm not sure why you say "preserve" here, because none of the existing
ANAME-alikes work that way.

A key aim of this draft is to provide something that works similar enough
to existing ANAME-like features, to give zone owners portability across
providers. I spoke to a number of DNS providers in Amsterdam who have
ANAME-like features and who are keen to improve interoperability.

> resolvers which aren't updated won't do.

It's really important that ANAME can be deployed on authoritative servers
without co-operation from anyone else, especially not resolvers. (After
all, that's how the existing implementations work.)

I think a resolver-side or client-side alternative (like the various
web-specific record types we have been discussing) is defintely soemthing
we should aim for in the long term, but that isn't what this work is
about.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin, Hebrides, Bailey: South or southeast 6 to gale 8, increasing severe
gale 9 at times. Moderate or rough, becoming rough or very rough, occasionally
high later. Rain. Good, occasionally poor.

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 2 Nov 2018 18:28:52 +0100

Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at 04:03:50PM +0800 Quoting John R Levine ([email-masked]):

> I'll defer to other people, but it seems to me that anything that depends on
> recursive DNS servers being updated isn't a realistic solution.  We're still
> waiting for DNSSEC, after all.

Be as pessimistic as you like, but in Sweden, more than 80% of the ISP
resolvers validate. The DNS can change, at a sometimes glacial speed,
but it does change.

"E pur si muove"
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Why are these athletic shoe salesmen following me??

---

From: Erik Nygren <[email-masked]>
Date: Fri, 2 Nov 2018 15:16:25 -0400

On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson <[email-masked]>
wrote:

> ...
> with ANAMEs, with respect to differentiated answers, based on topological
> topologically appropriate, i.e. gives the "best" answer based on resolver
> (or in the case of client-subnet, client) location.
> When done using CNAMEs, the resolver is the entity following the chain,
> and does so in a topologically consistent manner. Each resolver instance

I share your concerns on how useful ANAME will be or whether it will
actually solve problems.
To make matters worse, for an authority to use ANAME in conjunction with a
CDN that returns
dynamic responses for mapping and load balancing, it's likely that the
*authority* would also need
to use ECS with client subnet information for the A/AAAA lookups (as is
done by some of the largest
anycast open resolver services) but then dynamically resign the results.
This means online
ECS lookups with caching (often of names/records with very short TTLs)
and online signing which open up quite a few perf, scaling, and security
challenges
such as DDoS-attack-resilience.

One of the reason that at least some CDNs have built integrated-stack
solutions
to DNS authorities that can do CNAME collapsing internally is that this
allows them
to do proprietary optimizations to resolve some of the issues described
here.

If a stated goal of ANAME is to allow authorities distinct from a CDN to
follow
a CNAME chain to a given CDN and then incorporate the results in their
answer
for the zone apex (to improve vendor agnosticism), it may also be worth
really validating whether the design will scale and be performant and
interoperate
with such CDNs.  Since this is being configured by the owner of a zone,
they are likely incentivized to make sure that whatever is configured
actually
works well and provides good end-user overall performance (not just DNS
lookup
performance).  Not incorporating client information (eg, via ECS) into
responses
and/or substantially increasing TTLs are likely to cause significant
overall problems.
The result may then be "who will actually use ANAME as described here and
for what?".

Exploring some of the alternatives as you suggest may result in
slower-to-deploy
but overall more widely adoptable approaches.

        Erik

---

From: Bob Harold <[email-masked]>
Date: Fri, 2 Nov 2018 15:20:01 -0400

My thoughts at the bottom...

> The requirement to maintain sibling records (A/AAAA) itself is absolutely
> a "camel back breaking" requirement. The issues are: frequency of updates
> trying to preserve, is that of resolver-based *NAME chain resolution, just
> with the ability to do so at the apex of a zone.
>
> Another option would be a similar type, maybe ACNAME (address CNAME),
> which could co-exist with other types, and could occur both at an apex and
> A third option would be, for lack of a better term, WCRR, wildcard RR
> type, whose RDATA is an FQDN. The logical processing would be to add
> handling at the point where "NOERROR, NODATA" would otherwise be returned,
> right above the WILDCARD in the resolution process. If no match for QTYPE
> is found, check for WCRR type, and return that it found. Resolver handling
> would be the same; if a WCRR type is returned, replace the QNAME with the
> RDATA and re-start query processing.
>

I agree that unlimited updates could be an issue, but I think we can make
this work.

This might not be what the RFC says, but in reality I would likely handle
it this way:
I would treat this as a stepwise improvement.
I would suggest rolling this out in steps:
1. Allow adding ANAME records. Do not change any of the existing records,
and do not do any new updates.

Authoritative servers:

   - If the authoritative is not doing "proprietary A record updates" or
   "location based A records" (the premium feature you call "stupid DNS
   tricks") then there is no significant change in effort. They have a single
   set of A records for everyone, same as currently. Just also send the ANAME
   record.
   - If the authoritative is using "proprietary A record updates", it
   continues to do that. Just also send the ANAME record.

Resolvers:

   - If a resolver does not understand ANAME, nothing changes.
   - If a resolver does ANAME, it gets an immediate advantage.

2. ANAME style updates to the authoritative.

If not doing proprietary updates currently, this is a new feature, and
might require a premium cost.

   - Limit to one ANAME at the apex, or price per ANAME if needed.
   - Limit the update rate, or charge based on rate.

If currently using proprietary updates, convert to ANAME style updates, at
the same rate, and using the same DNSSEC signing mechanism that it used for
the proprietary updates. And charge the same amount.

3. Years later, when most all of the resolvers on the planet have updated
to understand ANAME, give users the option to remove the A and AAAA
records, and remove the update processing and charge less for the
simplified version. This might take decades and might never happen.

Another option to give users is a non-updating fallback A record, that
could point to a web redirect.  That saves all the hassle of updates.  (I
encourage users to redirect the apex to www... and the I CNAME www to the
CDN.  Some users don't want the www, but it solves the DNS problem.)

 My preference would be a *NAME record that specifies which record types it
applies to.  So one could delegate A and AAAA at apex to a web provider, MX
to a mail provider, etc.  That would also be valuable at non-apex names.
But I am happy to support ANAME as part of the solution.

-- 
Bob Harold

---

From: Richard Gibson <[email-masked]>
Date: Fri, 2 Nov 2018 17:00:47 -0400

I haven't reviewed the full draft yet, but am happy to see some people 
echoing my sentiments from earlier versions [1]. I particularly wanted 
to agree with some statements from Bob Harold.

On 11/2/18 15:20, Bob Harold wrote:
> could point to a web redirect.  That saves all the hassle of updates.

YES! This means a slightly worse fallback-only experience for users 
behind ANAME-ignorant resolvers that query against ANAME-ignorant 
authoritatives (the introduction of ANAME awareness to /either/ 
component allowing an opportunity to provide better address records by 
chasing the ANAME target), but provides a dramatic reduction in the 
amount of necessary XFR traffic. And even more importantly, it forces 
TTL stretching to be an explicit decision on the part of those 
administrators who choose to perform manual target resolution and update 
their zones to use them as fallback records (as they would do now to 
approximate ANAME anyway), rather than an inherent and enduring aspect 
of the functionality.

Treating ANAME-sibling address records as fallback data also supports 
better behavior for dealing with negative results from resolving ANAME 
targets (NODATA, NXDOMAIN, signature verification failure, response 
timeout, etc.)—serve the fallbacks.

> My preference would be a *NAME record that specifies which record 
> types it applies to.  So one could delegate A and AAAA at apex to a 
> web provider, MX to a mail provider, etc.  That would also be valuable 
> at non-apex names.  But I am happy to support ANAME as part of the 
> solution.
I agree on both counts (arbitrary type-specificity and deferment to a 
later date).

[1]: https://www.ietf.org/mail-archive/web/dnsop/current/msg21722.html

---

From: Paul Vixie <[email-masked]>
Date: Fri, 02 Nov 2018 14:06:31 -0700

for the love of god, please, do not add more complexity, logic, 
computation, or network fetching to recursive name servers. if it's your 
belief that a static solution can't work, push for SRV.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 3 Nov 2018 08:24:15 +0700

> resolvers validate. The DNS can change, at a sometimes glacial speed,

According to https://ithi.research.icann.org/graph-m5.html, the worldwide fraction of public DNS that performs DNSSEC validation is about 25%.

--Christian Huitema

---

From: "John R Levine" <[email-masked]>
Date: 3 Nov 2018 08:42:46 +0700

> resolvers validate. The DNS can change, at a sometimes glacial speed,

Sure, but DNSSEC addresses a huge security problem, and it's taken a 
decade to get fairly wide adoption.  ANAME basically works around a 
configuration mistake.  If we can't solve it in the servers with the 
configuration problems, it's not worth solving.

Regards,

---

From: Lanlan Pan <[email-masked]>
Date: Sat, 3 Nov 2018 08:42:43 -0400

Brian Dickson <[email-masked]>于2018年11月2日周五 上午9:38写道：

> While not a prime motivation for ANAME or its alternatives, it is
> certainly (or should be) one of its goals.
>
> That's the primary point; when non-toy situations with paying customers
> are considered, it isn't up to you to decide what the update rate is, and
> you don't have the luxury of not caring.
>
>> with
> Anycast caches do not have any expectation or requirement to be sync'd,
> and in particular, due to stupid DNS tricks, are typically topologically
> sync'd to regional answers.
>
> Anycast caches with smaller footprint or odd customer bases, might do
> those hacks, but even without them, there will be significant differences
> in the contents of those caches, in different locations.
>
>    - If ??? is an ANAME, which does a tracking query FROM ONE LOCATION,
>    and mirrors that out to many anycast instances, then one of two results
>    will be seen in the mini-example case:
>       - According to the HTTP folks, neither of those is "acceptable"..
>
> Agree.
I think it finally depended on recursive's decision.
Authoritative wants to select the "best" response to client. ANAME returns
multiple responses to recursive, then recursive selects the "best".
Authoritative is hardly to know which RR is selected as response to the
client.
Is authoritative's best response same with recursive's best response ?

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

潘蓝兰  Pan Lanlan

---

From: Joe Abley <[email-masked]>
Date: Sat, 3 Nov 2018 12:04:18 -0700

On Nov 3, 2018, at 03:20, Bob Harold <[email-masked]> wrote:

> My preference would be a *NAME record that specifies which record types it applies to.  So one could delegate A and AAAA at apex to a web provider, MX to a mail provider, etc.  That would also be valuable at non-apex names.  But I am happy to support ANAME as part of the solution.

I don't understand this suggestion.

Some use-cases (or even hypothetical examples) might help.

Joe

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 3 Nov 2018 20:32:58 +0100

> Some use-cases (or even hypothetical examples) might help.

example.org. IN SOA foo bar 2018102802 300 3600 3600000 300
example.org. IN NS	primary.se.
example.org. IN NS	secondary.se.
example.org. IN MX	10 some.host.gmail.com
_http._tcp.example.org. IN URI	10 20	"https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/"
example.org. IN	TXT	"v=spf0x41 not valid. because SPF records belong in RRtype 99."
example.org. IN	AFSDB	1 db0.example.org.
example.org. IN	AFSDB	1 db1.example.org.
example.org. IN	AFSDB	1 db2.example.org.
example.org. IN SPF	"v=spf1 +all"

We already have this. We need not build a new mechanism. 

/Måns, sounding like a broken record. 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Is this an out-take from the "BRADY BUNCH"?

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 04 Nov 2018 09:53:02 +0400

> We already have this. We need not build a new mechanism.

+1

   Patrik

---

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 14:10:52 +0700

>> We already have this. We need not build a new mechanism.

-1

What are the semantics of this?

- What appears in the user's UI when the URI record completely replaces 
the site name entered by the user?

- Which domain name is the SSL cert validated against?

- Which domain name appears in the HTTP Host: header?

- What is the HTTP "Origin" of the resultint content,
   and which domain's cookies are accepted / sent?

- What if there's also a URI record for 
'example-lb-frontend.hosting.namn.se' ?

- How do I provision a wildcard record for this?

I see absolutely zero chance of the web community embracing this.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Sun, 04 Nov 2018 01:05:50 -0700

Ray Bellis wrote:
> > ... "URI RR" ...

as evidenced by RFC 8484, the web community seems to regret basing their 
work on the Internet System, and is now moving independently. this may 
mean that offering them something like "HTTP RR" which can't work better 
than SRV or URI already works, because they speciously refuse to embrace 
these working technologies, will buy you nothing.

-- 
P Vixie

---

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 16:01:34 +0700

On 04/11/2018 15:05, Paul Vixie wrote:

> as evidenced by RFC 8484, the web community seems to regret basing
> their work on the Internet System, and is now moving independently.
> this may mean that offering them something like "HTTP RR" which can't
> work better than SRV or URI already works, because they speciously
> refuse to embrace these working technologies, will buy you nothing.

Members of both communities had what I felt was a very productive side
meeting during the Montreal IETF, at which I also believe there was an
acceptance that both "sides" need to come together for a mutually
agreeable solution.

I don't think that either SRV or URI are usable for the primary use
case, i.e. allowing a domain owner to put a record at the apex of
their zone that points at the hostname of the web provider they want to
use.   I personally don't think that ANAME is a good solution either.

Hence my draft which I hope is a move towards that middle ground that we
can all work with.  I have already had positive feedback from some HTTP 
people, but antagonising them won't help.

Ray

---

From: Brian Dickson <[email-masked]>
Date: Sun, 4 Nov 2018 18:16:01 +0700

Ray Bellis wrote:
> use.

Is the apex thing an optimization only (i.e. is it acceptable that the
mechanism for apex detection not be 100% effective)? I think that's the
input needed before it makes sense to go down any particular branch of
design work, by either the http folks or the dns folks.

Is knowing when something is (or is at least expected to be) the apex, one
of the fundamental drivers on this issue?

Is the question of how the "effective TLD list" is maintained, published,
integrated, etc., something we could/should look closer at, or is that a
big can of worms we should stay away from? E.g. get it published by IANA,
through multiple mechanisms, and formalize the update to it through the
TLD/registry creation process at ICANN? Is it necessary to change/improve
the process, publication, ownership, etc. in order for browsers to reply on
it at a protocol level?

I.e. Rather than rely on hunting for SOA records in DNS and/or looking for
NSes for zone cuts, is making a first pass determination by looking at
whether the "authority" of the URI, aka the FQDN, is one level below an
"effective TLD"? If I have "example.com" or "example.co.jp", or "
example.com.au", and I have the current, comprehensive list of places
someone can register domains, I know that in those cases, "example" is an
apex name. Or does the solution to this problem need to handle apex names
for internal-to-a-registrant zone cuts?

Use of ETLDs could drive the initial query to be some new record type that
exists at a zone apex.
(The ETLD list gives an answer to "is it the apex" which is either "yes" or
"maybe", because zone cuts below the ETLD+1 level can exist, obviously.)

Related, follow-on question:
If that new record type were pointing to the owner name (i.e. itself), or
otherwise signaled that an A/AAAA at the owner name should be used, would
having the authority server return the A/AAAA records as well fix the
multiple-lookups issue, i.e. not require the lookup of the A/AAAA records
if the new record type was not present?
(The distinction between a self-referential or empty RDATA answer, and a
NOERROR/NODATA lack of RR, would be the indicator on whether the zone owner
wanted to play nice with the optimizations. The client would probably also
need to do separate A/AAAA queries in the NOERROR/NODATA case, since the
triggering URI would still need to its authority name to be resolved to an
address.)

I.e. :
@ NEWRRTYPE @ ; (or empty RDATA, signaling that the response needs to
include A/AAAA, and that the client should expect A/AAAA in the response)
@ A <apex IPv4>
@ AAAA <apex IPv6>

or
@ NEWRRTYPE www.myproviders.fqdn ; points out of zone, so no additional
data -- but client/recursive needs to chase RDATA down like it was a CNAME

I realize in this hypothetical model, both authority and recursive servers
need updates.
Or is the returning A/AAAA on the empty/self-ref a strictly optional
optimization, and thus not a barrier to adoption?
(The client can't do a parallel query for the A/AAAA records, because it
needs the first answer to get the name for the second query. But it can do
the queries sequentially without the assistance of the recursive.)

I anticipate both the new record type and additional processing, would be
less problematic on authority operators than ANAME.
It adds more additional processing, but does not change the general model
of mostly-static zone data, which plays nice with DNSSEC.

For the recursives, the incremental change is the same additional
processing as authority servers (additional data if empty/self-ref,
possibly with extra queries, or CNAME-type processing.)

Also: would this new record type (and query/response logic) make sense to
use everywhere, not just at a zone apex? I think there would be nothing
implicitly difficult in making it universal, on both the authority and
recursive servers. For the recursive servers, I don't think they even have
the ability to distinguish whether a name is apex or not (!!). For
authorities, I don't think there's anything intrinsically apex-ish about
what is required, so it would probably be less work to support the new
record type anywhere.

Brian

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 04 Nov 2018 15:31:56 +0400

:-)

> What are the semantics of this?

The semantics is exactly like a CNAME + HTTP Redirect.

Provisioning is like any provisioning in the DNS, with the advantage that you can delegate the prefix:ed domain just like you can do with any _tcp and similar prefix domain to whatever administrative entity that manage the web. You can that way separate the DNS and web administration between two different entities.

That some people want a record at the apex is a big mistake as one that way must mix explicitly the administration of that name between two entities that do different things.

See how well the AD delegation works where you can split the AD functionality from the DNS functionality by doing "the right delegations", which makes enterprise DNS much easier to set up than if (more) stuff is to be entered at the apex.

We have apex overload, and that must be taken care of.

   Patrik

> - What appears in the user's UI when the URI record completely replaces the site name entered by the user?
>
> - What if there's also a URI record for 'example-lb-frontend.hosting.namn.se' ?
>

---

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 20:02:38 +0700

> The semantics is exactly like a CNAME + HTTP Redirect.

The latter part is what I expected, and why I think it's a non-starter.

HTTP Redirects cause the URI in the address bar to be changed.  A lot of 
the whole "CNAME at the Apex" issue arises because lots of marketing 
people don't want end users to have to type *or see* the www prefix.

Those folks aren't going to stand for their nice clean "example.com" URL 
getting replaced with the real CDN address in the address bar.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 20:19:35 +0700

On 04/11/2018 18:16, Brian Dickson wrote:

> Is the apex thing an optimization only (i.e. is it acceptable that
> the mechanism for apex detection not be 100% effective)? I think
> that's the input needed before it makes sense to go down any
> particular branch of design work, by either the http folks or the dns
> folks.

It's not a question of apex *detection*, it's that DNS simply doesn't
allow for the *provisioning* of a CNAME record at the apex.

Nor can you put a CNAME alongside any other "useful" DNS records, so you 
can't, for example, have a zone that looks like this:

$ORIGIN example.com
@                IN SOA   ...
                  IN NS    ...
company-division IN MX    <company mail system>
company-division IN CNAME <cdn web host>

[I should perhaps put that as an example in the draft]

> Is knowing when something is (or is at least expected to be) the
> apex, one of the fundamental drivers on this issue?

No, the mechanism is general purpose and could be used for any
domain name that requires redirection (at the DNS / hostname level) to a
hostname that does not match the domain name in the URI.

[snipping irrelvant stuff about effective TLD lists]

> Related, follow-on question: If that new record type were pointing to
> the owner name (i.e. itself), or otherwise signaled that an A/AAAA at
> the owner name should be used, would having the authority server
> return the A/AAAA records as well fix the multiple-lookups issue,
> i.e. not require the lookup of the A/AAAA records if the new record
> type was not present?

Although it's not documented as such yet (and I should, because it's an
important clarifaction) an HTTP record that points to itself would be an
error, in the same way that a CNAME loop would be.

Architecturally, the important part of my proposal is that resolution of
the A and AAAA records is done *at the recursive layer* of the DNS, with
no interference with how authoritative resolution works.

[the only exception is if EDNS Client Subnet is in use, but that's a
case where the authoritatives already know how to generate the right
answer for any particular subnet]

> [snippage]

> I anticipate both the new record type and additional processing,
> would be less problematic on authority operators than ANAME.

The new record type has *no* implications at all for authority operators
other than in their provision systems, and since it uses the same RDATA
format as a PTR or CNAME record the implications there should be minimal.

> It adds more additional processing, but does not change the general 
> model of mostly-static zone data, which plays nice with DNSSEC.

There's *no* additional processing done in authoritatives.  I suppose
theoretically if the target happens to be on the same server as the
owner name than an authority might also include the A and AAAA records,
but it's not specified that way at the moment.
> possibly with extra queries, or CNAME-type processing.)

Roughly, except per above, this is the *only* incremental change in the
DNS infrastructure.   The other necessary change is in the HTTP clients
themselves, which IMHO is how it should be.

> Also: would this new record type (and query/response logic) make
> sense to use everywhere, not just at a zone apex?

Yes, per above.

> I think there would be nothing implicitly difficult in making it
> universal, on both the authority and recursive servers. For the
> recursive servers, I don't think they even have the ability to
> distinguish whether a name is apex or not (!!). For authorities, I
> don't think there's anything intrinsically apex-ish about what is
> required, so it would probably be less work to support the new record
> type anywhere.

It's not apex specific at all, but its design is specifically intended 
to address the CNAME at the apex issue.

kind regards,

Ray

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 04 Nov 2018 08:56:31 -0700

ray> HTTP Redirects cause the URI in the address bar to be changed.  A
ray> lot of the whole "CNAME at the Apex" issue arises because lots of
ray> marketing people don't want end users to have to type *or see* the
ray> www prefix.

ray> Those folks aren't going to stand for their nice clean
ray> "example.com" URL getting replaced with the real CDN address in the
ray> address bar.

Last I heard, they're taking care of this by taking away the address bar
completely. You and I will have to set some kind of debug mode to ever
see this. So that in and of itself isn't a deal breaker. But let's get
comment from the firefox/chrome folks. I agree with you that we're
having some productive back and forth. I think that we've learned some but
not all of each other's spaces.

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 04 Nov 2018 09:02:39 -0700

ray> Architecturally, the important part of my proposal is that
ray> resolution of the A and AAAA records is done *at the recursive
ray> layer* of the DNS, with no interference with how authoritative
ray> resolution works.

Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
that this is what they want, since they are largely driving all of this?

I'd guess that they would prefer this in the auth layer, where they own
or have contractual relationship with the zone owner.

Yes, as DNS software folks, we'd like to keep auth doing auth and have
only recursive doing lookups but I'm not sure that solves the problem in
a way that will be accepted.

---

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 23:34:51 +0700

> a way that will be accepted.

My expectation is that this would work for them exactly the way a CNAME 
does (i.e. via EDNS Client Subnet or similar) but without the restrictions.

Ray

---

From: Dan York <[email-masked]>
Date: Sun, 4 Nov 2018 23:02:30 +0000

> 
> On Nov 4, 2018, at 8:02 PM, Ray Bellis <[email-masked]> wrote:
> 
>  A lot of the whole "CNAME at the Apex" issue arises because lots of marketing people don't want end users to have to type *or see* the www prefix.

Exactly. As many of us traveled through various airports to get to Bangkok, there were many large advertisements on walls, banners, and everywhere else. 

The people who make those ads have a limited amount of space in which to put the companies contact info. If they remove "www." and just use "example.com", they can make the font size larger and the text more visible. This is just one of the reasons people in marketing / communications teams want to drop the "www".  (A similar reason of spacing is why you almost never see anyone including "http(s)://" in advertisements.)

As someone managing a team responsible for multiple websites, and who has people asking about dropping the "www" on different sites, I tried to capture the business requirements as they relate to CDN usage in this draft I just submitted today:

--------

Name:		draft-york-dnsop-cname-at-apex-publisher-view
Revision:	00
Title:		CNAME at apex - a website publisher perspective
Document date:	2018-11-05
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-york-dnsop-cname-at-apex-publisher-view-00.txt <https://www.ietf.org/internet-drafts/draft-york-dnsop-cname-at-apex-publisher-view-00.txt>
Status:         https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/ <https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/>
Htmlized:       https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-00 <https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-00>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-york-dnsop-cname-at-apex-publisher-view <https://datatracker.ietf.org/doc/html/draft-york-dnsop-cname-at-apex-publisher-view>

Abstract:
  There has been a large amount of discussion about the "CNAME at apex"
  issue within the DNSOP Working Group.  This draft provides the
  perspective of one publisher of multiple websites about why CNAME-
  like functionality is desirable at the apex of a domain zone.

--------

Dan

P.S. Right now we do have "internetsociety.org" redirecting to "https://www.internetsociety.org", which uses a CNAME to go out to a CDN. In our case we are okay with people seeing "www" in the address bar.  Other organizations want the www to disappear completely - and I have had that request for some of our other sites.

--
Dan York
Director, Content & Web Strategy, Internet Society
[email-masked]   +1-802-735-1624 
Jabber: [email-masked]  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 5 Nov 2018 09:35:28 +0100

> It's really good to see more discussion about ANAME.

I agree. 
 
> we should aim for in the long term, but that isn't what this work is

IMNSHO _any_ work on "fixing CNAMES at apex" that gets traction is 
a spanner in the works for what we seem to agree is a better solution.
A interim fix will be deployed and stall every attempt at DTRT.

I am well aware of "perfect being the enemy of good enough" but I'm not
certain DNAME is "good enough". 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS ...

---

From: Joe Abley <[email-masked]>
Date: Mon, 5 Nov 2018 18:55:58 +0700

> A interim fix will be deployed and stall every attempt at DTRT.

I think you are both right.

First, pragmatically speaking, there is clearly demand for something that can do "CNAME at apex". DNS companies sell it, people buy it. It already exists, but in as many flavours as there are providers that support it, so interop is difficult. Having multiple providers is good; interop makes that easier. Maybe there's work that the IETF could do here, but I would suggest that a solution that nobody implements is not much use. A reasonable starting point would be to survey the existing implementations and ideally get the enterprise DNS providers responsible to join in.

Second, what is the longer-term solution that seems least likely to cause painful intestinal cramping and bleeding eyes? I agree that if we want a clean answer we should be looking at the clients, not the authority servers. We have application-specific records like this for mail; I think we can confidently call MX a good solution for that problem. We decided that creating an unbounded set of application-specific RRTYPEs for this (each with their own semantics, each implemented separately) was idiotic, and and hence SRV. Let's not abandon that thinking unless we really have to.

Various people have expressed dubious arguments against the use of SRV for this. I don't think the answer to that is to create something functionally identical with a different name and somehow expect to be able to trick people with sleight of hand. I think the answer is to document the use-cases and dispassionately assess each of the arguments and work out whether they are real. My suspicion is that for a significant proportion of the problem space SRV is quite sufficient, and that in pragmatic terms we're really only talking about something like three client-side codebases that would need to implement it before we could call it universally-deployed.

But I could be wrong and maybe there really is a convincing reason to design something HTTP-specific. Either way, I think we need to show our working here, and by "we" I mean web people and DNS people who are prepared to work together.

So for what it's worth, this is what I think we should be doing:

1. Make the existing, proprietary, non-interoperable dumpster fire better if we can (maybe we can't; the way to tell is whether the enterprise DNS people are interested);

2. Find a client-side solution to this, and try really hard not to invent something new that is really just SRV with a hat and a false moustache.

Joe

---

From: manu tman <[email-masked]>
Date: Mon, 5 Nov 2018 19:25:37 +0700

I like the ANAME idea and find it overall simple if what we are trying to
solve is CNAME at apex. If what is being solved is per service then it is
another story.
As much as I like it, I find the resolution at the auth nameserver a bad
thing for a couple of reasons.

As has been mentioned before:
1) it will add workload on the authoritative nameserver which so far was
mostly doing key/value lookups and now may need to either recurse or
forward to a recursor.
2) the resolution from such lookup will be wrong for resolver/ecs based
answers as you will now get an answer for the recursor at the authoritative
site instead of the client (recursor talking to the auth or ECS). While
doing per site ANAME resolution may make the answers a bit more accurate,
it will definitely not help with operations.

if someone want to do the chaining, I guess they could already do it with
some tooling on their side which will perform regular lookup and update
their zones so essentially making the ANAME resolution an out of band task.

If all that was required was to return an ANAME in the additional section,
it would be pretty straightforward to implement on the authoritative side
and add no complexity there neither workload (or very minimal).
On the recursor side, this will most likely heavily reuse the CNAME logic
and may not be that complex to implement (implementors may tell otherwise).

Recursors that understand ANAMES will be able to treat it as a CNAME and
follow the name chain just like for CNAME. If they don't, well nothing has
changed for them.
It may take time before it gets widely deployed, but it would be a simple
solution that could be easily implemented by the auth that are interested
in it, gets picked up as the recursors get upgraded and be backward
compatible during the transition phase.

Manu

On Mon, Nov 5, 2018 at 3:35 PM Måns Nilsson <[email-masked]>
wrote:

> Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at
> 04:39:09PM +0000 Quoting Tony Finch ([email-masked]):

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Nov 2018 22:38:04 +0700

On 05/11/2018 18:55, Joe Abley wrote:

> 2. Find a client-side solution to this, and try really hard not to 
> invent something new that is really just SRV with a hat and a false 
> moustache.

There *is* a big failing of SRV that's independent of the CNAME apex use 
case, and that is its lack of support for wildcards.  Since my proposal 
doesn't use underscore prefix labels, wildcards will work, and this is 
an important requirement for some large website operators.

The cost to the DNS community of *trying* my proposed HTTP record is 
pretty negligible.  Worst case, as Brian put it, is we burn a code 
point, add a trivial amount of code to DNS servers, but the browsers 
don't adopt it.  It wouldn't be the first time, it won't be the last.

However, it only takes one of the big browser vendors to decide they'll 
support it and I think the rest will shortly thereafter follow suit.

NB: this proposal currently satisfies the criteria for assignment via
expert review per RFC 6895.

Ray

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 05 Nov 2018 09:21:45 -0700

mansaxel> IMNSHO _any_ work on "fixing CNAMES at apex" that gets
mansaxel> traction is a spanner in the works for what we seem to agree
mansaxel> is a better solution. A interim fix will be deployed and stall
mansaxel> every attempt at DTRT.

While I agree with this approach in principle, the reality is we've had
a couple of decades and never come up with anything enough better to get
used.

There are times when an 80% solution is better with 0%, even if it might
slow down perfect.

jabley> So for what it's worth, this is what I think we should be doing:

jabley> 1. Make the existing, proprietary, non-interoperable dumpster
jabley>    fire better if we can (maybe we can't; the way to tell is
jabley>    whether the enterprise DNS people are interested);

Yes. And get buyoff from the browser and large auth folks so it actually
gets used.

jabley> 2. Find a client-side solution to this, and try really hard not
jabley>    to invent something new that is really just SRV with a hat
jabley>    and a false moustache.

Also yes. Folks saying that SRV won't work for them aren't stupid. They
have their own agendas that don't consider DNS to be the most important
thing to them; to them it's a handy tool. We should respect that
attitude and come up with a legit new solution both sides can live with.

---

From: Jim Reid <[email-masked]>
Date: Mon, 5 Nov 2018 16:31:41 +0000

> On 5 Nov 2018, at 15:38, Ray Bellis <[email-masked]> wrote:
> 
> The cost to the DNS community of *trying* my proposed HTTP record is pretty negligible.  Worst case, as Brian put it, is we burn a code point, add a trivial amount of code to DNS servers, but the browsers don't adopt it.  It wouldn't be the first time, it won't be the last.

I think this is worth a punt. The risks/costs are low and the benefits are more than worth it.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 05 Nov 2018 09:32:44 -0800

there were several pro-HTTP-URI comments in this thread; i picked the 
one with the most technical meat. brian, jim, paul: thank you for your 
comments.

> an important requirement for some large website operators.

on that basis, i would ordinarily withdraw my objection, since the 
needed functionality is just not present in the existing code point.

> pretty negligible. Worst case, as Brian put it, is we burn a code point,
> add a trivial amount of code to DNS servers, but the browsers don't
> adopt it. It wouldn't be the first time, it won't be the last.

please don't think this way, and don't do the right thing for the wrong 
reasons. the paragraph above is how the camel came to be -- one draft at 
a time, all well-meaning.

the fully loaded long term cost to the economy of an "if" statement in a 
widely deployed C program is about USD 10.000. we should never add to 
this externalized cost unless we have a compelling reason to do so. "the 
web people don't want even one extra RTT, ever" is not compelling. "the 
web people need wildcards to work which they don't in SRV" however, is 
compelling.

> expert review per RFC 6895.

as may be, this looks like an argument over who has to fetch the data. 
the browser people don't want it to be them. i can't blame them, but the 
reason SRV specifies opportunistic rather than mandatory additional data 
is to keep the recursive DNS server from both fetching and caching (and 
now, validating) the AAAA/A, from having to keep the SRV transaction 
open longer (while its mandatory AAAA/A additionals are fetched and 
before the very first answer, a possibly soft cache-miss, is sent), and 
to avoid loading the network with a query whose answer might not be used 
(something else about the SRV response might have caused a failure in 
the www transaction such that the AAAA/A is never needed.)

those were solid and still-valid engineering-technology and 
engineering-economics considerations. when we add "HTTP URI" we do so at 
costs greater than a code point. and even the code point has to add some 
"if" statements to the globally deployed system. that won't be cheap, 
merely externalized. a cheeseburger that externalizes USD 10 of 
environmental cleanup costs onto the economy is still a USD 10 
cheeseburger, even if it only costs USD 0,25 to make and has a consumer 
price of USD 1.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 05 Nov 2018 09:36:23 -0800

second reply, on a more general topic:

the "HTTP URI" will require a change to bert's teaching resolver (tres), 
which correctly handles unrecognized code points and thus would need no 
changes at all if the additional data weren't mandatory. i think in 
modern terminology, if your proposed addition to the DNS protocol 
requires a change to "tres", it's (a) not "cheap", and (b) part of "the 
camel". we are adding state, logic, and signal. (ouch.)

more broadly: most ideas are bad, including mine, and especially when 
DNS is the subject area. self-deception about how cheap they will be 
looks wretched on us. let's not be that. if a change is to be made, let 
it be because there is _no_ existing way within the standard to 
accomplish some vital task. SRV's lack of wildcard support is adequate 
cause. two RTT's on a cache miss is not. apparent cheapness is not.

-- 
P Vixie

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Nov 2018 00:51:15 +0700

> a time, all well-meaning.

The front running alternative (ANAME) shifts the entire and far more 
considerable complexity entirely into the DNS, and affects both 
authoritative and recursive servers.  Even then, I don't think it'll 
work properly with geo-locating CDNs nor with DNSSEC.

ANAME is less complex for the browsers (zero cost, even), but it's close 
to another whole hump's worth of complexity for The Camel.

I accept that the cost of the HTTP RR is not zero, but if it does 
succeed, that cost will be far far lower than any of the alternatives.

cheers,

Ray

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Nov 2018 00:53:46 +0700

> camel". we are adding state, logic, and signal. (ouch.)

The additional data is not mandatory.

> cause. two RTT's on a cache miss is not. apparent cheapness is not.

Ack, except on that very last point (see previous message) where I think 
we need to consider the relative cost-benefit-analysis of the alternatives.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Mon, 05 Nov 2018 09:55:51 -0800

Ray Bellis wrote:
>> the "HTTP URI" ...

then, according to marka, the web people won't use it.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Nov 2018 05:12:09 +1100

People don’t want CNAME at the apex. They want a pointer to a server for a service at the apex.
CNAME provided a pointer to a server when the prefix was www. 

This can be done a number of ways.

1) Prefix  + name in rdata.
2) Service specific type + name in rdata. 
3) Generic type + service and name in rdata. 

This is DNS choices from the IAB. 

ANAME is a extremely complicated version of 2 for HTTP which may be morphed into 1 with a well known service name for other services but will always have the risk of being misinterpreted. 

There are much simpler ways to achieve 2 than ANAME for HTTP.
 
Mark
-- 
Mark Andrews

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Nov 2018 18:16:58 +0000

Joe Abley <[email-masked]> wrote:
> First, pragmatically speaking, there is clearly demand for something
> that can do "CNAME at apex". DNS companies sell it, people buy it. It
> already exists, but in as many flavours as there are providers that
> support it, so interop is difficult. Having multiple providers is good;
> interop makes that easier. Maybe there's work that the IETF could do
> here, but I would suggest that a solution that nobody implements is not
> much use.

Exactly.

> A reasonable starting point would be to survey the existing
> implementations and ideally get the enterprise DNS providers responsible
> to join in.

I've had informal chats with people from a number of big DNS providers.

* One or two big DNS providers see better interop as beneficial to
  themselves as well as their customers. (I guess if two DNS providers
  can get a customers to pay both of them then everyone is happy!)

* Standardization is a tempting opportunity to rationalize services and
  reduce technical debt.

* Dynamic on-demand ANAME substitution is difficult to do with reliably
  good performance at scale.

* Frequent UPDATEs are not something you want at large scale.

* One CDN said they wouldn't do general ANAME, only their existing
  vertically-integrated setup where the CDN controls the (notional)
  target.

So it's a mixture of great desire to have a solution to the problem, but
the auth-side solutions are unappealing to many key players. My plan was
basically to write a draft that waves its hands vigorously and says, yes!
whatever you are doing can be made to fit ANAME! But that won't work if
the response is, We aren't doing anything like ANAME and we don't want to
do anything like THAT. So I'm feeling less confident that it's going to
get consensus.

> Second, what is the longer-term solution that seems least likely to
> cause painful intestinal cramping and bleeding eyes? I agree that if we
> want a clean answer we should be looking at the clients, not the
> authority servers.

Yes. I kind of feel in a weird superposition of states, believing both
Evan's skepticism, and Ray's optimism.

I'm not sure what Web browser feature deployment timescales are like now.
Picking a random example, from https://caniuse.com/#feat=flexbox it looks
like full flexbox support started appearing in 2012 and it's now at about
96% availability (most of the gap being due to IE).

But for ANAME we're also concerned about other HTTP clients, especially
dozens of programming-language-specific libraries and long-term-support
enterpriseware with much slower deployment timescales. And ANAME is also
useful for ssh clients, though they don't have such a large userbase, but
ssh is very relevant to Tim's comments in his presentation about on-demand
compute services.

Which implies that even if HTTP records become a thing, there will be a
period of years during which zone admins will also have to provision
address records for backwards compatibility. What we have seen again and
again in this kind of situation is that operators will react with, What
benefit do I get from the effort to learn this new thing and the extra
work to support it? For HTTP records I fear the practical benefits in the
short term will be zero.

Or maybe there are ways to get positive benefits. If ANAME stalls I'm
inclined to implement auto-provisioning of address records driven by HTTP
records instead, as a non-standard short-term backwards compatibility
stop-gap.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Cyclonic, becoming westerly later, 5 to 7, increasing gale 8 or severe
gale 9 for a time in south. Moderate or rough, occasionally very rough in
south. Rain or thundery showers. Good, occasionally poor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Nov 2018 06:03:15 +1100

You can measure when to stop publishing A/AAAA records with HTTP by pointing the HTTP record at a different address.  Clients that are HTTP record aware will use one address and legacy clients will use the other address.

Mark
-- 
Mark Andrews

> On 6 Nov 2018, at 05:16, Tony Finch <[email-masked]> wrote:
>

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 05 Nov 2018 23:14:48 +0400

> _http._tcp.example.org. IN URI	10 20	"https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/"

Btw, this is sort of what I am thinking of for URI, cooked up directly after dinner. Could be a wrapper around curl that fetches stuff. Probably hundreds of bad stuff in what I have below, but still...you get the point.

You can try with http://www.frobbit.se/ or http://frobbit.se/ for example, as I have URI records for them.

#!/bin/sh

PREFIX=_http._tcp
DOMAIN=`echo "$1" | sed 's/^.*\/\/\([^\/]*\)\/.*$/\1/'`
QUERY=`echo "$1" | sed 's/^.*\/\/[^\/]*\/\(.*\)$/\1/'`
URI=`dig "$PREFIX.$DOMAIN." URI +short`
if [ "x$URI" = x ]; then
   NEWURI="$1"
else
   NEWURI="`echo $URI | awk '-F"' '{ print $2 }'`${QUERY}"
fi

echo curl -H "HOST:$DOMAIN" "$NEWURI"

---

From: Joe Abley <[email-masked]>
Date: Mon, 5 Nov 2018 13:07:00 -0800

Hi Ray,

> On Nov 5, 2018, at 22:38, Ray Bellis <[email-masked]> wrote:
>
> There *is* a big failing of SRV that's independent of the CNAME apex use case, and that is its lack of support for wildcards.  Since my proposal doesn't use underscore prefix labels, wildcards will work, and this is an important requirement for some large website operators.

I realise it's 4am and I shouldn't even be awake,  ever mind replying
to dnsop mail, but it's not clear to me what the use-case is, here.

Specifically, I s the wildcard owner name a real problem in the grand
scheme of things? I understand that wildcards are used by some people
for names that feature in HTTP URIs, but I'm struggling to imagine
using a wildcard at a zone cut; if a wildcard label doesn't correspond
to a zone apex, why is it a problem that needs fixing? Didn't Ed
already clarify the use of CNAME with wildcards in RFC 4592 twelve
years ago?

> The cost to the DNS community of *trying* my proposed HTTP record is pretty negligible.

To be clear, the rules are clear and you should feel as empowered as
anybody to apply for an early assignment of an RRTYPE and start
writing code. If I sounded like I was arguing against that I
definitely apologise!

However I think that a more coordinated approach that involves people
from both web and DNS communities to understand the problem space is
more sensible, though, and more likely to be productive for this
working group. It's not clear to me that either community has a great
track record just guessing at what the other one wants.

Joe

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Nov 2018 07:43:25 +0700

On 06/11/2018 04:07, Joe Abley wrote:

> using a wildcard at a zone cut; [...]

You're not wrong, because most often the wildcard is indeed a label 
below that cut.

However, the intent is that this record would eventually replace *all* 
use of CNAME for web redirection regardless of whether at the zone cut 
or not.

This isn't a wildcard example, but here's a re-post of a currently 
impossible zone configuration from one of my emails Sunday:

$ORIGIN example.com
@                IN SOA   ...
                  IN NS    ...

Replacing that CNAME with HTTP makes this configuration possible.

> writing code. If I sounded like I was arguing against that I

No worries! :)

> track record just guessing at what the other one wants.

I've been actively socialising this with web people since Saturday even 
before the draft was submitted.  I'm going to be talking about it 
briefly at HTTP-bis this morning.

This draft is IMHO not so much a "guess", but a "starting point" based 
on what web folks said at the side meeting in Montreal.

Yes, it'll require browser implementors to update their code, but the 
alternative is breaking the camel's back.

cheers,

Ray

---

From: Olli Vanhoja <[email-masked]>
Date: Tue, 6 Nov 2018 09:23:14 +0100

> getting replaced with the real CDN address in the address bar.

It's not only about what is shown in the address bar but how fast the
website will
start rendering something on the screen. Even resolving a CNAME may add a
proportionally big delay to the TTFB, it could take about the same time as
TLS
negotiation. In fact if you look at the DNS records some big Internet
companies
they rarely use CNAMEs for www but instead you'll see an A record, that
might
be even backed by a proprietary ANAME solution.

---

From: Thomas Peterson <[email-masked]>
Date: Tue, 06 Nov 2018 10:22:32 +0000

That may be the case from your own (presumably anecdotal) experience, however I took the Alexa top 1 million websites and queried for A* and CNAME against the www records for the top 10 000 domains. What I found is that approximately 44% returned CNAME records, 56% returning A records.

Code is https://gist.github.com/thpts/eb5cec361867170a0ffd6ede136c6649 here if anyone wishes to look.

Regards

* I realise that I could have added AAAA. My presumption is that the top 10k websites are not v6 only and at least have an A record in place.

From: DNSOP <[email-masked]> on behalf of Olli Vanhoja <[email-masked]>
Date: Tuesday, 6 November 2018 at 08:24
To: <[email-masked]>
Subject: Re: [DNSOP] Fundamental ANAME problems

In fact if you look at the DNS records some big Internet companies

they rarely use CNAMEs for www but instead you'll see an A record, that might

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Nov 2018 13:44:35 +0000

Joe Abley <[email-masked]> wrote:
> scheme of things?

My understanding is that wildcards don't work for SRV because the
_prefixes are used to disambiguate which service you are asking for,
effectively to extend the RR TYPE number space. So if you wildcard a SRV
record then the target port has to support every possible protocol :-)

If you are using an _prefix without any meaning of its own but only to
move a record away from the apex (so that it can be delegated or CNAMEd)
and also using a specific RR type or an RDATA prefix, then wildcards do
not conflict.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Southeasterly 6 to gale
8. Moderate or rough, occasionally very rough later. Occasional drizzle. Good,
occasionally poor.

---

From: Joe Abley <[email-masked]>
Date: Tue, 6 Nov 2018 05:51:23 -0800

Hi Tony.

> On Nov 6, 2018, at 20:44, Tony Finch <[email-masked]> wrote:
>

Right, but my point was that wildcard owner names aren't seen at the
apex, so a solution to the problem of what to do at the apex doesn't
need to worry about them.

Ray has wider aspirations than just the apex. This may well be
sensible, but I think it's worth calling out the scope creep.

Joe

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 06 Nov 2018 17:58:45 +0400

On 6 Nov 2018, at 17:51, Joe Abley wrote:

> Right, but my point was that wildcard owner names aren't seen at the apex, so a solution to the problem of what to do at the apex doesn't need to worry about them.
>
> Ray has wider aspirations than just the apex. This may well be sensible, but I think it's worth calling out the scope creep.

We should also remember that there is a different goal as well, and that is to be able to delegate the zone within which "the records dealing with web" is managed so that the administrative responsibility is separated between the one which run the zone for example.com and the ones that run for _http._tcp.example.com (or _tcp.example.com).

   Patrik

---

From: Dan York <[email-masked]>
Date: Tue, 6 Nov 2018 15:56:22 +0000

Olli,

> On Nov 6, 2018, at 3:23 PM, Olli Vanhoja <[email-masked]> wrote:
> 

One detail about this is that if the CDN being used by the large Internet company is *also* providing the DNS hosting for the Internet company, then the CDN will do its resolution internally and return A / AAAA records directly. 

I did not do the kind of large scale measurement that Thomas Peterson did, but in anecdotally looking at the www records for a number of sites returning A/AAAA records, I often saw that the ones returning A / AAAA records also had NS records pointing to name servers run by CDNs I could recognize.  (I mentioned this in a note currently as section 2.1 of https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/ <https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/>  )

So yes, in those cases the A record is being dynamically created by whatever (potentially proprietary) ANAME/CNAME-like solution the CDN vendor is using internally in their DNS hosting operations. 

Dan

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Nov 2018 17:28:59 +0000

I'm going to use Richard's message as a starting point because I wanted to
write about fallback addresses, but I have kind of changed my mind so this
message is really about the possibility of deeper reductions / revisions
to the ANAME draft.

Richard Gibson <[email-masked]> wrote:
> > Another option to give users is a non-updating fallback A record, that could
> > point to a web redirect.  That saves all the hassle of updates.
>
> YES! This means a slightly worse fallback-only experience for users behind
> ANAME-ignorant resolvers that query against ANAME-ignorant authoritatives (the
> introduction of ANAME awareness to /either/ component allowing an opportunity
> to provide better address records by chasing the ANAME target), but provides a
> dramatic reduction in the amount of necessary XFR traffic. And even more
> importantly, it forces TTL stretching to be an explicit decision on the part
> of those administrators who choose to perform manual target resolution and
> update their zones to use them as fallback records (as they would do now to
> approximate ANAME anyway), rather than an inherent and enduring aspect of the
> functionality.
>
> Treating ANAME-sibling address records as fallback data also supports better
> behavior for dealing with negative results from resolving ANAME targets
> (NODATA, NXDOMAIN, signature verification failure, response timeout,
> etc.)—serve the fallbacks.

Matthijs Mekking has tried hard to persuade me of the merits of fallback
addresses, but I didn't really like the idea for a couple of reasons:

  * They break the elevator pitch, "like CNAME but only for address
    records" because fallback addresses aren't a thing that CNAMEs have.

  * With the UPDATE semantics there isn't anywhere for the fallback
    records to belong.

But thinking about the discussions from the weekend and yesterday, it
occurs to me that it might make sense to simplify ANAME even further:

  * Make all authoritative processing optional, whether UPDATE style or
    dynamic on-demand.

  * The sibling address records have to be provisioned, to act as fallback
    records for clients/resolvers that don't (yet) do their own ANAME
    processing. (There may be some automated assistance.)

I'm not entirely comfortable leaving so much unspecified, but it has some
advangates:

  * It's maybe still enough of a spec to provide the zone file
    portability that a lot of people want

  * It can fit both the Oracle/Dyn model or my UPDATE model with only a
    moderate amount of straining

  * It might work with the nay-sayers, who can continue doing their
    vertically-integrated thing to provision the address records

  * It won't give mass domain hosters indigestion from high UPDATE
    frequency

  * It doesn't require static authoritative servers to become dynamic

The result is getting weirdly close to the HTTP record proposal, though
there are still significant differences:

  * Target address records fetches in the resolver vs in the application

  * Authoritative support optional vs not present

  * General purpose (also works for ssh, databases, etc) vs HTTP-specific

So I'm wondering,

Does it make sense to strip ANAME back this far?

Is ANAME/HTTP convergence a useful accident or a foolish distraction?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover: South 5, increasing 6 or 7, perhaps gale 8 later.
Slight or moderate, occasionally rough later. Rain later. Good, occasionally
moderate later.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 7 Nov 2018 01:30:21 +0700

On 06/11/2018 20:58, Patrik Fältström wrote:

> We should also remember that there is a different goal as well, and
> that is to be able to delegate the zone within which "the records
> dealing with web" is managed so that the administrative
> responsibility is separated between the one which run the zone for
> example.com and the ones that run for _http._tcp.example.com (or
> _tcp.example.com).

That's an implicit non-goal of my draft.  I may have to make it more 
explicit.

You can have wildcard support, or you can have prefixes (hence
delegation), but you can't have both.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Wed, 7 Nov 2018 01:36:13 +0700

> record then the target port has to support every possible protocol :-)

No, it's because you can't do:

_http._tcp.*.example.com IN SRV ...

> and also using a specific RR type or an RDATA prefix, then wildcards do

I believe they still do, e.g.

_domainkey.*.example.com IN TXT ...

Ray

---

From: Ray Bellis <[email-masked]>
Date: Wed, 7 Nov 2018 01:37:30 +0700

> sensible, but I think it's worth calling out the scope creep.

It's in the intro text:

"This document specifies an "HTTP" resource record type for the DNS to
  facilitate the lookup of the server hostname of HTTP(s) URIs.  It is
  intended to replace the use of CNAME records for this purpose, and in
  the process provides a solution for the inability of the DNS to allow a
  CNAME to be placed at the apex of a domain name"

Ray

---

From: Ray Bellis <[email-masked]>
Date: Wed, 7 Nov 2018 01:51:24 +0700

>    * General purpose (also works for ssh, databases, etc) vs HTTP-specific

I just wanted to address this particular point, again.

IMHO, any record that doesn't support a service selector isn't doing its 
job properly.

You _have_ to be able to say "if I want this service at this domain, I 
either prepend this prefix, or lookup this type", otherwise you're just 
forcing _all_ services to connect to the A and AAAA found there.

A and AAAA should be for connecting to the right _host_, once you've 
established from the _service_ which host that is.

Ray

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Nov 2018 19:03:41 +0000

> _domainkey.*.example.com IN TXT ...

You obviously can't do that, but you can do:

	*.example.com TXT ...

and it'll match queries for tag._domainkey.whatever.example.com.

Except that it won't work very well for the specific example of _domainkey
records, because of the tag selector in the qname.

It will probably work OK for DMARC records which do not have any selectors
in the qname and which have a nice prefix in the TXT RDATA.

For the runing LJ example, if you want to match

	_http.fanf.livejournal.com HTTP ...

the zone admin can publish

	*.livejournal.com HTTP ...

But for the HTTP case, the record itself provides enough indirection so
there isn't any need for a _prefix to allow delegation as you might want
to for DMARC.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes, Southeast Southeast Iceland: Southeasterly 5 to 7,
occasionally gale 8 in Fair Isle. Rough, occasionally very rough. Occasional
rain. Moderate or good, occasionally poor.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 7 Nov 2018 02:07:06 +0700

p.s. anyone thinking a new _generic_ resource record is required, please 
(re)read RFC 5507.

HTTP started off with a service identifying prefix, but it was merely by 
convention, and it was "www."

This whole mess started because folks wanted to get rid of that service 
identifier, but a) didn't recognise it as being one, and b) therefore 
didn't consider what would replace it.

Ray

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Nov 2018 19:45:30 +0000

Ray Bellis <[email-masked]> wrote:
> IMHO, any record that doesn't support a service selector isn't doing its job
> properly.

Yes.

My point above is to do with what existing ANAME-like things expect client
software to do, i.e. connecting to hosts rather than services. It isn't a
judgment about what's good, but an observation about what is done. And it
raises questions about trade-offs between compatibiliy with the installed
base or improving things for the future. I don't have the answers :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
a fair voting system for all elections

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 07 Nov 2018 07:13:16 +0400

> delegation), but you can't have both.

Thats exactly my point. URI solves "the other problem".

   Patrik

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 7 Nov 2018 11:15:06 +0100

>      processing. (There may be some automated assistance.)

That is indeed what I am aiming at, with the exception that sibling 
records may be provisioned to act as fallback records (they don't 
necessarily have to, but the ANAME algorithm may use them if they exist 
and if resolution of the target address records failed).

---

From: Richard Gibson <[email-masked]>
Date: Wed, 7 Nov 2018 15:48:01 -0500

This is such a salient point, and always draws me back towards a desire 
for accompanying questions. They wouldn't directly address exactly the 
issue handled by ANAME (the addresses of one host corresponding to those 
of a distinct [probably out-of-bailiwick] name), but might make it 
moot—or at least tolerable—by tackling more fundamental progress 
blockers. Support for covering apex A, apex AAAA, and service-specific 
SRV (especially with target host addresses in the additional section of 
the response) in a single transaction could absolve many sins.

On 11/6/18 13:51, Ray Bellis wrote:
> IMHO, any record that doesn't support a service selector isn't doing 
> its job properly.
>
> either prepend this prefix, or lookup this type", otherwise you're 
> just forcing _all_ services to connect to the A and AAAA found there.
>

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 8 Nov 2018 04:13:50 +0700

Tony says this:

" It isn't a judgment about what's good, but an observation about what is
done."

I can't stress this enough - when you see ALIAS records at zone cuts that
point to a database server,
already, then we've missed the "server specific" ball.

And can someone show a significant number of SRV examples outside of SIP
and some gaming
servers?

---

From: Ray Bellis <[email-masked]>
Date: Thu, 8 Nov 2018 04:30:24 +0700

On 08/11/2018 04:13, Tim Wicinski wrote:

> I can't stress this enough - when you see ALIAS records at zone cuts
>  that point to a database server, already, then we've missed the
> "server specific" ball.

This sounds like it ought to be a very unusual configuration.

Even with a zone cut, couldn't those DB servers have been addressed as 
'db.<domain>' instead?

> And can someone show a significant number of SRV examples outside of
> SIP and some gaming servers?

Kerberos and AD both use SRV records.  Bonjour uses SRV extensively.

Either way, SRV is only one of three different ways that services are 
differentiated (per 5507).

Ray

---

From: "Michael J. Sheldon" <[email-masked]>
Date: Wed, 7 Nov 2018 21:46:24 +0000

On 11/07/2018 02:13 PM, Tim Wicinski wrote:
> Tony says this:
> 
> " It isn't a judgment about what's good, but an observation about what
> is done."
> 
> that point to a database server, 

From data in our systems, most common in order is _autodiscover and
other email/calendar related, then sip, then jabber/xmpp. After that,
the numbers are far less significant.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com

---

From: tjw ietf <[email-masked]>
Date: Thu, 8 Nov 2018 11:44:00 +0900

From my high tech gadget

> On Nov 8, 2018, at 06:30, Ray Bellis <[email-masked]> wrote:
> 
> Even with a zone cut, couldn't those DB servers have been addressed as 'db.<domain>' instead?

Sure but as more than one engineer whose been using this for several years asks “why should I change? This works now and you’re just cramping engineering velocity. “

And saying “it’s not standard” doesn’t hold water. Sure there are migration issues but if folks stay in their vendor ecosystem....

These are the questions we as operators are asked regularly. These are the questions  DNSOP need to look forward on. 

> Kerberos and AD both use SRV records.  Bonjour uses SRV extensively.

I forgot about AD. Those are set up by admins right?

Doesn’t Bonjour create those records behind the scenes? 

People are saying a domain owner is going to log into godaddy and configure a SRV record. 

If you want to convince me SRV will work get the vendors to support it seamlessly. 

> Either way, SRV is only one of three different ways that services are differentiated (per 5507).
> 
> Ray
> 
> 
>

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 8 Nov 2018 16:05:28 -0500

It should be pointed out that the Autodiscover subsystem of Microsoft
Office uses SRV in a very *degenerate* way. It ignores all fields other
than target. In my testing, I believe I also proved that it doesn't fail
over if presented multiple SRV RRs in a response. So, basically it's a
one-to-one mapping between a (fixed-prefix + domain-specific-suffix) name
and a hostname, something that syntactically could have been accomplished
more simply using, say, PTR (which, contrary to common misconception, is
*not* limited to reverse lookups).

Personally, I would exclude Autodiscover from any list of "things which use
SRV", since its use is not consistent with the spirit or the letter of the
SRV RFCs.

                         - Kevin

---

From: Richard Gibson <[email-masked]>
Date: Thu, 8 Nov 2018 22:27:23 -0500

I have finally reviewed the latest draft directly, and like the overall 
direction but have a small number of issues (however, the issues 
theirselves are somewhat fundamental). They broadly break down into 
concerns about zone transfers and TTL stretching, and ultimately seem to 
stem from a disagreement with my position that the proper conception of 
ANAME sibling address records is as fallback data to be used in cases 
where ANAME target resolution fails or is never attempted.

First, I am troubled by the requirement that ANAME forces the zone into 
a dynamic zone. That a primary master would dynamically replace sibling 
records on its own, update the zone serial, and then propagate that 
dynamic data via zone transfer overrides user conception about the state 
of a zone, induces undesirable churn between authoritative nameservers, 
/and/ stretches the TTLs of ANAME targets on downstream servers by the 
amount of time between successive updates. These consequences are just 
too much for what is supposed to be a low-impact feature. Anyone willing 
to opt-in to them should be updating the ANAME sibling address records 
on their own, not forcing authoritative server implementations to choose 
between taking on that dirty work or being labeled noncompliant.

Second, and relatedly, I think the TTLs of replacement records 
established for non-transfer responses are too high. Respecting the TTL 
of every record in a chain that starts with the ANAME requires the TTL 
of final replacement records to be no higher than the minimum TTL 
encountered over the chain, potentially /reduced/ nondeterministically 
to mitigate query bunching. I would therefore add language encouraging 
resolvers synthesizing those records to engage in best-effort 
determination of original TTLs by (e.g., by directly querying 
authoritative servers and refreshing at 50% remaining), but *requiring* 
them to decrement TTLs of records for which they are not authoritative.

And finally, back on the question of what ANAME sibling address records 
actually represent, I think that NXDOMAIN and NODATA results should be 
treated as errors for the purposes of ANAME sibling replacement. This 
position can be justified on both practical and principled 
grounds—replacing functional records with an empty RRSet is undesirable 
for DNS users (or at least the sample of them that are Oracle+Dyn 
customers), and could inappropriately stretch the maximum specified 
ANAME sibling TTL (on the ANAME record itself) to the SOA MINIMUM value 
(which is doubly bad, because it results in extended caching of the 
/least/ valuable state). And adding insult to injury, resolvers in 
general will not even have the SOA, and will need to perform more 
lookups in order to issue a proper negative response of their own. Let's 
please just eliminate all of that by specifying that ANAME processing 
can never replace something with nothing.

P.S. There is a typographical error in Appendix D; "RRGIG" should be 
"RRSIG".

P.P.S. I think it has been discussed before, but this document should 
also introduce and use a new "Address RTYPE" registry or subregistry, 
rather than forever constraining ANAME exclusively to A and AAAA.

On 11/2/18 17:00, Richard Gibson wrote:
>> Another option to give users is a non-updating fallback A record, 
>> that could point to a web redirect.  That saves all the hassle of 
>> updates.
>
> administrators who choose to perform manual target resolution and 
> update their zones to use them as fallback records (as they would do 
> now to approximate ANAME anyway), rather than an inherent and enduring 
> aspect of the functionality.
>
>> web provider, MX to a mail provider, etc.  That would also be 
>> valuable at non-apex names.  But I am happy to support ANAME as part 
>> of the solution.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 9 Nov 2018 11:03:40 +0100

> between taking on that dirty work or being labeled noncompliant.

It seems that everyone thinks that the latest ANAME draft requires DNS 
UPDATE. This is just a use case that Tony provides and would help him in 
his daily operations. However, it is not required to do so: ANAME 
resolution can also happen by updating the zone file before loading it 
into the primary server. Or it may happen in the authority server if 
people desire to implement it there.

I think the draft should be updated to make that absolutely clear. The 
draft should standardize how ANAME resolution is done, and what it means 
to have ANAME and sibling address records in the zone for address rtype 
(A, AAAA, ...) and ANAME query lookup.

The customer does not care about the address records, other than it may 
want to provide a default address. So in their provisioning dashboard 
they will only add a domain name that represents their CDN or whatever.

The DNS provider will perform ANAME resolution somewhere between where 
the customer provides the ANAME and hands out the addresses to the DNS 
client.

> them to decrement TTLs of records for which they are not authoritative.

I agree, the TTL language in this document is not ready and needs more 
discussion.

+1

Best regards,

Matthijs

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 9 Nov 2018 06:09:18 -0500

On 11/9/18 05:03, Matthijs Mekking wrote:
> UPDATE. This is just a use case that Tony provides and would help him 
> in his daily operations. However, it is not required to do so: ANAME 
> draft should standardize how ANAME resolution is done, and what it 
> means to have ANAME and sibling address records in the zone for 
> address rtype (A, AAAA, ...) and ANAME query lookup.
>

Agreed.

>> established for non-transfer responses are too high. Respecting the 
>> TTL of every record in a chain that starts with the ANAME requires 
>> the TTL of final replacement records to be no higher than the minimum 
>> TTL encountered over the chain, potentially /reduced/ 
>> nondeterministically to mitigate query bunching. I would therefore 
>> add language encouraging resolvers synthesizing those records to 
>> engage in best-effort determination of original TTLs by (e.g., by 
>> directly querying authoritative servers and refreshing at 50% 
>> remaining), but *requiring* them to decrement TTLs of records for 
>> which they are not authoritative.
>

If folks have some suggested text, please should send it along.

>
>> And finally, back on the question of what ANAME sibling address 
>> records actually represent, I think that NXDOMAIN and NODATA results 
>> should be treated as errors for the purposes of ANAME sibling 
>> replacement. This position can be justified on both practical and 
>> principled grounds—replacing functional records with an empty RRSet 
>> is undesirable for DNS users (or at least the sample of them that are 
>> Oracle+Dyn customers), and could inappropriately stretch the maximum 
>> specified ANAME sibling TTL (on the ANAME record itself) to the SOA 
>> MINIMUM value (which is doubly bad, because it results in extended 
>> caching of the /least/ valuable state). And adding insult to injury, 
>> resolvers in general will not even have the SOA, and will need to 
>> perform more lookups in order to issue a proper negative response of 
>> their own. Let's please just eliminate all of that by specifying that 
>> ANAME processing can never replace something with nothing.
>
> +1

"ANAME processing can never replace something with nothing"  should also 
be mentioned in the document.

>> rather than forever constraining ANAME exclusively to A and AAAA.

I think that should be discussed.

thanks Matthijs,

tim

---

From: Tony Finch <[email-masked]>
Date: Fri, 9 Nov 2018 16:39:33 +0000

Richard Gibson <[email-masked]> wrote:
>
> First, I am troubled by the requirement that ANAME forces the zone into a
> dynamic zone.

I don't see how it is possible to implement ANAME without some form of
dymamic behaviour, either by UPDATEs on the primary, or on-demand
substitution on the secondaries, or some combination of the two.

> Second, and relatedly, I think the TTLs of replacement records established for
> non-transfer responses are too high. Respecting the TTL of every record in a
> chain that starts with the ANAME requires the TTL of final replacement records
> to be no higher than the minimum TTL encountered over the chain, potentially
> /reduced/ nondeterministically to mitigate query bunching. I would therefore
> add language encouraging resolvers synthesizing those records to engage in
> best-effort determination of original TTLs by (e.g., by directly querying
> authoritative servers and refreshing at 50% remaining), but *requiring* them
> to decrement TTLs of records for which they are not authoritative.

I'm not sure I understand which TTLs you are worried about here. What are
"non-transfer responses"? There's certainly some rewording needed to make
it more clear, but the TTLs returned by resolvers that do sibling address
record substitution are decremented in the usual way, and resolvers make
no attempt to determine the original TTLs.

It isn't possible to require a resolver to query authoritative servers
directly.

> actually represent, I think that NXDOMAIN and NODATA results should be treated
> as errors for the purposes of ANAME sibling replacement. This position can be
> justified on both practical and principled grounds—replacing functional
> records with an empty RRSet is undesirable for DNS users (or at least the
> sample of them that are Oracle+Dyn customers),

Maybe so, but that's what happens with CNAME records.

> and could inappropriately stretch the maximum specified ANAME sibling
> TTL (on the ANAME record itself) to the SOA MINIMUM value (which is
> doubly bad, because it results in extended caching of the /least/
> valuable state).

That's a very good point, thank you.

> Let's please just eliminate all of that by specifying that ANAME
> processing can never replace something with nothing.

So when the target goes away, you would prefer to leave behind zombie
address records, and stretch their TTL indefinitely? If the zone admin is
given only a target hostname (just like a CNAME) they don't have any
alternative addresses to use when the target goes away. So the options are
to copy the target by deleting the addresses, or ignore the target and
leave the addresses to rot.

I'm inclined to say that fallback records should remain a non-standard
feature. The semantics can be that when you see the target go AWOL, delete
the ANAME and its siblings, and replace them with the fallback records
that were specified by some other means. You can apply the same logic to
CNAMEs too, if you want :-)

> P.S. There is a typographical error in Appendix D; "RRGIG" should be "RRSIG".

Thanks.

> P.P.S. I think it has been discussed before, but this document should also
> introduce and use a new "Address RTYPE" registry or subregistry, rather than
> forever constraining ANAME exclusively to A and AAAA.

The -01 draft specified a registry but I dropped that from -02 because I
was not sure if it should include X25, ISDN, NSAP, ATMA, the ILNP types,
the Nimrod types, etc. And now I realise that it needs a lot more thought
about what will happen to interoperability when the registry changes.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
a fair, free and open society

---

From: Bob Harold <[email-masked]>
Date: Fri, 9 Nov 2018 12:41:17 -0500

> substitution on the secondaries, or some combination of the two.

I think we have different viewpoints here:
- ANAME replaces existing CDN tricks, and the A/AAAA records are always
dynamically generated.  If ANAME leads nowhere, then there is no answer.
Or:
- ANAME is a new feature, which can be used instead the standard A/AAAA
records by the few server where ANAME is implemented.
Updates to the A/AAAA records can be done at the source, the same as any
normal zone update.  No special processing required on the authoritative
servers.  Only the recursive servers use ANAME if they support that new
feature.  If ANAME leads nowhere, then ignore the new broken feature and
return the standard A/AAAA records.  This option could be implementation
dependent.  (This is the view I prefer, at least until ANAME becomes
widespread.)

> established for
> them

I am inclined to use the TTL of the sibling A/AAAA records and avoid the
work and concerns of guessing the right ttl.  That gives the zone owner the
control, rather than the owner of the ANAME target.  (I am typically a zone
owner, so I prefer to have control.  Others may differ.)

> treated

If I view A/AAAA as standard, and ANAME as optional (shiny new feature),
then I prefer the A/AAAA if ANAME fails.  CNAME is standard, which is much
different than ANAME in this viewpoint.

> also

I agree that needs more thought, but I hope ANAME can cover future address
types.

-- 
Bob Harold

---

From: Richard Gibson <[email-masked]>
Date: Fri, 9 Nov 2018 12:54:02 -0500

Responses inline.

> substitution on the secondaries, or some combination of the two.

I am advocating for the special behavior of ANAME be limited to 
processing of non-transfer queries (i.e., explicitly excluding AXFR and 
IXFR). For example: ANAME-aware authoritative servers MAY attempt 
sibling replacement in response to address or ANY queries and SHOULD add 
records to the additional section in response to address or ANAME 
queries; ANAME-aware resolvers SHOULD do both. But all authoritative 
servers should agree that the sibling records—including their original 
TTLs—are a non-special part of zone contents for the purposes of transfers.

> no attempt to determine the original TTLs.
I hope the above clarifies... my TTL concerns relate not to resolvers, 
but to authoritative servers. In particular, I take issue with the 
"/Sibling address records are committed to the zone/" and "/Sibling 
address records are served from authoritative servers with a fixed TTL/" 
text, which stretches the TTL of one or more RRSets along the target 
name's resolution chain.
> Maybe so, but that's what happens with CNAME records.
CNAME does not allow for siblings, and therefore its processing is 
incapable of replacing functional records with an empty RRSet. Further, 
clients are required to understand CNAME and can therefore always 
identify at which domain name an issue lies (and in particular that it 
is not the queried name).
> leave the addresses to rot.
When the target goes away, there is no longer anything to replace the 
sibling records, which are not zombies but rather part of the zone 
contents and always issued by authoritative servers with their original 
TTL (just like every other record, including the ANAME itself). Only if 
there are no sibling records could an authoritative server issue a 
NODATA response, and if a /resolver/ cannot successfully resolve an 
ANAME target to non-expired records, then it should re-resolve the 
requested RRSet anyway—it will get from upstream either refreshed 
fallbacks or a NODATA, and in either case then has a response for its 
own client.
> CNAMEs too, if you want :-)
A system that complicated would /have/ to be non-standard, but I think 
you're reading too much into my use of the term "fallback". It's not a 
specification of special treatment, but rather the absence of such that 
gives ANAME sibling records that status... they're what to serve when 
nothing replaces them (i.e., the current semantics of every record in 
every zone that is not itself occluded by a delegation).

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 20 Nov 2018 16:07:24 +0100

Follow-up.

tldr:
- The first argument is just an issue of wording.
- Authoritative servers or provisioning scripts that do ANAME processing 
should honor the target address records TTL.
- Sibling address records should be used as a default if ANAME 
processing fails.

On 11/9/18 6:54 PM, Richard Gibson wrote:
>> Richard Gibson<[email-masked]>  wrote:

It looks like there is a non-issue: The draft allows you to do ANAME 
resolution however you want:
1. An anamifier script that updates a zone file before loading it into 
the primary.
2. A tool that translates ANAME target lookups into Dynamic Update.
3. An authoritative server that implements ANAME resolution.
4. ...

The point is that we would like to standardize the ANAME resolution, and 
what it means on the wire.

Richard makes a good point though that is: ANAME on zone transfers 
should have no special logic.

>> no attempt to determine the original TTLs.

non-transfer responses are responses for QTYPE != AXFR or IXFR.

> text, which stretches the TTL of one or more RRSets along the target 

Richard and I discussed this. In order for me to understand the issue I 
had to look this from the point of the resolver, that does ANAME resolution.

Suppose a resolver has an ANAME in its cache with a high TTL, say 3600, 
but not the target A and AAAA records. It can do the lookup for the 
targets. If successful, it will retrieve the A and/or AAAA records. 
Let's say they have a short TTL, 60. They time out after a minute, but 
the resolver can still use the ANAME record to do its own ANAME resolution.

In other words, if the resolver does ANAME resolution, the TTL of the 
target address records are honored. Now what does that mean for the 
authoritative side? What TTL should they use for the A and AAAA records 
that have been expanded by ANAME? It would only be logical that the 
authoritative side does the same.

This means that when adding A and AAAA records into the zone as a result 
of ANAME processing, the TTL to use is at most that of the TTL of the 
address target records. If you use a higher value, this will stretch the 
TTL which is undesired.

> every zone that is not itself occluded by a delegation).

Perhaps a better word is "default". If a default is set it is used if 
the ANAME processing resulted in a negative answer. If no default is 
set, a negative answer is used as the final response. This allows for 
both use cases.

I am in favor of specifying that sibling address records are used as a 
default. If you don't want that functionality, then don't add sibling 
address records. If you do want it: you have a way of doing so.

I am hesitant to accept an argument like "CNAME does it this way". We 
are not trying to recreate CNAME logic here.

Best regards,

Matthijs

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 21 Nov 2018 11:58:50 +0000

To hopefully awaken and further inform the discussion around the ANAME 
and HTTP draft specifications that have been put forward, I've done some 
further analysis across the Alexa top 1 million domains - my initial 
findings are available at https://thpts.github.io/a_or_cname/ .

A brief summary of what I have found across the entire dataset:

* 51% of www records return an A record
* 47% of www records return a CNAME
   * 64% of those point www back to apex (i.e. www.example.com. IN CNAME 
example.com.)
* 17 www records are DNAME

Any feedback, corrections, and suggestions would be greatly appreciated.

Regards

On Tue, 6 Nov 2018 at 10:22, Thomas Peterson <[email-masked] 
<mailto:[email-masked]>> wrote:

    That may be the case from your own (presumably anecdotal)
    experience, however I took the Alexa top 1 million websites and
    queried for A* and CNAME against the www records for the top 10 000
    domains. What I found is that approximately 44% returned CNAME
    records, 56% returning A records.

    Code is
    https://gist.github.com/thpts/eb5cec361867170a0ffd6ede136c6649 here
    if anyone wishes to look.

    Regards

    * I realise that I could have added AAAA. My presumption is that the
    top 10k websites are not v6 only and at least have an A record in place.

    *From: *DNSOP <[email-masked]
    <mailto:[email-masked]>> on behalf of Olli Vanhoja
    <[email-masked] <mailto:[email-masked]>>
    *Date: *Tuesday, 6 November 2018 at 08:24
    *To: *<[email-masked] <mailto:[email-masked]>>
    *Subject: *Re: [DNSOP] Fundamental ANAME problems

    they rarely use CNAMEs for www but instead you'll see an A record,
    that might

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 21 Nov 2018 07:25:26 -0500

Thomas

Thanks for the analysis.   It's a good data point.

And the Nameserver usage is useful - from a quick view of the graph if one
adds Cloudflare + GoDaddy is approx 60% of the nameservers.

On Wed, Nov 21, 2018 at 6:59 AM Thomas Peterson <[email-masked]>
wrote:

> To hopefully awaken and further inform the discussion around the ANAME and
> HTTP draft specifications that have been put forward, I've done some
> On Tue, 6 Nov 2018 at 10:22, Thomas Peterson <[email-masked]>
> wrote:
>
>> That may be the case from your own (presumably anecdotal) experience,
>> however I took the Alexa top 1 million websites and queried for A* and
>> CNAME against the www records for the top 10 000 domains. What I found is
>> that approximately 44% returned CNAME records, 56% returning A records.
>>
>>
>>
>> * I realise that I could have added AAAA. My presumption is that the top
>> 10k websites are not v6 only and at least have an A record in place.
>>
>>
>>
>> *From: *DNSOP <[email-masked]> on behalf of Olli Vanhoja <
>> [email-masked]>
>> *To: *<[email-masked]>