Does anyone have DNSSEC problem with uscg.mil

Marc Lampo marc.lampo.ietf at gmail.com
Fri Nov 15 06:51:18 UTC 2013


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 <rkoberman at gmail.com> wrote:

> On Thu, Nov 14, 2013 at 11:19 AM, Marc Lampo <marc.lampo.ietf at 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.Khuu at 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.Khuu at ssa.gov <Linh.Khuu at ssa.gov>*
>>>
>>>
>>>
>>> *From:* Marc Lampo [mailto:marc.lampo.ietf at 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.Khuu at 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.Khuu at 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: rkoberman at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20131115/7149d953/attachment-0001.html>


More information about the bind-users mailing list