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

[Mukund Sivaraman]

On Wed, Sep 19, 2018 at 09:48:18AM +0200, Petr Špaček wrote:
> 
> 
> On 19/09/2018 09:31, Mukund Sivaraman wrote:
> > On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote:
> >> On 18/09/2018 22:02, JW wrote:
> >>>
> >>>  Original message 
> >>> From: Mark Andrews 
> >>>
>  I would also expect a relatively large client population using SRV 
>  records
>  given the rate Firefox and Chrome browsers are upgraded.  SRV lookups
>  work for lots ofother protocols.  SRV records also make it through
>  firewalls and IDS today.
> 
> >>>
> >>> Hi Mark,
> >>>
> >>> I agree SRV is the obvious choice for a greenfield protocol but there is
> >>> HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten
> >>> scripts, lonely IOT devices, and troubleshooting guides are going to be
> >>> as easy to solve as updating chrome and firefox.
> >>>
> >>> Whatever the solution, I feel it should be as transparent to the client
> >>> as possible.  CNAME would fit this bill but the negative impact is
> >>> largely unknown.
> >>
> >> TL;DR: Experiments with CNAME @ apex showed that it is not going to work
> >> if the domain has e.g. MX records for e-mail.
> >>
> >> Ondrej Sury describes his experimental results in presentation here:
> >> https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf
> > 
> > Aren't these results with current state of implementations? A cached
> > CNAME is expected to be matched against future type queries when
> > following RFC 1034/1035 behavior.
> > 
> > A change in behavior where resolvers expect that CNAME (as a fallback
> > type) will co-exist with other types will work properly.
> 
> Well, I started this thread because I naively thought that we can get
> away with *current* behavior which kind of works because of various
> non-standard workarounds. Experiment above proved me wrong so this seems
> like dead-end to me - it will have similar upgrade problem as any other
> new mechanism.

That's fair, but it would have lower implementation complexity which is
my concern. I much prefer SRV (that Mark's been pushing for several
years now) that is simpler and elegant.

A relaxed fallback-CNAME resolver implementation would not break the
DNS, so IMO that proposal should still be carried through so some X
years later most deployed resolvers will be capable of handling it.

Mukund

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

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

[Petr Špaček]

On 19/09/2018 09:31, Mukund Sivaraman wrote:
> On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote:
>> On 18/09/2018 22:02, JW wrote:
>>>
>>>  Original message 
>>> From: Mark Andrews 
>>>
 I would also expect a relatively large client population using SRV records
 given the rate Firefox and Chrome browsers are upgraded.  SRV lookups
 work for lots ofother protocols.  SRV records also make it through
 firewalls and IDS today.

>>>
>>> Hi Mark,
>>>
>>> I agree SRV is the obvious choice for a greenfield protocol but there is
>>> HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten
>>> scripts, lonely IOT devices, and troubleshooting guides are going to be
>>> as easy to solve as updating chrome and firefox.
>>>
>>> Whatever the solution, I feel it should be as transparent to the client
>>> as possible.  CNAME would fit this bill but the negative impact is
>>> largely unknown.
>>
>> TL;DR: Experiments with CNAME @ apex showed that it is not going to work
>> if the domain has e.g. MX records for e-mail.
>>
>> Ondrej Sury describes his experimental results in presentation here:
>> https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf
> 
> Aren't these results with current state of implementations? A cached
> CNAME is expected to be matched against future type queries when
> following RFC 1034/1035 behavior.
> 
> A change in behavior where resolvers expect that CNAME (as a fallback
> type) will co-exist with other types will work properly.

Well, I started this thread because I naively thought that we can get
away with *current* behavior which kind of works because of various
non-standard workarounds. Experiment above proved me wrong so this seems
like dead-end to me - it will have similar upgrade problem as any other
new mechanism.

-- 
Petr Špaček  @  CZ.NIC

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

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

[Mark Andrews]

> On 19 Sep 2018, at 5:26 pm, Stephane Bortzmeyer  wrote:
> 
> On Wed, Sep 19, 2018 at 07:24:25AM +1000,
> Mark Andrews  wrote 
> a message of 38 lines which said:
> 
>> As for scripts, you upgrade the tools those scripts use:
>> curl(libcurl), wget, fetch for SH. File::Fetch for perl.  Similar
>> for the other scripting languages. Very few applications actually
>> make socket calls directly for http.
> 
> I hope it is true but I'm not so sure. Any hard data somewhere? My
> purely anecdotal evidence is that I've seen "applications actually
> make socket calls directly for http", one reason probably being it is
> widely teached in schools.

And the number of such applications that connect to names that are served by
CDN and are also at zone apexes such that CNAME doesn’t work is ~0%.  Such
applications need to be upgraded.

I’m sure CDN’s could give Agent string counts for sites where they are
doing DNS hacks for apex names so we could see actual data.  It will be in
their logs.  I’m sure there are employees of such companies reading this.

> HTTP/2 is a good thing here since it is much harder to do it yourself,
> so people will rely on libraries :-)

-- 
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] abandoning ANAME and standardizing CNAME at apex

[Mukund Sivaraman]

On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote:
> On 18/09/2018 22:02, JW wrote:
> > 
> >  Original message 
> > From: Mark Andrews 
> > 
> >> I would also expect a relatively large client population using SRV records
> >> given the rate Firefox and Chrome browsers are upgraded.  SRV lookups
> >> work for lots ofother protocols.  SRV records also make it through
> >> firewalls and IDS today.
> >>
> > 
> > Hi Mark,
> > 
> > I agree SRV is the obvious choice for a greenfield protocol but there is
> > HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten
> > scripts, lonely IOT devices, and troubleshooting guides are going to be
> > as easy to solve as updating chrome and firefox.
> > 
> > Whatever the solution, I feel it should be as transparent to the client
> > as possible.  CNAME would fit this bill but the negative impact is
> > largely unknown.
> 
> TL;DR: Experiments with CNAME @ apex showed that it is not going to work
> if the domain has e.g. MX records for e-mail.
> 
> Ondrej Sury describes his experimental results in presentation here:
> https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf

Aren't these results with current state of implementations? A cached
CNAME is expected to be matched against future type queries when
following RFC 1034/1035 behavior.

A change in behavior where resolvers expect that CNAME (as a fallback
type) will co-exist with other types will work properly.

Mukund

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

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

[Stephane Bortzmeyer]

On Wed, Sep 19, 2018 at 07:24:25AM +1000,
 Mark Andrews  wrote 
 a message of 38 lines which said:

> As for scripts, you upgrade the tools those scripts use:
> curl(libcurl), wget, fetch for SH. File::Fetch for perl.  Similar
> for the other scripting languages. Very few applications actually
> make socket calls directly for http.

I hope it is true but I'm not so sure. Any hard data somewhere? My
purely anecdotal evidence is that I've seen "applications actually
make socket calls directly for http", one reason probably being it is
widely teached in schools.

HTTP/2 is a good thing here since it is much harder to do it yourself,
so people will rely on libraries :-)

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

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

[Petr Špaček]

On 18/09/2018 22:02, JW wrote:
> 
>  Original message 
> From: Mark Andrews 
> 
>> I would also expect a relatively large client population using SRV records
>> given the rate Firefox and Chrome browsers are upgraded.  SRV lookups
>> work for lots ofother protocols.  SRV records also make it through
>> firewalls and IDS today.
>>
> 
> Hi Mark,
> 
> I agree SRV is the obvious choice for a greenfield protocol but there is
> HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten
> scripts, lonely IOT devices, and troubleshooting guides are going to be
> as easy to solve as updating chrome and firefox.
> 
> Whatever the solution, I feel it should be as transparent to the client
> as possible.  CNAME would fit this bill but the negative impact is
> largely unknown.

TL;DR: Experiments with CNAME @ apex showed that it is not going to work
if the domain has e.g. MX records for e-mail.

Ondrej Sury describes his experimental results in presentation here:
https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf

Petr Špaček  @  CZ.NIC


> Perhaps defining a set of default protocols for SRV where it could
> simulate a CNAME-like response if https/http SRV records are found?
> 
> /John

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

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

[Mark Andrews]

> On 19 Sep 2018, at 6:02 am, JW  wrote:
> 
> 
>  Original message 
> From: Mark Andrews 
> 
> > I would also expect a relatively large client population using SRV records
> > given the rate Firefox and Chrome browsers are upgraded.  SRV lookups
> > work for lots ofother protocols.  SRV records also make it through
> > firewalls and IDS today.
> >
> 
> Hi Mark,
> 
> I agree SRV is the obvious choice for a greenfield protocol but there is HTTP 
> code sprinkled /everywhere/.  I can't imagine all those forgotten scripts, 
> lonely IOT devices, and troubleshooting guides are going to be as easy to 
> solve as updating chrome and firefox.

Actually it really is.  Think about the names that are served by CDN’s, the 
other data
at those names and the clients that are making those lookups.  Those names with 
other
data are the ones that need to me moved to using SRV.  The rest of the HTTP 
lookups
can continue to use A and  lookup in perpetuity if they want.  Sure we want 
to
upgrade the rest over time but it is mostly browsers that are doing these 
lookups
where there is the other data issues.

As for scripts, you upgrade the tools those scripts use: curl(libcurl), wget, 
fetch
for SH. File::Fetch for perl.  Similar for the other scripting languages. Very 
few
applications actually make socket calls directly for http. 

Mark

> Whatever the solution, I feel it should be as transparent to the client as 
> possible.  CNAME would fit this bill but the negative impact is largely 
> unknown.
> 
> Perhaps defining a set of default protocols for SRV where it could simulate a 
> CNAME-like response if https/http SRV records are found?
> 
> /John
> 
> >
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, 
> > NSW 2117, Australia
> > PHONE: +61 2 9871 4742  
> > INTERNET: ma...@isc.org
> 

-- 
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] abandoning ANAME and standardizing CNAME at apex

[JW]

 Original message From: Mark Andrews 
> I would also expect a relatively large client population using SRV records> 
> given the rate Firefox and Chrome browsers are upgraded.  SRV lookups> work 
> for lots ofother protocols.  SRV records also make it through> firewalls and 
> IDS today.
>

Hi Mark,
I agree SRV is the obvious choice for a greenfield protocol but there is HTTP 
code sprinkled /everywhere/.  I can't imagine all those forgotten scripts, 
lonely IOT devices, and troubleshooting guides are going to be as easy to solve 
as updating chrome and firefox.
Whatever the solution, I feel it should be as transparent to the client as 
possible.  CNAME would fit this bill but the negative impact is largely unknown.
Perhaps defining a set of default protocols for SRV where it could simulate a 
CNAME-like response if https/http SRV records are found?
/John
>
> -- 
> 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] abandoning ANAME and standardizing CNAME at apex

[Mark Andrews]

> On 17 Sep 2018, at 5:43 pm, Mukund Sivaraman  wrote:
> 
> Hi Stephane
> 
> On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
>> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
>> Mukund Sivaraman  wrote 
>> a message of 66 lines which said:
>> 
>>> Adding resolver support (to resolvers that don't have it, i.e.,
>>> vs. RFC 1035) does not appear to break current DNS, i.e., it can be
>>> proposed now.
>> 
>> [Algorithm deleted]
>> 
>> The difficult thing is not to specify what the new resolvers will have
>> to do, but to describe what will happen with the current
>> resolvers. What will happen when "CNAME at apex" will be deployed,
>> assuming X % of the resolvers will not be upgraded?
> 
> I fully realise what you're saying.
> 
> The suggestion is only to require support in resolvers going forward for
> CNAME co-existing with other types for now. That should not break any
> detail of how DNS is used today.
> 
> Whether CNAME + other types at apex can be used in the future would be
> an operational decision for that time of the world.
> 
> Similar things can be said of other proposals.
> 
> * If SRV for HTTP is brought into use, what about X% of user agents that
>  don't have support for it?

Initially none.  That however doesn’t stop a site publishing SRV records for
itself.  They do no harm being published.  As browsers and other clients deploy
add SRV support they will use them.  If you have the SRV records point to
secondary addresses you can actually track the deployment of SRV in your
client population.

e.g.

example.com  2001:0DB8::1
_http._tcp.example.com SRV 0 0 80 server.example.net
server.example.net  2001:0DB8::2

I would also expect a relatively large client population using SRV records given
the rate Firefox and Chrome browsers are upgraded.  SRV lookups work for lots of
other protocols.  SRV records also make it through firewalls and IDS today.

Sites can look at the clients that are still using legacy A/ records as well
as the user agent so they know who and what to target to get SRV support added.

There is no simple / reliable way to measure the client population support for
accepting CNAME co-existance.

> * If a new RR type is introduced, what about X% of resolvers that do not
>  support it?
> 
> Although it changes current DNS protocol, AFAICT there does not seem to
> be anything badly wrong with allowing CNAME + other types at a node,
> where the CNAME is considered a fallback when the required type doesn't
> exist.

Which is a matter of opinion.  Even if support was started today it would be
a decade at least, maybe two, before you could use MX + CNAME instead of
MX + A/ synthesis.  DNS servers are just not upgraded that fast.

> Repeating what the original post's author Petr said, this seems to be a
> simpler change than adding other types for similar benefit, esp. when
> hacks are already necessary to workaround the case of CNAME and other
> types co-existing that are seen in the DNS.
> 
>   Mukund
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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] abandoning ANAME and standardizing CNAME at apex

[Mukund Sivaraman]

Hi Evan

On Mon, Sep 17, 2018 at 04:11:24PM +, Evan Hunt wrote:
> On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote:
> > Similar things can be said of other proposals.
> > 
> > * If SRV for HTTP is brought into use, what about X% of user agents that
> >   don't have support for it?
> > 
> > * If a new RR type is introduced, what about X% of resolvers that do not
> >   support it?
> 
> They're no worse off than they already were. The old methods would still
> work just as well or badly as they do today.
> 
> If apex CNAME were declared legitimate, then people using legacy resolvers
> *would* be worse off than they are now.

This would not be a decision for people using legacy resolvers to make -
it would be for the zone administrator to decide whether to co-exist
CNAME with other types depending on market share of resolver support.
Then, it wouldn't mean resolvers would break for all other zones - they
could break for this particular zone.

We see this happening in other technologies where new things are
introduced. E.g., many popular websites use SVG, canvas, HTML5 elements,
etc. with no fallback for old browsers which still exist.

(a) Initially, very few web browser instances supported the new
features.

(b) At some point, a majority of web browser instances supported it.

(c) At some point, the *web developer* (not the browser user) decides
that they will now use the new feature in their website, even though it
would not work on a percentage of web browser instances in the wild. It
is a calculated decision for that individual website's case (in the DNS
world, it is for that particular zone and the zone administrator's
choice depending on the risk).

No old behavior is removed as long as zone admins stick to the current
way. Current zones will work as before. And it is a resolver-specific
requirement to support CNAMES with other types for now - it doesn't
require authoritative use, without checking if the new feature is
supported in the market.

The example about SRV has just as much risk. What about browsers that
don't support it? Whether to co-exist CNAME with MX has similar risk as
whether to depend on a new SRV's support in web browsers.

The ANAME draft seemed to beat this, but it got quite complicated.

Mukund

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

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

[Evan Hunt]

On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote:
> Similar things can be said of other proposals.
> 
> * If SRV for HTTP is brought into use, what about X% of user agents that
>   don't have support for it?
> 
> * If a new RR type is introduced, what about X% of resolvers that do not
>   support it?

They're no worse off than they already were. The old methods would still
work just as well or badly as they do today.

If apex CNAME were declared legitimate, then people using legacy resolvers
*would* be worse off than they are now.

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

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

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

[Mukund Sivaraman]

Hi Petr

On Mon, Sep 17, 2018 at 12:29:13PM +0200, Petr Špaček wrote:
> Originally I thought that current workarounds for CNAME at apex (which
> are almost everywhere) deal with it in a more deterministic way.

Do you mean the current workarounds in resolver implementations?  These
can be brought into line going forward if there's a draft of expected
behavior.

I was sold when Evan presented the (basic) ANAME idea at a team meeting
at ISC and thought it was a fine idea. Now it seems that relaxing CNAME
to be a fallback would be the most painless and simple path. I
remembered reading something on dnsop@ and got to this thread. Other
ideas would create yet another chapter in the DNS book to implement
which seems excessive for little added benefit.

Mukund

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

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

[Petr Špaček]

On 17/09/2018 11:30, Mukund Sivaraman wrote:
> Hi Ray
> 
> On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote:
>> On 17/09/2018 08:43, Mukund Sivaraman wrote:
>>
>>> The suggestion is only to require support in resolvers going forward for
>>> CNAME co-existing with other types for now. That should not break any
>>> detail of how DNS is used today.
>>
>> 
>>
>>> Although it changes current DNS protocol, AFAICT there does not seem to
>>> be anything badly wrong with allowing CNAME + other types at a node,
>>> where the CNAME is considered a fallback when the required type doesn't
>>> exist.
>>
>> This is not true.
>>
>> Ondrej demonstrated at the last hackathon that permitting a CNAME
>> alongside the apex can cause MX-related failures in resolvers that are
>> not upgraded.
> 
> "The suggestion is only to require support in resolvers going forward
> for CNAME co-existing with other types for now."
> 
> It is obvious if authoritatives did that today and a RFC 1035 resolver
> cached a CNAME, it would match the cached CNAME when doing a type lookup
> in cache.
Originally I thought that current workarounds for CNAME at apex (which
are almost everywhere) deal with it in a more deterministic way.
Unfortunatelly it is not the case so I think this is a dead end.

Petr Špacek  @  CZ.NIC

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

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

[Mukund Sivaraman]

Hi Ray

On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote:
> On 17/09/2018 08:43, Mukund Sivaraman wrote:
> 
> > The suggestion is only to require support in resolvers going forward for
> > CNAME co-existing with other types for now. That should not break any
> > detail of how DNS is used today.
> 
> 
> 
> > Although it changes current DNS protocol, AFAICT there does not seem to
> > be anything badly wrong with allowing CNAME + other types at a node,
> > where the CNAME is considered a fallback when the required type doesn't
> > exist.
> 
> This is not true.
> 
> Ondrej demonstrated at the last hackathon that permitting a CNAME
> alongside the apex can cause MX-related failures in resolvers that are
> not upgraded.

"The suggestion is only to require support in resolvers going forward
for CNAME co-existing with other types for now."

It is obvious if authoritatives did that today and a RFC 1035 resolver
cached a CNAME, it would match the cached CNAME when doing a type lookup
in cache.

Mukund

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

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

[Ray Bellis]

On 17/09/2018 08:43, Mukund Sivaraman wrote:

> The suggestion is only to require support in resolvers going forward for
> CNAME co-existing with other types for now. That should not break any
> detail of how DNS is used today.



> Although it changes current DNS protocol, AFAICT there does not seem to
> be anything badly wrong with allowing CNAME + other types at a node,
> where the CNAME is considered a fallback when the required type doesn't
> exist.

This is not true.

Ondrej demonstrated at the last hackathon that permitting a CNAME
alongside the apex can cause MX-related failures in resolvers that are
not upgraded.

There are going to be presentations on this topic at the forthcoming
DNS-OARC meeting in Amsterdam.

Ray

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

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

[Mukund Sivaraman]

Hi Stephane

On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
>  Mukund Sivaraman  wrote 
>  a message of 66 lines which said:
> 
> > Adding resolver support (to resolvers that don't have it, i.e.,
> > vs. RFC 1035) does not appear to break current DNS, i.e., it can be
> > proposed now.
> 
> [Algorithm deleted]
> 
> The difficult thing is not to specify what the new resolvers will have
> to do, but to describe what will happen with the current
> resolvers. What will happen when "CNAME at apex" will be deployed,
> assuming X % of the resolvers will not be upgraded?

I fully realise what you're saying.

The suggestion is only to require support in resolvers going forward for
CNAME co-existing with other types for now. That should not break any
detail of how DNS is used today.

Whether CNAME + other types at apex can be used in the future would be
an operational decision for that time of the world.

Similar things can be said of other proposals.

* If SRV for HTTP is brought into use, what about X% of user agents that
  don't have support for it?

* If a new RR type is introduced, what about X% of resolvers that do not
  support it?

Although it changes current DNS protocol, AFAICT there does not seem to
be anything badly wrong with allowing CNAME + other types at a node,
where the CNAME is considered a fallback when the required type doesn't
exist.

Repeating what the original post's author Petr said, this seems to be a
simpler change than adding other types for similar benefit, esp. when
hacks are already necessary to workaround the case of CNAME and other
types co-existing that are seen in the DNS.

Mukund

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

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

[Ray Bellis]

On 17/09/2018 08:11, Stephane Bortzmeyer wrote:


Since the main use case is "people with a domain name such as
example.com, who wants https://example.com/ to actually work, and who
hosts the stuff at a CDN where the IP address is wildly variable so
they cannot use A or  records", I suggest that this use case is
better solved by using SRV records for HTTP. True, it seems
unrealistic that it will be specified and deployed but it is also the
case for the DNS "CNAME at apex" change.


We heard at the side meeting in Montreal that SRV doesn't meet the 
requirements, in part because it has features that are considered 
incompatible with the web origin model (i.e. the port field).


I do believe we need a new DNS type code that is designed in cooperation 
with the HTTP community and I've suggested as such on the http-srv 
mailing list, but so far there's little engagement.


There was a suggestion that the proposed ALT-SVC RR could be used, but 
IMHO it has significant issues that would need to be resolved first.


Ray

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

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

[Stephane Bortzmeyer]

On Sun, Sep 16, 2018 at 03:26:56PM +0530,
 Mukund Sivaraman  wrote 
 a message of 66 lines which said:

> Adding resolver support (to resolvers that don't have it, i.e.,
> vs. RFC 1035) does not appear to break current DNS, i.e., it can be
> proposed now.

[Algorithm deleted]

The difficult thing is not to specify what the new resolvers will have
to do, but to describe what will happen with the current
resolvers. What will happen when "CNAME at apex" will be deployed,
assuming X % of the resolvers will not be upgraded?

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

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

[Stephane Bortzmeyer]

On Mon, Sep 17, 2018 at 03:51:34AM +,
 Evan Hunt  wrote 
 a message of 124 lines which said:

> I don't see how we can responsibly declare a new standard which, if
> followed, will break every prior implementation. Apex CNAME is the
> sort of solution that's clear, simple, and wrong.

+1

> We're going to need another type code.

Since the main use case is "people with a domain name such as
example.com, who wants https://example.com/ to actually work, and who
hosts the stuff at a CDN where the IP address is wildly variable so
they cannot use A or  records", I suggest that this use case is
better solved by using SRV records for HTTP. True, it seems
unrealistic that it will be specified and deployed but it is also the
case for the DNS "CNAME at apex" change.

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

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

[Evan Hunt]

It seems to me problematic to start with the statement that apex CNAME is
"deployed on the internet". Obviously it does occur, but it breaks things
when it does.  Depending on various factors such as the order in which
responses are cached, the breakage is sometimes survivable, but you can't
put a CNAME at a zone apex and expect resolvers to Just Work. Even the
ones that have hacks to work around this problem aren't always successful.

I don't see how we can responsibly declare a new standard which, if
followed, will break every prior implementation. Apex CNAME is the sort
of solution that's clear, simple, and wrong.

We're going to need another type code.

On Mon, Sep 17, 2018 at 01:18:24AM +, Dan York wrote:
> Mukund,
> 
> Thank you for reviving this conversation. I was just asked last week
> about the status of this whole debate by someone who was seeking to set
> up “CNAME at apex”-style records for a variety of domains, all of which
> would be pointed over to links within various CDNs.
> 
> His challenge is that, for a variety of reasons not within his control,
> his domains are spread across several different CDNs / DNS hosting
> providers, all of whom do “CNAME at apex” in different ways. (And, if I
> recall correctly, one provider did NOT support this capability, citing
> RFC 1035 as their rationale.) The added complexity, and having to be
> sure he is doing it correctly for each of the different services, is
> quite frustrating and time consuming.  Meanwhile, he has communications
> people asking him very strongly for the ability to drop the “www” and
> just refer to their website addresses as
> “example.com/”.
> 
> Hence his question to me about if this was ever going to be “fixed” by
> the IETF with some kind of standard.
> 
> I do think something needs to be done to standardize CNAME (or something
> very similar) at the apex. For the person with whom I was speaking, all
> of this websites are set up using various CDNs. So all he can provide is
> a DNS address in the CDN’s network.  He has no way to get an A or 
> address as I understand the ANAME proposal would require.
> 
> So this is a lengthy way of saying that I would agree with moving ahead
> with a proposal to allow CNAME at apex, and to start to get resolvers to
> implement that.  I realize that updating the whole DNS infrastructure is
> incredibly challenging (we wrote about this with regard to crypto
> algorithms at
> https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs
> ).  And so this may not be something widely available for some time.
> But if we could get it started, it would definitely help the many people
> out there trying to configure domains to point to CDNs from their apex.
> 
> Dan
>
> --
> Dan York
> Director, Content & Web Strategy, Internet Society
> y...@isoc.org   +1-802-735-1624
> Jabber: y...@jabber.isoc.org  Skype: danyork   
> http://twitter.com/danyork
> 
> http://www.internetsociety.org/
> 
> On Sep 16, 2018, at 5:56 AM, Mukund Sivaraman 
> mailto:m...@mukund.org>> wrote:
> 
> Hi Petr
> 
> Apologies for the delayed reply.
> 
> On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
> Hello dnsop,
> 
> beware, material in this e-mail might cause your head to explode :-)
> 
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
>  is is deployed on the Internet.
> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>  already have code to cope with the "impossible" case of CNAME at the
>  apex and deal with it in ways which do not break stuff on resolver
>  side.
> - Authoritative servers of vendors named above refuse to serve CNAME at
>  apex.
> - There are CDNs etc. which allow users to create CNAME at apex
>  no matter what the standards and "normal" servers say and do.
> (We have found out this because Knot Resolver is missing hacks for CNAME
> at apex and users complain that "it works with every other resolver".)
> 
> 
> Take a deep breath!
> 
> 
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
> 
> It is very clear violation of the standard, but almost everyone found
> his way around it using different hacks. These hacks are not going away
> because all the CDNs just don't care about standards so we will have
> to maintain this code no matter what a great solution we will invent for
> future. I.e. adding ANAME will just increase complexity because CNAME at
> apex will be there for a long time (if not forever).
> 
> I personally do not like this but it seems better to think though
> corner cases in code we already have in production (i.e. think through
> current hacks for CNAME at apex) instead of inventing new things like ANAME
> (or whatever else).
> 
> Opinions? Tomatoes? Can it work? If not, why not?
> 
> To me it seems it can work, and it sounds like a goo

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

[Dan York]

Mukund,

Thank you for reviving this conversation. I was just asked last week about the 
status of this whole debate by someone who was seeking to set up “CNAME at 
apex”-style records for a variety of domains, all of which would be pointed 
over to links within various CDNs.

His challenge is that, for a variety of reasons not within his control, his 
domains are spread across several different CDNs / DNS hosting providers, all 
of whom do “CNAME at apex” in different ways. (And, if I recall correctly, one 
provider did NOT support this capability, citing RFC 1035 as their rationale.) 
The added complexity, and having to be sure he is doing it correctly for each 
of the different services, is quite frustrating and time consuming.  Meanwhile, 
he has communications people asking him very strongly for the ability to drop 
the “www” and just refer to their website addresses as 
“example.com/”.

Hence his question to me about if this was ever going to be “fixed” by the IETF 
with some kind of standard.

I do think something needs to be done to standardize CNAME (or something very 
similar) at the apex. For the person with whom I was speaking, all of this 
websites are set up using various CDNs. So all he can provide is a DNS address 
in the CDN’s network.  He has no way to get an A or  address as I 
understand the ANAME proposal would require.

So this is a lengthy way of saying that I would agree with moving ahead with a 
proposal to allow CNAME at apex, and to start to get resolvers to implement 
that.  I realize that updating the whole DNS infrastructure is incredibly 
challenging (we wrote about this with regard to crypto algorithms at 
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs ).  
And so this may not be something widely available for some time.  But if we 
could get it started, it would definitely help the many people out there trying 
to configure domains to point to CDNs from their apex.

Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.org  Skype: danyork   
http://twitter.com/danyork

http://www.internetsociety.org/

On Sep 16, 2018, at 5:56 AM, Mukund Sivaraman 
mailto:m...@mukund.org>> wrote:

Hi Petr

Apologies for the delayed reply.

On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
Hello dnsop,

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

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


Take a deep breath!


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

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

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

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

To me it seems it can work, and it sounds like a good idea. To relax DNS
protocol for CNAME to co-exist with other RR types, we'd need resolver
support, authoritive support and a time when it is practially usable.



Adding resolver support (to resolvers that don't have it, i.e., vs. RFC
1035) does not appear to break current DNS, i.e., it can be proposed
now.

1. When a resolver looks up a RR type in cache, and finds any positive
type match, it serves it.

2. If it does not find a positive type match, but finds a CNAME, it
looks for a negative cache entry for that RR type.

2.a. If a negative cache entry is found (or if it can synthesize one),
it returns/follows the CNAME chain.

2.b. If no negative cache entry is found (and it cannot synthesize one),
it starts a fetch for that type from upstream.

2.b.i. If the fetch returns a CNAME or NODATA, it means that the type
does not co-exist with CNAME in that node in the auth zone

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

[Paul Vixie]

this proposal appears to make more sense. if cname cannot be used until 
everybody has upgraded, then some other ?name RR could be used instead, 
on a similar time line, and would have no impact on those who never 
upgraded.


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

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

[Mukund Sivaraman]

Hi Petr

Apologies for the delayed reply.

On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
> Hello dnsop,
> 
> beware, material in this e-mail might cause your head to explode :-)
> 
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
>   is is deployed on the Internet.
> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>   already have code to cope with the "impossible" case of CNAME at the
>   apex and deal with it in ways which do not break stuff on resolver
>   side.
> - Authoritative servers of vendors named above refuse to serve CNAME at
>   apex.
> - There are CDNs etc. which allow users to create CNAME at apex
>   no matter what the standards and "normal" servers say and do.
> (We have found out this because Knot Resolver is missing hacks for CNAME
> at apex and users complain that "it works with every other resolver".)
> 
> 
> Take a deep breath!
> 
> 
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
> 
> It is very clear violation of the standard, but almost everyone found
> his way around it using different hacks. These hacks are not going away
> because all the CDNs just don't care about standards so we will have
> to maintain this code no matter what a great solution we will invent for
> future. I.e. adding ANAME will just increase complexity because CNAME at
> apex will be there for a long time (if not forever).
> 
> I personally do not like this but it seems better to think though
> corner cases in code we already have in production (i.e. think through
> current hacks for CNAME at apex) instead of inventing new things like ANAME
> (or whatever else).
> 
> Opinions? Tomatoes? Can it work? If not, why not?

To me it seems it can work, and it sounds like a good idea. To relax DNS
protocol for CNAME to co-exist with other RR types, we'd need resolver
support, authoritive support and a time when it is practially usable.



Adding resolver support (to resolvers that don't have it, i.e., vs. RFC
1035) does not appear to break current DNS, i.e., it can be proposed
now.

1. When a resolver looks up a RR type in cache, and finds any positive
type match, it serves it.

2. If it does not find a positive type match, but finds a CNAME, it
looks for a negative cache entry for that RR type.

2.a. If a negative cache entry is found (or if it can synthesize one),
it returns/follows the CNAME chain.

2.b. If no negative cache entry is found (and it cannot synthesize one),
it starts a fetch for that type from upstream.

2.b.i. If the fetch returns a CNAME or NODATA, it means that the type
does not co-exist with CNAME in that node in the auth zone. The resolver
adds a negative cache entry for the type for the TTL of the returned
CNAME (or from SOA fields) to the cache, and returns/follows the CNAME
chain.

2.b.ii. If the fetch returns the type, it means that the type may
co-exist with the CNAME. The resolver adds a positive cache entry for
the type and returns the fetched answer.

2.b.iii. If the fetch returns NXDOMAIN, it overwrites the cache for that
node with a negative cache entry.



Adding authoriative support would mean relaxing checks and allowing
CNAME to co-exist with other types except non-apex NS (parent of zone
cut), and perhaps allow CNAME and DNAME to co-exist too.

For operators to be able to use it, they would need resolver support to
be available everywhere. I guess nothing stops a draft requiring
resolvers to implement support for it now.

So +1.

Mukund

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

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

[Lanlan Pan]

Anthony Eden 于2018年6月20日周三 上午12:06写道：

> On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan  wrote:
>
>>
>>
>> Petr Špaček 于2018年6月19日周二 下午9:19写道：
>>
>>> Hello dnsop,
>>>
>>> beware, material in this e-mail might cause your head to explode :-)
>>>
>>> This proposal is based on following observations:
>>> - It seems that DNS protocol police lost battle about CNAME at apex,
>>>is is deployed on the Internet.
>>> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>>>already have code to cope with the "impossible" case of CNAME at the
>>>apex and deal with it in ways which do not break stuff on resolver
>>>side.
>>> - Authoritative servers of vendors named above refuse to serve CNAME at
>>>apex.
>>> - There are CDNs etc. which allow users to create CNAME at apex
>>>no matter what the standards and "normal" servers say and do.
>>> (We have found out this because Knot Resolver is missing hacks for CNAME
>>> at apex and users complain that "it works with every other resolver".)
>>>
>>>
>>> Take a deep breath!
>>>
>>>
>>> Given that resolver side somehow works already ...
>>> could we standardize this obvious violation of RFC 1035?
>>>
>>> It is very clear violation of the standard, but almost everyone found
>>> his way around it using different hacks. These hacks are not going away
>>> because all the CDNs just don't care about standards so we will have
>>> to maintain this code no matter what a great solution we will invent for
>>> future. I.e. adding ANAME will just increase complexity because CNAME at
>>> apex will be there for a long time (if not forever).
>>>
>>> I personally do not like this but it seems better to think though
>>> corner cases in code we already have in production (i.e. think through
>>> current hacks for CNAME at apex) instead of inventing new things like
>>> ANAME (or whatever else).
>>>
>> I think ANAME RR is hard to compatible with many old version resolvers.
>> If there are mutiple ANAME RR at compatible resolvers, authoritatives may
>> not know that resolvers will choose which A RR for client response.
>>
>> ANAME can ease apex CNAME configuration, maybe a work round is that
>> authoritatives directly return A RR to resolvers (but not ANAME RR).
>>
>
> This is essentially what those of us who implemented ANAME in
> authoritative name servers do right now. The original draft I started about
> ALIAS records also spelled out only this solution with some operational
> guidance on best practices.
>

Section 4. Recursive Server Behavior:  send client subnet  when query ANAME
target ?
Would it be simpler director send client subnet when first query ?

Anyway, one of ANAME's benefits is that it can return both  and A in
one response.


>
>>
>>> Opinions? Tomatoes? Can it work? If not, why not?
>>>
>>> --
>>> Petr Špacek  @  CZ.NIC
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> --
>> 致礼  Best Regards
>>
>> 潘蓝兰  Pan Lanlan
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
>
> --
> DNSimple.com
> http://dnsimple.com/
> Twitter: @dnsimple
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Fri, Jul 06, 2018 at 08:22:41AM +0200, Matthijs Mekking wrote:
> Me too :)
> 
> https://github.com/each/draft-aname/pulls

Yes, sorry, my bad. I'll try to address the pull requests next week.
Should've done ages ago.

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

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

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

[Tony Finch]

John Levine  wrote:
>
> You're probably right, but I think that ANAME would need as many
> upgrades, just in slightly different places.

ANAME should work without upgrades, because A and  queries will get
the answers they expect. ANAME support is just a performance optimization
when the ANAME target is going geodns tricks.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lundy, Fastnet: Variable mainly west 3 or 4. Slight. Fog patches developing.
Moderate or good, occasionally very poor.

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

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

[John Levine]

In article <5b3e8242.1010...@redbarn.org> you write:
>i think you will find that there is no dnssec-compatible way to solve 
>this problem without upgrades to both authority AND recursive AND stub 
>dns agents, AND to the getnameinfo-or-similar API. if i'm right, it'll 
>be necessary to make hard choices, such has, reconsider the constraints.

You're probably right, but I think that ANAME would need as many
upgrades, just in slightly different places.

Using CNAME has the (perhaps hypothetical) advantage that if we do it,
a lot of existing zone files that are now invalid will have become valid
with defined semantics.

R's,
John

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

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

[Matthijs Mekking]

On 07/05/2018 06:15 PM, Tony Finch wrote:

Tim Wicinski  wrote:


The chairs have decided to set aside some time in Montreal and see if we
can work through this problem.  We've asked Ondřej  from ISC and Willem
from NLnetLabs to help guide the talk.


I was hoping that there would be another revision of the draft following
IETF 101, based on the discussions we had then.


Me too :)

https://github.com/each/draft-aname/pulls

Matthijs



Is there some huge problem that I haven't noticed?

Tony.



___
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] abandoning ANAME and standardizing CNAME at apex

[Paul Vixie]

Tim Wicinski wrote:

...
What we do know is:

  - We're not going to do SRV records (sorry Mark).
  - We're not going to ask the IAB to give a waiver on DNSSEC.
  - We still bang into each other over this.


i think you will find that there is no dnssec-compatible way to solve 
this problem without upgrades to both authority AND recursive AND stub 
dns agents, AND to the getnameinfo-or-similar API. if i'm right, it'll 
be necessary to make hard choices, such has, reconsider the constraints.


--
P Vixie

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

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

[Brian Dickson]

Paul Vixie wrote:

> Tony Finch wrote:
>
> Paul Wouters  wrote:
>
> I understand, I just disagree this is the right way. I don't see why
> this entire problem shouldn't be resolved at the well, resolver level.
>
> I don't see how that can be deployed in a way that is compatible with
> existing software.
>
> there are now a half dozen x.x.x.x (where x is the same in all four octets)
> public anycast resolvers. if they can all be upgraded to handle dnssec or
> ECS, they can all be upgraded to handle something like ANAME.
>
> the "resolver" here is the recursive, not the stub. stubs believe what they
> hear, for good or ill. if we need to change what they hear, it's not as
> impossible as changing what they understand.
>
> --
> P Vixie
>
>
>
Apologies for a late response to an early part of the thread/discussion.

To paraphrase (hopefully correctly), we should be looking at ways of
getting the resolver to possibly just return A records (with appropriate
TTL) to stubs, even if the recursive was handed something along the likes
of an apex CNAME that it understood, or something that achieves the same
effect if the apex CNAME isn't something the resolver understands.

I think there is something that can be borrowed from the DNSSEC DNAME
stuff, where a DNAME signed response is accompanied by an unsigned CNAME.
DNAME-aware resolvers use/cache it, while DNAME-unaware resolvers get the
synthesized CNAME which they can cache. DNSSEC required DNAME, which is
very helpful -- this ensures the unsigned CNAME isn't breaking validation.

The thing to note about DNAME/CNAME, is that there is a performance/scale
benefit to having a resolver that understands DNAME. The CNAME hack works,
but can require much more work by the resolver (in terms of query to the
authoritative). Having DNSSEC-unaware resolver clients is pretty easy, as
the resolver can do its own CNAME synthesis.

The analogous set-up would be a CNAME2 RR type accompanied by (or replaced
by) a corresponding CNAME RR with TTL=0. I think it would preferable to use
a bit flag in the EDNS bitfield, where the client can signal CNAME2
awareness, and the server can signal its own support on replies. And I
think chaining involving both types (regardless of order of type in an
ordered chain) produces correct results/behavior.

(In the following, foo2 means foo understands CNAME2, foo means it doesn't)

foo -> resolver -> auth2 : auth2 sends CNAME TTL=0, resolver sends (but
does not cache) CNAME TTL=0.
foo -> resolver2 -> auth2 : auth2 sends CNAME2, resolver caches CNAME2,
sends CNAME with TTL=0.
foo2 -> resolver2 -> auth2 : auth2 sends CNAME2, resolver caches CNAME2,
sends CNAME2 response.

CNAME2 would need to have a bitfield of applicable RRTYPEs, similar to
NSEC/NSEC3.

resolver2 would then be able to synthesize CNAME TTL=0 responses for
subsequent queries from foo (or any other non-CNAME2-aware client).

Other than performance load due to TTL=0 for popular domains, which
admittedly is a big one, I don't think this wouldn't work.

This is probably something that would require substantial deployment in the
resolver community before it likely gets much use on the auth side.

Thoughts? Or discuss in Montreal...

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

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

[Tony Finch]

Tim Wicinski  wrote:
>
> The chairs have decided to set aside some time in Montreal and see if we
> can work through this problem.  We've asked Ondřej  from ISC and Willem
> from NLnetLabs to help guide the talk.

I was hoping that there would be another revision of the draft following
IETF 101, based on the discussions we had then.

Is there some huge problem that I haven't noticed?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
champion the freedom, dignity, and well-being of individuals___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On 5 Jul 2018, at 8:28, Tim Wicinski wrote:


I admit I look at this
problem too much through the lens of someone who thinks about 
operational

issues.


E, that's not a bad thing. This is DNSOP, not DNSEXT, after all.

The chairs have decided to set aside some time in Montreal and see if 
we
can work through this problem.  We've asked Ondřej  from ISC and 
Willem

from NLnetLabs to help guide the talk.


Hopefully the mic line is mostly OP, not EXT, folks. We can EXT all we 
want, but the purpose of this specific work is to improve OP.


--Paul Hoffman

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

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

[Tim Wicinski]

All

Thanks for this highly entertaining and also information conversation.  I
apologize for kicking up the dust but I feel this is one of those
conversations where the end-users/operators and protocol people are
disconnected.I do know when we talked with several DNS providers about
a standard was of synthesizing names at the apex, we encountered a similar
level of pushback.  Most of them spent the time explaining how
sophisticated their method was over Vendor Y.

But I don't think it's an impossible problem to solve, and this thread is
full of very smart people attempting to do that.   I admit I look at this
problem too much through the lens of someone who thinks about operational
issues. (I am probably not the only one here who was paged in the middle of
the night when someone rolled out 9.12 without reading the fine print).

What we do know is:

 - We're not going to do SRV records (sorry Mark).
 - We're not going to ask the IAB to give a waiver on DNSSEC.
 - We still bang into each other over this.

The chairs have decided to set aside some time in Montreal and see if we
can work through this problem.  We've asked Ondřej  from ISC and Willem
from NLnetLabs to help guide the talk.

Thanks
Tim




On Mon, Jun 25, 2018 at 1:00 PM, Paul Vixie  wrote:

>
>
> Tony Finch wrote:
>
>> Paul Wouters  wrote:
>>
>>> I understand, I just disagree this is the right way. I don't see why
>>> this entire problem shouldn't be resolved at the well, resolver level.
>>>
>>
>> I don't see how that can be deployed in a way that is compatible with
>> existing software.
>>
>
> there are now a half dozen x.x.x.x (where x is the same in all four
> octets) public anycast resolvers. if they can all be upgraded to handle
> dnssec or ECS, they can all be upgraded to handle something like ANAME.
>
> the "resolver" here is the recursive, not the stub. stubs believe what
> they hear, for good or ill. if we need to change what they hear, it's not
> as impossible as changing what they understand.
>
> --
> P Vixie
>
>
> ___
> 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] abandoning ANAME and standardizing CNAME at apex

[Paul Vixie]

Tony Finch wrote:

Paul Wouters  wrote:

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


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


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


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


--
P Vixie

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

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

[Tony Finch]

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

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, Thames, Dover: Variable becoming mainly northeast, 3 or 4,
occasionally 5 later in Dover. Slight, occasionally moderate later. Fog
patches. Moderate or good, occasionally very poor.

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

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

[Paul Wouters]

On Mon, 25 Jun 2018, Tony Finch wrote:


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


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

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


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


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


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

Paul

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

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

[Tony Finch]

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

Yes.

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

Yes.

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

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

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
South Utsire: Northwesterly 5 to 7. Moderate, occasionally rough in south.
Fair. Good.

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

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

[Paul Vixie]

Tony Finch wrote:

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

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

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

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


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


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


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


--
P Vixie

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

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

[Colm MacCárthaigh]

On Mon, Jun 25, 2018 at 8:06 AM, Ray Bellis  wrote:

> On 25/06/2018 16:05, Paul Wouters wrote:
>
> > Then you might as well use that mechanism to update A/ records and
> > skip the intermediate ANAME?
>
> +1
>
> Apex records are a provisioning problem, not a protocol one.
>

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

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

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

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

[Tony Finch]

Paul Wouters  wrote:
> On Mon, 25 Jun 2018, Tony Finch wrote:
>
> > That isn't required if the ANAME target records are fetched/updated by an
> > out-of-band provisioning process.
>
> Then you might as well use that mechanism to update A/ records and
> skip the intermediate ANAME?

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

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

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

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
a just distribution of the rewards of success

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

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

[Ray Bellis]

On 25/06/2018 16:05, Paul Wouters wrote:

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

+1

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

Ray

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

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

[Paul Wouters]

On Mon, 25 Jun 2018, Tony Finch wrote:


That isn't required if the ANAME target records are fetched/updated by an
out-of-band provisioning process.


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

Paul

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

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

[Tony Finch]

Colm MacCárthaigh  wrote:
> On Mon, Jun 25, 2018 at 7:02 AM, Tony Finch  wrote:
> >
> > That isn't required if the ANAME target records are fetched/updated by an
> > out-of-band provisioning process. A server will want to do it this way if
> > its query rate is bigger than the number of ANAME targetss divided by
> > their TTLs.
>
> A challenge with that is that many people now use geographic or latency
> based DNS routing based on the resolver IP address or EDNS-client-subnet.
> That's one of the reasons why Route53's ALIAS works only for targets that
> Route53 is authoritative for.

I think there are two issues here:

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

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

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Hebrides: Southwesterly 5 until later in northwest, otherwise variable 3 or 4.
Rough at first in northwest, otherwise slight or moderate. Mainly fair. Good,
occasionally poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Colm MacCárthaigh]

On Mon, Jun 25, 2018 at 7:02 AM, Tony Finch  wrote:

> > Even that though requires that the authoritative server be capable of
> > waiting for an asynchronously retrieved value before it can respond.
> >
> > For some authoritative servers that might require a substantial redesign.
>
> That isn't required if the ANAME target records are fetched/updated by an
> out-of-band provisioning process. A server will want to do it this way if
> its query rate is bigger than the number of ANAME targetss divided by
> their TTLs.
>

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

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

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

[Tony Finch]

Ray Bellis  wrote:
> On 22/06/2018 19:27, Evan Hunt wrote:
>
> > Minor clarification here: ANAME doesn't require the authoritative
> > server itself to do recursion; it requires it to have access to a
> > reursive server.
>
> Even that though requires that the authoritative server be capable of
> waiting for an asynchronously retrieved value before it can respond.
>
> For some authoritative servers that might require a substantial redesign.

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
West Forties, Cromarty, Forth, Tyne, Dogger: Variable 3 or 4, occasionally
northeasterly 5 at first in Cromarty and Forth. Slight. Fog patches
developing. Moderate or good, occasionally very poor.

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

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

[Tony Finch]

Paul Vixie  wrote:
> 神明達哉 wrote:
> >
> > I've always thought there's no point in standardizing ANAME-kind of
> > thing unless its ultimate goal includes the resolver-side support.
> > ...
>
> and to be clear, we already created a system like that: SRV. so if
> that's the only way we can do it, it's already done, and we know how it
> ends.

ANAME avoids some of the pitfalls that SRV encountered:

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

* recursive support is an optimization, not a requirement

* no added last-mile latency

And there are existing implementations that demonstrate demand.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
strengthen the democratic process and ensure that
there is a just and representative system of government___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

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

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

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

For some authoritative servers that might require a substantial redesign.

Ray

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

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

[Evan Hunt]

On Sun, Jun 24, 2018 at 07:42:36PM +, Viktor Dukhovni wrote:
> But that requires a new "XNAME" rrtype, whereas what the users want
> is a more flexible CNAME that coëxists with other RRtypes.

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

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

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

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

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

[Viktor Dukhovni]

On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote:

> > Yes, but if they have the NSEC bitmap, they can follow the XNAME
> > without asking again.
> > [...]
> > That's already handled by NSEC/NSEC3.
> 
> I think a pragmatic solution needs to work in unsigned zones.

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

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

