Interesting - like other respondent already observed : with or without AD flag set ?
Anyhow, I redid the query with a validating Bind 9.8 in the office : $ dig @127.0.0.1 mx uscg.mil. +dnssec ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @127.0.0.1 mx uscg.mil. +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4486 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1 Observe : AD bit set, 10 answers (and no warnings in the name server log file) Kind regards, On Thu, Nov 14, 2013 at 10:29 PM, Kevin Oberman <rkober...@gmail.com> wrote: > On Thu, Nov 14, 2013 at 11:19 AM, Marc Lampo <marc.lampo.i...@gmail.com>wrote: > >> Hello, >> >> dnsstuff.com gives me all green for DNSSEC of uscg.mil. >> dnsviz.net gives warnings (not : errors) on all RRSIG's - something with >> TTL values. >> >> What is odd - but should not be fatal - is that uscg.mil authoritative >> name servers send replies with "strange" TTL values. >> 1) uscg.mil. 77481 IN MX 40 >> smtp-gateway-4.uscg.mil. >> 2) uscg.mil. 77439 IN MX 40 >> smtp-gateway-4.uscg.mil. >> --> TTL is decreasing for that RR >> (strangely enough, TTL does not decrease for other RR's in the RRset, >> and consequently : different the one shown above) >> >> Now the RRSIG over the MX RRset says the TTL in the zone file is 86400 : >> uscg.mil. 80850 IN RRSIG MX 7 2 86400 ... >> >> Although weird : >> 1) TTL values of all RR's in the RRset should be identical >> 2) the authoritative name server partly behaves like it were replying >> from cache >> these abnormalities should not be fatal, in my opinion. >> >> I wonder what kind of name servers uscg.mil uses ? >> >> Kind regards, >> >> >> >> On Thu, Nov 14, 2013 at 7:22 PM, Khuu, Linh Contractor <linh.k...@ssa.gov >> > wrote: >> >>> *Hi Marc,* >>> >>> >>> >>> *Yes, on my DNS server, if I do a dig @8.8.8.8 <http://8.8.8.8>, I got >>> answer (with AD bit set). I also do a dig @pac1.nipr.mil >>> <http://pac1.nipr.mil>, I got answer (with AA bit set).* >>> >>> >>> >>> *However, when I do dig @localhost, that is where I don’t get any result >>> at all.* >>> >>> >>> >>> *All the DNSSEC tools out there, like dnsviz.net <http://dnsviz.net>, >>> dnsstuff.com <http://dnsstuff.com>, dnscheck.iis.se >>> <http://dnscheck.iis.se>, they all show DNSSEC error for uscg.mil >>> <http://uscg.mil>.* >>> >>> >>> >>> >>> >>> >>> >>> >>> *Linh Khuu Network Security SpecialistNorthrop Grumman IS | Civil >>> Systems Division (CSD)Office: 410-965-0746 <410-965-0746>Pager: >>> 443-847-7551 <443-847-7551> Email: linh.k...@ssa.gov <linh.k...@ssa.gov>* >>> >>> >>> >>> *From:* Marc Lampo [mailto:marc.lampo.i...@gmail.com] >>> *Sent:* Thursday, November 14, 2013 1:16 PM >>> *To:* Khuu, Linh Contractor >>> *Cc:* Bind Users Mailing List >>> *Subject:* Re: Does anyone have DNSSEC problem with uscg.mil >>> >>> >>> >>> Not at this moment : >>> $ dig @8.8.8.8 mx uscg.mil. +dnssec >>> >>> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @8.8.8.8 mx uscg.mil. +dnssec >>> ; (1 server found) >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42506 >>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags: do; udp: 512 >>> ;; QUESTION SECTION: >>> ;uscg.mil. IN MX >>> >>> ;; ANSWER SECTION: >>> uscg.mil. 8478 IN MX 40 >>> smtp-gateway-4.uscg.mil. >>> uscg.mil. 8478 IN MX 40 >>> smtp-gateway-4a.uscg.mil. >>> uscg.mil. 8478 IN MX 10 >>> smtp-gateway-2.uscg.mil. >>> uscg.mil. 8478 IN MX 20 >>> smtp-gateway-5a.uscg.mil. >>> uscg.mil. 8478 IN MX 10 >>> smtp-gateway-1.uscg.mil. >>> uscg.mil. 8478 IN MX 20 >>> smtp-gateway-5.uscg.mil. >>> uscg.mil. 8478 IN MX 10 >>> smtp-gateway-1a.uscg.mil. >>> uscg.mil. 8478 IN MX 10 >>> smtp-gateway-2a.uscg.mil. >>> uscg.mil. 8478 IN RRSIG MX 7 2 86400 >>> 20131118074336 20131113074105 53369 uscg.mil. F... >>> >>> Observe : AD bit set. >>> >>> Kind regards, >>> >>> >>> >>> On Thu, Nov 14, 2013 at 7:00 PM, Khuu, Linh Contractor < >>> linh.k...@ssa.gov> wrote: >>> >>> Hi, >>> >>> Does anyone have any DNSSEC problem with uscg.mil. >>> >>> On our DNS servers, we have seen broken trust chain error and the >>> validation failed. >>> >>> 14-Nov-2013 12:57:37.486 lame-servers: error (broken trust chain) >>> resolving 'uscg.mil/A/IN': 199.211.218.6#53 >>> 14-Nov-2013 12:57:37.573 lame-servers: error (broken trust chain) >>> resolving 'uscg.mil/A/IN': 199.211.218.6#53 >>> 14-Nov-2013 12:57:37.658 lame-servers: error (broken trust chain) >>> resolving 'uscg.mil/MX/IN': 199.211.218.6#53 >>> 14-Nov-2013 12:57:37.743 lame-servers: error (broken trust chain) >>> resolving 'uscg.mil/MX/IN': 199.211.218.6#53 >>> >>> 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: >>> uscg.milAAAA: in authvalidated >>> 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: >>> uscg.milAAAA: authvalidated: got broken trust chain >>> 14-Nov-2013 12:58:12.878 dnssec: debug 3: validating @23cee638: >>> uscg.milAAAA: resuming nsecvalidate >>> 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: >>> starting >>> 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: >>> attempting positive response validation >>> 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: >>> in fetch_callback_validator >>> 14-Nov-2013 12:58:13.058 dnssec: debug 3: validating @23cee638: uscg.milA: >>> fetch_callback_validator: got failure >>> 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: >>> starting >>> 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: >>> attempting positive response validation >>> 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: >>> in fetch_callback_validator >>> 14-Nov-2013 12:58:13.233 dnssec: debug 3: validating @23cee638: uscg.milMX: >>> fetch_callback_validator: got failure >>> >>> Thanks, >>> Linh Khuu >>> Network Security Specialist >>> Northrop Grumman IS | Civil Systems Division (CSD) >>> Office: 410-965-0746 >>> Pager: 443-847-7551 >>> Email: linh.k...@ssa.gov >>> >>> > Don't forget that Google will white-list domains with known (by them) > broken DNSSEC and reply even though validation is broken, so using 8.8.8.8 > for checking on whether validation is broken is not the best idea. > -- > R. Kevin Oberman, Network Engineer > E-mail: rkober...@gmail.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
