BIND 10 #2841: deal with inet_pton that doesn't recognize AF_INET6

[BIND 10 Development]

#2841: deal with inet_pton that doesn't recognize AF_INET6
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  UnAssigned
            Priority:  medium        |                       Status:  new
           Component:  build system  |                    Milestone:  Next-
            Keywords:                |  Sprint-Proposed
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:
         Total Hours:  0             |  Medium
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> I've received a feedback from a user who tried to build and used BIND 10.
> The OS is CentOS6 (reportedly), disables IPv6 in the kernel, and
> apparently its inet_pton doesn't recognize AF_INET6 (not sure it's
> related to the kernel support of IPv6; API-wise it should be
> independent).
>
> This caused at least two known issues:
>
> - some test data (generated by src/lib/util/python/gen_wiredata.py)
>   can't be generated because the genetator script fails to create AAAA
>   rdata.
> - b10-resolver (and I suspect b10-auth also) failed to start up
>   because its default config has ::1/53 for listen_on, which is
>   considered a syntax error.
>
> I'm not sure whether we want to help such environment; it seems to me
> inet_pton that doesn't recognize AF_INET6 is so broken and wouldn't
> worth introducing another layer of complexity in our code.  But if
> such a deployment is actually not so uncommon, we may have to do
> something in our side.
>
> Based on discussions at the Mar12 2003 team call, specific suggestion
> is:
> - Do #2842 (this will "hide" the first problem for most ordinary users)
> - Document the second issue with workaround somewhere
>
> Regarding the second (the main task of this ticket), my suggestion is
> to update the description of SRVCOMM_EXCEPTION_ALLOC log message which
> currently reads:
> {{{
> The process tried to allocate a socket using the socket creator, but an
> error
> occurred. But it is not one of the errors we are sure are "safe". In this
> case
> it is unclear if the unsuccessful communication left the process and the
> bind10
> process in inconsistent state, so the process is going to abort to
> prevent
> further problems in that area.
>
> This is probably a bug in the code, but it could be caused by other
> unusual
> conditions (like insufficient memory, deleted socket file used for
> communication).
> }}}
> so it will mention the issue.  As a workaround we should be able to
> avoid it by editting the installed resolver/auth.spec excluding IPv6
> addresses from listen_on.  We document it there, too.  And provide
> some text in ChangeLog.

New description:

 I've received a feedback from a user who tried to build and used BIND 10.
 The OS is CentOS6 (reportedly), disables IPv6 in the kernel, and
 apparently its inet_pton doesn't recognize AF_INET6 (not sure it's
 related to the kernel support of IPv6; API-wise it should be
 independent).

 This caused at least two known issues:

 - some test data (generated by src/lib/util/python/gen_wiredata.py)
   can't be generated because the genetator script fails to create AAAA
   rdata.
 - b10-resolver (and I suspect b10-auth also) failed to start up
   because its default config has ::1/53 for listen_on, which is
   considered a syntax error.

 I'm not sure whether we want to help such environment; it seems to me
 inet_pton that doesn't recognize AF_INET6 is so broken and wouldn't
 be worth introducing another layer of complexity in our code.  But if
 such a deployment is actually not so uncommon, we may have to do
 something in our side.

 Based on discussions at the Mar12 2013 team call, specific suggestion
 is:
 - Do #2842 (this will "hide" the first problem for most ordinary users)
 - Document the second issue with workaround somewhere

 Regarding the second (the main task of this ticket), my suggestion is
 to update the description of SRVCOMM_EXCEPTION_ALLOC log message which
 currently reads:
 {{{
 The process tried to allocate a socket using the socket creator, but an
 error
 occurred. But it is not one of the errors we are sure are "safe". In this
 case
 it is unclear if the unsuccessful communication left the process and the
 bind10
 process in inconsistent state, so the process is going to abort to prevent
 further problems in that area.

 This is probably a bug in the code, but it could be caused by other
 unusual
 conditions (like insufficient memory, deleted socket file used for
 communication).
 }}}
 so it will mention the issue.  As a workaround we should be able to
 avoid it by editting the installed resolver/auth.spec excluding IPv6
 addresses from listen_on.  We document it there, too.  And provide
 some text in ChangeLog.

--

-- 
Ticket URL: <http://bind10.isc.org/ticket/2841#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development