On 02/08/2022 14:22, Schanzenbach, Martin wrote:
So, we mostly separated the technical protocol design from the
namespace issue.
No such separation is possible - the DNS is the Domain Name _System_.
That _system_ is the combination of:
- the wire protocol
- the authoritative servers (from th
On 13/08/2022 23:56, Paul Vixie wrote:
it's very much worth re-reading RFC 921 and RFC 952 to understand how it
was that domain-style names (an RFC 952 term, which RFC 921 described as
"structured names" or "hierarchical names") preceded what we today call
the "domain name system."
I'm st
On 15/08/2022 18:55, Paul Vixie wrote:
if IETF decides at this late (2022) date to reserve part of the domain
style namespace for non-udp/53 non-tcp/53 uses, nothing will break. that
helps me understand the open ended _effective_ intent of STD-13, which
is to build roads not walls -- in the
On 15/08/2022 19:17, Paul Vixie wrote:
of course i meant that each such namespace would get its own
"sub-domain" under .alt (e.g., .GNS.ALT).
Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...
Ray
__
On 17/08/2022 15:56, Timothy Mcsweeney wrote:
But this part is super-genius "These ".alt" names are defined by
protocol specification to be nonexistent" I had no idea you could
specify non-existance. I'm going to have to try that!
I believe the intention was that the DNSSEC nsec records in
On 22/08/2022 15:05, Paul Hoffman wrote:
I would prefer that they choose whatever is best for their own
non-DNS user community, which might still be ASCII.
Since this came up earlier in the thread(s), I would also strongly
advise that users of .alt do not stray from the DNS standard of
-
On 22/08/2022 18:42, Timothy Mcsweeney wrote:
Why would they do that? And why wouldn't they just serve up their
own root from within a subdomain they already have. Maybe everyone
should have their own root, I mean isn't that what this .Alt
registry is??
You can't have a "root" label in
On 23/08/2022 10:22, Andrew McConachie wrote:
The only restriction that seems reasonable to me is prohibiting zero
length strings. This list convinced me other restrictions would be a bad
idea.
There will be a very long tail of systems out there that do not know
about ".alt".
How wo
On 23/08/2022 12:18, Schanzenbach, Martin wrote:
I think the notion that there is strict "format" of a name and that
if it is not in that format is not actually part of the same
namespace is already behind us.
If that were the case then we do not need .alt at all.
Arguably you do not, but u
On 23/08/2022 17:14, Paul Hoffman wrote:
Is the suggestion that the non-DNS protocol follow the DNS wire
format and/or presentation format now an expectation? This seems like
a long jump.
The dot-separated form of a domain name _is_ a "presentation format",
even if it's not precisely that
On 23/08/2022 16:45, Peter Thomassen wrote:
I think their point is that the application (e.g. browser) may be
agnostic of the resolution system (= accept the name), but resolution
may fail because something switching layer like nsswitch would choke
on a non-DNS-style name, *even when* the d
On 09/02/2023 08:54, Ted Lemon wrote:
Thotz?
draft-bellis-dnsext-multi-qtypes-04
Ray
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 16/02/2023 12:52, Dick Franks wrote:
The last statement is informatively and normatively mistaken.
The counterexample is to be found in RFC8490(5.4):
A DSO message begins with the standard twelve-byte DNS message header
[RFC1035] with the OPCODE field set to the DSO OPCODE (6). How
If we're looking for more counterexamples, there's also RFC7873#5.4
For servers with DNS Cookies enabled, the QUERY opcode behavior is
extended to support queries with an empty Question Section (a QDCOUNT
of zero (0)), provided that an OPT record is present with a COOKIE
opti
Forwarded Message
Subject: New Version Notification for
draft-bellis-dnsop-qdcount-is-one-00.txt
Date: Fri, 17 Feb 2023 08:12:18 -0800
From: internet-dra...@ietf.org
To: Joe Abley , Ray Bellis
A new version of I-D, draft-bellis-dnsop-qdcount-is-one-00.txt
has been
On 17/02/2023 20:58, Ted Lemon wrote:
OpenThread. It’s on GitHub.
Notwithstanding an implementation apparently getting by in the DNSSD
space, I remain convinced that QDCOUNT > 1 has no place in the global
DNS and that RFC 1035's ambiguity on the matter needs clarification.
To that end, Jo
On 04/08/2023 00:29, Petr Menšík wrote:
What do you think, would such mechanism be useful even on classic DNS?
Are there already deployed alternatives? How useful something similar
might be? Does such mechanism contain significant drawback, why it would
not be a good idea?
Something like i
On 23/10/2023 16:01, internet-dra...@ietf.org wrote:
Internet-Draft draft-ietf-dnsop-qdcount-is-one-01.txt is now available.
The only change relative to the -00 draft is slightly clearer wording in
the paragraph about DNS firewall processing.
Ray
_
On 16/11/2023 11:13, Paul Wouters wrote:
On Tue, 14 Nov 2023, internet-dra...@ietf.org wrote:
Internet-Draft draft-bellis-dnsext-multi-qtypes-08.txt is now available.
Last time this came around I also suggested instead of n times QT
entries, to use the same method as NSEC does for conveyin
On 17/11/2023 10:41, Paul Wouters wrote:
I think it would be unwise to make assumptions on how people will use
this feature. They might want to ask for many more records along with
A/ records. If we change a core DNS feature, it should not designed
for a specific DNSSD use case of HTTPS.
On 28/11/2023 12:25, Ben Schwartz wrote:
I think DNS is simply the wrong tool for this job.
+lots
Ray
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I think this document gives an opportunity to explicitly clarify
expectations regarding the NS records either side of the zone cut.
I get the impression with DELEG on the horizon that there's a shift
towards the parent side data being considered more "authoritative" even
though in protocol ter
On 05/04/2024 15:04, Willem Toorop wrote:
I also think the draft should be more explicit on what data is actually
meant in those ranks (i.e. referral responses with "B: Data from the
authority section of a non-authoritative answer, Additional information
from non-authoritative answers." etc
On 28/05/2024 22:12, Warren Kumari wrote:
Hi there, authors (and WG),
Thank you for this document, I found it clear, useful, and an easy read.
I do have a few comments/nits; addressing these now should help the IETF
LC and IESG evaluation go more smoothly.
Please SHOUT loudly once you've
> So this is not just RFC1035. I *guess* this could be "DNS specifications"
> instead of "DNS specification"
That was going to be my suggestion.
Ray
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
On 28/06/2024 17:47, Ben Schwartz wrote:
Hi DNSOP,
The practice of DNS Load Balancing -- sending different answers to
different resolvers to optimize latency and avoid overload -- has been
around for at least 25 years, and remains as popular as ever. It's
never really been supported in the
On 09/07/2024 11:06, Kazunori Fujiwara wrote:
Dear DNSOP,
I submitted new draft that proposes to consider "Upper limit value
for DNS". If you are interested, please read and comment it.
I disagree with the rationale for 13 name servers.
The root (and .com) have that because it was what wou
On 10/07/2024 14:27, Philip Homburg wrote:
So the question becomes, do we want some limits in an RFC that everybody
agrees on or do we want to keep the current informal system where limits
are not fixed and people can get unlucky if they exceed limits they didn't
know exist.
I'm all for a re
For those not paying attention to the HTTP-bis working group, this DNS
RR was proposed there last week.
It appears to subsume the ALT-SVC proposal and also covers the use case
I had in mind with my HTTP Record draft (i.e. CNAME at the apex).
Given that it has someone from at least major brows
On 08/07/2019 22:17, Erik Nygren wrote:
For DNSOP folks, and ANAME proponents in-particular,
I/we are especially interested in understanding if this would address
enough of the customer use-cases driving ANAME were major
browsers to implement support for HTTPSSVC, or would any
limitations her
On 10/08/2019 06:26, Wes Hardaker wrote:
8.2.2 DONE The biggest issue is of course to find out what to put in the
extended
-
error code. On some resolvers (at least on Knot), the place where the
error is n
On 23/08/2019 22:39, Joe Abley wrote:
People have always been able to anchor their non-DNS naming schemes
to domain names they control in the DNS as a way to avoid collisions,
and nobody has seemed to think that's a good idea. Is it more likely
that someone would anchor their ARTICHOKE alter
On 12/09/2019 19:10, Viktor Dukhovni wrote:
That's the crux of the matter and, in short, *no*, that's not (or should
not be) the motivation.
SERVFAIL means, and will continue to mean, I can't help you, better luck next
time (or elsewhere).
The new EDEs are *diagnostic* detail to aid in tr
On 06/11/2019 13:42, Matthew Pounsett wrote:
I still have a few comments. There were a few comments from my review
of -13 that weren't responded to in email, and haven't been updated in
the text, so I'm repeating them here.
Hi Matt,
We sought advice from one of the Chairs as to whether in
On 19/11/2019 18:49, Petr Špaček wrote:
> Please keep RR type name as one lexical unit!
There's already one RR type with a hypenated name (NSAP-PTR).
> Constructing the name from multiple tokens ("SVCB" "-" "HTTPS")
> will trigger all sorts of bugs all over the place
I've looked for, but can'
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?
> Then as a client, I can easily detect this situation, because the
> truncation p
On 20/12/2019 15:08, Bob Harold wrote:
> But if we are updating it, could we consider a better word than
> "forward" ? Actually "backward" would be correct, although I prefer
> "from the back to the front" as used elsewhere.
It's not possible to traverse the RRs in a raw DNS packet "backwards"
On 03/01/2020 21:10, Christian Huitema wrote:
> Most of the early tests of QUIC were using port 4433, not 443. Using
> alternate ports for testing is very common.
Not just for testing - many people use alternate ports when port
forwarding to reach services inside a many-to-one NAT.
Ray
pEpkey
On 13/01/2020 14:48, Warren Kumari wrote:
> On Thu, Dec 19, 2019 at 8:28 PM Warren Kumari wrote:
>>
>> [ Note: CC list edited ]
>>
>> Hi there authors,
>
> Any idea when you might get a chance to get to address these comments?
> This is a useful document, and I'd like to see it progress.
Mark is
On 25/02/2020 14:52, Tim Wicinski wrote:
> Any idea when will we see an updated version?
We're looking at it, but the BIND release schedule and Mark's TZ (he's
11 hours ahead of me) have been working against us.
Ray
___
DNSOP mailing list
DNSOP@ietf.o
On 08/04/2020 15:16, Éric Vyncke via Datatracker wrote:
>
> Also, if the firewall is "protecting" the DNS server (cough cough), then as a
> security officer I would prefer to block all unknown opcodes/types at the
> firewall (possibly with a reply).
>
See §4.
"with a reply" is fine, so long
§8 of the draft says:
> Some TLDs have a requirement for certain Fully Qualified Domain Names
> (FQDN) within their TLD, such as "whois.example" or "nic.example".
> These usually appear as signed data of the TLD and not as a delegated
> child zone. These names would have to be converted to delega
On 27/05/2020 07:33, Petr Špaček wrote:
> 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
> resource
On 27/05/2020 17:40, Eric Orth wrote:
> 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 q
On 23/07/2020 18:44, Tim Wicinski wrote:
> Actually, that does make sense. Though we also have to expect that these
> existing terminology will not be replaced in the lexicon overnight.
>
> The Chairs plan on having a few slides on this whole topic, as we've
> been thinking about it for some ti
On 24/07/2020 10:28, Martin Hoffmann wrote:
> Side note: Whenever using "upstream" and "downstream", I’ve pretty much
> always first had a half-hour discussion what each means and still later
> ran into issues a la "What was downstream again?"
Upstream is "towards the source". This works both
On 14/09/2020 15:32, libor.peltan wrote:
Let me leave some personal opnion/comments on this AUTHINFO idea,
although I don't know the background here.
There are multiple kinds of "capabilities" of an authoritative server.
Some of them are properties of the zone, some are properties of the DN
On 09/02/2021 10:21, Willem Toorop wrote:
I am intrigued by your suggestion to use CSYNC RR to signal SOA Serial
numbers and to help out in. And indeed, the flags in CSYNC's flags rdata
field appear to have helpful names and meanings with respect to clashing
member zones and member zone trans
On 14/04/2021 10:19, Stephane Bortzmeyer wrote:
> Regarding dnsop work, the same report suggests to modify RFC 5625 "DNS
> Proxy Implementation Guidelines" to replace the MAY in section 6.3 by
> a MUST. I think that the reason there is currently a MAY is not
> because RFC 5625 finds invalid com
On 16/04/2021 09:18, Ray Bellis wrote:
> Yes, that was pretty much it.
>
> Many DNS proxies / ALGs don't inspect the packet contents at all, so a
> stronger generic requirement was not feasible.
FWIW, I have formally requested that the authors withdraw the statement
in the p
On 19/04/2021 17:08, Lanlan Pan wrote:
>
>
> Ray Bellis mailto:r...@bellis.me.uk>> 于2021年4月16日
> 周五 下午4:19写道：
>
> Many DNS proxies / ALGs don't inspect the packet contents at all, so a
> stronger generic requirement was not feasible.
>
>
&g
On 30/07/2021 19:29, Paul Wouters wrote:
> We are seeing the WG dropping actual protocol work because of these
> discussions.
If only we had a working group for discussing DNS Extensions...
Ray
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.
On 03/09/2021 08:32, Paul Wouters wrote:
> I myself think we have reached the point where memory on nodes is so
> cheap, it is not worth the security degradation to use opt-out.
Generic DIMMs are indeed cheap.
However, supported ones from server vendors such as Dell have a retail
price about
On 02/11/2021 20:00, Roman Danyliw wrote:
> I believe that if this draft is going to be the BCP to discuss DNS
> over TCP, all of the flavors of DNS over TCP need to be covered.
I disagree, strongly.
The properties of DNS over TCP are well understood, and DNS over TLS is
(to a first approxima
On 14/12/2021 08:28, RFC Errata System wrote:
The following errata report has been submitted for RFC8906,
"A Common Operational Problem in DNS Servers: Failure to Communicate".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid
On 22/03/2022 16:01, Murray S. Kucherawy wrote:
As to the options proposed, I agree that Expert Review can introduce
delay, but given the above, so too can Specification Required (maybe
worse, in aggregate). So I recommend Expert Review.
I am concerned that the set of Expert Reviewers nece
On 04/08/2017 17:02, Matthew Pounsett wrote:
> Do I understand correctly that the intent is to obsolete existing
> underscore registries (whether they be actual IANA registries, or just
> code points listed in a draft) and move their data to a new, central
> registry? This seems sensible to me
Having looked at this a few months ago when one of our partners was
(briefly) returning NOTIMP for ANY queries, I find myself wondering why
this isn't discussed in the draft?
The draft does talk about *new* RCODEs, but not existing ones.
My reading of RFC 1035 is that it would be a perfectly appr
On 07/08/2017 16:44, Ólafur Guðmundsson wrote:
> This was the original proposal,
> the drawback is that resolvers to not cache the answer, and to make
> things worse they ask ALL NS addresses for listed domain
> thus it acts as a DDoS against the domain in question.
Indeed - I've since conf
On 09/08/2017 17:44, Ted Lemon wrote:
> Of course, the real answer to this is that neither solution is
> desirable. I've heard several people here say that if localhost were
> "fixed" in an RFC, then the W3C could mark http connections to localhost
> as secure, rather than insecure. This is
WG chairs
Could you please let me / the WG know where we stand with the various
drafts describing ways to accommodate multiple questions and/or answers
in a single request?
Multiple questions:
- draft-bellis-dnsext-multi-qtypes
- draft-yao-dnsop-accompanying-questions
Multiple answers:
- dr
I see that this draft uses a syntax similar to RFC 8145 Trust Anchor
Telemetry RFC (which uses _ta-) albeit without the leading
underscore, i.e. .ta-.
I'd like to propose instead ._ta.
This would allow _ta to be registered as a standalone entry in the
underscore label registry, whilst also avoid
On 30/10/2017 17:40, Evan Hunt wrote:
> IIRC we discussed it, and were concerned that _ta. could be cached as
> nonexistent by servers implementing QNAME minimization.
How would that happen, at least so long as _ta responds like any other
empty non-terminal?
Ray
__
On 31/10/2017 14:34, Tony Finch wrote:
> It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.)
>
> The problem occurs if you have a validator behind a cache. The cache will
> prevent downstream id._ta. queries from reaching the root, so any
> downstream trust anchor variation will be los
On 31/10/2017 14:56, Joe Abley wrote:
> Perhaps I missed something, but how do you ensure that _ta is an
> empty non-terminal?
By having that be part of the required server logic to implement the
sentinel mechanism?
That said, I'm not sure this would be consistent with the draft's
proposed use
On 13/11/2017 19:01, Geoff Huston wrote:
> errr - what would it mean if the rcode in the error code header differed
> from the rcode value in the extended-error component?
>
> The issue with duplicated information in a packet is that you then have
> add even further consideration to cope with t
On 13/11/2017 21:13, Tony Finch wrote:
> Ray Bellis wrote:
>>
>> Would it be feasible to reserve a standard RCODE value in the
>> header that just means "see extended error"?
>
> That would require client-to-server signalling,
It would. Perhaps the *
On 15/11/2017 11:47, Alexander Mayrhofer wrote:
> I agree that signaling is important, and i also believe that if
> there's an OPT in the request, we can safely assume that the client
> would not choke on this option. I'm torn on the question whether or
> not stale data should be served (without s
e slides. Draft slides are acceptable on submission.
If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Ray Bellis, for the OARC Programme Committee
OARC depends on sponsorship to fund its workshops and associated social
On 21/12/2017 15:36, Robert Story wrote:
> I reread the draft today, and noticed that two things aren't specified.
> The first is the contents of the A/ RRSET returned, and the second
> is the TTL for the records.
>
> Maybe the A/ record values could be used to return additional
> detail
On 02/01/2018 09:27, internet-dra...@ietf.org wrote:
> Title : DNS Multiple QTYPEs
> Author : Ray Bellis
> Filename: draft-bellis-dnsext-multi-qtypes-05.txt
> Pages : 7
> Date: 2018-01-02
This was just a "keepalive" upd
On 02/01/2018 23:37, Paul Hoffman wrote:
> This answer doesn't seem to fully address Robert's and Ray's questions.
> Why use an A/ query if you aren't going to do anything with the
> result? If you are going to use A/, you have to tell resolvers what
> to return in the results. Using a n
details are at:
<https://indico.dns-oarc.net/event/28/call-for-abstracts/>
Ray Bellis, for the DNS-OARC Programme Committee
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 30/01/2018 18:59, Andrew Sullivan wrote:
> Because of that same section, also, signing the answer should also not
> be controversial because the answer is static. My preference,
> however, would be for the root servers to REFUSE to answer such
> queries.
Won't that cause the resolver to cycle
On 31/01/2018 00:58, Paul Hoffman wrote:
> The problem you hit was in BIND. To get around it, you simply add
> "check-names master warn;" to the options.
If you're doing that, please put it in the zone specific stanza, and not
in the global options for the server:
zone "foo" {
type master;
On 01/02/2018 14:41, Tony Finch wrote:
> That's not entirely true - if you are asking an authoritative-only server
> then you get REFUSED or not depending on whether the QNAME is in an
> authoritative zone.
Right, but the resolver behaviour is to assume that that server is a
lame delegation, an
On 02/02/2018 08:32, Mark Andrews wrote:
> The real question is do the name lookup api’s in the web browsers barf
> on non IDN, non LDH names since that is the mechanism being proposed
> for people to test this.
+1 - that's my concern too.
The browsers that refuse to accept an underscore label
On 04/02/2018 22:35, Petr Špaček wrote:
> Underscore is now out of the question because we know about the
> Android/Chrome problem se might test alternative labels.
I don't think that's necessarily true.
It may just mean that there's an additional set of possible responses
that the draft needs t
On 08/02/2018 14:18, Edward Lewis wrote:
> I am not saying this theory has been put to the test, but it is
> compelling. This hypothesis is in the ICANN deck on the KSK rollover
> used throughout 2017 (until the postponement).
Another hypothesis is configurations where the directory in which B
On 14/02/2018 23:06, Jan Komissar (jkomissa) wrote:
> Currently, there are only plans for DPN, and that would force every
> connection to be TLS.
DPN is the only current _extension_ to DSO.
DSO is also supposed to stand in its own right as a way to improve the
management of long-lived connecti
On 01/03/2018 12:37, internet-dra...@ietf.org wrote:
> Abstract: This document describes a method for automatic DNS zone
> provisioning among DNS primary and secondary nameservers by storing
> and transferring the catalog of zones to be provisioned as one or
> more regular DNS zones.
This versi
On 14/03/2018 22:07, Paul Wouters wrote:
> While I was initially afraid of abuse of this feature, the document has
> addressed this issue very well. So as long as implementors follow the
> specification, I think this document poses no privacy risk.
>
> I'm in favour of adoption.
>
> Some nits:
On 15/03/2018 10:01, Ray Bellis wrote:
>
> On 14/03/2018 22:07, Paul Wouters wrote:
>
>> It could mention DNS-COOKIES as one way to avoid spoofing issues.
>
> That sounds like a good idea.
On reflection (and discussion with one of my co-authors) we think that
would b
On 21/03/2018 15:14, John R. Levine wrote:
> The proposal changes the spec for naming SRV records, by replacing the
> existing service name registry with a new, different one, and vastly
> shrinking the list of known names. To me, that is nuts. It will
> retroactively make an unknown set of exis
On 22/03/2018 15:12, Dave Crocker wrote:
> In the case of SRV, for example, that means that for the core SRV
> template specification document:
>
> 1. The first-level, _Proto name assignment text has to be updated
> to use the new, Attrleaf global table.
>
> 2. The second-level _Servic
Dave,
I think this is much improved :)
A few nits:
> Each globally-registered underscore name owns a distinct, subordinate
> name space.
except when it doesn't (i.e. the SRV transports all share the *same*
subordinate name space).
- on that note, _sctp and _dccp are missing from the global tab
On 26/03/2018 20:49, John R. Levine wrote:
> Assuming we agree that the table also says where to find the registry
> for second level names, this removes and need for special cases. The
> top level names _tcp _udp _sctp _dccp all work for SRV and URI and take
> service names on the second level.
On 28/03/2018 15:43, Pieter Lexis wrote:
> The draft speaks of an OPCode in the IANA section and of a meta
> RRType in the examples and Introduction section, which is it?
>
> If it is an RRType, some words need to be added about the fact that
> current resolvers will pass through the MIXFR query
On 03/04/2018 08:33, Martin Thomson wrote:
> This is intended to do what? Indicate where the response came from?
> Why does the client care? I assume that it doesn't apply to
> requests, or that would get into draft-bellis-dnsop-xpf territory.
I think there's some overlap here, if the intent of
On 04/04/2018 04:39, Dave Lawrence wrote:
> I think that's right. -05 with the original_transport optional
> parameter accommodates the aims of that other draft.
but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a server to make policy dec
[added DOH WG to the cc:]
On 04/04/2018 04:39, Dave Lawrence wrote
> I think that's right. -05 with the original_transport optional
> parameter accommodates the aims of that other draft.
but ignores the concerns I raised yesterday that simply indicating "tcp"
or "udp" is insufficient to allow a
On 04/04/2018 13:20, Paul Vixie wrote:
> tcp and udp are the two ways a query might have reached the
> initiating proxy, and that distinction is the only thing the
> responding proxy needs to know.
I disagree, I don't think that transport protocols should continue to be
used as things that should
On 19/06/2018 15:43, tjw ietf wrote:
> I find it personally appalling we can spend so many cycles injecting
> dns into http but we can’t be bothered to fix what end users want.
It's the HTTP folks that are putting most of those cycles into DNS into
HTTP.
It's also their intransigence re: SRV whi
On 19/06/2018 17:44, Tony Finch wrote:
> SRV should have been part of the fix (and it was invented early
> enough to be!) but it wasn't a complete fix without support from the
> application protocols.
AIUI, a large part of the supposed issue with SRV was the inertia of the
installed base of brow
On 20/06/2018 10:40, Jan Včelák wrote:
> SRV also trades CNAME at apex for wildcard names support.
Yes, that's a fair point, and indeed one of the biggest issues with SRV.
Ray
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
On 22/06/2018 19:27, Evan Hunt wrote:
> Minor clarification here: ANAME doesn't require the authoritative
> server itself to do recursion; it requires it to have access to a
> reursive server.
Even that though requires that the authoritative server be capable of
waiting for an asynchronously retr
On 25/06/2018 16:05, Paul Wouters wrote:
> Then you might as well use that mechanism to update A/ records and
> skip the intermediate ANAME?
+1
Apex records are a provisioning problem, not a protocol one.
Ray
___
DNSOP mailing list
DNSOP@ietf.org
On 25/06/2018 22:08, John Levine wrote:
> One minor point in attrleaf, is whether to mention the poor
> interactions between _names and wildcards. One issue is that
> _blah.*.example doesn't work, the other is that *.example will match
> underscored names which can be surprising if it has RRs of
On 26/06/2018 13:10, Ondřej Surý wrote:
> I read the document and I think it’s good to go.
Same here.
Ray
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 02/07/2018 15:39, Paul Wouters wrote:
> If you are trusting an unsigned A record in the answer section, you might
> as well trust the unsigned record in the additional section too.
>
> I think minimum responses should still always just include this.
As others have pointed out, the proble
1 - 100 of 347 matches
Mail list logo
