RE: Inline-signing feature request: Directly set the signed zone's serial number

[Chris Thompson]

On Oct 17 2014, Darcy Kevin (FCA) wrote:


FYI,
If you had to do this all over again, and your tools are flexible
enough to handle arbitrary RRTYPEs, you might consider using a "private"
RRTYPE (in the 65280-65534 range). See 
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

and/or http://tools.ietf.org/html/rfc6895.

Repurposing HINFO for something other than expressing host-related info,
is just downright confusing/surprising. Principle of Least Astonishment.


Well, yes ... in an ideal world. Which this is not!

It is perhaps only a convenience that BIND and its utilities (named-checkzone
and nsupdate, in this context) process HINFO records in a convenient-to-humans
text format.

But the isuue of having to support Windows DNS Server implementations as
stealth slaves was a very real issue for us. I am not clear that even the
most recent versions fully support unknown record types in the style of
RFC3597. The ones we were having to deal with at the time most certainly
did not!

As for the Principle of Least Astionishment, I could replace


1. No-one wants to use HINFO at a zone apex for any other reason.


with

1'. (Almost) no-one uses HINFO for its original purpose anywhere in
   the DNS.

and I think I might get away with it.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Inline-signing feature request: Directly set the signed zone's serial number

[Darcy Kevin (FCA)]

FYI,
If you had to do this all over again, and your tools are flexible 
enough to handle arbitrary RRTYPEs, you might consider using a "private" RRTYPE 
(in the 65280-65534 range). See 
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
 and/or http://tools.ietf.org/html/rfc6895.

Repurposing HINFO for something other than expressing host-related info, is 
just downright confusing/surprising. Principle of Least Astonishment.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Thompson
Sent: Friday, October 17, 2014 12:23 PM
To: Bind Users Mailing List
Cc: Tony Finch
Subject: Re: Inline-signing feature request: Directly set the signed zone's 
serial number

On Oct 8 2014, Tony Finch wrote:

>Terry Burton  wrote:
>>
>> This is especially useful in bootstrapping scenarios where the zone 
>> data is held under strict revision control or generated by some 
>> provisioning system that "owns" the serial number.
>
>Our provisioning system used to think it owned zone serial numbers, but 
>when we started signing we moved the version tag into an HINFO record.

In case anyone wonders "why HINFO?", this was because

1. No-one wants to use HINFO at a zone apex for any other reason.
2. As a very ancient type, even early Windows DNS Server implementations
   didn't object to it when slaving the zones.
3. One can put arbitrary text strings in it.

... but also for the much less reputable

4. As a low numbered type, it got sorted immediately after the apex
   SOA and NS records in a zone file normalised by "named-checkzone -D".

Well, it served me right when we later had to put an A record (sorts before
HINFO) at the apex of cam.ac.uk and I had to modify our normalised-zone-file- 
comparsion program to allow for that! 

--
Chris Thompson
Email: c...@cam.ac.uk

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Chris Thompson]

On Oct 8 2014, Tony Finch wrote:


Terry Burton  wrote:


This is especially useful in bootstrapping scenarios where the zone
data is held under strict revision control or generated by some
provisioning system that "owns" the serial number.


Our provisioning system used to think it owned zone serial numbers, but
when we started signing we moved the version tag into an HINFO record.


In case anyone wonders "why HINFO?", this was because

1. No-one wants to use HINFO at a zone apex for any other reason.
2. As a very ancient type, even early Windows DNS Server implementations
  didn't object to it when slaving the zones.
3. One can put arbitrary text strings in it.

... but also for the much less reputable

4. As a low numbered type, it got sorted immediately after the apex
  SOA and NS records in a zone file normalised by "named-checkzone -D".

Well, it served me right when we later had to put an A record (sorts before
HINFO) at the apex of cam.ac.uk and I had to modify our normalised-zone-file-
comparsion program to allow for that! 


--
Chris Thompson
Email: c...@cam.ac.uk

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Thomas Schulz]

> Hi,
> 
> After reinitialising the inline-signing process (for example by
> removing the journal files or redeploying the master server) the
> freshly signed zone's serial number will usually be behind the
> authoritative version on the slaves causing transfers to fail 
> possibly leading to expired signatures, zone expiry, etc.

If you redeploy the master server, couldn't you just copy the journal
files over from the old server? And, the rest of the time, never remove
journal files.

> Currently, bumping the serial number of the unsigned zones to exceed
> that of the slaves is required, however it would be /convenient/ to
> have a one-shot method (perhaps via rndc) for specifying the signed
> zone serial number such that this doesn't require edits to the
> unsigned zone files.
> 
> This is especially useful in bootstrapping scenarios where the zone
> data is held under strict revision control or generated by some
> provisioning system that "owns" the serial number.
> 
> Am I on my own with this or would others find this useful?
> 
> 
> Thanks,
> 
> Terry

Tom Schulz
Applied Dynamics Intl.
sch...@adi.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Tony Finch]

Terry Burton  wrote:
>
> This is especially useful in bootstrapping scenarios where the zone
> data is held under strict revision control or generated by some
> provisioning system that "owns" the serial number.

Our provisioning system used to think it owned zone serial numbers, but
when we started signing we moved the version tag into an HINFO record.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Alan Clegg]

On 10/7/2014 7:39 PM, Terry Burton wrote:

Separate the data provider and DNS infrastructure provider and this
predicament ensues.


Ah, but here-in lies trouble.  You are becoming the data provider as 
soon as you do the signing on the data.  But I digress.


What about "rndc sign -force" that would cause a resigning (which is 
really what you are looking for) even if the data does not appear to the 
signing server to have changed.  That would maintain the integrity of 
the "source" data by not needing to change it at all and would also "do 
the right thing" with the serial number.


AlanC
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Terry Burton]

On 7 Oct 2014 22:35, "Alan Clegg"  wrote:
>
> On 10/7/2014 2:03 PM, Terry Burton wrote:
>>
>> On 7 Oct 2014 18:42, "Alan Clegg" > > wrote:
>>  >
>>  > On 10/7/2014 9:49 AM, Terry Burton wrote:
>>  > > This is especially useful in bootstrapping scenarios where the zone
>>  > > data is held under strict revision control or generated by some
>>  > > provisioning system that "owns" the serial number.
>>  >
>>  > By setting the number backwards, you are breaking all of your slave
>> servers and causing no-end of problems getting all of THEM corrected.
>>
>> You've misunderstood. I'm not attempting to decrease the serial number.
>>
>> With inline signing you have a hidden serial number in the unsigned zone
>> and an exposed serial number in the signed versions which your slaves
>> track. After redeployment (following DR, emergency relocation, elastic
>> capacity expansion, etc.) I want to be able to bump the exposed serial
>> number (once) back to an appropriate value without having to modify the
>> unsigned zones.
>
>
> Ok, I'm aware of the difference between unsigned and signed zones in an
in-line signing configuration and am more and more curious about your
terminology of "appropriate value" for the signed zones.

Currently advertised serial +1.

> If the data hasn't changed, the serial is appropriate.  If the data has
changed, the signed data serial number is going to be incremented the next
time you transfer (bump in the wire) or reload (on box) the data.

BIND on a reinitialised signing master doesn't know about the external
serial number until you tell it either by updating the unsigned zone data
(fine when you control this) or update the signing state by some other
method, as I propose.

> As Doug said, edit the data and when you reload it's going to "do the
right thing" but you should never get into this predicament to begin with
from my limited understanding of DNS.

Separate the data provider and DNS infrastructure provider and this
predicament ensues.

> Now, the problem with his added step is that the next time you edit the
file that you have in your version control system, the serial number is now
going to match (if you treat it as "just a number") the one that you edited
OUTSIDE OF THE PROCEDURE and you won't get correct zone transfers.
>
> I'd recommend adding one step to the DR/whatever procedure:  "bump serial
number in version control in to complete process".

That sounds ideal however in this case it's not possible to redefine access
to the VCS in this fashion due to the integrity constraints of the current
procedures.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Inline-signing feature request: Directly set the signed zone's serial number

[Stuart Browne]

> -Original Message-
> From: bind-users-boun...@lists.isc.org [mailto:bind-users-
> boun...@lists.isc.org] On Behalf Of Alan Clegg
> Sent: Wednesday, 8 October 2014 8:35 AM
> To: bind-users@lists.isc.org
> Subject: Re: Inline-signing feature request: Directly set the signed
> zone's serial number
> 

> 
> I'd recommend adding one step to the DR/whatever procedure:  "bump
> serial number in version control in to complete process".
> 
> AlanC

Alan and Doug, how would you do this if you didn't control the zone, i.e. it 
was an external or customer master?

Terry, I think this is a good feature suggestion.

Stuart
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Alan Clegg]

On 10/7/2014 2:03 PM, Terry Burton wrote:

On 7 Oct 2014 18:42, "Alan Clegg" mailto:a...@clegg.com>> wrote:
 >
 > On 10/7/2014 9:49 AM, Terry Burton wrote:
 > > This is especially useful in bootstrapping scenarios where the zone
 > > data is held under strict revision control or generated by some
 > > provisioning system that "owns" the serial number.
 >
 > By setting the number backwards, you are breaking all of your slave
servers and causing no-end of problems getting all of THEM corrected.

You've misunderstood. I'm not attempting to decrease the serial number.

