Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records

[Eric Orth]

As a what-one-stub-resolver-does data point...

The resolver I'm most familiar with validates that all the CNAME records
form a single chain from the query name, and that all answer records of the
query type match the final name at the end of the CNAME chain.  If that is
not true, as in the case of this example, the entire DNS response is
rejected.  If there are any answer records with a type other than CNAME or
the query type, they are simply ignored.

On Thu, Jan 11, 2024 at 12:36 PM Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:

> Hello,
>
> We have been looking at some DNS resolvers and encountered a question:
>
> When a DNS response contains (in the answer section) records which were
> not requested, how should the resolver react to those and what should
> it return to the requesting client?
>
> For example:
>
> QUESTION:
> example.com   IN   A
> ANSWER:
> example.com   IN   CNAME  www.example.com
> www.example.com   IN   A  3600 1.2.3.4
> google.comIN   A  3600 5.6.7.8
>
> We have noticed that even with DNSSEC enabled and all records in the
> response being valid and signed, some resolvers return all records in
> the answer section to the client. Note that recursive resolvers (as
> well as network attackers on connections without integrity protection)
> can combine records from different requests to synthesize such an
> answer.
>
> Is the client responsible for identifying the requested RRSet or should
> the resolver only return the records matching the request?
> E.g. in the example above, should the client return all records in the
> answer section or just the 1.2.3.4 A record?
>
> Some clues:
>
> - It is mentioned in RFC 1034 that the resolver should
> communicate aliases (e.g. CNAMEs) to the client.
> - Even when records not belonging to a chain of CNAME records are
> removed from the answer section, simply filtering for the record type
> may not be sufficient for the client (E.g. consider a QTYPE of CNAME
> where during the resolution other CNAMEs are synthesized from DNAME
> records.)
> - DNSSEC would in some cases require checking NSEC/NSEC3 records while
> following a chain of CNAME records. This can only happen in a resolver.
>
> Thanks in advance for any responses,
>
> Thomas Bellebaum
>
> --
> M.Sc. Thomas Bellebaum
> Applied Privacy Technologies
> Fraunhofer Institute for Applied and Integrated Security AISEC
>
> Lichtenbergstraße 11, 85748 Garching near Munich (Germany)
> Tel. +49 89 32299 86 1039 <+49%2089%2032299861039>
> thomas.belleb...@aisec.fraunhofer.de
> https://www.aisec.fraunhofer.de
>
> ___
> 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] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Eric Orth]

Advertisements would be annoying, but my biggest concern with this stuff
has always been links to pages that mimic the page the user was trying to
access in the first place.  If the user types in social-network.com, I
don't trust users to not click links in the result without reading them and
go with it once they hit a page that looks like the social-network.com
login page.

On Thu, Oct 12, 2023 at 12:07 PM Tommy Pauly  wrote:

>
>
> On Oct 11, 2023, at 3:17 PM, Warren Kumari  wrote:
>
>
>
>
>
> On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone <
> Gianpaolo-Angelo.Scalone=40vodafone@dmarc.ietf.org> wrote:
>
>> I really love this draft and would like to see browser side
>> implementation for the benefit of customers user experience. Today several
>> services are implemented on top of DNS to filter malicious or unwanted
>> traffic in an effective way, but customers cannot distinguish the blocking
>> from a network error. This led to frustration or even worst put them in
>> danger: a quick solution to the "network error" is to disable the
>> protection and so be infected, or change browser. The server side
>> implementation provides all the needed information to build a great user
>> experience: in the example below I see at least 2 options
>>
>> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987 flags: qr rd ra;
>> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS:
>> version: 0, flags:; udp: 512
>> EDE: 17 (Filtered): ({ "c": [
>> https://blocking.vodafone.com/blockpage?list=malwarecc], "s": 1,"j":
>> "Malware C", "o": "Vodafone Internet Services" }) QUESTION SECTION:
>> malw.scalone.eu. IN A
>>
>> Option 1 - better user experience, some complexity to avoid security risks
>>
>> if the contact URI is trusted it is possible to present in the GUI a real
>> blocking page. The problem is that untrusted providers could use this
>> method as an attack vector. Potential solutions could be:
>> Browsers accept Exte4nded DNS Errors only from DoH servers. URI domain
>> has to be covered by DoH server certificate. There could potentially be a
>> vetting process e.g. through IANA, whereby filtering providers would need
>> to register. Only registered and approved providers would then be permitted
>> to use this method
>>
>> Option 2 - Sub-optimal user experience; however, a significant
>> improvement over today's user experience.
>>
>>  cannot open  because it
>> has been filtered by 
>> Blocking reason: 
>>
>>
>>
> Erm, can't a large amount of this already be accomplished using RFC8914
> Extended Errors. E.g:
>
> https://www.rfc-editor.org/rfc/rfc8914.html#name-extended-dns-error-code-15-
> —-
> "4.16. Extended DNS Error Code 15 - Blocked
> The server is unable to respond to the request because the domain is on a
> blocklist due to an internal security policy imposed by the operator of the
> server resolving or forwarding the query.
>
> 4.17. Extended DNS Error Code 16 - Censored
> The server is unable to respond to the request because the domain is on a
> blocklist due to an external requirement imposed by an entity other than
> the operator of the server resolving or forwarding the query. Note that how
> the imposed policy is applied is irrelevant (in-band DNS filtering, court
> order, etc.).
>
> 4.18. Extended DNS Error Code 17 - Filtered
> The server is unable to respond to the request because the domain is on a
> blocklist as requested by the client. Functionally, this amounts to "you
> requested that we filter domains like this one."
> ---
>
> Yes, it doesn't give you the HTML page, but I personally view that as a
> feature, not a bug.
> You *know* that if my coffee-shop/hotel/car-dealer has the ability to
> respond to every N-th DNS query with:
> "({ "c": [https://subaru.example.com/buy-the-new-outback.html})" or "(({
> "c": [https://www.example.com/free-donut-with-every-pumpkin-spice-latte
> .]})"
> they will.
>
> Yes, I shouldn't be trusting my coffee-shop/hotel/car-dealer's resolvers,
> but with captive-portals and similar many people do…
>
>
> Yeah, the existing error codes are quite good (and iOS and macOS natively
> support them now!), but having more details would allow this to replace
> more fully the cases where redirection occurs.
>
> I also am concerned about someone just putting advertisements or worse in
> the contact information, so there should be some control on it.
>
> Tommy
>
>
> W
>
>
>
> Thank you
>>
>> Gianpaolo
>>
>> C2 General
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] I-D Action: draft-bellis-dnsop-qdcount-is-one-01.txt

[Eric Orth]

I think this generally resolves my main concerns about the previous draft
hiding the normative changes behind all the history and justification.
Thanks for the update.

Minor remaining complaints (that I'm not going to fight over, so ignore if
you really disagree):
* I think all the stuff now in the appendix would be even better as a
separate Informational draft.  In my mind, appendix is acceptable, but
still feels like you feel it is necessary as justification for the
standards change.
* The Introduction still includes a bit of justification discussion about
ambiguity, whereas I would argue that the more pressing justification is
simply ecosystem compatibility.

On Thu, Sep 28, 2023 at 9:40 AM Joe Abley  wrote:

> Hi all,
>
> This version mainly incorporates feedback from the room at the last
> meeting and relate to document clarity; the advice is unchanged.
>
>
> Joe
>
> > On 28 Sep 2023, at 15:21, internet-dra...@ietf.org wrote:
> >
> > Internet-Draft draft-bellis-dnsop-qdcount-is-one-01.txt is now
> available. It
> > is a work item of the Domain Name System Operations (DNSOP) WG of the
> IETF.
> >
> >   Title:   In the DNS, QDCOUNT is (usually) One
> >   Authors: Ray Bellis
> >Joe Abley
> >   Name:draft-bellis-dnsop-qdcount-is-one-01.txt
> >   Pages:   7
> >   Dates:   2023-09-28
> >
> > Abstract:
> >
> >   This document clarifies the allowable values of the QDCOUNT parameter
> >   in DNS messages with OPCODE = 0 (QUERY) and specifies the required
> >   behaviour when values that are not allowed are encountered.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/
> >
> > There is also an HTMLized version available at:
> >
> https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one-01
> >
> > A diff from the previous version is available at:
> >
> https://author-tools.ietf.org/iddiff?url2=draft-bellis-dnsop-qdcount-is-one-01
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

[Eric Orth]

In the general case, you can't do anything with those bits for the same
practical reason why we can't decide to allow QDCOUNT > 1.  Too many
existing servers expect that those bits can never be validly non-zero and
will have unpredictable behavior.  It's already out-of-our-control ossified.

If we could do something with those bits (but we unfortunately can't), my
recommendation would be to use them to allow QDCOUNT > 1.  :P

On Wed, Jul 26, 2023 at 7:32 PM Mark Andrews  wrote:

>
>
> > On 27 Jul 2023, at 09:20, Brian Dickson 
> wrote:
> >
> >
> >
> > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson 
> wrote:
> > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> > the header.
> >
> > What would be interesting uses of the flow-label? Oh wait.. that's
> > right, nobody really knows at scale how to use flow-label either.
> >
> > I tend to "use it for 15 bits of signalling" because there are a lot
> > of things I wish were signalled from client to server.
> >
> > "I am new code"
> > "I am at least not ancient code"
> > "I'm the same as that other guy you saw over "
> > "I like TCP and want to do a persisting session"
> > "tell me if you are doing a|b|c|d"
> > "I like chocolate and want a pony"
> >
> > maybe the truth is, we've got 15 bits of zero in the header forever,
> amen.
> >
> > (I deliberately didn't put this in the draft- post from Ray so as not
> > to pollute an objective discussion of what it is or is not the value
> > proposition)
> >
> > clue-stick hits welcome. Avoid the stomach.
> >
> > 15 bits of entropy would maybe be a good use, particularly for short
> QNAMEs (and with QNAME minimization, that definitely applies to root and
> TLD queries).
> > That would augment or compensate for fewer bits available for 0x20
> entropy.
>
> Or root and TLD servers could just deploy DNS COOKIE.  There is no reason
> for them not to deploy
> DNS COOKIE today other than vendors not implementing it.  Time for vendors
> to pull their fingers
> out.
>
> DNS COOKIE is standards track.  It is a security fix.  Deploy it.
>
> >
> > Brian
> > ___
> > 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 <+61%202%209871%204742>  INTERNET:
> ma...@isc.org
>
> ___
> 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] Questions on DNS HTTPS/SVCB spec and deployment

[Eric Orth]

On Mon, Jul 24, 2023 at 1:14 PM Hongying Dong  wrote:

> Hello,We are researchers at the University of Virginia studying some
> aspects of the DNS HTTPS/SVCB specification and how it is deployed in
> practice. We had a few questions we are hoping you can provide the answers
> to. Primarily we are examining HTTPS right now, but if the answers can be
> generally provided for SVCB too, that would be great.* IPv4 and IPv6
> hints.
>>
>> *The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY
>> use to reach the service.  If A and  records for TargetName are locally
>> available, the client SHOULD ignore these hints. Otherwise, clients SHOULD
>> perform A and/or  queries for TargetName as in Section 3, and clients
>> SHOULD use the IP address in those responses for future connections.
>> Clients MAY opt to terminate any connections using the addresses in hints
>> and instead switch to the addresses in response to the TargetName query.
>> Failure to use A and/or  response addresses could negatively impact
>> load balancing or other geo-aware features and thereby degrade client
>> performance.*
>
> It seems to us that unless the IPv4 and IPv6 hints are kept diligently in
> sync with the actual addresses in the A and  records, this could easily
> pose operational problems in the field. The draft appears to concur and
> says clients should see if they are "locally available", and otherwise
> "SHOULD" perform A/ address lookups. If so, under what circumstances is
> it beneficial for an implementation to follow the "MAY" instruction of the
> first line in the above quoted paragraph and use the hints?
>

If a client using the hints is unworkable for a domain, then the domain can
always not include the hints.  They are there for cases where some server
might be able to do things slightly better if A/ results are used but
HTTPS hints are also acceptable, especially if the domain owner knows that
the benefit of A/ is not likely sufficient to make up for it if the
client has to do extra DNS roundtrips and deal with extra chances for DNS
failures.


> Also what does "If the A and  records for Targetname are _locally
> available_" mean? Is the expectation that HTTPS client applications run a
> local DNS cache from which this information could be extracted?
>

Yes, exactly that.  The vast majority of modern DNS clients have local
cache mechanisms.


> The  answer to the "MAY use hints" is suggested later on in this paragraph:
>>
>> *These parameters are intended to minimize additional connection latency
>> when a recursive resolver is not compliant with the requirements in Section
>> 4, and SHOULD NOT be included if most clients are using compliant recursive
>> resolvers.*
>
> First, how would a client application generally know that a recursive
> server is compliant with Section 4 (i.e. proactively fetching the A and
>  records for the HTTPS Targetname and providing them in the response)?
> Is there a proposed DNS API function that provides this information, or are
> clients expected to write custom code to parse the full response from a
> recursive server to figure this out?
>

The client only needs to look at the HTTPS response and see if it contains
the relevant A/ records.  If they are there, the client can use them
and not need to make any additional queries.  If the necessary records are
not included in the response, it means the recursive server did not query
them (or less likely, that the records do not exist).  If the client
receives the hints in a response but not A/ records, the client then
has the option between using the hints or waiting on the results for
additional A/ queries.


> Second, how would a service operator publishing HTTPS records know if most
> of their clients are using compliant recursive servers to help them make a
> decision about including IP hints? Or does this statement imply that
> everyone should deploy IP hints until the ecosystem has gained a critical
> mass of recursive servers that are compliant?
>

I believe this is mostly about ecosystem critical mass, but there may be
special cases where a domain is only used for some specific use by specific
clients where there may be more specific knowledge.


> What recursive servers today support this optimization? We've examined
> several of the public DNS resolvers (Google, Cloudflare, Quad9, and
> OpenDNS) and none of them appear to. We haven't looked at the open source
> implementations yet, but if anyone can answer that would be appreciated 
> too.Client
> implementation behavior in the field: What do existing web browsers/clients
> (e.g. Firefox, Chrome, Safari, etc) that support DNS HTTPS records do
> today? Under what conditions do they use the hints vs. query explicitly for
> address records?
>

Chrome does not yet support any cases where hints or followup queries are
necessary, only the more basic uses of HTTPS.  It's in the plans, but just
not implemented yet.  When it 

Re: [DNSOP] Private-use underscored DNS node name

[Eric Orth]

Am I interpreting the idea correctly that the goal here is to be able to
create names that are only usable as alias targets?

If so, interesting idea, but I'm not sure such a mechanism could actually
be created and widely implemented.  I don't think there's enough motivation
for all the relevant implementors to add code to block a previously-allowed
name for non-alias use or to allow a previously-disallowed name just for
alias use, so it just doesn't seem feasible unless all the implementations
are already handling underscore-prepended names the way we want and I don't
think that's the case.  Too much stuff would just allow "_private" names to
be resolved as a normal hostname, and I don't think you're going to
convince everybody that it's worth the effort to add special code to block
it.

On Tue, Jan 3, 2023 at 2:45 PM Ben Schwartz  wrote:

> Hi Jeremy,
>
> This is an interesting idea, but I think it's difficult to understand in
> the abstract.  Could you provide some example zone files for the use case
> you're considering?
>
> It sounds like you're concerned about the possibility that non-underscored
> names could be misconstrued as host names, even though they don't hold any
> address records.  However, I don't believe there is any general expectation
> that DNS names must be the names of hosts just because they are
> syntactically valid hostnames.
>
> Thanks,
> Ben
>
> On Thu, Dec 8, 2022 at 6:39 PM Jeremy Saklad  40saklad5@dmarc.ietf.org> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> BCP 222 sets out guidelines for using underscored DNS node names, which
>> are important for any record that should not be mistakenly interpreted as
>> an actual host. However, it doesn’t seem to set aside a name for private
>> use, which would be particularly helpful for deduplicating RRsets.
>>
>> As an example, draft-ietf-dnsop-svcb-https-11 suggests using AliasMode
>> HTTPS records to maintain a separation of concerns. I’ve found this helpful
>> myself, as it allows me to have the configuration for a web server and
>> single onion service in one RRset, with each of the served hostnames
>> aliasing to that.
>>
>> However, that suggestion recommends using non-underscored TargetNames,
>> which have the side-effect of incorrectly stating that the TargetName is
>> itself an origin. It would make much more sense to alias to an underscored
>> node name for this.
>>
>> Upon looking into my options, however, I can’t find any
>> standards-compliant way of actually doing that. The closest option is
>> “_example”, which doesn’t seem meant for actual use. Am I missing
>> something, or is it outright impossible to name arbitrary DNS records
>> without the possibility that future specifications ascribe unwanted meaning
>> to it?
>>
>> If I am in fact not missing anything, I propose registering “_private” as
>> a reserved node name for all RRTypes.
>> -BEGIN PGP SIGNATURE-
>>
>> iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY5J1DVYYJ2h0dHBzOi8v
>> b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw
>> NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIG1hwAP9fQoJv
>> UrWZA8GnQWK+sStyneA4t5IsTOmOSdto4wcziQD/ajah2eIyUr8rOkRoM2DveTQF
>> bl6EvRxLsQR2TjCmBQc=
>> =xghv
>> -END PGP SIGNATURE-
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Eric Orth]

I still disagree with the arguments for such a change being the ideal
behavior.  But rather than debating that further here, I will instead just
argue that I do not believe any of this rises to the level of necessity for
making technical changes at this late stage.  This is not a case of "OMG!
That clearly doesn't work", as evidenced by the fact that multiple parties
from different parts of the stack have already implemented the current
spec, and they are not overwhelmingly chiming into this thread to say it
doesn't work.

We should take the debate over this matter to a Bis proposal.

On Wed, Aug 24, 2022 at 10:14 PM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:

>
>
> On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman 
> wrote:
>
>> On Aug 24, 2022, at 5:14 PM, Brian Dickson 
>> wrote:
>> > "at this stage" is only the case due to the draft not being explicit in
>> the flow.
>>
>> Are you saying that it was explicit after WG Last Call but changed? Or
>> during IETF Last Call and was changed?
>>
>
> No, I'm saying that, as far as I can tell, the flow was never explicit,
> and that's a big part of the problem.
>
> And I'm saying that if it had been explicit, the concerns would have been
> raised at that time, rather than now.
>
> (This is, IMNSHO, the poster child for why being as clear as possible for
> actual logic flows is really important, both to implementers, and to those
> involved in the process of reviewing documents and advancing standards.)
>
> I.e. I definitely apologise that this was not caught earlier. I also don't
> think it would have been possible to catch prior to doing interoperability
> tests and discussing with developers, which is exactly what the process was
> that lead to the request to the chairs and AD.
>
>
>
>>
>> > Yes, this is a non-editorial change.
>>
>> Also called a technical change.
>>
>
> Or a technical correction of a defect. It's a change, but not an arbitrary
> change.
>
>
>>
>> > If it were limited to an editorial change, it could be handled with an
>> Errata or via a -bis document.
>>
>> Technical changes require going back at least to IETF Last Call, if not
>> WG consideration again. Bis documents are for making technical changes.
>>
>
>  once the RFC is published. And yes, while this will require those
> things, those are good things. Clarification and scrutiny are the
> responsibility of the WG and the IETF.
>
> This is an exceptional case, given that the issues are central to
> interoperability and deployability (usability by zone administrators).
>
> It is an unavoidable risk that developers take in attempting to track an
> in-progress draft prior to publication as a standards-draft RFC.
> Any change made up until the RFC is published, is something developers
> that want to be RFC-compliant need to do.
> Yes, doing development while the standard isn't complete gets software
> deployed sooner.
> The standard necessarily dictates the implementation, not vice versa. The
> copyright assignment stuff when bringing things to the IETF basically says
> that once adopted by the WG, it's a WG doc, not the original author's.
>
> I believe that, for the most part, the needed changes are code deletions
> or branching logic pruning, and as a result, de minimis.
> I also believe that the resulting client performance will be faster, more
> reliable, and less risky.
> In particular, the speculative DNS queries made in parallel can benefit
> from early abandonment. If a client receives an AliasMode response,
> outstanding queries for A/ are no longer needed. This permits a client
> to proceed faster than if the client waited until it received responses, or
> worse waited until those queries timed out.
>
> Brian
> ___
> 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] IANA Policy for SVCB

[Eric Orth]

I'm happy as long as things are still fast and easy enough to support
new/experimental/prototype usage.  I think Expert Review with the proposed
stuff for that expert to review is all reasonable for that goal.  If we
start getting into stricter bars than Expert Review, that's where we'd have
to start discussing the complexity of breaking off separate private-use and
experimental blocks with a lower bar.

On Tue, Apr 12, 2022 at 3:10 PM Erik Nygren  wrote:

> I think Expert Review makes sense (with the expert reviewing the SHOULD
> around the specification).
>
> On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson  wrote:
>
>> I agree with Tommy.
>>
>> Selecting an expert who is able to recognize when wider review might help
>> is a far lower bar than the one Ray suggests might be necessary.
>>
>> On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
>> > If this space is not extensible from non-IETF RFCs, we’ll have missed
>> > the mark. The space is designed to be large (65K) to allow new work to
>> > easily use this extensibility. We don’t need to be too conservative
>> > with this space.
>> >
>> > I disagree that there wouldn’t be good experts — we have authors of the
>> > document who have seen it through, and we have more people using this
>> > RR and gaining expertise.
>> >
>> > Expert review is the right balance here.
>> >
>> > Tommy
>> >
>> >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy 
>> wrote:
>> >>
>> >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis  wrote:
>> >>> I am concerned that the set of Expert Reviewers necessary to handle
>> SVCB
>> >>> needs to have both expert DNS experience *and* detailed knowledge of
>> the
>> >>> SVCB model for this to work.
>> >>>
>> >>> I am not sure there's anybody who fits that criteria.
>> >>
>> >> Specification Required also assumes a community that can produce them,
>> which presumably contains the right experts.
>> >>
>> >> Are we actually moving toward IETF Review here?
>> >>
>> >> -MSK
>> >> ___
>> >> DNSOP mailing list
>> >> DNSOP@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/dnsop
>> >
>> > ___
>> > DNSOP mailing list
>> > DNSOP@ietf.org
>> > https://www.ietf.org/mailman/listinfo/dnsop
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> 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] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Eric Orth]

If you split presentation format records into one record per SvcParam, that
necessitates either changing the wire format to match or structuring the
presentation and wire formats fundamentally differently with a translation
to merge those records into a single record for the wire format.  What the
records are and the relations between them is a fundamental part of the
wire format.



On Wed, May 19, 2021 at 6:01 PM Brian Dickson 
wrote:

>
>
> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman 
> wrote:
>
>> Are these still just idle ideas you are tossing out (as you indicated
>> earlier), or meant to be serious proposals? If the latter, what is the
>> significant improvement over the current draft? I ask because it feels like
>> you are suggesting moving the inherent complexity of the semantics of SCVB
>> around, but not noticeably reducing it overall. Unless there is a
>> significant reduction in complexity, I don't see the value of grinding on
>> this further. (I say this as someone who is not happy with the current
>> level of complexity of the semantics, but don't see a way to reduce it.)
>>
>> --Paul Hoffman
>
>
> It is meant to be a serious proposal.
> The improvement is in the clarity and parse-ability of the HTTPS record in
> zone file format, including reducing the complexity of the HTTPS-specific
> semantics, without changing the actual wire format semantics or complexity
> per se.
>
> I'm working on the details of that, but it will necessarily be its own
> work-in-progress. I hope to get something stable based on feedback... I
> don't expect to get it 100% right on the first pass.
>
> The first pass should hopefully illustrate the benefits at least, and
> justify keeping list activity ongoing.
>
> Brian
> ___
> 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] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Eric Orth]

On Wed, May 12, 2021 at 4:44 PM Brian Dickson 
wrote:

>
>
> On Wed, May 12, 2021 at 12:28 PM Eric Orth  40google@dmarc.ietf.org> wrote:
>
>>
>> I also oppose allowing multiple aliases within an RRSet.  This would
>> allow aliasing trees, unreasonably exploding the complexity/performance
>> scope of query followup logic in stubs and recursives.  In practice, I
>> don't think this would actually make multiple aliases useful because I
>> would then expect many stub/recursive implementations (including mine) to
>> only make followup queries down a single branch of the alias tree.
>>
>
> The current version of the document only addresses DNS issues which result
> from actual attacks. There do not appear to be any logic branches on
> timeouts (or other similar failures) other than to abandon the SVCB
> handling.
>
> Having multiple AliasMode records within an RRset (with either the same or
> different Priority) would provide an avenue for dealing with resolution
> failure - which is one of the main reasons for any CDN customer to use
> multiple CDNs, i.e. to avoid single points of failure (which includes the
> DNS component of the CDN).
>
> I think it would be reasonable to restrict the handling of SVCB processing
> to allow multiple AliasMode records in a single RRset in the resolution of
> SVCB, i.e. once a branch has been reached, follow the preferred branch
> using the existing logic, and either abandon the other branch after the
> first successful step in the resolution of the preferred branch, or
> alternatively holding the entry point to the second branch (as a backup)
> until the first branch's resolution has succeeded to the point of returning
> ServiceMode records (and if resolution failure occurs before that point,
> switching to the next branch).
> This would be the equivalent to keeping a simple list, rather than needed
> to handle full recursion tree-walking logic.
>

Is the primary concern here resolution failures or connection failures? I
suppose this could help recover from resolution failures, but I would be
surprised if that is the concern in mind when people are configuring
multiple redundant CDNs.

For connection failures, such decisions can only be made on the client
making the connection attempts, so it's not clear to me what behavior we
should suggest for recursives.  I'm already concerned enough with
persuading recursives to do the support here that we want, so unless a
recursive operator/implementor speaks up here to explain why it wouldn't be
an issue, I'm guessing we wouldn't see a lot of full support if we say they
must/should fully follow all branches.

A client could use RFC 8305 (or similar logic) to attempt connections via
one alias branch and move to others (separately queried) only on connection
failures.  But my client doesn't currently support RFC 8305, so we're
unable to reasonably and performantly use separate branches conditionally
on connection failures.  Assuming many other clients would be in a similar
position, I worry that even if we make multiple aliases possible, this
would create a defacto standard that only a single alias is allowed if you
want your domain to be compatible with all the clients.


>
> This is a suggestion only, but I think it has merit.
> The current examples of "juggling CNAMEs" isn't really practical,
> especially given TTLs on CNAMEs.
> Having multiple RRs in an RRSET with various Priority values achieves the
> equivalent function without requiring the domain owner to engage in active
> management of DNS records. The latter approach is at best naive, at worst
> harmful to deployment and use of SVCB in the real world.
>
> I am a big fan of SVCB, and want it to succeed, so my comments should be
> viewed in that light, please. This is about improving the proposal only.
>
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Eric Orth]

On Wed, May 12, 2021 at 4:28 PM Brian Dickson 
wrote:

>
>
> On Wed, May 12, 2021 at 12:28 PM Eric Orth  40google@dmarc.ietf.org> wrote:
>
>> I have no strong opinions on any of the discussions regarding escaping in
>> presentation mode because I don't have much involvement in dealing with
>> presentation mode of DNS records.  The client I work with parses wire
>> format directly into its internal structures.
>>
>> From my wire-format-only perspective...
>>
>> I strongly oppose breaking out the key/value pairs of the current
>> proposal into separate records within an RRSet.  The "independently
>> meaningful" records argument in favor of per-endpoint records isn't just
>> some small nice-to-have but is actually rather crucial to avoiding
>> inconsistent/missing-data issues that could easily become security issues.
>> Per-key/value records opens things up to too much error-proneness where the
>> separate records get cached separately (with potentially differing TTLs),
>> so there's a lot more room for clients to end up receiving/handling only
>> some parts of endpoint data without a clear indication that other parts are
>> missing.  Could be much more problematic than just getting a partial view
>> of the endpoint options.  Easily becomes a security issue, e.g. when a
>> client gets most of the records for an endpoint but misses the record
>> containing the ECH config.
>>
>
> Sincere apologies in advance for any offense you may take from this.
>
> However...
>
> You are completely mistaken in this concern.
>
> The DNS RFCs collectively, and in their entirety, forbid any of the
> following:
>
>- Breaking up RRSETs
>- Having RRSETs with Resource Records that do not have identical TTLs
>- Servers sending anything that does not comply with this
>- Clients accepting responses with any of these problems (clients are
>required to ignore such responses)
>
> In short, none of the things you present as concerns can occur if the
> resolvers or authority servers are at all RFC-compliant.
>
There is no need to design your protocol to defend against these issues, at
> all.
> (This is documented clearly in RFC2181, and further referenced for clarity
> purposes in the DNS Terminology RFC, RFC8499.)
>
> Responses including partial RRsets are as unlikely (and as illegal) as a
> response to a query for SVCB being a TXT record saying "I'm a teapot".
>

Agreed that there is no such issue with either wire format if all parties
in the ecosystem are bug-free and RFC-compliant.  But with all the many
layers and implementations caching DNS, I have a low level of trust that
everyone has read and understood all applicable RFCs and is capable of
applying it all correctly in an implementation.  Thus I still stand by my
point that one wire format here is much more susceptible to potential
caching bugs than the other, and that such issues, while arguably just as
"illegal", are way more likely than receiving a spurious teapot record
(that would be a very impressive bug).


>
> Please take it as read that queries for an RRTYPE will always return an
> RRSET which is complete and has uniform TTL values.
>
> Concerns over MITM tampering of results can be addressed by use of DNSSEC,
> where the RRSIG (signature) is over the complete RRSET and included with
> the RRSET itself. It is literally impossible for a MITM to tamper with a
> signed response which will pass the validation by the recipient.
>
> A MITM can just as easily modify the singular RR containing all the
> key/value pairs together, so the concern is either moot or invariant
> regarding single vs multiple records.
>
> IMNSHO, the wire-format discussion should not be excluded as a result of
> your concerns, if the RRSET integrity is your only concern.
>
> Sincerely,
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Eric Orth]

I have no strong opinions on any of the discussions regarding escaping in
presentation mode because I don't have much involvement in dealing with
presentation mode of DNS records.  The client I work with parses wire
format directly into its internal structures.

>From my wire-format-only perspective...

I strongly oppose breaking out the key/value pairs of the current proposal
into separate records within an RRSet.  The "independently meaningful"
records argument in favor of per-endpoint records isn't just some small
nice-to-have but is actually rather crucial to avoiding
inconsistent/missing-data issues that could easily become security issues.
Per-key/value records opens things up to too much error-proneness where the
separate records get cached separately (with potentially differing TTLs),
so there's a lot more room for clients to end up receiving/handling only
some parts of endpoint data without a clear indication that other parts are
missing.  Could be much more problematic than just getting a partial view
of the endpoint options.  Easily becomes a security issue, e.g. when a
client gets most of the records for an endpoint but misses the record
containing the ECH config.

I also oppose allowing multiple aliases within an RRSet.  This would allow
aliasing trees, unreasonably exploding the complexity/performance scope of
query followup logic in stubs and recursives.  In practice, I don't think
this would actually make multiple aliases useful because I would then
expect many stub/recursive implementations (including mine) to only make
followup queries down a single branch of the alias tree.

On Wed, May 12, 2021 at 3:42 AM Peter van Dijk 
wrote:

> On Tue, 2021-05-11 at 18:26 +0200, libor.peltan wrote:
> >
> > May I be wrong, but I think that name, type, class and TTL are not
> repeated in one RRSet with multiple RData. Not in wire format and not
> necessarily even in zonefile. (?)
>
> Zone files allow you to leave some of those out on subsequent records. The
> wire format does not:
> https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.3
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SVCB without A/AAAA records at the service name

[Eric Orth]

My preference would be the change in 289.  Maximizes keeping things open
for future protocols rather than attempting to predict the needs of the
protocols.

On Fri, Jan 15, 2021 at 2:02 PM Ben Schwartz  wrote:

> FWIW, I think this is really an editorial question.  The SVCB draft lays
> out how we expect SVCB to be used initially, but there are very few
> constraints on how some future protocol specification could make use of the
> RR type.  That includes the various possible fallback behaviors.
>
> I'm happy to adjust the text for clarity on this point.  Here are two
> alternatives for how to clarify the text:
>
> 1. Specify the expected behavior of future SVCB-reliant protocols (which
> do not yet exist):
> https://github.com/MikeBishop/dns-alt-svc/pull/288
>
> 2. Clarify that this section's recommendations are only defaults, and
> future protocols can do whatever they want:
> https://github.com/MikeBishop/dns-alt-svc/pull/289
>
> On Thu, Jan 14, 2021 at 6:43 PM Martin Thomson  wrote:
>
>> As requested (I'm not engaged here enough to understand the terms of
>> engagement, so my apologies for using an interaction form I'm accustomed
>> to), moving discussion from
>> https://github.com/MikeBishop/dns-alt-svc/issues/287 to here:
>>
>> The SVCB draft basically mandates a fallback to A/.  I think that
>> this is not universal and that this should instead be made an option.
>>
>> For HTTP, the fallback is necessary.  For a new protocol, a fallback
>> could be undesirable.  Especially if you want to deploy that protocol using
>> a service name on which you have already deployed HTTP.  If you don't want
>> your HTTP servers getting connection attempts for the new protocol, the
>> fallback is more nuisance than useful.
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

[Eric Orth]

Besides future-proofing for potential changes, I think the current rule
keeps us more flexible for handling obscure cornercases.  If there's any
reasonable chance that some obscure usecase in the future might make it
difficult for an authoritative to ensure only one alias is in place, it
seems to me better for the only-one-alias rule to stay a SHOULD-level rule
and keep the prescribed behavior for clients to reasonably handle it if
broken.

I wouldn't want to change to completely enforcing only-one-alias unless the
authoritative implementers are confident that they will always be able to
absolutely ensure that they are compliant.

On Tue, Jan 5, 2021 at 5:26 PM Ben Schwartz  wrote:

> On Tue, Jan 5, 2021 at 5:12 PM Paul Vixie  wrote:
>
>> a small matter.
>>
>> Ben Schwartz wrote on 2021-01-05 09:42:
>> >
>> >
>> > On Wed, Dec 30, 2020 at 4:39 AM libor.peltan > > > wrote:
>> >
>> > Hi Ben, all,
>> > i'd like to ask for some clarification of expected Authoritative
>> > server behaviour around Alias SVCB records:
>> >
>> > 1) when there are multiple Alias SVCB records for an owner name,
>> >
>> > As Section 2.4.2 says "SVCB RRSets SHOULD only have a single resource
>> > record in AliasMode".  So this "should" not happen.
>>
>> can you specify that if it does happen, the client behaviour should be
>> the same as if there are no matching records? otherwise clients will
>> have degrees of freedom, which i think would not end well.
>>
>
> The current draft says "If multiple are present, clients or recursive
> resolvers SHOULD pick one at random.".   I like that this leaves us the
> possibility of relaxing the single-Alias-RR rule in the future, if we find
> a use case for it.  Do you think this is not a suitable recommendation?
> ___
> 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] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

[Eric Orth]

On Wed, Dec 30, 2020 at 4:39 AM libor.peltan  wrote:

> Hi Ben, all,
> i'd like to ask for some clarification of expected Authoritative server
> behaviour around Alias SVCB records:
>
> 1) when there are multiple Alias SVCB records for an owner name, should
> the Authoritative server put targeted records into Additionals for all of
> them, or just pick one?
> (Section 4.1 says "authoritative DNS servers SHOULD return A, , and
> SVCB records in the Additional Section for any in-bailiwick TargetNames",
> but section 2.4.2 will render it useless with "If multiple are present,
> clients or recursive resolvers SHOULD pick one at random." Which means,
> half (or most) of the additionals will get thrown away.)
>
I believe Additional records would still be considered in the RRSet, and
thus including them would run afoul of a SHOULD in 2.4.2: "SVCB RRSets
SHOULD only have a single resource record in AliasMode."

Whether the authoritative server picks one or does something to reject a
multi-alias config as invalid seems to be up to the server and out of scope
for this spec.

>
> 2) When the TargetName points to an in-bailiwick CNAME, should the
> autoritative server populate the CNAME chain inside the Additional section?
> It seems to me (fortunately :) ), that following such CNAME is only
> required for Recursive resolvers, however e.g. this zone will thus need
> three upstream queries to fetch it all:
> foo 3600 IN SVCB 0 bar
> bar 3600 IN CNAME baz
> baz 3600 IN SVCB 0 . alpn=...
> baz 3600 IN  1::2
>
> Thanks for your answers,
> Libor
>
> PS: is this e-mail thread the right place to ask for details clarification
> around SVCB features?
> Dne 16. 11. 20 v 7:43 Ben Schwartz napsal(a):
>
> For those who haven't looked at the diff, here are the changes since -01
>   *  Added a Privacy Considerations section
>   *  Adjusted resolution fallback description
>   *  Clarified status of SvcParams in AliasMode
>   *  Improved advice on zone structuring and use with Alt-Svc
>   *  Improved examples, including a new Multi-CDN example
>   *  Reorganized text on value-list parsing and SvcPriority
>   *  Improved phrasing and other editorial improvements throughout
>
> Notably, the normative changes are extremely limited compared to the
> previous draft.  This reflects the authors' view that this draft is
> stabilizing and should be ready for WGLC soon.
>
> Perhaps more important than the changes that were made are the changes
> that were discussed but have not been made:
> * We had an extensive discussion regarding the meaning of TargetName =
> ".", which is currently shorthand for the owner name.  Some suggested
> augmenting this to mean "owner name minus underscore prefix labels", and
> others suggested removing this special-case entirely.  (
> https://github.com/MikeBishop/dns-alt-svc/issues/252)
> * We received a suggestion to ban fallback to non-SVCB connection
> establishment (https://github.com/MikeBishop/dns-alt-svc/issues/256).
> (We clarified the fallback text but did not change the recommendation.)
> * The escaping of ALPNs that contain commas continues to be contentious.
> We received a suggestion to remove support for such ALPNs (
> https://github.com/MikeBishop/dns-alt-svc/issues/268).
>
> In each case, we think that the draft's current text still reflects the
> group's consensus and strikes the right balance.  If you disagree, please
> open a thread on the dnsop list and we will discuss it.
>
> We have one open issue that seems likely to result in a text change (
> https://github.com/MikeBishop/dns-alt-svc/issues/87).  This is a fine
> point regarding the HTTPS user experience if TLS fails, and we are
> soliciting input from experts on those topics.
>
> On Mon, Nov 2, 2020 at 4:44 PM  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   : Service binding and parameter specification via
>> the DNS (DNS SVCB and HTTPS RRs)
>> Authors : Ben Schwartz
>>   Mike Bishop
>>   Erik Nygren
>> Filename: draft-ietf-dnsop-svcb-https-02.txt
>> Pages   : 45
>> Date: 2020-11-02
>>
>> Abstract:
>>This document specifies the "SVCB" and "HTTPS" DNS resource record
>>(RR) types to facilitate the lookup of information needed to make
>>connections to network services, such as for HTTPS origins.  SVCB
>>records allow a service to be provided from multiple alternative
>>endpoints, each with associated parameters (such as transport
>>protocol configuration and keys for encrypting the TLS ClientHello).
>>They also enable aliasing of apex domains, which is not possible with
>>CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
>>origins.  By providing more information to the client 

Re: [DNSOP] private-use in-meeting chat comments

[Eric Orth]

On Tue, Nov 17, 2020 at 4:46 PM Tony Finch  wrote:

> Brian Dickson  wrote:
>
> > One potential approach is to say (in the RFC) that one of the two-letter
> > reserved codes should avoid name collision by putting a
> collision-resistant
> > second-level label, below .zz and above the private use usage (and use
> that
> > particular two-letter code in that manner exclusively).
>
> This kind of thing, or guidspace.arpa, is not that different in terms of
> usability / ugliness from assigning a unique subdomain under a domain that
> has been registered in the normal way.
>

Confirming that I understand your point: You're discussing the case of some
local-network technology using $guid.guidspace.technology-vendor.com?

3 possible advantages I can think of of standardizing a .arpa subdomain:
1) More universally trustworthy that *.guidspace.arpa names will never be
globally resolvable, which would be unexpected behavior.  If using a
normally registered domain, you have to rely on whoever owns that domain,
and I could see usecases where the domain owner and the tech owner creating
a name are not one and the same.
2) In cases different technology vendors have created some standard relying
on guid-generated unique names (not necessarily an IETF standard), it may
be desirable for the generated names to fall under some neutral third-party
domain (in this case .arpa) rather than everyone involved relying on
somebody maintaining a domain.
3) In more general cases where different parties aren't trying to
interconnect, I don't quite understand why everyone can't just register
domains for their uses.  But one of the reasons we keep discussing
potential solutions for local domains is that many people keep refusing to
register names.  This would be a good alternative to hopefully convince
them to stop squatting unowned names.  (Although from a practical
perspective, I have no illusions that this would actually end the practice
of squatting.)


>
> There's also a privacy leak: if you assign a unique subdomain then when a
> device roams and leaks queries for the private domain, the device can be
> tracked and correlated with other devices that use the same private
> domain.
>

What if, in whatever hypothetical solution is using this, it is reasonable
for devices to always regenerate the names they are using on changing
networks? At least in such hypothetical cases, it seems the privacy danger
would be significantly mitigated, right? (Maybe we're getting too far into
unknown hypotheticals without finding actual usecases or implementors that
want this.)


>
> I have a terrible mental conflict trying to weigh this privacy issue
> against the horrible consequences of encouraging people to squat on
> unassigned domains and use colliding hostnames. The privacy leak probably
> needs to be fixed regardless, and if it is fixed then there would be a bit
> less pressure in favour of unwise squatting.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Biscay: Southerly 3 to 5, veering westerly 5 or 6 later in northwest.
> Moderate, occasionally rough in northwest. Rain later. Good, occasionally
> moderate.
>
> ___
> 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] private-use in-meeting chat comments

[Eric Orth]

guidspace.arpa or similar seems like a good potential solution to any of
the usecases around such "magic" negotiated systems where the user isn't
going to need to type in or see the actual name.  By generating a guid, any
system could easily generate unique names without any registration.

But it doesn't do anything for usecases that want nice names for users to
directly see or enter.  Anything with a guid is unlikely to ever be
considered a "nice" name.  Is this a usecase that also needs to be solved,
or are nice names even more into the territory where the system should be
registering a name first?

On Tue, Nov 17, 2020 at 1:57 AM Brian Dickson 
wrote:

> Comments made in the chat, about the private-use presentation/draft:
> Me:
> One potential approach is to say (in the RFC) that one of the two-letter
> reserved codes should avoid name collision by putting a collision-resistant
> second-level label, below .zz and above the private use usage (and use that
> particular two-letter code in that manner exclusively).
>
> E.g. whatever-i-want.guid-as-label-to-prevent-collisions.zz rather than
> whatever-i-want.zz
>
> Warren:
> @Brian: Yes, but as you know (being a registrar), people really want
> semantically meaningful names... People have seen using www.corp, not
> www.dfads3e4r34324rwefe.corp..
>
> Me:
> Correct, and I think possibly providing guidance that this private use
> SHOULD be generally limited to "magic" things like automation or
> automated/negotiated systems. The UI can/should hide the GUID component and
> possibly also the zz TLD
>
> Ben:
> That could be $guid.guidspace.arpa, no need for .zz
> "guidspace.arpa" is not a thing. I'm just suggesting an adjustment to
> Brian's proposal.
> Me:
> That's a good idea, can be pursued independently of the private-use TLDs
> like .zz
> (possibly addressing different use cases?)
>
> Brian
> ___
> 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] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

[Eric Orth]

I lead engineering for the stub resolver built into Chrome browser, so
while not an OS-level stub, maybe still prominent enough to count for the
"any communication" requested above.

My biggest concern with an approach like this is ossification from
middleboxes (especially some old home routers) that may not be ideally
engineered for the modern web.  Chrome has seen significant issues in the
past with such middleboxes creating pain (super slow responses mostly) for
a small number of our users on sending unusual queries or an increased
amount of queries.  As such, we're generally afraid of sending out anything
other than basic and rate-limited requests when it comes to Classic DNS.
Attempting new things and falling back to conservative behavior on an issue
is not necessarily a reasonable approach because the middlebox pain is not
always limited to the individual queries.  In some cases, probing or
experimenting with resolver capabilities can cause user pain for all
subsequent queries for a period of time on the order of minutes.

Since this specific multi-query proposal encodes it in EDNS, it might be
more reasonable.  I don't have any actual data to back this up, but I would
guess that unknown EDNS options are less likely to cause issues than
completely unknown queries.  So it might be safe enough to at least do
super cautious experimentation around it.

Note that none of these ossification issues are really a concern with DoH
(or DoT) where we can be reasonably sure we're talking to a modern
non-ossified resolver.  The usefulness of combining queries is a little
reduced since DoT and DoH often use connection sharing for multiple
requests anyway.  But there's still some potential value.  In ECH (ESNI)
discussions, it has come up a few times that an attacker could try to force
a downgrade from ECH by identifying and blocking the larger packets
containing HTTPSSVC responses that contain ECH keys but not address
resolves.  Much safer if A/ and HTTPSSVC can be in the same
query/response to force an attacker to block everything or nothing.

Additional possible issues with this multi-query proposal:
*By combining A and , you might lose nice abilities to try to speed
things up using Happy Eyeballs v2 style algorithms to immediately start
using addresses as they come in, before all addresses are received.  Not
currently a huge issue for Chrome DNS because we don't currently support
Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that
improvement.
*The current proposal seems to give the resolver a lot of leeway to only
sometimes include the additional results and includes a TODO note that
maybe there should be a way for clients to mark qtypes as mandatory.  I
don't think the client would get as much use out of multiple qtypes unless
it had reasonable confidence that it would at least usually get all the
responses.  Otherwise, the client is often going to have to make multiple
requests in parallel anyway to ensure it can get all the responses
reasonably quickly in parallel.  Then again, if it's something like
requesting an extra qtype that we would be afraid to send in Classic DNS
anyway (due to the ossification issues), eg HTTPSVC, I suppose there's more
value of just adding in the additional qtype and using the response
opportunistically when received.

On Thu, May 28, 2020 at 12:22 PM Vladimír Čunát 
wrote:

> Hello.
>
> On 5/28/20 10:00 AM, Shane Kerr wrote:
> > As I have mentioned several times on microphone, I think this draft
> > has huge potential, potentially cutting the number of queries handled
> > by recursive resolvers almost in half - since they could ask for A and
> >  records in a single query.
>
> I'm not sure if it would be a net benefit if we consider the added
> complexity (like the few unpleasant corner cases), the need to implement
> on both sides, and other ways that are available.  Is saving the number
> of IP-layer packets the only significant motivation?
>
> For resolver-to-auth case I do suspect some potential.  Plain UDP will
> probably still stay popular there for some time.  Though I'm afraid this
> might _sometimes_ push the answer sizes too large to fit into one packet
> (in signed zones), which in my eyes slightly reduces attractiveness of
> the technique, now that we know that UDP over 1.5 kB is no good.
>
> For non-auth cases, you typically communicate with just one upstream
> resolver (or very few), so if the number of packets is a concern, I'd go
> for a long-lived TCP or TLS connection (there's e.g. privacy motivation,
> too).  That's all standardized already, and it naturally avoids those
> extra corner cases.  Sure, it's probably possible to improve
> significantly on session timers and resuming, performance, usage of
> Nagle's algorithm, etc. but ATM to me that feels a more worthwhile
> investment than any of the multi-answer proposals.  One advantage is
> that many of the TCP/TLS improvements can be deployed one-sidedly with
> some effect but 

Re: [DNSOP] CNAME chain length limits

[Eric Orth]

I should also note though that Chrome's built-in stub won't do any followup
queries if the full chain is not in the response from the recursive.

On Wed, May 27, 2020 at 3:03 PM Eric Orth  wrote:

>
>
> On Wed, May 27, 2020 at 1:49 PM John R Levine  wrote:
>
>> While I should have been doing something else, I made a rather long CNAME
>> chain.  When I looked up chain.examp1e.com it got SERVFAIL, but after I
>> warmed up my cache five links at a time by looking for chain5, chain10,
>> chain15, and so forth, it worked.  At least it worked in "dig" and
>> "host".
>> When I try and look up http://chain.examp1e.com, Chrome waits a while
>> and says not found,
>
>
> If Chrome is using its built-in stub, there's not expected to be a limit
> (other than the overall message size limits), but nothing tests chains this
> long other than security fuzzers that are only looking for crashes or
> memory issues.
>
>
>> Firefox waits a while and says "Hmm. We’re having
>> trouble finding that site." and Safari on my Mac hangs.  (Feel free to
>> try
>> it yourself.)
>>
>> I realize the answer to most questions like this can be summarized as
>> "don't do that", but is there any consensus as to the maximum CNAME chain
>> length that works reliably, and what happens if the chain is too long?
>> Hanging seems sub-optimal.
>>
>> Regards,
>> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
>> Please consider the environment before reading this e-mail. https://jl.ly
>>
>> $ dig chain.examp1e.com A
>> ;; Truncated, retrying in TCP mode.
>>
>> ; <<>> DiG 9.10.6 <<>> chain.examp1e.com a
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;chain.examp1e.com. IN  A
>>
>> ;; ANSWER SECTION:
>> chain.examp1e.com.  3371IN  CNAME   chain100.examp1e.com.
>> chain100.examp1e.com.   3371IN  CNAME   chain99.examp1e.com.
>> chain99.examp1e.com.3371IN  CNAME   chain98.examp1e.com.
>> chain98.examp1e.com.3371IN  CNAME   chain97.examp1e.com.
>> chain97.examp1e.com.3371IN  CNAME   chain96.examp1e.com.
>> chain96.examp1e.com.3372IN  CNAME   chain95.examp1e.com.
>> chain95.examp1e.com.3372IN  CNAME   chain94.examp1e.com.
>> chain94.examp1e.com.3372IN  CNAME   chain93.examp1e.com.
>> chain93.examp1e.com.3372IN  CNAME   chain92.examp1e.com.
>> chain92.examp1e.com.3589IN  CNAME   chain91.examp1e.com.
>> chain91.examp1e.com.3589IN  CNAME   chain90.examp1e.com.
>> chain90.examp1e.com.3583IN  CNAME   chain89.examp1e.com.
>> chain89.examp1e.com.3583IN  CNAME   chain88.examp1e.com.
>> chain88.examp1e.com.3583IN  CNAME   chain87.examp1e.com.
>> chain87.examp1e.com.3583IN  CNAME   chain86.examp1e.com.
>> chain86.examp1e.com.3583IN  CNAME   chain85.examp1e.com.
>> chain85.examp1e.com.3577IN  CNAME   chain84.examp1e.com.
>> chain84.examp1e.com.3578IN  CNAME   chain83.examp1e.com.
>> chain83.examp1e.com.3578IN  CNAME   chain82.examp1e.com.
>> chain82.examp1e.com.3578IN  CNAME   chain81.examp1e.com.
>> chain81.examp1e.com.3579IN  CNAME   chain80.examp1e.com.
>> chain80.examp1e.com.3570IN  CNAME   chain79.examp1e.com.
>> chain79.examp1e.com.3571IN  CNAME   chain78.examp1e.com.
>> chain78.examp1e.com.3571IN  CNAME   chain77.examp1e.com.
>> chain77.examp1e.com.3571IN  CNAME   chain76.examp1e.com.
>> chain76.examp1e.com.3572IN  CNAME   chain75.examp1e.com.
>> chain75.examp1e.com.3564IN  CNAME   chain74.examp1e.com.
>> chain74.examp1e.com.3564IN  CNAME   chain73.examp1e.com.
>> chain73.examp1e.com.3564IN  CNAME   chain72.examp1e.com.
>> chain72.examp1e.com.3564IN  CNAME   chain71.examp1e.com.
>> chain71.examp1e.com.3564IN  CNAME   chain70.examp1e.com.
>> chain70.examp1e.com.3519IN  CNAME   chain69.examp1e.com.
>> chain69.examp1e.com.3519IN  CNAME   chain68.examp1e.com.
>> chain68.examp1e.com.3519IN  CNAME   chain67.examp1e.com.
>> chain67.examp1e.com.3519IN  CNAME   chain66.e

Re: [DNSOP] unsolicited HTTPSSVC responses

[Eric Orth]

On Wed, May 27, 2020 at 2:34 AM Petr Špaček  wrote:

> On 27. 05. 20 1:05, Paul Vixie wrote:
> > so, this way lies madness, and the solution we see most often is a
> host-level
> > cache of DNS results. the old INN (usenet net news) server had one of
> these,
> > and all modern browsers have one. many of us simply run a validating
> iterative
> > caching recursive resolver on our hosts, since it's not much code by
> modern
> > standards. but in all such cases we don't have a good way to retrieve
> more
> > than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is
> not
> > well defined and is broadly unimplemented. various other
> multiple-questions
> > proposals have been made but nothing gets traction.
>
> I would much rather spent time on
> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03
>
> That would bring benefit to broader set of clients and has advantage that
> server does not send back data nobody asked for (thus wasting resources on
> unnecessary work).
>

Maybe a better solution, but considering that the issue I'm dealing with is
when the stub is unwilling to send additional queries or queries for new
types out of concerns of middlebox ossificiation (especially from older
home routers) on additional queries or unknown query types, does anybody
have any data to show that the multiple qtype EDNS option won't cause
similar issues?

But in other cases without as much ossifciation concern, especially when
using DoH, I'm supportive of any effort to allow querying multiple types in
the same request.  Would significantly help with some of the security
concerns in ESNI/HTTPSSVC where an attacker could try to block ESNI by
identifying and blocking the packets just for the HTTPSSVC records.  If
A//HTTPSSVC are all in the same request/response, you can't block any
of it without blocking all of it.  My one concern of that specific proposal
is that if the client doesn't know that the server will respond for the
additional queries, it still has to make separate queries for all three,
leading to lots of redundant responses when the additional types are
handled.


>
> I feel that nowadays web browsers have better communication with OS
> vendors/stub resolvers (Android and Chrome come to mind). Can we stub
> resolvers on board, pretty please?
>
> --
> Petr Špaček  @  CZ.NIC
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02

[Eric Orth]

On Fri, Apr 17, 2020 at 6:20 AM Alessandro Ghedini 
wrote:

> Hello,
>
> First off, I have started implementing support for SVCB and HTTPSSVC as
> part of
> the dnspython library [0] and I'd be interested in doing some interop
> testing
> with other people's implementations.
>
> I also have a few comments/questions about the draft, apologies if they
> have
> already been discussed in the past (haven't been following the draft from
> the
> start).
>
> 1. For interop testing purposes it would be very helpful if the draft
> listed
> commonly agreed upon code-points for the new RR types. Ideally in the form
> of an
> official early assignment from IANA, but if that's not possible picking a
> couple
> of codepoints at random from the "private use" range would also be
> helpful. In
> my implementation I'm currently using "65481" for SVCB and "65482" for
> HTTPSSVC.
>
> 2. The structure of the draft is a bit odd, as it lists a bunch of examples
> before introducing any of the records. This was a bit confusing to me, so
> I'd
> suggest moving sections 1.5 and 1.6 _before_ the examples (that is,
> immediately
> after the introduction). It might also be a good idea to just move the
> examples
> to an Appendix instead.
>
> 3. Would it make sense to move the ESNI/ECHO config paramenter to the
> ESNI/ECHO
> draft instead? This way the DNS draft wouldn't need to depend on the ESNI
> draft
> (so e.g. if ESNI ends up taking longer, this draft could be published
> without
> having to wait for it).
>
> 4. What is the point of differentiating between AliasForm and ServiceForm?
> Like,
> couldn't the draft just say that the SvcFieldValue is an optional field
> and be
> done with that? It seems like not having to explicitly differentiate the
> two
> cases would simplify the draft a bit without sacrificing much, though I
> might
> be missing something.
>

I think the stronger distinction makes it easier to describe the required
behavior differences.  Much simpler to just say things like don't mix both
forms in the same response, and to ignore non-alias if any aliases are
present, than to make more detailed descriptions about what specific
optional contents are allowed to be mixed or not to accomplish the same
thing.


>
> 5. Section 2.1.1 says
>
>The presentation format for SvcFieldValue is a whitespace-separated
>list of elements representing a key-value pair, with an absent value
>or "=" indicating an empty value.
>
> It took me longer than I'd like to admit to understand the "with an absent
> value
> or "=" indicating an empty value" part. I'd suggest rewording that
> paragraph to
> something like:
>
>The presentation format for SvcFieldValue is a whitespace-separated
> list of
>key=value pairs (e.g. "key123=value1 keys456=value2"). When the value,
> or
>both the value and the "=" are omitted, the value should be interpreted
> as
>being empty.
>
> Or something better :)
>
> 6. In Section 2.2 it says (in reference to param field values):
>
>o  an octet string of the length defined by the previous field.
>
> It might be good to say here that the format of this octet string is
> defined
> according to the corresponding SvcParamKey, and then reference section 6
> for
> ths currently defined keys. The same applies for section 2.1.1 for the
> presentation format.
>
> 7. Section 4.3 says:
>
>All DNS servers SHOULD treat the SvcParam portion of the SVCB RR...
>
> Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned
> anywhere else.
>
> 8. Maybe I'm missing something, but the following sentence in Section 6.4
> seems
> wrong:
>
>When SvcDomainName is ".", server operators SHOULD NOT include these
> hints,
>because they are unlikely to convey any performance benefit.
>
> My understanding is that ipv4hint and ipv6hint are the way to solve the
> ESNI
> multi-CDN problem, so let's say I have "www.example.net" that CNAMEs to
> both
> "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both A
> and
> HTTPSVC concurrently for "www.example.net", and receives two answers (the
> answer
> to the A query points to CDN A, while the answer to HTTPSSVC points to CDN
> B):
>
> www.xample.net  3600 IN CNAME cname.cdn-a.example
> cname.cdn-a.example 3600 IN A 192.0.2.1
>
> and
>
> www.xample.net  3600 IN CNAME cname.cdn-b.example
> cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..."
>
> My understanding is that in this case the client could end up connecting to
> 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN).
> So if
> the server doesn't provide IP hints there would indeed be impact on
> performance
> because the client would just straight up fail to connect initially (e.g.
> maybe
> CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can use
> it,
> or just because of the wrong ESNI config).
>
> Long story short, I don't think the text should discourage setting
> ipv4hint and
> ipv6hint 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-14.txt

[Eric Orth]

Took a look at the diff.  I believe this resolves all my previous concerns.

On Wed, Jan 15, 2020 at 12:11 PM  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   : Extended DNS Errors
> Authors : Warren Kumari
>   Evan Hunt
>   Roy Arends
>   Wes Hardaker
>   David C Lawrence
> Filename: draft-ietf-dnsop-extended-error-14.txt
> Pages   : 14
> Date: 2020-01-15
>
> Abstract:
>This document defines an extensible method to return additional
>information about the cause of DNS errors.  Though created primarily
>to extend SERVFAIL to provide additional information about the cause
>of DNS and DNSSEC failures, the Extended DNS Errors option defined in
>this document allows all response types to contain extended error
>information.  Extended DNS Error information does not change the
>processing of RCODEs.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-14
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-14
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-14
>
>
> 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] Consensus suggestion for EDE and the TC bit

[Eric Orth]

I still have a soft preference (but am definitely not going to call it a
hard blocker) for some way to avoid followup queries when the only thing
causing truncation is EDE.

My concern comes from the EXTRA-TEXT being an open-length field, and I
imagine many operators would want to create long verbose error messages.
Seems that could lead to many cases where EDE causes common excessive
truncation.

Maybe an alternate easy solution would be to add a don't-do-that note to
section 3.4 along the lines of "Long EXTRA-TEXT fields may cause truncation
and bad resolve performance, which is usually undesirable for the
supplemental nature of EDE. Operators setting the field SHOULD avoid
setting unnecessarily long contents, especially when it can be determined
that doing so will cause truncation." With something like that, I think my
concerns are enough resolved that I wouldn't worry about DP unless future
experience shows EDE truncation to be a significant problem.

But otherwise, if people don't like my suggested note, because I only have
a soft preference to do something, I agree that moving TC/DP to a separate
doc is a good idea.  If EDE is otherwise consensus-ready, let's get it
published.

On Thu, Nov 21, 2019 at 12:04 PM Ray Bellis  wrote:

>
>
> On 21/11/2019 15:37, Ben Schwartz wrote:
>
> > I would suggest adding a requirement to the EDE draft that EDE be
> > the last option in OPT
>
> And what if some other future option wants to lay claim to that
> requirement?
>

 I agree that this would be a difficult requirement to set.  Only one thing
can be last, and I would argue that EDE is not important enough to claim
that distinction and take away the flexibility from future specs.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-nygren-dnsop-svcb-httpssvc

[Eric Orth]

On behalf of Chrome DNS, I support adoption and plan to stay engaged on
this.  While I don't think the draft is perfect yet, we like the general
approach and are interested in exploring it further.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop