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

[Bryan Hughes]

In many cases, DNS Made Easy is seeing ANAME records requiring synthesized
A record updates every 90 seconds or so. Also, it is surprising to me that
our non-apex ANAME record count has surpassed apex ANAME record count by a
significant amount. We have approximately 25% fewer apex ANAME records than
non-apex, however apex ANAME records account for over 75% of ANAME zone
update activity. We currently process around 50,000 distinct ANAME records
and we are seeing an average of 60, max of 925, and min of 0 zone updates
per zone per day with an average of 1.74 synthesized A records per non-apex
ANAME record and 1.41 synthesized A records per apex ANAME record.


On Fri, Apr 7, 2017 at 2:44 AM, Petr Špaček  wrote:

> On 4.4.2017 19:30, Matthew Pounsett wrote:
> > On 4 April 2017 at 13:21, Tony Finch  > > wrote:
> >
> > > I believe that's a faulty assumption.   Here's some data:
> > >
> > > [...] During the month of February, [...] an average of 31 changes
> > per zone. [...]
> >
> > That seems to agree with what I meant, though I probably should have
> > said
> > "per-zone" somewhere :-)
> >
> > That's the average, but there's a not-insignificant number there being
> > updated many times per day.Most of the time, you're right, there are
> > few changes, but one can't assume that any given alias will have a low
> > rate of change.
>
> Numbers, that really helps!
>
> If I consider the numbers above and the fact that IXFR is able to deal
> even dynamically updated zones, I conclude that pushing ANAME logic to
> provisioner side is reasonable approach and that added complexity in
> name server itself is not warranted.
>
> --
> Petr Špaček  @  CZ.NIC
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

On 4.4.2017 19:30, Matthew Pounsett wrote:
> On 4 April 2017 at 13:21, Tony Finch  > wrote:
> 
> > I believe that's a faulty assumption.   Here's some data:
> >
> > [...] During the month of February, [...] an average of 31 changes
> per zone. [...]
> 
> That seems to agree with what I meant, though I probably should have
> said
> "per-zone" somewhere :-)
> 
> That's the average, but there's a not-insignificant number there being
> updated many times per day.Most of the time, you're right, there are
> few changes, but one can't assume that any given alias will have a low
> rate of change.

Numbers, that really helps!

If I consider the numbers above and the fact that IXFR is able to deal
even dynamically updated zones, I conclude that pushing ANAME logic to
provisioner side is reasonable approach and that added complexity in
name server itself is not warranted.

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On 4 April 2017 at 13:21, Tony Finch  wrote:

> > I believe that's a faulty assumption.   Here's some data:
> >
> > [...] During the month of February, [...] an average of 31 changes per
> zone. [...]
>
> That seems to agree with what I meant, though I probably should have said
> "per-zone" somewhere :-)
>
> That's the average, but there's a not-insignificant number there being
updated many times per day.Most of the time, you're right, there are
few changes, but one can't assume that any given alias will have a low rate
of change.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Matthew Pounsett  wrote:
> On 3 April 2017 at 07:55, Tony Finch  wrote:
> >
> > If you expand ALIAS on the master server like this, I would expect that
> > most of the time the target addresses won't change very frequently, so the
> > IXFR rate should be much less than the ALIAS polling frequency.
>
> I believe that's a faulty assumption.   Here's some data:
>
> [...] During the month of February, [...] an average of 31 changes per zone. 
> [...]

That seems to agree with what I meant, though I probably should have said
"per-zone" somewhere :-)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Faeroes, Southeast Iceland: Northwesterly gale 8 to storm 10, backing
southwesterly 5 to 7 later. High or very high becoming very rough,
occasionally rough later. Squally showers, drizzle later. Moderate or poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthew Pounsett]

On 3 April 2017 at 07:55, Tony Finch  wrote:

>
> If you expand ALIAS on the master server like this, I would expect that
> most of the time the target addresses won't change very frequently, so the
> IXFR rate should be much less than the ALIAS polling frequency.
>

I believe that's a faulty assumption.   Here's some data:

One of our registrars has ~3.6 million zones hosted on its name servers.
We have historically allowed end users to put CNAMEs wherever they want in
the UI, but have a CNAME "emulator" in the publishing path replaces the
illegal ones before they're inserted in a zone.

During the month of February, the CNAME emulator initiated 872k changes to
28k zones, with an average of 31 changes per zone.  The minimum/maximum
changes per zone were 1 and 231 respectively.

A change is updating one or more replaced CNAME records in a single action,
so this doesn't count individual CNAMEs updated.  It's also possible actual
changes occurred on authoritative servers more often, since we avoid DoSing
upsteam authoritatives.

Here's the distribution of the  number of zones per number of changes.
I've used a LOG scale, since there's a spike of 10k zones with 42 changes,
which makes a linear graph unreadable.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Mon, 3 Apr 2017, Evan Hunt wrote:


I said what now?  Had I recently had dental surgery?  I don't remember
this.


Sorry about misremembering what you said.


(I do believe an authoritative server should be *able* to operate without
built-in recursive code



But I definitely wouldn't phrase that as "there should not be any code".)


I'll await the new draft :)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Mon, Apr 03, 2017 at 03:48:49PM -0400, Paul Wouters wrote:
> As Evan said, there should not be any code in an authoritative server
> that requires it to do recursive validation.

I said what now?  Had I recently had dental surgery?  I don't remember
this.

If you mean the comment I made on the ANAME thread, I was just saying
that it's possible to implement CNAME flattening without a built-in
resolver; several implementations already do.

(I do believe an authoritative server should be *able* to operate without
built-in recursive code, and enabling such operation is on my list of
things to get around to someday in BIND: if auth servers could be
configured to use external resolvers, then security bugs affecting
only the recursive code wouldn't be any risk to them. But I definitely
wouldn't phrase that as "there should not be any code".)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

Hi Dan,

On 3 Apr 2017, at 21:40, Dan York wrote:

I very much like the idea of this draft, given that I use multiple DNS 
hosting providers who all have their own unique (and proprietary) way 
of doing "CNAME flattening at the apex". I think the reality of 
today's user experience with domain names is that we are increasingly 
dropping the "www" or any other kind of second-level domain. So we 
want to talk about our sites as "example.com" ... 
but as the publisher we want to use CDNs, load balancers and other 
systems that need us to use a CNAME. A standardized way of doing this 
would be helpful.


Thank you for your kind words. As I said in another post indeed, I hope 
this draft (assuming it becomes an RFC) will remove one point of 
suffering for those who use multiple DNS providers.



One comment...

On Mar 30, 2017, at 7:13 PM, Evan Hunt 
> wrote:

>
> (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.)

... I think it would be helpful for the new draft to have a few 
examples of what the RR would look like in a zone file.  (This was the 
one component I found missing from Anthony's ALIAS draft.)


Our current draft-draft does not have that yet but I fully agree. I find 
many published RFCs are lacking in examples and test vectors, and I’ll 
make sure we do better on this.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Mon, 3 Apr 2017, Dan York wrote:


I very much like the idea of this draft, given that I use multiple DNS hosting 
providers who all have their own unique (and proprietary) way of doing
"CNAME flattening at the apex". I think the reality of today's user experience with 
domain names is that we are increasingly dropping the "www" or any
other kind of second-level domain. So we want to talk about our sites as 
"example.com" ... but as the publisher we want to use CDNs, load balancers and
other systems that need us to use a CNAME. A standardized way of doing this 
would be helpful.
One comment... 


I hate it :)

As Evan said, there should not be any code in an authoritative server
that requires it to do recursive validation.


(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.)


Staying tuned :)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dan York]

I very much like the idea of this draft, given that I use multiple DNS hosting 
providers who all have their own unique (and proprietary) way of doing "CNAME 
flattening at the apex". I think the reality of today's user experience with 
domain names is that we are increasingly dropping the "www" or any other kind 
of second-level domain. So we want to talk about our sites as 
"example.com" ... but as the publisher we want to use CDNs, 
load balancers and other systems that need us to use a CNAME. A standardized 
way of doing this would be helpful.

One comment...

On Mar 30, 2017, at 7:13 PM, Evan Hunt > 
wrote:

(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.)

... I think it would be helpful for the new draft to have a few examples of 
what the RR would look like in a zone file.  (This was the one component I 
found missing from Anthony's ALIAS draft.)

Thanks for doing this,
Dan

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
y...@isoc.org   +1-603-439-0024
Jabber: y...@jabber.isoc.org  Skype: danyork   
http://twitter.com/danyork

http://www.internetsociety.org/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article  you write:
>So I think my conclusion is that ALIAS is both unnecessary and unhelpful
>for RRtypes other than A and .

Depends.  If you allow what I described, shadowing records from a
server that thinks it's authoritative from the zone but isn't, it's
definitely useful for MX, possibly for others.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Peter van Dijk  wrote:
> On 31 Mar 2017, at 12:10, Tony Finch wrote:
> >
> > Does the more ambitious version use the NSEC rdata format so that you can
> > 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.

That's probably sensible :-)

The vague idea I had was ALIAS A  for your web hosting provider and
ALIAS MX TXT for your mail hosting provider. But the latter isn't actually
very useful, since MX and SPF records have built-in indirection, and TXT
is also used for other purposes (domain authorization, quite frequently in
my experience), and it doesn't cover DKIM or MUA SRV records. And other
scenarios stub their toes in similar ways, e.g. for SIP there's a mess of
SRV records plus NAPTR, and a NAPTR RRset can cover multiple unrelated
protocols and providers.

So I think my conclusion is that ALIAS is both unnecessary and unhelpful
for RRtypes other than A and .

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North or northeast 4 or 5, increasing 6 at times. Moderate at first
in east, otherwise rough. Fair. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Peter van Dijk  wrote:
>
> 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.

If you expand ALIAS on the master server like this, I would expect that
most of the time the target addresses won't change very frequently, so the
IXFR rate should be much less than the ALIAS polling frequency.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: South or southwest, veering northwest later, 5 or 6. Slight,
occasionally moderate in Humber. Fog patches, rain later. Moderate,
occasionally very poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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.


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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

On 31 Mar 2017, at 17:54, Tim Wicinski wrote:


On 3/31/17 10:33 AM, John Levine wrote:



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.



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, 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,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

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, , and SRV in parallel until this is
well supported or we have a flag day after which A and  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: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

On 3/31/17 10:33 AM, John Levine wrote:



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.



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article <9232f4f4-772f-48aa-80fb-c990662af...@powerdns.com> you write:
>On 31 Mar 2017, at 1:08, John Levine wrote:
>
>>> 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 .
>
>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.

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

>> 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  records that the web host
>> publishes in their DNS.
>
>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.

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 
>not like the requirements.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

Hello Tony,

On 31 Mar 2017, at 12:10, Tony Finch wrote:


Evan Hunt  wrote:

(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.)


Does the more ambitious version use the NSEC rdata format so that you 
can

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,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

On 31 Mar 2017, at 1:08, John Levine wrote:


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 .


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/ RRsets, otherwise you have nothing.



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  records that the web host
publishes in their DNS.


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.



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.


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.



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.


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/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Evan Hunt  wrote:

> (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.)

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[tjw ietf]

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



On Thu, Mar 30, 2017 at 6:13 PM, Evan Hunt  wrote:

> On Thu, Mar 30, 2017 at 11:08:06PM -, John Levine wrote:
> > 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.
>
> 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 -- e...@isc.org
> Internet Systems Consortium, Inc.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Thu, Mar 30, 2017 at 11:08:06PM -, John Levine wrote:
> 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.

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 -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Richard Gibson]

I don't think you can drop section 3.4 completely, but it should be updated
to acknowledge Refuse-Any
.
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.

On Thu, Mar 30, 2017 at 10:34 AM, Ólafur Guðmundsson 
wrote:

> 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 
> wrote:
>
>> 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
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ólafur Guðmundsson]

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 
wrote:

> 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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

On Wed, Mar 29, 2017 at 9:51 AM, Anthony Eden 
wrote:

> 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
>
>
Section 4
If you sign offline, what happens when the A records change?

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Anthony Eden]

On Wed, Mar 29, 2017 at 11:14 AM, Pieter Lexis
 wrote:
> Hello Anthony,
>
> On Wed, 29 Mar 2017 08:51:50 -0500
> Anthony Eden  wrote:
>
>> 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.
>
> 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.

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 
> ) records on the same node.

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

>
> 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  records should 
> yield an empty response from the authoritative server.

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 apex), or if there are labels 
> underneath the ALIAS'es name, the authoritative server cannot send out 
> NXDOMAIN.

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

>
> Section 3.3
>
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Pieter Lexis  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    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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hello Anthony,

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

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

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 
) 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  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] New draft for ALIAS/ANAME type

[Anthony Eden]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop