On 31/01/2025 09:58, Ray Bellis wrote:
A nit: I'd prefer {"DUJ": [...]} over ["DUJ", [...]]
Although I see that PH has given a reasonable rationale for the use of
an array over an object, so, "meh".
Ray
___
D
On 31/01/2025 08:42, Libor Peltan wrote:
If I understand the background correctly, it might also help to declare
that the DNS software vendors SHOULD NOT develop tools that
automatically convert DUJ into DDNS and send it to a nameserver.
Why on earth not?!
DNS software vendors are going to b
On 2024/11/05 20:59, Robert Edmonds wrote:
Overall I think it might make sense to have an informational document
that describes the problem, the mechanisms that could be used in the
DNS to address that problem (various kinds of reordering at different
points in the stack, etc.), makes operatio
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
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 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
> 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/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
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
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 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
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 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 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 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 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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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/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 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 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 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 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
§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 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
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 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 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 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 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 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 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 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 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 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 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
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 16/05/2019 11:23, Petr Špaček wrote:
Personally I think it is not worth the effort, it will just add one more
RFC to read and does not help the protocol maintenance.
I would say that it is better to have one "cleanup" RFC instead of
one-off doc with one useful paragraph in it. With one big
On 11/05/2019 15:54, Dave Lawrence wrote:
I have a related question ... is allowing only targets on their own
infrastructure currently a limitation most such providers have?
I don't know about "most", but certainly some. See e.g. the attached
message posted here 2018/06/25.
Ray
--- Beg
19 07:00:14 -0700
From: internet-dra...@ietf.org
To: Ray Bellis , Peter van Dijk
, Alan Clegg
A new version of I-D, draft-bellis-dnsop-edns-tags-01.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.
Name: draft-bellis-dnsop-edns-tags
Revision:
On 25/03/2019 16:08, Puneet Sood wrote:
you mean lots of changes or lots of agreement with the quoted text?
They mean very different things.
I was agreeing with the quoted text - I believe that any serving of
stale records must be predicated on the presence of a valid delegation
from the
On 25/03/2019 10:41, Patrick McManus wrote:
I've seen this confusion before, so I can clear it up!
Ray is (I believe) referring to the flexible re-ordering of DNS
request-reply pairs of a TCP channel.. similar to HTTP/2 (though with
less flexibility in granularity iirc). That addresses hol
On 25/03/2019 09:28, Ian Swett wrote:
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
Head of line blocking shouldn't happen on a modern Do53 server.
See RFC 7766 §6.2.1.1
Ray
_
On 24/03/2019 12:36, Paul Vixie wrote:
in other words, we'd be negotiating for the right to re-interpret
existing signaling (the authority's TTL no longer purely governs the
data's lifetime) by insisting that the parent zone's delegating TTL be
given absolute power for revocation.
+lots
On 22/03/2019 08:33, Eric Rescorla wrote:
I'm not sure where you have attempted to clarify this point (I think
we've been clear on this point at
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/)
Regardless of what the default is, users will be able to disable DoH.
Rega
On 08/03/2019 18:33, 神明達哉 wrote:
For example, assume that an operator uses dnsdist as a DNS load
balancer and BIND 9 as backend servers with RRL, and the operator
wants to trust particular clients (identified by their IP addresses)
and bypass RRL for them. How can we expect off-the-shelf dnsd
On 08/03/2019 14:28, Paul Wouters wrote:
But assigned and left completely opague is not really suitable for
"heterogenous off-the-shelf software". These different vendors must
understand the meaning of the opaque data even if their functionality
can be non-standard.
No, it does *not* require t
On 08/03/2019 03:58, Paul Wouters wrote:
If you have a specific use case, get a code point for that specific use
case. Than you know for sure what the blob means and that it will be
interpreted by all parties in the same standard RFC way.
I have some generic use cases in mind (subject to the e
On 07/03/2019 16:57, Petr Špaček wrote:
Like this one?
https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/
Have you perhaps got anything constructive to contribute to the
discussion instead of pure hyperbole?
:p
Ray
___
DNSOP
On 05/03/2019 10:57, I wrote wrote:
(Just as BGP communities only have meaning between peers)
That should've been qualified "usually".
Ray
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 05/03/2019 10:54, Dick Franks wrote:
But that is not the case here. Even if the mechanism were to become
standardised and ubiquitous, each instance would be interoperable
only between two specific consenting parties. IMHO this falls into
the "local use" category.
I was talking interopera
On 05/03/2019 09:11, Shane Kerr wrote:
I don't see much value in this beyond the already-standardized EDNS
range reserved for local/experimental use.
Shane,
The additional value is being able to use the feature in off-the-shelf
DNS software.
Stretching the analogy to BGP communities sli
On 04/03/2019 23:03, Wes Hardaker wrote:
Hmmm.. very interesting idea, but I'm having a hard time seeing how
this will be used in the real world in a scalable and interoperable
way.
The use cases on the open internet are probably less interesting than
those were client and server have a m
On 05/03/2019 01:44, Paul Wouters wrote:
This makes me very nervous. An edge ISP DNS server could use this to
mark DNS packets from certain users, and applications could use this as
another cookie to track users, especially in light of endusers talking
directly to open resolvers like the Quad
On 04/03/2019 18:06, Ted Lemon wrote:
Any reason not to use DNS Stateful Operations for this?
I expect there's plenty of reasons to define a DSO equivalent, but I can
think of no reason to -constrain- this for use only with DSO.
Ray
___
DNSOP
popular OSS implementations can support similar features interoperably.
Ray
Forwarded Message
Subject: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Date: Mon, 04 Mar 2019 08:14:24 -0800
From: internet-dra...@ietf.org
To: Ray Bellis , Alan Clegg
A new version
On 19/11/2018 13:45, Mukund Sivaraman wrote:
Soon after this TSIG authentication bypass attack was reported, during a
review of the BIND TSIG implementation by Ray Bellis and me, we found a
couple of other issues. One of them is not a real-world issue (to do
with under-specification of what to
On 09/11/2018 09:30, Paul Vixie wrote:
i regret not adding ANY as an RR type (not just a Q type) back when
the DNS was small and i supported 90% of it. what we actually needed
is a wildcard on types so that if there's no more-specific type you
get that one, which would have an rdata of the
On 09/11/2018 07:14, Tony Finch wrote:
But remember: the goal is to make the DNS easier to use for people
who don’t know about the restrictions on CNAMEs.
I'd say the goal is to make the DNS *possible* to use for people who
don't know about the restrictions on CNAMEs.
I concede that ANAME pe
On 08/11/2018 11:47, Dan York wrote:
For that reason, wouldn't all the resolvers (or at least an extremely high %)
need to be upgraded to support the new record?
They don't _have_ to be, but performance is improved when they are
(since only an upgraded resolver will include the A and
On 08/11/2018 04:13, Tim Wicinski wrote:
I can't stress this enough - when you see ALIAS records at zone cuts
that point to a database server, already, then we've missed the
"server specific" ball.
This sounds like it ought to be a very unusual configuration.
Even with a zone cut, couldn't t
p.s. anyone thinking a new _generic_ resource record is required, please
(re)read RFC 5507.
HTTP started off with a service identifying prefix, but it was merely by
convention, and it was "www."
This whole mess started because folks wanted to get rid of that service
identifier, but a) didn't
On 07/11/2018 00:28, Tony Finch wrote:
* General purpose (also works for ssh, databases, etc) vs HTTP-specific
I just wanted to address this particular point, again.
IMHO, any record that doesn't support a service selector isn't doing its
job properly.
You _have_ to be able to say "i
On 06/11/2018 20:51, Joe Abley wrote:
Ray has wider aspirations than just the apex. This may well be
sensible, but I think it's worth calling out the scope creep.
It's in the intro text:
"This document specifies an "HTTP" resource record type for the DNS to
facilitate the lookup of the se
On 06/11/2018 20:44, Tony Finch wrote:
My understanding is that wildcards don't work for SRV because the
_prefixes are used to disambiguate which service you are asking for,
effectively to extend the RR TYPE number space. So if you wildcard a SRV
record then the target port has to support eve
On 06/11/2018 20:58, Patrik Fältström wrote:
We should also remember that there is a different goal as well, and
that is to be able to delegate the zone within which "the records
dealing with web" is managed so that the administrative
responsibility is separated between the one which run the z
On 06/11/2018 17:58, Matthijs Mekking wrote:
That's the crux: A solution that depends on upgrading the resolvers is
considered not a (fast enough) deployable solution.
The HTTP record does not depend on resolvers being upgraded. If the
browser vendors implement the client side, it's not
On 06/11/2018 17:17, Tim Wicinski wrote:
In doing some digging through my data, I have instances which I have an
apex of a zone, sub zone, etc that are not HTTP but actually a dynamic
database endpoint.
I also have solid number of instances where the apex is used mainly as
an API endpoin
On 06/11/2018 16:15, Matthijs Mekking wrote:
As nice and clean the HTTP record draft is, without specifying how to do
expansion of the record into address records it is not going to solve
the CNAME-at-the-apex problem that DNS providers have, and we will stick
with the proprietary solutions
On 06/11/2018 04:07, Joe Abley wrote:
Specifically, I s the wildcard owner name a real problem in the grand
scheme of things? I understand that wildcards are used by some people
for names that feature in HTTP URIs, but I'm struggling to imagine
using a wildcard at a zone cut; [...]
You're n
On 06/11/2018 00:36, Paul Vixie wrote:
second reply, on a more general topic:
the "HTTP URI" will require a change to bert's teaching resolver (tres),
which correctly handles unrecognized code points and thus would need no
changes at all if the additional data weren't mandatory. i think in
On 06/11/2018 00:32, Paul Vixie wrote:
please don't think this way, and don't do the right thing for the wrong
reasons. the paragraph above is how the camel came to be -- one draft at
a time, all well-meaning.
The front running alternative (ANAME) shifts the entire and far more
considerable
On 05/11/2018 18:55, Joe Abley wrote:
2. Find a client-side solution to this, and try really hard not to
invent something new that is really just SRV with a hat and a false
moustache.
There *is* a big failing of SRV that's independent of the CNAME apex use
case, and that is its lack of su
On 05/11/2018 12:51, Brian Dickson wrote:
It's a lot better than ANAME, and I think we do a disservice to
ourselves as a DNS community, if we do anything other than put our
collective support into it, preferably unanimously.
Thank for you the support!
I see getting http adopted and deploy
On 05/11/2018 09:56, Dave Crocker wrote:
Clever suggestion. Seems like obvious benefit with no obvious detriment.
So I immediately went to add it and then realized that doing this
cleanly will take an entry for each RR...
Why not this?
++--++
| RR
On 04/11/2018 23:02, Paul Ebersman wrote:
Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
that this is what they want, since they are largely driving all of this?
I'd guess that they would prefer this in the auth layer, where they own
or have contractual relationship
On 04/11/2018 18:16, Brian Dickson wrote:
Is the apex thing an optimization only (i.e. is it acceptable that
the mechanism for apex detection not be 100% effective)? I think
that's the input needed before it makes sense to go down any
particular branch of design work, by either the http folks or
On 04/11/2018 18:31, Patrik Fältström wrote:
The semantics is exactly like a CNAME + HTTP Redirect.
The latter part is what I expected, and why I think it's a non-starter.
HTTP Redirects cause the URI in the address bar to be changed. A lot of
the whole "CNAME at the Apex" issue arises be
1 - 100 of 344 matches
Mail list logo
