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

From: Anthony Eden <[email-masked]>
Date: Wed, 29 Mar 2017 08:51:50 -0500

After attending the dnsop meeting on Monday I decided it was time I
submitted my first ID for review:

https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/

This draft describes the ALIAS/ANAME record (aka CNAME-flattening)
that numerous vendors and DNS providers are now supporting in
proprietary fashions. I hope that this draft will eventually lead to a
good mechanism for interop of ALIAS/ANAME records.

Sincerely,
Anthony Eden

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

---

From: Pieter Lexis <[email-masked]>
Date: Wed, 29 Mar 2017 18:14:25 +0200

Hello Anthony,

On Wed, 29 Mar 2017 08:51:50 -0500

> good mechanism for interop of ALIAS/ANAME records.

First off, thank you for this. I would love to hear from current implementors of ALIAS/ANAME/CNAME-flattening what their ideas/critisisms are.

This said, I have several comments after a first quick read of the document.

There is no mention of the fact that ALIAS is mostly meant for zone apexes where other records MUST be present and a CNAME cannot exist. CNAMEs would cover non-apex usecases for ALIAS.

I miss guidance what should happen when an ALIAS record is queried directly (would it be returned, should it be refused, should it be an empty response?).

I miss words on the interaction between ALIAS records and other (mostly A and AAAA) records on the same node.

Section 3.1

"The server will respond with one or more A records", I fail to see why this cannot be zero or more. Am ALIAS target without A or AAAA records should yield an empty response from the authoritative server.

"If the recursive query returns an NXDOMAIN response, then the authoritative name server MUST return an NXDOMAIN response as well.". If any other records exist (which is always the case for the apex), or if there are labels underneath the ALIAS'es name, the authoritative server cannot send out NXDOMAIN.

Section 3.3

This section has 2 similar paragraphs, one with should and the other with MUST.

Asking directly for a CNAME for a node that only has an ALIAS record should yield a response indicating that RRType does not exist at that node.

Again, thank you for starting this draft. I support adoption of this draft in the dnsop WG to facilitate better interop between ALIAS/ANAME/CNAME-flattening implementors.

Best regards,

Pieter

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Mar 2017 17:54:59 +0100

Pieter Lexis <[email-masked]> wrote:
>
> There is no mention of the fact that ALIAS is mostly meant for zone
> apexes where other records MUST be present and a CNAME cannot exist.
> CNAMEs would cover non-apex usecases for ALIAS.

There are lots of non-apex situations where you can't use a CNAME, e.g.
where mail domains and hostnames coincide. (lists.cam.ac.uk,
trin.cam.ac.uk, etc.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire, South Utsire: Cyclonic, becoming southeasterly for a
time, 4 or 5, increasing 6 or 7, perhaps gale 8 later, then becoming variable
4 later. Moderate or rough. Fair then rain. Good, becoming moderate or poor.

---

From: Anthony Eden <[email-masked]>
Date: Wed, 29 Mar 2017 14:27:46 -0500

> There is no mention of the fact that ALIAS is mostly meant for zone apexes where other records MUST be present and a CNAME cannot exist. CNAMEs would cover non-apex usecases for ALIAS.

As Tony pointed out, there are use cases for non-apex nodes as well.

> I miss guidance what should happen when an ALIAS record is queried directly (would it be returned, should it be refused, should it be an empty response?).

It's a good point. Our implementation doesn't expose the ALIAS itself
as a queryable type, but there is a legitimate argument to allow it.

> I miss words on the interaction between ALIAS records and other (mostly A and AAAA) records on the same node.

+1. In our case we would return both the static records as well as the
materialized records.

> "The server will respond with one or more A records", I fail to see why this cannot be zero or more. Am ALIAS target without A or AAAA records should yield an empty response from the authoritative…

Good point.

> "If the recursive query returns an NXDOMAIN response, then the authoritative name server MUST return an NXDOMAIN response as well.". If any other records exist (which is always the case for the ape…

Also a good point. I actually need to check our implementation to see
how it behaves now in this case.

> This section has 2 similar paragraphs, one with should and the other with MUST.

Yes, I am removing the extra paragraph and going with MUST.

> Asking directly for a CNAME for a node that only has an ALIAS record should yield a response indicating that RRType does not exist at that node.

I agree.

> Again, thank you for starting this draft. I support adoption of this draft in the dnsop WG to facilitate better interop between ALIAS/ANAME/CNAME-flattening implementors.

Thank you for your feedback, I appreciate it.

-Anthony

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

---

From: Bob Harold <[email-masked]>
Date: Thu, 30 Mar 2017 10:22:32 -0400

> good mechanism for interop of ALIAS/ANAME records.
Section 4
If you sign offline, what happens when the A records change?

-- 
Bob Harold

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 30 Mar 2017 10:34:40 -0400

Anthony,

Good writeup

Section 3.4 is in conflict with Refuse-Any draft (in WGLC)
IMHO there is no need to say that there is special processing for ANY
query;  so drop section 3.4

Olafur

On Wed, Mar 29, 2017 at 9:51 AM, Anthony Eden <[email-masked]>
wrote:

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

---

From: Richard Gibson <[email-masked]>
Date: Thu, 30 Mar 2017 11:04:12 -0400

I don't think you can drop section 3.4 completely, but it should be updated
to acknowledge Refuse-Any
<https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04#section-4>.
Only behavior 2 (HINFO synthesization) allows total ignorance of special
ALIAS behavior; every other (including conventional) needs modification to
deal with ANY queries against names at which ALIAS is the only RRSet.

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2017 23:08:06 -0000

>If you sign offline, what happens when the A records change?

You Lose(tm).  For that matter, you lose even when the A records don't
change since the signer only sees the ANAME, not the A or AAAA.

I did an ANAME like feature in my DNS system, entirely on the
provisioning side.  It does offline signing, zones are constructed by
the provisioning software, expanding the anames, then signed, then
given to the master server, NSD in my case.  It remembers which zones
have anames and rechecks them every hour, redoing the zone's expansion
and signing if they've changed.

This lets me do things that regular ANAME can't, in particular
shadowing data from a server that is not authoritative for the zone.
My users often host their web sites at hosting providers that insist
you use their name servers, except that they don't provide usable mail
so I have to do the mail and DNS.  On my server, the aname-like things
can specify what server to query as well as what name, so it
automatically follows the A and AAAA records that the web host
publishes in their DNS.

My objection to ANAME is more or less the same as it is to BULK, even
though ANAME is vastly less complex.  It requires that an
authoritative server include a recursive client and do online signing,
both of which would be rather large additions to the mandatory set of
server features.

I think it'd be fine to reserve ANAME as a pseudo-rrtype so that
people can do the name following magic consistently in their provisioning
software, but I wouldn't want to put it into DNS servers.

R's,
John

---

From: Evan Hunt <[email-masked]>
Date: Thu, 30 Mar 2017 23:13:58 +0000

> both of which would be rather large additions to the mandatory set of

It can outsource resolution to an external recursive resolver. Depending
on the implementation details, signing could also be handed by an external
bump-in-the-wire signer.

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

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

---

From: tjw ietf <[email-masked]>
Date: Thu, 30 Mar 2017 18:52:32 -0500

Thank You to Evan and Peter for working with Anthony on a merged draft.

---

From: Tony Finch <[email-masked]>
Date: Fri, 31 Mar 2017 11:10:56 +0100

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

Does the more ambitious version use the NSEC rdata format so that you can
have different target names for different alias RR types?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
German Bight, Humber, Thames, Dover, Wight: South or southwest 4 or 5,
occasionally 6 at first. Slight or moderate. Showers, mainly later. Good.

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 31 Mar 2017 16:04:01 +0200

> change since the signer only sees the ANAME, not the A or AAAA.

There are PowerDNS ALIAS deployments that signs offline (for some 
stretch of the definition of offline) - every minute. For small zones 
the NOTIFY+XFR overhead is very tolerable, and the public auths do not 
need the private key data.

Obviously, whatever way you sign, you would make sure the signer sees 
the A/AAAA RRsets, otherwise you have nothing.

> automatically follows the A and AAAA records that the web host

You could point your ANAME-aware auth at a specific resolver that has 
stub zones configured for those domains, and then this would work with 
ANAME as well.

> both of which would be rather large additions to the mandatory set of

Recursive clients are easy - your libc/libresolv comes with one. Live 
signing is not mandated if you can tolerate frequent XFRs. And, of 
course, any auth implementer is free to not implement ANAME if he does 
not like the requirements.

> software, but I wouldn't want to put it into DNS servers.

Yet the operational reality is that several big DNS hosters have it 
today, and I am aware of a few private PowerDNS ALIAS deployments as 
well. It’s obvious the need is real, and people today rely on ALIAS 
being transferred in AXFR without in line expansion. Anthony’s draft 
documents existing widespread practice. The upcoming replacement draft 
by Evan, Anthony and me adds some improvements to it, including details 
that may, if resolver operators cooperate, reduce the need for 
online/live signing in the future.

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

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 31 Mar 2017 16:06:13 +0200

Hello Tony,

> have different target names for different alias RR types?

I got this question some time ago when I was working on ALIAS for 
PowerDNS. Back then I said no, as nobody showed me an actual use case 
for it and I did not like the extra complexity. Today I feel the same 
way and the upcoming draft does not have type bitmaps currently.

Kind regards,

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2017 15:33:57 -0000

>need the private key data.

Sure.  That's what I do, too, but I'd call that doing it on the
provisioning side.

>stub zones configured for those domains, and then this would work with 

I don't see the benefit -- that just adds an extra level of kludge
in the middle.  If this is worth doing at (I think it is) why not
just put it into ANAME?

>And, of course, any auth implementer is free to not implement ANAME if he does 

Now we're back to the same issue I raised with BULK.  Everyone now has
to carefully check what features are supported by all of their
secondary servers, as opposed to now where I don't even know or care
what software they use.  Some of us hoped we got over that once DNSSEC
got into the mainstream auth servers.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 31 Mar 2017 10:54:31 -0500

> got into the mainstream auth servers.

This is already happening. I can't slave zones between third party 
vendors if I use any of their specialized features (Such as ALIAS 
records), let alone any Geo Directional features.  We're way past that now.

tim

---

From: Mark Andrews <[email-masked]>
Date: Sat, 01 Apr 2017 03:16:10 +1100

The long term way to fix this is for DNS servers to *always* fill
in the additional section for select RR types (e.g. SRV) including
chasing down missing additional records and setting TC=1 if those
additional records will not fit for recursive queries.  TC=1 is
already required when glue records do not fit.

This lets the applications get the entire chain without having to
come back and ask again.  This service would be requested via a
EDNS option which will appear in the response and its presence in
the response indicates that the client does not have to query for
missing RRsets.  The recursive server is guarenteeing that the
response is complete.

Now if SRV is inappropriate for the application, e.g. because it
doesn't work well with wild cards, then a application specific RR
needs to be defined.

This gets you a single lookup with no followup queries required
once the recursive server supports this.  If the client is still
talking to a legacy server it would still need to do followup queries
for missing records.

Clients would ask for A, AAAA, and SRV in parallel until this is
well supported or we have a flag day after which A and AAAA records
should not be requested.

CNAME does 50% job.  Lets do something that does a 100% job.  Yes
it requires both DNS recursive servers and applications update their
behaviours.

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

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 31 Mar 2017 18:41:23 +0200

> records), let alone any Geo Directional features.  We're way past that 

Tim, thanks, this is the voice of reality. Our hope is that we can 
reduce this pain by one point by standardising ALIAS/ANAME.

Kind regards,

---

From: "John R Levine" <[email-masked]>
Date: 31 Mar 2017 13:01:03 -0500

> talking to a legacy server it would still need to do followup queries

I like this but there's an obvious question: if the recursive server has 
to know about ANAME anyway, have the it do the extra fetches, and all of 
the DNSSEC troubles go away.

Straw man, er, straw being:

name ANAME canonname servername rrtype1 rrtype2 ...

If the authoritative server gets a request for one of the rrtypes, it 
returns the ANAME.  (If it gets a request for a type that isn't in the 
ANAME and there isn't a real RR, it returns the usual NOERROR.)  The cache 
sees the ANAME and looks up the canonname from the server at servername 
(with "." as the servername default to look it up in the usual way.) 
Putting an actual rrtypeI at the same name as the ANAME is naughty, like 
putting it at the same name as a CNAME.

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