[DNSOP] draft-tale-dnsop-serve-stale

Moin! As the mic line was closed after Mark, and I didn’t have anything new to say meaning I support the draft but don’t like the EDNS options before Mark spoke I use email to comment on Marks comments. We already have a mechanism where the Authority tells the resolver how long to cache stuf

[DNSOP] Protocol Action: 'A Root Key Trust Anchor Sentinel for DNSSEC' to Proposed Standard (draft-ietf-dnsop-kskroll-sentinel-17.txt)

The IESG has approved the following document: - 'A Root Key Trust Anchor Sentinel for DNSSEC' (draft-ietf-dnsop-kskroll-sentinel-17.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Ignas Bagdon

Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

Thanks very much for the review, Mukund! Puneet has already incorporated the editorial feedback into the GitHub copy. Mukund Sivaraman writes: >> "It is predicated on the observation that authoritative server >> unavailability can cause outages even when the underlying data >> those servers

Re: [DNSOP] Minimum viable ANAME

Paul Vixie wrote: > Ray Bellis wrote: > > On 21/09/2018 20:12, Dan York wrote: > > > I do think this is a path we need to go. We need *something* like > CNAME at the apex. Either CNAME itself or something that works in the > same way but might have a different name. > > [...] > > i think that ma

Re: [DNSOP] Minimum viable ANAME

> On 5 Nov 2018, at 2:06 pm, Paul Vixie wrote: > > > > Mark Andrews wrote: >> >>> On 4 Nov 2018, at 7:01 pm, Paul Vixie wrote: > ... >>> that would be a mistake. we are hitting for average here not power >>> -- the behaviour to optimize for is whatever's most common. if the >>> SRV is used,

[DNSOP] FYI - in v6OPS today - IPv6-Ready DNS/DNSSSEC Infrastructure

FYI, in the v6ops working group right now in Meeting 1 on the 7th floor, there is a draft that will be discussed (after two other drafts are discussed) that is: IPv6-Ready DNS/DNSSSEC Infrastructure https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00 Abstract: This documen

[DNSOP] Volunteers for Minutes Takers and Jabber Scribes

Hi DNSOP WG, We are looking for volunteers to take minutes and jabber scribe for the DNSOP WG meeting this afternoon 13:50-15:50. Please send an email to dnsop-chairs or reply directly. Otherwise we'll just have to ask at the start of the meeting. Thank you very much, -- Suzanne/Tim/Benno ___

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

On 11/4/2018 7:08 PM, Ray Bellis wrote: On 05/11/2018 09:56, Dave Crocker wrote: 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 Type    | _NODE NAME   | REFERENCE

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

On Mon, 5 Nov 2018 at 09:56, Dave Crocker wrote: > > On 11/4/2018 6:28 PM, Erik Kline wrote: > > One thing I missed earlier (and please forgive me if this was already > > discussed), was whether or not _example* should be reserved in the > > table in draft-ietf-dnsop-attrleaf-15#section-4.3. > > >

Re: [DNSOP] Minimum viable ANAME

Mark Andrews wrote: On 4 Nov 2018, at 7:01 pm, Paul Vixie wrote: that would be a mistake. we are hitting for average here not power -- the behaviour to optimize for is whatever's most common. if the SRV is used, the or A RRsets will be fetched, and thus cached. if the SRV is onl

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

On 11/4/2018 6:28 PM, Erik Kline wrote: One thing I missed earlier (and please forgive me if this was already discussed), was whether or not _example* should be reserved in the table in draft-ietf-dnsop-attrleaf-15#section-4.3. Basically, is there any value in reserving _example* for future RFCs

[DNSOP] FYI - in v6OPS today - IPv6-Ready DNS/DNSSSEC Infrastructure

FYI, in the v6ops working group right now in Meeting 1 on the 7th floor, there is a draft that will be discussed (after two other drafts are discussed) that is: IPv6-Ready DNS/DNSSSEC Infrastructure https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

Dave (others), One thing I missed earlier (and please forgive me if this was already discussed), was whether or not _example* should be reserved in the table in draft-ietf-dnsop-attrleaf-15#section-4.3. Basically, is there any value in reserving _example* for future RFCs to use (ones that don't c

Re: [DNSOP] Minimum viable ANAME

> On 4 Nov 2018, at 7:01 pm, Paul Vixie wrote: > > > > Ray Bellis wrote: >> >> >> On 04/11/2018 08:05, Ray Bellis wrote: >> >>> AFAIK, BIND does not currently do this. That said, MarkA has a patch >>> that supports it, so we do know it's possible. >> >> Correction - BIND *does* do this,

[DNSOP] CNAME at apex - a website publisher perspective - Re: Fundamental ANAME problems

> > On Nov 4, 2018, at 8:02 PM, Ray Bellis wrote: > > A lot of the whole "CNAME at the Apex" issue arises because lots of > marketing people don't want end users to have to type *or see* the www prefix. Exactly. As many of us traveled through various airports to get to Bangkok, there were m

[DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-12.txt

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 : A Common Operational Problem in DNS Servers - Failure To Respond. Authors : M. Andrews

Re: [DNSOP] DNS without Fragmentation (UDP and DF bit set)

Firstly you are insane to recommend dropping PTB’s. That will break lots of things including TCP. Secondly we could just use a well known TSIG key and have the authoritative servers add it to their configuration today, especially the root and TLDs servers. The recursive servers could also add

[DNSOP] DNS without Fragmentation (UDP and DF bit set)

It is time to drop fragmentation (and pMTU discovery) in DNS. A research paper showed that there are many authoritative servers that accept any ICMP destination unreachable / fragmentation needed and DF set (pMTU response packets) and reduce packet size up to 296 bytes. Path MTU discovery is contr

Re: [DNSOP] Fundamental ANAME problems

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

Re: [DNSOP] Fundamental ANAME problems

ray> Architecturally, the important part of my proposal is that ray> resolution of the A and records is done *at the recursive ray> layer* of the DNS, with no interference with how authoritative ray> resolution works. Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc th

Re: [DNSOP] Fundamental ANAME problems

ray> HTTP Redirects cause the URI in the address bar to be changed. A ray> lot of the whole "CNAME at the Apex" issue arises because lots of ray> marketing people don't want end users to have to type *or see* the ray> www prefix. ray> Those folks aren't going to stand for their nice clean ray> "e

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

On 11/3/2018 4:55 PM, Warren Kumari wrote: I'm also somewhat confused by the quoting in: "In the case of the "SRV" "RR" and "URI" "RR", distinguishing among different types"  (and in "defining "RR"s that might" ) - I'm not sure if it is intentional, but it doesn't align with much of the rest of

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt

Section 4.3 claims RFC7671 reserves "_dane": " ++--++ | RR Type| _NODE NAME | REFERENCE | ++--++ .. | TLSA | _dane| [RFC7671] | " I

Re: [DNSOP] Fundamental ANAME problems

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

Re: [DNSOP] Fundamental ANAME problems

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

Re: [DNSOP] Fundamental ANAME problems

On 4 Nov 2018, at 11:10, Ray Bellis wrote: > -1 :-) > What are the semantics of this? The semantics is exactly like a CNAME + HTTP Redirect. Provisioning is like any provisioning in the DNS, with the advantage that you can delegate the prefix:ed domain just like you can do with any _tcp and

Re: [DNSOP] Fundamental ANAME problems

Ray Bellis wrote: > > I don't think that either SRV or URI are usable for the primary use > case, i.e. allowing a domain owner to put a record at the apex of > their zone that points at the hostname of the web provider they want to > use. > > Is the apex thing an optimization only (i.e. is it acce

Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix

So, the new version of draft-ietf-dnsop-attrleaf-fix is posted -- https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ The diff from the previous is here: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-06 I **think** that this addresses the outstanding issues (modulo so

Re: [DNSOP] Fundamental ANAME problems

Ray Bellis wrote: > ... "URI RR" ... I see absolutely zero chance of the web community embracing this. as evidenced by RFC 8484, the web community seems to regret basing their work on the Internet System, and is now moving independently. this may mean that offering them something like "HT

Re: [DNSOP] Minimum viable ANAME

Ray Bellis wrote: On 04/11/2018 08:05, Ray Bellis wrote: AFAIK, BIND does not currently do this. That said, MarkA has a patch that supports it, so we do know it's possible. Correction - BIND *does* do this, but only for address records that are already in the cache. If the for the

Re: [DNSOP] Fundamental ANAME problems

On 04/11/2018 15:05, Paul Vixie wrote: as evidenced by RFC 8484, the web community seems to regret basing their work on the Internet System, and is now moving independently. this may mean that offering them something like "HTTP RR" which can't work better than SRV or URI already works, becaus

Re: [DNSOP] Fundamental ANAME problems

On 04/11/2018 12:53, Patrik Fältström wrote: On 3 Nov 2018, at 23:32, Måns Nilsson wrote: _http._tcp.example.org. IN URI 10 20 "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/"; We already have this. We need not build a new mechanism. +1 -1 What are the