DNSmasq dnssec support

[shooter40sw]

Hi @RMerlin , In fact google says it supports DNSSEC in there FAQ, and there a lot more information there, Im currently using dnscrypt with opendns, but this looks interesting.
Thanks to all for the hard work!, Im interested in testing this out, please let me know.

Does Google Public DNS support the DNSSEC protocol?
Yes. Google Public DNS is a validating, security-aware resolver. All responses from DNSSEC signed zones are validated unless clients explicitly set the CD flag in DNS requests to disable the validation.

 

[lancethepants]

I think he means that their own domains aren't using dnssec authentication. You can check using the dig tool.

dig +dnssec www.isoc.org.

This will show you can 'ad' flag which means it has dnssec authentication.

dig +dnssec www.google.com

Google's domain name does not have dnssec authentication.

 

[PabloAbonia]

One thought, if you set up a marker of boot completion (e.g. crond time disparity message) you could allow the initial dnssec flags to be off, and then restart dnssec with the flags on.

In general a script or nvram marker that runs after all of the startups have completed would be useful since I am often in situation were I am waiting for IPv6 prefix to be set, before making edits based upon that prefix. In native mode with the TWC ISP, they change the prefix all the time, which makes it difficult to setup a static IPv6 address.

Pablo

 

[RMerlin]

One thought, if you set up a marker of boot completion (e.g. crond time disparity message) you could allow the initial dnssec flags to be off, and then restart dnssec with the flags on.

In general a script or nvram marker that runs after all of the startups have completed would be useful since I am often in situation were I am waiting for IPv6 prefix to be set, before making edits based upon that prefix. In native mode with the TWC ISP, they change the prefix all the time, which makes it difficult to setup a static IPv6 address.

Pablo

The thing is, there is no such moment as "boot has completed". A few things, such as the WAN going up, are event-based, not part of a linear procedure.

There's already a flag that marks when NTP has been synced. This is what I'm using to determine if dnsmasq can unconditionally enable dnssec, or if it should wait for a SIGHUP.

In your case, the wan-start script would be the ideal location to act upon startup events.

 

[PabloAbonia]

I've tried wan-start in the past, however I think it needs to be modified to take into consideration the start of IPv6, as I believe that it regards the wan as being up once IPv4 is up. This causes any script dependent upon IPv6, to fail as IPv6 typically is up after IPv4 set. This is true for native modes, but does not apply to the 6in4 modes as much. If I 'm correct about this, it might make it better to have wan-start begin after IPv4 & IPv6 are up when IPv6 is being used.

Does the time disparity reported by crond at initial boot up occur before boot is completed for some applications like tor or the vpn started? I haven't used those applications, and the crond report is always last on my router.

Thanks,

Pablo

 

[RMerlin]

I've tried wan-start in the past, however I think it needs to be modified to take into consideration the start of IPv6, as I believe that it regards the wan as being up once IPv4 is up. This causes any script dependent upon IPv6, to fail as IPv6 typically is up after IPv4 set. This is true for native modes, but does not apply to the 6in4 modes as much. If I 'm correct about this, it might make it better to have wan-start begin after IPv4 & IPv6 are up when IPv6 is being used.

Does the time disparity reported by crond at initial boot up occur before boot is completed for some applications like tor or the vpn started? I haven't used those applications, and the crond report is always last on my router.

The crond warning occurs whenever ntp has just completed, and crond realized that the clock had just shifted. It's not part of a linear series of events. Once services-start has run, everything else is purely event based, not time based.

Don't think of the firmware as a linear series of events, it will only cause problems. You have to act based on specific triggers. The rc daemon handles events as it gets signaled, it does not run everything in a linear order.