I'm looking to implement an authentication mechanism which allows to enforce access policies based on the domain name of the client. The authentication server uses the information available in the DNS to verify the client authorisation.

More details:

Access policy The resource owner restricts the access to resource only to a specific subdomain (e.g. my-x-service.clientexample.com). To access the resource the client must prove that it owns the subdomain or that it's a 3rd party authorised to access that resource on behalf of the domain owner.

Authentication In order to prove that it acts on behalf of the domain owner the client must have its IP address whitelisted in the TXT records of the domain name. The auth server matches the IP address of the client request with the list published on the TXT record of the claimed domain provided. If both match it grants access to the resource.

   Content-Type: application/JSON
   Claim-Domain: my-x-service.clientexample.com

Is there any such standard already in place? I'm aware only about SPF but as it's used for email I think the specifications would require some trimming.

Edit -

enter image description here

  • 6
    So confuse. Such misguide. Overengineer. Wow.
    – Wesley
    Mar 6 '15 at 2:17
  • Tell you what @mihai, you make this as an open source project and see what the infosec community at large says about the concept.
    – Wesley
    Mar 6 '15 at 6:33
  • @wesley ha ha ...I guess I will postpone this project for a while. It seems to work for email authentication (though there may be some shortcomings) so I still can't explain myself why it wouldn't work for http. At least hypothetically it seemed a good method to provide http authentication in a distributed manner based on the IP address of the client.
    – themihai
    Mar 6 '15 at 6:49
  • See my comment below. It works for SPF because it's not a form of authentication. Once you try to treat DNS data as a form of authentication, without being able to validate the authenticity of the DNS reply you're getting, the whole house of cards falls apart. That's why it hasn't been done until now, and once you overcome that with DNSSEC the inertia is still extremely high on this being widely adopted as a standard. Nevermind the inertia that DNSSEC itself faces.
    – Andrew B
    Mar 6 '15 at 6:51
  • @AndrewB thanks for the constructive comment. I wasn't aware that the DNS security is so flawed. At least DNSSEC seemed to address the data integrity issue. Is this the only reason why this won't work?
    – themihai
    Mar 6 '15 at 6:57

SPF is not a security credential

I think the big misconception here is that SPF records provide a trusted credential. In truth SPF is not a secure credential, at least in the real world of security.

DNS is an inherently insecure protocol. It's based on UDP (no transport level handshake), the protocol itself does not implement a handshake, and there is no cryptographic guarantee that the "reply" packet you get hasn't been spoofed. If you do some research you can find this all over the place.

The elephant in the room is pretty obvious here: if DNS is so insecure, why is it okay for SPF to do what it does? Because the risk is low. The worst that can happen with SPF is a zero gain scenario: you're right back to where you were if you had no SPF record. SPF is an ugly compromise that mail admins were forced to reach in the face of a much larger problem, and that's the extent of it.

For further research, I recommend you look into a little-known DNS record type called SSHFP and the challenges that it faces to be useful. SSHFP is a standard for putting a server's SSH public key in DNS. Your SSH client would never ask you to initially trust a key. That'd be fantastic. But if you look into the prerequisites for a SSHFP record to be trusted by a SSH client, it's exactly the same type of problem that is being described here. This should eliminate any remaining doubts about whether DNS can be used to supply security credentials without some form of root nameserver trust. (DNSSEC)

DNS security isn't the only challenge

Okay, so now you know why what you're describing hasn't been done before. DNSSEC is just around the corner though, right? Let's pretend for a moment that validating DNSSEC resolvers are available to everyone, and that DNSSEC doesn't face the same kind of inertia that IPv6 does.

This standard probably isn't going to happen.

I know comment thread accompanying Mark's answer isn't what you want to hear, but they've got the nail on the head when it comes to it being a bad idea to have a published list of trusted IPs. Big companies are going to be very dis-incentivized to implement a three step trust where you are publishing a list of IPs to the internet that can be used to access their system. It's an absurd prospect for them, particularly when public key cryptography exists and is the preferred way for managing systems of delegated trust.

In this answer I've mentioned two technologies that address much bigger problems that impact everyone in IT on a global scale, both of which face significant inertia. That inertia is gonna be nothing compared to getting this bird to fly. That's the damn truth.

  • It makes sense now. So at most it would work only on an internal network & internal/private DNS server.
    – themihai
    Mar 6 '15 at 8:16
  • 1
    Without DNSSEC, security experts would tell you to not trust DNS in this context even on a private network. Doesn't matter how hard it is...if the probability of spoofing is >0, it's inadequate for this usage.
    – Andrew B
    Mar 6 '15 at 8:22

Think about how this would work. SPF works because it allows remote mail servers to verify their incoming mail to ensure that the mail has in fact come from where it's meant to. This puts the onus on the sender to have the SPF record in the first place.

How would this work with a DNS record for web access? It publishes a list of clients who are allowed to connect to it, and then... what? The client then just says "oh no! I'm not on the list! I better drop my connection!" and nobody ever writes a client that doesn't obey these records. And nobody has to lock their doors at night and we don't need banks because we keep our money in a shoebox under our bed and the police force retire because everyone just starts getting along and world peace is no longer an unrealistic dream.

If you want owners to restrict resources to known IP addresses, do it the way it's been done for decades: With a firewall. Or do it that way it's been done for almost as long: With rules on the web server configuration.

  • You don't need to drop the connection. I think an "unauthorised" error would be enough. The DNS is meant to help the resource owner to manage the permissions easier. It would organise its services/applications into "domains/subdomains" instead of raw IP ranges. That way if it removes a service or just needs to migrate it to a new infrastructure it would need to remove/update the domain/subdomain records only.
    – themihai
    Mar 6 '15 at 1:54
  • I should also mention that each resource owner specifies the ACL policies (e.g. IP restricted or not) so I can't just firewall the web server.
    – themihai
    Mar 6 '15 at 2:01
  • 1
    Forget about the actual action taken - the fact is that this plan relies on the client obeying a DNS TXT record. This is fundamentally flawed in that it's incredibly easy to just ignore the TXT record and make your request anyway. If you want to do per-resouce restrictions, do this with a .htaccess file in the folders for the resources you want to restrict Mar 6 '15 at 2:23
  • 5
    @mihai I can't think of any reason to publish your security policy in DNS. Web servers already handle the restrictions, and there are a number of other services than can restrict which addresses/domains can connect. If people can look up the TXT records, they can lookup up the IP. It just tells me where I need to break into so I can pivot onto your systems.
    – BillThor
    Mar 6 '15 at 2:23
  • 1
    @mahai Websites with access restrictions don't publish what addresses they accept connections from. (This is critical security data.) While I may know the address of the website. I don't get a list of address than I can connect from. This is valuable as cracking any one of them may be an easier way to attack the site than trying to attack the site directly.
    – BillThor
    Mar 6 '15 at 3:20

resource owner to restrict the access to one or more domain names.

The closest thing to this I can think of would be to run all your own name servers, and use ACL's to restrict who is allowed to query a given zone.

Example config excerpt (for bind):

acl trusted_src_ip {;
zone "mysecretdomain.com" IN {
    type master;
    file "zones/mysecretdomain.com";
    allow-query { trusted_src_ip; };

But this is almost certainly the wrong solution to the actual problem you're trying to solve.

  • 3
    But this is almost certainly the wrong solution to the actual problem you're trying to solve. Allowing the word "almost" in that sentence was very polite of you. =)
    – Wesley
    Mar 6 '15 at 6:06
  • @Wesley I think the question was badly formatted.See the edit. It can't be a such bad idea to get 2 down-votes :)
    – themihai
    Mar 6 '15 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.