> If an XNAME proposal was to solve real-world problems for these people
> it would need to work with or without DNSSEC.
> [...]
> (And I wasn't entirely serious about calling the wildcard RRTYPE * :-)

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

On Sun, Jun 24, 2018 at 04:36:50AM +, Evan Hunt wrote:

> > I think a pragmatic solution needs to work in unsigned zones.
> 
> +1, but, an unsigned zone could still return an NSEC-style bitmap.  It
> wouldn't be provably correct, but neither is any other unsigned response.

Agreed.

> You could actually add the bitmap to the XNAME rdata, instead of returning
> an NSEC.

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

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

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

> In any case, I don't understand how XNAME avoids the "ANAME kludges".
> Legacy resolvers won't know what to do with XNAME, so all the same
> workarounds on the auth side still must be implemented.

By making: XNAME == CNAME.

-- 
Viktor.

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

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

[Evan Hunt]

On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote:
> I think a pragmatic solution needs to work in unsigned zones.

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

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

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

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

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

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

[Paul Vixie]

Joe Abley wrote:

On Jun 23, 2018, at 22:45, Paul Vixie  wrote:


Joe Abley wrote:

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

...

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

"let's move on."


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


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


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



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


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


...

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


"cart, meet horse."

--
P Vixie

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

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

[Shumon Huque]

On Sat, Jun 23, 2018 at 10:45 PM Paul Vixie  wrote:

>
> Joe Abley wrote:
> > I think a pragmatic solution needs to work in unsigned zones.
> >
> > ...
>
> can someone ask the IAB to rule on whether any new internet technology
> standard should address unsigned DNS zones, or for that matter, IPv4
> networks?
>

I have to agree with Joe here.

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

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

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

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

[Joe Abley]

On Jun 23, 2018, at 22:45, Paul Vixie  wrote:

> Joe Abley wrote:
>> I think a pragmatic solution needs to work in unsigned zones.
>>
>> ...
>
> can someone ask the IAB to rule on whether any new internet technology 
> standard should address unsigned DNS zones, or for that matter, IPv4 networks?
>
> "let's move on."

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

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

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

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


Joe

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

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

[Paul Vixie]

Joe Abley wrote:

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

...


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


"let's move on."

--
P Vixie

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

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

[Joe Abley]

Hi Victor,

On Jun 23, 2018, at 17:04, Viktor Dukhovni  wrote:

> [...]
> Yes, but if they have the NSEC bitmap, they can follow the XNAME
> without asking again.
> [...]
> That's already handled by NSEC/NSEC3.

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

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

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

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

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


Joe

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

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

[Viktor Dukhovni]

On Tue, Jun 19, 2018 at 07:59:34AM -0700, Joe Abley wrote:

> > Petr Špaček  wrote:
> >>
> >> Given that resolver side somehow works already ...
> >> could we standardize this obvious violation of RFC 1035?
> >
> > The feature I would like is CNAME and other data (typically CNAME + MX +
> > TXT), because I have a lot of deeply hierarchial subdomains in my main
> > zone. CNAME at apex does not need to be (and I think should not be treated
> > as) a special case.

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

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

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

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

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

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

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

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

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

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

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

Yes.

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

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

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

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

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

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

That's already handled by NSEC/NSEC3.

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

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

-- 
Viktor.

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

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

[Evan Hunt]

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

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

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

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

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

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

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

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

[John R Levine]

On Sat, 23 Jun 2018, Evan Hunt wrote:

Either way we end up importing all of the failure modes of a recursive
server into an authoritative one.


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


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



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


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


Regards,
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] abandoning ANAME and standardizing CNAME at apex

[Evan Hunt]

On Fri, Jun 22, 2018 at 03:18:43PM -0400, John R Levine wrote:
> > Minor clarification here: ANAME doesn't require the authoritative server
> > itself to do recursion; it requires it to have access to a reursive
> > server.
> 
> I suppose, but that seems to me a distinction without a difference. 
> Either way we end up importing all of the failure modes of a recursive 
> server into an authoritative one.

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

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

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

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

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

[Paul Vixie]

神明達哉 wrote:

At Fri, 22 Jun 2018 16:00:51 -0400,
Paul Vixie  wrote:
...

Either way we end up importing all of the failure modes of a recursive
server into an authoritative one.

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


Also +1.  I've always thought there's no point in standardizing
ANAME-kind of thing unless its ultimate goal includes the
resolver-side support.  ...


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


--
P Vixie

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

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

[Mark Andrews]

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

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

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

-- 
Mark Andrews

> On 23 Jun 2018, at 06:08, Tony Finch  wrote:
> 
> The problem with SRV (and MX) is that you can’t tell what an empty additional 
> section means. (By “you” I mean anything in the resolver chain: app, stub, 
> recursor, etc.)
> 
> If the  records are missing, does that mean there aren’t any? Does it 
> mean they were not cached? Does it mean the server chose not to provide them 
> for some other reason?
> 
> If you want to find out, you have to make a follow-up query to get a clear 
> answer, so you have spent two round trips instead of one. And hopefully your 
> recursive server omitted the  because it has an ncache entry so you get a 
> quick answer, but that’s unlikely if the auth server didn’t provide  and 
> the resolver didn’t eagerly go chasing (which they don’t) and you are an 
> early adopter of SRV so no one else filled the ncache for you.
> 
> This can (in theory) be fixed with DNSSEC, but the additional section 
> processing rules have to be changed so that they require the nonexistence 
> proof when records are missing, and of course stubs and apps have to be 
> changed to understand the NSEC(3) records.
> 
> Mail servers generally regard additional sections as too unreliable to be 
> useful, and take the simpler slower approach of making all the queries 
> explicitly. It works for them because they are not especially worried about 
> latency.
> 
> Because of all this I can sympathize with browser authors to some extent; on 
> the other hand, if they had adopted SRV before it was too late, we might have 
> done more to fix these problems in the last 22 years. (eg an EDNS option to 
> disambiguate missing additional records, maybe.)
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at
> ___
> 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] abandoning ANAME and standardizing CNAME at apex

[神明達哉]

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

> >> Minor clarification here: ANAME doesn't require the authoritative server
> >> itself to do recursion; it requires it to have access to a reursive
> >> server.
> >
> > I suppose, but that seems to me a distinction without a difference.
> > Either way we end up importing all of the failure modes of a recursive
> > server into an authoritative one.
>
> +1. authority servers cannot be coerce-able into doing work, whether
> it's computation, memory allocation, or external transactions like RDNS.

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

--
JINMEI, Tatuya

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

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

[Tony Finch]

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

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

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

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

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

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

John R Levine wrote:

On Fri, 22 Jun 2018, Evan Hunt wrote:

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


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


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


--
P Vixie

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

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

[Shumon Huque]

On Fri, Jun 22, 2018 at 3:27 PM Warren Kumari  wrote:

> On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman  wrote:
>
>>
>> With additional-from-cache (default on), BIND will return address of
>> target of SRV if it is already in cache. The second RTT will get
>> amortized. It won't take a lot to make it fetch and return the target
>> too, if it isn't found in cache.
>>
>>
> ​Ah, fair nuff.
> I had tested this against a local bind instance, but didn't think to
> manually trigger the target lookup to get it into the cache.
>
> After doing so, it does indeed stuff it in the additional section.
>
> I'm not sure if my host (OS X) will make use of it, but that's a local
> issue...
>
> W
>
>
I just tested Google Public DNS, Cloudflare DNS, and OpenDNS.

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

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

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

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

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

[Warren Kumari]

On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman  wrote:

> On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote:
> > On Fri, Jun 22, 2018 at 8:57 AM Joe Abley  wrote:
> >
> > > On 19 Jun 2018, at 17:03, Ray Bellis  wrote:
> > >
> > > > On 19/06/2018 17:44, Tony Finch wrote:
> > > >
> > > >> SRV should have been part of the fix (and it was invented early
> > > >> enough to be!) but it wasn't a complete fix without support from the
> > > >> application protocols.
> > > >
> > > > AIUI, a large part of the supposed issue with SRV was the inertia of
> the
> > > > installed base of browsers that wouldn't know how to access them.
> > > >
> > > > Ironically the proposed fix seems to require upgrades to the
> > > > installed base of one of the most important network infrastructure
> > > > services on the planet.
> > > >
> > > > Meanwhile, a very large portion of the installed base of web browsers
> > > > gets automatically and silently upgraded every month or so...
> > >
> > > I think so long as there's a fallback for clients that don't yet have
> SRV
> > > implemented (e.g. publish A/ RRSets at the same owner name as the
> SRV
> > > RRSet, and specify the behaviour by SRV-compliant servers in the event
> that
> > > both are present) this is not a plausible engineering argument.
> > >
> > > Processing an SRV might require additional DNS lookups to get name ->
> SRV
> > > -> SRV target -> address, but that's a one-time hit per TTL and I think
> > > it's a stretch to paint that as definitely a problem. Modelling is
> required
> > > and worst cases remain to be understood.
> > >
> >
> > ​It certainly is the ​case that a number of browser / large web
> properties
> > have stated that an additional DNS lookup is a price that they are not
> > willing to pay, especially for something not "critical".
> >
> > I believe that this also would require firing off simultaneous lookups
> for
> > SRV along with the A and  (or, even worse, firing off a SRV, waiting
> > for the "nooerror" error and *then* trying for the A / ) and waiting
> > for the long tail before you even know of you need to resolve the target.
>
> With additional-from-cache (default on), BIND will return address of
> target of SRV if it is already in cache. The second RTT will get
> amortized. It won't take a lot to make it fetch and return the target
> too, if it isn't found in cache.
>
>
​Ah, fair nuff.
I had tested this against a local bind instance, but didn't think to
manually trigger the target lookup to get it into the cache.

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

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

W



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

; <<>> DiG 9.11.1-P3 <<>> -t srv _xmpp-server._tcp.crab.im @localh

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

[John R Levine]

On Fri, 22 Jun 2018, Evan Hunt wrote:

specified version of ANAME, and it avoids the ANAME ugliness of making
authoritative servers do recursive lookups.


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


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


Regards,
John Levine, 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] abandoning ANAME and standardizing CNAME at apex

[Mukund Sivaraman]

On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote:
> On Fri, Jun 22, 2018 at 8:57 AM Joe Abley  wrote:
> 
> > On 19 Jun 2018, at 17:03, Ray Bellis  wrote:
> >
> > > On 19/06/2018 17:44, Tony Finch wrote:
> > >
> > >> SRV should have been part of the fix (and it was invented early
> > >> enough to be!) but it wasn't a complete fix without support from the
> > >> application protocols.
> > >
> > > AIUI, a large part of the supposed issue with SRV was the inertia of the
> > > installed base of browsers that wouldn't know how to access them.
> > >
> > > Ironically the proposed fix seems to require upgrades to the
> > > installed base of one of the most important network infrastructure
> > > services on the planet.
> > >
> > > Meanwhile, a very large portion of the installed base of web browsers
> > > gets automatically and silently upgraded every month or so...
> >
> > I think so long as there's a fallback for clients that don't yet have SRV
> > implemented (e.g. publish A/ RRSets at the same owner name as the SRV
> > RRSet, and specify the behaviour by SRV-compliant servers in the event that
> > both are present) this is not a plausible engineering argument.
> >
> > Processing an SRV might require additional DNS lookups to get name -> SRV
> > -> SRV target -> address, but that's a one-time hit per TTL and I think
> > it's a stretch to paint that as definitely a problem. Modelling is required
> > and worst cases remain to be understood.
> >
> 
> ​It certainly is the ​case that a number of browser / large web properties
> have stated that an additional DNS lookup is a price that they are not
> willing to pay, especially for something not "critical".
> 
> I believe that this also would require firing off simultaneous lookups for
> SRV along with the A and  (or, even worse, firing off a SRV, waiting
> for the "nooerror" error and *then* trying for the A / ) and waiting
> for the long tail before you even know of you need to resolve the target.

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

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

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

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

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

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

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

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

[muks@jurassic ~]$ 

Mukund

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

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

[Warren Kumari]

On Fri, Jun 22, 2018 at 8:57 AM Joe Abley  wrote:

> On 19 Jun 2018, at 17:03, Ray Bellis  wrote:
>
> > On 19/06/2018 17:44, Tony Finch wrote:
> >
> >> SRV should have been part of the fix (and it was invented early
> >> enough to be!) but it wasn't a complete fix without support from the
> >> application protocols.
> >
> > AIUI, a large part of the supposed issue with SRV was the inertia of the
> > installed base of browsers that wouldn't know how to access them.
> >
> > Ironically the proposed fix seems to require upgrades to the
> > installed base of one of the most important network infrastructure
> > services on the planet.
> >
> > Meanwhile, a very large portion of the installed base of web browsers
> > gets automatically and silently upgraded every month or so...
>
> I think so long as there's a fallback for clients that don't yet have SRV
> implemented (e.g. publish A/ RRSets at the same owner name as the SRV
> RRSet, and specify the behaviour by SRV-compliant servers in the event that
> both are present) this is not a plausible engineering argument.
>
> Processing an SRV might require additional DNS lookups to get name -> SRV
> -> SRV target -> address, but that's a one-time hit per TTL and I think
> it's a stretch to paint that as definitely a problem. Modelling is required
> and worst cases remain to be understood.
>

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

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

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

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

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

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



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

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

W


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


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Tue, Jun 19, 2018 at 03:02:12PM -0400, John Levine wrote:
> Agreed but it doesn't seem all that much less work than a well
> specified version of ANAME, and it avoids the ANAME ugliness of making
> authoritative servers do recursive lookups.

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

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

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

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

[Joe Abley]

On 19 Jun 2018, at 17:03, Ray Bellis  wrote:

> On 19/06/2018 17:44, Tony Finch wrote:
> 
>> SRV should have been part of the fix (and it was invented early
>> enough to be!) but it wasn't a complete fix without support from the
>> application protocols.
> 
> AIUI, a large part of the supposed issue with SRV was the inertia of the
> installed base of browsers that wouldn't know how to access them.
> 
> Ironically the proposed fix seems to require upgrades to the
> installed base of one of the most important network infrastructure
> services on the planet.
> 
> Meanwhile, a very large portion of the installed base of web browsers
> gets automatically and silently upgraded every month or so...

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

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

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


Joe


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

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

[Paul Vixie]

tjw ietf wrote:

With all of you here.

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


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


--
P Vixie

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

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

[Mark Andrews]

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

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

-- 
Mark Andrews

On 20 Jun 2018, at 19:40, Jan Včelák  wrote:

>> It's also their intransigence re: SRV which has caused the CNAME at the
>> Apex issue.   CNAME was *never* the right answer for doing application
>> level indirection in HTTP space.
> 
> SRV also trades CNAME at apex for wildcard names support. There is a
> plenty of services that employ wildcards to provide customized site
> for each user. For instance, userxyz.popularservice.test can be
> resolved via *.popularservice.test but equivalent setup with SRV would
> require _https._tcp.*.popularservice.test to work as a wildcard.
> 
> ___
> 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] abandoning ANAME and standardizing CNAME at apex

[Ray Bellis]

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

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

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

Ray

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

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

[Jan Včelák]

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

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

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

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

[Mark Andrews]

> On 20 Jun 2018, at 12:06 pm, Paul Ebersman  wrote:
> 
> bellis> AIUI, a large part of the supposed issue with SRV was the
> bellis> inertia of the installed base of browsers that wouldn't know how
> bellis> to access them.
> 
> drc> I thought the more fundamental problem was the additional latency
> drc> caused by the second lookup since SRV specified domain names as
> drc> targets.
> 
> You're not mis-remembering this. I hear this from the major browser
> folks every time we mention SRV. We may or may not think this isn't
> relevent (or that dozens of embedded objects are way slower to load on a
> web page) but it doesn't matter. If browser folks believe this and won't
> change, we aren't likely to convince them if we haven't by now.
> 
> SRV is a technically cleaner solution that will never get deployed...
> 
> While I understand cautions about changing CNAME, legacy issues,
> etc. I've come more and more to the camp that we lost this argument
> years ago and we should just let server software folks allow CNAME at
> apex and be done.
> 
> This is DNSOP. Operational. The world wants CNAME at apex. Let's give it
> to them.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

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

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

Mark
-- 
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] abandoning ANAME and standardizing CNAME at apex

[Paul Ebersman]

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

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

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

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

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

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

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

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

[Mark Andrews]

> On 20 Jun 2018, at 8:56 am, Paul Vixie  wrote:
> 
> Neither. There were additional data rules to mostly prevent a second lookup, 
> and even in those days, browsers cached hostname to address mappings.
> 
> Browsers didn't adopt because srv didn't solve geo or topology optimization. 
> For a design change of this size, more payback was needed.
> -- 
> Paul Vixie
> 

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

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

> - Original Message -
> From: David Conrad 
> Sent: 2018-06-19 - 18:44
> To: Ray Bellis 
> Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
> 
>> On Jun 19, 2018, at 2:03 PM, Ray Bellis  wrote:
>>> AIUI, a large part of the supposed issue with SRV was the inertia of the
>>> installed base of browsers that wouldn't know how to access them.
>> 
>> I thought the more fundamental problem was the additional latency caused by 
>> the second lookup since SRV specified domain names as targets.
>> 
>> But maybe I’m misremembering.
>> 
>> Regads,
>> -drc
>> 
>> ___
>> 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

-- 
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] abandoning ANAME and standardizing CNAME at apex

[Mark Andrews]

> On 20 Jun 2018, at 8:44 am, David Conrad  wrote:
> 
> On Jun 19, 2018, at 2:03 PM, Ray Bellis  wrote:
>> AIUI, a large part of the supposed issue with SRV was the inertia of the
>> installed base of browsers that wouldn't know how to access them.
> 
> I thought the more fundamental problem was the additional latency caused by 
> the second lookup since SRV specified domain names as targets.

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

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

> But maybe I’m misremembering.
> 
> Regads,
> -drc
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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] abandoning ANAME and standardizing CNAME at apex

[Paul Vixie]

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

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

- Original Message -
From: David Conrad 
Sent: 2018-06-19 - 18:44
To: Ray Bellis 
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

> On Jun 19, 2018, at 2:03 PM, Ray Bellis  wrote:
>> AIUI, a large part of the supposed issue with SRV was the inertia of the
>> installed base of browsers that wouldn't know how to access them.
> 
> I thought the more fundamental problem was the additional latency caused by 
> the second lookup since SRV specified domain names as targets.
> 
> But maybe I’m misremembering.
> 
> Regads,
> -drc
> 
> ___
> 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] abandoning ANAME and standardizing CNAME at apex

[David Conrad]

On Jun 19, 2018, at 2:03 PM, Ray Bellis  wrote:
> AIUI, a large part of the supposed issue with SRV was the inertia of the
> installed base of browsers that wouldn't know how to access them.

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

But maybe I’m misremembering.

Regads,
-drc

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

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

[Tony Finch]

Ray Bellis  wrote:
> On 19/06/2018 17:44, Tony Finch wrote:
>
> > SRV should have been part of the fix (and it was invented early
> > enough to be!) but it wasn't a complete fix without support from the
> > application protocols.
>
> AIUI, a large part of the supposed issue with SRV was the inertia of the
> installed base of browsers that wouldn't know how to access them.

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon, Rockall, Malin: Cyclonic, becoming west 5 or 6, decreasing 3 or 4 for
a time. Rough, occasionally moderate. Rain, fair later. Moderate or poor,
occasionally good later.

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

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

[Ray Bellis]

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

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

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

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

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

Ray

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

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

[Ondřej Surý]

Oh, what about this?

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

:-)

O.
--
Ondřej Surý
ond...@isc.org

> On 19 Jun 2018, at 15:18, Petr Špaček  wrote:
> 
> Hello dnsop,
> 
> beware, material in this e-mail might cause your head to explode :-)
> 
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
>  is is deployed on the Internet.
> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>  already have code to cope with the "impossible" case of CNAME at the
>  apex and deal with it in ways which do not break stuff on resolver
>  side.
> - Authoritative servers of vendors named above refuse to serve CNAME at
>  apex.
> - There are CDNs etc. which allow users to create CNAME at apex
>  no matter what the standards and "normal" servers say and do.
> (We have found out this because Knot Resolver is missing hacks for CNAME
> at apex and users complain that "it works with every other resolver".)
> 
> 
> Take a deep breath!
> 
> 
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
> 
> It is very clear violation of the standard, but almost everyone found
> his way around it using different hacks. These hacks are not going away
> because all the CDNs just don't care about standards so we will have
> to maintain this code no matter what a great solution we will invent for 
> future. I.e. adding ANAME will just increase complexity because CNAME at apex 
> will be there for a long time (if not forever).
> 
> I personally do not like this but it seems better to think though
> corner cases in code we already have in production (i.e. think through 
> current hacks for CNAME at apex) instead of inventing new things like ANAME 
> (or whatever else).
> 
> Opinions? Tomatoes? Can it work? If not, why not?
> 
> -- 
> Petr Špacek  @  CZ.NIC
> 
> ___
> 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] abandoning ANAME and standardizing CNAME at apex

[Matthew Pounsett]

On 19 June 2018 at 15:02, John Levine  wrote:

> In article  mail.gmail.com> you write:
> >This sounds like a lot of work and likely to cause camel indigestion.
>
> Agreed but it doesn't seem all that much less work than a well
> specified version of ANAME, and it avoids the ANAME ugliness of making
> authoritative servers do recursive lookups.
>
> But even after all that work, CNAME + other data is still not quite going
to work, because there's an install base for which the behaviour is
unspecified and ambiguous.  CNAME + other data fails in indeterminate ways
depending on which recursive implementation you happen to query for it.

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

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

[Joe Abley]

> On 19 Jun 2018, at 15:02, John Levine  wrote:
> 
> In article 
>  you 
> write:
>> This sounds like a lot of work and likely to cause camel indigestion.
> 
> Agreed but it doesn't seem all that much less work than a well
> specified version of ANAME, and it avoids the ANAME ugliness of making
> authoritative servers do recursive lookups.

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

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


Joe



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

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

[John Levine]

In article  
you write:
>This sounds like a lot of work and likely to cause camel indigestion.

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



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

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

[Tony Finch]

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

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

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

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

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

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

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

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

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

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

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole: South 4 or 5, becoming variable 3. Moderate, occasionally rough in west.
Drizzle, fog patches. Moderate, occasionally very poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Anthony Eden]

On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan  wrote:

>
>
> Petr Špaček 于2018年6月19日周二 下午9:19写道：
>
>> Hello dnsop,
>>
>> beware, material in this e-mail might cause your head to explode :-)
>>
>> This proposal is based on following observations:
>> - It seems that DNS protocol police lost battle about CNAME at apex,
>>is is deployed on the Internet.
>> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>>already have code to cope with the "impossible" case of CNAME at the
>>apex and deal with it in ways which do not break stuff on resolver
>>side.
>> - Authoritative servers of vendors named above refuse to serve CNAME at
>>apex.
>> - There are CDNs etc. which allow users to create CNAME at apex
>>no matter what the standards and "normal" servers say and do.
>> (We have found out this because Knot Resolver is missing hacks for CNAME
>> at apex and users complain that "it works with every other resolver".)
>>
>>
>> Take a deep breath!
>>
>>
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
>>
>> It is very clear violation of the standard, but almost everyone found
>> his way around it using different hacks. These hacks are not going away
>> because all the CDNs just don't care about standards so we will have
>> to maintain this code no matter what a great solution we will invent for
>> future. I.e. adding ANAME will just increase complexity because CNAME at
>> apex will be there for a long time (if not forever).
>>
>> I personally do not like this but it seems better to think though
>> corner cases in code we already have in production (i.e. think through
>> current hacks for CNAME at apex) instead of inventing new things like
>> ANAME (or whatever else).
>>
> I think ANAME RR is hard to compatible with many old version resolvers.
> If there are mutiple ANAME RR at compatible resolvers, authoritatives may
> not know that resolvers will choose which A RR for client response.
>
> ANAME can ease apex CNAME configuration, maybe a work round is that
> authoritatives directly return A RR to resolvers (but not ANAME RR).
>

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


>
>> Opinions? Tomatoes? Can it work? If not, why not?
>>
>> --
>> Petr Špacek  @  CZ.NIC
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> --
> 致礼  Best Regards
>
> 潘蓝兰  Pan Lanlan
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>


-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Erik Nygren]

On Tue, Jun 19, 2018 at 11:24 AM, Ray Bellis  wrote:

> On 19/06/2018 15:43, tjw ietf wrote:
>
> > I find it personally appalling we can spend so many cycles injecting
> > dns into http but we can’t be bothered to fix what end users want.
>
> It's the HTTP folks that are putting most of those cycles into DNS into
> HTTP.
>
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue.   CNAME was *never* the right answer for doing application
> level indirection in HTTP space.
>


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

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

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

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

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

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

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

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

[Jared Mauch]

> On Jun 19, 2018, at 11:24 AM, Ray Bellis  wrote:
> 
> On 19/06/2018 15:43, tjw ietf wrote:
> 
>> I find it personally appalling we can spend so many cycles injecting
>> dns into http but we can’t be bothered to fix what end users want.
> 
> It's the HTTP folks that are putting most of those cycles into DNS into
> HTTP.
> 
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue.   CNAME was *never* the right answer for doing application
> level indirection in HTTP space.

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

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

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

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

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

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

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

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

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

[Ray Bellis]

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

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

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

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

Ray

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

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

[Joe Abley]

On Jun 19, 2018, at 10:20, Tony Finch  wrote:

> Petr Špaček  wrote:
>>
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
>
> The feature I would like is CNAME and other data (typically CNAME + MX +
> TXT), because I have a lot of deeply hierarchial subdomains in my main
> zone. CNAME at apex does not need to be (and I think should not be treated
> as) a special case.

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

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

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

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

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

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

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

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

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


Joe

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

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

[Lanlan Pan]

Petr Špaček 于2018年6月19日周二 下午9:19写道：

> Hello dnsop,
>
> beware, material in this e-mail might cause your head to explode :-)
>
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
>is is deployed on the Internet.
> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>already have code to cope with the "impossible" case of CNAME at the
>apex and deal with it in ways which do not break stuff on resolver
>side.
> - Authoritative servers of vendors named above refuse to serve CNAME at
>apex.
> - There are CDNs etc. which allow users to create CNAME at apex
>no matter what the standards and "normal" servers say and do.
> (We have found out this because Knot Resolver is missing hacks for CNAME
> at apex and users complain that "it works with every other resolver".)
>
>
> Take a deep breath!
>
>
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
>
> It is very clear violation of the standard, but almost everyone found
> his way around it using different hacks. These hacks are not going away
> because all the CDNs just don't care about standards so we will have
> to maintain this code no matter what a great solution we will invent for
> future. I.e. adding ANAME will just increase complexity because CNAME at
> apex will be there for a long time (if not forever).
>
> I personally do not like this but it seems better to think though
> corner cases in code we already have in production (i.e. think through
> current hacks for CNAME at apex) instead of inventing new things like
> ANAME (or whatever else).
>
I think ANAME RR is hard to compatible with many old version resolvers.
If there are mutiple ANAME RR at compatible resolvers, authoritatives may
not know that resolvers will choose which A RR for client response.

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

>
> Opinions? Tomatoes? Can it work? If not, why not?
>
> --
> Petr Špacek  @  CZ.NIC
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[tjw ietf]

With all of you here. 

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

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

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

> On Jun 19, 2018, at 10:20, Tony Finch  wrote:
> 
> Petr Špaček  wrote:
>> 
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
> 
> The feature I would like is CNAME and other data (typically CNAME + MX +
> TXT), because I have a lot of deeply hierarchial subdomains in my main
> zone. CNAME at apex does not need to be (and I think should not be treated
> as) a special case.
> 
> As I understand it, in the RFC 883 era, CNAME was allowed to coexist with
> other records, but that led to consistency problems. eg, if you have a
> CNAME cached for a particular name, and you get a query for MX at the same
> name, do you go and ask the CNAME's owner or its target for the MX? And do
> you get a different answer to the MX query when you don't have a CNAME
> cached?
> 
> My guess is that it was hard to fix this at the time because the semantics
> of negative cache entries was not well developed (e.g. RFC 1034 section
> 4.3.4 says it was still a new and experimental feature). For
> CNAME-with-siblings to work, a resolver needs to remember whether it
> already asked for the other data, for each RR type. 1980s caches couldn't
> do this, so CNAMEs were made exclusive instead.
> 
> I think the resolver's algorithm for handling CNAMEs can be updated to
> allow CNAME-with-siblings and preserve compatibility. There will be some
> latency cost for later queries that can no longer immediately follow the
> CNAME shortcut. NSEC/NSEC3 records could be used to eliminate this cost.
> 
> I'm much less sure about whether it's possible to publish
> CNAME-with-siblings in a reliably compatible way. I would feel a lot more
> comfortable with an ANAME implementation that copies the sibling records
> from the target to the owner when the zone is published or signed.
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Trafalgar: Cyclonic, mainly northeasterly in northwest, 5 to 7. Slight or
> moderate until later in southeast, otherwise moderate or rough. Thundery
> showers, fog patches later. Moderate or good, occasionally very poor later.
> ___
> 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] abandoning ANAME and standardizing CNAME at apex

[Tony Finch]

Petr Špaček  wrote:
>
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?

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

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

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

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

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic, mainly northeasterly in northwest, 5 to 7. Slight or
moderate until later in southeast, otherwise moderate or rough. Thundery
showers, fog patches later. Moderate or good, occasionally very poor later.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] abandoning ANAME and standardizing CNAME at apex

[Petr Špaček]

Hello dnsop,

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

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


Take a deep breath!


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

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


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


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

--
Petr Špacek  @  CZ.NIC

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