Subject: [DNSOP] Any website publishers who use CDNs on the list?

From: Dan York <[email-masked]>
Date: Fri, 2 Nov 2018 10:57:33 +0000

DNSOP subscribers,

Are there any other publishers of websites on this list who use CDNs in front of their sites - and who are interested in the whole “CNAME at apex” issue?

Given the ANAME discussions and other continuing “CNAME at apex” discussions, I started putting together a short draft clearly stating the problem statement of why we who publish websites want something like CNAME at apex (and why we aren’t happy being locked into proprietary solutions).

The issue has been stated multiple times in different email threads (including by Paul Vixie just yesterday) … but I thought it would be useful / helpful to formally write it down in a draft during these discussions.

Since I’m just one publisher of sites, I’d appreciate anyone else who might want to give a sanity check to what I’m writing (and/or potentially sign on as a co-author).

I’m about to head to the airport to begin 29 hours of travel to Bangkok, so I probably won’t see any responses until I get on the ground there Sunday morning.

See (some of) you in Bangkok,
Dan

P.S. The “short draft” I mentioned currently exists only on my laptop, so it’s not something you can see anywhere yet.

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

http://www.internetsociety.org/

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 2 Nov 2018 13:11:08 +0100

> Are there any other publishers of websites on this list who use CDNs in front of their sites - and who are interested in the whole “CNAME at apex” issue?

I am employed by an organisation who does this. 

I strongly oppose any work being done to slacken the restrictions around
CNAMES.  At least in order to bodge together a fix for the "CDN problem".

I would much much rather see RFC 7553 URI support.  

A little quote from the applicability statement in 7553: 

   In general, it is expected that URI records will be used by clients
   for applications where the relevant protocol to be used is known,
   but, for example, an extra abstraction is needed in order to separate
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   a domain name from a point of service (as addressed by the URI).  One
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   example of such a situation is when an organization has many domain
   names but only one official web page.

		(my underlining)

But, I am certain that the fine disillusion^W^Wrealists in the hosting
world will tell me that some DNS-frontend software does not support
anything but CNAME, so CNAME it is.  And we'll do the entire shouting
game that we had around SRV/TXT once again.

Typ^W^WApex-squatting for fun and profit. 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Used staples are good with SOY SAUCE!

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 2 Nov 2018 22:16:25 +0100

> CNAMES.  At least in order to bodge together a fix for the "CDN problem".

And, now that I've read the backlog, I'd like to apologize for not having
done that before, and also point out that I still, more so than before
actually, count ANAME as a prime example of a bodge fix to the "CNAME
on apex" issue.

I have also read the draft. It made me realise that there is more Heath
Robinson[0] than I ever could imagine in ANAME. Jumping in and out of
secure, signing on the fly, sometimes, et c. It bears all the telltales
of a reactive development.

It is not that I don't realise there is a need to do /something/. CNAMES
don't work for most scenarios. 

At the risk of sounding like a repetitive bore, what is actually needed
is a way to say "for that domain name, apex or not, https[1] services are
over there ---->". Without messing up the entire node in the tree and
causing special processing in every name server and full service
resolver. And without stomping the other interesting protocols that
might like a RR on the node to be found.

The entire effect that ANAME is supposed to have is achieved easier 
by publishing URI records. And by getting web browsers to ask for URI
first. As a bonus, load balancers that send 302's (which by the way are
much faster than DNS resolution, or so I'm told) can listen on 1000s of
ports, because we do not have to point to 443 and listen on 80 as backup
when we can specify the port and the protocol in the URI RR payload.

DNSSEC compatibility? The node we're pointing to can be in another zone
or in the same zone. Signed or not. Either way, we have predictable
behaviour. 

If we need dynamic data along the way, we can push that work where
it belongs, by putting the service names (domain name part in the URI
we point to) in a special zone, perhaps run by the CDN. And the CDN can
run a dynamic signed zone on every anycast master if they so wish. Without
making much more of a mess than today.

All this in RR's that exist today and can be deployed tomorrow. 

"Warum einfach, wenn es auch kompliziert geht?" 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
I'm having a RELIGIOUS EXPERIENCE ... and I don't take any DRUGS

[0] "Rube Goldberg" to those from USA. 
[1] Or whatever, but we've bred a generation of devloprs (sic) who are 
    unable to network without HTTP.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 2 Nov 2018 21:41:14 +0000

On Fri, Nov 02, 2018 at 10:16:25PM +0100, Måns Nilsson wrote:
> first.

Speaking as a co-author of ANAME, I agree about this. URI, SRV, a proposed
new HTTP RRtype, whatever - service lookup is absolutely the correct way to
accomplish this goal.

