date:20230918

Re: resolver: DNS format errors

2023-09-18 Thread Mark Andrews

Correction, they incorrectly answer the SOA query.

> On 19 Sep 2023, at 09:53, Mark Andrews  wrote:
> 
> 
> 
>> On 19 Sep 2023, at 02:14, Alex  wrote:
>> 
>> 
>> 
>> On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews  wrote:
>> Spamhaus’s servers are sending back responses that do not answer the 
>> question. Named is doing QNAME minimisation using NS queries and rather than 
>> the servers sending back a NODATA response for the empty non-terminal names 
>> they are sending back the NS records for the top of the zone. 
>> 
>> I suggest that you ask them to fix their DNS servers to correctly answer NS 
>> queries.  They appear to need to look at the query name as well as the query 
>> type. 
>> 
>> This is what often happens when you write custom DNS servers.  You fail to 
>> handle some query you weren’t planning for. 
>> 
>> They have just recommended disabling qname-minimization altogether. Is that 
>> the right solution?
> 
> No.  The correct solution is for them to fix their broken servers.  Their 
> servers give correct
> answers for DS, A, TXT, SOA, A and others but not for NS (a referral back 
> to the same
> servers) and TYPE1000 (they return NOTIMP instead of NOERROR NODATA as they 
> do for DS, A, TXT,
> SOA, A and others).  This is behaviour that is specified in RFC 1034 that 
> is wrong.  QNAME
> minimisation (RFC 7816) is a security fix designed to prevent leaking of 
> query names and types
> to servers closer to the root that don’t need this information and it works 
> with all servers
> that are DNS protocol compliant.  They are recommending that you turn off a 
> security fix.
> 
> 
> RFC 1034, 4.3.2. Algorithm
> 
>   ...
> 
>   2. Search the available zones for the zone which is the nearest
>  ancestor to QNAME. If such a zone is found, go to step 3,
>  otherwise step 4.
> 
>   3. Start matching down, label by label, in the zone. The
>  matching process can terminate several ways:
> 
> a. If the whole of QNAME is matched, we have found the
> node.
> 
> If the data at the node is a CNAME, and QTYPE doesn’t
> match CNAME, copy the CNAME RR into the answer section
> of the response, change QNAME to the canonical name in
> the CNAME RR, and go back to step 1.
> 
> Otherwise, copy all RRs which match QTYPE into the
> answer section and go to step 6.
> 
>...
> 
>6. Using local data only, attempt to add other RRs which may be
>   useful to the additional section of the query. Exit.
> 
> Step 2 gives zrd.dq.spamhaus.net.  Step 3a matches 
> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net
> and as there isn’t NS records at that name the answer section should be 
> empty.  Adding referral
> records is done in step 3b which is skipped.
> 
>  b. If a match would take us out of the authoritative data,
>  we have a referral. This happens when we encounter a
>  node with NS RRs marking cuts along the bottom of a
>  zone.
> 
>  Copy the NS RRs for the subzone into the authority
>  section of the reply. Put whatever addresses are
>  available into the additional section, using glue RRs
>  if the addresses are not available from authoritative
>  data or the cache. Go to step 4.
> 
> % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' ds @a.gns.spamhaus.net
> 
> ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net ds 
> @a.gns.spamhaus.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26823
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 2048
> ;; QUESTION SECTION:
> ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN DS
> 
> ;; AUTHORITY SECTION:
> zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. 
> 2309182309 3600 600 432000 1
> 
> ;; Query time: 194 msec
> ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP)
> ;; WHEN: Tue Sep 19 09:11:44 AEST 2023
> ;; MSG SIZE  rcvd: 151
> 
> % dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' txt @a.gns.spamhaus.net
> 
> ; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net 
> txt @a.gns.spamhaus.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65222
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 2048
> ;; QUESTION SECTION:
> ;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN TXT
> 
> ;; AUTHORITY SECTION:
> zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. 
> 2309182309 3600 600 432000 1
> 
> ;; Query time: 188 msec
> ;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP)
> ;; WHEN: Tue Sep 19 09:12:05 AEST 2023
> ;; MSG SIZE  rcvd: 151
> 
> %

Re: resolver: DNS format errors

2023-09-18 Thread Mark Andrews

