Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #101558 > unrolled thread

Require packages to build without any configured DNS

Back to article view | Back to linux.debian.devel

Contents

  Require packages to build without any configured DNS Mattia Rizzolo <mattia@debian.org> - 2021-09-06 16:50 +0200
    Re: Require packages to build without any configured DNS Don Armstrong <don@debian.org> - 2021-09-08 01:50 +0200
      Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-08 15:00 +0200
    Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-08 16:20 +0200
      Re: Require packages to build without any configured DNS Pirate Praveen <praveen@onenetbeyond.org> - 2021-09-08 16:30 +0200
        Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-08 17:30 +0200
          Re: Require packages to build without any configured DNS Pirate Praveen <praveen@onenetbeyond.org> - 2021-09-09 00:00 +0200
            Re: Require packages to build without any configured DNS Paul Wise <pabs@debian.org> - 2021-09-09 06:50 +0200
    Re: Require packages to build without any configured DNS Helmut Grohne <helmut@subdivi.de> - 2021-09-08 18:00 +0200
      Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-08 19:10 +0200
      Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-08 22:30 +0200
        Re: Require packages to build without any configured DNS Paul Wise <pabs@debian.org> - 2021-09-09 06:50 +0200
          Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-09 09:40 +0200
            Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-12 21:10 +0200
        Re: Require packages to build without any configured DNS Josh Triplett <josh@joshtriplett.org> - 2021-09-10 11:00 +0200
          Re: Require packages to build without any configured DNS Thomas Goirand <zigo@debian.org> - 2021-09-12 21:10 +0200
            Re: Require packages to build without any configured DNS Josh Triplett <josh@joshtriplett.org> - 2021-09-13 06:20 +0200
    Re: Require packages to build without any configured DNS Josh Triplett <josh@joshtriplett.org> - 2021-09-08 18:10 +0200
      Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-10 22:40 +0200
        Re: Require packages to build without any configured DNS Don Armstrong <don@debian.org> - 2021-09-14 09:00 +0200
          Re: Require packages to build without any configured DNS Adrian Bunk <bunk@debian.org> - 2021-09-14 14:50 +0200
    Re: Require packages to build without any configured DNS Johannes Schauer Marin Rodrigues <josch@debian.org> - 2021-09-14 10:20 +0200
      Re: Require packages to build without any configured DNS Mattia Rizzolo <mattia@debian.org> - 2021-09-14 15:40 +0200
        Re: Require packages to build without any configured DNS Johannes Schauer Marin Rodrigues <josch@debian.org> - 2021-09-14 19:20 +0200
          Re: Require packages to build without any configured DNS Scott Kitterman <debian@kitterman.com> - 2021-09-14 19:50 +0200

Page 1 of 2  [1] 2  Next page →

#101558 — Require packages to build without any configured DNS

[Multipart message — attachments visible in raw view] — view raw

Hi,

during the year, a src:dnspython change made it so that any software
importing that library now requires a valid /etc/resolv.conf with at
least one nameserver configured.

This also made it so that something between 50-100 packages now fail to
build if the build system doesn't have any working /etc/resolv.conf.  I
venture to say that this is a very reasonable configuration to have in a
build system that tries to be network-disabled.

It must be noted that no actual network operation happen, so this
doesn't fall into the "no network activity" bucket.


This is the bug that was filed against dnspython: https://bugs.debian.org/989171


Do anybody on the list have any opinion on where is the bug, on
dnspython, or on the build environment?


As the pbuilder maintainer, I've been asked to make it serve a
non-working /etc/resolv.conf just to make that bug above moot, so I'm
quite biased on the matter myself :)

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
More about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[toc] | [next] | [standalone]

#101575

On Mon, 06 Sep 2021, Mattia Rizzolo wrote:
> It must be noted that no actual network operation happen, so this
> doesn't fall into the "no network activity" bucket.
> 
> This is the bug that was filed against dnspython: https://bugs.debian.org/989171
> 
> Do anybody on the list have any opinion on where is the bug, on
> dnspython, or on the build environment?

Do you know why dnspython doesn't just fall back to socket.getaddrinfo
if it can't parse /etc/resolv.conf [or maybe why python applications
using dnspython don't fall back to that if dnspython fails?]

That seems like the right default unless you really, really need to talk
to a full-fledged DNS server directly.


-- 
Don Armstrong                      https://www.donarmstrong.com

He quite enjoyed the time by himself in the mornings. The day was too
early to have started going really wrong.
  -- Terry Pratchet _Only You Can Save Mankind_ p133

[toc] | [prev] | [next] | [standalone]

#101590

On Tue, Sep 07, 2021 at 04:41:49PM -0700, Don Armstrong wrote:
> On Mon, 06 Sep 2021, Mattia Rizzolo wrote:
> > It must be noted that no actual network operation happen, so this
> > doesn't fall into the "no network activity" bucket.
> > 
> > This is the bug that was filed against dnspython: https://bugs.debian.org/989171
> > 
> > Do anybody on the list have any opinion on where is the bug, on
> > dnspython, or on the build environment?
> 
> Do you know why dnspython doesn't just fall back to socket.getaddrinfo
> if it can't parse /etc/resolv.conf [or maybe why python applications
> using dnspython don't fall back to that if dnspython fails?]
> 
> That seems like the right default unless you really, really need to talk
> to a full-fledged DNS server directly.

https://github.com/rthalley/dnspython

  dnspython provides both high and low level access to DNS. The high level 
  classes perform queries for data of a given name, type, and class, and 
  return an answer set. The low level classes allow direct manipulation of 
  DNS zones, messages, names, and records.
...
  dnspython is a utility to work with DNS, /etc/hosts is thus not used. 
  For simple forward DNS lookups, it's better to use socket.getaddrinfo() 
  or socket.gethostbyname().

  dnspython originated at Nominum where it was developed to facilitate the 
  testing of DNS software.


cu
Adrian

[toc] | [prev] | [next] | [standalone]

#101593

On 9/6/21 4:39 PM, Mattia Rizzolo wrote:
> Hi,
> 
> during the year, a src:dnspython change made it so that any software
> importing that library now requires a valid /etc/resolv.conf with at
> least one nameserver configured.
> 
> This also made it so that something between 50-100 packages now fail to
> build if the build system doesn't have any working /etc/resolv.conf.  I
> venture to say that this is a very reasonable configuration to have in a
> build system that tries to be network-disabled.
> 
> It must be noted that no actual network operation happen, so this
> doesn't fall into the "no network activity" bucket.
> 
> 
> This is the bug that was filed against dnspython: https://bugs.debian.org/989171
> 
> 
> Do anybody on the list have any opinion on where is the bug, on
> dnspython, or on the build environment?
> 
> 
> As the pbuilder maintainer, I've been asked to make it serve a
> non-working /etc/resolv.conf just to make that bug above moot, so I'm
> quite biased on the matter myself :)

I already stated this during discussions on IRC, but I will reiterate
here to feed the discussion.

The only place where dnspython needs a working /etc/resolv.conf is
testing. Mandating a non-working /etc/resolv.conf will only result in
having less tests in that package, which will potentially lower the
package quality insurance, rather than improving Debian. When addressing
this problem, we should ask ourselves: what is it that we're actually
trying to fix. IMO: not much here... There's nothing broken.

Therefore, I am in the opinion that we should let the package run its
test as much as possible, especially considering that it's not doing
actual network outbound connections.

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#101594

On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു 
+0200 +0200, Thomas Goirand <zigo@debian.org> wrote:
> Therefore, I am in the opinion that we should let the package run its
> test as much as possible, especially considering that it's not doing
> actual network outbound connections.

Can't we run these tests as autopkgtests?

[toc] | [prev] | [next] | [standalone]

#101595

On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote:
> On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand <zigo@debian.org> wrote:
> > Therefore, I am in the opinion that we should let the package run its
> > test as much as possible, especially considering that it's not doing
> > actual network outbound connections.
> 
> Can't we run these tests as autopkgtests?

That would only move the problem elsewhere, since this creates a similar 
question whether such tests should need a "needs-internet" restriction
for autopkgtest which might result in them being skipped in most cases.

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#101603

On ബു, സെപ്റ്റം 8 2021 at 06:10:56 വൈകു 
+0300 +0300, Adrian Bunk <bunk@debian.org> wrote:
> On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote:
>>  On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു 
>> +0200 +0200, Thomas Goirand <zigo@debian.org> wrote:
>>  > Therefore, I am in the opinion that we should let the package run 
>> its
>>  > test as much as possible, especially considering that it's not 
>> doing
>>  > actual network outbound connections.
>> 
>>  Can't we run these tests as autopkgtests?
> 
> That would only move the problem elsewhere, since this creates a 
> similar
> question whether such tests should need a "needs-internet" restriction
> for autopkgtest which might result in them being skipped in most 
> cases.
> 

I don't think the default autopkgtest environment should be as 
restrictive as the build environment. So adding this to default 
autopkgtest enviroment is not the same as adding it to default build 
environment.
> 

[toc] | [prev] | [next] | [standalone]

#101611

On Wed, Sep 8, 2021 at 9:51 PM Pirate Praveen wrote:

> I don't think the default autopkgtest environment should be as
> restrictive as the build environment. So adding this to default
> autopkgtest enviroment is not the same as adding it to default build
> environment.

It is already the case that the autopkgtest "needs-internet"
restriction is not enabled by default. Personally I think that is the
right choice, to give people the option of not running such tests on
offline machines or where arbitrary outgoing Internet connections are
not allowed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101597

On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote:
> Do anybody on the list have any opinion on where is the bug, on
> dnspython, or on the build environment?

I concur that the absence of /etc/resolv.conf is a sensible
configuration. Indeed, it is my method-of-choice for implementing
poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It
doesn't actually prevent network access, but makes accidental network
access very unlikely.

I'm unsure whether /etc/resolv.conf is supposed to be essential. None of
the packages in that set ensure its creation. Rather debootstrap and
mmdebstrap have extra code to copy the host's /etc/resolv.conf into the
chroot. Therefore any created chroot will contain one. However that
seems more like an artifact of the bootstrap implementation rather than
an intentional guarantee to me.

As such, I err on dnspython being in need of a fix.

Helmut

[toc] | [prev] | [next] | [standalone]

#101600

On Wed, Sep 08, 2021 at 05:44:34PM +0200, Helmut Grohne wrote:
> On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote:
> > Do anybody on the list have any opinion on where is the bug, on
> > dnspython, or on the build environment?
> 
> I concur that the absence of /etc/resolv.conf is a sensible
> configuration. Indeed, it is my method-of-choice for implementing
> poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It
> doesn't actually prevent network access, but makes accidental network
> access very unlikely.

This does not work when software has a built-in fallback IP when no 
nameserver is configured in /etc/resolv.conf

dnspython removing such a built-in fallback IP address and returning an 
error instead is what caused the breakage in reproducible builds.

>...
> As such, I err on dnspython being in need of a fix.

What kind of fix?
Re-adding a default of 127.0.0.1 (or even 8.8.8.8) when no nameserver
is found in /etc/resolv.conf ?

dnspython is initialized several packages down in the callstack for the 
failing packages by a concurrent networking library, and I am not aware 
of any package in this stack doing something unreasonable.

> Helmut

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#101602

On 9/8/21 5:44 PM, Helmut Grohne wrote:
> As such, I err on dnspython being in need of a fix.

Dnspython isn't broken in any ways, it doesn't do any network access.
The only thing you're going to achieve is:
- more work for the maintainers (who will need to disable or patch the
tests).
- probably less tests (because the maintainer will probably choose to
simply disable the tests), which means less quality.

Again: what are you trying to achieve?

On 9/8/21 6:01 PM, Josh Triplett wrote:
> Now, that said, if the build process actually wants a DNS server to
> run tests against, it should provide or depend on such a DNS server,
> and configure it for such tests.

Just to be 100% sure we're on the same page: that's *not* what dnspython
is doing. It's a client library that's testing parsing of the
/etc/resolv.conf format, and it just expects it to be there for parsing.

The code has:

class Resolver:
    def __init__(self, filename='/etc/resolv.conf', configure=True):

Later on, the class calls the method read_resolv_conf that has:

    try:
        f = stack.enter_context(open(f))
    except OSError:
        # /etc/resolv.conf doesn't exist, can't be read, etc.
        raise NoResolverConfiguration

The test cases are of course instantiating the Resolver object to test
it, and calls it with the default configuration (ie: /etc/resolv.conf as
default), with something like this:

r = dns.resolver.Resolver(configure=False)

So, any test case that does that fails simply because the *FILE*
/etc/resolv.conf isn't there on the filesystem (and not because there's
no working DNS server, which would be just fine).

One could argue that the test cases should aways instantiate the
Resolver object with a non-default (test only) filename argument. Well,
I agree with that: please propose such a patch upstream. But does it
deserve anyone time? I don't think so. We're achieving absolutely
nothing doing this: this doesn't improve Debian...

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#101610

On Wed, Sep 8, 2021 at 8:23 PM Thomas Goirand wrote:

> Later on, the class calls the method read_resolv_conf that has:

It also fails if the file exists but has no nameservers:

        if len(self.nameservers) == 0:
            raise NoResolverConfiguration

> So, any test case that does that fails simply because the *FILE*
> /etc/resolv.conf isn't there on the filesystem (and not because there's
> no working DNS server, which would be just fine).

That seems like a bug in the test cases, they shouldn't be testing the
build time environment like that, since it could differ from the
runtime environment. There are nss_wrapper/resolv_wrapper for mocking
away the build-time DNS resolving infrastructure.

https://cwrap.org/nss_wrapper.html
https://cwrap.org/resolv_wrapper.html

> One could argue that the test cases should aways instantiate the
> Resolver object with a non-default (test only) filename argument.

Agreed.

> I agree with that: please propose such a patch upstream. But does it
> deserve anyone time? I don't think so. We're achieving absolutely
> nothing doing this: this doesn't improve Debian...

It improves support for offline systems, which often don't have a
working /etc/resolv.conf

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#101618

On Thu, Sep 09, 2021 at 04:45:35AM +0000, Paul Wise wrote:
>...
> That seems like a bug in the test cases, they shouldn't be testing the
> build time environment like that, since it could differ from the
> runtime environment.

These are usually not the tests of dnspython.

dnspython even has some support for using a different file instead of 
/etc/resolv.conf, the problem is that there are several other packages
in the callstack before dnspython in these failing tests.

Note that even if you would be mocking /etc/resolv.conf, you'd still 
have to add a nameserver IP address in the mocked /etc/resolv.conf
At that point you might as well install the mocked resolv.conf
as /etc/resolv.conf in build environments.

> There are nss_wrapper/resolv_wrapper for mocking
> away the build-time DNS resolving infrastructure.
> 
> https://cwrap.org/nss_wrapper.html
> https://cwrap.org/resolv_wrapper.html
>...

This is mocking the C library functionality,
which is not used by dnspython.

> bye,
> pabs

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#101678

On 9/9/21 9:07 AM, Adrian Bunk wrote:
> On Thu, Sep 09, 2021 at 04:45:35AM +0000, Paul Wise wrote:
>> ...
>> That seems like a bug in the test cases, they shouldn't be testing the
>> build time environment like that, since it could differ from the
>> runtime environment.
> 
> These are usually not the tests of dnspython.
> 
> dnspython even has some support for using a different file instead of 
> /etc/resolv.conf, the problem is that there are several other packages
> in the callstack before dnspython in these failing tests.
> 
> Note that even if you would be mocking /etc/resolv.conf, you'd still 
> have to add a nameserver IP address in the mocked /etc/resolv.conf
> At that point you might as well install the mocked resolv.conf
> as /etc/resolv.conf in build environments.

Exactly. Which is why I wrote that we would be achieving nothing by
mandating a broken /etc/resolv.conf *IN THIS SPECIFIC CASE* (ie: where
the package is *NOT* doing any exteral DNS query).

I do believe, however, that we should not allow real DNS queries during
build time (just like accessing any external resource on the internet
should be forbiden, DNS shouldn't be an exception). But that's not what
happening with dnspython (it builds fine without any internet
connectivity, it just wants a valid /etc/resolv.conf so it can parse it).

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#101630

Thomas Goirand wrote:
> On 9/8/21 6:01 PM, Josh Triplett wrote:
> > Now, that said, if the build process actually wants a DNS server to
> > run tests against, it should provide or depend on such a DNS server,
> > and configure it for such tests.
> 
> Just to be 100% sure we're on the same page: that's *not* what dnspython
> is doing. It's a client library that's testing parsing of the
> /etc/resolv.conf format, and it just expects it to be there for parsing.

I understood that; I'd just wanted to make it clear that while programs
parsing /etc/resolv.conf should assume a nameserver on localhost if
/etc/resolv.conf doesn't exist, that doesn't mean that build processes
should actually require that such a nameserver be running.

[toc] | [prev] | [next] | [standalone]

#101679

On 9/10/21 10:53 AM, Josh Triplett wrote:
> Thomas Goirand wrote:
>> On 9/8/21 6:01 PM, Josh Triplett wrote:
>>> Now, that said, if the build process actually wants a DNS server to
>>> run tests against, it should provide or depend on such a DNS server,
>>> and configure it for such tests.
>>
>> Just to be 100% sure we're on the same page: that's *not* what dnspython
>> is doing. It's a client library that's testing parsing of the
>> /etc/resolv.conf format, and it just expects it to be there for parsing.
> 
> I understood that; I'd just wanted to make it clear that while programs
> parsing /etc/resolv.conf should assume a nameserver on localhost if
> /etc/resolv.conf doesn't exist

I don't understand why that should be the case. If there's a local
nameserver, then it should be configured in resolv.conf as "nameserver
127.0.0.1" no?

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#101685

Thomas Goirand wrote:
> On 9/10/21 10:53 AM, Josh Triplett wrote:
> > Thomas Goirand wrote:
> >> On 9/8/21 6:01 PM, Josh Triplett wrote:
> >>> Now, that said, if the build process actually wants a DNS server to
> >>> run tests against, it should provide or depend on such a DNS server,
> >>> and configure it for such tests.
> >>
> >> Just to be 100% sure we're on the same page: that's *not* what dnspython
> >> is doing. It's a client library that's testing parsing of the
> >> /etc/resolv.conf format, and it just expects it to be there for parsing.
> > 
> > I understood that; I'd just wanted to make it clear that while programs
> > parsing /etc/resolv.conf should assume a nameserver on localhost if
> > /etc/resolv.conf doesn't exist
> 
> I don't understand why that should be the case. If there's a local
> nameserver, then it should be configured in resolv.conf as "nameserver
> 127.0.0.1" no?

Three reasons:

- It's the documented behavior when /etc/resolv.conf doesn't exist. `man
  resolv.conf` says "If this file does not exist, only the name server
  on the local machine will be queried, and the search list contains the
  local domain name determined from the hostname.".
- It's the established historical behavior of glibc, musl, adns, and
  various other resolvers, so breaking it would also be a backwards
  compatibility break.
- This behavior allows providing DNS for a chroot or similar without
  hacks like mounting a file over /etc/resolv.conf.

[toc] | [prev] | [next] | [standalone]

#101599

Mattia Rizzolo wrote:
> during the year, a src:dnspython change made it so that any software
> importing that library now requires a valid /etc/resolv.conf with at
> least one nameserver configured.
> 
> This also made it so that something between 50-100 packages now fail to
> build if the build system doesn't have any working /etc/resolv.conf.  I
> venture to say that this is a very reasonable configuration to have in a
> build system that tries to be network-disabled.
> 
> It must be noted that no actual network operation happen, so this
> doesn't fall into the "no network activity" bucket.
> 
> 
> This is the bug that was filed against dnspython: https://bugs.debian.org/989171
> 
> 
> Do anybody on the list have any opinion on where is the bug, on
> dnspython, or on the build environment?

I think dnspython's previous approach was correct: just like glibc, musl, and
other libraries, if /etc/resolv.conf is missing they should treat that as
though it specified a nameserver on localhost. The change to make that a
configuration error, instead, breaks real configurations that intentionally
don't have /etc/resolv.conf.

Among other things, having a DNS server on localhost (or forwarding the DNS
port on localhost to your real DNS server) means that a chroot without
/etc/resolv.conf still has functional DNS.

Now, that said, if the build process actually wants a DNS server to run tests
against, it should provide or depend on such a DNS server, and configure it for
such tests. But a build process that's just *importing the dnspython library*
should not need to have either /etc/resolv.conf *or* a functional DNS server.

- Josh Triplett

[toc] | [prev] | [next] | [standalone]

#101646

On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote:
>...
> I think dnspython's previous approach was correct: just like glibc, musl, and
> other libraries, if /etc/resolv.conf is missing they should treat that as
> though it specified a nameserver on localhost.

How libraries implement a standard high-level C interface is not 
necessarily relevant for how a DNS library implements a low-level 
interface.

> The change to make that a
> configuration error, instead, breaks real configurations that intentionally
> don't have /etc/resolv.conf.
> 
> Among other things, having a DNS server on localhost (or forwarding the DNS
> port on localhost to your real DNS server) means that a chroot without
> /etc/resolv.conf still has functional DNS.

It is debatable whether this is a feature or a bug.

Having to configure a nameserver when you want DNS is less surprising 
than software automatically using nameservers like 127.0.0.1 or 8.8.8.8
when none is configured.

> Now, that said, if the build process actually wants a DNS server to run tests
> against, it should provide or depend on such a DNS server, and configure it for
> such tests.
>...

Depending on and configuring a normal DNS server might not happen in 
practice, since the build process running as a normal user would have
to configure and manually start it running on a non-privileged port.

Trying to resolve DNS addresses on the internet during the build is
not permitted.

> - Josh Triplett

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#101703

On Fri, 10 Sep 2021, Adrian Bunk wrote:
> On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote:
> >...
> > I think dnspython's previous approach was correct: just like glibc, musl, and
> > other libraries, if /etc/resolv.conf is missing they should treat that as
> > though it specified a nameserver on localhost.
> 
> How libraries implement a standard high-level C interface is not 
> necessarily relevant for how a DNS library implements a low-level 
> interface.

It seems to me that upstream should just not raise
NoResolverConfiguration, and instead not configure any nameservers.

Then, if someone tries to resolve without any configured nameservers,
NoNameservers will be raised, which is the same thing that happens if
there are no good nameservers, and is less inconsistent with the
previous behavior.


-- 
Don Armstrong                      https://www.donarmstrong.com

2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.devel

csiph-web