Re: DNSSEC Question
I should have pointed out that BOTH servers have recursion turned on. Yeah, I know about having DNSSEC-enable=yes to not break downstream validation. (I inherited this setup...) BOTH are internal DNS servers with access to the internet to query the internet roots (no default forwarding active). I suspect it's the issue of having the DNSSEC-enable set to off on server B even though it's not validating. (But that's just a guess...) Thanks, Bob On Wed, Apr 11, 2018 at 9:48 AM, Tony Finch wrote: > Bob McDonald wrote: > > > > Server A > > DNSSEC=yes > > DNSSEC-validation=yes > > Valid trust anchor for the root zone > > DNSSEC validation seems to work correctly > > Zone one.com. is setup as a forward zone to server B > > > > Server B > > DNSSEC=no > > DNSSEC-validation=N/A > > authoritative and the master for one.com. > > This setup will not work reliably: the target forwarding server has to be > a recursive server, since the forwarding client will expect it to do full > resolution of the query - following delegations, etc. I expect it will > have funky interactions with DNSSEC validation (e.g. chasing DS records) > but I have not experimented with this myself. > > Also, you should never turn off the `dnssec-enable` setting, since that > prevents BIND from doing the right thing with RRSIG/NSEC/DS records. This > will break downstream validation even if the server is not itself > validating - that is, if you turn it off on an authoritative server, it > cannot serve any signed zones. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Southeast Malin: Easterly 5 to 7. Slight or moderate, becoming moderate or > rough. Mainly fair. 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: DNSSEC Question
Bob McDonald wrote: > > Server A > DNSSEC=yes > DNSSEC-validation=yes > Valid trust anchor for the root zone > DNSSEC validation seems to work correctly > Zone one.com. is setup as a forward zone to server B > > Server B > DNSSEC=no > DNSSEC-validation=N/A > authoritative and the master for one.com. This setup will not work reliably: the target forwarding server has to be a recursive server, since the forwarding client will expect it to do full resolution of the query - following delegations, etc. I expect it will have funky interactions with DNSSEC validation (e.g. chasing DS records) but I have not experimented with this myself. Also, you should never turn off the `dnssec-enable` setting, since that prevents BIND from doing the right thing with RRSIG/NSEC/DS records. This will break downstream validation even if the server is not itself validating - that is, if you turn it off on an authoritative server, it cannot serve any signed zones. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Malin: Easterly 5 to 7. Slight or moderate, becoming moderate or rough. Mainly fair. 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: dnssec question. confused.
Just an FYI - This is no longer the case for ASA/PIX after the commit of CSCta35563 - which went into the codebase in 2009.11. After the above commit, "the default" has been changed. Non-EDNS replies will still have the message length set to 512. But EDNS replies will use the advertised buffer size value specified by the requester in the OPT pseudo-RR. The command "message-length maximum client auto" was added to version 7.2.1 via the introduction of AIC inspection for DNS. However, when introduced if multiple maximum lengths were specified, like: ! policy-map type inspect dns preset_dns_map parameters message-length maximum client auto message-length maximum 512 ! Then the lesser of the two (typically 512 in the DNSSEC case) would be selected. With the fix for CSCta35563, we first check if the OPT pseudo-RR is present in a query request, and if so, that buffer size value is used. Otherwise, we fallback to using the global value of 512. In summary, customers running a version with the fix for CSCta35563 will work fine if they have the following configured: Versions with fix for CSCta35563: - ! policy-map type inspect dns preset_dns_map parameters message-length maximum client auto message-length maximum 512 ! Customers running a version prior to the fix for CSCta35563 will need to increase the global message-length maximum to 4096, until they upgrade to a version with the fix. Versions without fix for CSCta35563: ! policy-map type inspect dns preset_dns_map parameters message-length maximum 4096 ! regards, -- /karpenko On 2011.09.28-12:47:53 -0700, michoski wrote: > Date: Wed, 28 Sep 2011 12:47:53 -0700 > From: michoski > To: Steve Arntzen , bind-users@lists.isc.org > Subject: Re: dnssec question. confused. > > On 9/28/11 5:32 AM, "Steve Arntzen" wrote: >> Is your firewall Cisco based? >> >> There is a known "default" setting in Cisco with respect to >> packet size for DNS. Our network guys run into this anytime they >> do an upgrade, etc. and have to go in and update the setting. > > This bit me the first time I managed a PIX years ago (though, in > fairness, even then it was well documented on Cisco's site...I > just had to read logs and search), and now continues on the ASA it > seems... Once it's understood, it really shouldn't bite again: > > https://supportforums.cisco.com/thread/2013390 > > -- > By nature, men are nearly alike; > by practice, they get to be wide apart. > -- Confucius > > [ --- End of Included Message --- ] ___ 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: dnssec question. confused.
> On 9/28/11 5:32 AM, "Steve Arntzen" wrote: > > Is your firewall Cisco based? Yes. The firewall is Cisco based. However, the main problem there is, there are several firewalls before leaving our network and my dept doesn't manage all of them. > > There is a known "default" setting in Cisco with respect to packet > > size for DNS. Our network guys run into this anytime they do an > > upgrade, etc. and have to go in and update the setting. > > This bit me the first time I managed a PIX years ago (though, > in fairness, even then it was well documented on Cisco's > site...I just had to read logs and search), and now continues > on the ASA it seems... Once it's understood, it really > shouldn't bite again: > > https://supportforums.cisco.com/thread/2013390 I have read this site before and I'm told the settings are there on at least two of the firewalls, but yet we still have problems. I think the problem is a combination of the fixup or policy-map settings and ip fragmentation. I based this conclusion on details from this thread: https://lists.dns-oarc.net/pipermail/dns-operations/2011-February/006896.html I think there is some fragment IP settings on firewalls in between which are causing problems. Using Mark's test of: dig edns-v4-ok.isc.org txt I can't get a reply at all from this query. I'm waiting to discuss this with the network guy and see if we can get all the firewalls up the chain updated. I will let everyone know how it goes. Thanks for the assistance. bb ___ 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: dnssec question. confused.
On 9/28/11 5:32 AM, "Steve Arntzen" wrote: > Is your firewall Cisco based? > > There is a known "default" setting in Cisco with respect to packet size > for DNS. Our network guys run into this anytime they do an upgrade, > etc. and have to go in and update the setting. This bit me the first time I managed a PIX years ago (though, in fairness, even then it was well documented on Cisco's site...I just had to read logs and search), and now continues on the ASA it seems... Once it's understood, it really shouldn't bite again: https://supportforums.cisco.com/thread/2013390 -- By nature, men are nearly alike; by practice, they get to be wide apart. -- Confucius ___ 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: dnssec question. confused.
Is your firewall Cisco based? There is a known "default" setting in Cisco with respect to packet size for DNS. Our network guys run into this anytime they do an upgrade, etc. and have to go in and update the setting. Steve. On Tue, 2011-09-27 at 15:45 -0500, Brad Bendily wrote: > When trying the DNSSEC check command from: > https://www.dns-oarc.net/oarc/services/replysizetest > > behind our corporate firewall, I get: > rst.x476.rs.dns-oarc.net. > rst.x485.x476.rs.dns-oarc.net. > rst.x490.x485.x476.rs.dns-oarc.net. > "Tested at 2011-09-27 20:32:34 UTC" > "205.172.49.177 sent EDNS buffer size 4096" > "205.172.49.177 DNS reply size limit is at least 490" > > > Which, based on the website tells me our firewall is blocking > or filtering EDNS/DNSSEC packets. > > > > However, what I'm confused about is when I run this command: > dig +dnssec eeoc.gov > > I get: > > ; <<>> DiG 9.7.3-P1 <<>> +dnssec eeoc.gov > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40572 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;eeoc.gov. IN A > > ;; ANSWER SECTION: > eeoc.gov. 19499 IN A 64.94.64.52 > eeoc.gov. 19499 IN RRSIG A 7 2 21600 20111208014816 > 20110909014816 52909 eeoc.gov. > AW5Ny32xDP7+m4XxCSS7q/zuK8RBc+la70Zmg0A/Pe1+p0agkrzbxaHM > GgvKldSKCzVgo7XPGR3LqcGIFDl0CPaaSTxTntlZkdh6x2qS4mM/49+B > 9podxzbV3V4LcNpR4c4jyteAa5Uxaz3WSRr1T69PpJyIZZ53JmexkMPi > yOjMcp1IqeSJ0P/06CuZccemo+f/fjGW8xfG/slOp2XJlmbPo1EfJnlw > i07YstZVszHxsgmRUXssEUmkWi3eqAw4Ug2QiRa+zz3JpmgBnC0G7Kxd > SXUJLuvfNdDrtJ9T5anNVRVxCVq499gaJQnWBXKKVVaC9w/BcPnGuSRy OZTyPg== > > ;; AUTHORITY SECTION: > eeoc.gov. 66519 IN NS dnssec10.datamtn.com. > eeoc.gov. 66519 IN NS dnssec14.datamtn.com. > eeoc.gov. 66519 IN NS dnssec11.datamtn.com. > eeoc.gov. 66519 IN NS dnssec12.datamtn.com. > eeoc.gov. 66519 IN NS dnssec9.datamtn.com. > > ;; ADDITIONAL SECTION: > dnssec9.datamtn.com.3114IN 2001:49f0:a02a:1000::238 > dnssec11.datamtn.com. 3114IN 2001:470:1:7a::147 > dnssec9.datamtn.com.3114IN RRSIG 7 3 10800 2025185428 > 20110827185428 21352 datamtn.com. > Ngz7Bl2VWqhIY5Uh8bHJjwyAWQXcEM7qaAH8JSJ5VM5qMelfVA1pV+Y6 > RltfXpACQxRpHsayiArGZulzp1XX4yW6+qsHiKLJOcRiS5kmjexBPUlK > zyU3cp7BC5dprHyPBpXKbHExuGlvqrg1aqRJtAmH6Q7tkp2wWqEuO3Ku > LBvvGXN46U+sYPsd98YixlLLTtj2qFo7/vhPN8ao2g6HuFBVIUTU4LuV > d7Wjz+r4Xj722w6RFgZFu9qFwYsOQwTGlon4zqDvflzESSWSjFdzHCZ0 > prkagjXwcZYMlQGRMgnmHlEEvvg+lKMdl4imHLx/LKLD+feCzp2d4PFj 9byoYA== > dnssec9.datamtn.com.3114IN RRSIG 8 3 10800 2025185428 > 20110827185428 61898 datamtn.com. > NtPfKvEs6DF0Bac9ZbCfi0b0QdeVMSlaNXAyDFSjo4J8uQUYllDwt101 > C78VAiXplumZRM/9Vv7fg1/Ds/qCd6wC6wdTR3S8mtDOpLHVhuZTSGI1 > jBVBXYjzBdqIBitydwD6vs+VaPsfd352NBqE8teFQJhbVAI98+d9BO4x > /Qx+i2HJOPdQyVRq6dj2NYg1GT4ODDb6VmQUOb01XgIyX/pLt+7AdtId > 1FFbA9LfO4xvYTCKAO3LbPvdU7nJ2+mCMu5CNQFNiwAbSHT3letupzpH > yLUNrjhcO0cj/vVf1YrrIzZXF69zKGYfsCP876zKoVtlrUe1dZ0bersP 4I9klg== > dnssec11.datamtn.com. 3114IN RRSIG 7 3 10800 2025185428 > 20110827185428 21352 datamtn.com. > Lgt6Wq5JvvAF6BKUUoPSiv6lx0yqQ3HAFoClEcg11V7XhIngeaTperu7 > 7lytmKl53yZUxarFbQdJ/NxwwNVl/F2Os5RkNHkAjVTkku1mjoMeqEhF > NDe+cvYOOo0EASc9LhmHo2qgkyhjGAt1FtbmrOG9Gwr5OdUM5l2EgcGj > bRvH1Sfv5le68ST1+74sQPKmp+3n0gopfKUlcYuDDw/mUKXR8lo3MCTv > xe6q6NbwHNHWBCgUw4rqX4ZdVArL4WumKvkufeieDJpMhKwHlWHyPvu9 > pX1IsZRyQPo9RqnmSpG+yjR59ixbb23LyO6alrEDJTyaJZL8uHfwiTQ8 4V29tQ== > dnssec11.datamtn.com. 3114IN RRSIG 8 3 10800 2025185428 > 20110827185428 61898 datamtn.com. > vtFFEZbruIfnwSGAdlXukUn40SOEIZY9QXrHh6CfOl3WkQduSnbvgS5T > +e2QN6GDcZgigGON8yHHTS8DI8ld/tCxxVkwB3ISkqkQHrjyyRD6+8IR > J2BWsdMTyAhe9PygLR1FkfCt1JDaDnAbOKOniMT+6DRlnE7ZW7KfvZT/ > 7j5qG+xDixCXUHyhnstbv9vmMPTxnK1ASy6nz7ErnA/DUMleO484xIgM > 6Pc8uqy3Onw4Yfn4l5R66tQwC0yoSVwqmEyIWNWyx1SNQLFzUc1hySaF > aQs1L/Zyu9e/wSHdZUeGiOwx5cz3yWE2NsF3tagxukkL9vNu2s/nyjzR 3igT3g== > > ;; Query time: 1 msec > ;; SERVER: 10.120.11.107#53(10.120.11.107) > ;; WHEN: Tue Sep 27 15:34:07 2011 > ;; MSG SIZE rcvd: 1726 > > > Which tells me my DNSSEC queries are working, right? > I noticed in the "OPT PSEUDOSECTION" udp=4096. > > This started because, as the DNS admin, I was informed today that we could > not resolve > this domain, eeoc.gov. Which was true. As I started digging into it, and > performing a > dig from an offsite server which was working, I found that the domain > "eeoc.gov" is > running DNSSEC. So, I assumed the problem was with our firewall blocking or > filtering > the DNSSEC traffic. But then after researching for a few hours, I found we > w
RE: dnssec question. confused.
Hello, 1) the dig command, as shown, does not ask an authoritative name server for eeoc.gov. but rather addresses a locally configured caching name server (10.120.11.107). (which may explain the difference in size - 1726 bytes - as opposed to the 3918 bytes of Doug Barton) ((some data may already have timed out of the local cache, observe the TTL values)) 2) I'd say : yes, you receive DNSSEC responses. But your caching name server is not validating them : the AD bit is not set in the answer. 3) The OPT RR, with length 4096, is in the *reply*. The server indicates that itself is willing to accept DNS over UDP packets up till that size (eg. for dynamic updates). (while EDNS0 RFC does not explicitly state replying with EDNS0 is mandatory, if a query came in with EDNS0, there is also a statement that claims this (sending EDNS0 and looking in the reply) is a way, for a (dynamic update) client, to find out what the server is willing to accept. This statement seems to imply that EDNS0 in a reply, should be there if the client sent EDNS0. Any other opinions in the list ?) In order to see the packet size in the outgoing query packet, use something like wireshark. 4) "DNSSEC query" is not precise enough ! For one thing, DNSSEC requires EDNS0, EDNSO announces a buffersize, which can vary. As long as (!) the buffersize is sufficient, UDP will be used, but DNS queries can also be sent over TCP (and is your firewall allowing that ?). My suggestion (from a device that is allowed to send DNS queries to the Internet), try : dig @dnssec9.datamtn.com. eeoc.gov. +dnssec dig @dnssec9.datamtn.com. eeoc.gov. +dnssec +bufsize=512 and dig @dnssec9.datamtn.com. eeoc.gov. +dnssec +vc (and don't forget to have your caching NS validate DNSSEC answers, because providing signatures that are ignored by clients makes the Internet *less* safe) Kind regards, Marc Lampo Security Officer EURid -Original Message- From: Brad Bendily [mailto:brad.bend...@la.gov] Sent: 27 September 2011 10:45 PM To: bind-users@lists.isc.org Subject: dnssec question. confused. When trying the DNSSEC check command from: https://www.dns-oarc.net/oarc/services/replysizetest behind our corporate firewall, I get: rst.x476.rs.dns-oarc.net. rst.x485.x476.rs.dns-oarc.net. rst.x490.x485.x476.rs.dns-oarc.net. "Tested at 2011-09-27 20:32:34 UTC" "205.172.49.177 sent EDNS buffer size 4096" "205.172.49.177 DNS reply size limit is at least 490" Which, based on the website tells me our firewall is blocking or filtering EDNS/DNSSEC packets. However, what I'm confused about is when I run this command: dig +dnssec eeoc.gov I get: ; <<>> DiG 9.7.3-P1 <<>> +dnssec eeoc.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40572 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;eeoc.gov. IN A ;; ANSWER SECTION: eeoc.gov. 19499 IN A 64.94.64.52 eeoc.gov. 19499 IN RRSIG A 7 2 21600 20111208014816 20110909014816 52909 eeoc.gov. AW5Ny32xDP7+m4XxCSS7q/zuK8RBc+la70Zmg0A/Pe1+p0agkrzbxaHM GgvKldSKCzVgo7XPGR3LqcGIFDl0CPaaSTxTntlZkdh6x2qS4mM/49+B 9podxzbV3V4LcNpR4c4jyteAa5Uxaz3WSRr1T69PpJyIZZ53JmexkMPi yOjMcp1IqeSJ0P/06CuZccemo+f/fjGW8xfG/slOp2XJlmbPo1EfJnlw i07YstZVszHxsgmRUXssEUmkWi3eqAw4Ug2QiRa+zz3JpmgBnC0G7Kxd SXUJLuvfNdDrtJ9T5anNVRVxCVq499gaJQnWBXKKVVaC9w/BcPnGuSRy OZTyPg== ;; AUTHORITY SECTION: eeoc.gov. 66519 IN NS dnssec10.datamtn.com. eeoc.gov. 66519 IN NS dnssec14.datamtn.com. eeoc.gov. 66519 IN NS dnssec11.datamtn.com. eeoc.gov. 66519 IN NS dnssec12.datamtn.com. eeoc.gov. 66519 IN NS dnssec9.datamtn.com. ;; ADDITIONAL SECTION: dnssec9.datamtn.com.3114IN 2001:49f0:a02a:1000::238 dnssec11.datamtn.com. 3114IN 2001:470:1:7a::147 dnssec9.datamtn.com.3114IN RRSIG 7 3 10800 2025185428 20110827185428 21352 datamtn.com. Ngz7Bl2VWqhIY5Uh8bHJjwyAWQXcEM7qaAH8JSJ5VM5qMelfVA1pV+Y6 RltfXpACQxRpHsayiArGZulzp1XX4yW6+qsHiKLJOcRiS5kmjexBPUlK zyU3cp7BC5dprHyPBpXKbHExuGlvqrg1aqRJtAmH6Q7tkp2wWqEuO3Ku LBvvGXN46U+sYPsd98YixlLLTtj2qFo7/vhPN8ao2g6HuFBVIUTU4LuV d7Wjz+r4Xj722w6RFgZFu9qFwYsOQwTGlon4zqDvflzESSWSjFdzHCZ0 prkagjXwcZYMlQGRMgnmHlEEvvg+lKMdl4imHLx/LKLD+feCzp2d4PFj 9byoYA== dnssec9.datamtn.com.3114IN RRSIG 8 3 10800 2025185428 20110827185428 61898 datamtn.com. NtPfKvEs6DF0Bac9ZbCfi0b0QdeVMSlaNXAyDFSjo4J8uQUYllDwt101 C78VAiXplumZRM/9Vv7fg1/Ds/qCd6wC6wdTR3S8mtDOpLHVhuZTSGI1 jBVBXYjzBdqIBitydwD6vs+VaPsfd352NBqE8teFQJhbVAI98+d9BO4x /Qx+i2HJOPdQyVRq6dj2NYg1GT4ODDb6VmQUOb01XgIyX/pLt+7AdtId 1FFbA9LfO4xvYTCKAO3LbPvdU7nJ2+mCMu5CNQFNiwAbSHT3letupzpH yLUNrjhcO0cj/vVf1YrrIz
Re: dnssec question. confused.
In message <798e3caf2fcc264481d8f75fb3d0bfd91b538...@mailmbx10.mail.la.gov>, Br ad Bendily writes: > > When trying the DNSSEC check command from: > https://www.dns-oarc.net/oarc/services/replysizetest > > behind our corporate firewall, I get: > rst.x476.rs.dns-oarc.net. > rst.x485.x476.rs.dns-oarc.net. > rst.x490.x485.x476.rs.dns-oarc.net. > "Tested at 2011-09-27 20:32:34 UTC" > "205.172.49.177 sent EDNS buffer size 4096" > "205.172.49.177 DNS reply size limit is at least 490" > > > Which, based on the website tells me our firewall is blocking > or filtering EDNS/DNSSEC packets. > > However, what I'm confused about is when I run this command: > dig +dnssec eeoc.gov > > I get: > > ; <<>> DiG 9.7.3-P1 <<>> +dnssec eeoc.gov > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40572 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7 > [snipped] > > ;; Query time: 1 msec > ;; SERVER: 10.120.11.107#53(10.120.11.107) > ;; WHEN: Tue Sep 27 15:34:07 2011 > ;; MSG SIZE rcvd: 1726 > > > Which tells me my DNSSEC queries are working, right? Not optimally. Named will work around some firewall breakage by retrying the queries the time oute with smaller EDNS UDP buffer size of 512 bytes which allow the response to get through the firewall. Often those responses will have TC=1 set so named will then ask the query again but this time over TCP. So instead of a single UDP query and response you end up with multiple UDP queries and a TCP connection. You should have your firewall configured to pass EDNS UDP packets up to 4096 bytes of UDP payload. The two queries below generate such a response from the authoritative nameservers and can't be resolved from behind a firewall that blocks such responses (TCP fallback will fail). dig edns-v4-ok.isc.org txt dig edns-v6-ok.isc.org txt > I noticed in the "OPT PSEUDOSECTION" udp=4096. Because you were talking to the local recursive nameserver which is also behind the firewall. > This started because, as the DNS admin, I was informed today that we could no > t resolve > this domain, eeoc.gov. Which was true. As I started digging into it, and perf > orming a > dig from an offsite server which was working, I found that the domain "eeoc.g > ov" is > running DNSSEC. So, I assumed the problem was with our firewall blocking or f > iltering > the DNSSEC traffic. But then after researching for a few hours, I found we we > re able > to resolve the domain, through no changes of DNS. > It could be that "datamtn.com", their authoritative NS are performing > maintenance or something. So, all this research led me to the information abo > ve. There could have been many causes. > Are we getting EDNS/DNSSEC responses or no? Yes but not optimally. > thanks > bb > ___ > 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: dnssec question. confused.
On 09/27/2011 13:45, Brad Bendily wrote: > dig +dnssec eeoc.gov Try that again with +notcp. FYI, on a "clean" network the response I get to that query is 3,918 bytes. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
