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
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 wi
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 th
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
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 e
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 im
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
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 sta
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
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 exp
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
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 perspectiv
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
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 m
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 r
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 us
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 d
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) th
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:
>
>> Wh
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. m
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 c
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.
>
>
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 verbo
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.or
24 matches
Mail list logo
