Re: Resolve some hosts thats are dnssec signed differently

[Petr Špaček]

On 07. 02. 23 7:45, Matthias Fechner wrote:


So if I would like to access idefix.fechner.net it makes a DNS lookup 
which returns the A record for idefix.fechner.net and it sees it does 
not belong to my interface so it uses the default gateway to go to my 
internet provider. It reaches my server in the internet, is routed into 
the openvpn tunnel and goes through my local firewall through a policy 
based NAT to a local IP (192.168.200.x). So you see that is not very 
efficient.


My idea was to hook into the DNS and make sure to not return the IPv4 
address 195.30.95.36, but 192.168.0.1 (as all my devices at home are 
using my local bind here for lookup).


I hope that explain it better what I would like to solve.


It seems to be that you are trying to fix rounting problem/suboptimality 
in DNS... Perhaps consider routing 195.30.95.36 to the appropriate host 
in your network directly - that way you don't have to do anything in the 
DNS.


--
Petr Špaček

--
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: [KASP] Key rollover

[adrien sipasseuth]

Hello,

I waited 24 hours and then put my zone back in dnssec.

after 24 everything seems ok... at least by doing a "rndc dnssec -status
"

everything is in omnipresent:
  Next rollover scheduled on Fri Feb 10 09:15:51 2023
  - goal: omnipresent
  - dnskey: omnipresent
  - ds: omnipresent
  - key rrsig: omnipresent

so it works BUT I need to know more than 48h in advance that the rollover
is starting to submit the new KSK to my registar.

How can I set this up if it's not with "public-safety"?

Regards,
Adrien



Le mer. 25 janv. 2023 à 11:34, Matthijs Mekking  a écrit :

>
>
> On 1/24/23 15:18, adrien sipasseuth wrote:
> > Hello,
> >
> > I don't why DSState: hidden, it's ok with some online check tools like :
> > - https://dnssec-analyzer.verisignlabs.com/
> > 
> > - https://zonemaster.net/fr/run-test  >
>
> DSState: hidden is what BIND thinks. Note that it does not query yet to
> determine the DSState.
>
>
> >
> > my master is hidden, it can be related ? How i can debug this DSState:
> > hidden ?
>
> It has nothing to do with hidden primaries.
>
>
> > I found this command to check actual status : rndc dnssec -status
> **
> > This is the output :
> > 
> > key: 46358 (ECDSAP256SHA256), KSK
> >published:  yes - since Tue Jan 17 17:55:03 2023
> >key signing:yes - since Tue Jan 17 17:55:03 2023
> >
> >Next rollover scheduled on Tue Jan 24 17:55:03 2023
> >- goal:   omnipresent
> >- dnskey: omnipresent
> >- ds: hidden
> >- key rrsig:  omnipresent
>
> It is hard to determine why your DS is hidden. If all other elements are
> omnipresent, the DS should be rumoured (because you may submit it to the
> parent).
>
> I have a feeling this is because your publish-safety is 3 days. It takes
> an additional 3 days before continuing with the rollover, thus also with
> "making the DS known to the world". In other words, I think BIND does
> not yet think it is safe to publish the DS, hence DS is hidden.
>
> I understand this may not reflect the real world, and perhaps it is a
> bug. If someone issues a "rndc dnssec -checkds published" command", we
> probably should force move the DS state from "hidden" to "rumoured".
>
> Best regards,
>
> Matthijs
>
>
>
>
> > ...
> >
> > Regards Adrien
> >
> > Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking  > > a écrit :
> >
> > Hi Adrien,
> >
> > I don't think it is fine yet. I see in your state file the following
> > line:
> >
> >   > DSState: hidden
> >
> > This means the DS is not published according to BIND.
> >
> >   > From my understanding, the second KSK should appear because I
> > put the
> >   > parameter "publish-safety 3d;" that is to say 3 days before the
> >   > expiration ("retired") of the key in use. is that right?
> >
> > In addition to the DNSKEY TTL yes. The successor KSK should be
> > pre-published the sum of dnskey-ttl, publish-safety, and
> > zone-propagation-delay, prior to its retirement.
> >
> > Best regards,
> >
> > Matthijs
> >
> > On 1/24/23 09:08, adrien sipasseuth wrote:
> >  > Hello Matthijs,
> >  >
> >  > Indeed I had not published the DS at my registar because I
> > thought that
> >  > the second KSK would have appeared anyway at the time of the
> > rollover.
> >  >
> >  > I published the DS yesterday and I reported to BIND with the
> > command you
> >  > gave me. I didn't find any error in the logs so everything must
> have
> >  > been fine!
> >  >
> >  > here is the state file of the KSK in use :
> >  > ; This is the state of key 46358, for ***.
> >  > Algorithm: 13
> >  > Length: 256
> >  > Lifetime: 604800
> >  > Predecessor: 28887
> >  > KSK: yes
> >  > ZSK: no
> >  > Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
> >  > Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
> >  > Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
> >  > Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
> >  > Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
> >  > DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
> >  > PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
> >  > DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> >  > KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> >  > DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
> >  > DNSKEYState: omnipresent
> >  > KRRSIGState: omnipresent
> >  > DSState: hidden
> >  > GoalState: omnipresent
> >  >
> >  >  From my understanding, the second KSK should appear because I
> > put the
> >  > parameter "publish-safety 3d;" that is to say 3 days before the
> >  > expiration ("retired") of the key in use. is that right?
> >  >
> >  > that is to say tonight at 7pm

Re: Intermittent issues resolving "labor.upload.akamai.com"

[tale via bind-users]

On Fri, Feb 3, 2023 at 4:32 AM Greg Choules via bind-users
 wrote:
>> From a quick look in Wireshark at what my own server (9.18.8) is doing, this 
>> looks like Akamai not responding correctly to a BIND QNAME minimisation 
>> query. Here's one response, from 95.101.36.192 for example, of many similar 
>> ones showing an issue. The response code shouldn't be REFUSED:

Definitely protocol issues going on with akamai.net.  A query for the
target in the OP, at an akamai.net auth, indicates  that there's a
zone cut at e.stor:

dig +noall +auth r33674-33729.neards.1.cftp.e.stor.lb.akamai.net
@zc.akamaitech.net
e.stor.lb.akamai.net.   4000IN  NS  n4e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000IN  NS  n0e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000IN  NS  n3e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000IN  NS  n2e.stor.lb.akamai.net.
e.stor.lb.akamai.net.   4000IN  NS  n1e.stor.lb.akamai.net.

but it returns that the stor label is a lame delegation:

dig stor.lb.akamai.net @zc.akamaitech.net | awk '/status/ {print $6}'
REFUSED,

Even if lb were itself delegated, REFUSED is still the wrong answer
for stor; in that case it should get the delegation for lb.  But lb
isn't delegated either, so refused is even more wrongerer.

I'll forward this over to Akamai.
-- 
tale
-- 
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