With inline signing you have a hidden serial number in the unsigned zone
and an exposed serial number in the signed versions which your slaves
track. After redeployment (following DR, emergency relocation, elastic
capacity expansion, etc.) I want to be able to bump the exposed serial
number (once) back to an appropriate value without having to modify the
unsigned zones.


Ok, I'm aware of the difference between unsigned and signed zones in an 
in-line signing configuration and am more and more curious about your 
terminology of "appropriate value" for the signed zones.


If the data hasn't changed, the serial is appropriate.  If the data has 
changed, the signed data serial number is going to be incremented the 
next time you transfer (bump in the wire) or reload (on box) the data.


As Doug said, edit the data and when you reload it's going to "do the 
right thing" but you should never get into this predicament to begin 
with from my limited understanding of DNS.


Now, the problem with his added step is that the next time you edit the 
file that you have in your version control system, the serial number is 
now going to match (if you treat it as "just a number") the one that you 
edited OUTSIDE OF THE PROCEDURE and you won't get correct zone transfers.


I'd recommend adding one step to the DR/whatever procedure:  "bump 
serial number in version control in to complete process".


AlanC
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Terry Burton]

On 7 Oct 2014 21:44, "Doug Barton"  wrote:
>
> On 10/7/14 11:03 AM, Terry Burton wrote:
>
>> With inline signing you have a hidden serial number in the unsigned zone
>> and an exposed serial number in the signed versions which your slaves
>> track. After redeployment (following DR, emergency relocation, elastic
>> capacity expansion, etc.) I want to be able to bump the exposed serial
>> number (once) back to an appropriate value without having to modify the
>> unsigned zones.
>>
>> (For context, the unsigned zone serial number matches the revision
>> number in a VCS to which the DNS infrastructure hosts and administrators
>> have read-only access, i.e. mandatory separation of infrastructure and
>> data access rights.)
>
>
> * Check out the unmodified version of the unsigned zone
> * Increase the serial number in the checked out copy to be past the one
in the signed zone
> * rndc reload
> * Delete the modified version of the zone file, and revert to the master
copy
>
> ... all of which is not to say that your request is not reasonable, just
letting you know that a solution exists.

Sure, this is the approach that is currently taken. As stressed in my
request, this is purely for convenience... and a little bit of obsessive
data purity - load what you're given without additional processing, etc.

Thanks all the same!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Doug Barton]

On 10/7/14 11:03 AM, Terry Burton wrote:


With inline signing you have a hidden serial number in the unsigned zone
and an exposed serial number in the signed versions which your slaves
track. After redeployment (following DR, emergency relocation, elastic
capacity expansion, etc.) I want to be able to bump the exposed serial
number (once) back to an appropriate value without having to modify the
unsigned zones.

(For context, the unsigned zone serial number matches the revision
number in a VCS to which the DNS infrastructure hosts and administrators
have read-only access, i.e. mandatory separation of infrastructure and
data access rights.)


* Check out the unmodified version of the unsigned zone
* Increase the serial number in the checked out copy to be past the one 
in the signed zone

* rndc reload
* Delete the modified version of the zone file, and revert to the master 
copy


... all of which is not to say that your request is not reasonable, just 
letting you know that a solution exists.


hope this helps,

Doug


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Terry Burton]

On 7 Oct 2014 18:42, "Alan Clegg"  wrote:
>
> On 10/7/2014 9:49 AM, Terry Burton wrote:
> > This is especially useful in bootstrapping scenarios where the zone
> > data is held under strict revision control or generated by some
> > provisioning system that "owns" the serial number.
>
> By setting the number backwards, you are breaking all of your slave
servers and causing no-end of problems getting all of THEM corrected.

You've misunderstood. I'm not attempting to decrease the serial number.

With inline signing you have a hidden serial number in the unsigned zone
and an exposed serial number in the signed versions which your slaves
track. After redeployment (following DR, emergency relocation, elastic
capacity expansion, etc.) I want to be able to bump the exposed serial
number (once) back to an appropriate value without having to modify the
unsigned zones.

(For context, the unsigned zone serial number matches the revision number
in a VCS to which the DNS infrastructure hosts and administrators have
read-only access, i.e. mandatory separation of infrastructure and data
access rights.)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline-signing feature request: Directly set the signed zone's serial number

[Alan Clegg]

On 10/7/2014 9:49 AM, Terry Burton wrote:
> This is especially useful in bootstrapping scenarios where the zone
> data is held under strict revision control or generated by some
> provisioning system that "owns" the serial number.

By setting the number backwards, you are breaking all of your slave 
servers and causing no-end of problems getting all of THEM corrected.


Seems better to set the number correctly (as in "higher than the number 
that was being used in the signed zones before the change") in your 
version/provisioning system.


AlanC

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users