Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

In section 3.21 3.21. Extended DNS Error Code 20 - Lame An authoritative server that receives a query (with the RD bit clear) for a domain for which it is not authoritative SHOULD include this EDE code in the SERVFAIL response. A resolver that receives a query (with the RD bit

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/9/19 7:07 AM, Tony Finch wrote: > BIND's default lame-ttl is 10 minutes; I don't know if other resolvers > have a similar feature. It might be better from your point of view if the > lame-ttl matched the delegation TTL, but I bet that would be a bit > frustrating for operators who set up a

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 10:59 AM, Ted Lemon wrote: > BTW, it would also be perfectly legitimate for an authoritative server > that doesn’t provide recursion to respond with NXDOMAIN for any query > within a domain that’s delegated to it, But again, since you have no SOA to return, you have no record to

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 11:05 AM, Ted Lemon wrote: > Notice: This email is from an external sender. > > > > The parent zone TTL would work fine. What parent zone??? .. ? com. ? I'm not authoritative for those. Any response I send for the parent should be ignored completely. And it still leaves the issue

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 10:56 AM, Paul Vixie wrote: > i've always sent back SERVFAIL when the zone isn't loaded, on either a primary > or secondary (authoritative, that is) server. and i cache SERVFAIL on the > recursive/iterative side with a holddown timer equal to the negative TTL > interval (SOA.MINIMUM).

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 10:13 AM, Ted Lemon wrote: > Notice: This email is from an external sender. > >   > > On Jul 8, 2019, at 1:04 PM, Michael J. Sheldon <mailto:mshel...@godaddy.com>> wrote: >> Neither solution >> is good, and the second one, while probably justifi

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

On 7/8/19 9:50 AM, Ted Lemon wrote: > Notice: This email is from an external sender. > >   > > On Jul 8, 2019, at 12:42 PM, Michael J. Sheldon <mailto:mshel...@godaddy.com>> wrote: > To put it another way, if you get a REFUSED from a server, that server > is

[DNSOP] Caching of negative zone (non-authoritative) responses

This is something that has bugged me for a long time, and I'd love to see a good solution to. If a record is requested from an authoritative server, where the zone exists, but the records does not exist, the negative response is cached for period of time. If a record is requested from an

Re: [DNSOP] ANAME in answer or additional section [issue #62]

On 6/11/19 5:53 AM, Bob Harold wrote: > > If the camel was not already overloaded, then a cautious approach might > be to put it in the additional section, *unless* there was a capability > signal in the request that indicated that the requester would understand > ANAME, or at least not have a

Re: [DNSOP] Deprecating the status opcode

On 5/16/19 3:23 AM, Petr Špaček wrote: > Notice: This email is from an external sender. > > > > On 15. 05. 19 19:57, Bob Harold wrote: >> >> On Wed, May 15, 2019 at 1:00 PM John Levine > > wrote: >> >> In article <064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com >>

Re: [DNSOP] Related Domains By DNS (RDBD) Draft

Section 1: Current issues #1 says "use TXT or new RR? (ATB: new RR, but TXT for now)" Is there a single person here who believes this? Once implemented as TXT, I give the odds of seeing a specific type record being implemented as less than zero. Pick one, don't tease. Section 2: I am

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

On 2/14/19 12:51 PM, Stephane Bortzmeyer wrote: > On Mon, Jan 07, 2019 at 12:30:10PM -0800, > internet-dra...@ietf.org wrote > a message of 44 lines which said: > >> Title : Extended DNS Errors >> Authors : Warren Kumari >> Evan Hunt

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

On 11/07/2018 02:13 PM, Tim Wicinski wrote: > Tony says this: > > " It isn't a judgment about what's good, but an observation about what > is done." > > 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