Re: Internernal view is answering to external ping
- Original Message -
On 1 August 2013 18:58, Lawrence K. Chen, P.Eng. lkc...@ksu.edu
wrote:
Did I miss something... what does ICMP ping have anything to do
with bind?
Yes, you missed the actual question. The use of the word 'ping' is a
misnomer, what he really meant to say that from a host on the
internet
he is receiving an internal 192.168.x.x IP address as the response
(he
pinged a FQDN which in turn does a lookup to obtain the IP). Without
seeing the full config (which has been asked for) it's pointless
speculating on possible reasons for this as there are quite a few.
Steve
so totally a red herring
yet...the thing that is weird is that if he's ping'ing from the Internet side
and getting the internal IP, how does ping succeed in sending and receiving 3
packets?
VPN?
Anyways, at this point...I would speculate the problem is this:
acl internal {
localhost;
200.57.66.77/28;
192.168.0.0/23
};
since typical example of doing this kind of thing might be:
view internal {
match-clients { internal; }
// view statements
zone mydomain.com {
type master;
// private zone file including 192.168.x.x hosts
file mydomain.com.hosts.lan;
};
// additional zone clauses
}
view external {
match-clients { any; }
// view statements
zone mydomain.com {
type master;
// public only hosts
file mydomain.com.hosts;
};
// additional zone clauses
}
And, that he's only testing from another IP in 200.57.66.64/28
Since ping times are really short too.
Lawrence
___
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
Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both
Hello all, I ran into an interesting situation resolving dfas.mil. It appears that they have attempted to roll their ZSKs to algorithm 8 while leaving their KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for each record set in the zone MUST include at least one RRSIG for each algorithm. (The distinction between KSK and ZSK is an operational convenience and not part of the standard, per se.) The relevant excerpt from Section 2.2 of RFC 4035: There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). DNSViz and Verisign's DNSSEC debugger correctly report the error. http://dnssec-debugger.verisignlabs.com/dfas.mil http://dnsviz.net/d/dfas.mil/dnssec/ However, I discovered when I checked against DNS-OARC ODVR (and my own personal validating recursive nameserver at home) that BIND 9 apparently doesn't correctly enforce that requirement. https://www.dns-oarc.net/oarc/services/odvr The BIND 9 resolver returns an answer with the AD bit set. Unbound returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the only three nameservers I've tested. It looks like a validation bug in BIND to me, but I thought I would see what others thought. It's probably a pretty rare situation, since I can't imagine most people who choose to use separate KSKs and ZSKs would try to migrate only their ZSKs to a new algorithm while leaving their KSKs at the old algorithm. Thanks, Scott ___ 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: Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both
In message 51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov, Scott Morizot wri tes: Hello all, I ran into an interesting situation resolving dfas.mil. It appears that they have attempted to roll their ZSKs to algorithm 8 while leaving their KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for each record set in the zone MUST include at least one RRSIG for each algorithm. (The distinction between KSK and ZSK is an operational convenience and not part of the standard, per se.) The relevant excerpt from Section 2.2 of RFC 4035: There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). DNSViz and Verisign's DNSSEC debugger correctly report the error. http://dnssec-debugger.verisignlabs.com/dfas.mil http://dnsviz.net/d/dfas.mil/dnssec/ However, I discovered when I checked against DNS-OARC ODVR (and my own personal validating recursive nameserver at home) that BIND 9 apparently doesn't correctly enforce that requirement. Because the requirement is *only* on the signer. You will note that the validator is NOT required to check for this as part of the list of things it is supposed to check for and that is a deliberate design decision. If the signer follows this and the timing rules the zone will not be treated as bogus. The unbound developers didn't realise this initially and added unspecified checks to their validator. As the zone currently stands a validator that only support alg 8 will treat it as insecure as there is no DS record from alg 8. A validator that only supports alg 7 will treat it as secure. A validator that supports alg 7 and alg 8 will treat it as secure. Remember when you introduce a new algorithm you will have cached records that only have old signature on them which are being returned to down stream validators and their is no syncronisation of record expiry. You may have a old DNSKEY set and new signatures on other records in the zone or you may have the new DNSKEY set and old signatures on other records in the zone. The validator has to work under both circumstances. The only RRset that it is possible to perform this consistancy check on is the DNSKEY RRset itself and both algorithms exist in the RRSIGs. ; DiG 9.10.0pre-alpha +dnssec dfas.mil dnskey +multi ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 51859 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dfas.mil. IN DNSKEY ;; ANSWER SECTION: dfas.mil. 25300 IN DNSKEY 257 3 7 ( AwEAAXLZgixJU1KVrdcv+evwuKlDFDmUQR7FsC2zghPU mERiPR9wwgpuKdkQ6BQizeObACqfUwepXuBp1b3t0480 Oyn7OlCaaV+M/O1hH5pkCaRV69iVuWRqPAXfCu6XvHUz xL2ugzwr+uYeGrRLfDNsZ1VN/b1zc33c2qdepPbcMDv7 8ZzXlgy1DJ6DjylOQx7Jm/5uKQiA6sA+W9ViZTHZ9BX9 9mQcaRqFzY4eVCGid7sgrD71hTxSOnK3b1B1gQEv8CCP eZwFsCOG2/9ToTXRxRP1dvIHoWkEEGHy2czb2FbGrfiW sRF1uVwoMJRX28D4QndyFy1yWLOMKh0DNyjyePc= ) ; KSK; alg = NSEC3RSASHA1; key id = 4069 dfas.mil. 25300 IN DNSKEY 256 3 8 ( AwEAAeIV8hHiYnEiREniwiz5NkAP2yuklG9b0iEBCij0 F/1Z//Yps0Kk3ss9DprQXqs5MlyCwVJZ1JOIlTe3dlhW +fiTBGnSlo/VeBJIfflMAdbzQh7ls9mesdr2kOyjgZzg iO8snht0kGYYlr3Qa+4zvSi4p7uJ7oMYEVc7OD13P2PN 2pM+lwGgB78m9BXLcibw6GBiqVL2M7sY3j0BV1Zbzjd6 /lEWN1QVktueetc1PfTco9RiJ7vnkw9VpI/FtaKQLDIp YWCRPOUoUxLk/ji5r3jez8zQbbe8VxjuH+hyMvb69GMd k6Y88vskrCotECqbG/TijhPnDjhfJ0IWY5Kj8Mk= ) ; ZSK; alg = RSASHA256; key id = 8389 dfas.mil. 25300 IN DNSKEY 256 3 8 ( AwEAAXzmgOtId7xGSjccxMfW8WlEEJKH7GTnzD58VqhF 2CJBN0eiyKFxQVwmSdrr9TG/mCVTbAH7RGAP/R3pYxhB fBybZp+WwlryBSQIeWpgLFwwv4oLlKxopcpsFcG23Oh5 BxTuBPW/NCWSu6deGpkA4WQP275Q0gRwjlBKZtD3b8wD PsRhL9TsxsYNzLELIW2dnE82YcZB22XVyV0NVbNE1Ks0 S6oZznxXCp3d2lVw8ImgVm2hCD0c9EZUi7pYf6NedMVH mxI5t/JGC22z0Z1/zmQu3z76ZsEhl/uetzSqK9VczmZ3 JPNNbOtyQHf23lne33mxnZaAuTn81sGLyaVLS6s=
Re: Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both
On 2 Aug 2013 at 22:25, Mark Andrews wrote: In message 51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov, Scott Morizot wri tes: Hello all, I ran into an interesting situation resolving dfas.mil. It appears that they have attempted to roll their ZSKs to algorithm 8 while leaving their KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for each record set in the zone MUST include at least one RRSIG for each algorithm. (The distinction between KSK and ZSK is an operational convenience and not part of the standard, per se.) The relevant excerpt from Section 2.2 of RFC 4035: There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). Because the requirement is *only* on the signer. You will note that the validator is NOT required to check for this as part of the list of things it is supposed to check for and that is a deliberate design decision. If the signer follows this and the timing rules the zone will not be treated as bogus. The unbound developers didn't realise this initially and added unspecified checks to their validator. I hadn't noticed the differences between 2.2 and 5.3. Interesting. So you can have signing errors (at least according to the standard) that don't result in validation errors. Thanks, Scott ___ 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: Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both
In message 51fbad70.9183.445a...@tmorizot.sd.is.irs.gov, Scott Morizot writes: On 2 Aug 2013 at 22:25, Mark Andrews wrote: In message 51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov, Scott Morizot wri tes: Hello all, I ran into an interesting situation resolving dfas.mil. It appears that they have attempted to roll their ZSKs to algorithm 8 while leaving their KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for each record set in the zone MUST include at least one RRSIG for each algorithm. (The distinction between KSK and ZSK is an operational convenience and not part of the standard, per se.) The relevant excerpt from Section 2.2 of RFC 4035: There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). Because the requirement is *only* on the signer. You will note that the validator is NOT required to check for this as part of the list of things it is supposed to check for and that is a deliberate design decision. If the signer follows this and the timing rules the zone will not be treated as bogus. The unbound developers didn't realise this initially and added unspecified checks to their validator. I hadn't noticed the differences between 2.2 and 5.3. Interesting. So you can have signing errors (at least according to the standard) that don't result in validation errors. The point of 2.2 was to ensure that the necessary RRSIGs were all generated so that it doesn't matter what combination of algorithms the validator supports. A validator only requires a single signature to exist for the RRset to validate. Yes this is asymetric but it allows DNSSEC to work with caches getting answers from different versions of the zone. Failure to follow 2.2, unless you know exactly what you are doing, will result in some validators treating the answers as bogus. Writing down those rules would have been extremely complicated and the WG decided to apply the KISS principle. Note even if you think you are talking to the master server you may be talking to a slave which has a older copy of the zone. There is *no* way to check if records being return are coming from the same version of the zone that signed the DNSKEY RRset. Mark Thanks, Scott ___ 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: How to get AD flag
On Fri, Aug 02, 2013 at 10:49:22AM +0530, rams brames...@gmail.com wrote a message of 41 lines which said: I have 9.7 bind installed and configured recursive. When i query against forwader i am not getting AD flag. Could you please guide me how to get AD flag. Several possible reasons: 1) Unsigned domain. Are you sure you test with a signed domain such as ietf.org, afnic.fr or nlnetlabs.nl? 2) Broken forwarder (strip the signatures or something like that). Try without it. 3) Wrong anchor (DNS root key). Do you have a trusted-keys or managed-keys directive and what does it contain? remaining answer is correct for signed query I would prefer that you copy-and-paste this answer. How do you know it is correct? (See suggestions 1 and 2) ___ 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: Internernal view is answering to external ping
Many use ping to check DNS issues but doing so brings in another factor: the client's os/resolver/caching. The 'dig' utility aims to work around this. If 'dig' (to the DNS server's numeric address) and 'ping' DNS resolutions differ, you have good evidence it is a client issue. On the other hand if both give the same unwanted answer, you have evidence it is a server configuration issue. John Wobus Cornell University IT ___ 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: How to get AD flag
On 8/1/13 10:48 PM, rams wrote: Thanks david, This the response i get dig +short rs.dns-oarc.net http://rs.dns-oarc.net txt @forwarderip rst.x3827.rs.dns-oarc.net http://rst.x3827.rs.dns-oarc.net. rst.x3837.x3827.rs.dns-oarc.net http://rst.x3837.x3827.rs.dns-oarc.net. rst.x3843.x3837.x3827.rs.dns-oarc.net http://rst.x3843.x3837.x3827.rs.dns-oarc.net. 50.16.87.189 sent EDNS buffer size 4096 50.16.87.189 DNS reply size limit is at least 3843 bytes That looks OK, but the forwarder might still be broken (i.e., it might strip replies). Stephane Bortzmeyer's three possibilities are all plausible. I'd recommend beginning with queries of known-valid domains (e.g., ietf.org, isc.org) against known-valid resolvers (e.g., 8.8.8.8) and then working from there. dn ___ 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: Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both
On Fri, Aug 2, 2013 at 5:25 AM, Mark Andrews ma...@isc.org wrote: In message 51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov, Scott Morizot wri tes: The BIND 9 resolver returns an answer with the AD bit set. Unbound returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the only three nameservers I've tested. Version 1.4.8 onwards should validate the zone. Earlier versions were broken. http://www.unbound.net/documentation/info_algo.html Actually, while unbound has loosened their requirements as per the reference above, they are still stricter than BIND--and RFC for that matter, though the basis for their strictness is actually lack of specification for some circumstances. There was a recent thread on the unbound-users mailing list on just this topic and the same DNS name (though I can't seem to get to the site over v4 or v6 at the moment to reference it). RFC 6840 (DNSSEC clarifications) says the following, paraphrased from section 5.11: - all the algorithms in the DS RRset must be present in the DNSKEY RRset - addition algorithms are allowed in the DNSKEY RRset, but not vice-versa - the zone RRsets must be signed by all algorithms in the DNSKEY RRset - a validator must support any valid path (i.e., don't require that a path with all algorithms) dfas.mil is violating the third rule above, which could potentially hinder some implementations from creating a chain of trust all the way to the RRset. unbound (capable of both algorithms in the DNSKEY RRset) is violating the fourth rule above. The second rule above is what creates the apparent underspecification. What about validators that don't support the algorithm with which the (extra) RRset is signed? Insecure delegations happen at the zone cut, not mid-zone. A delegation might be secure because the algorithm at the DS is understood, but if an additional algorithm from the DNSKEY RRset is used to exclusively sign an RRset, the behavior is undefined. IMO, the outcome would need to be bogus (as opposed to insecure), but it's simply not defined. Casey ___ 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: Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both
In message CAEKtLiT9=m1nbfjq2ormrdqr2uprjhcx9lznkxsytzv4tdj...@mail.gmail.com , Casey Deccio writes: On Fri, Aug 2, 2013 at 5:25 AM, Mark Andrews ma...@isc.org wrote: In message 51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov, Scott Morizot wri tes: The BIND 9 resolver returns an answer with the AD bit set. Unbound returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the only three nameservers I've tested. Version 1.4.8 onwards should validate the zone. Earlier versions were broken. http://www.unbound.net/documentation/info_algo.html Actually, while unbound has loosened their requirements as per the reference above, they are still stricter than BIND--and RFC for that matter, though the basis for their strictness is actually lack of specification for some circumstances. There was a recent thread on the unbound-users mailing list on just this topic and the same DNS name (though I can't seem to get to the site over v4 or v6 at the moment to reference it). RFC 6840 (DNSSEC clarifications) says the following, paraphrased from section 5.11: - all the algorithms in the DS RRset must be present in the DNSKEY RRset - addition algorithms are allowed in the DNSKEY RRset, but not vice-versa - the zone RRsets must be signed by all algorithms in the DNSKEY RRset - a validator must support any valid path (i.e., don't require that a path with all algorithms) dfas.mil is violating the third rule above, which could potentially hinder some implementations from creating a chain of trust all the way to the RRset. unbound (capable of both algorithms in the DNSKEY RRset) is violating the fourth rule above. The listed requirement is the signer signs with all key algorithms. This is per instance of the zone. There is no requirement that all visible sources of zone have signature for all key algorithms published in all visible instances of the zone. There is no requirement that one apparent source of the zone present a single instance of the zone only that a single answer comes from a single instance. Unless you can see the full contents of a instance (i.e. be able to transfer the zone) of the zone you cannot check if the signer is correctly operating or not. There is no other way. The second rule above is what creates the apparent underspecification. What about validators that don't support the algorithm with which the (extra) RRset is signed? The ignore those records. They DO NOT care if they are there or not. Insecure delegations happen at the zone cut, not mid-zone. Correct. A delegation might be secure because the algorithm at the DS is understood, but if an additional algorithm from the DNSKEY RRset is used to exclusively sign an RRset, the behavior is undefined. IMO, the outcome would need to be bogus (as opposed to insecure), but it's simply not defined. Which is why there is a requirement on the signer. There is no requirement on the validator to check that the signer did the correct thing. If a signer makes this mistake then some validators will treat the records being signed as good (those that support both algorithms) and some will treat it as bogus (those that only support the algorithm in the DS set). You would like to see consistancy when rules are not followed. The specification does not give that and does not require that. It is designed to give consistency when the rules are followed. In this instance all the records in dfas.mil are signed with algorithm 7. The DS records are for algorithm 7. There are algorithm 7 and 8 dnskey records visible. A validator that only supports algorithm 8 treats this zone as insecure as there is no DS record which lists agorithm 8. A validator that only supports algorithm 7 treats this zone as secure as there is a DS record that lists algorithm 7. It expects to see RRSIGs with algorithm 7. A validator that supports algorithm 7 and 8 treats this zone as secure as there is a DS record that lists algorithm 7. It expects to see RRSIGs with algorithm 7. If the validator is operating correctly will pass the answers from this zone. The operator of the zone is required to wait until all caches are clear of answers which only contain algorithm 7 records before publishing a DS record with algorithm 8. Mark -- 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: How to get AD flag
On Aug 2, 2013, at 11:35 AM, David Newman dnew...@networktest.com wrote: That looks OK, but the forwarder might still be broken (i.e., it might strip replies). If this were the case and the resolver is correctly configured with a root anchor then all attempted validation (from the root down) would result in SERVFAIL. I'm going with misconfigured resolver for 1000. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: How to get AD flag
On Aug 2, 2013, at 9:19 PM, Alan Clegg a...@clegg.com wrote: On Aug 2, 2013, at 11:35 AM, David Newman dnew...@networktest.com wrote: That looks OK, but the forwarder might still be broken (i.e., it might strip replies). If this were the case and the resolver is correctly configured with a root anchor then all attempted validation (from the root down) would result in SERVFAIL. I'm going with misconfigured resolver for 1000. Or, on a second (third?) reading of the original problem, very possibly a missing DS record in the parent of the zone in question, but we don't really know enough at this point. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
