Re: [DNSOP] SIG(0) useful (and used?)

Mark Elkins <mje@posix.co.za> Wed, 20 June 2018 07:50 UTC

Return-Path: <mje@posix.co.za>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3294C12E039 for <dnsop@ietfa.amsl.com>; Wed, 20 Jun 2018 00:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level:
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jmUbJ4s6JFm for <dnsop@ietfa.amsl.com>; Wed, 20 Jun 2018 00:49:59 -0700 (PDT)
Received: from relay.vweb.co.za (relay.vweb.co.za [IPv6:2001:42a0::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A0A128CF3 for <dnsop@ietf.org>; Wed, 20 Jun 2018 00:49:59 -0700 (PDT)
Received: from [165.255.69.216] (port=37290 helo=[160.124.48.103]) by relay.vweb.co.za with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <mje@posix.co.za>) id 1fVXsH-0004VE-2F for dnsop@ietf.org; Wed, 20 Jun 2018 09:49:53 +0200
Reply-To: mje@posix.co.za
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
References: <6C8533C2-6510-4A0E-A7EA-50EB83E43A7D@isc.org> <CD6DB8C1-108A-433E-8CD9-34F549844D10@isc.org> <D770751E-437F-48AA-8B1B-19A9F3A966CE@akamai.com>
From: Mark Elkins <mje@posix.co.za>
Organization: Posix Systems
Message-ID: <c162b656-17ec-a9ed-d525-ede08d1d99c2@posix.co.za>
Date: Wed, 20 Jun 2018 09:49:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <D770751E-437F-48AA-8B1B-19A9F3A966CE@akamai.com>
Content-Type: multipart/alternative; boundary="------------F3F37FC6D6D81288A930F385"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fcxrZUOS0bsQmqn7t_4JmqM4UI4>
Subject: Re: [DNSOP] SIG(0) useful (and used?)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2018 07:50:05 -0000

I run bind on my authoritative nameservers. I run linux on a number of
laptops. When these laptops are provided a DHCP address, they use SIG(0)
to authenticate a forwards zone update to update their current (DHCP
provided) IPv4 address into the Zone. I've been doing this for years -
ever since Johan Ihrén taught me how to do so on his DNS training
courses. A number of other people may also be doing this for the same
reason. This is totally automatic - just once in a while, I update the
SIG(0) "password".

If there is another newer way that does the same - I'd be willing to
look at it - otherwise I enjoy this current methodology.


On 19/06/2018 23:41, Wellington, Brian wrote:
> SIG(0) was implemented in BIND 9 back when BIND 9 was basically the only modern implementation, and no one used it then.  The fact that no servers have implemented it since then means that there really isn’t any demand.
>
> Brian  
>
>> On Jun 19, 2018, at 2:20 PM, Mark Andrews <marka@isc.org> wrote:
>>
>> SIG(0) is much superior for machines updating their own data  to TSIG as you don’t need a secondary storage for the TSIG key.   You can replace a master server without having to worry about transferring TSIG secrets off a dead machine. You just copy the zone from a slave and go.
>>
>> There are other scenarios where it is also superior like automaton delegating  In the reverse tree.
>>
>> No I don’t think it should go. 
>>
>> It should be widely implemented so it can be used. There is a lot of self fulfilling prophecy in the DNS of people will never is this so we won’t implement it. 
>>
>> -- 
>> Mark Andrews
>>
>>> On 20 Jun 2018, at 06:48, Ondřej Surý <ondrej@isc.org> wrote:
>>>
>>> Hi,
>>>
>>> as far as I could find on the Internet there are only SIG(0) implementation in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I haven’t found; no mentions of real deployment was found over the Internet (but you can blame Google for that)...
>>>
>>> Do people think the SIG(0) is something that we should keep in DNS and it will be used in the future or it is a good candidate for throwing off the boat?
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ondrej@isc.org
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje@posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za