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 : Message Digest for DNS Zones
Authors : Duane Wessels
Piet Barber
> On 7 Nov 2018, at 4:54 pm, Ben Schwartz wrote:
>
>
>
> On Tue, Nov 6, 2018 at 5:53 PM Mark Andrews wrote:
>
>
> > On 7 Nov 2018, at 9:25 am, Ben Schwartz wrote:
> >
> >
> >
> > On Tue, Nov 6, 2018 at 5:06 PM Mark Andrews wrote:
> >
> >
> > > On 6 Nov 2018, at 5:27 am, Ben Schwartz
On Tue, Nov 6, 2018 at 5:53 PM Mark Andrews wrote:
>
>
> > On 7 Nov 2018, at 9:25 am, Ben Schwartz wrote:
> >
> >
> >
> > On Tue, Nov 6, 2018 at 5:06 PM Mark Andrews wrote:
> >
> >
> > > On 6 Nov 2018, at 5:27 am, Ben Schwartz 40google@dmarc.ietf.org> wrote:
> > >
> > > On Sat, Nov 3, 2018
I changed Subject.
Let me clarify confusions on SRV and ALTSRV.
On 2018/11/07 7:05, Mark Andrews wrote:
On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren wrote:
How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to >> make it more DNS-aligned (e.g. the name as a separate field in the>>
Here are the draft minutes from the Monday session. Thanks to Thomas for
taking them and others for pitching in.
https://datatracker.ietf.org/doc/minutes-103-dnsop/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 6 Nov 2018, at 22:30, Ray Bellis wrote:
> You can have wildcard support, or you can have prefixes (hence
> delegation), but you can't have both.
Thats exactly my point. URI solves "the other problem".
Patrik
signature.asc
Description: OpenPGP digital signature
___
> On 7 Nov 2018, at 9:25 am, Ben Schwartz wrote:
>
>
>
> On Tue, Nov 6, 2018 at 5:06 PM Mark Andrews wrote:
>
>
> > On 6 Nov 2018, at 5:27 am, Ben Schwartz
> > wrote:
> >
> > On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren wrote:
> > How does draft-schwartz-httpbis-dns-alt-svc-02 with some
> On 6 Nov 2018, at 5:27 am, Ben Schwartz
> wrote:
>
> On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren wrote:
> How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it
> more DNS-aligned (e.g. the name as a separate field in the record) not help
> here?
>
> Thanks for mentio
Ray Bellis wrote:
> 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.
Yes.
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
Ray Bellis wrote:
> On 06/11/2018 20:44, Tony Finch wrote:
>
> > If you are using an _prefix without any meaning of its own but only to
> > move a record away from the apex (so that it can be delegated or CNAMEd)
> > and also using a specific RR type or an RDATA prefix, then wildcards do
> > not c
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
I'm going to use Richard's message as a starting point because I wanted to
write about fallback addresses, but I have kind of changed my mind so this
message is really about the possibility of deeper reductions / revisions
to the ANAME draft.
Richard Gibson wrote:
> On 11/2/18 15:20, Bob Harold
Olli,
> On Nov 6, 2018, at 3:23 PM, Olli Vanhoja wrote:
>
> In fact if you look at the DNS records some big Internet companies
> they rarely use CNAMEs for www but instead you'll see an A record, that might
> be even backed by a proprietary ANAME solution.
One detail about this is that if the C
> On Nov 6, 2018, at 17:27, Mukund Sivaraman wrote:
>
> We talked about DNSSEC and certificate signing and such. If the host
> serving this webpage to the browser has control over the webpage's
> content (e.g., the contents of that src attribute), and the webpage's
> contents are already authentic
On 6 Nov 2018, at 17:51, Joe Abley wrote:
>> On Nov 6, 2018, at 20:44, Tony Finch wrote:
>>
>> Joe Abley wrote:
>>>
>>> Specifically, I s the wildcard owner name a real problem in the grand
>>> scheme of things?
>>
>> My understanding is that wildcards don't work for SRV because the
>> _prefixes
Hi Tony.
> On Nov 6, 2018, at 20:44, Tony Finch wrote:
>
> Joe Abley wrote:
>>
>> Specifically, I s the wildcard owner name a real problem in the grand
>> scheme of things?
>
> My understanding is that wildcards don't work for SRV because the
> _prefixes are used to disambiguate which service yo
> On 6 Nov 2018, at 11:38 pm, Matthijs Mekking wrote:
>
>
>
> On 06-11-18 12:39, Ray Bellis wrote:
>> 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 re
Joe Abley wrote:
>
> Specifically, I s the wildcard owner name a real problem in the grand
> scheme of things?
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
On 06-11-18 12:39, Ray Bellis wrote:
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 vendo
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-18 10:19, Ray Bellis wrote:
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
wi
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
Hi all
It seemed that the objective (or an objective) of what is desired is for
a webpage to have an and also push an address record for
the hostname in the src URL.
We talked about DNSSEC and certificate signing and such. If the host
serving this webpage to the browser has control over the webp
That may be the case from your own (presumably anecdotal) experience, however I
took the Alexa top 1 million websites and queried for A* and CNAME against the
www records for the top 10 000 domains. What I found is that approximately 44%
returned CNAME records, 56% returning A records.
Code
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 endpoint, that serves not HTTP web content.
just data poi
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
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 (this may solve a different use case though).
B
> > The semantics is exactly like a CNAME + HTTP Redirect.
>
> The latter part is what I expected, and why I think it's a non-starter.
>
> HTTP Redirects cause the URI in the address bar to be changed. A lot of
> the whole "CNAME at the Apex" issue arises because lots of marketing
> people don't w
32 matches
Mail list logo
