Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-22 Thread Warren Kumari 
On Wed, Oct 19, 2022 at 4:38 AM, Scott Morizot  wrote:

> On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček  wrote:
>
>> Code is your guide :-)
>>
>
> Agreed. Any time I have a need to drill down and understand exactly what
> is happening and source code is available, that is always where I look
> first.
>


Weell… I think that the way it *should* work is: When you need to
understand how something works you read the fine RFCs… and when it doesn't
work like that, you read the code and say "See, over here in line 42 of
foozlewargh.c you are checking if bar <= 17, and you *should* be checking
if bar == 17."

Yes, I know, I know… but I did say "the way it *should* work"...

W



>
>> Now seriously: I don't think documenting it neither
>> a) necessary
>> b) good idea
>>
>
> Comments in the code are always helpful. ;-) But yes, beyond that trying
> to capture specific mechanisms rather than what is being accomplished in
> the documentation is often counter-productive.
>
>
>> It can change between versions, and we certainly do not want people to
>> depend on particular behavior. We want people to follow protocol!
>>
>
> Yep. And in this instance, I haven't found the protocol standard
> ambiguous. Once the chain of trust is broken through a valid insecure
> delegation, it can only be reestablished by a trust anchor for a zone
> farther down the hierarchy. In earlier days, before the root zone was
> signed or when there were gaps in the chain, such lower level trust anchors
> were more common for early adopters. These days, people mostly just use the
> root trust anchor so once there's a point where the chain of trust shifts
> to insecure it remains insecure for everyone for subsequent delegations. A
> DS record can only establish a secure delegation when placed in a secure
> zone. Putting one in an insecure zone does nothing for the security status
> of the delegated zone. A resolver would require a trust anchor for it to
> establish security.
>
> So the controlling point from a DNSSEC perspective is the insecure status
> of fiscal.treasury.gov.
>
> DNSVIZ captures it. The red lines note that the RRSIGs for the entries in
> fiscal.treasury.gov are no good. (I have no insight into why they are
> being generated, but it's likely a misconfiguration somewhere.) But the
> records themselves, like the delegation, are clearly marked insecure. At
> that juncture, everything below fiscal.treasury.gov becomes insecure
> unless a resolver has a trust anchor for a lower level zone.
>
> https://dnsviz.net/d/fiscal.treasury.gov/dnssec/
>
> The DS query correctly validates the non-existence of a DS record in the
> secure parent zone, treasury.gov. They should clean up the fiscal.
> treasury.gov zone and fix whatever is generating the spurious and invalid
> DNSSEC records in it. But the presence of those records should have no
> impact on validation since the zone itself is insecure. They also really
> should migrate at least to algorithm 8 and remove the SHA-1 DS record for
> treasury.gov from .gov. But none of those items actually break anything.
>
> dig @ns1.treasury.gov fiscal.treasury.gov ds +multiline +dnssec +norecurse
>
> ; <<>> DiG 9.16.28 <<>> @ns1.treasury.gov fiscal.treasury.gov ds
> +multiline +dnssec +norecurse
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;fiscal.treasury.gov.   IN DS
>
> ;; AUTHORITY SECTION:
> treasury.gov.   900 IN SOA ns1.treasury.gov. ecb-hosting.fiscal.
> treasury.gov. (
> 2001180551 ; serial
> 3600   ; refresh (1 hour)
> 900; retry (15 minutes)
> 1209600; expire (2 weeks)
> 900; minimum (15 minutes)
> )
> treasury.gov.   900 IN RRSIG SOA 7 2 900 (
> 20221023094202 20221016084202 3908
> treasury.gov.
>
> J0M3CKVGn+KAUhQ086q4tuAlA9HpoUQRVjfwP67wC/RO
>
> HTvSldVFCnKEV0QfTBnb8Z+bCU421PtMTjeI66efgPrc
>
> agp2BcggozZyMkonypTRJ4CW63JabXxy5RtSFq1jnTdf
> zNz2TK+yhfelkV1e3FN4uJmT2rcwcaQToOEYCzM= )
> mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN NSEC3 1 0 1
> 16EBC108F10FE696 (
> MTA7ICVE5V8C9RQJ08UR3QEO9TPP6L6T
> NS RRSIG )
> mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN RRSIG NSEC3 7 3 900
> (
> 20221026090448 20221019080448 3908
> treasury.gov.
>
> ng8mTUN469dzduIYeUWNcVJJlnRLnH8C7OA5J3ysjk+8
>
> X1yX0/CONnMmlztKL1zwCstgv6L9xr8aUJW9Z/Bn/CtI
>
> whh9ymeJ0lXQzXzg6Fi7RmeSHl9Ecu1789FrbuPQF+tA
> bwTcddJ29fDG9lgx4F8JvnzVxeHk4TqOh171Fhs= )

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-19 Thread Scott Morizot 
On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček  wrote:

> Code is your guide :-)
>

Agreed. Any time I have a need to drill down and understand exactly what is
happening and source code is available, that is always where I look first.


> Now seriously: I don't think documenting it neither
> a) necessary
> b) good idea
>

Comments in the code are always helpful. ;-) But yes, beyond that trying to
capture specific mechanisms rather than what is being accomplished in the
documentation is often counter-productive.


> It can change between versions, and we certainly do not want people to
> depend on particular behavior. We want people to follow protocol!
>

Yep. And in this instance, I haven't found the protocol standard ambiguous.
Once the chain of trust is broken through a valid insecure delegation, it
can only be reestablished by a trust anchor for a zone farther down the
hierarchy. In earlier days, before the root zone was signed or when there
were gaps in the chain, such lower level trust anchors were more common for
early adopters. These days, people mostly just use the root trust anchor so
once there's a point where the chain of trust shifts to insecure it remains
insecure for everyone for subsequent delegations. A DS record can only
establish a secure delegation when placed in a secure zone. Putting one in
an insecure zone does nothing for the security status of the delegated
zone. A resolver would require a trust anchor for it to establish security.

So the controlling point from a DNSSEC perspective is the insecure status
of fiscal.treasury.gov.

DNSVIZ captures it. The red lines note that the RRSIGs for the entries in
fiscal.treasury.gov are no good. (I have no insight into why they are being
generated, but it's likely a misconfiguration somewhere.) But the records
themselves, like the delegation, are clearly marked insecure. At that
juncture, everything below fiscal.treasury.gov becomes insecure unless a
resolver has a trust anchor for a lower level zone.

https://dnsviz.net/d/fiscal.treasury.gov/dnssec/

The DS query correctly validates the non-existence of a DS record in the
secure parent zone, treasury.gov. They should clean up the
fiscal.treasury.gov zone and fix whatever is generating the spurious and
invalid DNSSEC records in it. But the presence of those records should have
no impact on validation since the zone itself is insecure. They also really
should migrate at least to algorithm 8 and remove the SHA-1 DS record for
treasury.gov from .gov. But none of those items actually break anything.

dig @ns1.treasury.gov fiscal.treasury.gov ds +multiline +dnssec +norecurse

; <<>> DiG 9.16.28 <<>> @ns1.treasury.gov fiscal.treasury.gov ds +multiline
+dnssec +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;fiscal.treasury.gov.   IN DS

;; AUTHORITY SECTION:
treasury.gov.   900 IN SOA ns1.treasury.gov.
ecb-hosting.fiscal.treasury.gov. (
2001180551 ; serial
3600   ; refresh (1 hour)
900; retry (15 minutes)
1209600; expire (2 weeks)
900; minimum (15 minutes)
)
treasury.gov.   900 IN RRSIG SOA 7 2 900 (
20221023094202 20221016084202 3908
treasury.gov.
J0M3CKVGn+KAUhQ086q4tuAlA9HpoUQRVjfwP67wC/RO
HTvSldVFCnKEV0QfTBnb8Z+bCU421PtMTjeI66efgPrc
agp2BcggozZyMkonypTRJ4CW63JabXxy5RtSFq1jnTdf
zNz2TK+yhfelkV1e3FN4uJmT2rcwcaQToOEYCzM= )
mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN NSEC3 1 0 1
16EBC108F10FE696 (
MTA7ICVE5V8C9RQJ08UR3QEO9TPP6L6T
NS RRSIG )
mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN RRSIG NSEC3 7 3 900 (
20221026090448 20221019080448 3908
treasury.gov.
ng8mTUN469dzduIYeUWNcVJJlnRLnH8C7OA5J3ysjk+8
X1yX0/CONnMmlztKL1zwCstgv6L9xr8aUJW9Z/Bn/CtI
whh9ymeJ0lXQzXzg6Fi7RmeSHl9Ecu1789FrbuPQF+tA
bwTcddJ29fDG9lgx4F8JvnzVxeHk4TqOh171Fhs= )
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-19 Thread Petr Špaček 

On 18. 10. 22 17:58, Viktor Dukhovni wrote:

By the way is the validation workflow used in BIND written up somewhere
as a separate document, or are the comments in the code the best way to
understand how BIND validates names below a trust anchor (finding either
a valid signature or an insecure delegation).


Code is your guide :-)