> On 19 Sep 2023, at 02:14, Alex  wrote:
> 
> 
> 
> On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews  wrote:
> Spamhaus’s servers are sending back responses that do not answer the 
> question. Named is doing QNAME minimisation using NS queries and rather than 
> the servers sending back a NODATA response for the empty non-terminal names 
> they are sending back the NS records for the top of the zone. 
> 
> I suggest that you ask them to fix their DNS servers to correctly answer NS 
> queries.  They appear to need to look at the query name as well as the query 
> type. 
> 
> This is what often happens when you write custom DNS servers.  You fail to 
> handle some query you weren’t planning for. 
> 
> They have just recommended disabling qname-minimization altogether. Is that 
> the right solution?

No.  The correct solution is for them to fix their broken servers.  Their 
servers give correct
answers for DS, A, TXT, SOA, A and others but not for NS (a referral back 
to the same
servers) and TYPE1000 (they return NOTIMP instead of NOERROR NODATA as they do 
for DS, A, TXT,
SOA, A and others).  This is behaviour that is specified in RFC 1034 that 
is wrong.  QNAME
minimisation (RFC 7816) is a security fix designed to prevent leaking of query 
names and types
to servers closer to the root that don’t need this information and it works 
with all servers
that are DNS protocol compliant.  They are recommending that you turn off a 
security fix.

RFC 1034, 4.3.2. Algorithm

   ...

   2. Search the available zones for the zone which is the nearest
  ancestor to QNAME. If such a zone is found, go to step 3,
  otherwise step 4.

   3. Start matching down, label by label, in the zone. The
  matching process can terminate several ways:

 a. If the whole of QNAME is matched, we have found the
 node.

 If the data at the node is a CNAME, and QTYPE doesn’t
 match CNAME, copy the CNAME RR into the answer section
 of the response, change QNAME to the canonical name in
 the CNAME RR, and go back to step 1.

 Otherwise, copy all RRs which match QTYPE into the
 answer section and go to step 6.

...

6. Using local data only, attempt to add other RRs which may be
   useful to the additional section of the query. Exit.

Step 2 gives zrd.dq.spamhaus.net.  Step 3a matches 
pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net
and as there isn’t NS records at that name the answer section should be empty.  
Adding referral
records is done in step 3b which is skipped.

  b. If a match would take us out of the authoritative data,
  we have a referral. This happens when we encounter a
  node with NS RRs marking cuts along the bottom of a
  zone.

  Copy the NS RRs for the subzone into the authority
  section of the reply. Put whatever addresses are
  available into the additional section, using glue RRs
  if the addresses are not available from authoritative
  data or the cache. Go to step 4.

% dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' ds @a.gns.spamhaus.net

; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net ds 
@a.gns.spamhaus.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26823
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2048
;; QUESTION SECTION:
;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN DS

;; AUTHORITY SECTION:
zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. 
2309182309 3600 600 432000 1

;; Query time: 194 msec
;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP)
;; WHEN: Tue Sep 19 09:11:44 AEST 2023
;; MSG SIZE  rcvd: 151

% dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' txt @a.gns.spamhaus.net

; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net txt 
@a.gns.spamhaus.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65222
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2048
;; QUESTION SECTION:
;pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net. IN TXT

;; AUTHORITY SECTION:
zrd.dq.spamhaus.net. 1 IN SOA need.to.know.only. hostmaster.spamhaus.org. 
2309182309 3600 600 432000 1

;; Query time: 188 msec
;; SERVER: 149.28.9.86#53(a.gns.spamhaus.net) (UDP)
;; WHEN: Tue Sep 19 09:12:05 AEST 2023
;; MSG SIZE  rcvd: 151

% dig 'pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net' soa @a.gns.spamhaus.net

; <<>> DiG 9.19.17-dev <<>> pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net soa 
@a.gns.spamhaus.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29540
;; flags: qr aa rd; QUERY: 1, ANSWER: 1,

Re: resolver: DNS format errors

2023-09-18 Thread Alex

On Thu, Sep 7, 2023 at 4:06 PM Mark Andrews  wrote:

> Spamhaus’s servers are sending back responses that do not answer the
> question. Named is doing QNAME minimisation using NS queries and rather
> than the servers sending back a NODATA response for the empty non-terminal
> names they are sending back the NS records for the top of the zone.
>
> I suggest that you ask them to fix their DNS servers to correctly answer
> NS queries.  They appear to need to look at the query name as well as the
> query type.
>
> This is what often happens when you write custom DNS servers.  You fail to
> handle some query you weren’t planning for.
>

They have just recommended disabling qname-minimization altogether. Is that
the right solution? It doesn't seem to be complete for me. It prints
hundreds of these (presumably one for each DNS request necessary to process
the email?):

18-Sep-2023 12:07:25.561 lame-servers: FORMERR resolving '
pc5eqyfskhlh55qut433gdq2gq.zrd.dq.spamhaus.net/NS/IN': 209.222.201.139#53
18-Sep-2023 12:07:25.584 resolver: DNS format error from 50.31.133.59#53
resolving mykey.zrd.dq.spamhaus.net/NS for : reply has no answer

... then a strange line like this:

18-Sep-2023 12:13:31.606 lame-servers: success resolving
'um27qfow2knpuwx56o4otvovib2zbomydtlkuo4sktbo34cmjqvq._
file.mykey.hbl.dq.spamhaus.net/A' after disabling qname minimization due to
'failure'

btw, their support really sucks.

Thanks,
Alex
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: consolidating in-addr.arpa data

2023-09-18 Thread John Thurston


Yep.

I understand the IP space can be delegated, and some of it allocated for 
use by systems registering in MS DNS. But this isn't going to happen. 
There are multiple MS Active Directories, with registered machines 
scattered willy-nilly across the 10-dot address-space, sometimes several 
competing in the same subnets. The "design and delegate" ship sailed 
years ago. I don't have a prayer of correctly fixing the underlying problem.


After thinking harder, I don't even need correct records in all of the 
publishers of the various 10.in-addr.arpa zones. My goal now is simpler. 
Get the PTR-records from the zones handled by ISC BIND into (and out of) 
one particular MS DNS system. I don't need to get the PTRs registered in 
MS DNS back into the BIND data.


I think I can get where I need to be by leveraging /nsdiff/

No. We won't be correctly publishing accurate PTRs from all of the 
possible DNS services in the environment. But this is achievable, and 
will address the problem (of our own making) which is causing pain.


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska

On 9/15/2023 10:55 PM, Greg Choules wrote:
This is because (close your ears MS) it assumes it is the only DNS in 
town. Why would there be another one? If there is one client with a 
10.x.y.z address then there are potentially several billion more, so 
we'll create 10... just to be on the safe side. This makes MS DNS THE 
source of truth for all 10, so no-one else can have any of it unless 
you start creating delegations.-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work

2023-09-18 Thread Nicholas Miller

I know this is an old thread but we are having issues resolving pms.psc.gov as 
well. Disabling DNSSec validation on a test server doesn’t solve the problem. I 
can add a forwarding zone for ha.psc.gov pointed to their NS servers and things 
work. I would love to know what is broken here. 

> dig pms.psc.gov

; <<>> DiG 9.16.43 <<>> pms.psc.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60669
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 20b2eb2c9840bfbd010065084978288fdde1e6f7c2a6 (good)
;; QUESTION SECTION:
;pms.psc.gov. IN A

;; Query time: 2993 msec
;; SERVER: 128.138.240.1#53(128.138.240.1)
;; WHEN: Mon Sep 18 06:58:32 MDT 2023
;; MSG SIZE  rcvd: 68

_
Nicholas Miller, OIT, University of Colorado at Boulder

> On Aug 22, 2021, at 11:57 AM, Matthew Richardson  
> wrote:
> 
> It looks slightly more subtle than a straight failure.  There is a DS
> record in psc.gov pointing to key 180 in ha.psc.gov:-
> 
>> ha.psc.gov. 56  IN  DS  180 7 1 
>> 8A631C83457F4BDB3C450A725DFDB267C4BAC1CC
> 
> This points correctly to the key.  However digest algorith 1 is now either
> prohibited or discouraged.  Worse there is also a DS:-
> 
>> ha.psc.gov. 56  IN  DS  39093 7 2 
>> DD956C9568726B6EEED24D9814F0EC0D2BD119CF4B8A6352A4BF6968 0880E8E7
> 
> where key 39093 does not exist in ha.psc.gov.
> 
> Buried in the mass of errors & warnings, dnsvis says:-
> 
>> ha.psc.gov/DS (alg 7, id 180): DS records with digest type 1 (SHA-1) are 
>> ignored when DS records with digest type 2 (SHA-256) exist in the same RRset.
> 
> With both Bind & Unbound, I get SERVFAIL.  However, other resolvers may be
> more tolerant of algorithm 1 DS records, in which case they may decide that
> the answer is "valid".
> 
> In any event, it needs fixing.
> 
> However, to answer the OP's question, the solution is to use a "negative
> trust anchor":-
> 
>> # rndc nta -lifetime 1d ha.psc.gov
>> Negative trust anchor added: ha.psc.gov/_default, expires 23-Aug-2021 
>> 18:55:13.000
> 
> which then allowed my Bind to resolve it.
> 
> Best wishes,
> Matthew
> 
> --
>> From: "John W. Blue via bind-users" 
>> To: "bind-users@lists.isc.org" 
>> Cc: 
>> Date: Sun, 22 Aug 2021 16:24:41 +
>> Subject: Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work
> 
>> Your using the wrong tools to troubleshoot or investigate this error.
>> 
>> Instead of relying upon resolvers to provide situational awareness you need 
>> to inspect DNSSEC itself using dnsviz.net:
>> 
>> https://dnsviz.net/d/pms.psc.gov/dnssec/
>> 
>> psc.gov is giving the world ID 5089 when they need to handing out ID 180.
>> 
>> Recommend the pms.psc.gov admins give the psc.gov admins the correct hash.
>> 
>> Sent from Nine
>> 
>> From: Roger Hammerstein 
>> Sent: Sunday, August 22, 2021 9:45 AM
>> To: bind-users@lists.isc.org
>> Subject: unresolvable pms.psc.gov, but google/cloudflare/unbound work
>> 
>> 
>> pms.psc.gov appears to be unresolvable against bind9.16.19
>> and 9.11.34 because of dnssec issues.
>> But it resolves against Cloudflare's 1.1.1.1, Google's 8.8.8.8, and an 
>> Unbound
>> resolver that does dnssec-validation.
>> 
>> There's a ticket open with nih.gov to look into it, but is there anything 
>> that can
>> be changed with Bind to make this domain resolve in the meantime?
>> 
>> (pms.psc.gov): query failed (SERVFAIL) for pms.psc.gov/IN/A at query.c:8678
>> 
>> https://dnsviz.net/d/pms.psc.gov/dnssec/
>> https://dnssec-analyzer.verisignlabs.com/pms.psc.gov
>> 
>> dig a pms.psc.gov @8.8.8.8
>> pms.psc.gov.2852IN  CNAME   pms.ha.psc.gov.
>> pms.ha.psc.gov. 29  IN  A   156.40.178.24
>> 
>> 
>> 
>> dig a pms.psc.gov @8.8.8.8 +dnssec
>> 
>> ;; ANSWER SECTION:
>> pms.psc.gov.2835IN  CNAME   pms.ha.psc.gov.
>> pms.psc.gov.2835IN  RRSIG   CNAME 8 3 3600 
>> 20210827000144 20210821230144 5089 psc.gov. 
>> kpclRfRyBqaSGW6VrpkE4gP/QPfggKZTVb68npiosnt+4lIUglUxino5 
>> jQAqd9a1p8HbdHG63HPnfYYBq1bX9q/f11CVUmxXXJUbRBGTZBnDyATP 
>> LLI2GWSZ1at364O+C+iZozi8NpJNU4oTCfd3PLScFbOfSGbPyRfUzfvB AJc=
>> pms.ha.psc.gov. 29  IN  A   156.40.178.24
>> pms.ha.psc.gov. 29  IN  RRSIG   A 7 4 30 20210827185442 
>> 20210820185442 21380 ha.psc.gov. 
>> w2XUqBVoBMtLv0qfc5xmccrpv+w2ukwGfaGJvthIKHXr2SdlAk3oQxve 
>> xyolEaj2zWn8Uj7lOsaZD8mewBMQ3iEEp8U96aFBslWV/ffEKL+H9oMM 
>> sUNU5KwNi7/Nk3KZuNc8R3xxuYTsSVdbu6ai1lQ6fmw2uWAoDP9YIqek 
>> jyo/0WFSXM+hxw/5WguijhilSRIywNgG3/6MY3ZmunPPafGTCTXigyex 
>> IBACJQJ+meD6vMi0YoRM17mwdD+7Buq2cb6LJyVYaQImh7M2gF8My75n 
>> lDns4PWEIx4bSW2uQQEPpB7MA9VI9y5CuVCmqC3wMZ2ow6G8pkaf18wv r/ucSQ==
>> 
>> 
>> 
>> 
>> I can sometimes get a servfail out of 8.8.8.8 with

Re: resolver: DNS format errors

Re: resolver: DNS format errors

Re: resolver: DNS format errors

Re: consolidating in-addr.arpa data

Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work

5 matches

Site Navigation

Mail list logo

Footer information