From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id F15FB3858297 for ; Fri, 29 Jul 2022 16:23:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F15FB3858297 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-203-wNNPt3lPMxSoVofX8Bjv2Q-1; Fri, 29 Jul 2022 12:23:19 -0400 X-MC-Unique: wNNPt3lPMxSoVofX8Bjv2Q-1 Received: by mail-qv1-f69.google.com with SMTP id ln10-20020a0562145a8a00b004749ae27efcso381559qvb.22 for ; Fri, 29 Jul 2022 09:23:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:organization:in-reply-to :content-transfer-encoding; bh=nAXL97IAtMboGx5mBEhJOvTOOsl+zJaCAQg+loorkgo=; b=V70LMED+jR4l/OPJXgQzjzzW+mRLpV6GbKo7k/efO5mpaHpbSti/yRZUBddRyO8tcH S6RJhZvav/rAvTLmFKV2z08aVN2xsVfJLV2aivwl0FwphmnF1q75bwf/uEw0xynQR+Oy wAZdSTEt5ebkJaxP3LFCIW6zpKlrBKjbMM4nPiPsOE3xHoRr5qtz4NAoyj6iJHnRcwFM l2pIG8s27PjFTzASwA9pMq6y6Su+AK0IIjVUQYCY9uO/0E62zn51Pyziv9OcRJNLJOEw gyqvQNo7dpA8CgRgFYPEgkiWxGInvLdiGNhEkGVue0vv2pZSaZn7w2o3TULq7jJYOL2N Ch2A== X-Gm-Message-State: ACgBeo2RVhcAmcbgvhQJBjz0E9Dvdw/lndQwHPR74od6MGN8RyK7uayN Up1qPNh2U7lzCrCDMGH1WbjYsNgQBemNlzqPW2E8Cex+ntrbWtcMGi//df+b9a/5fmT65r7b0MU 4h5RVfj+M/w4K0Jz3cnI= X-Received: by 2002:ad4:5fc7:0:b0:474:1b46:907f with SMTP id jq7-20020ad45fc7000000b004741b46907fmr4208336qvb.55.1659111798666; Fri, 29 Jul 2022 09:23:18 -0700 (PDT) X-Google-Smtp-Source: AA6agR76dxLCSuZXj28OJHwleQW6qv2vHDa5q6hY92PjY3f3E2kzq0S9GeH5ldtKSP48xrqSEb5I2Q== X-Received: by 2002:ad4:5fc7:0:b0:474:1b46:907f with SMTP id jq7-20020ad45fc7000000b004741b46907fmr4208321qvb.55.1659111798428; Fri, 29 Jul 2022 09:23:18 -0700 (PDT) Received: from [192.168.0.241] (192-0-145-146.cpe.teksavvy.com. [192.0.145.146]) by smtp.gmail.com with ESMTPSA id x10-20020a05620a448a00b006b618e006ffsm2777137qkp.2.2022.07.29.09.23.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jul 2022 09:23:17 -0700 (PDT) Message-ID: <5145d15f-1381-dc7b-a469-bde3159b67ca@redhat.com> Date: Fri, 29 Jul 2022 12:23:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: nsswitch.conf - db service for hosts To: Peter Polgar , Carlos O'Donell , libc-help@sourceware.org, "Dmitry V. Levin" References: From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2022 16:23:22 -0000 On 7/24/22 12:56, Peter Polgar via Libc-help wrote: > Thanks! Now it's clear to me. > > Then any idea on how to achieve a static fallback for IP if DNS fails? > My idea was to have it likes this: > hosts: files mdns dns db The only solutions I know about involve a local DNS server that can be tried as a last resort which provides the fallback resolution. > So files and mdns can handle localhost and .local first then if dns fails > db can have a record for the host in question. Without db this apparently > won't work. NSS was not designed to be used in this way. Each service provider should be fully authoritative for the service it provides, with files being the exception that generally goes first or last, depending on the use case (MERGE is useful there too). A solution along the lines of remembering the last result [1][2] and using that result if everything else fails was discussed, but this kind of design change has additional complexity that we don't want to accept unless it really can't be solved in another way. What you might use is a "fallback" NSS module that does what you want and is placed at the end of the list. I know that Alt Linux (CC'ing Dmitry) has a libnss_fallback module, but I don't know if it meets your requirements. Good luck. -- Cheers, Carlos. [1] https://developers.redhat.com/blog/2018/11/26/etc-nsswitch-conf-non-complexity [2] https://bugzilla.redhat.com/show_bug.cgi?id=1374228