[DNSOP] draft-tale-dnsop-serve-stale

[Ralf Weber]

Moin!

As the mic line was closed after Mark, and I didn’t have anything new 
to say meaning I support the draft but don’t like the EDNS options 
before Mark spoke I use email to comment on Marks comments.


We already have a mechanism where the Authority tells the resolver how 
long to cache stuff it’s TTL and we have in pretty much all modern 
resolvers mechanisms to cap the lower and upper bounds of that, which 
means we occasionally ignore that. Serve-stale just adds to that. Having 
a new knob where the authority tells the resolvers on how long to serve 
stale that then will be ignored/capped just increases complexity with no 
benefit.


Also if you integrated the serve stale with prefetching the actual 
timers visible to the users go down to zero as you probably already 
recursed before the record expired and didn’t get the answer. Maybe 
you should note that in the timer section.


So long
-Ralf

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

[DNSOP] Protocol Action: 'A Root Key Trust Anchor Sentinel for DNSSEC' to Proposed Standard (draft-ietf-dnsop-kskroll-sentinel-17.txt)

[The IESG]

The IESG has approved the following document:
- 'A Root Key Trust Anchor Sentinel for DNSSEC'
  (draft-ietf-dnsop-kskroll-sentinel-17.txt) as Proposed Standard

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Warren Kumari, Ignas Bagdonas and Terry
Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/





Technical Summary

   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user and third parties to determine the trusted key
   state for the root key of the resolvers that handle that user's DNS
   queries.  Note that this method is only applicable for determining
   which keys are in the trust store for the root key.

Working Group Summary

This document has had a short history, and came about while working with ICANN 
on
  the KSK rollover process, as a way to assist tracking the addition and 
removal of DNSSEC
  keys. 

Document Quality

There are two different implementations of the design. 

Personnel

Document Shepherd: Tim Wicinski 

Responsible Area Director: Terry Manderson


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

Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

[Dave Lawrence]

Thanks very much for the review, Mukund!  Puneet has already
incorporated the editorial feedback into the GitHub copy.

Mukund Sivaraman writes:
>>  "It is predicated on the observation that authoritative server
>>   unavailability can cause outages even when the underlying data 
>>   those servers would return is typically unchanged."
> 
> While reading this, I wonder whether the last sentence was meant to be
> written as: "It is predicated on the observation that zone data returned
> by authoritative nameservers during a resolver refresh would typically
> be unchanged."

I agree that it's a reasonable rephrasing, and I'm wondering if you
see that there's a practical difference.  Not that I'm particularly
wed to the original text, just wondering if I'm missing something
either in grammar or semantics that makes the rewrite superior.

> >issues, and so on.  If the recursive server is unable to contact the
> >authoritative servers for a name but still has relevant data that has
> 
> s/for a name/for a query/

Puneet made this change, but I'll observe that since names are how
authoritative servers get delegated, I think "servers for a name" is an
acceptable, natural way to refer to the process.

> It is a curious thing why it was decided that [TTL] values with the
> high order bit set are not clamped but set to zero. Possibly because
> it can be thought that such high values are bogus and assumed to be
> made in error, and so a resolver should attempt to re-query such
> records instead of caching them for a very long time. OTOH, one can
> think the same of a TTL=2147483647 answer too. :P

Yeah, I don't know the reasoning and haven't searched the dnsext
archives to see if there was discussion on it back in the mid-90s when
the treat-it-as-zero clarification was decided.  Neither zero not 2^31
seem like good ideas really, and the issue will be in the presentation
to dnsop today.

> This option seems to me too complicated to generate, parse and make use
> of. RRs are re-ordered very late during message rendering in some DNS
> implementations, and updating this syntax in the EDNS option just looks
> too painful. It does not appear parsing (by resolvers) will be easy
> either, and whether this fine granularity in determining staleness is
> generally useful.

I do agree that it is somewhat more complicated, but I'm not sure
about "too complicated".  My thinking when I first offered it is that
if I'm using an option for diagnostic purposes, I want explicit
information returned.  So for something like "dig +any +edns-stale
example.com" (or whatever) when I'm debugging, I can count off the
indices well enough.

I would not expect automated systems that receive the option to really
care much about specifically what RRSets were stale, if they were
concerned about staleness at all.  And if they do care ... they can
count off the indices well enough too.

Here's another fun idea, to specifically identify the relevant parts
of the message:  name compression pointers!  Okay, okay ... yeah it
makes me feel a little skeevy too.  

On the other hand you could also iterate over each name/type with
either recursion disabled or the other EDNS option, so there's that
way of dealing with diagnostics too.

> Would it be better to limit fetches by the resolver for 30 seconds,
> while still returning TTL=0 answers?

It's an interesting though, but besides my general wariness of TTL 0
records I do note that this would mean keeping more state in the
resolver than it currently has to keep, and when I think about how I'd
implement that in BIND at least there's a fair bit of complexity there.

> Do all implementations mentioned earlier supporting the idea of this
> draft attempt to refresh stale data before serving it? Does this draft
> prescribe if resolvers SHOULD/MUST do so? Because the two approaches
> result in quite different behaviors.

To the best of my knowledge, no, though hopefully I've missed news on
an update to Unbound.  My understanding about how Unbound does it's
feature is that it's basically "shoot first and ask questions later".
That is, I think it'll use any data from the cache first, stale or
not, before trying the resolution.   That's part of the reason that I
wrote explicitly in the draft about honoring the intent of the TTL and
using stale data only in unusual circumstances.

> I think some implementations of this draft do not implement the client
> response timer, and so waiting for the query resolution timer (which may
> be a large duration) may result in application getaddrinfo() timeouts.

That would circumvent pretty much the whole intent to add resiliency
for clients waiting for answers.

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

Re: [DNSOP] Minimum viable ANAME

[Brian Dickson]

Paul Vixie wrote:

> Ray Bellis wrote:
>
> On 21/09/2018 20:12, Dan York wrote:
>
>
> I do think this is a path we need to go.  We need *something* like
> CNAME at the apex.  Either CNAME itself or something that works in the
> same way but might have a different name.
>
> [...]
>
> i think that makes HTTP as fast in terms of round trips as SRV is.
>
>
>Also, the presence of the Port field in an SRV record is incompatible
>with the "Same Origin" security policy enforced by web browsers and
>in practise the load-balancing / fallback capabilities of the SRV
>record are not widely used either, ...
>
> so use "0" for the port number, and don't include more than one SRV RR.
>
>
>
> there's no benefit to accompany the cost of this proposal compared to re-use
> of existing code points which are already broadly implemented.
>
>
>
So, the counter-arguments (or better, facts) are:

   - The existing code points (SRV etc), for whatever reason, are not being
   used (fact)
   - Providing Ray's "http" solution, enforces the equivalent of "use '0'
   for the port number", implicitly (fact)
   - The cost is extremely low, i.e. adding the new code point to authority
   servers with no new logic or RDATA format required (argument or fact)

IMHO, opposing http on the basis of extremely marginal development cost and
no operational cost (as a differential comparison to SRV), and otherwise on
the vague assertion that the browser folks won't use it, isn't helpful.

At worst, it gets adopted and fails to make significant deployment.

At best, it gets adopted and deployed and used with significant uptake,
especially in the CDN vendor space, and everybody wins.

It's a lot better than ANAME, and I think we do a disservice to ourselves
as a DNS community, if we do anything other than put our collective support
into it, preferably unanimously.

I see getting http adopted and deployed, and fixing the single major
web-specific deficiency in DNS, as critical to attempting to head off DoH,
which is the biggest bugbear at the moment.

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

Re: [DNSOP] Minimum viable ANAME

[Mark Andrews]

> On 5 Nov 2018, at 2:06 pm, Paul Vixie  wrote:
> 
> 
> 
> Mark Andrews wrote:
>> 
>>> On 4 Nov 2018, at 7:01 pm, Paul Vixie  wrote:
> ...
>>> that would be a mistake. we are hitting for average here not power
>>> -- the behaviour to optimize for is whatever's most common. if the
>>> SRV is used, the  or A RRsets will be fetched, and thus cached.
>>> if the SRV is only used once, that caching effort will be wasted.
>>> if the SRV is used many times, then the dominant use case will be
>>> that the additional data is found in cache because the client
>>> caused this to be so.
>> 
>> The main objection to SRV was the double RTT to the recursive server.
>> Fetching the address records before returning will speed up the sites
>> that are not talked to regularly and will not slow down the sites
>> that are talked to regularly as the values will already be in cache.
> 
> i'll try again differently. such a fetch would add logic branches and
> state and network information, to no purpose whatsoever.


> if the stub who asked the SRV question does not receive the addresses it 
> needs in additional data, it will query for them. that will put those 
> addresses in cache, so that on subsequent same-SRV questions, it will be 
> present.

And that requires 2 RTT’s from the client which, despite being only a few ms 
normally, has been enough for the HTTP folks to refuses to deploy anything 
other than CNAME for ~2 decades now.

> if the SRV is never fetched again, then there's no win to be had.

The win is loosing the extra RTT from the stub to the recursive server.

> popular SRV answers will be overwhelmingly dominated by the second and 
> subsequent responses, which will all include the additional data.

> a recursive should only fetch what it needs for its own operations, so for 
> example if it knows an NS RR but not the corresponding  or A RR, it can 
> fetch those. and for qname minimization it can make the requisite diagnostic 
> queries. but it should NOT fetch just because it lacks additional data. the 
> stubs should cause those fetches.

And then we get back to the complaints from the HTTP side saying the SRV takes 
longer than CNAME, which is valid for the first lookup if you don’t fetch the 
additional records before returning.

> -- 
> P Vixie

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

[DNSOP] FYI - in v6OPS today - IPv6-Ready DNS/DNSSSEC Infrastructure

[Dan York]

FYI, in the v6ops working group right now in Meeting 1 on the 7th floor, there 
is a draft that will be discussed (after two other drafts are discussed) that 
is:


IPv6-Ready DNS/DNSSSEC Infrastructure

https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00

Abstract:

   This document defines the timing for implementing a worldwide
   IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
   global IPv6-only deployment.

   A key issue for this, is the need for a global support of DNSSEC and
   DNS64, which in some scenarios do not work well together.  This
   document states that any DNSSEC signed resources records should
   include a native IPv6 resource record as the most complete and
   expedient path to solve any deployment conflict with DNS64 and DNSSEC.

Slides: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-v6ops-ipv6-ready-dnsdnssec-infrastructure-00

The key point is the conflict between DNS64 and DNSSEC, as described in the 
draft here:

DNS64 ([RFC6147]) is a widely deployed technology allowing hundreds
   of millions of IPv6-only hosts/networks to reach IPv4-only resources.
   DNSSEC is a technology used to validate the authenticity of
   information in the DNS, however, as DNS64 ([RFC6147]) modifies DNS
   answers and DNSSEC is designed to detect such modifications, DNS64
   ([RFC6147]) can break DNSSEC in some circumstances.

I'm passing it along in case others were, like me, not paying attention to this 
draft.

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/

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

[DNSOP] Volunteers for Minutes Takers and Jabber Scribes

[Benno Overeinder]

Hi DNSOP WG,

We are looking for volunteers to take minutes and jabber scribe for the
DNSOP WG meeting this afternoon 13:50-15:50.

Please send an email to dnsop-chairs or reply directly.

Otherwise we'll just have to ask at the start of the meeting.

Thank you very much,

-- Suzanne/Tim/Benno

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Dave Crocker]

On 11/4/2018 7:08 PM, Ray Bellis wrote:

On 05/11/2018 09:56, Dave Crocker wrote:
So I immediately went to add it and then realized that doing this 
cleanly will take an entry for each RR...


Why not this?

++--++
| RR Type    | _NODE NAME   | REFERENCE  |
++--++
| *  | _example | [TBD]  |



Well, that's two of you making close to the same suggestion (though the 
version Erik suggested seems a bit more complete.


Absent objections, I'll add that.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Ray Bellis]

On 05/11/2018 09:56, Dave Crocker wrote:


Clever suggestion.  Seems like obvious benefit with no obvious detriment.

So I immediately went to add it and then realized that doing this 
cleanly will take an entry for each RR...


Why not this?

++--++
| RR Type| _NODE NAME   | REFERENCE  |
++--++
| *  | _example | [TBD]  |

Ray


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Erik Kline]

On Mon, 5 Nov 2018 at 09:56, Dave Crocker  wrote:
>
> On 11/4/2018 6:28 PM, Erik Kline wrote:
> > One thing I missed earlier (and please forgive me if this was already
> > discussed), was whether or not _example* should be reserved in the
> > table in draft-ietf-dnsop-attrleaf-15#section-4.3.
> >
> > Basically, is there any value in reserving _example* for future RFCs
> > to use (ones that don't care about the specific _foo label but apply
> > to all such labels in some way).
>
>
> Clever suggestion.  Seems like obvious benefit with no obvious detriment.
>
> So I immediately went to add it and then realized that doing this
> cleanly will take an entry for each RR...
>
> Not so sure we want to do that?

Perhaps doable via a {see section #X.Y} e.g.:

  | *   | _example* {see #X.Y} | [this doc]  |

X.Y Reserved _example* label
For use in RFC documentation describing behaviour applicable to
any label associate with any RR type. More awesome text also goes
here.

I'm not sure about the strictness requirements for this kind of table for IANA.

Also, this doesn't address whether it's an actually useful suggestion. :-)

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

Re: [DNSOP] Minimum viable ANAME

[Paul Vixie]

Mark Andrews wrote:



On 4 Nov 2018, at 7:01 pm, Paul Vixie  wrote:



that would be a mistake. we are hitting for average here not power
-- the behaviour to optimize for is whatever's most common. if the
SRV is used, the  or A RRsets will be fetched, and thus cached.
if the SRV is only used once, that caching effort will be wasted.
if the SRV is used many times, then the dominant use case will be
that the additional data is found in cache because the client
caused this to be so.


The main objection to SRV was the double RTT to the recursive server.
Fetching the address records before returning will speed up the sites
that are not talked to regularly and will not slow down the sites
that are talked to regularly as the values will already be in cache.


i'll try again differently. such a fetch would add logic branches and 
state and network information, to no purpose whatsoever.


if the stub who asked the SRV question does not receive the addresses it 
needs in additional data, it will query for them. that will put those 
addresses in cache, so that on subsequent same-SRV questions, it will be 
present.


if the SRV is never fetched again, then there's no win to be had.

popular SRV answers will be overwhelmingly dominated by the second and 
subsequent responses, which will all include the additional data.


a recursive should only fetch what it needs for its own operations, so 
for example if it knows an NS RR but not the corresponding  or A RR, 
it can fetch those. and for qname minimization it can make the requisite 
diagnostic queries. but it should NOT fetch just because it lacks 
additional data. the stubs should cause those fetches.


--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Dave Crocker]

On 11/4/2018 6:28 PM, Erik Kline wrote:

One thing I missed earlier (and please forgive me if this was already
discussed), was whether or not _example* should be reserved in the
table in draft-ietf-dnsop-attrleaf-15#section-4.3.

Basically, is there any value in reserving _example* for future RFCs
to use (ones that don't care about the specific _foo label but apply
to all such labels in some way).



Clever suggestion.  Seems like obvious benefit with no obvious detriment.

So I immediately went to add it and then realized that doing this 
cleanly will take an entry for each RR...


Not so sure we want to do that?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

[DNSOP] FYI - in v6OPS today - IPv6-Ready DNS/DNSSSEC Infrastructure

[Dan York]

FYI, in the v6ops working group right now in Meeting 1 on the 7th floor, there 
is a draft that will be discussed (after two other drafts are discussed) that 
is:

IPv6-Ready DNS/DNSSSEC Infrastructure

https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00 


Abstract:

   This document defines the timing for implementing a worldwide
   IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
   global IPv6-only deployment.

   A key issue for this, is the need for a global support of DNSSEC and
   DNS64, which in some scenarios do not work well together.  This
   document states that any DNSSEC signed resources records should
   include a native IPv6 resource record as the most complete and
   expedient path to solve any deployment conflict with DNS64 and DNSSEC.

Slides: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-v6ops-ipv6-ready-dnsdnssec-infrastructure-00
 


The key point is the conflict between DNS64 and DNSSEC, as described in the 
draft here:

DNS64 ([RFC6147]) is a widely deployed technology allowing hundreds
   of millions of IPv6-only hosts/networks to reach IPv4-only resources.
   DNSSEC is a technology used to validate the authenticity of
   information in the DNS, however, as DNS64 ([RFC6147]) modifies DNS
   answers and DNSSEC is designed to detect such modifications, DNS64
   ([RFC6147]) can break DNSSEC in some circumstances.

I'm passing it along in case others were, like me, not paying attention to this 
draft.

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/ 


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Erik Kline]

Dave (others),

One thing I missed earlier (and please forgive me if this was already
discussed), was whether or not _example* should be reserved in the
table in draft-ietf-dnsop-attrleaf-15#section-4.3.

Basically, is there any value in reserving _example* for future RFCs
to use (ones that don't care about the specific _foo label but apply
to all such labels in some way).

Sorry for the last-minute distraction,
-Erik
On Sun, 4 Nov 2018 at 03:23,  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>
> Title   : DNS Scoped Data Through "Underscore" Naming of 
> Attribute Leaves
> Author  : Dave Crocker
> Filename: draft-ietf-dnsop-attrleaf-15.txt
> Pages   : 14
> Date: 2018-11-03
>
> Abstract:
>Formally, any DNS resource record may occur under any domain name.
>However some services use an operational convention for defining
>specific interpretations of an RRset, by locating the records in a
>DNS branch, under the parent domain to which the RRset actually
>applies.  The top of this subordinate branch is defined by a naming
>convention that uses a reserved node name, which begins with an
>_underscore.  The underscored naming construct defines a semantic
>scope for DNS record types that are associated with the parent
>domain, above the underscored branch.  This specification explores
>the nature of this DNS usage and defines the "DNS Global Underscore
>Scoped Entry Registry" with IANA.  The purpose of the Underscore
>registry is to avoid collisions resulting from the use of the same
>underscore-based name, for different services.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-15
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-15
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] Minimum viable ANAME

[Mark Andrews]

> On 4 Nov 2018, at 7:01 pm, Paul Vixie  wrote:
> 
> 
> 
> Ray Bellis wrote:
>> 
>> 
>> On 04/11/2018 08:05, Ray Bellis wrote:
>> 
>>> AFAIK, BIND does not currently do this.  That said, MarkA has a patch
>>> that supports it, so we do know it's possible.
>> 
>> Correction - BIND *does* do this, but only for address records that are
>> already in the cache. If the  for the target is in the cache, but
>> the A record isn't, that's all you'll get.
> 
> that's all we need. it's all we do for MX and NS additional data, too.
> 
>> Mark's patch forces BIND to pre-fill the cache with the A and 
>> records for the SRV target before replying.
> 
> that would be a mistake. we are hitting for average here not power -- the 
> behaviour to optimize for is whatever's most common. if the SRV is used, the 
>  or A RRsets will be fetched, and thus cached. if the SRV is only used 
> once, that caching effort will be wasted. if the SRV is used many times, then 
> the dominant use case will be that the additional data is found in cache 
> because the client caused this to be so.

The main objection to SRV was the double RTT to the recursive server.  Fetching 
the address records before returning will speed up the sites that are not 
talked to regularly and will not slow down the sites that are talked to 
regularly as the values will already be in cache.

> -- 
> P Vixie
> 
> ___
> 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

[DNSOP] CNAME at apex - a website publisher perspective - Re: Fundamental ANAME problems

[Dan York]

> 
> On Nov 4, 2018, at 8:02 PM, Ray Bellis  wrote:
> 
>  A lot of the whole "CNAME at the Apex" issue arises because lots of 
> marketing people don't want end users to have to type *or see* the www prefix.


Exactly. As many of us traveled through various airports to get to Bangkok, 
there were many large advertisements on walls, banners, and everywhere else. 

The people who make those ads have a limited amount of space in which to put 
the companies contact info. If they remove "www." and just use "example.com", 
they can make the font size larger and the text more visible. This is just one 
of the reasons people in marketing / communications teams want to drop the 
"www".  (A similar reason of spacing is why you almost never see anyone 
including "http(s)://" in advertisements.)

As someone managing a team responsible for multiple websites, and who has 
people asking about dropping the "www" on different sites, I tried to capture 
the business requirements as they relate to CDN usage in this draft I just 
submitted today:



Name:   draft-york-dnsop-cname-at-apex-publisher-view
Revision:   00
Title:  CNAME at apex - a website publisher perspective
Document date:  2018-11-05
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-york-dnsop-cname-at-apex-publisher-view-00.txt
 

Status: 
https://datatracker.ietf.org/doc/draft-york-dnsop-cname-at-apex-publisher-view/ 

Htmlized:   
https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-00 

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-york-dnsop-cname-at-apex-publisher-view
 


Abstract:
  There has been a large amount of discussion about the "CNAME at apex"
  issue within the DNSOP Working Group.  This draft provides the
  perspective of one publisher of multiple websites about why CNAME-
  like functionality is desirable at the apex of a domain zone.



Dan

P.S. Right now we do have "internetsociety.org" redirecting to 
"https://www.internetsociety.org";, which uses a CNAME to go out to a CDN. In 
our case we are okay with people seeing "www" in the address bar.  Other 
organizations want the www to disappear completely - and I have had that 
request for some of our other sites.

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

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : A Common Operational Problem in DNS Servers - Failure 
To Respond.
Authors : M. Andrews
  Ray Bellis
Filename: draft-ietf-dnsop-no-response-issue-12.txt
Pages   : 25
Date: 2018-11-04

Abstract:
   The DNS is a query / response protocol.  Failing to respond to
   queries, or responding incorrectly, causes both immediate operational
   problems and long term problems with protocol development.

   This document identifies a number of common kinds of queries to which
   some servers either fail to respond or else respond incorrectly.
   This document also suggests procedures for TLD and other zone
   operators to apply to help reduce / eliminate the problem.

   The document does not look at the DNS data itself, just the structure
   of the responses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-12
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-no-response-issue-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] DNS without Fragmentation (UDP and DF bit set)

[Mark Andrews]

Firstly you are insane to recommend dropping PTB’s.  That will break lots of 
things
including TCP.

Secondly we could just use a well known TSIG key and have the authoritative 
servers add
it to their configuration today, especially the root and TLDs servers.  The 
recursive
servers could also add the key for root and TLD servers they know have 
installed the
the well known key.  This is easy to test with tools like dig.

e.g.

key "." {
algorithm hmac-sha256;
secret "AAA=";
};

server  { key “.”; };

Auto configuring the key can come in the next revision of the software and 
would handle
FORMERR/NOTIMP (STD-13 errors) and NOTAUTH/BADKEY (expected error from TSIG 
implementations)
by falling back to non-TSIG queries when talking to a server using the well 
known key without
it being explicitly configured.  If using the well known key with a server is 
explicitly
configured fallback to non-TSIG messages would not occur.

Yes, some implementations may need to add TSIG support.  The majority already 
support
TSIG, it is just a matter of configuring the key.

https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt

Below are typical error responses as well as a one from a server with the key 
configured.

% dig soa . @b.root-servers.net -y 
hmac-sha256:.:AAA=
;; Couldn't verify signature: tsig indicates error

; <<>> DiG 9.13.1 <<>> soa . @b.root-servers.net -y 
hmac-sha256:.:AAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTAUTH, id: 42384
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: af1f5afe5008ef28ac57d36f5bdf617e3364284dfc68df28 (good)
;; QUESTION SECTION:
;.  IN  SOA

;; TSIG PSEUDOSECTION:
.   0   ANY TSIGhmac-sha256. 1541366142 300 0  
42384 BADKEY 0 

;; Query time: 178 msec
;; SERVER: 199.9.14.201#53(199.9.14.201)
;; WHEN: Mon Nov 05 08:15:42 AEDT 2018
;; MSG SIZE  rcvd: 96
;; WARNING -- Some TSIG could not be validated

% 

% dig soa . @a.root-servers.net -y hmac-sha256:.: 
AAA=
;; Couldn't verify signature: expected a TSIG or SIG(0)

; <<>> DiG 9.13.1 <<>> soa . @a.root-servers.net -y 
hmac-sha256:.:AAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 38857
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

;; Query time: 279 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Nov 05 08:14:45 AEDT 2018
;; MSG SIZE  rcvd: 12
;; WARNING -- Some TSIG could not be validated

% 

% dig soa . @127.0.0.1 -y 
hmac-sha256:.:AAA= 
;; BADCOOKIE, retrying.

; <<>> DiG 9.13.1 <<>> soa . @127.0.0.1 -y 
hmac-sha256:.:AAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63699
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a2986dd7ec4014f14a25b1d85bdf6805e53cda0537bd7b68 (good)
;; QUESTION SECTION:
;.  IN  SOA

;; ANSWER SECTION:
.   86400   IN  SOA a.root-servers.net. 
nstld.verisign-grs.com. 2018110401 1800 900 604800 86400

;; TSIG PSEUDOSECTION:
.   0   ANY TSIGhmac-sha256. 1541367813 300 32 
NJNkcTXIjQ4PWVc6o9RNqXIzjofXDMpTlrXCEKJ1EQ4= 63699 NOERROR 0 

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 05 08:43:33 AEDT 2018
;; MSG SIZE  rcvd: 203

% 

Mark

> On 5 Nov 2018, at 3:36 am, fujiw...@jprs.co.jp wrote:
> 
> It is time to drop fragmentation (and pMTU discovery) in DNS.
> 
> A research paper showed that there are many authoritative servers that
> accept any ICMP destination unreachable / fragmentation needed and DF
> set (pMTU response packets) and reduce packet size up to 296 bytes.
> Path MTU discovery is controlled by any attacker.  Then the authors
> sent trigger queries and did second fragmentation attack to CA's
> resolvers.
> 
>  https://dl.acm.org/citation.cfm?id=3243790
>  Domain Validation++ For MitM-Resilient PKI
>  Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, Michael Waidner
>  Fraunhofer SIT, TU Darmstadt
> 
> Proposed solution is not good. DNS with TCP transport is enough, I think.
> 
> I would like to propose to drop fragmentation and pMTU discovery in DNS.
> 
> Authoritative servers should drop ICMP fragmentation needed,
> set static EDNS buffsize 1220, and set DF bit in responses.
> 
> On resolver machines, I would l

[DNSOP] DNS without Fragmentation (UDP and DF bit set)

[fujiwara]

It is time to drop fragmentation (and pMTU discovery) in DNS.

A research paper showed that there are many authoritative servers that
accept any ICMP destination unreachable / fragmentation needed and DF
set (pMTU response packets) and reduce packet size up to 296 bytes.
Path MTU discovery is controlled by any attacker.  Then the authors
sent trigger queries and did second fragmentation attack to CA's
resolvers.

  https://dl.acm.org/citation.cfm?id=3243790
  Domain Validation++ For MitM-Resilient PKI
  Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, Michael Waidner
  Fraunhofer SIT, TU Darmstadt

Proposed solution is not good. DNS with TCP transport is enough, I think.

I would like to propose to drop fragmentation and pMTU discovery in DNS.

Authoritative servers should drop ICMP fragmentation needed,
set static EDNS buffsize 1220, and set DF bit in responses.

On resolver machines, I would like to drop fragmented response packets.
We can write IP filter that drop fragmented packet to resolvers,
but it is not beautiful.

--
Kazunori Fujiwara, JPRS 

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 23:02, Paul Ebersman wrote:


Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
that this is what they want, since they are largely driving all of this?

I'd guess that they would prefer this in the auth layer, where they own
or have contractual relationship with the zone owner.

Yes, as DNS software folks, we'd like to keep auth doing auth and have
only recursive doing lookups but I'm not sure that solves the problem in
a way that will be accepted.


My expectation is that this would work for them exactly the way a CNAME 
does (i.e. via EDNS Client Subnet or similar) but without the restrictions.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Paul Ebersman]

ray> Architecturally, the important part of my proposal is that
ray> resolution of the A and  records is done *at the recursive
ray> layer* of the DNS, with no interference with how authoritative
ray> resolution works.

Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
that this is what they want, since they are largely driving all of this?

I'd guess that they would prefer this in the auth layer, where they own
or have contractual relationship with the zone owner.

Yes, as DNS software folks, we'd like to keep auth doing auth and have
only recursive doing lookups but I'm not sure that solves the problem in
a way that will be accepted.

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

Re: [DNSOP] Fundamental ANAME problems

[Paul Ebersman]

ray> HTTP Redirects cause the URI in the address bar to be changed.  A
ray> lot of the whole "CNAME at the Apex" issue arises because lots of
ray> marketing people don't want end users to have to type *or see* the
ray> www prefix.

ray> Those folks aren't going to stand for their nice clean
ray> "example.com" URL getting replaced with the real CDN address in the
ray> address bar.

Last I heard, they're taking care of this by taking away the address bar
completely. You and I will have to set some kind of debug mode to ever
see this. So that in and of itself isn't a deal breaker. But let's get
comment from the firefox/chrome folks. I agree with you that we're
having some productive back and forth. I think that we've learned some but
not all of each other's spaces.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Dave Crocker]

On 11/3/2018 4:55 PM, Warren Kumari wrote:

I'm also somewhat confused by the quoting in:
"In the case of the "SRV" "RR" and "URI" "RR", distinguishing among 
different types"  (and in "defining "RR"s that might" ) - I'm not sure 
if it is intentional, but it doesn't align with much of the rest of the 
formatting, and is (IMO) confusing around the first part.)


I used spanx too liberally, because it looked nice in the html version 
on my machine, and I didn't realize what it did for the text version. My 
use matched what I'm seeing in some bibxml entries, but you are right 
that it doesn't look right in some of the sequences here.


So I've removed most spanx occurrences in the source.



Also nit (I think):
Adam Roach, Petr Špaček, Ondřej Sury


This is a dilemma. The characters produce appropriate text in html, to 
show his actual name.  The xml2rfc text rendering engine produces this 
silliness and I'm inclined to class it as a bug in the engine.


If there is an established practice for working around that bug, to 
produce the proper characters in html and an 'acceptable' alternative in 
text, please let me know and I'll fix it.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

[Bjørn Mork]

Section 4.3 claims RFC7671 reserves "_dane":


" ++--++
  | RR Type| _NODE NAME   | REFERENCE  |
  ++--++
..
  | TLSA   | _dane| [RFC7671]  |
"

I can't see any support of this in RFC7671.

I assume the misunderstanding comes from a couple of examples using a
"_dane" label. But this is an arbitrary choice, and not an attempt to
reserve a name.  For example from RFC7671 section 5.2:

"  Some domains may prefer to avoid the operational complexity of
   publishing unique TLSA RRs for each TLS service.  If the domain
   employs a common issuing CA to create certificates for multiple TLS
   services, it may be simpler to publish the issuing authority as a TA
   for the certificate chains of all relevant services.  The TLSA query
   domain (TLSA base domain with port and protocol prefix labels) for
   each service issued by the same TA may then be set to a CNAME alias
   that points to a common TLSA RRset that matches the TA.  For example:

   ; Two servers, each with its own certificate, that share
   ; a common issuer (TA).
   ;
   www1.example.com.IN A 192.0.2.1
   www2.example.com.IN A 192.0.2.2
   _443._tcp.www1.example.com.  IN CNAME tlsa._dane.example.com.
   _443._tcp.www2.example.com.  IN CNAME tlsa._dane.example.com.
   tlsa._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c14...
"


It is obvious from this that "tlsa._dane.example.com." is a placeholder
alias, and not reserving "tlsa" or "_dane" labels.

The consistent choice of "tlsa._dane" in the RFC7671 examples might have
contributed to this confusion.  Something to keep in mind for future DNS
label examples.  Use your fantasy :-)



Bjørn

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 18:16, Brian Dickson wrote:


Is the apex thing an optimization only (i.e. is it acceptable that
the mechanism for apex detection not be 100% effective)? I think
that's the input needed before it makes sense to go down any
particular branch of design work, by either the http folks or the dns
folks.


It's not a question of apex *detection*, it's that DNS simply doesn't
allow for the *provisioning* of a CNAME record at the apex.

Nor can you put a CNAME alongside any other "useful" DNS records, so you 
can't, for example, have a zone that looks like this:


$ORIGIN example.com
@IN SOA   ...
 IN NS...
company-division IN MX
company-division IN CNAME 

[I should perhaps put that as an example in the draft]


Is knowing when something is (or is at least expected to be) the
apex, one of the fundamental drivers on this issue?


No, the mechanism is general purpose and could be used for any
domain name that requires redirection (at the DNS / hostname level) to a
hostname that does not match the domain name in the URI.

[snipping irrelvant stuff about effective TLD lists]


Related, follow-on question: If that new record type were pointing to
the owner name (i.e. itself), or otherwise signaled that an A/ at
the owner name should be used, would having the authority server
return the A/ records as well fix the multiple-lookups issue,
i.e. not require the lookup of the A/ records if the new record
type was not present?


Although it's not documented as such yet (and I should, because it's an
important clarifaction) an HTTP record that points to itself would be an
error, in the same way that a CNAME loop would be.

Architecturally, the important part of my proposal is that resolution of
the A and  records is done *at the recursive layer* of the DNS, with
no interference with how authoritative resolution works.

[the only exception is if EDNS Client Subnet is in use, but that's a
case where the authoritatives already know how to generate the right
answer for any particular subnet]


[snippage]



I anticipate both the new record type and additional processing,
would be less problematic on authority operators than ANAME.


The new record type has *no* implications at all for authority operators
other than in their provision systems, and since it uses the same RDATA
format as a PTR or CNAME record the implications there should be minimal.

It adds more additional processing, but does not change the general 
model of mostly-static zone data, which plays nice with DNSSEC.


There's *no* additional processing done in authoritatives.  I suppose
theoretically if the target happens to be on the same server as the
owner name than an authority might also include the A and  records,
but it's not specified that way at the moment.
For the recursives, the incremental change is the same additional 
processing as authority servers (additional data if empty/self-ref, 
possibly with extra queries, or CNAME-type processing.)


Roughly, except per above, this is the *only* incremental change in the
DNS infrastructure.   The other necessary change is in the HTTP clients
themselves, which IMHO is how it should be.


Also: would this new record type (and query/response logic) make
sense to use everywhere, not just at a zone apex?


Yes, per above.


I think there would be nothing implicitly difficult in making it
universal, on both the authority and recursive servers. For the
recursive servers, I don't think they even have the ability to
distinguish whether a name is apex or not (!!). For authorities, I
don't think there's anything intrinsically apex-ish about what is
required, so it would probably be less work to support the new record
type anywhere.


It's not apex specific at all, but its design is specifically intended 
to address the CNAME at the apex issue.


kind regards,

Ray


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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 18:31, Patrik Fältström wrote:


The semantics is exactly like a CNAME + HTTP Redirect.


The latter part is what I expected, and why I think it's a non-starter.

HTTP Redirects cause the URI in the address bar to be changed.  A lot of 
the whole "CNAME at the Apex" issue arises because lots of marketing 
people don't want end users to have to type *or see* the www prefix.


Those folks aren't going to stand for their nice clean "example.com" URL 
getting replaced with the real CDN address in the address bar.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Patrik Fältström]

On 4 Nov 2018, at 11:10, Ray Bellis wrote:

> -1

:-)

> What are the semantics of this?

The semantics is exactly like a CNAME + HTTP Redirect.

Provisioning is like any provisioning in the DNS, with the advantage that you 
can delegate the prefix:ed domain just like you can do with any _tcp and 
similar prefix domain to whatever administrative entity that manage the web. 
You can that way separate the DNS and web administration between two different 
entities.

That some people want a record at the apex is a big mistake as one that way 
must mix explicitly the administration of that name between two entities that 
do different things.

See how well the AD delegation works where you can split the AD functionality 
from the DNS functionality by doing "the right delegations", which makes 
enterprise DNS much easier to set up than if (more) stuff is to be entered at 
the apex.

We have apex overload, and that must be taken care of.

   Patrik

> - What appears in the user's UI when the URI record completely replaces the 
> site name entered by the user?
>
> - Which domain name is the SSL cert validated against?
>
> - Which domain name appears in the HTTP Host: header?
>
> - What is the HTTP "Origin" of the resultint content,
>   and which domain's cookies are accepted / sent?
>
> - What if there's also a URI record for 'example-lb-frontend.hosting.namn.se' 
> ?
>
> - How do I provision a wildcard record for this?
>
> I see absolutely zero chance of the web community embracing this.
>
> Ray
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


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

Re: [DNSOP] Fundamental ANAME problems

[Brian Dickson]

Ray Bellis wrote:
>
> I don't think that either SRV or URI are usable for the primary use
> case, i.e. allowing a domain owner to put a record at the apex of
> their zone that points at the hostname of the web provider they want to
> use.
>
>

Is the apex thing an optimization only (i.e. is it acceptable that the
mechanism for apex detection not be 100% effective)? I think that's the
input needed before it makes sense to go down any particular branch of
design work, by either the http folks or the dns folks.

Is knowing when something is (or is at least expected to be) the apex, one
of the fundamental drivers on this issue?

Is the question of how the "effective TLD list" is maintained, published,
integrated, etc., something we could/should look closer at, or is that a
big can of worms we should stay away from? E.g. get it published by IANA,
through multiple mechanisms, and formalize the update to it through the
TLD/registry creation process at ICANN? Is it necessary to change/improve
the process, publication, ownership, etc. in order for browsers to reply on
it at a protocol level?

I.e. Rather than rely on hunting for SOA records in DNS and/or looking for
NSes for zone cuts, is making a first pass determination by looking at
whether the "authority" of the URI, aka the FQDN, is one level below an
"effective TLD"? If I have "example.com" or "example.co.jp", or "
example.com.au", and I have the current, comprehensive list of places
someone can register domains, I know that in those cases, "example" is an
apex name. Or does the solution to this problem need to handle apex names
for internal-to-a-registrant zone cuts?

Use of ETLDs could drive the initial query to be some new record type that
exists at a zone apex.
(The ETLD list gives an answer to "is it the apex" which is either "yes" or
"maybe", because zone cuts below the ETLD+1 level can exist, obviously.)

Related, follow-on question:
If that new record type were pointing to the owner name (i.e. itself), or
otherwise signaled that an A/ at the owner name should be used, would
having the authority server return the A/ records as well fix the
multiple-lookups issue, i.e. not require the lookup of the A/ records
if the new record type was not present?
(The distinction between a self-referential or empty RDATA answer, and a
NOERROR/NODATA lack of RR, would be the indicator on whether the zone owner
wanted to play nice with the optimizations. The client would probably also
need to do separate A/ queries in the NOERROR/NODATA case, since the
triggering URI would still need to its authority name to be resolved to an
address.)

I.e. :
@ NEWRRTYPE @ ; (or empty RDATA, signaling that the response needs to
include A/, and that the client should expect A/ in the response)
@ A 
@  

or
@ NEWRRTYPE www.myproviders.fqdn ; points out of zone, so no additional
data -- but client/recursive needs to chase RDATA down like it was a CNAME

I realize in this hypothetical model, both authority and recursive servers
need updates.
Or is the returning A/ on the empty/self-ref a strictly optional
optimization, and thus not a barrier to adoption?
(The client can't do a parallel query for the A/ records, because it
needs the first answer to get the name for the second query. But it can do
the queries sequentially without the assistance of the recursive.)

I anticipate both the new record type and additional processing, would be
less problematic on authority operators than ANAME.
It adds more additional processing, but does not change the general model
of mostly-static zone data, which plays nice with DNSSEC.

For the recursives, the incremental change is the same additional
processing as authority servers (additional data if empty/self-ref,
possibly with extra queries, or CNAME-type processing.)

Also: would this new record type (and query/response logic) make sense to
use everywhere, not just at a zone apex? I think there would be nothing
implicitly difficult in making it universal, on both the authority and
recursive servers. For the recursive servers, I don't think they even have
the ability to distinguish whether a name is apex or not (!!). For
authorities, I don't think there's anything intrinsically apex-ish about
what is required, so it would probably be less work to support the new
record type anywhere.

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

Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix

[Warren Kumari]

So, the new version of draft-ietf-dnsop-attrleaf-fix is posted --
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/
The diff from the previous is here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-06

I **think** that this addresses the outstanding issues (modulo some
formatting nits) -- Alissa / Adam, does this satisfy your concern?

W

On Mon, Oct 22, 2018 at 11:34 PM Adam Roach  wrote:

> On 10/19/18 7:08 AM, Warren Kumari wrote:
>
> So, there were a few documents where I was not able to quickly figure out
> which of the classes it should be placed in.
>
>
> tl;dr: my analysis is that all four of the mentioned documents should be
> removed from the list. Details below.
>
>
> RFC3861 describes how to use SRV, but it is updated by RFC6121, which
> largely says "Don't!" -- what do we do here? Update both? Just RFC3861?
> Juast RFC6121?
>
>
> That's sort of true. 3861 defines rules for _im._x and _pres._x (for
> arbitrary values of "x"), while 6121 says "don't do this for x = xmpp."
> For example, RFC 5509 builds on RFC 3861 for SIP, and it's technically
> still in effect (although the practical case is probably the same as XMPP,
> no one has produced a revision to 5509 that says as much).
>
> All of that notwithstanding, 3861 most definitely does not deal with
> "Global" underscored node names as -attrleaf- defines that term. It deals
> only with labels further down the tree. I believe it should be removed from
> the list.
>
>
> I couldn't figure out RFC3404, and RFC6011.
> Clue appreciated.
>
> RFC3404 -- Dynamic Delegation Discovery System (DDDS) Part Four: The
> Uniform Resource Identifiers (URI) Resolution Application
> Perhaps SRV? But it doesn't really seem to be underscore scoped...
>
>
> This one is quite perplexing, and I don't know how it got caught up in
> Dave's net. The character "_" appears only 12 times in this document, all
> in variable names in the pseudo-code in its appendix. Neither of the
> English words "underscore" nor "underline" appear at all.
>
> As far as I recall (and a quick skim seems to validate this), the only
> reservations DDDS makes are under "urn.arpa." and "uri.arpa." -- there
> aren't any global name reservations, with or without underscores.
>
> I think this document was included in error.
>
>
> RFC6121 -- Extensible Messaging and Presence Protocol (XMPP): Instant
> Messaging and Presence
> This updates RFC3921 and explicitly recommends against SRV.
> "Interoperability Note: RFC 3921 specified how to use the _im._xmpp and
> _pres._xmpp SRV records [IMP-SRV] as a fallback method for discovering
> whether a remote instant messaging and presence service communicates via
> XMPP. Because those SRV records have not been widely deployed, this
> document no longer specifies their use, and new implementations are not
> encouraged."
> Should this be in this list?
>
>
> RFC 6121, as you point out, only mentions _{im,pres}.xmpp as an historical
> note while deprecating its use. I believe it should also be removed.
>
>
>
> RFC3861 -- Extensible Messaging and Presence Protocol (XMPP): Instant
> Messaging and Presence
> See above. It would be SRV, but was updated by RFC6121.
>
>
> [see above]
>
>
>
> RFC6011 -- Session Initiation Protocol (SIP) User Agent Configuration
> I got confused here -- I cannot really see the underscore names here as
> anything other than a target name.
>
>
> 6011 shouldn't be updated by this document. The only underscored node
> names in that document are in non-normative examples, and they're actually
> incidental to the purpose of the example. Presumably, they're included to
> demonstrate that querying for NAPTR records can return both UA Config
> records **and** other, unrelated records, and that implementations need
> to ignore the unrelated records.
>
>
> Thanks for doing the heavy lifting on this. I think it has dramatically
> improved the document to figure out why each updated RFC is included, since
> it flushed out several that should not be.
>
> /a
>


-- 
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] Fundamental ANAME problems

[Paul Vixie]

Ray Bellis wrote:

> ... "URI RR" ...

I see absolutely zero chance of the web community embracing this.


as evidenced by RFC 8484, the web community seems to regret basing their 
work on the Internet System, and is now moving independently. this may 
mean that offering them something like "HTTP RR" which can't work better 
than SRV or URI already works, because they speciously refuse to embrace 
these working technologies, will buy you nothing.


--
P Vixie

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

Re: [DNSOP] Minimum viable ANAME

[Paul Vixie]

Ray Bellis wrote:



On 04/11/2018 08:05, Ray Bellis wrote:


AFAIK, BIND does not currently do this.  That said, MarkA has a patch
that supports it, so we do know it's possible.


Correction - BIND *does* do this, but only for address records that are
already in the cache. If the  for the target is in the cache, but
the A record isn't, that's all you'll get.


that's all we need. it's all we do for MX and NS additional data, too.


Mark's patch forces BIND to pre-fill the cache with the A and 
records for the SRV target before replying.


that would be a mistake. we are hitting for average here not power -- 
the behaviour to optimize for is whatever's most common. if the SRV is 
used, the  or A RRsets will be fetched, and thus cached. if the SRV 
is only used once, that caching effort will be wasted. if the SRV is 
used many times, then the dominant use case will be that the additional 
data is found in cache because the client caused this to be so.


--
P Vixie

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 15:05, Paul Vixie wrote:


as evidenced by RFC 8484, the web community seems to regret basing
their work on the Internet System, and is now moving independently.
this may mean that offering them something like "HTTP RR" which can't
work better than SRV or URI already works, because they speciously
refuse to embrace these working technologies, will buy you nothing.


Members of both communities had what I felt was a very productive side
meeting during the Montreal IETF, at which I also believe there was an
acceptance that both "sides" need to come together for a mutually
agreeable solution.

I don't think that either SRV or URI are usable for the primary use
case, i.e. allowing a domain owner to put a record at the apex of
their zone that points at the hostname of the web provider they want to
use.   I personally don't think that ANAME is a good solution either.

Hence my draft which I hope is a move towards that middle ground that we
can all work with.  I have already had positive feedback from some HTTP 
people, but antagonising them won't help.


Ray

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

Re: [DNSOP] Fundamental ANAME problems

[Ray Bellis]

On 04/11/2018 12:53, Patrik Fältström wrote:

On 3 Nov 2018, at 23:32, Måns Nilsson wrote:


_http._tcp.example.org. IN URI  10 20   
"https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/";

We already have this. We need not build a new mechanism.


+1


-1

What are the semantics of this?

- What appears in the user's UI when the URI record completely replaces 
the site name entered by the user?


- Which domain name is the SSL cert validated against?

- Which domain name appears in the HTTP Host: header?

- What is the HTTP "Origin" of the resultint content,
  and which domain's cookies are accepted / sent?

- What if there's also a URI record for 
'example-lb-frontend.hosting.namn.se' ?


- How do I provision a wildcard record for this?

I see absolutely zero chance of the web community embracing this.

Ray

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