Re: Multiple masters expected behavior?
On 2010-07-23 22:52, Peter Laws wrote: I would have expected that it would only ask the second-listed master if the first didn't answer ... but I didn't write the code (and haven't read it either! And how would your slave ever pick up an update on second-listed master that (for whatever reason) doesn't propagate to the first? After all, the first is still answering, but with old data. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: USADOTGOV.NET Root Problems?
On Jul 25, 2010, at 3:34 PM, Kevin Oberman wrote: From: Warren Kumari war...@kumari.net Date: Sun, 25 Jul 2010 11:22:46 +0200 Sender: bind-users-bounces+oberman=es@lists.isc.org On Jul 25, 2010, at 4:33 AM, Danny Mayer wrote: On 7/24/2010 5:10 AM, Warren Kumari wrote: On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote: On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote: Thanks for the confirmation that the problem was related to DNSSEC. I didn't see your message until I got home from work; however, I did find the root of the problem late this afternoon. At each of our Internet egress and ingress points, we have Cisco ASA devices sitting in front of a pair of redundant firewalls. Each ASA is configured with the default DNS inspect policy that doesn't accept fragmented UDP packets. Why would any inspection policy not allow fragmented UDP packets? There's nothing wrong with that. Because it's hard The issue is that then you need to buffer fragments until you get a full packet -- which leaves you open to attacks that send a bunch of fragments but leave one of them out. Vendors like to avoid reassembling fragments by default, because it makes their performance numbers better At the expense of correct behavior and loss of real performance. Yes. Sorry, if I gave the impression that I was condoning this -- I'm not. Vendors exist to sell boxen -- tuning for the test cases at the expense of correctness often wins And, as tests start to include DNSSEC (and EDNS0) tests, the vendors will likely adjust defaults. Tests for DNSSEC are already appearing on federal systems (not a trivial part of the business) and will likely become general test in the procurement process in the next year. Of course, changing defaults will take longer to change. Now to a more basic question...why the ^...@#$ does everyone put STATEFUL firewalls in front of servers. They are a denial of service attack waiting to happen. I don't know of any highly regarded security expert who recommends them and most object to them rather strongly. I will admit to once having stateful firewalls in front of my DNS servers, but after an unfortunate case of a badly written application DOSing ourselves, stateful firewalls have been removed. Yes, the software needed fixing, but the software was not enough to cause any problem for the servers...just the firewall. And, yes, we still have stateless firewalls in front of our DNS servers and other public servers as well as an aggressive IDS/IPS system. Here! Here! I much prefer using packet filter firewalls at the outer markers but haven't been able to sway security or my network colleagues. For those interested, the error code is ASA-4-209005. The error is that the message contains more than 1 element. So far the first fix didn't solve the problem and I haven't seen what problems that the next layer of firewalls will produce. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: USADOTGOV.NET Root Problems?
On Jul 26, 2010, at 12:36 AM, Warren Kumari wrote: On Jul 26, 2010, at 12:34 AM, Kevin Oberman wrote: From: Warren Kumari war...@kumari.net Date: Sun, 25 Jul 2010 11:22:46 +0200 Sender: bind-users-bounces+oberman=es@lists.isc.org On Jul 25, 2010, at 4:33 AM, Danny Mayer wrote: On 7/24/2010 5:10 AM, Warren Kumari wrote: On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote: On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote: Thanks for the confirmation that the problem was related to DNSSEC. I didn't see your message until I got home from work; however, I did find the root of the problem late this afternoon. At each of our Internet egress and ingress points, we have Cisco ASA devices sitting in front of a pair of redundant firewalls. Each ASA is configured with the default DNS inspect policy that doesn't accept fragmented UDP packets. Why would any inspection policy not allow fragmented UDP packets? There's nothing wrong with that. Because it's hard The issue is that then you need to buffer fragments until you get a full packet -- which leaves you open to attacks that send a bunch of fragments but leave one of them out. Vendors like to avoid reassembling fragments by default, because it makes their performance numbers better At the expense of correct behavior and loss of real performance. Yes. Sorry, if I gave the impression that I was condoning this -- I'm not. Vendors exist to sell boxen -- tuning for the test cases at the expense of correctness often wins And, as tests start to include DNSSEC (and EDNS0) tests, the vendors will likely adjust defaults. Tests for DNSSEC are already appearing on federal systems (not a trivial part of the business) and will likely become general test in the procurement process in the next year. Of course, changing defaults will take longer to change. Now to a more basic question...why the ^...@#$ does everyone put STATEFUL firewalls in front of servers. i suspect that this was intended as a rhetorical question / rant, but I'll ignore that and answer it anyway :-) Folk seems to do this for 3 reasons: 1: They truly believe that a stateful firewall will protect their server, either from port 53 attacks, or attacks on other ports. 2: They went through some certification process that demands that all services live behind a firewall 3: (and this is the common one) The folk that run the DNS servers are not the network security folk. The network security folk believe that the sysadmin types are unable to run a secure service that can be exposed to the Internet. The DNS folk may / probably have tried explaining that this firewall causes more issues than it solves, but what management hear is The DNS folk think that they can run a secure service, but network folk think that they need more security. and they err on the side of caution... You forgot one point. Each layer of firewall must implement exactly the same security policy. Can't have outer firewalls different in order to remove ambiguity or simply to get rid of packets and protocols you are not prepared to support anyway. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Migrating to a New Cryptographic Suite
Hi, I am running a test about the DNSSEC on my name servers. At present, i use the algorithm RSASHA-1 for DNSKEY, but i want migrate the RSASHA-1 to RSASHA-256, when i resigning the zone,it failed. so i wonder if DNSSEC supporting migrating RSASHA-1 to RSASHA-256 smoothly? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS update from Linux to Windows DNS Server
I'm not sure if this is the right place to ask this but I am trying to execute a DNS update using the nsupdate utility to update an A record from a Linux server to a Windows 2008 R2 DNS server. Sending the request using 'nsupdate -o' responds with 'response to GSS-TSIG query was unsuccessful'. Am I missing something or is this not possible? ~Cory Coager The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS update from Linux to Windows DNS Server
On 26/07/10 16:32, Cory Coager wrote: I'm not sure if this is the right place to ask this but I am trying to execute a DNS update using the nsupdate utility to update an A record from a Linux server to a Windows 2008 R2 DNS server. Sending the request using 'nsupdate -o' responds with 'response to GSS-TSIG query was unsuccessful'. Am I missing something or is this not possible? nsupdate -o is documented to be for old win2k servers only. Try nsupdate -g ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS update from Linux to Windows DNS Server
'nsupdate -g' responds with 'dns_request_getresponse: FORMERR' On 07/26/2010 11:40 AM, Phil Mayers wrote: On 26/07/10 16:32, Cory Coager wrote: I'm not sure if this is the right place to ask this but I am trying to execute a DNS update using the nsupdate utility to update an A record from a Linux server to a Windows 2008 R2 DNS server. Sending the request using 'nsupdate -o' responds with 'response to GSS-TSIG query was unsuccessful'. Am I missing something or is this not possible? nsupdate -o is documented to be for old win2k servers only. Try nsupdate -g ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS update from Linux to Windows DNS Server
On 26/07/10 16:56, Cory Coager wrote: 'nsupdate -g' responds with 'dns_request_getresponse: FORMERR' Sorry then. I don't know. Personally I can't make nsupdate work at all with GSSAPI; I get: dns_tkey_buildgssquery failed: ran out of space ...before it even tries to talk to the network. I have to use a home-grown tool (I also don't have access to a win2k8 r2 DNS server to test against...) You could try tcpdump/wireshark - figure out whether the issue is the TKEY negotiation of the GSSAPI context or the TSIG update. In a successful attempt you should see: C: query name=1234-56.x IN TKEY additional name=1234-56.x ANY TKEY payload=gssapi S: answer name=1234-56.x ANY TKEY payload=gssapi resp. C: update fields additional name=1234-56.x ANY TSIG payload=gssapi mic C: update response additional name=1234-56.x ANY TSIG payload=gssapi mic You might have a look at klist just before the attempt (do a kinit to zero out your cached tickets) and afterwards to check that you are getting the right ticket. As always with kerberos, DNS and NTP setup are vital to get this working. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS update from Linux to Windows DNS Server
In tcpdump I see: Standard query response, Refused On 07/26/2010 12:16 PM, Phil Mayers wrote: On 26/07/10 16:56, Cory Coager wrote: 'nsupdate -g' responds with 'dns_request_getresponse: FORMERR' Sorry then. I don't know. Personally I can't make nsupdate work at all with GSSAPI; I get: dns_tkey_buildgssquery failed: ran out of space ...before it even tries to talk to the network. I have to use a home-grown tool (I also don't have access to a win2k8 r2 DNS server to test against...) You could try tcpdump/wireshark - figure out whether the issue is the TKEY negotiation of the GSSAPI context or the TSIG update. In a successful attempt you should see: C: query name=1234-56.x IN TKEY additional name=1234-56.x ANY TKEY payload=gssapi S: answer name=1234-56.x ANY TKEY payload=gssapi resp. C: update fields additional name=1234-56.x ANY TSIG payload=gssapi mic C: update response additional name=1234-56.x ANY TSIG payload=gssapi mic You might have a look at klist just before the attempt (do a kinit to zero out your cached tickets) and afterwards to check that you are getting the right ticket. As always with kerberos, DNS and NTP setup are vital to get this working. The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ignoring forwarder zone statements..
Hi list,
I have a BIND9 server in a non public internet connected network. Most of the
functionality is working correctly but I have a specific problem.
The server 'resides' in a 3rd level zone ( e.g.
my-ns-server.level3.level2.level1. ) for which it is SOA NS, in addition it
is slave for the level1 zone.
sample from named.conf:
// slave level1 from masters.
zone level1 {
type slave;
file slave/level1;
notify no;
masters { 1.2.3.4; 1.2.3.5; };
};
// forward directly to otherlevel2 due to absence delegation from level1
zone otherlevel2.level1 {
type forward;
forwarders { 2.3.4.5; 2.3.4.6; };
};
(my root.hint also correctly references the private . servers)
My problem is that when clients query my server for entries within
otherlevel2.level1, instead forwarding the queries directly to the declared
forwarders, instead my server replies with NXDOMAIN (presumably from the
level1 slave data.)
any insight appreciated
/Pete
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring forwarder zone statements..
On 7/26/2010 1:46 PM, Pete Vickers wrote:
Hi list,
I have a BIND9 server in a non public internet connected network. Most of the
functionality is working correctly but I have a specific problem.
The server 'resides' in a 3rd level zone ( e.g. my-ns-server.level3.level2.level1.
) for which it is SOA NS, in addition it is slave for the level1 zone.
sample from named.conf:
// slave level1 from masters.
zone level1 {
type slave;
file slave/level1;
notify no;
masters { 1.2.3.4; 1.2.3.5; };
};
// forward directly to otherlevel2 due to absence delegation from level1
zone otherlevel2.level1 {
type forward;
forwarders { 2.3.4.5; 2.3.4.6; };
};
(my root.hint also correctly references the private . servers)
My problem is that when clients query my server for entries within
otherlevel2.level1, instead forwarding the queries directly to the declared
forwarders, instead my server replies with NXDOMAIN (presumably from the level1 slave
data.)
any insight appreciated
Make sure an actual delegation exists from level1 to otherlevel2.level1.
The forwarding logic doesn't know to look for a subzone definition
unless it sees a delegation.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: ignoring forwarder zone statements..
On 7/26/2010 1:46 PM, Pete Vickers wrote:
Hi list,
I have a BIND9 server in a non public internet connected network. Most of
the \
functionality is working correctly but I have a specific problem.
The server 'resides' in a 3rd level zone ( e.g.
my-ns-server.level3.level2.level1. \
) for which it is SOA NS, in addition it is slave for the level1 zone.
sample from named.conf:
// slave level1 from masters.
zone level1 {
type slave;
file slave/level1;
notify no;
masters { 1.2.3.4; 1.2.3.5; };
};
// forward directly to otherlevel2 due to absence delegation from level1
zone otherlevel2.level1 {
type forward;
forwarders { 2.3.4.5; 2.3.4.6; };
};
(my root.hint also correctly references the private . servers)
My problem is that when clients query my server for entries within \
otherlevel2.level1, instead forwarding the queries directly to the
declared \
forwarders, instead my server replies with NXDOMAIN (presumably from the
level1 \
slave data.)
any insight appreciated
Make sure an actual delegation exists from level1 to otherlevel2.level1.
The forwarding logic doesn't know to look for a subzone definition
unless it sees a delegation.
- Kevin
hmm. My problem is that the delegation _doesn't_ exist from level1 to
otherlevel2.level1. That is what I'm try to work around with the forward
statement directly referencing the NSs.
The level1 zone is politically immutable, so fixing the problem there is not an
option. Any other ideas ? (being a slave of the otherlevel2.level1. zone is
also not practical).
/Pete
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Migrating to a New Cryptographic Suite
- Original message - At present, i use the algorithm RSASHA-1 for DNSKEY, but i want migrate the RSASHA-1 to RSASHA-256, when i resigning the zone,it failed. so i wonder if DNSSEC supporting migrating RSASHA-1 to RSASHA-256 smoothly? Yes, it does. Smoothness depends on the timing. You might find this summary useful: http://snad.ncsl.nist.gov/dnssec/download/DNSSEC_Algorithm_rollover.pdf Did you create a new key with the appropriate algorithm ID? dnssec-signzone can only sign the zone with algorithms present in the DNSKEY set. The actual error message would be helpful, too. If you have registered DS records with your parent zone, you must update them to include the new key(s). Hauke. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring forwarder zone statements..
On 7/26/2010 2:27 PM, Pete Vickers wrote:
On 7/26/2010 1:46 PM, Pete Vickers wrote:
Hi list,
I have a BIND9 server in a non public internet connected network. Most of the \
functionality is working correctly but I have a specific problem.
The server 'resides' in a 3rd level zone ( e.g.
my-ns-server.level3.level2.level1. \
) for which it is SOA NS, in addition it is slave for the level1 zone.
sample from named.conf:
// slave level1 from masters.
zone level1 {
type slave;
file slave/level1;
notify no;
masters { 1.2.3.4; 1.2.3.5; };
};
// forward directly to otherlevel2 due to absence delegation from level1
zone otherlevel2.level1 {
type forward;
forwarders { 2.3.4.5; 2.3.4.6; };
};
(my root.hint also correctly references the private . servers)
My problem is that when clients query my server for entries within \
otherlevel2.level1, instead forwarding the queries directly to the declared \
forwarders, instead my server replies with NXDOMAIN (presumably from the
level1 \
slave data.)
any insight appreciated
Make sure an actual delegation exists from level1 to otherlevel2.level1.
The forwarding logic doesn't know to look for a subzone definition
unless it sees a delegation.
- Kevin
hmm. My problem is that the delegation _doesn't_ exist from level1 to
otherlevel2.level1. That is what I'm try to work around with the forward
statement directly referencing the NSs.
The level1 zone is politically immutable, so fixing the problem there is not an
option. Any other ideas ? (being a slave of the otherlevel2.level1. zone is
also not practical).
Politics has left you with precious few options. One of them is to
define otherlevel2.level1 as a stub zone. If that zone has any
descendant zones, you may need to take some special care for them to be
resolvable as well.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring forwarder zone statements..
Hi list,
I have a BIND9 server in a non public internet connected network. Most of
the \
functionality is working correctly but I have a specific problem.
The server 'resides' in a 3rd level zone ( e.g.
my-ns-server.level3.level2.level1. \
) for which it is SOA NS, in addition it is slave for the level1 zone.
sample from named.conf:
// slave level1 from masters.
zone level1 {
type slave;
file slave/level1;
notify no;
masters { 1.2.3.4; 1.2.3.5; };
};
// forward directly to otherlevel2 due to absence delegation from level1
zone otherlevel2.level1 {
type forward;
forwarders { 2.3.4.5; 2.3.4.6; };
};
(my root.hint also correctly references the private . servers)
My problem is that when clients query my server for entries within \
otherlevel2.level1, instead forwarding the queries directly to the
declared \
forwarders, instead my server replies with NXDOMAIN (presumably from the
level1 \
slave data.)
any insight appreciated
Make sure an actual delegation exists from level1 to otherlevel2.level1.
The forwarding logic doesn't know to look for a subzone definition
unless it sees a delegation.
- Kevin
hmm. My problem is that the delegation _doesn't_ exist from level1 to
otherlevel2.level1. That is what I'm try to work around with the forward
statement directly referencing the NSs.
The level1 zone is politically immutable, so fixing the problem there is not
an option. Any other ideas ? (being a slave of the otherlevel2.level1. zone
is also not practical).
/Pete
Politics has left you with precious few options. One of them is to
define otherlevel2.level1 as a stub zone. If that zone has any
descendant zones, you may need to take some special care for them to be
resolvable as well.
- Kevin
Bingo, at initial testing it appears to work like a charm, even for sub-zones.
thanks !
/Pete
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters expected behavior?
In article mailman.100.1280077153.15649.bind-us...@lists.isc.org, Laws, Peter C. pl...@ou.edu wrote: Understood, but what I'm asking about is that the slave does not appear to be losing contact with the first-listed master. In fact, from the logs, it appears to be flipping back and forth (though not round-robinning). Multiple masters is not about losing contact, it's about getting the most up-to-date version of the zone. There's no reason for the slave to assume that the first master has the best version of the zone. The only way to tell is to check the SOA records on all the masters, and perform a zone transfer from any of them that have a higher serial than the one you already have. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
