Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

On 08. 01. 19 17:30, Wes Hardaker wrote: > internet-dra...@ietf.org writes: > >> Title : Extended DNS Errors >> Filename: draft-ietf-dnsop-extended-error-04.txt > > FYI, updates from 03 to 04 include: > > 1. moving the unsupported algorithm codes to "NOERROR" > 2.

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On 7 Feb 2019, at 16:55, Ted Lemon wrote: On Feb 7, 2019, at 10:48 AM, Bob Harold wrote: If we write it down, perhaps we should also mention that other things that answer DNS queries, like load balancers, should also return proper SOA and NS records, not just A and records, for the

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Feb 7, 2019, at 10:48 AM, Bob Harold wrote: > If we write it down, perhaps we should also mention that other things that > answer DNS queries, like load balancers, should also return proper SOA and NS > records, not just A and records, for the same reasons. Are they currently

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Thu, Feb 07, 2019 at 09:40:24AM -0500, Ted Lemon wrote: > On Feb 7, 2019, at 9:16 AM, Tony Finch wrote: > > But in this scenario things soon go wrong, because RFC 2181 says the > > NODATA reply replaces the delegation records in the resolver's cache. This > > means that if a client explicitly

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon wrote: > On Feb 7, 2019, at 10:06 AM, Petr Špaček wrote: > > We (as developers in our office) all have had gut feeling that NS is > mandatory but we could not find it in the RFCs. > > > I hate to say it, but we should really make sure that this is

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On 07. 02. 19 16:48, Bob Harold wrote: > > On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon > wrote: > > On Feb 7, 2019, at 10:06 AM, Petr Špaček > wrote: >> We (as developers in our office) all have had gut feeling that NS is >>

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Feb 7, 2019, at 10:06 AM, Petr Špaček wrote: > We (as developers in our office) all have had gut feeling that NS is > mandatory but we could not find it in the RFCs. I hate to say it, but we should really make sure that this is actually stated somewhere where it can reasonably be found. If

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Feb 7, 2019, at 11:05 AM, Marius Olafsson wrote: > "The authoritative servers for a zone are enumerated in the NS records > for the origin of the zone, which, along with a Start of Authority > (SOA) record are the mandatory records in every zone." Problem solved. :)

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Petr Špaček wrote: > > We (as developers in our office) all have had gut feeling that NS is > mandatory but we could not find it in the RFCs. There's this bit in RFC 1034 which discusses zone cuts and says the NS RRset above and below the cut should be exactly the same. DNS admins are generally

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

Peter van Dijk wrote on 2019-02-07 06:41: ... I think it’s important to repeat that not only do I oppose adoption - any implementation, no matter the status of the document, will be *actively harmful to the DNS at large*. Please do not implement this. to be fair, the harm in terms of icmp

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

At Fri, 8 Feb 2019 00:39:27 +0530, Mukund Sivaraman wrote: > > The draft doubles the number of packets involved in a legitimate > > exchange; it more than doubles the number of packets involved in a > > spoofed exchange. About half of these packets are ICMP > > packets. Without the draft, ICMP

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

> I hate to say it, but we should really make sure that this is actually stated > somewhere where it can reasonably be found. If it is not, we should state > it. Petr was completely sensible to think it was the case but not be sure. > Saying that it is the case, and why it is the case,

[DNSOP] draft-ietf-dnsop-attrleaf vs. RFC7553

Hello everyone, I'm turning my head around an issue around the attrleaf draft, and its connection with RFC7553 (the URI RRType). Im specifically wondering what the connection between the "service parameter" in RFC 7553 and the "Global Underscore Node Names" in draft-ietf-dnsop-attrleaf is.

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Thu, Feb 07, 2019 at 01:16:01PM +0100, Petr Špaček wrote: > Is it mandatory or not? Should I submit erratum for RFC 1035? Please do so. If something that's widely accepted is not clearly stated, documenting it would be helpful both to implementors and also to point as reference when checking

Re: [DNSOP] draft-ietf-dnsop-attrleaf vs. RFC7553

In article <19f54f2956911544a32543b8a9bde0759fbcd...@nics-exch2.sbg.nic.at> you write: >I'm turning my head around an issue around the attrleaf draft, and its >connection with RFC7553 (the URI >RRType). Im specifically wondering what the connection between the "service >parameter" in RFC 7553

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Petr Spacek wrote: Subject: [Technical Errata Reported] RFC1035 (5626) I don't think errata is necessary. 5. At least one NS RR must be present at the top of the zone. At least two. Masataka Ohta

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Thu, Feb 7, 2019 at 6:42 PM Mark Andrews wrote: > > > > On 8 Feb 2019, at 10:28 am, Masataka Ohta < > mo...@necom830.hpcl.titech.ac.jp> wrote: > > > > Petr Spacek wrote: > > > >> Subject: [Technical Errata Reported] RFC1035 (5626) > > > > I don't think errata is necessary. > > Neither do I. >

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

> On 8 Feb 2019, at 12:53 pm, Joe Abley wrote: > > Ohta-san, > > On 7 Feb 2019, at 18:28, Masataka Ohta > wrote: > >> Petr Spacek wrote: >> >>>5. At least one NS RR must be present at the top of the zone. >> >> At least two. > > With respect, I think the protocol requirement is at

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

[ Top-post ] So, I've been staring at the Errata which Petr submitted, and trying to work out what to do. I'd like to mark it as either Verified, but the errata process cannot be used for fixing issues with the protocol itself, or adding additional restrictions which may cause compatibility

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Ohta-san, On 7 Feb 2019, at 18:28, Masataka Ohta wrote: > Petr Spacek wrote: > >>5. At least one NS RR must be present at the top of the zone. > > At least two. With respect, I think the protocol requirement is at least one, not at least two. I think best current practice is to avoid

Re: [DNSOP] [Ext] draft-ietf-dnsop-attrleaf vs. RFC7553

Dave moved the duct tape patching up all the places that defined underscored names to draft-ietf-dnsop-attrleaf-fix. See sections 2.3 and 2.3 for URI records. It's still a draft so if it seems wrong, send text. It is a draft, but it is has been in the RFC Editor's queue for 2.5 months.

Re: [DNSOP] [Ext] draft-ietf-dnsop-attrleaf vs. RFC7553

On Feb 7, 2019, at 11:29 AM, John Levine wrote: > > In article <19f54f2956911544a32543b8a9bde0759fbcd...@nics-exch2.sbg.nic.at> > you write: >> I'm turning my head around an issue around the attrleaf draft, and its >> connection with RFC7553 (the URI >> RRType). Im specifically wondering what

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

> On 8 Feb 2019, at 10:28 am, Masataka Ohta > wrote: > > Petr Spacek wrote: > >> Subject: [Technical Errata Reported] RFC1035 (5626) > > I don't think errata is necessary. Neither do I. >>5. At least one NS RR must be present at the top of the zone. > > At least two. And address

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Feb 7, 2019, at 23:12, Masataka Ohta wrote: >>> In short, this is an operational question with multiple answers and I don't >>> like the idea of formalising an over-simplistic restriction in the protocol >>> specification. > > How do you do IPv6 anycast with L servers? That question seems

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Mark Andrews wrote: A single anycast server DOES NOT and never can provide diversity from the client’s perspective. Additionally multiple servers in the same /24 (IPv4) or same /48 (IPv6) should be treated as a single server for diversity testing as these are accepted longest accepted

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On 7 Feb 2019, at 21:06, Mark Andrews wrote: > On 8 Feb 2019, at 12:53 pm, Joe Abley wrote: > >> Ohta-san, >> >> On 7 Feb 2019, at 18:28, Masataka Ohta >> wrote: >> >>> Petr Spacek wrote: >>> 5. At least one NS RR must be present at the top of the zone. >>> >>> At least two. >>

[DNSOP] RFC 1035 vs. mandatory NS at apex?

Hello dnsop, here is a quiz for experienced RFC archeologists: https://tools.ietf.org/html/rfc1035#section-5.2 section 5.2. Use of master files to define zones does not mention NS at apex at all, but it does explicitly mention SOA at apex. Can it be interpreted as if NS at apex is not mandatory?

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Feb 7, 2019, at 7:44 AM, Petr Špaček wrote: > When looking at it from resolver perspective, what is the resolver > supposed to do with query "zone. NS" if there is no authoritative NS set > in the zone? Return NOERROR+NODATA? It should reply with no error and no data. But this is okay,

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On 07. 02. 19 13:52, Ted Lemon wrote: > On Feb 7, 2019, at 7:44 AM, Petr Špaček > wrote: >> When looking at it from resolver perspective, what is the resolver >> supposed to do with query "zone. NS" if there is no authoritative NS set >> in the zone? Return

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On 07. 02. 19 13:39, Ted Lemon wrote: > Why would NS at the apex be mandatory? What breaks if it’s not there? > > (Playing the devil’s advocate—I’m also curious about this, but I think the > answer is that nothing breaks.) When looking at it from resolver perspective, what is the resolver

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

> On 7 Feb 2019, at 11:16 pm, Petr Špaček wrote: > > Hello dnsop, > > here is a quiz for experienced RFC archeologists: > > https://tools.ietf.org/html/rfc1035#section-5.2 > section 5.2. Use of master files to define zones > does not mention NS at apex at all, but it does explicitly mention

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

The "apex" terminology didn't come into vogue until later. Prior to that, people talked about the "top" of a zone. RFC 1034 Section 4.2.1 lays this out: "In the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative)". Admittedly "are found" doesn't sound

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Ted Lemon wrote: > On Feb 7, 2019, at 7:44 AM, Petr Špaček wrote: > > When looking at it from resolver perspective, what is the resolver > > supposed to do with query "zone. NS" if there is no authoritative NS set > > in the zone? Return NOERROR+NODATA? > > It should reply with no error and no

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

On Feb 7, 2019, at 9:16 AM, Tony Finch wrote: > But in this scenario things soon go wrong, because RFC 2181 says the > NODATA reply replaces the delegation records in the resolver's cache. This > means that if a client explicitly asks for the NS records of a zone that > lacks them, resolution for

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

On 6 Feb 2019, at 9:08, Mukund Sivaraman wrote: Considering that the method is implementable without any changes at a resolver, and that it doesn't require compatible behavior among DNS implementations ("protocol" or best practice), I suppose it does not matter if this draft is adopted or not

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Thank you Kevin and Tony! We (as developers in our office) all have had gut feeling that NS is mandatory but we could not find it in the RFCs. Thank you for your time! Petr Špaček @ CZ.NIC On 07. 02. 19 14:53, Kevin Darcy wrote: > The "apex" terminology didn't come into vogue until later.