Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: should expand IP address 1.1 to #36822

perpetual-hydrofoil opened this issue Jan 28, 2020 · 18 comments

net: should expand IP address 1.1 to #36822

perpetual-hydrofoil opened this issue Jan 28, 2020 · 18 comments
help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.


Copy link

perpetual-hydrofoil commented Jan 28, 2020

nameserver 1.1 in /etc/resolv.conf not parsed

What did you do?

go get

What did you see instead?

go get module
dial tcp: lookup on [::1]:53: dial tcp [::1]:53:
connect: connection refused


Change 1.1 to or in /etc/resolv.conf

# /etc/resolv.conf
nameserver 1.1
Copy link

Looking at, name server is defined to be an IPV4 or IPV6 address, nameserver 1.1 appears to be neither so I don't see how it could be used as a DNS server.

Why did you expect that Go would be able to use 1.1 as a nameserver?

Copy link

perpetual-hydrofoil commented Jan 28, 2020

1.1 should expand to


Try putting nameserver 1.1 into resolv.conf and then ping something; your resolver should properly use that resolver.

Or, just ping 1.1 or traceroute 1.1, or ping 127.1. On Linux (but apparently not Mac), you can even ping 0 (which expands to

CloudFlare's public nameservers are documented at: https://1.1/ (which should be a working link in your browser)

dig @1.1
;; ANSWER SECTION:     120 IN  A

The expansion rules are covered here (part of POSIX / IEEE 1003.1).

#! /usr/bin/env python

import socket
# ''

It appears that net does not properly expand and parse IPv4 in this format, so that might be the underlying cause here.

Copy link

This is part of POSIX (IEEE 1003.1).

Do you have a citation for that? I didn't think that IEEE 1003.1 talked about networking at all. Thanks.

@ianlancetaylor ianlancetaylor changed the title /etc/resolv.conf not interpreted properly net: should treat IP address 1.1 as Jan 28, 2020
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 28, 2020
@ianlancetaylor ianlancetaylor added this to the Go1.15 milestone Jan 28, 2020
Copy link

package main

import (

func main() {
    ip := net.ParseIP("1.1")
    if ip.To4() == nil {
        fmt.Printf("IPv4 expansion is not working.")

Copy link

rhedile commented Jan 28, 2020 via email

Copy link

Thanks for the pointer.

Copy link

Indeed, TIL!

Copy link


Copy link

Well, that's just about all the internet I can handle today. Good evening

@perpetual-hydrofoil perpetual-hydrofoil changed the title net: should treat IP address 1.1 as net: should expand IP address 1.1 to Jan 30, 2020
@odeke-em odeke-em modified the milestones: Go1.15, Go1.16 May 25, 2020
Copy link

epelc commented Aug 13, 2020

Are there any security issues related to this potentially changing behavior in higher level packages(net/http, etc)? I think it may be a good idea to make a note about the potential for SSRF and other security problems on the release notes if/when this is changed.

ie if you are filtering some internal address like you could potentially expand via 192.168.2 and a simple filter might not catch it. I know best practice is to use proxy hosts setup on separate networks/subnets but it's been shown in the past with major programs(github enterprise) that many webhook implementations skip this or use alternative methods.

Copy link

Good point (and that's an awesome presentation.)

I'm not clear on what exact attack vector you're suggesting here -- are we talking about URL routing with embedded IP's, general input sanitation, other protocols, etc. It seems like most naive implementations that would be expecting an IPv4 at all should also enforce a dotted-quad input sanitation filter, since any developer that would just allow untrusted input without even the bare minimum of bounds checking for some sort of properly formed IP (whatever that means to the developer!) will probably have far larger issues anyway.

Even if the developer has some inscrutable take on what an IPv4 "looks" like, in practice this expansion isn't really much different from how you can drop octets in IPv6, so perhaps the behavior should match whatever is currently done for IPv6 octets.

Copy link

iwdgo commented Nov 8, 2020

One POSIX online reference is on opengroup
Searching for inet_addr returns the page pasted above.

Copy link

Change mentions this issue: net: expand IP when octets are missing

Copy link

Punting to Go1.17, as per guidance on the CL after the need for clarification.

@odeke-em odeke-em modified the milestones: Go1.16, Go1.17 Dec 25, 2020
Copy link

In addition, net.ParseIP() should support hex and octal form.

e.g., "0x7F.010" should correspond to "".

$ wget http://0x7F.010
--2021-03-13 16:38:50--  http://0x7f.010/
Resolving 0x7f.010 (0x7f.010)...

Copy link

AkihiroSuda commented Mar 13, 2021

Punting to Go1.17, as per guidance on the CL after the need for clarification.

The "7.4. Rare IP Address Formats" section of RFC3986 has explanation about the rare formats, though not formal definition:

7.4. Rare IP Address Formats

Although the URI syntax for IPv4address only allows the common
dotted-decimal form of IPv4 address literal, many implementations
that process URIs make use of platform-dependent system routines,
such as gethostbyname() and inet_aton(), to translate the string
literal to an actual IP address. Unfortunately, such system routines
often allow and process a much larger set of formats than those
described in Section 3.2.2.

For example, many implementations allow dotted forms of three
numbers, wherein the last part is interpreted as a 16-bit quantity
and placed in the right-most two bytes of the network address (e.g.,
a Class B network). Likewise, a dotted form of two numbers means
that the last part is interpreted as a 24-bit quantity and placed in
the right-most three bytes of the network address (Class A), and a
single number (without dots) is interpreted as a 32-bit quantity and
stored directly in the network address. Adding further to the
confusion, some implementations allow each dotted part to be
interpreted as decimal, octal, or hexadecimal, as specified in the C
language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0
implies octal; otherwise, the number is interpreted as decimal).

These additional IP address formats are not allowed in the URI syntax
due to differences between platform implementations. However, they
can become a security concern if an application attempts to filter
access to resources based on the IP address in string literal format.
If this filtering is performed, literals should be converted to
numeric form and filtered based on the numeric value, and not on a
prefix or suffix of the string form.

Copy link

fis commented Jan 24, 2022

FWIW, I don't think POSIX has really made up its mind on this consistently either:

inet_addr, inet_ntoa:

Values specified using IPv4 dotted decimal notation take one of the following forms: a.b.c.d / a.b.c / a.b / a

inet_ntop, inet_pton:

If the af argument of inet_pton() is AF_INET, the src string shall be in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where "ddd" is a one to three digit decimal number between 0 and 255 (see inet_addr). The inet_pton() function does not accept other formats (such as the octal numbers, hexadecimal numbers, and fewer than four numbers that inet_addr() accepts).

You could argue that net.ParseIP is closer to inet_pton in spirit, given that it supports both IPv4 and IPv6, and also does not accept the "rare" formats. Sticking to a stricter syntax would also be in line with how issue #30999 was resolved.

RFC 6943 section 3.1.1 referred in that issue also talks of this distinction between "strict" and "loose" forms:

In specifying the inet_addr() API, the Portable Operating System Interface (POSIX) standard [IEEE-1003.1] defines "IPv4 dotted decimal notation" as allowing not only strings of the form "" but also allowing octal and hexadecimal, and addresses with less than four parts. For example, "10.0.258", "0xA000102", and "012.0x102" all represent the same IPv4 address in standard "IPv4 dotted decimal" notation. We will refer to this as the "loose" syntax of an IPv4 address literal.

In Section 6.1 of [RFC3493], getaddrinfo() is defined to support the same (loose) syntax as inet_addr(): [--] In contrast, Section 6.3 of the same RFC states, specifying inet_pton(): [--]

As shown above, inet_pton() uses what we will refer to as the "strict" form of an IPv4 address literal. Some platforms also use the strict form with getaddrinfo() when the AI_NUMERICHOST flag is passed to it.

Both the strict and loose forms are standard forms, and hence a protocol specification is still ambiguous if it simply defines a string to be in the "standard IPv4 dotted decimal form". [--]

[--] New protocols and data formats should similarly consider using the strict form rather than the loose form in order to better match user expectations. [--]

Copy link

codewinch commented Jan 24, 2022

The RFC 6943 reference is very interesting, especially that part you quoted:

Both the strict and loose forms are standard forms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
None yet

No branches or pull requests