Re: update-policy wildcard grant
> On 2 Apr 2020, at 11:59, Jim Popovitch via bind-users
> wrote:
>
> On Thu, 2020-04-02 at 09:27 +1100, Mark Andrews wrote:
>>> On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users <
>>> bind-users@lists.isc.org> wrote:
>>>
>>> Hello!
>>>
>>> I started on #bind, moved on to the ARM, and now I am here.
>>>
>>> Here is what I want:
>>>
>>> update-policy {grant webserver-tsig-key wildcard _acme-challenge.*
>>> TXT;};
>>>
>>> This is what I get:
>>>
>>> ~$ named-checkconf
>>> /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
>>>
>>> What am I doing wrong?
>>
>> Presumably the webserver is locked done enough that you can just let
>> the TSIG update TXT anywhere.
>
> Do you mean like kb.isc.org ? :-)
>
> Honestly, no webserver, worth it's salt in 2020, is ever locked down
> well enough, imho.
The tool updating the acme challenges and certificates can definitely
be locked down enough.
You could use SIG(0) rather than TSIG to authenticate the updates and store KEY
records in the DNS for each site. That is much easier to manage than TSIG’s for
each site and doesn’t require updating named.conf once it is setup with TSIG
only
being used to add the KEY records as each site is establised.
grant * self . TXT;
>> If you really need to apply tighter rules then use ‘external’ and
>> implement the check outside of named.
>
> Thanks for that, it looks exactly like what I need/want.
>
> -Jim P.
>
>
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: update-policy wildcard grant
On Thu, 2020-04-02 at 09:27 +1100, Mark Andrews wrote:
> > On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users <
> > bind-users@lists.isc.org> wrote:
> >
> > Hello!
> >
> > I started on #bind, moved on to the ARM, and now I am here.
> >
> > Here is what I want:
> >
> > update-policy {grant webserver-tsig-key wildcard _acme-challenge.*
> > TXT;};
> >
> > This is what I get:
> >
> > ~$ named-checkconf
> > /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
> >
> > What am I doing wrong?
>
> Presumably the webserver is locked done enough that you can just let
> the TSIG update TXT anywhere.
Do you mean like kb.isc.org ? :-)
Honestly, no webserver, worth it's salt in 2020, is ever locked down
well enough, imho.
> If you really need to apply tighter rules then use ‘external’ and
> implement the check outside of named.
Thanks for that, it looks exactly like what I need/want.
-Jim P.
___
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: update-policy wildcard grant
> On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users
> wrote:
>
> Hello!
>
> I started on #bind, moved on to the ARM, and now I am here.
>
> Here is what I want:
>
> update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
>
> This is what I get:
>
> ~$ named-checkconf
> /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
>
> What am I doing wrong?
Presumably the webserver is locked done enough that you can just let the TSIG
update TXT anywhere.
If you really need to apply tighter rules then use ‘external’ and implement the
check outside of named.
This is documented in the BIND 9 Administrators Reference Manual.
external
This rule allows named to defer the decision of whether to allow a given update
to an external daemon.
The method of communicating with the daemon is specified in the identity field,
the format of which is "local:path", where path is the location of a
UNIX-domain socket. (Currently, "local" is the only supported mechanism.)
Requests to the external daemon are sent over the UNIX-domain socket as
datagrams with the following format:
Protocol version number (4 bytes, network byte order, currently 1)
Request length (4 bytes, network byte order)
Signer (null-terminated string)
Name (null-terminated string)
TCP source address (null-terminated string)
Rdata type (null-terminated string)
Key (null-terminated string)
TKEY token length (4 bytes, network byte order )
TKEY token (remainder of packet)
The daemon replies with a four-byte value in network byte order, containing
either 0 or 1; 0 indicates that the specified update is not permitted, and 1
indicates that it is.
Mark
> tia!
>
> -Jim P.
>
>
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: update-policy wildcard grant
Jim Popovitch via bind-users wrote:
>
>update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
Sadly in the DNS a wildcard * can only occur as the leftmost label in a name.
RFC 4592 has more than you ever wanted to know about DNS wildcards. It's
not pretty.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
The Minch: Northwesterly 6 to gale 8, occasionally severe gale 9 at first in
north, decreasing 4 to 6 later. Slight or moderate, occasionally rough in
north. Squally wintry showers. Good, occasionally poor.
___
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: Localhost view is not working for me SOLVED!
Thanks Bob, while your suggestions didn't help directly they did put me
on a path that eventually lead to the solution. Turns out I had an ill
defined SOA record along with a ill defined NS record (copy/paste error)
that was the problem in my localhost zone. I think I am once again a
happy camper.
Marc..
On 3/30/20 11:42 AM, Bob Harold wrote:
> Try without the "match-destinations". Only use match-clients to
> determine the view. (Or try only match-destinations as a separate test.)
> (I have never used match-destinations.)
> Turn on query logging and see what source and destination your queries
> are using. Make fake queries to unique names just to be sure which
> queries you are looking at.
> That's the best that I can suggest.
>
> --
> Bob Harold
>
>
> On Mon, Mar 30, 2020 at 1:07 PM Marc Chamberlin via bind-users
> mailto:bind-users@lists.isc.org>> wrote:
>
> Hello - I am running the Bind server
>
> > named -v
> BIND 9.11.2
>
> under OpenSuSE Leap 15.0. In order to support other servers
> running on the same system that my Bind server is running on I am
> trying to set up 3 views, one for the localhost, one for my
> internal network to use, and one for the external Internet. (yes
> this is also a gateway system with 2 NIC cards.) What I am having
> troubles with is getting the localhost view to work properly. I
> have tried a number of ways to get this to work and will show the
> apropos segment of my named.conf file below. Commented out
> sections show things I have tried already but rejected because the
> results I get from queries, from other servers on this
> gateway/localhost system, that are not what I want. For example
> if I use the definition in with localhost is defined, rather than
> 127.0.0.1, I will get results that are defined by my internal view
> which is not acceptable. If I use 127.0.0.1 instead, lookup query
> results from/for the other servers running on my gateway/localhost
> fail completely with no results returned. I don't understand why
> 127.0.0.1 fails, it seems like this should be the proper way to
> limit the scope of localhost queries so that they are answered by
> definitions defined in my "localhost_resolver" view. What am I
> missing? How to I set up the "localhost_resolver" view so that it
> will answer queries from localhost without falling through to my
> "internal" view? (The keys are also necessary to restrict
> certain types of queries but I tried not using them and got the
> same inadequate responses to queries from the localhost.)
>
> I have also used dig to show exactly what view was answering
> queries from localhost and it verified that the queries were
> indeed being answered by my internal view when I used localhost in
> the match-clients and match-destinations statements. If necessary
> I can post other files, such as the local_zones.conf or some of
> the domain definition files themselves but will have to edit them
> to remove actual URLs and other sensitive information. I checked
> the log files also, after setting the debug level to 10, and the
> Bind server reports no errors or warnings when it is started up.
> Thanks for any help offered, and below is what I think is the
> relevant part of my named.conf file.
>
> Marc
>
>> view "localhost_resolver"
>> {
>> // match-clients { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>> // match-destinations { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>>
>> match-clients { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };
>> match-destinations { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };
>>
>> // match-clients { 127.0.0.1; };
>> // match-destinations { 127.0.0.1; };
>>
>> recursion yes;
>> zone "." in {
>> type hint;
>> file "root.hint";
>> };
>> zone "localhost" in {
>> type master;
>> file "localhost.zone";
>> allow-update { none; };
>> };
>> zone "0.0.127.in-addr.arpa" in {
>> type master;
>> file "127.0.0.zone";
>> allow-update { none; };
>> };
>> zone
>> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
>> in {
>> type master;
>> file "127.0.0.zone";
>> };
>> include "/etc/named.d/local/local_zones.conf";
>> };
>>
>> view "internal" { // What the home network will see
>> // match-clients { ! key letsencrypt.; ! key rndc-key.;
>> ! key
update-policy wildcard grant
Hello!
I started on #bind, moved on to the ARM, and now I am here.
Here is what I want:
update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
This is what I get:
~$ named-checkconf
/etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
What am I doing wrong?
tia!
-Jim P.
___
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: Machine friendly alternative to nsupdate
Shumon Huque wrote: > > The implication is that "ignore" also means set the response code to > NOERROR. Although, I suppose CNAME related UPDATE processing could have > been special cased to return an error code like YXRRSET (even without a > specified prerequisite clause). Ah, yes, now you mention it I have remembered the relevant bit of how UPDATE is designed: the idea is that update processing can't cause an error response (except for internal server failures unrelated to the contents of the zone or the update message); all errors come from processing prerequisites, permissions, and the update prescan phase. So if you want errors from an UPDATE you have to ask for them in the prerequisites. Tony. -- f.anthony.n.finchhttp://dotat.at/ Selsey Bill to Lyme Regis: Variable 3 or less, becoming west or north west 3 or 4. Smooth or slight. Showers. 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: Machine friendly alternative to nsupdate
I recently tried using dnspython to replay captured queries and found that it refuses to do any "meta" queries, including "ANY". But since the real world occasionally uses meta queries, I need to be able to make them. I ended up using https://github.com/paulc/dnslib, but I don't see where that handles updates. -- Bob Harold On Wed, Apr 1, 2020 at 9:39 AM Ondřej Surý wrote: > I would recommend dnspython as a start. The API is very non-Python, > but once you get hang of it, it’s not that bad. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > On 1 Apr 2020, at 15:21, Petr Bena wrote: > > > > like a "proper DNS library" you talk about, is there any such a thing? > > ___ > 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: Machine friendly alternative to nsupdate
On Wed, Apr 1, 2020 at 8:36 AM Tony Finch wrote: > > This error behaviour is mostly specified by the UPDATE protocol (RFC > 2136). It's worth reading the RFC becasue (as you have found) some of the > behaviour is a bit surprising. For instance, adding a record that already > exists is not an error because multiple copies of the same record > traditionally get silently de-duplicated in the DNS. (I can't explain the > lack of error in the CNAME case...) > This was a bit unexpected for me too, until I saw that RFC2136 does explicitly cover the CNAME case. From Section 3.4.2.2 (the "vice versa" covers the original poster's case): "In the case of a CNAME Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME Update RR, otherwise replace the CNAME Zone RR with the CNAME Update RR." The implication is that "ignore" also means set the response code to NOERROR. Although, I suppose CNAME related UPDATE processing could have been special cased to return an error code like YXRRSET (even without a specified prerequisite clause). Shumon. ___ 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: Machine friendly alternative to nsupdate
Petr Bena wrote: > > The problem with this approach is that it's not atomic. That's the point of the prerequisite section! You can package up the atomicity checks and updates into one request. You will have to deal with concurrent update clashes in some way, but that's true for any system that has serializable updates. (DNS updates are one-at-a-time serialized, not concurrent and serializable, but concurrency hazards have the same high-level effect in both cases.) For an example / discussion from elsewhere ... https://www.postgresql.org/docs/current/transaction-iso.html#XACT-SERIALIZABLE Whether it's DNS or SQL, concurrency hazards aren't just about the storage or the protocol: they are also about the user interface. If your user prepares and submits an update based on old data, that clashes with a concurrent update, you need to show them that things have changed under their feet so that they know something weird is happening. There are cases where you might be able to retry automatically without causing confusion, but it needs some thought. To get atomicity, use the UPDATE prerequisites section to ensure that the zone actually matches what your user interface was showing the user before the user prepared the update. > I am looking for a some alternative to nsupdate, that can achieve the > same, but more machine friendly, like a "proper DNS library" you talk > about, is there any such a thing? The system I work with is mostly perl, so I use Net::DNS which is generally very good. Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Westerly to northwesterly, 4 to 6, occasionally 7 in north. Slight or moderate, occasionally rough later near Mull of Kintyre. Rain or showers. Good, occasionally moderate. ___ 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: Machine friendly alternative to nsupdate
Hi there, On Wed, 1 Apr 2020, Petr Bena wrote: ... Is there any alternative to nsupdate, something that can work with XML or JSON payloads or provide output in such machine parseable format? ... If it's any help DNS::ZoneParse claims to be able to output XML - but I don't have any experience of it. The last changelog entry is dated Sep 22 2010, which you might consider a good thing, or you might not. -- 73, Ged. ___ 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: Machine friendly alternative to nsupdate
These projects tend to be custom... there may be a prepackaged solution, but everything I've run into has either been tied to the specific abstractions of a project - or very low level. Mine uses the Perl Net::DNS module to setup update transactions. Net::DNS gives you the ability to send update, use TSIG, get all the response fields conveniently, and get display text. It's pretty well supported - and the basis for a number of DNS tools and tests. When first approached, it can be, er, less than obvious exactly how to make UDPATE work. If you get stuck, I can probably extract the code to do (TSIG-signed) updates. As for the next layer - XML or whatever - that's another project. If you speak Perl, it would not be difficult to wrap Net::DNS to meet your needs. P.S. Other than using it (and reporting the occasional bug), I have no relationship with Net::DNS :-) Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 01-Apr-20 05:07, Petr Bena wrote: > Hello, > > Some preamble: Some time ago I created an open source DNS admin web > GUI *1 that is basically a wrapper around dig and nsupdate that allows > people with "less CLI knowledge" to easily manipulate DNS records. The > main reason for this was that in our corporation we have about 400 > internal DNS zones hosted on over 100 different BIND master servers, > in more than 10 countries around the planet and this tool allowed us > to unify the management as it allowed integration with different > master servers, allow granular role based access for individual zones > (integrated with LDAP groups), including some web API for our > automation tools etc. > > Now to the actual problem: as I said, this tool is just a wrapper > around nsupdate and dig, I like it that way because it's non-invasive, > unlike other similar DNS admin panels, it doesn't require ANY changes > on DNS server configuration and it integrates well with other > solutions already in place. The problem I have however, is, that > nsupdate was created as a tool for humans, rather than machines and > parsing its output and even giving it input is very hard. Plus some > things don't even seem to be possible in it. > > Is there any alternative to nsupdate, something that can work with XML > or JSON payloads or provide output in such machine parseable format? > For example, typical problem I am facing right now - is that nsupdate > silently ignores things that IMHO shouldn't be ignored - for example > when someone try to add a record that already exists, or try to add an > A record over CNAME, nsupdate silently ignores this, even in debug > output I can't see any difference, in first send the record is > created, resulting in NOERROR, in second identical send, update is > ignored resulting in NOERROR, so I have no way to tell users of my app > that record was not in fact created or changed (because it already > exists). For example: > > Here is operation where I first add a CNAME record and then try to add > same A record (imagine two different users were doing this so user B > was unaware that CNAME already exists) you can see in both cases > nsupdate respond with same answer, despite record is created only in > first case. And on top of that this answer is not easy to machine parse. > > > debug > > update add petrbena.test.zone. 600 CNAME this.is.test. > > send > Sending update to 10.15.12.17#53 > Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433 > ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 > ;; ZONE SECTION: > ;test.zone. IN SOA > > ;; UPDATE SECTION: > petrbena.test.zone. 600 IN CNAME this.is.test. > > ;; TSIG PSEUDOSECTION: > server. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1585729680 300 > 16 xx== 48433 NOERROR 0 > > > Reply from update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433 > ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 > ;; ZONE SECTION: > ;test.zone. IN SOA > > ;; TSIG PSEUDOSECTION: > server. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1585729680 300 > 16 xx== 48433 NOERROR 0 > > > update add petrbena.test.zone. 600 A 0.0.0.0 > > send > Sending update to 10.15.12.17#53 > Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 30709 > ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 > ;; ZONE SECTION: > ;test.zone. IN SOA > > ;; UPDATE SECTION: > petrbena.test.zone. 600 IN A 0.0.0.0 > > ;; TSIG PSEUDOSECTION: > > server. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1585729721 300 > 16 xx== 30709 NOERROR 0 > > > Is there any alternative to nsupdate that can do this? Or some newer > version of nsupdate that can acomplish this? > > Thanks > > > *1 https://github.com/benapetr/dnsphpadmin > > signature.asc Description: OpenPGP digital signature
Re: Machine friendly alternative to nsupdate
I would recommend dnspython as a start. The API is very non-Python, but once you get hang of it, it’s not that bad. Ondrej -- Ondřej Surý ond...@isc.org > On 1 Apr 2020, at 15:21, Petr Bena wrote: > > like a "proper DNS library" you talk about, is there any such a thing? signature.asc Description: Message signed with OpenPGP ___ 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: Machine friendly alternative to nsupdate
Hello, The problem with this approach is that it's not atomic. I can run a query to check if record exists before it's created, but there are two problems: * It adds an overhead (one more call of dig to lookup current situation) * It's not reliable - because it's not atomic So I was hoping this can be achieved with the nsupdate, I guess the prereq statement is what I need to work with, but as I said - parsing the current output of nsupdate, especially that header from debug or answer section, is just not very easy, and I wouldn't be surprised if the format of output changed in future versions (that would break my parser), so that's why I am looking for a some alternative to nsupdate, that can achieve the same, but more machine friendly, like a "proper DNS library" you talk about, is there any such a thing? On 01/04/2020 14:35, Tony Finch wrote: Petr Bena wrote: I think your approach of using standard protocols (DNS queries and updages) to edit zones is very good! Is there any alternative to nsupdate, something that can work with XML or JSON payloads or provide output in such machine parseable format? I've done a lot with wrapping dig and nsupdate, and it works quite well, but I find that when I start getting into parsing swamps (anything more complicated than one line per record, or caring about response codes) it's better to use a proper DNS library, which should include support for UPDATE requests as well as queries. For example, typical problem I am facing right now - is that nsupdate silently ignores things that IMHO shouldn't be ignored - for example when someone try to add a record that already exists, or try to add an A record over CNAME, nsupdate silently ignores this, This error behaviour is mostly specified by the UPDATE protocol (RFC 2136). It's worth reading the RFC becasue (as you have found) some of the behaviour is a bit surprising. For instance, adding a record that already exists is not an error because multiple copies of the same record traditionally get silently de-duplicated in the DNS. (I can't explain the lack of error in the CNAME case...) You might find that a more complicated update strategy gives you better error detection, using UPDATE's prerequisite feature. Something roughly like, * Query the current state of the name you want to edit. In most cases you care about the type being edited and whether or not there's a CNAME involved. You may already have this information for display in your user interface! * In your update request, assert in the prerequisite section that the state of the zone matches what you expect, to detect problems with concurrent updates; * In the update section, you'll have to explicitly delete existing records and add new ones if a CNAME is involved. If you have all the records of all the types at a name in hand, a simple strategy might be to delete everything at the name and add all the records that you think should be there. In nsdiff (https://dotat.at/prog/nsdiff/) I'm doing whole-zone updates which makes things slightly simpler. I know I have all the records at a name so I can handle CNAMEs fairly straightforwardly, and I can just use the SOA serial number (a SOA record in the prerequisite section) to detect concurrent updates. But it gets slow and eats memory with big zones! Tony. ___ 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: Machine friendly alternative to nsupdate
> On 1 Apr 2020, at 20:07, Petr Bena wrote: > > Hello, > > Some preamble: Some time ago I created an open source DNS admin web GUI *1 > that is basically a wrapper around dig and nsupdate that allows people with > "less CLI knowledge" to easily manipulate DNS records. The main reason for > this was that in our corporation we have about 400 internal DNS zones hosted > on over 100 different BIND master servers, in more than 10 countries around > the planet and this tool allowed us to unify the management as it allowed > integration with different master servers, allow granular role based access > for individual zones (integrated with LDAP groups), including some web API > for our automation tools etc. > > Now to the actual problem: as I said, this tool is just a wrapper around > nsupdate and dig, I like it that way because it's non-invasive, unlike other > similar DNS admin panels, it doesn't require ANY changes on DNS server > configuration and it integrates well with other solutions already in place. > The problem I have however, is, that nsupdate was created as a tool for > humans, rather than machines and parsing its output and even giving it input > is very hard. Plus some things don't even seem to be possible in it. > > Is there any alternative to nsupdate, something that can work with XML or > JSON payloads or provide output in such machine parseable format? For > example, typical problem I am facing right now - is that nsupdate silently > ignores things that IMHO shouldn't be ignored - for example when someone try > to add a record that already exists, or try to add an A record over CNAME, > nsupdate silently ignores this, even in debug output I can't see any > difference, in first send the record is created, resulting in NOERROR, in > second identical send, update is ignored resulting in NOERROR, so I have no > way to tell users of my app that record was not in fact created or changed > (because it already exists). For example: Add a prerequisite that a CNAME RRset does not exist at the name and the nameserver will return the appropriate error code it if does (YXRRSET). nxrrset petrbena.test.zone CNAME add petrbena.test.zone. 600 A 0.0.0.0 If you want to add a CNAME regardless of what is already there then you need to clear the existing records as CNAME and other data can’t co-exist, the exceptions are KEY, NSEC and RRSIG records and if you care about them then you need to do the more complicate update based on the SOA’s value. del petrbena.test.zone. add petrbena.test.zone. 600 CNAME this.is.test. For more complicated conditionals you use the SOA record and do a value dependent prerequisite that it hasn’t changed since you have determined the state of the zone. Request the SOA, request the state of the names you care about, request the SOA and if it hasn’t changed compute the update request with the SOA record as a prerequisite. If the SOA changes you start the process over. NXRRSET would be the error code from the UPDATE request if the SOA doesn’t match. yxrrset example.com 0 IN SOA … changes here > Here is operation where I first add a CNAME record and then try to add same A > record (imagine two different users were doing this so user B was unaware > that CNAME already exists) you can see in both cases nsupdate respond with > same answer, despite record is created only in first case. And on top of that > this answer is not easy to machine parse. > > > debug > > update add petrbena.test.zone. 600 CNAME this.is.test. > > send > Sending update to 10.15.12.17#53 > Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433 > ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 > ;; ZONE SECTION: > ;test.zone.INSOA > > ;; UPDATE SECTION: > petrbena.test.zone.600INCNAMEthis.is.test. > > ;; TSIG PSEUDOSECTION: > server. 0ANYTSIGhmac-md5.sig-alg.reg.int. 1585729680 300 16 xx== > 48433 NOERROR 0 > > > Reply from update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433 > ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 > ;; ZONE SECTION: > ;test.zone.INSOA > > ;; TSIG PSEUDOSECTION: > server. 0ANYTSIGhmac-md5.sig-alg.reg.int. 1585729680 300 16 xx== > 48433 NOERROR 0 > > > update add petrbena.test.zone. 600 A 0.0.0.0 > > send > Sending update to 10.15.12.17#53 > Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 30709 > ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 > ;; ZONE SECTION: > ;test.zone.INSOA > > ;; UPDATE SECTION: > petrbena.test.zone.600INA0.0.0.0 > > ;; TSIG PSEUDOSECTION: > > server. 0ANYTSIGhmac-md5.sig-alg.reg.int. 1585729721 300 16 xx== > 30709 NOERROR 0 > > > Is there any alternative to nsupdate that can do this? Or some newer version > of nsupdate that can acomplish this? > > Thanks > > > *1
Re: Machine friendly alternative to nsupdate
Petr Bena wrote: > I think your approach of using standard protocols (DNS queries and updages) to edit zones is very good! > Is there any alternative to nsupdate, something that can work with XML > or JSON payloads or provide output in such machine parseable format? I've done a lot with wrapping dig and nsupdate, and it works quite well, but I find that when I start getting into parsing swamps (anything more complicated than one line per record, or caring about response codes) it's better to use a proper DNS library, which should include support for UPDATE requests as well as queries. > For example, typical problem I am facing right now - is that nsupdate > silently ignores things that IMHO shouldn't be ignored - for example > when someone try to add a record that already exists, or try to add an A > record over CNAME, nsupdate silently ignores this, This error behaviour is mostly specified by the UPDATE protocol (RFC 2136). It's worth reading the RFC becasue (as you have found) some of the behaviour is a bit surprising. For instance, adding a record that already exists is not an error because multiple copies of the same record traditionally get silently de-duplicated in the DNS. (I can't explain the lack of error in the CNAME case...) You might find that a more complicated update strategy gives you better error detection, using UPDATE's prerequisite feature. Something roughly like, * Query the current state of the name you want to edit. In most cases you care about the type being edited and whether or not there's a CNAME involved. You may already have this information for display in your user interface! * In your update request, assert in the prerequisite section that the state of the zone matches what you expect, to detect problems with concurrent updates; * In the update section, you'll have to explicitly delete existing records and add new ones if a CNAME is involved. If you have all the records of all the types at a name in hand, a simple strategy might be to delete everything at the name and add all the records that you think should be there. In nsdiff (https://dotat.at/prog/nsdiff/) I'm doing whole-zone updates which makes things slightly simpler. I know I have all the records at a name so I can handle CNAMEs fairly straightforwardly, and I can just use the SOA serial number (a SOA record in the prerequisite section) to detect concurrent updates. But it gets slow and eats memory with big zones! Tony. -- f.anthony.n.finchhttps://dotat.at/ Viking: West or northwest 6 or 7, increasing gale 8 or severe gale 9 later, perhaps storm 10. Rough or very rough, becoming high later. Thundery wintry showers. Good, occasionally poor. ___ 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
Machine friendly alternative to nsupdate
Hello, Some preamble: Some time ago I created an open source DNS admin web GUI *1 that is basically a wrapper around dig and nsupdate that allows people with "less CLI knowledge" to easily manipulate DNS records. The main reason for this was that in our corporation we have about 400 internal DNS zones hosted on over 100 different BIND master servers, in more than 10 countries around the planet and this tool allowed us to unify the management as it allowed integration with different master servers, allow granular role based access for individual zones (integrated with LDAP groups), including some web API for our automation tools etc. Now to the actual problem: as I said, this tool is just a wrapper around nsupdate and dig, I like it that way because it's non-invasive, unlike other similar DNS admin panels, it doesn't require ANY changes on DNS server configuration and it integrates well with other solutions already in place. The problem I have however, is, that nsupdate was created as a tool for humans, rather than machines and parsing its output and even giving it input is very hard. Plus some things don't even seem to be possible in it. Is there any alternative to nsupdate, something that can work with XML or JSON payloads or provide output in such machine parseable format? For example, typical problem I am facing right now - is that nsupdate silently ignores things that IMHO shouldn't be ignored - for example when someone try to add a record that already exists, or try to add an A record over CNAME, nsupdate silently ignores this, even in debug output I can't see any difference, in first send the record is created, resulting in NOERROR, in second identical send, update is ignored resulting in NOERROR, so I have no way to tell users of my app that record was not in fact created or changed (because it already exists). For example: Here is operation where I first add a CNAME record and then try to add same A record (imagine two different users were doing this so user B was unaware that CNAME already exists) you can see in both cases nsupdate respond with same answer, despite record is created only in first case. And on top of that this answer is not easy to machine parse. > debug > update add petrbena.test.zone. 600 CNAME this.is.test. > send Sending update to 10.15.12.17#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;test.zone. IN SOA ;; UPDATE SECTION: petrbena.test.zone. 600 IN CNAME this.is.test. ;; TSIG PSEUDOSECTION: server. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1585729680 300 16 xx== 48433 NOERROR 0 Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433 ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;test.zone. IN SOA ;; TSIG PSEUDOSECTION: server. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1585729680 300 16 xx== 48433 NOERROR 0 > update add petrbena.test.zone. 600 A 0.0.0.0 > send Sending update to 10.15.12.17#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 30709 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;test.zone. IN SOA ;; UPDATE SECTION: petrbena.test.zone. 600 IN A 0.0.0.0 ;; TSIG PSEUDOSECTION: server. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1585729721 300 16 xx== 30709 NOERROR 0 Is there any alternative to nsupdate that can do this? Or some newer version of nsupdate that can acomplish this? Thanks *1 https://github.com/benapetr/dnsphpadmin ___ 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