Now seriously: I don't think documenting it neither
a) necessary
b) good idea

It can change between versions, and we certainly do not want people to 
depend on particular behavior. We want people to follow protocol!


--
Petr Špaček
Internet Systems Consortium

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Mark Andrews 



> On 18 Oct 2022, at 17:02, Viktor Dukhovni  wrote:
> 
> On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@pumpky.net wrote:
> 
>> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
>> pretty clearly a problem,
>> 
>> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
> 
> DNSViz struggles to display this properly, because the same underlying
> nameservers serve both the parent and child zone, and instead of
> referrals serves authoritative data from the child.  However, the
> parent zone is signed, and the child zone is not.  A resolver
> expecting signed answers from the parent sees unsigned answers
> instead and is liable to get confused.
> 
>> What it looks like to me is that everything [below] fiscal.treasury.gov is 
>> supposed to be insecure (unsigned). There is a zone cut at 
>> fiscal.treasury.gov, but it is not properly delegated in DNSSEC. The 
>> servers are signing above the cut with the treasury.gov ZSK, but there 
>> are no DS records in the parent or the DNSKEY records in the 
>> fiscal.treasury.gov apex. Thus, the responses are seen as BOGUS.
> 
> Close, but not quite.  Explicit DS queries to the parent in fact
> elicit a valid denial of existence:
> 
>$ dig +dnssec -t ds fiscal.treasury.gov @ns1.treasury.gov +norecur +nocl 
> +nottl +noall +nocrypto +question +ans +auth
>;fiscal.treasury.gov.   IN DS
>treasury.gov.   SOA ns1.treasury.gov. 
> ecb-hosting.fiscal.treasury.gov. 2001180551 3600 900 1209600 900
>treasury.gov.   RRSIG   SOA 7 2 900 20221022031023 20221015021023 
> 3908 treasury.gov. [omitted]
>4u954er66u6qum644o2088ircof2kt1g.treasury.gov. NSEC3 1 0 1 
> DADE5BC724805E45 4U954ER66U6QUM644O2088IRCOF2KT1H NS RRSIG
>4u954er66u6qum644o2088ircof2kt1g.treasury.gov. RRSIG NSEC3 7 3 900 
> 20221025022736 20221018012736 3908 treasury.gov. [omitted]

Actually the bit map is incorrect RRSIG should not be present unless the DS is 
present.  An insecure delegation only has NS where as a secure delegation has 
NS, DS and RRSIG.  The exception to this is
when there is a KEY RRset present (yes, they can exist on the parent and child 
sides of a delegation
independently of each other). 

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Casey Deccio 

> On Oct 18, 2022, at 4:02 PM, Scott Morizot  wrote:
> 
> I can't say why any RRSIGs or other DNSSEC records are being returned for 
> queries for records in fiscal.treasury.gov , 
> however those records are spurious. As DNSVIZ does show, the delegation from 
> the last secure zone, treasury.gov , to 
> fiscal.treasury.gov  is insecure. And thus the 
> subsequent delegation from fiscal.treasury.gov  
> to igt.fiscal.treasury.gov  is also 
> insecure. Once the chain of trust is properly broken and the status moves to 
> insecure, everything below that point is also insecure.
> 
> DNSVIZ is attempting to make some sense of the spurious DNSSEC records and 
> show what the state would be if there weren't an insecure delegation at 
> treasury.gov . Or at least that's my guess at what it's 
> doing.

I agree with both points.  I just don't know what's going on.  As it turns out, 
writing a piece of software to try to visualize complex configurations is, um, 
complex.  I'll add it to my list.  Just know that I'm a little behind... :)

Casey___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Scott Morizot 
There's a validated insecure delegation from treasury.gov to
fiscal.treasury.gov.

I can't say why any RRSIGs or other DNSSEC records are being returned for
queries for records in fiscal.treasury.gov, however those records are
spurious. As DNSVIZ does show, the delegation from the last secure zone,
treasury.gov, to fiscal.treasury.gov is insecure. And thus the subsequent
delegation from fiscal.treasury.gov to igt.fiscal.treasury.gov is also
insecure. Once the chain of trust is properly broken and the status moves
to insecure, everything below that point is also insecure.

DNSVIZ is attempting to make some sense of the spurious DNSSEC records and
show what the state would be if there weren't an insecure delegation at
treasury.gov. Or at least that's my guess at what it's doing.

I haven't found any public resolver or other implemented validator that
doesn't properly validate qa.ws.igt.fiscal.treasury.gov as insecure.

Scott


On Tue, Oct 18, 2022, 15:35 Casey Deccio  wrote:

> > On Oct 18, 2022, at 1:58 PM, Mark Andrews  wrote:
> >
> > Not for DS  as it is part of the parent zone.
> >
>
> Right.  What I meant (but didn't say) was this:
>
> The following is a query for testing for the presence of a DS record in
> the igt.fiscal.treasury.gov zone.  The signer for the records in the
> response should be the parent zone of igt.fiscal.treasury.gov, which is
> fiscal.treasury.gov.  However, the the signer for the records in the
> observed response is treasury.gov.
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Casey Deccio 
> On Oct 18, 2022, at 1:58 PM, Mark Andrews  wrote:
> 
> Not for DS  as it is part of the parent zone. 
> 

Right.  What I meant (but didn't say) was this:

The following is a query for testing for the presence of a DS record in the 
igt.fiscal.treasury.gov zone.  The signer for the records in the response 
should be the parent zone of igt.fiscal.treasury.gov, which is 
fiscal.treasury.gov.  However, the the signer for the records in the observed 
response is treasury.gov.

$ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4 == "RRSIG" 
{ print $12 }'
treasury.gov.
treasury.gov.

Casey

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Viktor Dukhovni 
On Wed, Oct 19, 2022 at 06:58:21AM +1100, Mark Andrews wrote:

> Not for DS  as it is part of the parent zone. 

But is not an "apex" DS query, the parent zone (if "igt" were delegated)
would surely be fiscal.treasury.gov.

> > $ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4 == 
> > "RRSIG" { print $12 }'
> > treasury.gov.
> > treasury.gov.
> > 
> > Because there is a zone cut at fiscal.treasury.gov, the the signer
> > should be fiscal.treasury.gov.  That being said, I can't tell
> > at-a-glance why DNSViz is drawing ZSK 3908 in the
> > fiscal.treasury.gov zone, rather than in the treasury.gov zone.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Viktor Dukhovni 


> >> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
> > 
> > DNSViz struggles to display this properly, because the same underlying
> > nameservers serve both the parent and child zone, and instead of
> > referrals serves authoritative data from the child.  However, the
> > parent zone is signed, and the child zone is not.  A resolver
> > expecting signed answers from the parent sees unsigned answers
> > instead and is liable to get confused.
> 
> The one clear issue that I see here is that the signer field in RRSIGs
> in responses from fiscal.treasury.gov is treasury.gov:
> 
> $ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4 == 
> "RRSIG" { print $12 }'
> treasury.gov.
> treasury.gov.

In more detail:

$ dig +dnssec +nocrypto +nocl +nottl +nocmd @ns1.treasury.gov 
igt.fiscal.treasury.gov ds
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50116
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;igt.fiscal.treasury.gov. IN DS

;; AUTHORITY SECTION:
fiscal.treasury.gov.SOA ns1.treasury.gov. 
ecb-hosting.fiscal.treasury.gov. 149240 3600 900 1209600 900
fiscal.treasury.gov.RRSIG   SOA 7 3 900 20221023235856 20221016225856 
3908 treasury.gov. [omitted]
f4s09eu1581gb4kordo869r2hnia9mah.treasury.gov. NSEC3 1 0 1 46A5FF83352054F7 
F4S09EU1581GB4KORDO869R2HNIA9MAI NS RRSIG
f4s09eu1581gb4kordo869r2hnia9mah.treasury.gov. RRSIG NSEC3 7 3 900 
20221025185901 20221018175901 3908 treasury.gov. [omitted]

> Because there is a zone cut at fiscal.treasury.gov, the the signer
> should be fiscal.treasury.gov.

That is defintely not kosher, given the SOA, there should of course be
no "treasury.gov" signatures for fiscal.treasury.gov names, and the NSEC
records are on the wrong side of the delegation...

> That being said, I can't tell at-a-glance why DNSViz is drawing ZSK
> 3908 in the fiscal.treasury.gov zone, rather than in the treasury.gov
> zone.

Given the conflicting signals, perhaps garbage in garbage out?

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Mark Andrews 
Not for DS  as it is part of the parent zone. 

-- 
Mark Andrews

> On 19 Oct 2022, at 06:52, Casey Deccio  wrote:
> 
> 
> 
>> On Oct 18, 2022, at 12:02 AM, Viktor Dukhovni  wrote:
>> 
>>> On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@pumpky.net wrote:
>>> 
>>> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
>>> pretty clearly a problem,
>>> 
>>> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
>> 
>> DNSViz struggles to display this properly, because the same underlying
>> nameservers serve both the parent and child zone, and instead of
>> referrals serves authoritative data from the child.  However, the
>> parent zone is signed, and the child zone is not.  A resolver
>> expecting signed answers from the parent sees unsigned answers
>> instead and is liable to get confused.
> 
> The one clear issue that I see here is that the signer field in RRSIGs in 
> responses from fiscal.treasury.gov is treasury.gov:
> 
> $ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4 == 
> "RRSIG" { print $12 }'
> treasury.gov.
> treasury.gov.
> 
> Because there is a zone cut at fiscal.treasury.gov, the the signer should be 
> fiscal.treasury.gov.  That being said, I can't tell at-a-glance why DNSViz is 
> drawing ZSK 3908 in the fiscal.treasury.gov zone, rather than in the 
> treasury.gov zone.
> 
> Casey
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Casey Deccio 



> On Oct 18, 2022, at 12:02 AM, Viktor Dukhovni  wrote:
> 
> On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@pumpky.net wrote:
> 
>> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
>> pretty clearly a problem,
>> 
>> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
> 
> DNSViz struggles to display this properly, because the same underlying
> nameservers serve both the parent and child zone, and instead of
> referrals serves authoritative data from the child.  However, the
> parent zone is signed, and the child zone is not.  A resolver
> expecting signed answers from the parent sees unsigned answers
> instead and is liable to get confused.

The one clear issue that I see here is that the signer field in RRSIGs in 
responses from fiscal.treasury.gov is treasury.gov:

$ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4 == "RRSIG" 
{ print $12 }'
treasury.gov.
treasury.gov.

Because there is a zone cut at fiscal.treasury.gov, the the signer should be 
fiscal.treasury.gov.  That being said, I can't tell at-a-glance why DNSViz is 
drawing ZSK 3908 in the fiscal.treasury.gov zone, rather than in the 
treasury.gov zone.

Casey
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Viktor Dukhovni 
On Tue, Oct 18, 2022 at 05:56:25PM +1100, Mark Andrews wrote:

> > However, resolvers generally don't send explicit DS queries.  Instead,
> > when the parent zone is signed, they set the DO bit and expect any
> > referrals to either include the signed DS records, or authenticated
> > denial of existence thereof.
> 
> What resolver doesn’t make DS queries?  BIND makes DS queries.  If you
> have reasonable testing insecure delegations (signed -> unsigned as well
> as signed -> signed (no DS)) from the same server should be part of your
> test suite.

Yes "generally" was the wrong word.  For one it seems that DNSViz is
not doing the right thing.  And I did observe problems problems via
CloudFlare yesterday, and guessed they were related.  Not able to
reproduce them just now.

By the way is the validation workflow used in BIND written up somewhere
as a separate document, or are the comments in the code the best way to
understand how BIND validates names below a trust anchor (finding either
a valid signature or an insecure delegation).

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Viktor Dukhovni 
On Tue, Oct 18, 2022 at 02:02:48AM -0400, Viktor Dukhovni wrote:

> However, resolvers generally don't send explicit DS queries.  Instead,
> when the parent zone is signed, they set the DO bit and expect any
> referrals to either include the signed DS records, or authenticated
> denial of existence thereof.

Perhaps "generally" is too strong, some do and some don't.  The
validator module in "libunbound" does in fact walk down the tree probing
for DS records:

...
[1666075678] libunbound[59247:0] info: prime trust anchor
[1666075678] libunbound[59247:0] info: generate keytag query _ta-4f66. NULL 
IN
[1666075678] libunbound[59247:0] info: resolving . DNSKEY IN
[1666075678] libunbound[59247:0] info: resolving _ta-4f66. NULL IN
[1666075678] libunbound[59247:0] info: response for . DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from <.> 2001:500:1::53#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validate keys with anchor(DS): 
sec_status_secure
[1666075678] libunbound[59247:0] info: Successfully primed trust anchor . 
DNSKEY IN
[1666075678] libunbound[59247:0] info: validated DS gov. DS IN
[1666075678] libunbound[59247:0] info: resolving gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: response for _ta-4f66. NULL IN
[1666075678] libunbound[59247:0] info: reply from <.> 199.9.14.201#53
[1666075678] libunbound[59247:0] info: query response was NXDOMAIN ANSWER
[1666075678] libunbound[59247:0] info: response for gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from  
2001:500:4431::2:30#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validated DNSKEY gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: validated DS treasury.gov. DS IN
[1666075678] libunbound[59247:0] info: resolving treasury.gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: response for treasury.gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from  
2610:108:3100:100a::20:53#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validated DNSKEY treasury.gov. 
DNSKEY IN
[1666075678] libunbound[59247:0] info: resolving fiscal.treasury.gov. DS IN
[1666075678] libunbound[59247:0] info: response for fiscal.treasury.gov. DS 
IN
[1666075678] libunbound[59247:0] info: reply from  
2610:108:3100:100a::20:53#53
[1666075678] libunbound[59247:0] info: query response was nodata ANSWER
[1666075678] libunbound[59247:0] info: NSEC3s for the referral proved no DS.
[1666075678] libunbound[59247:0] info: Verified that unsigned response is 
INSECURE
qa.ws.igt.fiscal.treasury.gov has address 199.169.199.63

While CloudFlare 1.1.1.1 sometimes fails to resolve the same name:

$ dig -t a @1.1.1.1 qa.ws.igt.fiscal.treasury.gov

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35710
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 34 37 6d 37 39 ("447m79")
; EDE: 12 (NSEC Missing): (failed to verify an insecure referral proof for 
fiscal.treasury.gov.)
;; QUESTION SECTION:
;qa.ws.igt.fiscal.treasury.gov. IN  A

and sometimes (different anycast location and cache content) succeeds:

$ dig -t a @1.1.1.1 qa.ws.igt.fiscal.treasury.gov

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46190
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 33 38 36 6d 31 32 37 ("386m127")
;; QUESTION SECTION:
;qa.ws.igt.fiscal.treasury.gov. IN  A

;; ANSWER SECTION:
qa.ws.igt.fiscal.treasury.gov. 30 INA   199.169.199.63

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Mark Andrews 


> On 18 Oct 2022, at 17:02, Viktor Dukhovni  wrote:
> 
> On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@pumpky.net wrote:
> 
>> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
>> pretty clearly a problem,
>> 
>> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
> 
> DNSViz struggles to display this properly, because the same underlying
> nameservers serve both the parent and child zone, and instead of
> referrals serves authoritative data from the child.  However, the
> parent zone is signed, and the child zone is not.  A resolver
> expecting signed answers from the parent sees unsigned answers
> instead and is liable to get confused.
> 
>> What it looks like to me is that everything [below] fiscal.treasury.gov is 
>> supposed to be insecure (unsigned). There is a zone cut at 
>> fiscal.treasury.gov, but it is not properly delegated in DNSSEC. The 
>> servers are signing above the cut with the treasury.gov ZSK, but there 
>> are no DS records in the parent or the DNSKEY records in the 
>> fiscal.treasury.gov apex. Thus, the responses are seen as BOGUS.
> 
> Close, but not quite.  Explicit DS queries to the parent in fact
> elicit a valid denial of existence:
> 
>$ dig +dnssec -t ds fiscal.treasury.gov @ns1.treasury.gov +norecur +nocl 
> +nottl +noall +nocrypto +question +ans +auth
>;fiscal.treasury.gov.   IN DS
>treasury.gov.   SOA ns1.treasury.gov. 
> ecb-hosting.fiscal.treasury.gov. 2001180551 3600 900 1209600 900
>treasury.gov.   RRSIG   SOA 7 2 900 20221022031023 20221015021023 
> 3908 treasury.gov. [omitted]
>4u954er66u6qum644o2088ircof2kt1g.treasury.gov. NSEC3 1 0 1 
> DADE5BC724805E45 4U954ER66U6QUM644O2088IRCOF2KT1H NS RRSIG
>4u954er66u6qum644o2088ircof2kt1g.treasury.gov. RRSIG NSEC3 7 3 900 
> 20221025022736 20221018012736 3908 treasury.gov. [omitted]
> 
>$ ldns-nsec3-hash -s DADE5BC724805E45 -t 1 fiscal.treasury.gov
>4u954er66u6qum644o2088ircof2kt1g.
> 
> However, resolvers generally don't send explicit DS queries.  Instead,
> when the parent zone is signed, they set the DO bit and expect any
> referrals to either include the signed DS records, or authenticated
> denial of existence thereof.

What resolver doesn’t make DS queries?  BIND makes DS queries.  If you
have reasonable testing insecure delegations (signed -> unsigned as well
as signed -> signed (no DS)) from the same server should be part of your
test suite.

> Here however, the auth nameserver has no way to know that you're
> expecting signed parent-side delegation answers, and answers
> authoritatively from the child perspective.  Such answers lack the
> requisite signatures.
> 
>> Now if our servers saw it as completely broken, I'd understand. But 
>> names above fiscal.treasury.gov sometimes work. Sometimes they don't. 
>> That's what's really confusing me.
> 
> Rather depends whether the denial of existence of DS records manages to
> make it into the resolver cache (via an explicit DS query perhaps).
> 
> This looks like a poorly understood corner case, serving a DNSSEC-signed
> zone and its child from the same server can work poorly, becase either
> no or the wrong signatures may accompany query replies.
> 
> The delegation NS records are not visible, and the DS records can only
> be discovered via explicit DS queries.  And when queries for an interior
> node or for other zone apex RRtypes are received, answers from the child
> perspective are all the more natural.
> 
> -- 
>Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-18 Thread Viktor Dukhovni 
On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@pumpky.net wrote:

> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
> pretty clearly a problem,
> 
> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/

DNSViz struggles to display this properly, because the same underlying
nameservers serve both the parent and child zone, and instead of
referrals serves authoritative data from the child.  However, the
parent zone is signed, and the child zone is not.  A resolver
expecting signed answers from the parent sees unsigned answers
instead and is liable to get confused.

> What it looks like to me is that everything [below] fiscal.treasury.gov is 
> supposed to be insecure (unsigned). There is a zone cut at 
> fiscal.treasury.gov, but it is not properly delegated in DNSSEC. The 
> servers are signing above the cut with the treasury.gov ZSK, but there 
> are no DS records in the parent or the DNSKEY records in the 
> fiscal.treasury.gov apex. Thus, the responses are seen as BOGUS.

Close, but not quite.  Explicit DS queries to the parent in fact
elicit a valid denial of existence:

$ dig +dnssec -t ds fiscal.treasury.gov @ns1.treasury.gov +norecur +nocl 
+nottl +noall +nocrypto +question +ans +auth
;fiscal.treasury.gov.   IN DS
treasury.gov.   SOA ns1.treasury.gov. 
ecb-hosting.fiscal.treasury.gov. 2001180551 3600 900 1209600 900
treasury.gov.   RRSIG   SOA 7 2 900 20221022031023 20221015021023 
3908 treasury.gov. [omitted]
4u954er66u6qum644o2088ircof2kt1g.treasury.gov. NSEC3 1 0 1 DADE5BC724805E45 
4U954ER66U6QUM644O2088IRCOF2KT1H NS RRSIG
4u954er66u6qum644o2088ircof2kt1g.treasury.gov. RRSIG NSEC3 7 3 900 
20221025022736 20221018012736 3908 treasury.gov. [omitted]

$ ldns-nsec3-hash -s DADE5BC724805E45 -t 1 fiscal.treasury.gov
4u954er66u6qum644o2088ircof2kt1g.

However, resolvers generally don't send explicit DS queries.  Instead,
when the parent zone is signed, they set the DO bit and expect any
referrals to either include the signed DS records, or authenticated
denial of existence thereof.

Here however, the auth nameserver has no way to know that you're
expecting signed parent-side delegation answers, and answers
authoritatively from the child perspective.  Such answers lack the
requisite signatures.

> Now if our servers saw it as completely broken, I'd understand. But 
> names above fiscal.treasury.gov sometimes work. Sometimes they don't. 
> That's what's really confusing me.

Rather depends whether the denial of existence of DS records manages to
make it into the resolver cache (via an explicit DS query perhaps).

This looks like a poorly understood corner case, serving a DNSSEC-signed
zone and its child from the same server can work poorly, becase either
no or the wrong signatures may accompany query replies.

The delegation NS records are not visible, and the DS records can only
be discovered via explicit DS queries.  And when queries for an interior
node or for other zone apex RRtypes are received, answers from the child
perspective are all the more natural.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

2022-10-17 Thread cjc+dns-oarc 
Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
pretty clearly a problem,


https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/

Trying to figure out the nature of the brokenness.

What it looks like to me is that everything above fiscal.treasury.gov is 
supposed to be insecure (unsigned). There is a zone cut at 
fiscal.treasury.gov, but it is not properly delegated in DNSSEC. The 
servers are signing above the cut with the treasury.gov ZSK, but there 
are no DS records in the parent or the DNSKEY records in the 
fiscal.treasury.gov apex. Thus, the responses are seen as BOGUS.


Now if our servers saw it as completely broken, I'd understand. But 
names above fiscal.treasury.gov sometimes work. Sometimes they don't. 
That's what's really confusing me.


Of course, the answer here is to get treasury.gov to fix their servers. 
I've emailed the MNAME in the SOA, but if any Feds lurking who know 
someone at treasury.gov, it'd be great if you give the right people a 
heads up.


But I'd like to also understand why we're getting sporadic success and 
failures.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations