rev delegation robot and selection of NS to pull zone from
Another question regarding v6 reverse delegation, but possibly also applicable to v4 reverse... One of our customers has a somewhat complex DNS setup which makes us face the situation that in the SOA record the name of the NS where the zone originates is not in the set of responses to NS queries. While this is not the common case, I presume, it seems to NOT be "illegal". The domain has to on-site name servers and is configured to have a slave at the NCC. For this zone we received an alert that the ZXFR has failed from the machine with the name given in the SOA. That box will never be serving external zone transfer requests. So - this may just be a glitch in the alerting script, but I am still left with the question: how does the robot at the NCC's end determine the "appropriate" host to try zone transfers from? Any recommendations? Thanks, Wilfreid.
Wilfried, Some call it "hidden master", others call it "hidden primary" and others call it "stealth master"... This URL may help and I'm sure there is much more thorough source of documentation: http://www.dns.net/dnsrd/servers/ (just look up "hidden master" in the web page...) You may also visit this page: https://www.isc.org/software/bind/documentation/arm95 I think as for the XFR config, amha, the slave run by NCC should be configured to feed from the other NS listed (and run on-site). Hope that helps, Mohsen. On 20 Nov, Wilfried Woeber, UniVie/ACOnet wrote: | Another question regarding v6 reverse delegation, but possibly also | applicable to v4 reverse... | | One of our customers has a somewhat complex DNS setup which makes us | face the situation that in the SOA record the name of the NS where | the zone originates is not in the set of responses to NS queries. | | While this is not the common case, I presume, it seems to NOT be "illegal". | | The domain has to on-site name servers and is configured to have a slave | at the NCC. | | For this zone we received an alert that the ZXFR has failed from the | machine with the name given in the SOA. That box will never be serving | external zone transfer requests. | | So - this may just be a glitch in the alerting script, but I am still | left with the question: how does the robot at the NCC's end determine | the "appropriate" host to try zone transfers from? | | Any recommendations? | | Thanks, | Wilfreid.
A new term, without the baggage of "hidden" or "stealth" is "distribution master". -Barb On 11/20/08 10:44 AM, "Mohsen Souissi" <mohsen.souissi@nic.fr> wrote: Wilfried, Some call it "hidden master", others call it "hidden primary" and others call it "stealth master"... This URL may help and I'm sure there is much more thorough source of documentation: http://www.dns.net/dnsrd/servers/ (just look up "hidden master" in the web page...) You may also visit this page: https://www.isc.org/software/bind/documentation/arm95 I think as for the XFR config, amha, the slave run by NCC should be configured to feed from the other NS listed (and run on-site). Hope that helps, Mohsen. On 20 Nov, Wilfried Woeber, UniVie/ACOnet wrote: | Another question regarding v6 reverse delegation, but possibly also | applicable to v4 reverse... | | One of our customers has a somewhat complex DNS setup which makes us | face the situation that in the SOA record the name of the NS where | the zone originates is not in the set of responses to NS queries. | | While this is not the common case, I presume, it seems to NOT be "illegal". | | The domain has to on-site name servers and is configured to have a slave | at the NCC. | | For this zone we received an alert that the ZXFR has failed from the | machine with the name given in the SOA. That box will never be serving | external zone transfer requests. | | So - this may just be a glitch in the alerting script, but I am still | left with the question: how does the robot at the NCC's end determine | the "appropriate" host to try zone transfers from? | | Any recommendations? | | Thanks, | Wilfreid.
On Thu, Nov 20, 2008 at 10:48:25AM -0800, Barbara Roseman wrote:
A new term, without the baggage of "hidden" or "stealth" is "distribution master".
while this is helpful to avoid layer 9 issues, associating 'stealth' with certainly colored helicopters and such, it doesn't make obvious the fact that the server is not listed in the NS RRSet. In theory the MNAME should be the root of the XFR dependency graph, not necessarily accessible from the outside. -Peter
the root ops folks have used that term for nearly a decade... its much cleaner/nicer than the baggage of other, more highly charged words. --bill On Thu, Nov 20, 2008 at 10:48:25AM -0800, Barbara Roseman wrote:
A new term, without the baggage of "hidden" or "stealth" is "distribution master".
-Barb
On 11/20/08 10:44 AM, "Mohsen Souissi" <mohsen.souissi@nic.fr> wrote:
Wilfried,
Some call it "hidden master", others call it "hidden primary" and others call it "stealth master"...
This URL may help and I'm sure there is much more thorough source of documentation: http://www.dns.net/dnsrd/servers/
(just look up "hidden master" in the web page...)
You may also visit this page: https://www.isc.org/software/bind/documentation/arm95
I think as for the XFR config, amha, the slave run by NCC should be configured to feed from the other NS listed (and run on-site).
Hope that helps,
Mohsen.
On 20 Nov, Wilfried Woeber, UniVie/ACOnet wrote: | Another question regarding v6 reverse delegation, but possibly also | applicable to v4 reverse... | | One of our customers has a somewhat complex DNS setup which makes us | face the situation that in the SOA record the name of the NS where | the zone originates is not in the set of responses to NS queries. | | While this is not the common case, I presume, it seems to NOT be "illegal". | | The domain has to on-site name servers and is configured to have a slave | at the NCC. | | For this zone we received an alert that the ZXFR has failed from the | machine with the name given in the SOA. That box will never be serving | external zone transfer requests. | | So - this may just be a glitch in the alerting script, but I am still | left with the question: how does the robot at the NCC's end determine | the "appropriate" host to try zone transfers from? | | Any recommendations? | | Thanks, | Wilfreid.
the root ops folks have used that term for nearly a decade... its much cleaner/nicer than the baggage of other, more highly charged words. So if we really can get rid of "master" and "slave", we get a political correct dns :-). jaap
On Fri, Nov 21, 2008 at 05:54:18AM +0100, Jaap Akkerhuis wrote:
the root ops folks have used that term for nearly a decade... its much cleaner/nicer than the baggage of other, more highly charged words.
So if we really can get rid of "master" and "slave", we get a political correct dns :-).
we did get rid of "master" and "slave" - using "primary" and "secondary". In the legal jurisdiction where I live, it is illegal to use the terms master/slave for DNS purposes.... YMMV. --bill
On 20/11/08 15:02, Wilfried Woeber, UniVie/ACOnet wrote: Hello Wilfried,
Another question regarding v6 reverse delegation, but possibly also applicable to v4 reverse...
One of our customers has a somewhat complex DNS setup which makes us face the situation that in the SOA record the name of the NS where the zone originates is not in the set of responses to NS queries.
While this is not the common case, I presume, it seems to NOT be "illegal".
The domain has to on-site name servers and is configured to have a slave at the NCC.
For this zone we received an alert that the ZXFR has failed from the machine with the name given in the SOA. That box will never be serving external zone transfer requests.
So - this may just be a glitch in the alerting script, but I am still left with the question: how does the robot at the NCC's end determine the "appropriate" host to try zone transfers from?
When the RIPE NCC's provisioning system sees ns.ripe.net in the list of name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record of the zone, extracts the MNAME from there, and looks up A and AAAA records for the MNAME. These are then used to attempt zone transfers for that zone. The provisioning system does not use any servers from the NS RRset. The provisioning system just generates configuration for BIND running on the ns.ripe.net cluster. It doesn't know whether a zone transfer will succeed or not. The recent alerts that we sent out to notify administrators of failing zone transfers were generated by a script, which took its input from BIND log files, where we have a record of failed zone transfers. The configuration you describe above isn't illegal. However, the RIPE NCC's provisioning system won't be able to cope with it. Currently, there's no way to explicitly provide a list of master servers that zone transfers should be attempted from. One solution is to list a server in the MNAME field which will provide zone transfers. Alternatively, you can choose not to use ns.ripe.net as a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 reverse zones. -- Anand Buddhdev DNS Services Manager, RIPE NCC
Thanks, Anand, providing answers for two of my questions in one mail :-) - that this isn't going to work for this setup, and - that we can deal with it locally, by excluding the server at the NCC from the list of slaves for that zone (as the requirement for a slave at the NCC is no longer in place - which I missed). Best regards, Wilfried Anand Buddhdev wrote:
On 20/11/08 15:02, Wilfried Woeber, UniVie/ACOnet wrote:
Hello Wilfried,
Another question regarding v6 reverse delegation, but possibly also applicable to v4 reverse...
One of our customers has a somewhat complex DNS setup which makes us face the situation that in the SOA record the name of the NS where the zone originates is not in the set of responses to NS queries.
While this is not the common case, I presume, it seems to NOT be "illegal".
The domain has to on-site name servers and is configured to have a slave at the NCC.
For this zone we received an alert that the ZXFR has failed from the machine with the name given in the SOA. That box will never be serving external zone transfer requests.
So - this may just be a glitch in the alerting script, but I am still left with the question: how does the robot at the NCC's end determine the "appropriate" host to try zone transfers from?
When the RIPE NCC's provisioning system sees ns.ripe.net in the list of name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record of the zone, extracts the MNAME from there, and looks up A and AAAA records for the MNAME. These are then used to attempt zone transfers for that zone. The provisioning system does not use any servers from the NS RRset.
The provisioning system just generates configuration for BIND running on the ns.ripe.net cluster. It doesn't know whether a zone transfer will succeed or not. The recent alerts that we sent out to notify administrators of failing zone transfers were generated by a script, which took its input from BIND log files, where we have a record of failed zone transfers.
The configuration you describe above isn't illegal. However, the RIPE NCC's provisioning system won't be able to cope with it. Currently, there's no way to explicitly provide a list of master servers that zone transfers should be attempted from.
One solution is to list a server in the MNAME field which will provide zone transfers. Alternatively, you can choose not to use ns.ripe.net as a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 reverse zones.
On Thu, Nov 20, 2008 at 08:14:34PM +0100, Anand Buddhdev wrote:
The configuration you describe above isn't illegal. However, the RIPE NCC's provisioning system won't be able to cope with it. Currently, there's no way to explicitly provide a list of master servers that zone transfers should be attempted from.
One solution is to list a server in the MNAME field which will provide zone transfers. Alternatively, you can choose not to use ns.ripe.net as
while the latter is probably the most pragmatic approach, it could interfere with other requirements. Depending on how widespread this issue is, the WG might also consider to propose a new attribute for the domain: object to denominate the (list of) AXFR source(s). -Peter
When the RIPE NCC's provisioning system sees ns.ripe.net in the list of name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record of the zone, extracts the MNAME from there, and looks up A and AAAA records for the MNAME. These are then used to attempt zone transfers for that zone. The provisioning system does not use any servers from the NS RRset. Why? I mean for me that would be one natural source of information another of course would be the nserver entries in the RIPE database. Using these source also would increase the resiliency of the zone
Moin! On 20.11.2008, at 20:14, Anand Buddhdev wrote: transfers as the server then usually has more than one source to transfer the zone from. I think that this is what people using hidden/ distribution masters want to have also, at least from my experience with our customers using this. [..]
One solution is to list a server in the MNAME field which will provide zone transfers. Alternatively, you can choose not to use ns.ripe.net as a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 reverse zones. Both are options, but I still would like to know if it wouldn't make more sense to use nserver records or NS RRset. Do you have some statistics on how often the MNAME is not in the nserver/NS RRset?
So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400
Ralf Weber wrote:
Moin!
On 20.11.2008, at 20:14, Anand Buddhdev wrote:
When the RIPE NCC's provisioning system sees ns.ripe.net in the list of name servers for /16 IPv4 and /32 IPv6 zones, it looks up the SOA record of the zone, extracts the MNAME from there, and looks up A and AAAA records for the MNAME. These are then used to attempt zone transfers for that zone. The provisioning system does not use any servers from the NS RRset.
Why? I mean for me that would be one natural source of information another of course would be the nserver entries in the RIPE database.
Beware - I am not a DNS expert... My feeling is that the current behaviour is quite reasonable. Of course we might suggest to look at the NS records (in addition maybe), but I presume that many folks do not allow zone transfers from *all* NS in the set. Unless we find a "clever" way to provide the info about the name server(s) to try for a transfer, overall, we would just increase the number of failed attempts. Whether that would do any harm (at the NCC's or customer's end) is a different story, maybe.
Using these source also would increase the resiliency of the zone transfers as the server then usually has more than one source to transfer the zone from. I think that this is what people using hidden/ distribution masters want to have also, at least from my experience with our customers using this.
[..]
One solution is to list a server in the MNAME field which will provide zone transfers. Alternatively, you can choose not to use ns.ripe.net as a secondary - it is no longer mandatory for /16 IPv4 and /32 IPv6 reverse zones.
Both are options, but I still would like to know if it wouldn't make more sense to use nserver records or NS RRset. Do you have some statistics on how often the MNAME is not in the nserver/NS RRset?
I definitely don't have any figures.
So long -Ralf
Wilfried
Moin! On 21.11.2008, at 10:28, Wilfried Woeber, UniVie/ACOnet wrote:
My feeling is that the current behaviour is quite reasonable. Of course we might suggest to look at the NS records (in addition maybe), but I presume that many folks do not allow zone transfers from *all* NS in the set. Correct, but only one is required for a proper transfer.
Unless we find a "clever" way to provide the info about the name server(s) to try for a transfer, overall, we would just increase the number of failed attempts. Whether that would do any harm (at the NCC's or customer's end) is a different story, maybe. Yes it could clutter the logs, but if one transfer would succeed it would be ok. I have used this technique successfully during various DNS migrations.
Both are options, but I still would like to know if it wouldn't make more sense to use nserver records or NS RRset. Do you have some statistics on how often the MNAME is not in the nserver/NS RRset?
I definitely don't have any figures. Sorry that was a question to Anand, but I didn't point that out. Anand do you have statistics for the current delegations?
So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400
On Fri, Nov 21, 2008 at 11:05:25AM +0100, Ralf Weber wrote:
Unless we find a "clever" way to provide the info about the name server(s) to try for a transfer, overall, we would just increase the number of failed attempts. Whether that would do any harm (at the NCC's or customer's end) is a different story, maybe. Yes it could clutter the logs, but if one transfer would succeed it would be ok. I have used this technique successfully during various DNS migrations.
So maybe the easiest idea is to change the structure of the nserver attribute to something like: nserver: name-of-ns-server [transfer] where "transfer" is optional parameter which is recognised by NCC? Regards, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
So maybe the easiest idea is to change the structure of the nserver attribute to something like: nserver: name-of-ns-server [transfer] where "transfer" is optional parameter which is recognised by NCC? Good idea, but if we want to solve this with changes you also have model the case that currently is handled with the primary not being in
Moin! On 21.11.2008, at 11:18, Piotr Strzyzewski wrote: the name server records (transfer-only?). The questions is do we want to change this and if so don't we then have to take it to the Database and NCC Services Working Groupa also. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400
On Thu, 2008-11-20 at 14:02 +0000, Wilfried Woeber, UniVie/ACOnet wrote:
So - this may just be a glitch in the alerting script, but I am still left with the question: how does the robot at the NCC's end determine the "appropriate" host to try zone transfers from?
Any recommendations?
IMHO ... This is a system-administrative matter to be agreed between the zone administrator and the slave operator. Zone data is not zone metadata. Blurring the distinction can only lead to unintended consequences. If a robot is involved, there needs to be an out-of-zone channel from the zone administrator to the robot. Peter's suggestion of using a new attribute in the database to serve this purpose makes sense to me. A similar, but more sensitive, issue arises with shared secrets for TSIGs. ATB, Niall
participants (10)
-
Anand Buddhdev -
Barbara Roseman -
bmanning＠vacation.karoshi.com -
Jaap Akkerhuis -
Mohsen Souissi -
Niall O'Reilly -
Peter Koch -
Piotr Strzyzewski -
Ralf Weber -
Wilfried Woeber, UniVie/ACOnet