However, browser vendors are *not doing that*, and I've given up hope that
they ever will. Trying to out-stubborn them has been ineffective.

So vendors muck around in DNS software to solve what ought to be a
non-problem, ending up with mutually-incompatible, protocol-violating
bodges - apex CNAME, ALIAS, etc.  ANAME is an effort to unify these
various approaches into a standards-compliant, portable bodge.

Elegant it isn't, but if we don't standardize ANAME, the existing bodges
will persist.  Browser vendors want the DNS to give them addresses, and
only addresses.

If you can get them to change their minds, though, I wish you all success.

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

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 3 Nov 2018 06:06:37 +0700

> On Nov 2, 2018, at 17:57, Dan York <[email-masked]> wrote:
> 

$employer hosts apex domains on an anycast service. Like all of the work-arounds it is a bodge, albeit one that is not explicitly incompatible with existing DNS practice.

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 5 Nov 2018 12:10:46 +0100

> they ever will. Trying to out-stubborn them has been ineffective.

Yes, but I can understand that they're not too inclined - I believe it's
not easy to portably get information about such RRTYPEs from the OS
resolver, e.g. I can't see a way in POSIX.  Most http libraries would
need to deal with this somehow.  It doesn't seem realistic to *wait* for
OS implementations or even APIs to improve.  Overall it seems quite a
stalemate, I'm afraid, probably without an "ideal" solution within
reasonable timeframe.

--Vladimir

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 7 Nov 2018 10:00:43 -0500

> stalemate, I'm afraid, probably without an "ideal" solution within

Can you point to a major browser that does *not* implement its own resolver
already?

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 7 Nov 2018 10:47:34 -0500

On 2018-11-05 06:10 -0500, Vladimír Čunát wrote:
> resolver, e.g. I can't see a way in POSIX.

It seems there is a clear movement from many browsers to use DOH now for 
DNS matters.

At which point they are able to get all DNS data in its full glory 
without any kind of OS or underlying libraries limitations, and hence 
could use SRV records like any other clients are doing for other protocols.
-- 
Patrick Mevzek

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 7 Nov 2018 18:19:50 +0100

On 11/7/18 4:00 PM, Matthew Pounsett wrote:
> Can you point to a major browser that does *not* implement its own
> resolver already?

I believe Firefox on Linux uses libc call (in my basically default
setup).  When I enable logging, I get:
> [...] D/nsHostResolver DNS lookup thread - Calling getaddrinfo for
host [...]
I haven't dug too deep, perhaps they use
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/PR_GetAddrInfoByName

Please, correct me if I'm wrong.

Of course, DoH has an advantage in this respect, but I don't expect most
of dnsop wants to push browsers that way...

--Vladimir

---

From: Tony Finch <[email-masked]>
Date: Wed, 7 Nov 2018 17:48:44 +0000

Vladimír Čunát <[email-masked]> wrote:
> setup).

There's a problem on Unix that there isn't a way to get the recursive
server IP addresses from the libc resolver. In the IPv4 era it was often
possible to dig around in the _res struct in a moderately portable way, if
the libc resolver was derived from BIND, but that was thoroughly broken by
the divergence in IPv6 support.

And even if you can get the recursive server addresses, you should still
go through the name service switch to deal with names that aren't in the
DNS.

The custom DNS stub resolvers that I know about (adns, ldns, libevent)
reimplement the libc resolver, with their own parsers for /etc/resolv.conf
and all the rest.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: South or southwest 5 to 7, increasing gale 8 at times. Very rough,
becoming high. Rain or thundery showers. Moderate or poor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 07 Nov 2018 10:07:04 -0800

Tony Finch wrote:
> ...

agreed.

> reimplement the libc resolver, with their own parsers for /etc/resolv.conf

dns requests should almost universally go out via the open source 
"getdns" API (https://getdnsapi.net/) at this point. if your code uses 
one of the above methods, or getXbyY() in any form, please investigate.

-- 
P Vixie

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 8 Nov 2018 03:31:31 +0700

Mr Paul is correct - getdns is the best path for developers.

On Thu, Nov 8, 2018 at 1:07 AM Paul Vixie <[email-masked]> wrote:

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Nov 2018 09:33:47 +1100

> On 8 Nov 2018, at 5:07 am, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Tony Finch wrote:
>> ...
>> 

For A and AAAA, but not for HTTP, SRV and all the rest as there are no alternative data sources for those values.

> dns requests should almost universally go out via the open source "getdns" API (https://getdnsapi.net/) at this point. if your code uses one of the above methods, or getXbyY() in any form, please investigate.

It really doesn’t matter which API you decide to use to lookup HTTP or SRV.  They all get the same data.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]