Re: [mif] RFC 6731 implementations

Petr Menšík <pemensik@redhat.com> Wed, 09 November 2022 22:02 UTC

Return-Path: <pemensik@redhat.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414FCC14F74F for <mif@ietfa.amsl.com>; Wed, 9 Nov 2022 14:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.678
X-Spam-Level:
X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy1g16dTTFFB for <mif@ietfa.amsl.com>; Wed, 9 Nov 2022 14:02:12 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0919C1522D9 for <mif@ietf.org>; Wed, 9 Nov 2022 14:02:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668031331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SaD8dgJKEY4Q4YmjDDj04uXfXlbPdoSBrlEpivtw3f4=; b=HiCMCFn2QP7hDY8zFHO2yHQQld65qKROVvt6v1LNGEk3xcM4wSL29M7qUdpbZ4TTWWKNsV eiXOrsptqrQBg45UbSS1ob0wXtcuwrOriCXESH87CFxYUg3S3SXZvk4q59PKA/pOfepTUi lSS2xDBmJpum66o/+aHdhbB1xb7HX5Y=
Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-393-5k2E_PB8OnK4jWHKaOv2mg-1; Wed, 09 Nov 2022 17:02:08 -0500
X-MC-Unique: 5k2E_PB8OnK4jWHKaOv2mg-1
Received: by mail-ej1-f69.google.com with SMTP id ga26-20020a1709070c1a00b007ad4a55d6e1so63071ejc.6 for <mif@ietf.org>; Wed, 09 Nov 2022 14:02:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:subject:from:references:cc:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=SaD8dgJKEY4Q4YmjDDj04uXfXlbPdoSBrlEpivtw3f4=; b=lQWwURIXEA+bNvkckiBYkJEo/gbGTCxzzV42/mjZc/o8rtqaqFDR3uhXYXVKrOkRDI u9DA3gaZ2xzxumk4Cl0LgZCREn6VzztBShdfqjO1sVT3nYcd3oxbEO2cqZFlMKLFMGYQ R7SRAzjYL9sBKuMtNbTiM8Lru873+DR7jjYjzauOgOg3ctn7JUtDFsZ8/AVi9HPDQRIo RAgGjKeZP6HkvkVaCY7CE2RDPtJPOTgw+0OeXSLK0HCp9kPE0e1Bi0HR9l1EeInGEsdY bt67qwcReoOp6D+kkUv9XEUl0i39sz5n4zXcYGYtY1DEv3hZSHvJslUqZrt7Ke1gl4TV la4Q==
X-Gm-Message-State: ACrzQf3cOMaGFCqNQN/mvZmGMQzPTjagB1lKMDab4sXrL7baZeoUSOac kWW3vWqYG2PxFZiUC/ahqfvQ4ijPKwxxScSJzfSYcYKxX9t/4qgSfjfyemYmdWy16pFmbW+ZRQB NSKc=
X-Received: by 2002:a17:907:31c1:b0:742:28a3:5d08 with SMTP id xf1-20020a17090731c100b0074228a35d08mr57614187ejb.112.1668031327198; Wed, 09 Nov 2022 14:02:07 -0800 (PST)
X-Google-Smtp-Source: AMsMyM7L4mSIReW9heINUQTNaX628c679XMxz+80ZdrN7k2fdiPFWMWxwiAnx1DPssWvsgKUTqMePQ==
X-Received: by 2002:a17:907:31c1:b0:742:28a3:5d08 with SMTP id xf1-20020a17090731c100b0074228a35d08mr57614173ejb.112.1668031326890; Wed, 09 Nov 2022 14:02:06 -0800 (PST)
Received: from [10.43.2.41] (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id u17-20020a1709061db100b007789e7b47besm6313717ejh.25.2022.11.09.14.02.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Nov 2022 14:02:06 -0800 (PST)
Message-ID: <998abc0f-8cc9-d628-2ad8-c936fa923f85@redhat.com>
Date: Wed, 09 Nov 2022 23:02:05 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1
Content-Language: en-US
To: Margaret Cullen <mrcullen42@gmail.com>
Cc: mif@ietf.org
References: <83c25827-1211-8c1c-9001-e6cb6fdaaab9@redhat.com> <E6A381F3-3600-48AE-A9BB-116A5907734C@gmail.com>
From: Petr Menšík <pemensik@redhat.com>
In-Reply-To: <E6A381F3-3600-48AE-A9BB-116A5907734C@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------XOY0Wulkm6OL6e0k1TUBtZWa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mif/5HPEOK0OjSUePGDpOSUNkNlyiK8>
Subject: Re: [mif] RFC 6731 implementations
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2022 22:02:17 -0000

Hello Margaret,

I think the section 4.7 confuses me. I think I understand its 
motivation. But every solid validation resolver implementation wants to 
fetch its own CNAME follow on its own. If the cname does not lead to the 
same zone, it drops whatever the forwarder send and asks again. I admit 
that is common for iterative recursive servers, which often do not have 
any forwarders at all. I think only caching stub-resolvers, like dnsmasq 
or systemd-resolved, would trust also follow up.

But I think the most confusing are priorities of described in section 
4.1. Is has quite complex logic. But at the same time the whole 
mechanism is recommended to be enabled only for trusted networks, where 
bogus redirecting domains is unlikely. Were there defined use cases, 
when supplying the same domain on multiple networks required different 
preference from IP routing records? Which could be solved by making 
lower priority on wifi connection, if wired is also available, for example.

Could be that complexity, mixing also DNSSEC validation into the 
equation, a reason which resulted in no implementations widely used?

Regards,
Petr

On 03. 11. 22 18:33, Margaret Cullen wrote:
> Hi Petr,
>
> There is no successor to this document, and the WG has been closed for some time.
>
> What parts of the specification do you find confusing?  There may be folks on this list who can answer any questions you have.
>
> Margaret
> (Former mif co-chair)
>
>> On Nov 3, 2022, at 8:18 AM, Petr Menšík <pemensik@redhat.com> wrote:
>>
>> Hello former MIF group members,
>>
>> I have found RFC 6731 [1], which is Standard Tracks since December 2012. I have found reference to it from some draft of add WG. When I read it, I found it proposes solution to existing problem on Linux desktops, which is not yet sufficiently solved. A bit similar attempt is implemented by systemd-resolved [2], but does not use any standardized way.
>>
>> I think every device with multiple interfaces is potential candidate for it. Every laptop with ethernet+wifi, every smart phone with wifi+cellular network. Yet I haven't found any attempts to implement RFC 6731. Do you know existing implementations for any operating system? Is it used somewhere already? Is there a reason why it is not widely used?
>>
>> I work in Red Hat as a Software Engineer, maintaining some DNS packages. Dnsmasq has some integration with Network Manager, which does something similar. Yet they are misusing dns-search parameter of DHCP protocol. I would like to add more proper support, but I find current standards confusing. Is there more relevant successor to this standard?
>>
>> Best Regards,
>> Petr
>>
>> 1. https://www.rfc-editor.org/rfc/rfc6731.html
>> 2. https://systemd.io/RESOLVED-VPNS/
>>
>> -- 
>> Petr Menšík
>> Software Engineer, RHEL
>> Red Hat, http://www.redhat.com/
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>>
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB