Add directive to allow underscores in hostnames

Aleksandr Kupriyanov sasha at instartlogic.com
Thu Nov 17 18:34:03 UTC 2016


De facto, some "big guys" already use underscores in their host names:

sasha at kernel.home:~$ host cow_fb_cdn0-a.akamaihd.net
cow_fb_cdn0-a.akamaihd.net is an alias for
cow_fb_cdn0-a.akamaihd.net.edgesuite.net.
cow_fb_cdn0-a.akamaihd.net.edgesuite.net is an alias for a1877.g.akamai.net.
a1877.g.akamai.net has address 104.73.160.114
a1877.g.akamai.net has address 104.73.160.64
sasha at kernel.home:~$


On Thu, Nov 17, 2016 at 12:21 PM, Thomas Ward <teward at dark-net.net> wrote:

> Correct me if I am wrong but the discussion of underscores in DNS does not
> apply to hostnames.  The discussion referenced states as such, and only
> touches on underscores as a part of DNS attributes and internals, not as
> part of hostnames.  It even says as such that hostnames are *not permitted*
> to have underscores.
>
> By extension of that, should not the Host header should be a hostname or a
> requested hostname and therefore obey the requirements for a Hostname at
> the bare minimum?
>
>
> *Sent from my iPhone.  Please excuse any typos, as they are likely to
> happen by accident.*
>
> > On Nov 17, 2016, at 12:10, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > Hello!
> >
> >> On Wed, Nov 16, 2016 at 06:36:12PM -0600, Aleksandr Kupriyanov wrote:
> >>
> >> <http://www.google.com/url?q=http%3A%2F%2Fwww.instartlogic.
> com%2F&sa=D&sntz=1&usg=AFrqEzc4puDXYOgyifEWrSJrJIfW1sViFg>
> >
> >> # HG changeset patch
> >> # User Aleksandr Kupriyanov <sasha at instartlogic.com>
> >> # Date 1479340749 21600
> >> # Node ID af947b854971993f318417c70c3818147b320a0d
> >> # Parent  6a26016e9a138102798a7ec3e74747fbd6018f82
> >> Add directive to allow underscores in hostnames
> >>
> >> Two equivalent requests generate different responses:
> >>
> >> 1. ---------------
> >> GET http://host_1.home/ HTTP/1.1
> >> Host: host_1.home
> >> ...
> >> HTTP/1.1 400 Bad Request
> >> Server: nginx/1.X.XX
> >> ------------------
> >>
> >> 2. ---------------
> >> GET / HTTP/1.1
> >> Host: host_1.home
> >> ...
> >> HTTP/1.1 200 OK
> >> Server: nginx/1.X.XX
> >> ------------------
> >>
> >> To avoid that a new directive is proposed:
> >>
> >> Syntax: underscores_in_hostname on | off;
> >> Default: underscores_in_headers off;
> >> Context: http, server
> >>
> >> Enables or disables the use of underscores in host names of
> >> client request line.
> >>
> >> See a discussion about underscores in DNS here:
> >> http://domainkeys.sourceforge.net/underscore.html
> >
> > Shouldn't we just allow underscores in
> > ngx_http_parse_request_line() instead?  It doesn't looks like
> > there are reasons to keep the test that strict.
> >
> > In case of underscores_in_headers there a clear security reason:
> > headers are exposed via the HTTP_* variables in CGI, and via
> > $http_* variables in nginx itself, and this makes headers with
> > underscores indistinguishable from ones with dash, and creates an
> > attack vector.
> >
> > I don't see such a problem with underscores in hostname when it's
> > passed via the request line - especially keeping in mind that we
> > don't enforce such a limitation via the Host header.
> >
> > --
> > Maxim Dounin
> > http://nginx.org/
> >
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>



-- 
<https://sites.google.com/a/instartlogic.com/saleshub/email-signatures/Instart_Logic_Logo_100px-width-50px-height.jpg?attredirects=0>
  World's First Endpoint-Aware Application Delivery Solution

  *Aleksandr **Kupriyanov*

  Email: sasha at instartlogic.com
  Instart Logic | 450 Lambert Ave, Palo Alto, CA 94306 | instartlogic.com
<http://www.google.com/url?q=http%3A%2F%2Fwww.instartlogic.com%2F&sa=D&sntz=1&usg=AFrqEzc4puDXYOgyifEWrSJrJIfW1sViFg>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20161117/690240cf/attachment.html>


More information about the nginx-devel mailing list