nanog mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Cloudflare reverse DNS SERVFAIL, normal?

From: Mark Andrews <marka () isc org>
Date: Wed, 31 Aug 2016 10:12:13 +1000

In message <46671DC5-3138-4E7A-A5AF-631B98FE354A () delong com>, Owen DeLong writes:



On Aug 30, 2016, at 15:02 , Mark Andrews <marka () isc org> wrote:


In message <926F8B85-8864-4424-BEAA-1836B718A9FD () delong com

<mailto:926F8B85-8864-4424-BEAA-1836B718A9FD () delong com>>, Owen DeLong
writes:

On Aug 29, 2016, at 17:01 , Mark Andrews <marka () isc org> wrote:


In message <20160829234737.GA16137 () cmadams net>, Chris Adams writes:

Once upon a time, Mark Andrews <marka () isc org> said:

The following is general and is not directed at Cloudflare.  I know
some people don't think errors in the reverse DNS are not critical
but if you are delegated a zone it is your responsablity to ensure
your servers are correctly serving that zone regardless of where
it is in the DNS heirarchy.  Failure to do that causes additional
work for recursive servers.  If you don't want to serve a zone then
remove the delegation.


You are assuming that an authoritative server operator has some way

to

know all the zones people delegate to their servers, and remove such
delegations if they don't want to handle them.  That is a wrong
assumption.


They have methods.  They choose not to use them.  See RFC 1033
COMPLAINTS then after that the court system.

Mark


Let us review this and compare to your statement…

From RFC 1033:

COMPLAINTS

  These are the suggested steps you should take if you are having
  problems that you believe are caused by someone else's name server:


  1.  Complain privately to the responsible person for the domain.

You

  can find their mailing address in the SOA record for the domain.

  2.  Complain publicly to the responsible person for the domain.

  3.  Ask the NIC for the administrative person responsible for the
  domain.  Complain.  You can also find domain contacts on the NIC in
  the file NETINFO:DOMAIN-CONTACTS.TXT

  4.  Complain to the parent domain authorities.

  5.  Ask the parent authorities to excommunicate the domain.


1. Doesn’t really apply in a situation where someone has pointed
   an NS record for a domain at your server without warning. There
   is no SOA record from which to retrieve said mailing address.


If they have pointed a NS record at you there is a SOA record.  Either
in the zone or in the delegating zone.


Sure, but most likely this isn’t particularly useful… See below.




   Also doesn’t work very well in cases where the SOA record does
   not contain a valid email address that reaches someone.


Some do, some don't.  There is also whois address, web contact addresses
etc.


Sometimes, if you’re lucky, if it all works as intended and the person
isn’t using domain privacy…


Domain privacy is supposed to pass on operational and legal issues.
It isn't a get out of free card for not running a nameserver / zone
correctly.


2. Do we really want NANOG buried in “Will the
   @#@!@$!@$% who delegated XYZ.COM <http://xyz.com/>

<http://xyz.com/ <http://xyz.com/>> NS Records to

point to
   my servers <name> and <name> please cease and desist?”
   messages? Personally, I vote no.


Why not.  It is a operational message about a misconfiguration.


Because NANOG isn’t for solving individual misconfigurations. It’s for
discussing issues on the internet requiring coordination.

This doesn’t require coordination of multiple providers, it’s a simple
bug report.

It would significantly raise the N in SNR IMHO. Your opinion may differ.

I still vote no.


3. The NIC? Please explicate Mr. Andrews what that would mean
   in the modern era. Please cover both the normal case and
   the cases where domain privacy is configured.

4. This might _MIGHT_ actually work, but I suspect that $REGISTRY
   is unlikely to help much when $REGISTRAR accepted an NS record
   from one of their customers for a domain they registered
   that happens to point to your server. Similarly, I suspect
   $REGISTRAR is going to tell you that they won’t make changes
   without authorization from the domain owner.


The registrar becomes party to the disruption to your services and
no the contract the registry signed with ICANN does not save them
from being fined by a court further down the process so they should
listen as it is their finanical interests to listen.


What disruption? It’s pretty hard to argue that sending back some
SERVFAIL responses as a result of a few errant packets on UDP/53
constitutes a significant disruption to service.


Owen you have zero knowledge of the volume or impact a configuration
error causes.  Some are minor, some are not.


Criminal law trumps contract law and deliberate disruption to
services falls under criminal law.  It becomes deliberate once they
fail to act on the complaint in a timely manner.  Remember we are
dealing with matters of fact here.  Published NS records and address
records.


Sure, but to get a DA to prosecute for deliberate disruption, one has
to be able to prove intent. Mere misconfiguration is not intent.
Mere misconfiguration followed by ignoring bug reports becomes a little
more grey, but I bet you’re still not likely to get very far without
a much larger disruption to your service in the form of time spent
than you suffer by simply ignoring it.


I suspect ignoring a certified letter complaining about the problem
with easily verifiable facts leads to easily provable intent.


Add to that there are published proceedures that are not being
followed that they should be aware of.


Published procedures don’t have the force of law. They may help you
to create a presumption of misconduct or negligence, but that’s about
as far as they can go.


I agree they don't have the force of law but courts do pay attention
to them especially when one of the parties involved has tried to
follow them to avoid going to the courts in the first place.


5. I suspect that success in this effort will likely parallel
   the level of success I would expect in step 4.

So, now that we’ve realized that RFC-1033 is utterly useless in this
context and badly outdated to boot, let’s review your other suggestion…


No, it isn't utterly useless.  It also shows you have tried to solve
the problem in a civil manner if you take it further.


It has a less than 0.001% probability of achieving a useful end result.


A made up statistic.  I've had better success with errors at stage
1 than that, probably about 20% and no I don't have the records to
prove it.


I consider that within the realm of “utterly useless”. YMMV.


“… after that [sic] the court system.”

[sic] refers to the missing comma.

So let me see if I understand correctly.

I run a pair of nameservers. Let’s call them ns1.company.com
<http://ns1.company.com/> and ns2.company.com <http://ns2.company.com/>

Someone registers example.com <http://example.com/> and points NS

records

in the COM zone at my
nameservers.

I’m now supposed to seek judicial relief in order to compel them to

stop

doing that?

Small claims doesn’t process claims seeking injunctive relief. I

suppose

I could
use a $1,500 or even $5,000 small claims case as a way to get their
attention,
but that’s kind of an abuse of the process. If I want an injunction, at
least
in California, I have to go to Superior court.

Now, first, we have to figure out jursidiction. As a general rule,
jurisdiction
goes to the court which is responsible for the locale in which the

event

takes
place or where the contract was entered into, or the jursidiction set

by

the
contract. In this case, there’s no contract, so we have to look at

where

the
event in question occurred. The problem is that the law hasn’t really
caught
up with technology in this area and depending on who ends up being

parties

to the suit, the definition gets pretty murky at best. Is it the

primary

office of the registry? The registrar? The registrant? The location of

the

nameserver(s) which are erroneously pointed to? (What if they are

anycast

all over the world?) The business address of the operator or owner of
those
nameservers? Where, exactly do we file this suit?


Your lawyer will work that out.


OK, so let me make sure I’m understanding you correctly.

I’m getting these extra packets I don’t want. They’re probably costing me
less than $1/day, but they’re a bit annoying.

You now want me to go pay someone $300/hour to sort all of this out,
probably
against a $5,000 or $10,000 retainer just to start?

Will you be financing any of these operations, or, are you just hoping
that
we’re all dumb enough to bankrupt ourselves in the name of clean DNS?


The next problem we have is who to sue. Do we sue the domain

registrant?

The
registrar they used to register the domain name? etc.


Your lawyer will work that out.


See above.


Yeah, I don’t think there’s enough possibility of any sort of recovery

to

make that worth the effort or expense.


So you decide to not avail yourself of the process available to you.

That

is not the same thing as saying there is no process.


I never said there was no process. I said that the existing process was
useless.

If the procedural argument doesn’t convince you and the economic argument
doesn’t
sink in, then, you are entitled to your opinion, but I’m willing to bet
that a
much larger fraction of the community believes that there is nothing to
be gained
from the process compared to the costs of engaging in it.

Owen


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org
Previous By Date Next
Previous By Thread Next

Current thread: