Subject: Re: [DNSOP] Minimum viable ANAME

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

On 21/09/2018 20:12, Dan York wrote:

> I do think this is a path we need to go.  We need *something* like CNAME 
> at the apex.  Either CNAME itself or something that works in the same 
> way but might have a different name.

I agree, and earlier today (well, yesterday, now) I wrote it up:

A new version of I-D, draft-bellis-dnsop-http-record-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:		draft-bellis-dnsop-http-record
Revision:	00
Title:		A DNS Resource Record for HTTP
Document date:	2018-11-04
Group:		Individual Submission
Pages:		5
URL: 
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-http-record-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bellis-dnsop-http-record/
Htmlized: 
https://tools.ietf.org/html/draft-bellis-dnsop-http-record-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-http-record

Abstract:
    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.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 03 Nov 2018 16:53:07 -0700

Ray Bellis wrote:
>> I do think this is a path we need to go.  We need *something* like
>> CNAME at the apex.  Either CNAME itself or something that works in the
>> same way but might have a different name.
>
> ...

the arguments against SRV in that document are unsupported and wrong.

>    While there have been previous attempts to promote the use of the SRV
>    record instead of CNAME records, there have been concerns raised
>    about the performance impact of the additional DNS lookup an SRV
>    record would typically require.

SRV responses include additional data.

>    To achieve equivalent end-user performance as existing CNAME-based
>    solutions, this document permits recursive resolvers to pre-emptively
>    look up the target of an HTTP Record and return the corresponding
>    records to the client.  While this feature is not mandatory it is
>    hoped that support would over time become near ubiquitous.

i think that makes HTTP as fast in terms of round trips as SRV is.

>    Also, the presence of the Port field in an SRV record is incompatible
>    with the "Same Origin" security policy enforced by web browsers and
>    in practise the load-balancing / fallback capabilities of the SRV
>    record are not widely used either, ...

so use "0" for the port number, and don't include more than one SRV RR.

>    ... and non-DNS based solutions for
>    this are already widely deployed for HTTP traffic.

so just keep using non-DNS solutions.

there's no benefit to accompany the cost of this proposal compared to 
re-use of existing code points which are already broadly implemented.

the HTTP folks are obviously not interested in round trips, anyway:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37345
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
; COOKIE: 5a8f3fa2fa447f4c (echoed)
;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME 
www.microsoft.com-c-3.edgekey.net.

;; Query time: 23 msec
;; SERVER: 2620:0:30::53#53(2620:0:30::53)
;; WHEN: Sat Nov 03 23:52:17 UTC 2018
;; MSG SIZE  rcvd: 105

-- 
P Vixie

---

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 08:05:17 +0700

> the arguments against SRV in that document are unsupported and wrong.

They are something of a straw man, yes.

We did hear unequivocally at the side meeting in Montreal that SRV is 
not acceptable to the HTTP folks, though, for the broad reasons 
mentioned in my draft.

> SRV responses include additional data.

AFAIK, BIND does not currently do this.  That said, MarkA has a patch 
that supports it, so we do know it's possible.

> i think that makes HTTP as fast in terms of round trips as SRV is.

The intent is to make it as fast as CNAME, and faster than SRV currently is.

> so use "0" for the port number, and don't include more than one SRV RR.

If the record supports it, people will want to use it, and complain when 
they can't.

> so just keep using non-DNS solutions.

No argument from me, I've always strongly believed that if 
load-balancing and/or failover are the question then DNS is not the answer.

> re-use of existing code points which are already broadly implemented.

There appear to be political benefits, though.   Code points are cheap 
these days, and the point of this document is to try to introduce 
something where the DNS folk and the HTTP folks can "meet in the middle" 
with a mutually acceptable solution.

> the HTTP folks are obviously not interested in round trips, anyway:

Sometimes the content folk appear less interested in this than the UI folk.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 13:00:05 +0700

> that supports it, so we do know it's possible.

Correction - BIND *does* do this, but only for address records that are 
already in the cache.   If the AAAA for the target is in the cache, but 
the A record isn't, that's all you'll get.

Mark's patch forces BIND to pre-fill the cache with the A and AAAA 
records for the SRV target before replying.

Ray

---

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

> the A record isn't, that's all you'll get.

that's all we need. it's all we do for MX and NS additional data, too.

> records for the SRV target before replying.

that would be a mistake. we are hitting for average here not power -- 
the behaviour to optimize for is whatever's most common. if the SRV is 
used, the AAAA or A RRsets will be fetched, and thus cached. if the SRV 
is only used once, that caching effort will be wasted. if the SRV is 
used many times, then the dominant use case will be that the additional 
data is found in cache because the client caused this to be so.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Nov 2018 10:04:47 +1100

> On 4 Nov 2018, at 7:01 pm, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Ray Bellis wrote:
>> 
>> 
> that would be a mistake. we are hitting for average here not power -- the behaviour to optimize for is whatever's most common. if the SRV is used, the AAAA or A RRsets will be fetched, and thus cached. if the SRV is only used once, that caching effort will be wasted. if the SRV is used many times, then the dominant use case will be that the additional data is found in cache because the client caused this to be so.

The main objection to SRV was the double RTT to the recursive server.  Fetching the address records before returning will speed up the sites that are not talked to regularly and will not slow down the sites that are talked to regularly as the values will already be in cache.

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

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

---

From: Paul Vixie <[email-masked]>
Date: Sun, 04 Nov 2018 19:06:56 -0800

Mark Andrews wrote:
>
>> On 4 Nov 2018, at 7:01 pm, Paul Vixie<[email-masked]>  wrote:
...
>> that would be a mistake. we are hitting for average here not power
>> -- the behaviour to optimize for is whatever's most common. if the
>> SRV is used, the AAAA or A RRsets will be fetched, and thus cached.
>> if the SRV is only used once, that caching effort will be wasted.
>> if the SRV is used many times, then the dominant use case will be
>> that the additional data is found in cache because the client
>> caused this to be so.
>
> The main objection to SRV was the double RTT to the recursive server.
> Fetching the address records before returning will speed up the sites
> that are not talked to regularly and will not slow down the sites
> that are talked to regularly as the values will already be in cache.

i'll try again differently. such a fetch would add logic branches and 
state and network information, to no purpose whatsoever.

if the stub who asked the SRV question does not receive the addresses it 
needs in additional data, it will query for them. that will put those 
addresses in cache, so that on subsequent same-SRV questions, it will be 
present.

if the SRV is never fetched again, then there's no win to be had.

popular SRV answers will be overwhelmingly dominated by the second and 
subsequent responses, which will all include the additional data.

a recursive should only fetch what it needs for its own operations, so 
for example if it knows an NS RR but not the corresponding AAAA or A RR, 
it can fetch those. and for qname minimization it can make the requisite 
diagnostic queries. but it should NOT fetch just because it lacks 
additional data. the stubs should cause those fetches.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Nov 2018 16:27:17 +1100

> On 5 Nov 2018, at 2:06 pm, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Mark Andrews wrote:
>> 

> if the stub who asked the SRV question does not receive the addresses it needs in additional data, it will query for them. that will put those addresses in cache, so that on subsequent same-SRV questions, it will be present.

And that requires 2 RTT’s from the client which, despite being only a few ms normally, has been enough for the HTTP folks to refuses to deploy anything other than CNAME for ~2 decades now.

> if the SRV is never fetched again, then there's no win to be had.

The win is loosing the extra RTT from the stub to the recursive server.

> popular SRV answers will be overwhelmingly dominated by the second and subsequent responses, which will all include the additional data.

> a recursive should only fetch what it needs for its own operations, so for example if it knows an NS RR but not the corresponding AAAA or A RR, it can fetch those. and for qname minimization it can make the requisite diagnostic queries. but it should NOT fetch just because it lacks additional data. the stubs should cause those fetches.

And then we get back to the complaints from the HTTP side saying the SRV takes longer than CNAME, which is valid for the first lookup if you don’t fetch the additional records before returning.

---

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

Mark Andrews wrote:
...
>> if the stub who asked the SRV question does not receive the
>> addresses it needs in additional data, it will query for them. that
>> will put those addresses in cache, so that on subsequent same-SRV
>> questions, it will be present.
>
> And that requires 2 RTT’s from the client which, despite being only a
> few ms normally, has been enough for the HTTP folks to refuses to
> deploy anything other than CNAME for ~2 decades now.

i don't think we've made it clear to them that this only happens once.

> The win is loosing the extra RTT from the stub to the recursive

i know that. but the second RTT stub-rdns only happens once per unique 
SRV or AAAA/A. after they are both cached, they are returned in a single 
RTT.

> And then we get back to the complaints from the HTTP side saying the
> SRV takes longer than CNAME, which is valid for the first lookup if
> you don’t fetch the additional records before returning.

i don't think they are objecting to something that only happens on the 
first time a unique SRV or AAAA/A is needed. someone should explain to 
them that we built this with the expectation that popular data would be 
fast, and unpopular data wouldn't make a difference in the long run.

-- 
P Vixie

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 6 Nov 2018 10:15:42 +0100

As nice and clean the HTTP record draft is, without specifying how to do 
expansion of the record into address records it is not going to solve 
the CNAME-at-the-apex problem that DNS providers have, and we will stick 
with the proprietary solutions (this may solve a different use case though).

Best regards,

Matthijs

On 03-11-18 18:04, Ray Bellis wrote:
> Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-http-record/
> Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-http-record-00
> Htmlized:

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Nov 2018 16:19:36 +0700

> with the proprietary solutions (this may solve a different use case 

They're supposed to be expanded either in the client, or in the 
recursive resolver, as described in the draft.

If we're misunderstanding each other, please let me know!

Ray

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 6 Nov 2018 17:17:51 +0700

In doing some digging through my data, I have instances which I have an
apex of a zone, sub zone, etc that are not HTTP but actually a dynamic
database endpoint.

I also have solid number of instances where the apex is used mainly as an
API endpoint, that serves not HTTP web content.

just data points to fit into our world view.

Tim

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Nov 2018 17:42:55 +0700

On 06/11/2018 17:17, Tim Wicinski wrote:
> I also have solid number of instances where the apex is used mainly as 
> an API endpoint, that serves not HTTP web content.

I think you're expressing a similar concern to those that Wes expressed 
at the mic.

However, if there was also an HTTP endpoint on that domain apex, how 
would you distinguish it from the non-HTTP one?   Clients don't connect 
to "hosts", they connect to "services" on those hosts.

Recalling Mark's message from last night which indirectly referenced RFC 
5507:

> People ... 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.

#1 is what SRV does, but HTTP has issues with that
#2 is what my proposed HTTP record does
#3 is what SPF etc uses - TXT records with a prefix in the RDATA

These methods are not mutually exclusive - a prefixed SRV record can 
co-exist with an SPF TXT record and an HTTP (or other record) all at the 
same point in the DNS.

Turning my proposal into a supposedly "future proof" RR type as was 
suggested yesterday that covers non-HTTP "future services" won't work 
unless it uses a service prefix (#1) or something else in the RDATA 
(subtyping, #3) to identify the service.

Ray

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 6 Nov 2018 11:58:15 +0100

On 06-11-18 10:19, Ray Bellis wrote:
>> As nice and clean the HTTP record draft is, without specifying how to 
>> do expansion of the record into address records it is not going to 
>> solve the CNAME-at-the-apex problem that DNS providers have, and we 
>> will stick with the proprietary solutions (this may solve a different 
>> use case though).
> 

That's the crux: A solution that depends on upgrading the resolvers is 
considered not a (fast enough) deployable solution.

That's why I like ANAME: It allows you to do CNAME-at-the-APEX 
processing without requiring resolvers to be updated, however resolvers 
can implement ANAME to optimize the behavior.

Also the ANAME in its current form does not require (but also does not 
prevent) the resolution to take place inside the name server, it can be 
a simple script that is part of your zone provisioning.

Best regards,
Matthijs

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Nov 2018 18:39:06 +0700

> considered not a (fast enough) deployable solution.

The HTTP record does not depend on resolvers being upgraded.   If the 
browser vendors implement the client side, it's not required.

Once they do fully implement it by serving the A and AAAA records from 
cache, then it'll be fast, too.

> a simple script that is part of your zone provisioning.

I think Tony Finch was suggesting that you could also do that with "HTTP".

Ray

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 6 Nov 2018 13:38:26 +0100

> browser vendors implement the client side, it's not required.

But DNS providers like to solve the CNAME-at-the-apex problem within the 
DNS protocol.

>> processing without requiring resolvers to be updated, however 
>> resolvers can implement ANAME to optimize the behavior.
>>
>> prevent) the resolution to take place inside the name server, it can 
>> be a simple script that is part of your zone provisioning.
> 

Okay, I missed that. If HTTP can do that too, than the approach is very 
similar to ANAME except for the name. Why have both then? Also the name 
HTTP suggests the record is only applicable to the web.

Matthijs

---

From: Mark Andrews <[email-masked]>
Date: Wed, 7 Nov 2018 00:45:05 +1100

> On 6 Nov 2018, at 11:38 pm, Matthijs Mekking <[email-masked]> wrote:
> 
> 
> 
>>> That's the crux: A solution that depends on upgrading the resolvers is considered not a (fast enough) deployable solution.
>> The HTTP record does not depend on resolvers being upgraded.   If the browser vendors implement the client side, it's not required.
> 
> But DNS providers like to solve the CNAME-at-the-apex problem within the DNS protocol.
> 
>> Once they do fully implement it by serving the A and AAAA records from cache, then it'll be fast, too.
>>> That's why I like ANAME: It allows you to do CNAME-at-the-APEX processing without requiring resolvers to be updated, however resolvers can implement ANAME to optimize the behavior.
>>> 
>>> Also the ANAME in its current form does not require (but also does not prevent) the resolution to take place inside the name server, it can be a simple script that is part of your zone provisioning.
> Okay, I missed that. If HTTP can do that too, than the approach is very similar to ANAME except for the name. Why have both then? Also the name HTTP suggests the record is only applicable to the web.

Because being able to have different services on different hosts / providers is a good thing.
Your SIP service is handled on one machine.  You mail on a different machine.  HTTP on a third and ftp on a forth.  I don’t know what new services are going to be dreamed up.  I do know that some of them are not going to wanted to be on the same machine that is serving HTTP, or SMTP, or SUBMISSION or …

HTTP is actually the odd man out here.  Lots of other protocols have taken up SRV or used other mechanisms to be able to direct traffic to particular servers.