Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Paul Wouters]

On Mon, 22 Sep 2014, bert hubert wrote:


Feedback welcome! I note that there has been discussion on EDNS0 probing and
other fancy things, but please note that this feature is needed to solve a
problem we have today. This means it can't involve upgrades to
infrastructure except for that operated by the people with the problem -
authoritative servers.


If we can do this with auth only changes in a sane way, I'm all for it.

But if a decent solution requires recursor updates, we should not leave
that solution space out of scope.

A bandaid for those that need this today is to delegate the A record of the
apex and the www record to the CDN, and MX, NS and SRV records to their
own infrastructure. And to refrain from using the apex A/ for any other
service.

Paul

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[bert hubert]

Based on the discussions here (thanks!), I've now written this up as:

https://github.com/PowerDNS/pdns/blob/alias/pdns/docs/alias.md

The ALIAS record
The ALIAS record leads authoritative servers to synthesize A or  records
in case these are not present. The source of the synthesized A or 
record is specified by the target of the ALIAS record.

etc..

Feedback welcome! I note that there has been discussion on EDNS0 probing and
other fancy things, but please note that this feature is needed to solve a
problem we have today. This means it can't involve upgrades to
infrastructure except for that operated by the people with the problem -
authoritative servers.

Bert

On Sun, Sep 21, 2014 at 01:52:22PM +0200, bert hubert wrote:
> Hi everybody,
> 
> Your input on the initial implementation described below would be most
> appreciated.  I see this as a dns operations issue since it does not
> describe an on-the wire change, except when we do AXFR perhaps.  It is
> mostly a feature.
> 
> However, even features could have interoperability issues, and it would be
> nice if we were aligned.
> 
> The last forwared paragraph below says "Please let us know your thoughts
> based on the semantics outlined above.  Would this work for you?  Do you
> miss anything?  Is there a need for multiple ALIAS statements for load
> balancing?  Are we needlessly incompatible with existing implementations? 
> Is there standardization work we could align against?"
> 
> Thanks!
> 
>   Bert
> 
> - Forwarded message from bert hubert  -
> 
> Date: Sun, 21 Sep 2014 12:54:07 +0200
> From: bert hubert 
> To: pdns-us...@mailman.powerdns.com
> Subject: [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
> 
> Hi everybody,
> 
> Based on strong user interest, we are fast-tracking the implementation of
> ALIAS/ANAME records, to solve the 'CNAME at apex' problem. Because of the
> fast-tracking, we need rapid feedback to see if we got it right (see the end
> of the mail for details).
> 
> In short, you can CNAME 'www.yourdomain.com' to a CDN or somewhere else, but
> you can't CNAME 'yourdomain.com', since that breaks DNS. This blogpost by
> CloudFlare expands on the problem:
> https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root
> 
> Today, we implemented ALIAS support as an experimental PowerDNS feature,
> which allows the following:
> 
> $ORIGIN example.com.
> @   IN  SOA ns1 ahu 2014091619 7200 3600 1209600 3600
> @   IN  NS  ns1
> @   IN  NS  ns2
> www IN  CNAME   xs.powerdns.com.
> ns1 IN  A   1.2.3.4
> ns2 IN  A   4.3.2.1
> @   IN  ALIAS   www.powerdns.com.
> @   IN  MX  25 outpost.ds9a.nl.
> elsewhere   IN  CNAME   @
> 
> The branch can be found on https://github.com/PowerDNS/pdns/tree/alias and
> we should have packages soon. 
> 
> The current semantics for the ALIAS pseudo-record are that they only match
> if no real record did.  So in the case above, an MX query for example.com
> would return "25 outpost.ds9a.nl".  But a query for  would return the
> IPv6 address obtained by following the www.powerdns.com CNAME chain to
> xs.powerdns.com. This also works for all other record types, btw.
> 
> Our implementation uses a defined resolver to look up the actually requested
> record, and adds the data found to the packet built so far. This means that
> querying 'elsewhere.example.com' will include a CNAME to example.com, which
> in turn will lead to processing of the ALIAS record.
> 
> Finally, for TTL, we currently use what the resolver gave us. But perhaps we
> could use the TTL of the ALIAS record instead, or as a maximum? Or minimum?
> 
> Please let us know your thoughts based on the semantics outlined above.
> Would this work for you? Do you miss anything? Is there a need for multiple
> ALIAS statements for load balancing? Are we needlessly incompatible with
> existing implementations? Is there standardization work we could align
> against?
> 
> Your input is highly welcome!
> 
>   Bert
> 
> PS: the above is currently not yet supported for DNSSEC domains!
> 
> -- 
> PowerDNS Website: http://www.powerdns.com/
> Contact us by phone on +31-15-7850372
> 
> ___
> Pdns-users mailing list
> pdns-us...@mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users
> 
> 
> - End forwarded message -
> 
> ___
> 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] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[bert hubert]

