[191249] in North American Network Operators' Group
Re: Cloudflare reverse DNS SERVFAIL, normal?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Aug 30 19:43:38 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20160830220247.B429652F1A39@rock.dv.isc.org>
Date: Tue, 30 Aug 2016 16:41:25 -0700
To: Mark Andrews <marka@isc.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> On Aug 30, 2016, at 15:02 , Mark Andrews <marka@isc.org> wrote:
>=20
>=20
> 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:
>>>=20
>>>=20
>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> They have methods. They choose not to use them. See RFC 1033
>>> COMPLAINTS then after that the court system.
>>>=20
>>> Mark
>>=20
>> Let us review this and compare to your statement=E2=80=A6
>>=20
>> =46rom RFC 1033:
>>> COMPLAINTS
>>>=20
>>> These are the suggested steps you should take if you are having
>>> problems that you believe are caused by someone else's name =
server:
>>>=20
>>>=20
>>> 1. Complain privately to the responsible person for the domain. =
You
>>> can find their mailing address in the SOA record for the domain.
>>>=20
>>> 2. Complain publicly to the responsible person for the domain.
>>>=20
>>> 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
>>>=20
>>> 4. Complain to the parent domain authorities.
>>>=20
>>> 5. Ask the parent authorities to excommunicate the domain.
>>=20
>> 1. Doesn=E2=80=99t 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.
>=20
> 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=E2=80=99t particularly useful=E2=80=A6 =
See below.
>=20
>> Also doesn=E2=80=99t work very well in cases where the SOA =
record does
>> not contain a valid email address that reaches someone.
>=20
> Some do, some don't. There is also whois address, web contact =
addresses
> etc.
Sometimes, if you=E2=80=99re lucky, if it all works as intended and the =
person isn=E2=80=99t
using domain privacy=E2=80=A6
>=20
>> 2. Do we really want NANOG buried in =E2=80=9CWill 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?=E2=80=9D
>> messages? Personally, I vote no.
>=20
> Why not. It is a operational message about a misconfiguration.
Because NANOG isn=E2=80=99t for solving individual misconfigurations. =
It=E2=80=99s for
discussing issues on the internet requiring coordination.
This doesn=E2=80=99t require coordination of multiple providers, it=E2=80=99=
s a simple
bug report.
It would significantly raise the N in SNR IMHO. Your opinion may differ.
I still vote no.
>=20
>> 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.
>>=20
>> 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=E2=80=99t make =
changes
>> without authorization from the domain owner.
>=20
> 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=E2=80=99s 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.
> 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=E2=80=99re 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.
> Add to that there are published proceedures that are not being
> followed that they should be aware of.
Published procedures don=E2=80=99t have the force of law. They may help =
you
to create a presumption of misconduct or negligence, but that=E2=80=99s =
about
as far as they can go.
>> 5. I suspect that success in this effort will likely parallel
>> the level of success I would expect in step 4.
>>=20
>> So, now that we=E2=80=99ve realized that RFC-1033 is utterly useless =
in this
>> context and badly outdated to boot, let=E2=80=99s review your other =
suggestion=E2=80=A6
>=20
> 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.
I consider that within the realm of =E2=80=9Cutterly useless=E2=80=9D. =
YMMV.
>=20
>> =E2=80=9C=E2=80=A6 after that [sic] the court system.=E2=80=9D
>>=20
>> [sic] refers to the missing comma.
>>=20
>> So let me see if I understand correctly.
>>=20
>> I run a pair of nameservers. Let=E2=80=99s call them ns1.company.com
>> <http://ns1.company.com/> and ns2.company.com =
<http://ns2.company.com/>
>>=20
>> Someone registers example.com <http://example.com/> and points NS =
records
>> in the COM zone at my
>> nameservers.
>>=20
>> I=E2=80=99m now supposed to seek judicial relief in order to compel =
them to stop
>> doing that?
>>=20
>> Small claims doesn=E2=80=99t 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=E2=80=99s kind of an abuse of the process. If I want an =
injunction, at
>> least
>> in California, I have to go to Superior court.
>>=20
>> 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=E2=80=99s no contract, so we have to =
look at where
>> the
>> event in question occurred. The problem is that the law hasn=E2=80=99t =
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?
>=20
> Your lawyer will work that out.
OK, so let me make sure I=E2=80=99m understanding you correctly.
I=E2=80=99m getting these extra packets I don=E2=80=99t want. They=E2=80=99=
re probably costing me
less than $1/day, but they=E2=80=99re 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=E2=80=99re 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.
>=20
> Your lawyer will work that out.
See above.
>> Yeah, I don=E2=80=99t think there=E2=80=99s enough possibility of any =
sort of recovery to
>> make that worth the effort or expense.
>=20
> 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=E2=80=99t convince you and the economic =
argument doesn=E2=80=99t
sink in, then, you are entitled to your opinion, but I=E2=80=99m 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
