Cloudflare reverse DNS SERVFAIL, normal?
We're seeing a huge uptick in reverse dns lookup failures across an app, 99% are all for Cloudflare ip addresses. Instead of seeing a PTR or NXDOMAIN we're getting back SERVFAIL. Does anyone know if this is a standard response from them? Do they not have reverse DNS setup for their networks? Trying to narrow this down to see if it's a result in a change in how our application handles these errors or if there's an issue going on with cloudflare's DNS setup. Thanks! Jeremy
On 2016-08-29 2:46 PM, Jeremy wrote:
We're seeing a huge uptick in reverse dns lookup failures across an app, 99% are all for Cloudflare ip addresses.
Instead of seeing a PTR or NXDOMAIN we're getting back SERVFAIL.
Does anyone know if this is a standard response from them? Do they not have reverse DNS setup for their networks?
Got an example range? All the ones I'm checking here seem fine.
Trying to narrow this down to see if it's a result in a change in how our application handles these errors or if there's an issue going on with cloudflare's DNS setup.
Thanks! Jeremy
In message <CAJCOWev9n7i+dAhrKTqN=vvBj7qL95y7_5wAwTB9yCeyoYMyBA@mail.gmail.com>, Jeremy writes:
We're seeing a huge uptick in reverse dns lookup failures across an app, 99% are all for Cloudflare ip addresses.
Instead of seeing a PTR or NXDOMAIN we're getting back SERVFAIL.
Does anyone know if this is a standard response from them? Do they not have reverse DNS setup for their networks?
Trying to narrow this down to see if it's a result in a change in how our application handles these errors or if there's an issue going on with cloudflare's DNS setup.
Thanks! Jeremy
If you are delegated a zone then you should answer queries for that zone. SERVFAIL is not appropriate. It indicates a condition that needs to be fixed especially from a authoritative server. Contact Cloudflare with a list of failing names. Cloudflare are generally good about making sure the DNS is giving well formed answers. 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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. -- Chris Adams <cma@cmadams.net>
On 2016-08-29 5:47 PM, Chris Adams wrote:
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.
Even more generally is that your authoritative server should respond to anything it is asked with an appropriate answer. Dropping/filtering can lead to bad situations.
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
-- Chris Adams <cma@cmadams.net> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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. Also doesn’t work very well in cases where the SOA record does not contain a valid email address that reaches someone. 2. Do we really want NANOG buried in “Will the @#@!@$!@$% who delegated XYZ.COM <http://xyz.com/> NS Records to point to my servers <name> and <name> please cease and desist?” messages? Personally, I 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. 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… “… 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? 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. Yeah, I don’t think there’s enough possibility of any sort of recovery to make that worth the effort or expense. Owen
In message <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.
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.
2. Do we really want NANOG buried in “Will the @#@!@$!@$% who delegated 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.
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. 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. Add to that there are published proceedures that are not being followed that they should be aware of.
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.
“… 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.
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.
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.
Owen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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…
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.
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.
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.
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. 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
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
On Tue, 30 Aug 2016 14:39:10 -0700, Owen DeLong said:
I run a pair of nameservers. Let’s call them ns1.company.com and ns2.company.com
Someone registers example.com and points NS records in the COM zone at my nameservers.
I would have expected that the resulting NXDOMAIN replies from ns1 and ns2 would usually make this a self-correcting problem. Are there actually people who do this misconfiguration on a zone big enough for the traffic to matter, and leave it that way for very long before they clue in that things aren't working right? I'd think that if somebody points billy-bobs-bait-tackle-and-internet.com at you, it might take you quite some time to notice - and if somebody whoopsies and points ebay.com's NS records at you, the resulting disfunction would be noticed fairly soon.... (Miscreants who do this intentionally are, of course, a totally different kettle of fish, and need to be dealt with as micreants....)
On Aug 30, 2016, at 15:50 , Valdis.Kletnieks@vt.edu wrote:
On Tue, 30 Aug 2016 14:39:10 -0700, Owen DeLong said:
I run a pair of nameservers. Let’s call them ns1.company.com and ns2.company.com
Someone registers example.com and points NS records in the COM zone at my nameservers.
I would have expected that the resulting NXDOMAIN replies from ns1 and ns2 would usually make this a self-correcting problem.
You don’t get NXDOMAIN when a nameserver gets a request for a zone it doesn’t serve. You either get SERVFAIL or you get NS records back as a referral.
Are there actually people who do this misconfiguration on a zone big enough for the traffic to matter, and leave it that way for very long before they clue in that things aren't working right? I'd think that if somebody points billy-bobs-bait-tackle-and-internet.com at you, it might take you quite some time to notice - and if somebody whoopsies and points ebay.com's NS records at you, the resulting disfunction would be noticed fairly soon….
Depends on your definition of “matter”. Also, misconfiguring one important zone doesn’t necessarily generate significantly more traffic than generating a whole lot of unimportant ones. Especially if you misconfigure zones in ip6.arpa or in-addr.arpa as was the case at the beginning of this topic.
(Miscreants who do this intentionally are, of course, a totally different kettle of fish, and need to be dealt with as micreants....)
Yep, though one has to wonder why they would bother. Owen
* owen@delong.com (Owen DeLong) [Wed 31 Aug 2016, 01:47 CEST]:
You don’t get NXDOMAIN when a nameserver gets a request for a zone it doesn’t serve.
Correct in most cases (there's an edge case where a server is [mis] configured as authoritative with its own empty . and its regular zones and allows global querying; it's similar to asking a root server for anything in a nonexistent TLD).
You either get SERVFAIL or you get NS records back as a referral.
Or REFUSED. -- Niels.
On Tue, Aug 30, 2016 at 06:50:03PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Tue, 30 Aug 2016 14:39:10 -0700, Owen DeLong said:
I run a pair of nameservers. Let???s call them ns1.company.com and ns2.company.com
Someone registers example.com and points NS records in the COM zone at my nameservers.
I would have expected that the resulting NXDOMAIN replies from ns1 and ns2 would usually make this a self-correcting problem.
Are there actually people who do this misconfiguration on a zone big enough for the traffic to matter, and leave it that way for very long before they clue in that things aren't working right? I'd think that if somebody points billy-bobs-bait-tackle-and-internet.com at you, it might take you quite some time to notice - and if somebody whoopsies and points ebay.com's NS records at you, the resulting disfunction would be noticed fairly soon....
The recent example seems to be Digital Ocean who had 20k domains pointed at their NS servers that weren't configured by customers. There is a bit about it at https://thehackerblog.com/floating-domains-taking-over-20k-digitalocean-doma... that may be interesting to read. I disagree with some of the analysis but it's a reasonable insight into the frequency of this.
(Miscreants who do this intentionally are, of course, a totally different kettle of fish, and need to be dealt with as micreants....)
participants (8)
-
Chris Adams -
David -
Jeremy -
Mark Andrews -
Niels Bakker -
Nigel Jones -
Owen DeLong -
Valdis.Kletnieks＠vt.edu