On Mon, Sep 22, 2014 at 01:37:03PM -0400, Olafur Gudmundsson wrote:
> I’m getting confused about what the exact semantics of the proposed 
> mechanisms are. 

We're here to figure those out. Thanks for your input Olafur, appreciated!

> 
> Q1: The intent is that  ALIAS/ANAME/etc are a fallback rewrite operation if 
> the name does not have the type asked for?

The intent is to solve the 'CNAME at apex'-problem. The implementation needs
to keep SOA, NS etc alive, but override at least A and . Hence the
fallback, to retain SOA and NS.

> Q2: Is there a good  reason to restrict this to just the apex of a zone? 

No, and it isn't implemented like that right now.

> Q3: Is there a  good reason to restrict the target of A* to be in-zone ? 

No, since the specific use-case is to hand off to a CDN name, which is
unlikely to be in-zone.

> Q4: Is there a  good reason to restrict this to specific types? (Think about 
> DANE cases with names like _443._tcp.@apex) 

I think Tony's input that you might end up with an incompatible SPF
if you fall-through for MX makes a good case to restrict to 'address
records', currently A and .

The open questions are: what to do on an ANY query? You can't proxy on an
ANY query to auth as an ANY query to a resolver since the semantics are
different. ANY queries are fragile enough as is, but to maintain any
semblance of working, an ANY query hitting an ALIAS type should be proxied
on as an A and an  query, and both should be tacked on to the answer.

Bert

> 
> 
> On Sep 22, 2014, at 6:03 AM, Tony Finch  wrote:
> 
> > I can see roughly three ways this might be done, in order of increasing
> > complexity...
> > 
> > (1) Master-only. The master observes an ANAME record at the apex of a zone
> > it loads and uses it to periodically refresh the relevant records in the
> > zone (as if you had a cron job running dig | magic | nsupdate).
> > 
> > Disadvantage: potentially lots of XFR traffic if the TTLs are low.
> 
> Disadvantage: if the target is a CNAME what does the master do? 
> It either need to know ALL possible types that may exist or use NSECx record 
> to determine what exists. 
> Possible disadvantage: Master/master signer needs access to resolver to 
> access out of zone-data. 
> 
> Further disadvantage: if the A* target is out of zone at a CDN then the 
> answers the “master” gets back reflect its 
> location. 
> 
> > 
> > (2) Authority-only: All authority servers recognize ANAME records,
> > PowerDNS style.
> > 
> > Disadvantage: all authority servers need DNSSEC private keys.
> 
> Not an absolute requirement, we could play type code tricks that allow master 
> server to store 
> A* target records as different types but servers know that to check for them 
> if A* exists. 
> Disadvantage: All authority serves supporting A* need to know about type 
> translation and signers need to know to perform actions. 
> 
> > 
> > (3) DNAME-style: Authority servers and resolvers recognize ANAME records.
> > ANAME-aware servers (auth and rec) return the synthesized records for
> > backwards compatibility, without signatures. For DNSSEC purposes the
> > signed ANAME goes in the answer section and the original signed target
> > goes in the additional section.
> > 
> > Disadvantages: forklift upgrade; DNSSEC codepoint rollover.
> > 
> 
> You mean DNSKEY alg code points,? 
> We only have 5 popular algorithms so that is not a big deal?
> 
>   Olafur
> 
> 
> ___
> 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] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Olafur Gudmundsson]

I’m getting confused about what the exact semantics of the proposed mechanisms 
are. 

Q1: The intent is that  ALIAS/ANAME/etc are a fallback rewrite operation if the 
name does not have the type asked for?

Q2: Is there a good  reason to restrict this to just the apex of a zone? 

Q3: Is there a  good reason to restrict the target of A* to be in-zone ? 

Q4: Is there a  good reason to restrict this to specific types? (Think about 
DANE cases with names like _443._tcp.@apex) 


On Sep 22, 2014, at 6:03 AM, Tony Finch  wrote:

> I can see roughly three ways this might be done, in order of increasing
> complexity...
> 
> (1) Master-only. The master observes an ANAME record at the apex of a zone
> it loads and uses it to periodically refresh the relevant records in the
> zone (as if you had a cron job running dig | magic | nsupdate).
> 
> Disadvantage: potentially lots of XFR traffic if the TTLs are low.

Disadvantage: if the target is a CNAME what does the master do? 
It either need to know ALL possible types that may exist or use NSECx record to 
determine what exists. 
Possible disadvantage: Master/master signer needs access to resolver to access 
out of zone-data. 

Further disadvantage: if the A* target is out of zone at a CDN then the answers 
the “master” gets back reflect its 
location. 

> 
> (2) Authority-only: All authority servers recognize ANAME records,
> PowerDNS style.
> 
> Disadvantage: all authority servers need DNSSEC private keys.

Not an absolute requirement, we could play type code tricks that allow master 
server to store 
A* target records as different types but servers know that to check for them if 
A* exists. 
Disadvantage: All authority serves supporting A* need to know about type 
translation and signers need to know to perform actions. 

> 
> (3) DNAME-style: Authority servers and resolvers recognize ANAME records.
> ANAME-aware servers (auth and rec) return the synthesized records for
> backwards compatibility, without signatures. For DNSSEC purposes the
> signed ANAME goes in the answer section and the original signed target
> goes in the additional section.
> 
> Disadvantages: forklift upgrade; DNSSEC codepoint rollover.
> 

You mean DNSKEY alg code points,? 
We only have 5 popular algorithms so that is not a big deal?

Olafur


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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Colm MacCárthaigh]

On Mon, Sep 22, 2014 at 7:06 AM, Tony Finch  wrote:
> The fun bit is that an auth server implementing some kind of proxying
> ANAME is in a position very like Google and OpenDNS. That is, if the
> target of the ANAME is a hostname provided by Akamai or CloudFlare or
> whoever, and if the auth server is going to proxy the answer faithfully,
> then it has to implement client-subnet.

I wonder if the best thing to do would be to define an ANAME/NAME
that can be negotiated by resolvers. If the resolver supports it (it
can let the auth know via EDNS0) then the ANAME/NAME is returned
without resolution. If the resolver doesn't support it, then a
synthetic A/ can be returned.

-- 
Colm

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Tony Finch]

Andrew Sullivan  wrote:
> On Sun, Sep 21, 2014 at 03:52:13PM -0700, Paul Vixie wrote:
>
> > if it caches, does it implement "client subnet"?
>
> It sort of has to, not that it will necessarily be useful.  An
> important use case is CDNs, and since you probably want to do stupid
> DNS tricks based on the source of the query, you better do client
> subnet with it.  (Of course, statistically speaking right now that
> means, "Works for Google and OpenDNS and not really anyone else.")

The fun bit is that an auth server implementing some kind of proxying
ANAME is in a position very like Google and OpenDNS. That is, if the
target of the ANAME is a hostname provided by Akamai or CloudFlare or
whoever, and if the auth server is going to proxy the answer faithfully,
then it has to implement client-subnet.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Dick Franks]

On 22 September 2014 12:27, Tony Finch  wrote:

> Dick Franks  wrote:
> > On 22 September 2014 11:03, Tony Finch  wrote:
> > >
> > > (1) Master-only. The master observes an ANAME record at the apex of a
> zone
> > > it loads and uses it to periodically refresh the relevant records in
> the
> > > zone (as if you had a cron job running dig | magic | nsupdate).
> > >
> > > Disadvantage: potentially lots of XFR traffic if the TTLs are low.
> >
> > Why would TTL be relevant here?
> >
> > Is the master not acting as a "partial slave" for the target RRs?
> > In which case, the timing should depend on the SOA refresh period.
>
> Yes, you could do it that way. But a lot of people want changes to take
> effect quickly.
>
> So whenever TTL times out, master does validated lookup of each ANAME
target, resigns, updates zone, notifies own slaves, services XFRs.

Someone beyond your direct control sets a short TTL (0 or 1) in ANAME
target RRs and your master is in deep, deep [trouble] !!

Thinking about it, (target side) SOA refresh is not much better.



> And I forgot to cover the effects that client-subnet might have ...
>
>  I do not know either


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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Andrew Sullivan]

On Sun, Sep 21, 2014 at 03:52:13PM -0700, Paul Vixie wrote:

> does the ANAME(/ALIAS) server proxy every request, so, no caching? 

Some people have tried to implement it that way.  This is an excellent
way to DoS your server, it turns out (rumour has it that someone
learned that in production; but if you make a fairly simple
performance model you can derive this result on paper).

> if it caches, does it implement "client subnet"? 

It sort of has to, not that it will necessarily be useful.  An
important use case is CDNs, and since you probably want to do stupid
DNS tricks based on the source of the query, you better do client
subnet with it.  (Of course, statistically speaking right now that
means, "Works for Google and OpenDNS and not really anyone else.")

> proxied request times out (or servfails), does the original authority
> request also time out (or servfail?) and i wonder-- if the proxy request
> returns NXDOMAIN, what does the authority answer with?

There are use cases where the "right" answer is to extend the cache
value you had, even though the TTL has expired.  In other cases, you
should just pass on whatever you got, so you're working like a cache.

> what the implementers of this nonstandard feature seem to want is
> cname-and-other-data, by which i mean, a requester-visible alias that
> can live at the apex, and then have its target resolved in the
> requester's context. i'm not sure how best to do it, but i'm not liking
> the implications of always-proxy nor proxy-with-cache.

Yes.  For what it's worth, at Dyn we've come up with four different
designs for this functionality, every one of which has some compromise
that has caused my product people to say, "No, not like that."  I am
increasingly convinced that this feature is one of those well-known
ponies.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Tony Finch]

Dick Franks  wrote:
> On 22 September 2014 11:03, Tony Finch  wrote:
> >
> > (1) Master-only. The master observes an ANAME record at the apex of a zone
> > it loads and uses it to periodically refresh the relevant records in the
> > zone (as if you had a cron job running dig | magic | nsupdate).
> >
> > Disadvantage: potentially lots of XFR traffic if the TTLs are low.
>
> Why would TTL be relevant here?
>
> Is the master not acting as a "partial slave" for the target RRs?
> In which case, the timing should depend on the SOA refresh period.

Yes, you could do it that way. But a lot of people want changes to take
effect quickly.

And I forgot to cover the effects that client-subnet might have ...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Dick Franks]

On 22 September 2014 11:03, Tony Finch  wrote:

> I can see roughly three ways this might be done, in order of increasing
> complexity...
>
> (1) Master-only. The master observes an ANAME record at the apex of a zone
> it loads and uses it to periodically refresh the relevant records in the
> zone (as if you had a cron job running dig | magic | nsupdate).
>
> Disadvantage: potentially lots of XFR traffic if the TTLs are low.
>
> Why would TTL be relevant here?

Is the master not acting as a "partial slave" for the target RRs?
In which case, the timing should depend on the SOA refresh period.

No reason to do XFR.  Each (assuming these to be plural) ANAME target could
be resolved independently.


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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[John Levine]

>(1) Master-only. The master observes an ANAME record at the apex of a zone
>it loads and uses it to periodically refresh the relevant records in the
>zone (as if you had a cron job running dig | magic | nsupdate).

I have implemented something like this, with master file syntax

foo IN A [rmtip:bar.remote]

The implementation fetches any A and  records from bar.remote and
invents local A and  records.  It rechecks every hour or so.

>Disadvantage: potentially lots of XFR traffic if the TTLs are low.

My crock manages the zone serial numbers and only changes the serial
number and does a notify if the zone changes.  It's all done in python
scripts on top of NSD.  It doesn't do DNSSEC yet but I don't see any
problems since the zones that NSD sees are ordinary zones.

I agree that Paul's suggestion to limit this to references within the
zone would make it useless in practice unless it also resolved CNAMEs,
which turns it back into the more complicated case.

R's,
John



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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Tony Finch]

Doug Barton  wrote:
>
> https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit

I am confused by the use "label" in that document. Do you really mean a
single component of a domain name wherever you say "label"?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Tony Finch]

I can see roughly three ways this might be done, in order of increasing
complexity...

(1) Master-only. The master observes an ANAME record at the apex of a zone
it loads and uses it to periodically refresh the relevant records in the
zone (as if you had a cron job running dig | magic | nsupdate).

Disadvantage: potentially lots of XFR traffic if the TTLs are low.

(2) Authority-only: All authority servers recognize ANAME records,
PowerDNS style.

Disadvantage: all authority servers need DNSSEC private keys.

(3) DNAME-style: Authority servers and resolvers recognize ANAME records.
ANAME-aware servers (auth and rec) return the synthesized records for
backwards compatibility, without signatures. For DNSSEC purposes the
signed ANAME goes in the answer section and the original signed target
goes in the additional section.

Disadvantages: forklift upgrade; DNSSEC codepoint rollover.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Tony Finch]

bert hubert  wrote:
>
> The current semantics for the ALIAS pseudo-record are that they only match
> if no real record did.

Why not restrict it to A and ?

I forsee problems with zones that have MX and ALIAS at the apex which
accidentally get the wrong SPF record, for example.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Suzanne Woolf]

On Sep 21, 2014, at 5:10 PM, David Conrad  wrote:

> On Sep 21, 2014, at 2:04 PM, Doug Barton  wrote:
>> On 9/21/14 1:14 PM, Suzanne Woolf wrote:
>>> This topic has come up here many times before,
> 
> And like the joke about the weather...
> 
>>> and there always seems to
>>> be interest. A fielded implementation
> 
> There are at least three implementations of ‘alias mechanism for zone apex’ 
> I’m aware of (DNS Made Easy’s ANAME, PowerDNS’s ANAME (same thing?), and 
> CloudFlare’s “CNAME Flattening”). Not sure if they interoperable (or even if 
> there is a need for interoperability).

I'm personally fine with a discussion here of whether an interoperable standard 
is worth the effort, likely to be adopted, etc. 

Previous versions of this discussion have included use cases where 
interoperability is part of the value of an alias feature-- for example, if I'm 
a domain owner who wants both to determine the behavior of an "alias" in terms 
of what a client sees and to have flexibility across managed-DNS providers, I 
want a standard to hold my vendors to.

> 
>>> and Paul's suggestion of an
>>> interoperable spec both seem like healthy developments.
>> 
>> As always I stand ready to revive 
>> https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if 
>> there is interest.
> 
> Given the end of the DNSEXT working group, perhaps there is sufficient 
> interest to have a BOF (Bar, Beach, or otherwise) in Honolulu?

As a first cut, the general topic is IMO on charter for the WG, if people 
seriously want to work on this.

I like David's idea of an informal BOF. I'm not sure of logistical constraints 
for the venue in Honolulu but I'm happy to work on pulling something together. 

Descriptions of the workings of the known "alias" features currently in the 
world would be helpful inputs, along with any specific use cases or problem 
statements people have in mind. The goal would be to get a preliminary idea of 
whether there's useful work to be done on the subject within the IETF process, 
beyond periodic bull sessions on the list, and if so, what's the most effective 
way to proceed.


best,
Suzanne

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Paul Vixie]

> Colm MacCárthaigh 
> Sunday, September 21, 2014 3:33 PM
>
>
> i'd be very interested in a standards-track (interoperable;
> including DNSSEC support and AXFR/IXFR) version of this feature.
> my hope is that you will remove out-of-zone capability here, that
> is, the target of ALIAS should have to be authority data in the
> same zone.
>
>
> But then the feature is pointless; you could just include the record
> directly at the apex if you knew what the value should be.
you make a good point. i'm curious about the implication.

does the ANAME(/ALIAS) server proxy every request, so, no caching? or,
if it caches, does it implement "client subnet"? and, either way: if the
proxied request times out (or servfails), does the original authority
request also time out (or servfail?) and i wonder-- if the proxy request
returns NXDOMAIN, what does the authority answer with?

what the implementers of this nonstandard feature seem to want is
cname-and-other-data, by which i mean, a requester-visible alias that
can live at the apex, and then have its target resolved in the
requester's context. i'm not sure how best to do it, but i'm not liking
the implications of always-proxy nor proxy-with-cache.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Colm MacCárthaigh]

On Sun, Sep 21, 2014 at 11:37 AM, Paul Vixie  wrote:

> i'd be very interested in a standards-track (interoperable; including
> DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you
> will remove out-of-zone capability here, that is, the target of ALIAS
> should have to be authority data in the same zone.
>

But then the feature is pointless; you could just include the record
directly at the apex if you knew what the value should be.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[David Conrad]

Paul,

On Sep 21, 2014, at 2:23 PM, Paul Vixie  wrote:
>> (or even if there is a need for interoperability)
> i don't think it makes sense to question, inside the IETF, whether a 
> vendor-independent interoperable standard is desirable.

Who said anything about desirability?

The reason for my parenthetical was that in at least one implementation, the 
existence of the ‘alias mechanism for zone apex’ is never externally visible, 
so the question of whether or not that implementation is interoperable would be 
moot.

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Paul Vixie]

> David Conrad 
> Sunday, September 21, 2014 2:10 PM
> ...
>
> There are at least three implementations of 'alias mechanism for zone apex' 
> I'm aware of (DNS Made Easy's ANAME, PowerDNS's ANAME (same thing?), and 
> CloudFlare's "CNAME Flattening"). Not sure if they interoperable (or even if 
> there is a need for interoperability).

from the point of view of many operators and implementers (so, like dns
made easy, powerdns, and cloudflare from your example above) there is
almost certainly a disadvantage to interoperability and standardization
here, that being economic, in that as long as this feature remains
incompatible, a single vendor is likely to gain business via "lock in".
my reason for preferring a standardized way to do this is to make it
possible for a registrant to get primary name service from one vendor
and secondary name service from one or more others vendors.

i don't think it makes sense to question, inside the IETF, whether a
vendor-independent interoperable standard is desirable. we can ask
questions of the form "but is this good engineering?" or "is this the
best way to do it?" or even "what should the applicability statement
be?" but since the IETF's stated purpose is to promote interoperable
standards, if we want to argue about whether we need an interoperable
standard for this widely-used feature, we should move that thread to a
non-IETF forum where it would not be a nonsequitur.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[David Conrad]

On Sep 21, 2014, at 2:04 PM, Doug Barton  wrote:
> On 9/21/14 1:14 PM, Suzanne Woolf wrote:
>> This topic has come up here many times before,

And like the joke about the weather...

>> and there always seems to
>> be interest. A fielded implementation

There are at least three implementations of ‘alias mechanism for zone apex’ I’m 
aware of (DNS Made Easy’s ANAME, PowerDNS’s ANAME (same thing?), and 
CloudFlare’s “CNAME Flattening”). Not sure if they interoperable (or even if 
there is a need for interoperability).

>> and Paul's suggestion of an
>> interoperable spec both seem like healthy developments.
> 
> As always I stand ready to revive 
> https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if there 
> is interest.

Given the end of the DNSEXT working group, perhaps there is sufficient interest 
to have a BOF (Bar, Beach, or otherwise) in Honolulu?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/21/14 2:04 PM, Doug Barton wrote:
| On 9/21/14 1:14 PM, Suzanne Woolf wrote:
|> Hi,
|>
|> This topic has come up here many times before, and there always
|> seems to be interest. A fielded implementation and Paul's
|> suggestion of an interoperable spec both seem like healthy
|> developments.
|
| As always I stand ready to revive
| https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit
| if there is interest.

I should add that I'll be at the DNS-OARC and ICANN meetings here in
LA in October if anyone wants to discuss the issue.

Doug

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUHz28AAoJEFzGhvEaGryEe4UH/1jcKEiGJY2mbTdC6AM+nJ0H
H/ZrPk4LqDilCTMS5Qn7o6HJ4TzJWqbFhaUdBo/TYlxQ67cna+Imcf4A9qzDEmG6
r5Ux58J9BLoC6PkeOKPVJDG7iqR+bUuLwoCpPmry4y2nL5yV7Q1J8uzpQoByoIHX
IoHdTHeQ6TPIUfxkQPNf99FNSumqzlz76xjMXuwZsqMrf1ktbFkgpUDE1ZLWVk1l
k6rkdY0q5W/CeCY3hUyWqlX49/su8J4Zeu4OoTlwcstzJirwLFv6GfO1ofzHx8HM
1bTZpSYXO/FV0CWde53G5aDL78IfsFsKwxXPA8s+Ham4KEOK7FrCXdJ/ytyWkv4=
=ROL9
-END PGP SIGNATURE-

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Doug Barton]

On 9/21/14 1:14 PM, Suzanne Woolf wrote:

Hi,

This topic has come up here many times before, and there always seems to
be interest. A fielded implementation and Paul's suggestion of an
interoperable spec both seem like healthy developments.


As always I stand ready to revive 
https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if 
there is interest.


Doug

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Suzanne Woolf]

Hi,

This topic has come up here many times before, and there always seems to be 
interest. A fielded implementation and Paul's suggestion of an interoperable 
spec both seem like healthy developments.


Suzanne

On Sep 21, 2014, at 2:37 PM, Paul Vixie  wrote:

> 
> 
>>  bert hubert Sunday, September 21, 2014 4:52 AM
>> ...
>> 
>> PS: the above is currently not yet supported for DNSSEC domains!
>> 
> i'd be very interested in a standards-track (interoperable; including DNSSEC 
> support and AXFR/IXFR) version of this feature. my hope is that you will 
> remove out-of-zone capability here, that is, the target of ALIAS should have 
> to be authority data in the same zone. this would simplify the DNSSEC case, 
> but more importantly, it would avoid having authority servers make upstream 
> queries.
> 
> if you decide to work on this, i'll contribute as at least a reviewer and 
> perhaps (if invited) as an editor.
> 
> -- 
> Paul Vixie
> ___
> 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] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Dick Franks]

On 21 September 2014 19:14, bert hubert  wrote:

> On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote:
>
> > > PS: the above is currently not yet supported for DNSSEC domains!
> >
> > Can you say (much) more about that aside? Does it mean that the server
>
>
> An interesting opening is that we'd be signing potentially unsigned data
> this way. Potentially, we should check for the AD bit. But first let's see
> how this idea fits.
>
> Must validate the response. Otherwise bad actor can just toss in a bogus
AD bit!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Paul Vixie]

> bert hubert 
> Sunday, September 21, 2014 4:52 AM
> ...
>
> PS: the above is currently not yet supported for DNSSEC domains!
>
i'd be very interested in a standards-track (interoperable; including
DNSSEC support and AXFR/IXFR) version of this feature. my hope is that
you will remove out-of-zone capability here, that is, the target of
ALIAS should have to be authority data in the same zone. this would
simplify the DNSSEC case, but more importantly, it would avoid having
authority servers make upstream queries.

if you decide to work on this, i'll contribute as at least a reviewer
and perhaps (if invited) as an editor.

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[bert hubert]

On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote:
> - What happens / should happen if the "@  IN MX 25 outpost.ds9a.nl." record 
> is not in the zone file and the server gets an MX query for example.com?

It proxies that on as an MX query for www.powerdns.com and puts back the
answer. So ALIAS is type transparent.

> > PS: the above is currently not yet supported for DNSSEC domains!
> 
> Can you say (much) more about that aside? Does it mean that the server
> will fail to load the zone if there is DNSSEC records and ALIAS
> pseudo-records?  Or that the DNSSEC gets broken?  Or that the ALIAS gets
> broken?  Or...  ?

In the current branch, it will load the zone, but neglect to add signatures
for the proxied records. In other words, if you do DNSSEC, it will load the
zone but make you BOGUS. 

This is not a fundamental problem as long as we have keys. If you don't have
the keys, we can't sign any how. We'll add the signing code shortly, we just
haven't typed it in yet.

An interesting opening is that we'd be signing potentially unsigned data
this way. Potentially, we should check for the AD bit. But first let's see
how this idea fits.

Bert

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

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[Paul Hoffman]

Two questions (although other folks are likely to have more questions).

> $ORIGIN example.com.
> @   IN  SOA ns1 ahu 2014091619 7200 3600 1209600 3600
> @   IN  NS  ns1
> @   IN  NS  ns2
> www IN  CNAME   xs.powerdns.com.
> ns1 IN  A   1.2.3.4
> ns2 IN  A   4.3.2.1
> @   IN  ALIAS   www.powerdns.com.
> @   IN  MX  25 outpost.ds9a.nl.
> elsewhere   IN  CNAME   @
> 
> The branch can be found on https://github.com/PowerDNS/pdns/tree/alias and
> we should have packages soon. 
> 
> The current semantics for the ALIAS pseudo-record are that they only match
> if no real record did.  So in the case above, an MX query for example.com
> would return "25 outpost.ds9a.nl".  But a query for  would return the
> IPv6 address obtained by following the www.powerdns.com CNAME chain to
> xs.powerdns.com. This also works for all other record types, btw.

- What happens / should happen if the "@  IN MX 25 outpost.ds9a.nl." record is 
not in the zone file and the server gets an MX query for example.com?

> PS: the above is currently not yet supported for DNSSEC domains!

Can you say (much) more about that aside? Does it mean that the server will 
fail to load the zone if there is DNSSEC records and ALIAS pseudo-records? Or 
that the DNSSEC gets broken? Or that the ALIAS gets broken? Or... ?

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

[DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

[bert hubert]

Hi everybody,

Your input on the initial implementation described below would be most
appreciated.  I see this as a dns operations issue since it does not
describe an on-the wire change, except when we do AXFR perhaps.  It is
mostly a feature.

However, even features could have interoperability issues, and it would be
nice if we were aligned.

The last forwared paragraph below says "Please let us know your thoughts
based on the semantics outlined above.  Would this work for you?  Do you
miss anything?  Is there a need for multiple ALIAS statements for load
balancing?  Are we needlessly incompatible with existing implementations? 
Is there standardization work we could align against?"

Thanks!

Bert

- Forwarded message from bert hubert  -

Date: Sun, 21 Sep 2014 12:54:07 +0200
From: bert hubert 
To: pdns-us...@mailman.powerdns.com
Subject: [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

Hi everybody,

Based on strong user interest, we are fast-tracking the implementation of
ALIAS/ANAME records, to solve the 'CNAME at apex' problem. Because of the
fast-tracking, we need rapid feedback to see if we got it right (see the end
of the mail for details).

In short, you can CNAME 'www.yourdomain.com' to a CDN or somewhere else, but
you can't CNAME 'yourdomain.com', since that breaks DNS. This blogpost by
CloudFlare expands on the problem:
https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root

Today, we implemented ALIAS support as an experimental PowerDNS feature,
which allows the following:

$ORIGIN example.com.
@   IN  SOA ns1 ahu 2014091619 7200 3600 1209600 3600
@   IN  NS  ns1
@   IN  NS  ns2
www IN  CNAME   xs.powerdns.com.
ns1 IN  A   1.2.3.4
ns2 IN  A   4.3.2.1
@   IN  ALIAS   www.powerdns.com.
@   IN  MX  25 outpost.ds9a.nl.
elsewhere   IN  CNAME   @

The branch can be found on https://github.com/PowerDNS/pdns/tree/alias and
we should have packages soon. 

The current semantics for the ALIAS pseudo-record are that they only match
if no real record did.  So in the case above, an MX query for example.com
would return "25 outpost.ds9a.nl".  But a query for  would return the
IPv6 address obtained by following the www.powerdns.com CNAME chain to
xs.powerdns.com. This also works for all other record types, btw.

Our implementation uses a defined resolver to look up the actually requested
record, and adds the data found to the packet built so far. This means that
querying 'elsewhere.example.com' will include a CNAME to example.com, which
in turn will lead to processing of the ALIAS record.

Finally, for TTL, we currently use what the resolver gave us. But perhaps we
could use the TTL of the ALIAS record instead, or as a maximum? Or minimum?

Please let us know your thoughts based on the semantics outlined above.
Would this work for you? Do you miss anything? Is there a need for multiple
ALIAS statements for load balancing? Are we needlessly incompatible with
existing implementations? Is there standardization work we could align
against?

Your input is highly welcome!

Bert

PS: the above is currently not yet supported for DNSSEC domains!

-- 
PowerDNS Website: http://www.powerdns.com/
Contact us by phone on +31-15-7850372

___
Pdns-users mailing list
pdns-us...@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


- End forwarded message -

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