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

[Michael J. Sheldon]

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 clear) SHOULD include this EDE code in the REFUSED
   response.

The above case is not consistent with current authoritative server behavior.

The authoritative servers I have tested all return REFUSED, not
SERVFAIL, regardless of the query RD bit, when the server does not allow
recursion, and the server is not authoritative for the zone.

I would change to:

3.21.  Extended DNS Error Code 20 - Not Authoritative

   An authoritative server that receives a query (with the RD bit clear,
   or when not configured for recursion) for a domain for which it is
   not authoritative SHOULD include this EDE code in the REFUSED
   response.  A resolver that receives a query (with the RD bit clear)
   SHOULD include this EDE code in the REFUSED response.



IMO, while "lame" is a valid term, quite frankly, it's not nearly as
clear in meaning as just saying "not authoritative". To me, "lame" is at
the delegation (referring server), not the targeted server.


-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 new delegation in the wrong order!

10 min seems pretty reasonable to me. Allows for a reasonably short
delay where someone didn't set up the DNS zone before the delegation,
but prevents the hammering of a server with a true lame delegation.

While in the case of a true bad delegation, I wouldn't mind the typical
48 hour TTL from the TLDs, It seems a bit punitive for the guy who just
forgot to do a restart of his server before changing delegation.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 attach
a TTL to, so retries, retries, retries.

> Although now that I think about this, another problem we’d face here is
> that DNSSEC would break this completely.   If you have a secure
> delegation, but don’t have the ability to sign the zone, you can’t
> respond authoritatively even if the delegation is pointing at your
> server.   So here the only real fix is at the registrar.

Not gonna argue that the best fix is at the registrar. As an owner of a
nameserver, I really should have the right to say "no, you can't point
that to me."

But there's other reasons for REFUSED as well (security, ddos filtering,
etc) and I should have a means to add to the reply, "don't ask again for
X seconds"

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 that I can't return a TTL without a
record, and I don't have a record to return it on.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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).
> 
> but i didn't realize that the standard doesn't say to do this, until i read
> the above.
> 
> --
> Paul
> 
> 

BIND returns REFUSED, so that's what I've always used, for maximum
consistency/compatibility.

What SOA.minimum are you returning? Which SOA? And on what record would
it be returned? The issue is that there is no matching zone.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 justifiable, does not feel
>> "legit" to me, and results in longer-term data maintenance issues.
> 
> So this is a former customer who stopped paying but still has a valid
> registration?   This seems like it would be straightforward to automate.
>  I think it’s legit to configure your server to answer authoritatively
> for the zone as long as the delegation exists.
> 

I agree it's somewhat legit to answer for it, but it's a literal
maintenance nightmare when you're dealing with a very large number of
zones. Things like that tend to get put in place, then never removed.

And it still leaves the issue that recursives should not just keep
hammering the lame delegations when they've gotten a REFUSED response.
That is a definitive legitimate response, and should be honored for a
reasonable period of time.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 not authoritative for the name that you requested.   Is the situation
> that you have a delegation from one server to another where the other is
> not actually configured to be authoritative for the delegated zone?   If
> so, that is indeed an interesting conundrum.

This is exactly the situation. A domain owner has discontinued their
services, but left the domain pointing to our DNS Servers, or sometimes,
just pointed to us for no apparent reason.

There is no mechanism for Authoritative DNS Server owners to have lame
delegations removed by the registries, so I either have to put up with
the continuous query/retry traffic, or I have to actually create a zone
just so there's a means to return NXDOMAIN with a TTL. Neither solution
is good, and the second one, while probably justifiable, does not feel
"legit" to me, and results in longer-term data maintenance issues.


-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 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 same response. Our authoritative servers see no less 
than 15%, and sometimes as much as 25% of our worldwide traffic as these 
non-authoritative responses.

There needs to be a means to signal to a recursive server that it should not 
requery a REFUSED response for a specified period of time. Given that these 
responses to not have ANSWER records to put a TTL on, return a (new) EDNS 
record?

Michael Sheldon
Dev-DNS Services
GoDaddy.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 problem if it were in the answer section. 
>  I am guessing that the capability signal would be some EDNS option, or
> perhaps an EDNS version.  Is that reasonable?

An EDNS capabililty signal would allow the ANAME to be sent in the
answer bare, no accompanying A/ needed.

In absence of that signal, the authoritative *could* return the ANAME in
the additional, but not sure if there would be much value to it,
assuming the signal was standard behaviour.

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Deprecating the status opcode

[Michael J. Sheldon]

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
>> > you write:
>> >-=-=-=-=-=-
>> >
>> >Hi,
>> >
>> >In the spirit of deprecating things I have submitted a draft to
>> deprecate the status opcode.
>>
>> RFC 1034 says it's "To be defined" so this seems a little premature.
>>
>> Other than that, go for it.
>>
>>
>> Does this increase or decrease the 'camel' page count?
> 
> Personally I think it is not worth the effort, it will just add one more
> RFC to read and does not help the protocol maintenance.
> 
> I would say that it is better to have one "cleanup" RFC instead of
> one-off doc with one useful paragraph in it. With one bigger document we
> could say to newcommers "this is list of things you can ignore when you
> encounter them in pile of DNS RFCs".
>

In a perfect world, we'd have occasional complete rewrites like what
happened with RFCs 821, 2821, 5321 and RFCs 822, 2822, 5322



-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 vehemently against adding yet another large TXT record at the apex
of zones. Everybody and their brother wants to jam something there. We
are polluting the apex to such a point that it will no longer be
possible to answer TXT queries via UDP even with EDNS. If you MUST use
TXT, please prefix the name with an application-specific value.

On 2/25/19 1:38 PM, Brotman, Alexander wrote:
> Hello,
> 
> Stephen and I have spent a bit of time working on a draft to be able to show 
> a relationship between two domains.  We're aware this subject has been 
> covered a few times previously, especially in the DBOUND drafts, but we're 
> hopeful that a more simple approach might be more acceptable.   The secondary 
> domain will create a DNS record that shows a link to a primary domain, and 
> the text should be able to be validated using the public key in a DNS record 
> the primary domain shares.  This is something akin to DKIM, a mechanism that 
> the email world uses to ensure the contents of a message have not been 
> tampered with.
> 
> https://datatracker.ietf.org/doc/draft-brotman-rdbd/
> 
> We'll request that replies relating to this be sent to the dbo...@ietf.org 
> due to the nature of the topic, but it was suggested that we might want to 
> notify a few other lists for their awareness.  Thank you for your 
> participation and comments.
> 
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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
>>   Roy Arends
>>   Wes Hardaker
>>   David C Lawrence
>>  Filename: draft-ietf-dnsop-extended-error-04.txt
> 

>> 4.2.5.  SERVFAIL Extended DNS Error Code 5 - DNSKEY missing
>>
>>   A DS record existed at a parent, but no DNSKEY record could be found
>>   for the child.
> 
> I suggest to replace "no DNSKEY record could be found for the child"
> by "no DNSKEY record for this specific key could be found for the
> child".
> 
> Rationale : the current text seems to imply this code is only when
> there is no DNSKEY at all.
 I disagree. There are going to be cases where DS and DNSKEY are not
fully in sync due to key rollovers, prestaging, etc. This is not a fatal
error.
So long as one DS matches one (supported) DNSKEY, the domain is
resolvable, and is not a SERVFAIL. It is only SERVFAIL if *no* DS match
useable keys.

I would suggest "No supported matching DNSKEY record could be found for
the child"

-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Michael J. Sheldon]

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 "server specific" ball.
> 
> And can someone show a significant number of SRV examples outside of SIP
> and some gaming
> servers?  

From data in our systems, most common in order is _autodiscover and
other email/calendar related, then sip, then jabber/xmpp. After that,
the numbers are far less significant.



-- 
Michael Sheldon
Dev-DNS Services
GoDaddy.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop