Subject: [DNSOP] abandoning ANAME and standardizing CNAME at apex

From: Petr Špaček <[email-masked]>
Date: Tue, 19 Jun 2018 15:18:22 +0200

Hello dnsop,

beware, material in this e-mail might cause your head to explode :-)

This proposal is based on following observations:
- It seems that DNS protocol police lost battle about CNAME at apex,
   is is deployed on the Internet.
- Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
   already have code to cope with the "impossible" case of CNAME at the
   apex and deal with it in ways which do not break stuff on resolver
   side.
- Authoritative servers of vendors named above refuse to serve CNAME at
   apex.
- There are CDNs etc. which allow users to create CNAME at apex
   no matter what the standards and "normal" servers say and do.
(We have found out this because Knot Resolver is missing hacks for CNAME
at apex and users complain that "it works with every other resolver".)

Take a deep breath!

Given that resolver side somehow works already ...
could we standardize this obvious violation of RFC 1035?

It is very clear violation of the standard, but almost everyone found
his way around it using different hacks. These hacks are not going away
because all the CDNs just don't care about standards so we will have
to maintain this code no matter what a great solution we will invent for 
future. I.e. adding ANAME will just increase complexity because CNAME at 
apex will be there for a long time (if not forever).

I personally do not like this but it seems better to think though
corner cases in code we already have in production (i.e. think through 
current hacks for CNAME at apex) instead of inventing new things like 
ANAME (or whatever else).

Opinions? Tomatoes? Can it work? If not, why not?

-- 
Petr Špacek  @  CZ.NIC

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jun 2018 15:20:48 +0100

> could we standardize this obvious violation of RFC 1035?

The feature I would like is CNAME and other data (typically CNAME + MX +
TXT), because I have a lot of deeply hierarchial subdomains in my main
zone. CNAME at apex does not need to be (and I think should not be treated
as) a special case.

As I understand it, in the RFC 883 era, CNAME was allowed to coexist with
other records, but that led to consistency problems. eg, if you have a
CNAME cached for a particular name, and you get a query for MX at the same
name, do you go and ask the CNAME's owner or its target for the MX? And do
you get a different answer to the MX query when you don't have a CNAME
cached?

My guess is that it was hard to fix this at the time because the semantics
of negative cache entries was not well developed (e.g. RFC 1034 section
4.3.4 says it was still a new and experimental feature). For
CNAME-with-siblings to work, a resolver needs to remember whether it
already asked for the other data, for each RR type. 1980s caches couldn't
do this, so CNAMEs were made exclusive instead.

I think the resolver's algorithm for handling CNAMEs can be updated to
allow CNAME-with-siblings and preserve compatibility. There will be some
latency cost for later queries that can no longer immediately follow the
CNAME shortcut. NSEC/NSEC3 records could be used to eliminate this cost.

I'm much less sure about whether it's possible to publish
CNAME-with-siblings in a reliably compatible way. I would feel a lot more
comfortable with an ANAME implementation that copies the sibling records
from the target to the owner when the zone is published or signed.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic, mainly northeasterly in northwest, 5 to 7. Slight or
moderate until later in southeast, otherwise moderate or rough. Thundery
showers, fog patches later. Moderate or good, occasionally very poor later.

---

From: tjw ietf <[email-masked]>
Date: Tue, 19 Jun 2018 10:43:58 -0400

With all of you here. 

As an Operator who gets these requests regularly (just 10 minutes ago!) when you tell users the  world of BIND/PowerDNS/NSD/Knot do not support such a mechanism they say “we’re off to use route 53. okthxbai “

I find it personally appalling we can spend so many cycles injecting dns into http but we can’t be bothered to fix what end users want. 

Tim
Just an infrastructure operations person. 
From my high tech gadget

> On Jun 19, 2018, at 10:20, Tony Finch <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 19 Jun 2018 09:47:09 -0500

> ANAME (or whatever else).
I think ANAME RR is hard to compatible with many old version resolvers.
If there are mutiple ANAME RR at compatible resolvers, authoritatives may
not know that resolvers will choose which A RR for client response.

ANAME can ease apex CNAME configuration, maybe a work round is that
authoritatives directly return A RR to resolvers (but not ANAME RR).

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Joe Abley <[email-masked]>
Date: Tue, 19 Jun 2018 07:59:34 -0700

> zone. CNAME at apex does not need to be (and I think should not be treated

My memory of the specifics about the various ANAME/BNAME/ALIAS/etc
proposals or non-standard features is fuzzy so the following may miss
the point (apologies if so, as usual).

However, it sounds a bit like what is being proposed in this thread
(generally, not in your specific message) is for CNAME to be treated
on authority servers like a wildcard RRTYPE for a particular owner
name. The response behaviour if a CNAME is present at the owner name
matching the QTYPE but there is no corresponding RRTYPE in the zone is
to return a NOERROR/CNAME response instead of a NODATA response.

For recursive servers the change that is required is to keep track of
what QTYPEs triggered particular CNAMEs in the cache so that new-QTYPE
cache misses trigger an upstream query.

All of this needs to be extended along the edns-client-subnet axis.

All of the corner cases relating to existing CNAME behaviour, both
standardised and not, on recursive servers, stub resolvers and
authority servers needs to be specified.

This sounds like a lot of work and likely to cause camel indigestion.

However assuming the initial thesis was correct and there is demand
for this functionality (seems right to me) using a new RRTYPE for this
still sounds easier than changing the semantics of CNAME.

Perhaps the new RRTYPE could include an encoding of explicit types
that do exist to make life easier for resolvers.

Perhaps we could call the RRTYPE "*" instead of ENAME or FNAME to
avoid encouraging future GNAME and HNAME proposals :-)

Joe

---

From: Ray Bellis <[email-masked]>
Date: Tue, 19 Jun 2018 16:24:33 +0100

On 19/06/2018 15:43, tjw ietf wrote:

> I find it personally appalling we can spend so many cycles injecting
> dns into http but we can’t be bothered to fix what end users want.

It's the HTTP folks that are putting most of those cycles into DNS into
HTTP.

It's also their intransigence re: SRV which has caused the CNAME at the
Apex issue.   CNAME was *never* the right answer for doing application
level indirection in HTTP space.

Ray

---

From: Jared Mauch <[email-masked]>
Date: Tue, 19 Jun 2018 11:40:21 -0400

> On Jun 19, 2018, at 11:24 AM, Ray Bellis <[email-masked]> wrote:
> 

Throw some shade at SMTP as well, if I send mail to [email-masked] and that pointed to @nether.net it would end up as @nether.net in the messages :-)

Part of it is just the human nature of how we debug things.  I can speak HTTP because it was easy to type telnet localhost 80.  These days I have to do the same thing but with openssl s_client etc.. 

If these methods to debug weren’t so hard, it would have gone much further to helping.  Developers/users want easy debugging steps and what we give them is things like the ednscomp tool, which is technically awesome but not very user friendly.  Instead of doing a dig on the port test tool, it’s much easier to visit https://cmdns.dev.dns-oarc.net/ instead.  I also may not have dig on my phone.. (ok, well I do).

I think a lot can be learned from how Apple (as an example) made simpler APIs to do connections vs doing  gethostbyname()^wgetaddrinfo().  It makes it easier to build tools if you don’t have to learn how to do all these things.  I really like Unix, the simplicity of many calls in C, but sometimes hiding the internal layers is what’s needed.  This is why https://developer.apple.com/documentation/foundation/nsurlconnection?changes=_2 is a thing.

This is why folks are doing what tjw says, “meh, go to route53 because it does what I expect”.

This doesn’t mean the internals aren’t important, but many application developers and end-users can’t be expected to know/care about how a CNAME at apex differs from an A record w/ redirector.

One thing that SMTP got right was MX records, so it’s easier to say “go over here”.  While I’m sure someone will say that HTTP should have it’s own (eg: SRV) but the barn door is still open, etc..

- jared

---

From: Erik Nygren <[email-masked]>
Date: Tue, 19 Jun 2018 11:58:47 -0400

> level indirection in HTTP space.

SRV has enough limitations that the risk/reward for adding it into the DNS
lookup chain made it hard to swallow for many HTTP/browser folks.

The most recent proposal on this front for an ALTSVC DNS record:

      https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02

adds value well beyond what SRV does and seems much more likely to
get interest/traction from browsers from discussions.

Although it is more annoying for users than just CNAME'ign the apex,
the ALTSVC DNS record would solve the problem for the HTTP case
where there's the most practival issues today.  The ALTSVC DNS record
approach also has minimal camel impact on the DNS side as it
doesn't require special handling by resolvers or authorities.

I think we should seriously consider seeing if we the ALTSVC DNS
record case covers enough of the use-cases of ANAME that we can
abandon ANAME and focus effort there instead?  Having multiple
mechanisms solutions to the same problem means we may not
get critical implementation mass on any of them.

     Erik

---

From: Anthony Eden <[email-masked]>
Date: Tue, 19 Jun 2018 18:06:03 +0200

> authoritatives directly return A RR to resolvers (but not ANAME RR).

This is essentially what those of us who implemented ANAME in authoritative
name servers do right now. The original draft I started about ALIAS records
also spelled out only this solution with some operational guidance on best
practices.

-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jun 2018 17:44:35 +0100

... going wildly off-topic now ...

Jared Mauch <[email-masked]> wrote:
>
> Throw some shade at SMTP as well, if I send mail to
> [email-masked] and that pointed to @nether.net it would end up
> as @nether.net in the messages :-)

Not always - Exim doesn't do that rewrite, for example. CNAME-driven
rewrites were removed in RFC 2822, but some MTAs are still partying like
it's 1988.

> This doesn’t mean the internals aren’t important, but many application
> developers and end-users can’t be expected to know/care about how a
> CNAME at apex differs from an A record w/ redirector.

In my experience, many of them don't really understand the distinction
between web site names and server names, or between CNAME indirection and
HTTP redirection.

> One thing that SMTP got right was MX records, so it’s easier to say “go
> over here”.  While I’m sure someone will say that HTTP should have it’s
> own (eg: SRV) but the barn door is still open, etc..

The key thing that SMTP got right was explicitly mentioning the complete
target address in-band in the protocol: SMTP doesn't assume that the
server implicitly knows what it is called. But this feature (and MXs) was
driven by mail's prolific and baroque gatewaying.

The DNS also got the same thing right. I guess in its case the right
solution was a result of looking at zones as database keys rather than as
service endpoints.

It's sort of weird that this architectural lesson took so long to be
learned by other protocols. I was relatively late to the party: at the
time I got involved in HTTP (1997), name-based virtual hosting was just
about starting to become usable, but we were still rolling out new
IP-based vhosting setups. And of course the same story was repeated for
TLS a decade later.

SRV should have been part of the fix (and it was invented early enough to
be!) but it wasn't a complete fix without support from the application
protocols.

The other thing that SRV tried to do, but didn't quite succeed, was to
liberate us from well-known port numbers. Another way we might have done
mass hosting in the late 1990s, if SRV had been deployed, could have been
port-based virtual hosting. Though that would have had interesting effects
on kernel and web server performance that we avoided with name-based and
IP-based vhosting...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole: South 4 or 5, becoming variable 3. Moderate, occasionally rough in west.
Drizzle, fog patches. Moderate, occasionally very poor.

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2018 15:02:12 -0400

>This sounds like a lot of work and likely to cause camel indigestion.

Agreed but it doesn't seem all that much less work than a well
specified version of ANAME, and it avoids the ANAME ugliness of making
authoritative servers do recursive lookups.

---

From: Joe Abley <[email-masked]>
Date: Tue, 19 Jun 2018 15:05:34 -0400

> On 19 Jun 2018, at 15:02, John Levine <[email-masked]> wrote:
> 

It's the full mesh of CNAME-related behaviours of all the various actors that gives me the fear, mainly.

At least with a new specification you get to try and start with a clean slate and you generally only need one fall-back behaviour for each kind of actor talking to each other kind of actor; by changing CNAME behaviour (yet again) we'd be making an already hairy situation even more hirsute.

Joe

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 19 Jun 2018 15:06:26 -0400

On 19 June 2018 at 15:02, John Levine <[email-masked]> wrote:

> But even after all that work, CNAME + other data is still not quite going
to work, because there's an install base for which the behaviour is
unspecified and ambiguous.  CNAME + other data fails in indeterminate ways
depending on which recursive implementation you happen to query for it.

I'm still of the mind that a protocol specific service type for HTTP is all
we need to fix the problem.  If ANAME seems like too much work, and SRV
isn't quite what the HTTP folks want, then maybe we should have a closer
look at ALTSVC or make up something entirely new that does precisely what
HTTP requires.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 19 Jun 2018 22:33:06 +0200

Oh, what about this?

https://tools.ietf.org/html/draft-sury-dnsext-cname-dname-00

:-)

O.
--
Ondřej Surý
[email-masked]

> On 19 Jun 2018, at 15:18, Petr Špaček <[email-masked]> wrote:
> 
> Hello dnsop,
> 
> to maintain this code no matter what a great solution we will invent for future. I.e. adding ANAME will just increase complexity because CNAME at apex will be there for a long time (if not forever).
> 
> corner cases in code we already have in production (i.e. think through current hacks for CNAME at apex) instead of inventing new things like ANAME (or whatever else).
>

---

From: Ray Bellis <[email-masked]>
Date: Tue, 19 Jun 2018 22:03:09 +0100

On 19/06/2018 17:44, Tony Finch wrote:

> SRV should have been part of the fix (and it was invented early 
> enough to be!) but it wasn't a complete fix without support from the
> application protocols.

AIUI, a large part of the supposed issue with SRV was the inertia of the
installed base of browsers that wouldn't know how to access them.

Ironically the proposed fix seems to require upgrades to the
installed base of one of the most important network infrastructure
services on the planet.

Meanwhile, a very large portion of the installed base of web browsers
gets automatically and silently upgraded every month or so...

Ray

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jun 2018 22:05:46 +0100

> installed base of browsers that wouldn't know how to access them.

The same was true for name-based virtual hosting, at about the same time!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Rockall, Malin: Cyclonic, becoming west 5 or 6, decreasing 3 or 4 for
a time. Rough, occasionally moderate. Rain, fair later. Moderate or poor,
occasionally good later.

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Jun 2018 15:44:46 -0700

> installed base of browsers that wouldn't know how to access them.

I thought the more fundamental problem was the additional latency caused by the second lookup since SRV specified domain names as targets.

But maybe I’m misremembering.

Regads,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 19 Jun 2018 18:56:57 -0400 (EDT)

Neither. There were additional data rules to mostly prevent a second lookup, and even in those days, browsers cached hostname to address mappings.

Browsers didn't adopt because srv didn't solve geo or topology optimization. For a design change of this size, more payback was needed.
-- 
Paul Vixie

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2018 09:00:07 +1000

> On 20 Jun 2018, at 8:44 am, David Conrad <[email-masked]> wrote:
> 

Yes, they keep coming up with theoretical issues which won’t be a issue in practice.  Nameservers put the address records of the server listed in the SRV record in the additional section so no second lookup is required.  If the address isn’t in the cache the nameserver can look it up while the SRV reply is in flight.  I’ve got code that does exactly that.  Took 30 minutes to write.  It’s just a different form of prefetch.  If they really want the additional section populated they can define a EDNS option or flag to say to do that.  At the moment most servers don’t follow CNAMEs when populating the additional section but that can also be done easily.

So one SRV query with all the rest of the data in the additional section.  Perfectly doable. Fallback to 2 queries with older name servers and a CNAME chain for the SRV target. 

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2018 11:03:10 +1000

> On 20 Jun 2018, at 8:56 am, Paul Vixie <[email-masked]> wrote:
> 

Which is ridiculous given that it really is a *very* small change.

GLB should be able to compute "SRV 0 0 80 <target>” and "SRV 0 0 443 <target>" as easily as they compute "CNAME <target>”.  That should be no more than 30 minutes work to add even if you are doing it in assembler. It might even be faster in assembler. It uses all the same mechanisms to figure out the target.

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 19 Jun 2018 22:06:32 -0400

bellis> AIUI, a large part of the supposed issue with SRV was the
bellis> inertia of the installed base of browsers that wouldn't know how
bellis> to access them.

drc> I thought the more fundamental problem was the additional latency
drc> caused by the second lookup since SRV specified domain names as
drc> targets.

You're not mis-remembering this. I hear this from the major browser
folks every time we mention SRV. We may or may not think this isn't
relevent (or that dozens of embedded objects are way slower to load on a
web page) but it doesn't matter. If browser folks believe this and won't
change, we aren't likely to convince them if we haven't by now.

SRV is a technically cleaner solution that will never get deployed...

While I understand cautions about changing CNAME, legacy issues,
etc. I've come more and more to the camp that we lost this argument
years ago and we should just let server software folks allow CNAME at
apex and be done.

This is DNSOP. Operational. The world wants CNAME at apex. Let's give it
to them.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2018 12:35:26 +1000

> On 20 Jun 2018, at 12:06 pm, Paul Ebersman <[email-masked]> wrote:
> 

CNAME at the apex really will be the straw that broke the camel’s back.

To do it we would have to redo DNSSEC.  Rewrite thousands of lines of
code because the browser vendors are too pig headed to even attempt to
move to using SRV.  Really would it cost them anything to perform the
SRV lookups?  It’s not like they can’t do the two lookups in parallel.

One could even take _http._tcp and _https._tcp as a signal to fully
populate the additional section before returning.  That way you get
single query either way.

Mark

---

From: Jan Včelák <[email-masked]>
Date: Wed, 20 Jun 2018 11:40:12 +0200

> level indirection in HTTP space.

SRV also trades CNAME at apex for wildcard names support. There is a
plenty of services that employ wildcards to provide customized site
for each user. For instance, userxyz.popularservice.test can be
resolved via *.popularservice.test but equivalent setup with SRV would
require _https._tcp.*.popularservice.test to work as a wildcard.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 20 Jun 2018 10:41:24 +0100

On 20/06/2018 10:40, Jan Včelák wrote:

> SRV also trades CNAME at apex for wildcard names support.

Yes, that's a fair point, and indeed one of the biggest issues with SRV.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2018 20:31:44 +1000

Well define HTTP which is identical to SRV without the prefix.

None of this is hard to do.   That’s 10 minutes work after IANA allocates the code point. 

-- 
Mark Andrews

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Jun 2018 08:38:50 -0400

tjw ietf wrote:
> With all of you here.
>
> As an Operator who gets these requests regularly (just 10 minutes
> ago!) when you tell users the  world of BIND/PowerDNS/NSD/Knot do not
> support such a mechanism they say “we’re off to use route 53.
> okthxbai “

there is a reason the spec doesn't support this. route53 does not care 
about those reasons; they have a business to run.

-- 
P Vixie

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2018 18:04:24 -0400

>https://tools.ietf.org/html/draft-sury-dnsext-cname-dname-00

I think it would work in the DNS but it wouldn't solve any real
problems.

If you want to make your applications work with parallel or variant
domain names, the work is about 5% getting the names into the DNS, and
95% getting your web and mail and other application servers to do the
right thing when they see the names.  I can imagine some approaches
but they all involve provisioning systems that should be able to spit
out the required DNS zones while they do everything else, no CNAME or
ANAME or DNAME required.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Tue, 19 Jun 2018 17:08:00 -0400

> gets automatically and silently upgraded every month or so...

I think so long as there's a fallback for clients that don't yet have SRV implemented (e.g. publish A/AAAA RRSets at the same owner name as the SRV RRSet, and specify the behaviour by SRV-compliant servers in the event that both are present) this is not a plausible engineering argument.

Processing an SRV might require additional DNS lookups to get name -> SRV -> SRV target -> address, but that's a one-time hit per TTL and I think it's a stretch to paint that as definitely a problem. Modelling is required and worst cases remain to be understood.

If there are definitive problems it would be good to hear what they are. It has always sounded to me like the problem is "this is not how we did things before". Perhaps the cost of change is not actually in the client, but in the provisioning/client education/product packaging across all web and hosting services?

Joe

---

From: Evan Hunt <[email-masked]>
Date: Fri, 22 Jun 2018 18:27:52 +0000

> authoritative servers do recursive lookups.

Minor clarification here: ANAME doesn't require the authoritative server
itself to do recursion; it requires it to have access to a reursive
server.

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 Jun 2018 15:02:35 -0400

On Fri, Jun 22, 2018 at 8:57 AM Joe Abley <[email-masked]> wrote:

> I think so long as there's a fallback for clients that don't yet have SRV
> implemented (e.g. publish A/AAAA RRSets at the same owner name as the SRV
> RRSet, and specify the behaviour by SRV-compliant servers in the event that
> both are present) this is not a plausible engineering argument.
>
> Processing an SRV might require additional DNS lookups to get name -> SRV
> -> SRV target -> address, but that's a one-time hit per TTL and I think
> it's a stretch to paint that as definitely a problem. Modelling is required
> and worst cases remain to be understood.
>

​It certainly is the ​case that a number of browser / large web properties
have stated that an additional DNS lookup is a price that they are not
willing to pay, especially for something not "critical".

I believe that this also would require firing off simultaneous lookups for
SRV along with the A and AAAA (or, even worse, firing off a SRV, waiting
for the "nooerror" error and *then* trying for the A / AAAA) and waiting
for the long tail before you even know of you need to resolve the target.

The DNS lookup from my house (behind Comcast, in NoVa, using 8.8.8.8) for
SRV www.afilias.com was Query time: 125 msec.

That is probably not a fair test - there is no SRV for www.afailias.com and
so it wouldn't be cached, but just querying for A www.afilias.com gives
me ;; Query time: 62 msec. This is from a relatively well connected
residential network, and is noticeably worse in many other places in the
world.

Anyway, adding ~60ms is definitely something that many will say is a
problem, especially because all of this falls into the "before first byte"
bucket, and so the user cannot be distracted with progressive rendering,
etc.

I'd note that things like
https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05 (and
similar) would allow you to bundle the SRV and the target of the SRV so
that you *could* do this in one DNS transaction...

>
> If there are definitive problems it would be good to hear what they are.
> It has always sounded to me like the problem is "this is not how we did
> things before". Perhaps the cost of change is not actually in the client,
> but in the provisioning/client education/product packaging across all web
> and hosting services?
>

​I think that the problem boils down to:
A: a chicken and egg issue and
B: extreme sensitivity to latency, especially "avoidable" latency.

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 23 Jun 2018 00:43:34 +0530

> for the long tail before you even know of you need to resolve the target.

With additional-from-cache (default on), BIND will return address of
target of SRV if it is already in cache. The second RTT will get
amortized. It won't take a lot to make it fetch and return the target
too, if it isn't found in cache.

[muks@jurassic ~]$ dig -t srv _xmpp-server._tcp.conference.banu.com

; <<>> DiG 9.11.3-RedHat-9.11.3-4.fc27 <<>> -t srv _xmpp-server._tcp.conference.banu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42270
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0578a97e07ef62a47b1993205b2d491527ff6b5b4672bea0 (good)
;; QUESTION SECTION:
;_xmpp-server._tcp.conference.banu.com. IN SRV

;; ANSWER SECTION:
_xmpp-server._tcp.conference.banu.com. 3543 IN SRV 0 0 5269 jabber.banu.com.

;; AUTHORITY SECTION:
banu.com.		3003	IN	NS	ns2.akira.org.
banu.com.		3003	IN	NS	ns1.banu.com.

;; ADDITIONAL SECTION:
jabber.banu.com.	3599	IN	A	46.4.129.229
ns2.akira.org.		3004	IN	A	46.4.129.253
ns1.banu.com.		3003	IN	A	46.4.83.135

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 23 00:38:05 IST 2018
;; MSG SIZE  rcvd: 222

[muks@jurassic ~]$ 

		Mukund

---

From: "John R Levine" <[email-masked]>
Date: 22 Jun 2018 15:18:43 -0400

> itself to do recursion; it requires it to have access to a reursive

I suppose, but that seems to me a distinction without a difference. 
Either way we end up importing all of the failure modes of a recursive 
server into an authoritative one.

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 Jun 2018 15:26:46 -0400

> too, if it isn't found in cache.
​Ah, fair nuff.
I had tested this against a local bind instance, but didn't think to
manually trigger the target lookup to get it into the cache.

After doing so, it does indeed stuff it in the additional section.

I'm not sure if my host (OS X) will make use of it, but that's a local
issue...

W

dig -t srv _xmpp-server._tcp.crab.im

; <<>> DiG 9.11.1-P3 <<>> -t srv _xmpp-server._tcp.crab.im
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56937
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 93617acb30a0870d29a435625b2d4c107cbf4333363923bb (good)
;; QUESTION SECTION:
;_xmpp-server._tcp.crab.im.     IN      SRV

;; ANSWER SECTION:
_xmpp-server._tcp.crab.im. 300  IN      SRV     10 0 5269
malganis.fleshless.org.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d54c5241ef721df5f76b0d7e5b2d4c188a89ef7e1293b2c4 (good)
;; QUESTION SECTION:
;_xmpp-server._tcp.crab.im.     IN      SRV

;; ANSWER SECTION:
_xmpp-server._tcp.crab.im. 292  IN      SRV     10 0 5269
malganis.fleshless.org.

;; AUTHORITY SECTION:
crab.im.                259191  IN      NS      ns1lmy.name.com.
crab.im.                259191  IN      NS      ns4htz.name.com.
crab.im.                259191  IN      NS      ns3cgw.name.com.
crab.im.                259191  IN      NS      ns2fkr.name.com.

;; ADDITIONAL SECTION:
ns1lmy.name.com.        292     IN      A       162.88.61.47
ns2fkr.name.com.        292     IN      A       162.88.60.47
ns3cgw.name.com.        292     IN      A       162.88.61.49
ns4htz.name.com.        292     IN      A       162.88.60.49

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 22 15:20:56 EDT 2018
;; MSG SIZE  rcvd: 280

root@ron[0]:/etc/namedb# dig -t srv _xmpp-server._tcp.crab.im @localhost

; <<>> DiG 9.11.1-P3 <<>> -t srv _xmpp-server._tcp.crab.im @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;malganis.fleshless.org.                IN      A

;; ANSWER SECTION:
malganis.fleshless.org. 299     IN      A       176.9.22.146

;; Query time: 110 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jun 22 15:21:51 EDT 2018
;; MSG SIZE  rcvd: 67

root@ron[0]:/etc/namedb# dig -t srv _xmpp-server._tcp.crab.im @localhost

; <<>> DiG 9.11.1-P3 <<>> -t srv _xmpp-server._tcp.crab.im @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47059
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 58159e9daff595240cd3d0d45b2d4c53ea5cc1bb748254a9 (good)
;; QUESTION SECTION:
;_xmpp-server._tcp.crab.im.     IN      SRV

;; ANSWER SECTION:
_xmpp-server._tcp.crab.im. 233  IN      SRV     10 0 5269
malganis.fleshless.org.

;; AUTHORITY SECTION:
crab.im.                259132  IN      NS      ns2fkr.name.com.
crab.im.                259132  IN      NS      ns3cgw.name.com.
crab.im.                259132  IN      NS      ns1lmy.name.com.
crab.im.                259132  IN      NS      ns4htz.name.com.

;; ADDITIONAL SECTION:
malganis.fleshless.org. 295     IN      A       176.9.22.146
ns1lmy.name.com.        233     IN      A       162.88.61.47
ns2fkr.name.com.        233     IN      A       162.88.60.47
ns3cgw.name.com.        233     IN      A       162.88.61.49
ns4htz.name.com.        233     IN      A       162.88.60.49

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 22 15:21:55 EDT 2018
;; MSG SIZE  rcvd: 296​

---

From: Shumon Huque <[email-masked]>
Date: Fri, 22 Jun 2018 15:51:25 -0400

> I'm not sure if my host (OS X) will make use of it, but that's a local
I just tested Google Public DNS, Cloudflare DNS, and OpenDNS.

None of them return address records for the SRV targets in the additional
section of their responses, even after priming their caches by querying the
targets first.

As for BIND, my resolver instances have been using "minimal-responses yes"
for a while, and they behave the same.

So, there might still be latency issue that could be improved ..

Shumon.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Jun 2018 16:00:51 -0400

> server into an authoritative one.

+1. authority servers cannot be coerce-able into doing work, whether 
it's computation, memory allocation, or external transactions like RDNS.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Fri, 22 Jun 2018 21:08:04 +0100

The problem with SRV (and MX) is that you can’t tell what an empty additional section means. (By “you” I mean anything in the resolver chain: app, stub, recursor, etc.)

If the AAAA records are missing, does that mean there aren’t any? Does it mean they were not cached? Does it mean the server chose not to provide them for some other reason?

If you want to find out, you have to make a follow-up query to get a clear answer, so you have spent two round trips instead of one. And hopefully your recursive server omitted the AAAA because it has an ncache entry so you get a quick answer, but that’s unlikely if the auth server didn’t provide AAAA and the resolver didn’t eagerly go chasing (which they don’t) and you are an early adopter of SRV so no one else filled the ncache for you.

This can (in theory) be fixed with DNSSEC, but the additional section processing rules have to be changed so that they require the nonexistence proof when records are missing, and of course stubs and apps have to be changed to understand the NSEC(3) records.

Mail servers generally regard additional sections as too unreliable to be useful, and take the simpler slower approach of making all the queries explicitly. It works for them because they are not especially worried about latency.

Because of all this I can sympathize with browser authors to some extent; on the other hand, if they had adopted SRV before it was too late, we might have done more to fix these problems in the last 22 years. (eg an EDNS option to disambiguate missing additional records, maybe.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: 神明達哉 <[email-masked]>
Date: Fri, 22 Jun 2018 13:49:06 -0700

At Fri, 22 Jun 2018 16:00:51 -0400,

> it's computation, memory allocation, or external transactions like RDNS.

Also +1.  I've always thought there's no point in standardizing
ANAME-kind of thing unless its ultimate goal includes the
resolver-side support.  Of course it would take very long time and may
even turn out to be unsuccessful, but if we give up with the idea from
the beginning by stating 'not required, I wouldn't be able to support
the work.  So to me, this is not minor but quite critical.

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Jun 2018 08:20:12 +1000

We do what we should have done from the very beginning and have a rdata type that combines A and AAAA records.  Master servers automatically generate the type and sign it from the A and AAAA resets.  Address family is determined from the rdata length. 

We have a EDNS option that tells the recursive server to construct this type if not present in the zone or return the A or AAAA records in its place if construction would be detected by DNSSEC.  If this option is set you return the new type in the additional section in preference to A and AAAA records.  This way one is not waiting for all the master servers to be updated. 

We also have a option that says recurse to populate the additional section before returning and set tr if the additional section is too small.  The recursive server would use this option to signal if the additional section is complete or not.

-- 
Mark Andrews

> On 23 Jun 2018, at 06:08, Tony Finch <[email-masked]> wrote:
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Jun 2018 18:32:41 -0400

神明達哉 wrote:
> Paul Vixie<[email-masked]>  wrote:
>...
> resolver-side support.  ...

and to be clear, we already created a system like that: SRV. so if 
that's the only way we can do it, it's already done, and we know how it 
ends.

-- 
P Vixie

---

From: Evan Hunt <[email-masked]>
Date: Sat, 23 Jun 2018 00:40:10 +0000

> server into an authoritative one.

I wasn't disagreeing about it being regrettable, I just wanted to nip in
the bud any repeat of the argument that the auth server would itself have
to be upgraded into a recursive server.

The goal of ANAME is for the processing to be done on the resolver side.
Addresses that are included in the authoritative response alongside
ANAME should be ignored by the resolver and re-queried.  But, for the
benefit of legacy resolvers that don't know what to do with an ANAME, the
auth would need to provide some sort of usable answer, which means it has
to be able to look up addresses for the target name (whether it does that
internally or via resolv.conf). It would be nice if that could be avoided,
but there's no straightforward way.

---

From: "John R Levine" <[email-masked]>
Date: 22 Jun 2018 21:18:25 -0400

> to be upgraded into a recursive server.

Like I said, it's a disctinction without a difference.  I don't care 
whether the authoritative and recursive servers are in one process or talk 
to each other through some sort of IPC.  Either way the authoritative 
server has to deal with all of the ways that recursive queries can fail. 
I have an ANAME like kludge in the provisioning crudware for my 
authoritative server which ignores most of the failures, but that's not 
going to work past toy scale.

> but there's no straightforward way.

Well, yes, that's why ANAME is a mess, and I'd rather see if we can figure 
how to make CNAME coexist so the recursion is all done in the recursive 
code.

Regards,

---

From: Evan Hunt <[email-masked]>
Date: Sat, 23 Jun 2018 01:45:03 +0000

On Fri, Jun 22, 2018 at 09:18:25PM -0400, John R Levine wrote:
> Like I said, it's a disctinction without a difference.

The difference is implememtation complexity, which maybe isn't of concern
to you but has been of concern to some people who argued with me about
ANAME on this basis early on.

You *don't* have to implement a full resolver inside your auth server to
get ANAME to work. That's all I'm trying to make clear.

Your point about having to deal with recursion failures is entirely valid.
It's irreducibly a hack, but I'm still pretty sure a different rrtype than
CNAME will be needed to get anything like this to work reliably.

(And, realistically, it isn't going to be SRV; it's going to have to be
something that browsers get for free just by sending address queries, since
that's all they're willing to do.  A related idea that's occurred to me is
an EDNS option that could be included with a query for example.com/A, which
says "this query originated from a _http._tcp application, so do me a favor
and check for SRV while you're at it, 'k?"  But I'm pretty well convinced
at this point that no browser vendor would ever lift a finger to use that
information no matter how easy we made it for them.  *All* of the
finger-lifting will have to be done in the resolver.)

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 23 Jun 2018 21:04:17 +0000

> > zone. CNAME at apex does not need to be (and I think should not be treated

I concur that allowing some form of redirection alongside other
records is a valuable generalization that seems more natural than
ANAME kludges on the authoritative server.

> to return a NOERROR/CNAME response instead of a NODATA response.

Yes, precisely, a default redirection answer when it would otherwise
have been NODATA.  If the RRtype in question is "XNAME" for some
value of "XNAME", then with:

	example.com. IN SOA ns1.example.com. root.example.com. ...
	example.com. IN NS ns1.example.com.
	example.com. IN MX 0 smtp.example.com.
	example.com. IN NSEC ... SOA NS MX FOONAME NSEC RRSIG
	example.com. IN XNAME www.provider.net.
	;
	example.com. IN RRSIG SOA ...
	example.com. IN RRSIG NS ...
	example.com. IN RRSIG MX ...
	example.com. IN RRSIG FOONAME ...
	example.com. IN RRSIG NSEC ...

You get the SOA/NS/MX/NSEC/XNAME records when asking for one of
those, but otherwise you get the XNAME record along with the NSEC
bitmap proving the non-existence of the requested type.

> cache misses trigger an upstream query.

Yes, but if they have the NSEC bitmap, they can follow the XNAME
without asking again.

> All of this needs to be extended along the edns-client-subnet axis.

I am not convinced that ends-client-subnet should be in scope here.
Should there really be a different list of RRtypes per client
subnet?  Or just variation in the payload of the same set of RRsets.

It would be far simpler to say that NODATA/NXDomain and the type
bitmap should be global across all client subnets.  All you get
per client subnet is payload variation per RRset.

> authority servers needs to be specified.

Yes.

> This sounds like a lot of work and likely to cause camel indigestion.

Yes, but IMHO cleaner than ANAME, and solves a more general problem.

> still sounds easier than changing the semantics of CNAME.

This is where a more detailed pros/cons analysis is needed.  The
main advantage of sticking with (modified) CNAMEs is that they will
already be understood by applications.  It is unclear to me how
XNAME works.

We're trying to meet application needs, and if this can be made to
work by updating CNAME to allow co-existence with other records
(not just at the zone apex, but more generally), then that would
be a much better fit with existing applications.

> that do exist to make life easier for resolvers.

That's already handled by NSEC/NSEC3.

> avoid encouraging future GNAME and HNAME proposals :-)

If it is not CNAME, then the WG will have to bikeshed a name, but
"*" I think invites trouble, various interfaces that expect RRtype
names to look like an alphanumeric identifier would choke on "*".

-- 
	Viktor.

---

From: Joe Abley <[email-masked]>
Date: Sat, 23 Jun 2018 19:43:19 -0700

Hi Victor,

On Jun 23, 2018, at 17:04, Viktor Dukhovni <[email-masked]> wrote:

> [...]
> [...]

I think a pragmatic solution needs to work in unsigned zones.

The demand for this kind of functionality is from the same customers
who are relying upon non-standard response tricks from enterprise DNS
providers as part of wider requirements for things like geo-steering
and site failover.

Many of those enterprise DNS providers don't support those tricks in
signed zones (in part, no doubt, because doing so would be complicated
and there has not been significant demand for it, by which I mean
customers willing to pay more for it).

If an XNAME proposal was to solve real-world problems for these people
it would need to work with or without DNSSEC.

(And I wasn't entirely serious about calling the wildcard RRTYPE * :-)

Joe

---

From: Paul Vixie <[email-masked]>
Date: Sat, 23 Jun 2018 19:45:02 -0700

> I think a pragmatic solution needs to work in unsigned zones.

can someone ask the IAB to rule on whether any new internet technology 
standard should address unsigned DNS zones, or for that matter, IPv4 
networks?

"let's move on."

-- 
P Vixie

---

From: Joe Abley <[email-masked]>
Date: Sat, 23 Jun 2018 20:06:03 -0700

On Jun 23, 2018, at 22:45, Paul Vixie <[email-masked]> wrote:

> can someone ask the IAB to rule on whether any new internet technology standard should address unsigned DNS zones, or for that matter, IPv4 networks?
>
> "let's move on."

I agree with the sentiment, but in practical terms in 2018 I think
this is just a recipe for more DNS extensions without standardisation,
which will not help customers who want diversity in providers or who
want to be able to switch providers easily.

To the example at hand, enterprise DNS providers have already
implemented XNAME-like functionality in unsigned zones and and are
selling it. If they can't easily support a standardised mechanism,
they're going to carry on selling what they have.

These response-time tricks that need response-time signing or
pre-computation of signatures across a full set of possible responses
are used by a lot of high-traffic zones and there's significant money
and competition all around it. I don't think that ecosystem is highly
motivated by the opinions of the IAB, and so the pragmatic result of
such a (perfectly reasonable and architecturally progressive)
statement would be to hamstring the working group, not to make the
deployed system better.

If there was a visible horizon where DNSSEC was in widespread demand
and a zone being unsigned was unusual, I would think differently.

Joe

---

From: Shumon Huque <[email-masked]>
Date: Sat, 23 Jun 2018 23:08:15 -0400

> standard should address unsigned DNS zones, or for that matter, IPv4

I have to agree with Joe here.

I have no problem with the IAB/IETF requiring that new DNS enhancements
need to be compatible with and work with DNSSEC - and I support that
requirement. But if they don't also work with unsigned zones, then they
will face a critical deployment obstacle in today's Internet environment,
where DNSSEC is still largely undeployed. So I think for each new
enhancement proposal, we need to evaluate this obstacle, and determine if
it's worth doing the work.

In particular, for the various type specific alias proposals that are the
topic of this thread, the target audience is extensively deployed sites on
the Internet. And if you survey all the sites that use apex CNAME hacks
today, I suspect that you will find a very small minority of them have
deployed DNSSEC. And so, if the proposed solution requires DNSSEC, it is
not really solving the problem in the field. Maybe it will a decade down
the road (if DNSSEC gets wide update by then, which is by no means
certain), but I assume we want to solve the problem on a somewhat smaller
time frame.

Shumon.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 23 Jun 2018 20:36:10 -0700

Joe Abley wrote:
> On Jun 23, 2018, at 22:45, Paul Vixie<[email-masked]>  wrote:
>
>> Joe Abley wrote:

yes, i know, and i'm strangely OK with that. market chaos will be 
painful, and could drive dnssec adoption, if the only standard way to 
get some cool new thing is if you have an NSEC bitmap to work with.

we should have cut off EDNS-incompatible name service clients and 
servers who could not either implement, or signal nonimplementation 
successfully, after 2004. five years should be enough, but only ever 
will be enough if there's Tough Love somewhere in the equation.

> they're going to carry on selling what they have.

right, which will hurt their addressable market calculations. bring it on!

> and a zone being unsigned was unusual, I would think differently.

"cart, meet horse."

-- 
P Vixie

---

From: Evan Hunt <[email-masked]>
Date: Sun, 24 Jun 2018 04:36:50 +0000

> I think a pragmatic solution needs to work in unsigned zones.

+1, but, an unsigned zone could still return an NSEC-style bitmap.  It
wouldn't be provably correct, but neither is any other unsigned response.

You could actually add the bitmap to the XNAME rdata, instead of returning
an NSEC. The XNAME could then mean "alias to <name> for any rrtype not in
<bitmap>". Or you could turn it around, and have it mean "alias to <name>
for any rrtype that IS in <bitmap>". Then you could have multiple XNAME
records with different bitmaps, and forward different types to different
names.  That's kind of cool, but I suspect the benefits are outweighed by
the camel burden.

In any case, I don't understand how XNAME avoids the "ANAME kludges".
Legacy resolvers won't know what to do with XNAME, so all the same
workarounds on the auth side still must be implemented.  Possibly even more
of them, since XNAME responses might need to include answers for lots
of different rrtypes, while ANAME is explicitly limited to A and AAAA.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 24 Jun 2018 19:42:36 +0000

> I think a pragmatic solution needs to work in unsigned zones.

For unsigned zones a synthetic NSEC record can (and should) be
returned unsigned,

	example.com. IN "XNAME" www.example.net.
	example.com. IN NSEC \0.example.com. SOA NS MX "XNAME"

> (And I wasn't entirely serious about calling the wildcard RRTYPE * :-)

Good, but actually, for "XNAME" to solve real-world problems, what's
needed is XNAME == CNAME.  Anything else faces deployment hurdles,
as applications have to be updated to support the new record.
CNAMEs are already understood, so just generalize them to be a
fallback redirect for RRtypes not explicitly configured.

> wouldn't be provably correct, but neither is any other unsigned response.

Agreed.

> an NSEC.

But that requires a new "XNAME" rrtype, whereas what the users want
is a more flexible CNAME that coëxists with other RRtypes.  And
so in the unsigned case, an NSEC RR can ride along to provide the
information that the CNAME is of the new kind that lives alongside
some other records.

> The XNAME could then mean "alias to <name> for any rrtype not in
> <bitmap>".

I think that's the more appropriate definition.  Anything else
would require considerable new machinery.

> workarounds on the auth side still must be implemented.

By making: XNAME == CNAME.

-- 
	Viktor.

---

From: Evan Hunt <[email-masked]>
Date: Mon, 25 Jun 2018 04:32:30 +0000

On Sun, Jun 24, 2018 at 07:42:36PM +0000, Viktor Dukhovni wrote:
> is a more flexible CNAME that coëxists with other RRtypes.

Ah. I didn't understand that you were proposing to reuse the CNAME
rrtype for this.

I think it would be impossible to make that work sanely with legacy
resolvers.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 25 Jun 2018 08:52:41 +0100

On 22/06/2018 19:27, Evan Hunt wrote:

> Minor clarification here: ANAME doesn't require the authoritative
> server itself to do recursion; it requires it to have access to a
> reursive server.

Even that though requires that the authoritative server be capable of
waiting for an asynchronously retrieved value before it can respond.

For some authoritative servers that might require a substantial redesign.

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Jun 2018 14:59:28 +0100

Paul Vixie <[email-masked]> wrote:
> 神明達哉 wrote:
> >
> > I've always thought there's no point in standardizing ANAME-kind of
> > thing unless its ultimate goal includes the resolver-side support.
> > ...
>

ANAME avoids some of the pitfalls that SRV encountered:

* apps and stubs don't have to be upgraded to support ANAME

* recursive support is an optimization, not a requirement

* no added last-mile latency

And there are existing implementations that demonstrate demand.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
strengthen the democratic process and ensure that
there is a just and representative system of government

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Jun 2018 15:02:53 +0100

> For some authoritative servers that might require a substantial redesign.

That isn't required if the ANAME target records are fetched/updated by an
out-of-band provisioning process. A server will want to do it this way if
its query rate is bigger than the number of ANAME targetss divided by
their TTLs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Forties, Cromarty, Forth, Tyne, Dogger: Variable 3 or 4, occasionally
northeasterly 5 at first in Cromarty and Forth. Slight. Fog patches
developing. Moderate or good, occasionally very poor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 25 Jun 2018 07:25:07 -0700

> its query rate is bigger than the number of ANAME targetss divided by

A challenge with that is that many people now use geographic or latency
based DNS routing based on the resolver IP address or EDNS-client-subnet.
That's one of the reasons why Route53's ALIAS works only for targets that
Route53 is authoritative for.

-- 
Colm

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Jun 2018 15:55:02 +0100

> Route53 is authoritative for.

I think there are two issues here:

If your server has special knowledge of the target then there's nothing
stopping it from taking short cuts to serve tricksy answers more
efficiently.

If you are worried about a third-party auth server handing out ANAME
targets that are suboptimal, then that is what recursive ANAME support
will fix.

At the moment a third-party auth server can't do any cunning tricks with
apex names, so it has to serve a suboptimal static answer; with ANAME, the
tricksy target service gains the option of moving traffic around with TTL
granularity, if not (in the short term before recursive support) more
fine-grained tricks.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides: Southwesterly 5 until later in northwest, otherwise variable 3 or 4.
Rough at first in northwest, otherwise slight or moderate. Mainly fair. Good,
occasionally poor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Jun 2018 11:05:31 -0400 (EDT)

On Mon, 25 Jun 2018, Tony Finch wrote:

> out-of-band provisioning process.

Then you might as well use that mechanism to update A/AAAA records and
skip the intermediate ANAME?

Paul

---

From: Ray Bellis <[email-masked]>
Date: Mon, 25 Jun 2018 16:06:51 +0100

> skip the intermediate ANAME?

+1

Apex records are a provisioning problem, not a protocol one.

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Jun 2018 16:42:40 +0100

> skip the intermediate ANAME?

ANAME will add two things beyond a provisioning-only setup:

* a standard way to signal to dynamic auth servers where to get A/AAAA
  records from

* a way to signal to recursives that they might get a better answer if
  they query the target themselves

Even for a provisioning-only setup, ANAME will give the zone admin a
standard way to configure the provisioning process. That's what I mostly
want it for.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
a just distribution of the rewards of success

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 25 Jun 2018 08:46:05 -0700

> Apex records are a provisioning problem, not a protocol one.

When we implemented ALIAS for Route 53 we looked at a model like that,
where it would be more like an instruction to merely import certain DNS
entries. But we found that didn't quite match CNAME in terms of who pays
for the queries (we charge my the query, which is a common model).

As a Route 53 customer, when you ALIAS to something, you don't pay for
queries to those names, the owner of the hidden target name does.  That's
because the target retains control of the TTL, and we didn't want it that
the target could lower the TTL and increase your bill.

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Jun 2018 08:47:27 -0700

> standard way to configure the provisioning process. That's what I mostly

what do you expect non-dynamic servers to do in the presence of ANAME? i 
assume you'll recommend that they also host real A and AAAA RRsets at 
the same name-node, which only a dynamic authoritative would ignore?

if so, there's a third work flow available, which is to use RFC 2136 
dynamic update to periodically update those "last resort" or "static" A 
and AAAA RRsets, for a non-dynamic server.

and if so, why aren't we just specifying that, and avoiding the creation 
of a new kind of authority server ("dynamic")?

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Jun 2018 17:08:52 +0100

Paul Vixie <[email-masked]> wrote:
> assume you'll recommend that they also host real A and AAAA RRsets at the same
> name-node, which only a dynamic authoritative would ignore?

Yes.

> if so, there's a third work flow available, which is to use RFC 2136 dynamic
> update to periodically update those "last resort" or "static" A and AAAA
> RRsets, for a non-dynamic server.

Yes.

> and if so, why aren't we just specifying that, and avoiding the creation of a
> new kind of authority server ("dynamic")?

A dynamic auth is (from the point of view of the trad DNS model) a kind of
master server: it has the signing keys (which secondaries don't), it
determines the contents of the zone according to its own rules (whereas
secondaries passively receive contents from elsewhere). Services like
Route53 and Dyn are effectively multi-master setups.

Dynamic auth servers exist. I would be pleased if ANAME makes it easier
for zone owners to move between providers with fewer portability problems
due to proprietary DNS extensions. Dunno how plausible that is, but
there's clearly demand, e.g. my favourite example (because they're using
one of my tools): https://www.theguardian.com/info/developer-blog/2016/dec/23/multiple-dns-synchronising-dyn-to-aws-route-53

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire: Northwesterly 5 to 7. Moderate, occasionally rough in south.
Fair. Good.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Jun 2018 12:44:07 -0400 (EDT)

> * a standard way to signal to dynamic auth servers where to get A/AAAA

I understand, I just disagree this is the right way. I don't see why
this entire problem shouldn't be resolved at the well, resolver level.

>  they query the target themselves

This you can do with ANAME records that are provisioned, and the only
modification needed would be to add ANAME to the additional/answer
section on auth servers. That's quite different from adding a protocol
requiring auth nameservers to interpret/fetch/verify/replace zone
records.

Paul

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Jun 2018 17:57:43 +0100

> this entire problem shouldn't be resolved at the well, resolver level.

I don't see how that can be deployed in a way that is compatible with
existing software.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover: Variable becoming mainly northeast, 3 or 4,
occasionally 5 later in Dover. Slight, occasionally moderate later. Fog
patches. Moderate or good, occasionally very poor.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Jun 2018 10:00:33 -0700

Tony Finch wrote:
> Paul Wouters<[email-masked]>  wrote:

there are now a half dozen x.x.x.x (where x is the same in all four 
octets) public anycast resolvers. if they can all be upgraded to handle 
dnssec or ECS, they can all be upgraded to handle something like ANAME.

the "resolver" here is the recursive, not the stub. stubs believe what 
they hear, for good or ill. if we need to change what they hear, it's 
not as impossible as changing what they understand.

-- 
P Vixie

---

From: Michael Sheldon <[email-masked]>
Date: Fri, 29 Jun 2018 09:32:09 -0700

Breaking this out of the ANAME discussion, since it has wider use.

I've been thinking on this one. If I was to create a record, I'd set aside a byte or two at the beginning to denote family, but I'm just paranoid and OCD that way.

But what about just creating a query type HOSTA with behavior like MAILA? Where a query type for HOSTA would return A and/or AAAA records for the requested name. This prevents a long (possibly infinite) time where both A/AAAA and a new type would have to be supported. And if we wanted to create the new record type anyway, that could also be returned with HOSTA.

Willing to bet a lot of implementations already have something similar internally to deal with MX/SRV targets.

--
Michael Sheldon 

On June 22, 2018 3:20:12 PM MST, Mark Andrews <[email-masked]> wrote:
>We do what we should have done from the very beginning and have a rdata
>type that combines A and AAAA records.  Master servers automatically
>generate the type and sign it from the A and AAAA resets.  Address
>family is determined from the rdata length. 
>
>We have a EDNS option that tells the recursive server to construct this
>type if not present in the zone or return the A or AAAA records in its
>place if construction would be detected by DNSSEC.  If this option is
>set you return the new type in the additional section in preference to
>A and AAAA records.  This way one is not waiting for all the master
>servers to be updated. 
>
>We also have a option that says recurse to populate the additional
>section before returning and set tr if the additional section is too
>small.  The recursive server would use this option to signal if the
>additional section is complete or not.
>
>-- 
>Mark Andrews
>
>> The problem with SRV (and MX) is that you can’t tell what an empty
>additional section means. (By “you” I mean anything in the resolver
>chain: app, stub, recursor, etc.)
>> 
>> If the AAAA records are missing, does that mean there aren’t any?
>Does it mean they were not cached? Does it mean the server chose not to
>provide them for some other reason?
>> 
>> If you want to find out, you have to make a follow-up query to get a
>clear answer, so you have spent two round trips instead of one. And
>hopefully your recursive server omitted the AAAA because it has an
>ncache entry so you get a quick answer, but that’s unlikely if the auth
>server didn’t provide AAAA and the resolver didn’t eagerly go chasing
>(which they don’t) and you are an early adopter of SRV so no one else
>filled the ncache for you.
>> 
>> This can (in theory) be fixed with DNSSEC, but the additional section
>processing rules have to be changed so that they require the
>nonexistence proof when records are missing, and of course stubs and
>apps have to be changed to understand the NSEC(3) records.
>> 
>> Mail servers generally regard additional sections as too unreliable
>to be useful, and take the simpler slower approach of making all the
>queries explicitly. It works for them because they are not especially
>worried about latency.
>> 
>> Because of all this I can sympathize with browser authors to some
>extent; on the other hand, if they had adopted SRV before it was too
>late, we might have done more to fix these problems in the last 22
>years. (eg an EDNS option to disambiguate missing additional records,
>maybe.)
>> 
>> Tony.
>> --

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Jun 2018 09:38:32 -0700

Michael Sheldon wrote:
> I've been thinking on this one. If I was to create a record, I'd set
> aside a byte or two at the beginning to denote family, but I'm just
> paranoid and OCD that way.

that seems like the long way around.

for QTYPE=A, add AAAA as a desired additional data type.

for QTYPE=AAAA, add A as a desired additional data type.

advantages:

no fork-lifts. incremental. opportunistic. no protocol changes. start today.

any server which does it will give better time-to-first-ad benchmarks, 
and will therefore outcompete any server who doesn't do it in all bakeoffs.

-- 
P Vixie

---

From: Michael Sheldon <[email-masked]>
Date: Fri, 29 Jun 2018 09:45:58 -0700

I kind of agree it's the long way around. The problem it gets around is recursives not returning Additional, which has been noted as being very common.

But you are correct that returning the "other" address in additional could be done, probably without breaking existing recursives.

--
Michael Sheldon

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Jun 2018 09:47:23 -0700

Michael Sheldon wrote:
> I kind of agree it's the long way around. The problem it gets around
> is recursives not returning Additional, which has been noted as being
> very common.

recursives could (as could authoritatives) do this today if they wanted 
to. if you think they will only do it if there's a document telling them 
to, then by all means write that document. but just describe what they 
can already do, don't define new protocol elements.

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 Jun 2018 13:28:08 -0400

> On Jun 29, 2018, at 12:38, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Michael Sheldon wrote:

And ANAME (just a regular rrtype, no strange preprocessing)
> for QTYPE=AAAA, add A as a desired additional data type.

Same here.

Let the recursive then use the ANAME for refreshing the A/AAAA

And everything has regular dnssec signatures without online signing.

> any server which does it will give better time-to-first-ad benchmarks, and will therefore outcompete any server who doesn't do it in all bakeoffs.

+1

Paul

---

From: Mark Andrews <[email-masked]>
Date: Sat, 30 Jun 2018 11:26:54 +1000

> On 30 Jun 2018, at 2:47 am, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Michael Sheldon wrote:
> recursives could (as could authoritatives) do this today if they wanted to.
> if you think they will only do it if there's a document telling them to,
> then by all means write that document. but just describe what they can
> already do, don't define new protocol elements.

It’s not so much that they don’t return the records.  It’s that they
don’t have the records in the cache to start with so they are not returned.
This is especially true when the content is hosted by a different organisation.

It is possible to fetch all the records before returning if you want to though some
sort of signal from the client that they will use the data would be useful.  I’ve
just been working on code to do just that for BIND for SRV as a proof of concept.
It is also possible to prefetch missing additional records.  Both of these things
are being done in this MR though I might increase the number of prefetch slots used.

https://gitlab.isc.org/isc-projects/bind9/merge_requests/449