Update DnsQueryHandler.java

[santo-codes]

Allow dot character (.) in service names

Motivation:

Currently queries of the form <name>.service.<domain> are supported. <name> values cannot have the dot character. Services in our project tend to have the dot character. This change adds support for the dot character in <name>.

Modification:

Solution is simple. SERVICE_NAME_REGEX in DnsQueryHandler needs minor change. Add \\. in the first capturing group. I.e.

private static final String SERVICE_NAME_REGEX = "^_?([\\w\\-\\.]+)\\.(?:_\\w+\\.)?(?:service|connect)\\.";

Result:

Fixes #20 .

[bfg]

Thank you for your contribution; I'll give it a spin and try to write a test for it!

[santo-codes]

@bfg Did you get a chance to look at this PR? Can this be merged? Let me know if I can help speed this up.

[bfg]

Hey @santo-codes, this project has been on hold for some time, so I wanted to modernize build infra and merged it as #22. However, it seems that your change breaks several tests:

I'm wondering about added value of this change; frankly, why would you register your service as foo.app instead of foo-app? Supporting foo.app is possible, but I find it really hard to justify such change, because . character creates sub-domain in the DNS terms.

So, in short, what is your reasoning behind such service naming scheme in your cluster?

[santo-codes]

@bfg Thanks for taking a look at my PR.

There is no reason per se for using this naming scheme. It started out with this convention and its wide spread now. All consumers either use Ribbon or Zuul gateway to access services registered on our Eureka instance. Current service naming convention (with the dots) is fine in this context.

I am exploring DNS interface to Eureka for a new use case. I am trying to access a service registered on Eureka via HAProxy. HAProxy supports service discovery using DNS SRV lookups.

So modifying existing service name patterns will be costly. Which is why I was looking for this change. However, your point is valid too. This naming convention conflicts with DNS naming. Is there a way to Eureka service resolution? Basically one could query with a proper DNS name but resolve on Eureka with a different name based on incoming query.

E.g. dig @localhost -p 8553 foo-app.service.eureka SRV

.. will be looked up by foo.app in Eureka.

In more specific terms provide a way to extend behaviour of DnsQueryHandler.getServiceName().