[DNSOP] FYI: draft-andrews-dnsop-defeat-frag-attack

I’ve written up a method to defeat UDP fragmentation attacks using TSIG. https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00 If we are going to discuss methods to defeat such attacks this should be considered. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Austra

Re: [DNSOP] Proposal: Whois over DNS

Take activedisplay.org.uk. The DNS server for this zone has a broken DNS COOKIE implementation (see the mismatch between the request cookie and the response cookie). COOKIE: 5dc8e2253d5f2702 COOKIE: e0d5650141611e0110474b000300dce86501ad361e01 % dig ns1.activedisplay.org.uk @88.208.234.46 +

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

Hi, Two comments: 1. Maybe I'm confused but it seems to me that the RESPONSE-CODE field of 12 bits plus the INFO-CODE field of 16 bits is 28 bits. So I don't understand the 2nd paragraph of Section 3.3 that talks about their concatenation fitting within 24 bits. 2. On the code poin

[DNSOP] Admin note: Change in affiliation

Colleagues, As some of you might have heard, I’ve started a new position with PIR, the operator of the .org TLD. I’m noting this primarily in the interests of transparency, particularly on two points: First, I’m reporting to Joe Abley, CTO of PIR and a regular contributor to DNSOP. It happens

Re: [DNSOP] Proposal: Whois over DNS

— John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 19:41, Paul Vixie wrote: > > > John Bambenek wrote on 2019-07-09 17:29:> >> On

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

Yes, something like that could work, but you’d have to document it. Sent from my iPhone > On Jul 9, 2019, at 7:58 PM, Mark Andrews wrote: > > > >> On 9 Jul 2019, at 10:53 pm, Ted Lemon wrote: >> >> On Jul 9, 2019, at 12:00 AM, Mark Andrews wrote: >>> Actually if a DNS operator is requesti

Re: [DNSOP] Fwd: HTTPSSVC record draft

Will AWS Support this? That seems to be all I see deployed now On Tue, Jul 9, 2019 at 8:44 PM Paul Vixie wrote: > > > Joe Abley wrote on 2019-07-09 17:35: > > On Jul 9, 2019, at 20:11, Paul Vixie wrote: > > > >> everything other than HTTPS can just use SRV. > >> > >> ANAME is (should be) toast

Re: [DNSOP] Fwd: HTTPSSVC record draft

Joe Abley wrote on 2019-07-09 17:35: On Jul 9, 2019, at 20:11, Paul Vixie wrote: everything other than HTTPS can just use SRV. ANAME is (should be) toast(ed). Didn't we get to this point by acknowledging that there was a gap between now and the glorious future where SRV and unnamed alter

Re: [DNSOP] Proposal: Whois over DNS

John Bambenek wrote on 2019-07-09 17:29:> On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 19:13, Paul Vixie wrote: whois and rdap servers are

Re: [DNSOP] Fwd: HTTPSSVC record draft

On Jul 9, 2019, at 20:11, Paul Vixie wrote: > everything other than HTTPS can just use SRV. > > ANAME is (should be) toast(ed). Didn't we get to this point by acknowledging that there was a gap between now and the glorious future where SRV and unnamed alternatives for HTTPS, and that the gap was

Re: [DNSOP] Proposal: Whois over DNS

Below. — John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 19:13, Paul Vixie wrote: >> On Tuesday, 9 July 2019 21:56:49 UTC John Bam

Re: [DNSOP] Proposal: Whois over DNS

On Tuesday, 9 July 2019 21:56:49 UTC John Bambenek wrote: > How would having an SRV record and an entirely different (currently > undeveloped) service help the situation? whois and rdap servers are a dime a dozen. i can run one for all of my domains, and put it behind a rate limiter to make life

Re: [DNSOP] Fwd: HTTPSSVC record draft

On Tuesday, 9 July 2019 21:49:50 UTC Mark Andrews wrote: > Which invariable ends up being needed to be split over multiple machines for > different protocols. ANAME can’t do that splitting. > > ANAME if it continues to exist needs rules like MX. It also needs to be > explicitly looked for by the

Re: [DNSOP] Proposal: Whois over DNS

On Mon, Jul 08, 2019 at 02:42:25PM -0700, Bill Woodcock wrote: > > In response to ICANN essentially removing most of the fields in WHOIS > > for domain records, Richard Porter and myself created a draft of an > > implementation putting these records into DNS TXT records. It would require > > self-

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

> On 9 Jul 2019, at 10:53 pm, Ted Lemon wrote: > > On Jul 9, 2019, at 12:00 AM, Mark Andrews wrote: >> Actually if a DNS operator is requesting that NS records pointing to them be >> removed then the TLD only need to look at the enclosing SOA of NS’s address >> records to find a valid contac

Re: [DNSOP] Proposal: Whois over DNS

On Wed, Jul 10, 2019 at 1:07 AM Joe Abley wrote: > > Hi John, > > On 9 Jul 2019, at 10:36, John Bambenek wrote: > > > If the proposal is to create a standard by which to put contact > > information into DNS records, what venue would you suggest? > > I think that the protocol aspects of this are t

Re: [DNSOP] Proposal: Whois over DNS

How would having an SRV record and an entirely different (currently undeveloped) service help the situation? If its a question of query logs, the consequence of putting any service (smtp, web, slack) in the hands of a third-party is they need to provide that (if you pay them) or you don’t get i

Re: [DNSOP] Fwd: HTTPSSVC record draft

Which invariable ends up being needed to be split over multiple machines for different protocols. ANAME can’t do that splitting. ANAME if it continues to exist needs rules like MX. It also needs to be explicitly looked for by the application. Add a flag to getaddrinfo() if one wants to make t

Re: [DNSOP] Proposal: Whois over DNS

Below — John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 16:21, Brian Dickson wrote: > > >> On Tue, Jul 9, 2019 at 2:01 PM John Ba

Re: [DNSOP] Proposal: Whois over DNS

On Tue, Jul 9, 2019 at 2:01 PM John Bambenek wrote: > Below > > — > John Bambenek > > On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 > license which means commercial use will require a license. Contact > sa...@bambenekconsulting.com for details > > On Jul 9, 2019, at 15:51, J

Re: [DNSOP] Proposal: Whois over DNS

Below — John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 15:51, Jim Reid wrote: >> On 9 Jul 2019, at 17:43, John Bambenek >> wrote

[DNSOP] dictionary of registration data elements

> On 9 Jul 2019, at 17:26, Steve Crocker wrote: > > I would strongly support an effort within the IETF to create and maintain a > dictionary of registration data elements. This would probably be in the form > of an IANA-maintained registry, with oversight from DNSOP. Hmmm. That might be a b

Re: [DNSOP] Proposal: Whois over DNS

On 9 Jul 2019, at 17:43, John Bambenek wrote: > > I guess I'm not understanding the risks of people accidentally disclosing > what they don't intend to. I suggest you learn more about GDPR. The penalties for non-compliance can hurt - up to 4% of global turnover. Some CIOs are learning this t

Re: [DNSOP] Proposal: Whois over DNS

On Jul 9, 2019, at 2:32 PM, John Bambenek wrote: > Then why do we allow them to have social media accounts, email accounts, etc? > We don’t. > How many RFCs involve using passwords somewhere in them? We know users pick > bad passwords. We know users reuse passwords. And we know credential theft

Re: [DNSOP] Proposal: Whois over DNS

Then why do we allow them to have social media accounts, email accounts, etc? How many RFCs involve using passwords somewhere in them? We know users pick bad passwords. We know users reuse passwords. And we know credential theft and misuse is a big problem. Were these same considerations given to

Re: [DNSOP] Proposal: Whois over DNS

On Jul 9, 2019, at 2:04 PM, John Bambenek wrote: > Can't this be mitigated by any number of forms of user education? The evidence is crystal clear on this point: no, it can’t. It is not possible for a person who is informed on this topic to believe otherwise.

Re: [DNSOP] Proposal: Whois over DNS

> > Another way to put it: if a system requires you think and > exercise care to stay safe, that means the system itself is by > default unsafe. Building unsafe systems is not good engineering > practice. > If we adhere to this we should just stop engineering anything for any purpose. It's litera

Re: [DNSOP] Proposal: Whois over DNS

> John Bambenek > wrote: > > > But is the risk to self-identification as present when > > role-based accounts could be used as opposed to PII? I guess > > I'm not understanding the risks of people accidentally > > disclosing what they don't intend to. > > The risk is this: until people have been b

Re: [DNSOP] Proposal: Whois over DNS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 John Bambenek wrote: > > But is the risk to self-identification as present when > role-based accounts could be used as opposed to PII? I guess > I'm not understanding the risks of people accidentally > disclosing what they don't intend to. The ris

Re: [DNSOP] Proposal: Whois over DNS

I'll look at ETSI. But is the risk to self-identification as present when role-based accounts could be used as opposed to PII? I guess I'm not understanding the risks of people accidentally disclosing what they don't intend to. On 7/9/19 11:27 AM, Vittorio Bertola wrote: >> Il 9 luglio 2019 16:36

Re: [DNSOP] Proposal: Whois over DNS

I generally agree with this and have no problem deferring to an effort to create a dictionary of registration data elements and agreed upon definitions. I gave serious thought to just making the current proposal have one contact class, I kept several more for consistency with the legacy system, bu

Re: [DNSOP] Proposal: Whois over DNS

> Il 9 luglio 2019 16:36 John Bambenek > ha scritto: > > > I agree with pretty much everything else Jim said, but really this seems > > like the core issue: this seems like a proposal in the wrong venue. > > If the proposal is to create a standard by which to put contact > information into DNS

[DNSOP] Proposal: Whois over DNS

Folks, Let me share a somewhat broader perspective. I was chair of the ICANN board for several years. During that period, I attempted, without success, to reset the dialog related to whois. After I stepped off the board in late 2017, I decided to take another run at the problem. I've been work

Re: [DNSOP] Proposal: Whois over DNS

Yes, I can do that. On 7/9/19 11:12 AM, Paul Wouters wrote: > On Tue, 9 Jul 2019, John Bambenek wrote: > >> On 7/9/19 11:00 AM, Ted Lemon wrote: >>   On Jul 9, 2019, at 11:41 AM, John Bambenek >> wrote: >>     You assume I'm going to create a huge database, I am not. >> I would envisi

Re: [DNSOP] Proposal: Whois over DNS

On 7/9/19 11:09 AM, Ted Lemon wrote: > On Jul 9, 2019, at 12:03 PM, John Bambenek > > wrote: >> I cannot coerce anything. I represent nothing that represents even a >> molecule of the network to coerce or enforce anything. I hope incentives >> w

Re: [DNSOP] Proposal: Whois over DNS

On Tue, 9 Jul 2019, John Bambenek wrote: On 7/9/19 11:00 AM, Ted Lemon wrote: On Jul 9, 2019, at 11:41 AM, John Bambenek wrote: You assume I'm going to create a huge database, I am not. I would envision doing something like if you send me email, try to connect, e

Re: [DNSOP] Fwd: HTTPSSVC record draft

Erik Speaking as myself and not a chair, I see way too many use cases which are API end points using ANAME like features. Those aren't browser based. I would hope for a solution which would work across all solution spaces - not just web browsers. Tim (speaking only as myself) On Mon, Jul 8, 20

Re: [DNSOP] Proposal: Whois over DNS

On Jul 9, 2019, at 12:03 PM, John Bambenek wrote: > I cannot coerce anything. I represent nothing that represents even a > molecule of the network to coerce or enforce anything. I hope incentives > will be created, and those may be purely positive incentives (mails more > likely to be delivered,

Re: [DNSOP] Proposal: Whois over DNS

On 7/9/19 10:27 AM, Jim Reid wrote: >> John Bambenek wrote: >> >>> Why? GDPR applies to IP addresses that, doesn't impact DNS yet. > GDPR applies to *any* data which identifies a living European citizen. > > If you think it only applies to IP addresses you are very badly mistaken. > GDPR will a

Re: [DNSOP] Proposal: Whois over DNS

On 7/9/19 11:00 AM, Ted Lemon wrote: > On Jul 9, 2019, at 11:41 AM, John Bambenek > > wrote: >> You assume I'm going to create a huge database, I am not. I would >> envision doing something like if you send me email, try to connect, >> etc, ther

Re: [DNSOP] Proposal: Whois over DNS

> Hello, > > John Bambenek > wrote: > >> All whois data is PII, in the case where people register > >> individual details, as opposed to organizational roles. I think > >> you may need to do a bit more research on this topic, you seem to > >> have misunderstood a thing or two. > > > You could set

Re: [DNSOP] Proposal: Whois over DNS

On Jul 9, 2019, at 11:41 AM, John Bambenek wrote: > You assume I'm going to create a huge database, I am not. I would envision > doing something like if you send me email, try to connect, etc, there is a > DNS query for this information, much like there are queries for DBLs, SPF et > al, and s

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] Proposal: Whois over DNS

Not intended to debate, per se. On 7/9/19 10:21 AM, Ted Lemon wrote: > As far as I can tell, you are deflecting my serious concerns rather > than responding to them.   I’m asking you to describe an actual > situation where the information you want us to publish would (a) be > published and (b) /ac

Re: [DNSOP] Proposal: Whois over DNS

> > Folks, Let me share a somewhat broader perspective. I was chair of the ICANN board for several years. During that period, I attempted, without success, to reset the dialog related to whois. After I stepped off the board in late 2017, I decided to take another run at the problem. I've been

Re: [DNSOP] Proposal: Whois over DNS

> John Bambenek wrote: > > > Why? GDPR applies to IP addresses that, doesn't impact DNS yet. GDPR applies to *any* data which identifies a living European citizen. If you think it only applies to IP addresses you are very badly mistaken. GDPR will also apply to anything in the DNS which happ

Re: [DNSOP] Proposal: Whois over DNS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, John Bambenek wrote: > > All whois data is PII, in the case where people register > > individual details, as opposed to organizational roles. I think > > you may need to do a bit more research on this topic, you seem to > > have misunderstoo

Re: [DNSOP] Proposal: Whois over DNS

As far as I can tell, you are deflecting my serious concerns rather than responding to them. I’m asking you to describe an actual situation where the information you want us to publish would (a) be published and (b) actually work as a means of notifying some real person of something, or prosec

Re: [DNSOP] Proposal: Whois over DNS

> Hi :-) > > John Bambenek wrote: > >> That said, I agree it cannot solve GDPR or other policy concerns. > > > Why? GDPR applies to IP addresses, that doesn't impact DNS yet. > > You appear to have confused IP with P(I)I: personally identifying > information. > > All whois data is PII, in the case

Re: [DNSOP] Proposal: Whois over DNS

Below On 7/9/19 10:07 AM, Joe Abley wrote: > Hi John, > > On 9 Jul 2019, at 10:36, John Bambenek wrote: > >> If the proposal is to create a standard by which to put contact >> information into DNS records, what venue would you suggest? > I think that the protocol aspects of this are the least dif

Re: [DNSOP] Proposal: Whois over DNS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi :-) John Bambenek wrote: > > That said, I agree it cannot solve GDPR or other policy concerns. > > Why? GDPR applies to IP addresses, that doesn't impact DNS yet. You appear to have confused IP with P(I)I: personally identifying information. A

Re: [DNSOP] Proposal: Whois over DNS

This is true with DKIM today which uses a label. On 7/9/19 10:05 AM, Jim Reid wrote: > >> On 9 Jul 2019, at 15:50, John Bambenek >> wrote: >> >> I'm not married to any name, I chose WHOIS for historical reasons. We can >> call it _hamsandwich if it builds consensus. > The concern here isn't wha

Re: [DNSOP] Proposal: Whois over DNS

Hi John, On 9 Jul 2019, at 10:36, John Bambenek wrote: > If the proposal is to create a standard by which to put contact > information into DNS records, what venue would you suggest? I think that the protocol aspects of this are the least difficult ones. If this is fundamentally the data gover

Re: [DNSOP] Proposal: Whois over DNS

> On 9 Jul 2019, at 15:50, John Bambenek > wrote: > > I'm not married to any name, I chose WHOIS for historical reasons. We can > call it _hamsandwich if it builds consensus. The concern here isn't what the label is called. Prepending a label won't work with absurdly long domain names beca

Re: [DNSOP] Proposal: Whois over DNS

I'm not married to any name, I chose WHOIS for historical reasons. We can call it _hamsandwich if it builds consensus. On 7/9/19 9:37 AM, Rubens Kuhl wrote: > > I like the overall idea, but I believe we should let go the name > WHOIS. What about "_contact" for the fields instead of "_whois" ?  > I

Re: [DNSOP] Proposal: Whois over DNS

> Hello everyone, > > Jim Reid wrote: > > > BTW, whois was originally intended to provide a way to publish > > out-of-band contact data so the domain holder could be > > contacted whenever their DNS or email was broken. Putting this > > info in the DNS would defeat that. > > Implementation details

Re: [DNSOP] Proposal: Whois over DNS

> On 9 Jul 2019, at 15:15, Bjarni Rúnar Einarsson wrote: > > I think having a technical specification like this would be quite interesting > from the point of view of automatically updates to existing Whois databases, > without requiring the registrant directly (or indirectly) interact with

Re: [DNSOP] Proposal: Whois over DNS

On Tuesday, 9 July 2019 14:36:50 UTC John Bambenek wrote: > Below > > ... john, (all,) my own prior review of this proposal was effectively neutral but actually negative. dns does not permit the kind of rate limiting and logging needed by individual domain holders around their whois details unl

Re: [DNSOP] Proposal: Whois over DNS

Below On 7/9/19 9:28 AM, Ted Lemon wrote: > On Jul 9, 2019, at 10:07 AM, John Bambenek > > wrote: >> But ICANN won’t allow such a system with meaningful data, so here we >> are.  > > The question you should be asking is “why not?”   The answer i

Re: [DNSOP] Proposal: Whois over DNS

I like the overall idea, but I believe we should let go the name WHOIS. What about "_contact" for the fields instead of "_whois" ? I like the All record as an option. I don't agree with your reasoning for this, but we can agree on something to be done for different reasons, too. I understan

Re: [DNSOP] Proposal: Whois over DNS

Below On 7/9/19 9:25 AM, Joe Abley wrote: > On 9 Jul 2019, at 10:07, John Bambenek > wrote: > >> On Jul 9, 2019, at 08:32, Jim Reid wrote: >> >>> 2. These policy problems are out of scope for the IETF. It deals with >>> technical and operational matters around protocol design and deployment.

Re: [DNSOP] Proposal: Whois over DNS

On Jul 9, 2019, at 10:07 AM, John Bambenek wrote: > But ICANN won’t allow such a system with meaningful data, so here we are. The question you should be asking is “why not?” The answer is that nobody whose info you need will publish it, because the info you need is from people who are engag

Re: [DNSOP] Proposal: Whois over DNS

On 9 Jul 2019, at 10:07, John Bambenek wrote: > On Jul 9, 2019, at 08:32, Jim Reid wrote: > >> 2. These policy problems are out of scope for the IETF. It deals with >> technical and operational matters around protocol design and deployment. >> Policy issues are handled in other fora - like I

Re: [DNSOP] Proposal: Whois over DNS

To go along with this proposal, maybe we can adapt the approach from RFC3514 for DNS? We could send a new RRTYPE with a bitfield value, giving a more granular level of detail than that in RFC3514. RFC3514 was constrained to only use one bit because IP headers are small; with DNS, we don't have

Re: [DNSOP] Proposal: Whois over DNS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello everyone, Jim Reid wrote: > > BTW, whois was originally intended to provide a way to publish > out-of-band contact data so the domain holder could be > contacted whenever their DNS or email was broken. Putting this > info in the DNS would de

Re: [DNSOP] Proposal: Whois over DNS

Below — John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 08:32, Jim Reid wrote: >> On 8 Jul 2019, at 22:38, John Bambenek >> wrote

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

Michael J. Sheldon wrote: > > If a record is requested from an authoritative server, where the zone > does not exist, generally the response is REFUSED, but *this is not > cached* by the requesting server. This results in a nearly continuous > stream of retries, which continue to result in the sam

Re: [DNSOP] proposal: Covert in-band zone data

Hi Tony, On 9 Jul 2019, at 09:24, Tony Finch wrote: > Joe Abley wrote: > >> There is hence an operational risk that data will leak (e.g. by >> configuration changes, software downgrades that are pragmatic >> necessities, side systems that publish zone data in ways other than the >> DNS). >> >

Re: [DNSOP] Proposal: Whois over DNS

On 8 Jul 2019, at 22:38, John Bambenek wrote: > > In response to ICANN essentially removing most of the fields in WHOIS for > domain records, Richard Porter and myself created a draft of an > implementation putting these records into DNS TXT records. It would require > self-disclosure which m

Re: [DNSOP] proposal: Covert in-band zone data

Joe Abley wrote: > > There is hence an operational risk that data will leak (e.g. by > configuration changes, software downgrades that are pragmatic > necessities, side systems that publish zone data in ways other than the > DNS). > > By keeping data that is already exchanged over a (manual) out-o

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

On Jul 9, 2019, at 12:00 AM, Mark Andrews wrote: > Actually if a DNS operator is requesting that NS records pointing to them be > removed then the TLD only need to look at the enclosing SOA of NS’s address > records to find a valid contact. And how do they validate that any communication that f

Re: [DNSOP] Proposal: Whois over DNS

Below — John Bambenek On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sa...@bambenekconsulting.com for details On Jul 9, 2019, at 05:09, Vittorio Bertola wrote: > >> Il 9 luglio 2019 00:01 John Bambenek

Re: [DNSOP] Request for adoption: draft-sah-resolver-information

Hi Paul, My comments below: 1) Unless a DNS request for .{in-addr,ip6}.arpa/IN/RESINFO, or a subdomain, as described in Section 2 is sent over DNS-over-TLS (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], or unless the .{in-addr,ip6}.arpa zone is signed with DNSSEC, the response is

Re: [DNSOP] Proposal: Whois over DNS

> Il 9 luglio 2019 00:01 John Bambenek > ha scritto: > > > Like I said, I’m ok with someone lying to me. Its easy to detect > and easy to deal with. For instance, in DNS a mailserver could > query these records, see phone number is set to 00 and > then just reject email from said dom

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

Paul, Minor nit, just to be pedantic. On 08/07/2019 20.38, Paul Vixie wrote: REFUSED means, in my reading (and coding) that there is no zone declaration at the authority. SERVFAIL means the zone is declared/configured, but not loaded. i now realize that both have to have a holddown timer, not j