tobez / validns Goto Github PK

Hello,

We would be very grateful if you are willing to release a 0.4 of validns (with the ECC support).

Merci

Via Daniel Stirnimann:

• there are multiple RRSIGs for every signed record
• one or more DNSKEYs for some of those RRSIGs is missing
• but there is at least one valid RRSIG for which a valid key is found,
  for every signed record

If so, then it might make sense to not consider this an error at all
(or maybe add a policy check that will make such cases into errors,
thus allowing the operator the degree of control you suggest, effectively).

Do you still plan on implementing INCLUDE? If not, would it be possible to (add an option to) ignore INCLUDE statements?

validns currently only supports checking the zone file against a single time stamp. By default, validns checks the expiration and inception time against "now". However, using the parameter '-t epoch-time' one can provide a time in the future or the past.

It seems like a trivial fix to me, to allow more then one time parameter to be given on the command line.

e.g. validns -t epoch-time -t epoch-time zone-file

The signatures expiration and inception time stamps would then be checked against all provided time parameters from the command line. The advantage is that this allows for more advanced time checks. For example, my zone file contains signatures with the inception time of at least now-1h. The expiration time is at least now+2weeks or up to now+3weeks.

Before publishing a zone, I could check my zone with:

validns -t -t <now+2weeks> zone-file

to make sure that the signing worked as expected. With the current implementation, I would need to run validns twice. However, given that my zone files are quite large, I rather run validns only once!

Requested by Daniel Stirnimann:

Nonetheless, I think in the long term it could still make sense to
provide the granularity of different error levels such as ERROR, WARNING
and maybe INFO. For example: you have a buggy signer which leaves some
old RRSIGs by accident and your zone is not in an algorithm key rollover
state as described above. The operator has enabled the above new policy
check because some of his zones do have an algorithm key rollover at one
point in time. Without providing different error levels, the operator
will not detect this failure in the buggy signer.
Maybe you could just log such situations in the "verbose" output so that
an operator has the chance to detect them. Current verbose logging would
be marked as INFO and more serious none-errors could be marked as WARNING.

(Via Paul Woters):

I just encountered a bug in validns.

Image the zone:

example.com.            IN SOA .......
example.com.            IN NS ns1.example.com.
ns1.example.com.        IN A 1.2.3.4
backoffice.toronto.example.com. IN NS ns1.backoffice.toronto.example.com.
ns1.backoffice.toronto.example.com. IN 3.4.5.6
www.example.com.        IN A 5.6.7.8

When this zone is signed, validns gives an an error about missing
NSEC(3) records for "toronto.example.com".

I think there is a wrong assumtion in the code that any "." means a
zone cut with NS/A/AAAA records. This assumption is incorrect :)

Reported by Daniel Stirnimann,
commented on by Willem Toorop.

Validns canonicalizes NSEC RDATA. The common practice for bind and unbound is to not do it:

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19#section-5.1

5.1. Errors in Canonical Form Type Code List

   When canonicalizing DNS names (for both ordering and signing), DNS
   names in the RDATA section of NSEC resource records are not
   downcased.  DNS names in the RDATA section of RRSIG resource records
   are downcased.

   The guidance in the above paragraph differs from what has been
   published before but is consistent with current common practice.
   [RFC4034] Section 6.2 item 3 says that names in both of these RR
   types should be downcased.  The earlier [RFC3755] says that they
   should not.  Current practice follows neither document fully.

Therefore, validns behavior must be changed to reflect the current practices.

The following files needs to be removed when cleaning:

• base32hex.o
• base64.o

Validns fails to validate RRSIGs for CAA-records. The CAA-record itself validates fine and the RRSignature seems ok as well. NSD, Unbound and dig have no problem serving and retrieving the records which strongly suggests that the RRSIG is correct.

$ ./validns -z mijnuvt.nl /tmp/mijnuvt.nl 
/tmp/mijnuvt.nl:12: mijnuvt.nl. RRSIG(CAA): bad signature

$ grep CAA /tmp/mijnuvt.nl 
mijnuvt.nl.     3600    IN      CAA     0 issue "digicert.com"
mijnuvt.nl.     3600    IN      RRSIG   CAA 8 2 3600 20170817111032 20170803134224 40935 mijnuvt.nl. ZU5S/KK5Nl0XKHbCjhHC7Iacbsm1CrCA2AjKfGaw0XojCrWOJjMq2UvjVrZsDAsvyjeLBpfqvpTDyLHCin/xxHSP455e8skRcvDovpEmhHNoUcYKIQLOFTy6acAuzAyUbZ5vJAgzga4vayFKaaHcJqL+9Zm0avDb00fZRBoB+mw=
71cmi5a5nrv504hcc2rglvu6mjgqejhg.mijnuvt.nl.    3600    IN      NSEC3   1 0 5 279cca9209a3eec3  91k63cl5l58cdttq946f1ck8e2t3uim6 SOA TXT RRSIG DNSKEY NSEC3PARAM CAA

$ dig +short  +dnssec -t CAA mijnuvt.nl @ulam.uvt.nl
0 issue "digicert.com"
CAA 8 2 3600 20170817111032 20170803134224 40935 mijnuvt.nl. ZU5S/KK5Nl0XKHbCjhHC7Iacbsm1CrCA2AjKfGaw0XojCrWOJjMq2Uvj VrZsDAsvyjeLBpfqvpTDyLHCin/xxHSP455e8skRcvDovpEmhHNoUcYK IQLOFTy6acAuzAyUbZ5vJAgzga4vayFKaaHcJqL+9Zm0avDb00fZRBoB +mw=

$ git rev-parse HEAD
eb71f3620c76612f02c07695a757514188891858

I get an error:

% validns -p all -z example example.signed-text 
example.signed-text:15: example. RRSIG(TYPE65534): bad signature
example.signed-text:3: example. RRSIG(SOA): bad signature

The zone is maintained by BIND "auto-dnssec maintain;" feature (auto-signing). Since the signed zone is in binary format, I extracted it with:

named-compilezone -j -i none -f raw -F text -o example.signed-text  example  example.signed

Is it a bad procedure? A bug in BIND? In validns?

The actual zone file is in https://gist.github.com/bortzmeyer/6105081

And possible other RR types.

I get a lot of NSEC validation problems while testing the .se zone now, example:

/home/pawal/antispam/se.new:10184434: NSEC says xn--ulrikskldblogg-dib.se. comes after xn--ulriksfrskringsblogg-jzb70b.se., but a.ns.xn--ulriksfrskringsblogg-jzb70b.se. does
/home/pawal/antispam/se.new:10184443: NSEC says xn--ultraljudsskrmma-7nb.se. comes after xn--ulrikskldblogg-dib.se., but a.ns.xn--ulrikskldblogg-dib.se. does

This is the content of the zone file:

xn--ulriksfrskringsblogg-jzb70b.se. 7200 IN NSEC xn--ulrikskldblogg-dib.se. NS NSEC
RRSIG
xn--ulriksfrskringsblogg-jzb70b.se. 86400 IN NS a.ns.xn--ulriksfrskringsblogg-jzb70b
.se.
a.ns.xn--ulriksfrskringsblogg-jzb70b.se. 86400 IN A 178.73.224.237
xn--ulrikskldblogg-dib.se. 7200 IN RRSIG NSEC 5 2 7200 20111110080515 (
20111027170504 33951 se.
QzarSfVI7VknY1PxQEO0ySkhpPoKg7BbzilsyoMVofVpH
DA11Vsn2alwuaQkx6vxu2W1C2RyolEJG8fSmO8A4cxd9q
EkWNoDJK8frkiN2PuCY3uI1u+BIiX1rxbVZO+qqk05hFr
o6szHzZNtlmlWSoqaRedkf3h4i4iU0S/rudY= )
xn--ulrikskldblogg-dib.se. 7200 IN NSEC xn--ultraljudsskrmma-7nb.se. NS NSEC RRSIG
xn--ulrikskldblogg-dib.se. 86400 IN NS a.ns.xn--ulrikskldblogg-dib.se.
a.ns.xn--ulrikskldblogg-dib.se. 86400 IN A 178.73.238.252
xn--ultraljudsskrmma-7nb.se. 7200 IN RRSIG NSEC 5 2 7200 20111111210454 (
20111029190504 33951 se.
J7MVJJhqYq/6GC53Pf2vmVLZI2XiRaPKvQY8oi7Y7OyxV
f0avF6SrLaJ4+IMLUCVK+sV3Q2XyRPN7nnlib9BiTglaM
QHsgdAujduQY4n35cl57p3rPwMmJIdScv0OZnWPQU1IIM
GtpkIJqGZMLcC5/+P2WXCOTtXph2y/ArkgkM= )

xn--ulriksfrskringsblogg-jzb70b.se. has been delegated (with the NS) so therefore a.ns.xn--ulriksfrskringsblogg-jzb70b.se is glue that should not be covered by NSEC.

See RFC 4034 section 4, and 4.1.1:

Owner names of RRsets for which the given zone is not authoritative
(such as glue records) MUST NOT be listed in the Next Domain Name
unless at least one authoritative RRset exists at the same owner
name.

Hi. I'm having a validns error in a zone with a LOC RR signed with algorithm 7. The error is

vulcano.cl.signed:73: vulcano.cl. RRSIG(LOC): cannot verify the signature

The zone is signed with bind tools and validate correctly in the live zone.
I hunted down the error to EVP_VerifyFinal, so may be my openssl version (OpenSSL 1.0.0e-fips 6 Sep 2011)?
Changing the algorithm to 5 (like the example.sec.signed test file) works ok.

I've opened AXFR for the zone in ns.vulcano.cl, if you need it.

Thanks,

Hugo

With this zone :

1-wire.fr.  43200   IN  SOA ns1.absolight.net. root.absolight.com. 2013071502 86400 3600 604800 600
1-wire.fr.  43200   IN  RRSIG   SOA 7 2 43200 20130722150717 20130715135031 54587 1-wire.fr. C0TMxMsWPT7BpJk4l+Ad1MOGEEMUenyXrjz+JvEmUi4vEUFFsioG5aL4eXCvHGGgA8UQqDo0ehgcvIbWQL27ewqUniI9ZKQiJL8JpAMiwXPKMf3dM9dx8a85hZOZn2jskqGUmAcBaEmVdMVO+g2GIhAyg/dueovvCEEvj5OPu7g=
1-wire.fr.  10800   IN  DNSKEY  257 3 7 AwEAAbE2XO555dx58x7Dr+4fcheKI19lhdd3JwcySQ3Ej6Gg8TvB9yNJnT6dpj9ISspPUYlYgjFku/R7ILVlA2KBHCttP3b9UyERYczx6F5FHfROlvmn+fgvTYqPIQBv/Im1O+F1AEPqINPadY3BuOc4B3X7cC5PEpX+J2SWHrBimNSFKjQCxKdk+WVY84daJXbjUgCzc/qaQbnOpw0bg5PpmNLmiecQfTSHoKSdl/vXWwUxpAIEDGdY2ZLpPrF5bCbIhAS6j2D9ya9VnPPgGlg4KnDkFL9yEHgciPHqkNzjcC/7qumjFJ5W9vhiRy8CeOrGMGpRXVzGU2QKtVp1clslVfs= ;{id = 26548 (ksk), size = 2048b}
1-wire.fr.  10800   IN  DNSKEY  256 3 7 AwEAAa/kxQu4uWyLW+O47FetO7W6ir9G0MbmCZTaXuaKxNGOyA6JNvOnyuQLRgYSldzDI3y0m5dxSG0GCtAED7uvhIzO6aQt8RS2Jl6USYLR8ih/tT8xcU185rssP06xzjWs5U/BklBTSEdCeBdrIOqA03N4c8E1k4LXh/We8WGoN0c1 ;{id = 61635 (zsk), size = 1024b}
1-wire.fr.  10800   IN  DNSKEY  256 3 7 AwEAAaFgYm3yv4AfK6wWuBKzqI6WEW/vbNPtVho6hyAjEIsGCnoDft7hxcqcaNm+7CNSi99WIC5m//Cxh1Lx0wyMytI7ttvGsCpoYtvDwf6P656kxoaAIGhyHMJq3Y8JrbR69+XagQlDBeHt3GMzeytMSGD3nOl3b1B7yEkrSooLGDXh ;{id = 54587 (zsk), size = 1024b}
1-wire.fr.  10800   IN  RRSIG   DNSKEY 7 2 10800 20130722151334 20130715134757 26548 1-wire.fr. ccA00mtHbD4BhFc+YxhVMpD+oB+m+Q0Es+YgIiAOcNcfsd33r5WM8IChV9IIFqUZ8uH2ehdMNadc9Kue0HJsTzjhp5DAJ2tgIDOIKU8jzuExLDuk/EvSE48z7fZMlncyrOv1DBpri+Rs7ePtDQjdiTuBejFEUirlBCCzhMvOuFQTQhnkKs+ZbR1Ei4NCyfcoPR3mJzsl7h5aa54E7MzaeVL3uhOBHezorbLSaqX+khmuQCbGgHNplMN7YxKhhihHQHASqQHc4BGka/ZR0eL4aNAu91kfDCMgbSGXd8YWFD7RayUMIoG3DXBd2I9zmIO8sRBuHbhd8WDO38SFrk50EQ==
1-wire.fr.  0   IN  NSEC3PARAM  1 0 100 a6b05497e26b2e5a 
1-wire.fr.  0   IN  RRSIG   NSEC3PARAM 7 2 0 20130722102802 20130715134757 54587 1-wire.fr. M/IGI7xR7lkik1tOj8s9nfAfUFjAlBMJ8OoWxjTQNpyFUrHLs0UsKPIfJwTcva2KLXw3/lw6k9MHe6eUD61AGptU34vXhFDcZgrgh5jEMHZyguyfFYVXI50WrXR7jEUpEL/+CGso4KPYAS0lqThlYWn5qci8Pwuu+CGOiO9CrNU=
1-wire.fr.  86400   IN  NS  ns1.absolight.net.
1-wire.fr.  86400   IN  NS  ns2.absolight.net.
1-wire.fr.  86400   IN  NS  ns3.absolight.net.
1-wire.fr.  86400   IN  NS  ns4.absolight.net.
1-wire.fr.  86400   IN  RRSIG   NS 7 2 86400 20130722192629 20130715134757 54587 1-wire.fr. UQ3ZXu2FKM+MK4pL++4jFSzU5y9JTQ5uZAo+iZJs61KIjpGuUepcAqsSsLQ7kkInJC6WwLs+HP1Rf9vdZJT1/bXQ3idzjCdFvC8GgOWQ26/9o4eZaosOu6GZDJ8yr8A4D1MwWCATnCir+Aodp0VXFLTrUULa8yzNICYc1wje7nw=
1-wire.fr.  86400   IN  A   193.30.224.226
1-wire.fr.  86400   IN  RRSIG   A 7 2 86400 20130722140635 20130715134757 54587 1-wire.fr. Ac8kVc8a7F7NZfq1HjpokUSbMmvdiEtSSnC7F6+ZZ1PkKKlr1tcTrxgin3HPWx/A41bwaSjA5gCddpGILBPKgvDHREEviGqfHjYycC4Z3c/o3aoKhFmAKWkD7vr7B+RdNMwZ383HmaGESTU4JT6y01Hxby1xxORJn7xXt8B2hVg=
1-wire.fr.  86400   IN  MX  10 mx3.absolight.net.
1-wire.fr.  86400   IN  MX  20 mx4.absolight.net.
1-wire.fr.  86400   IN  RRSIG   MX 7 2 86400 20130722053332 20130715134757 54587 1-wire.fr. IrNybnP6OevPYdIQRiBZhREaHbVi3x2g5Zpe72/3C7vajc0pDDHyy6ardXXbikGCfsNWvZJk2k4XDlhFjUsjRtRqzMskAqRggKsBFSRUFn1XW2Pqlb0jAXpBNRPNs1mlAHQpAirADCZvUSyT0yDO9nwPo7Si0uJ/i9OiHzQGxvk=
rbbkes60aq8v8tj8993u9jc7g0nnvmkd.1-wire.fr. 600 IN  NSEC3   1 0 100 a6b05497e26b2e5a  3tok8i9ahpvn7voas6f25dbnlcrkt32m A NS SOA MX RRSIG DNSKEY NSEC3PARAM 
rbbkes60aq8v8tj8993u9jc7g0nnvmkd.1-wire.fr. 600 IN  RRSIG   NSEC3 7 3 600 20130722090734 20130715134757 54587 1-wire.fr. nSJmsfyObrzSu9xxjwnyt9ZVy/R9wCcKruDpKCWiSXaNkwrGnNBvFFctSWoUdtixX0BAwlOfuLjwhjkyetZJEXqR+TD8t2002ol/FjjzgTY7jrfORgQ0mZKmKNQKT/gu9Px5k/uI9fihoAuYMZxFJpqQuRiIculyciz61bx+yjM=
_keyword.1-wire.fr. 86400   IN  TXT "$Abso: 1-wire.fr,v efbe6fe0d5af 2013/07/15 14:00:27 mat $"
_keyword.1-wire.fr. 86400   IN  RRSIG   TXT 7 3 86400 20130722081009 20130715135031 54587 1-wire.fr. BN0Njs/7Xl0/dU/kjt50dwL8gmoEFolsCHf+CLsHwD/JbR7aJVbn34QcjCS/HGVSbjm/0phIrMCNHA6QndllzWpQ948RKD3qdEUpRFfe+v1f8qxMSkkWjpFpZgse4zX10PuiM8WSvr21j3x69s2KJhMSz0I9Y4z/wIPBl/STQ3o=
51a6th45ca1hnfa540p77t6d79flpfnj.1-wire.fr. 600 IN  NSEC3   1 0 100 a6b05497e26b2e5a  fui5h4nkfd427prmp83unqg52ah4ecs5 TXT RRSIG 
51a6th45ca1hnfa540p77t6d79flpfnj.1-wire.fr. 600 IN  RRSIG   NSEC3 7 3 600 20130722052351 20130715134757 54587 1-wire.fr. FCV9sYwaq//Uyo7yIIBo4ZhCIYK6FF6ox0lHq2Hnl167JNjawZoibFpWXhevGMy1Ba5LNs/pcAzf/DvwBogVpOp+QYdzcSE/SU9xTsDhOD5fC09/jryCmQwtmqSBJ2og+jCEce/k1ZxfKIGKJf8v8wBTmiQnulFb/X7DIc+qIks=
localhost.1-wire.fr.    86400   IN  A   127.0.0.1
localhost.1-wire.fr.    86400   IN  RRSIG   A 7 3 86400 20130722215806 20130715134757 54587 1-wire.fr. DuYXMjs1JqMBhBRN4leKeQ35aKYbJY/sFX18Ay/Gsw+mBvZmhYiIpEvF5S+6Y2DdsfW4cACRFHgcH1xA+4x6bZ8qgx9a0chUvPhZEYxE4x+OUPQIxiHTuv1uMggFn3IXzVa6gF2LyzXcTpVllTgv+/ys5CEsGMi9tIW6dkKw1jI=
fui5h4nkfd427prmp83unqg52ah4ecs5.1-wire.fr. 600 IN  NSEC3   1 0 100 a6b05497e26b2e5a  rbbkes60aq8v8tj8993u9jc7g0nnvmkd A RRSIG 
fui5h4nkfd427prmp83unqg52ah4ecs5.1-wire.fr. 600 IN  RRSIG   NSEC3 7 3 600 20130722142056 20130715134757 54587 1-wire.fr. O02p9ZOPhrzIy+BOpJ1/GlYAVmqvPGoOu4nI7dvuuYMwKGAPjsO0fDKz+6+1Wm5DfXVYseec95IK8YfLpuF3q+jAJZ0OUov+5b3TJAwH+Etv9UxkHVW12uA9hL/1X5iehEH6d+LXZUKtwFnsanLSvlchJf4JQrnxEBmmdmH6R4A=
www.1-wire.fr.  86400   IN  CNAME   1-wire.fr.
www.1-wire.fr.  86400   IN  RRSIG   CNAME 7 3 86400 20130722090344 20130715134757 54587 1-wire.fr. RF00wQjwTUDvIYLqNtqpnLNW24gBbb9FQLmmt5KccbFVcRIop99GFIvjWZOf2bNFVStSgIgbYdMYB1SpfAppYw8jDmOcmjNc1pcWtcyVXMvFrtEgozKqt3sCykqRRWOwiFXXg0KB/QqfBa51u9PJxmJG5XqvqX0DztSRWkZOCPU=
3tok8i9ahpvn7voas6f25dbnlcrkt32m.1-wire.fr. 600 IN  NSEC3   1 0 100 a6b05497e26b2e5a  51a6th45ca1hnfa540p77t6d79flpfnj CNAME RRSIG 
3tok8i9ahpvn7voas6f25dbnlcrkt32m.1-wire.fr. 600 IN  RRSIG   NSEC3 7 3 600 20130722082512 20130715134757 54587 1-wire.fr. getervzzrXmyuvYOkeElN+Ztd4nb2xTLHRFrNWfo2bXwQYVx0700xva7X8kxsw2ozC9R731jlqO8YUl9g7z7k12udndO3eZ2XBu7XAoQckuUBuBNR5wqgrcXlt48tfVzJGwcjg2Ak9W+Gj/tLNe/JE8vBW42+4qD8Y7wO4JoWAk=

I get :

# validns -p all -z 1-wire.fr master/1-wire.fr.signed2
master/1-wire.fr.signed2:15: 1-wire.fr. RRSIG(SOA): cannot verify the signature

And I don't really understand what's happening, as tools like http://dnssec-debugger.verisignlabs.com/ don't seem to find any problem.

DANE/TLSA records will appear soon (Type 52, see
http://www.iana.org/assignments/dns-parameters and
http://www.rfc-editor.org/internet-drafts/draft-ietf-dane-protocol-23.txt) so it would be nice to have support for them.

Hi,

I have a zone which contains records with IDN characters. "Example: é ". Validns outputs an error record name is not valid. So it seems validns can not handle idn characters?

Can this be solved?

Thanks

Via Daniel Stirnimann:

$TTL    1d
$INCLUDE Kexample.com.+008+18169.key
$INCLUDE Kexample.com.+008+57699.key
@       IN      SOA     ns.example.com. hostmaster.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

                IN      NS      ns1.example.net.
sub             IN      NS      ns1.example.net.
test.sub        IN      A       127.0.0.1

The error is that there exists the "test.sub" record but "sub" is
already delegated.

BIND "dnssec-signzone" ignores "test.sub" and does not create
RRSIG/NSEC/NSEC3 records.

When I verify the signed zone (using NSEC) with validns, no error is shown.

When I verify the signed zone (using NSEC3) with validns, the error:
"no corresponding NSEC3 found for test.sub.example.com." is shown which
is correct.

I'm not sure what's the right way of handling this error is. In any
case, I think the error message should be the same whether NSEC or NSEC3
is used. Practically, I could live with a WARNING and not an ERROR
because, as far as BIND dnssec-signzone goes, the additional record of
the delegated zone is not signed, so does not lead to a signing error.
However, I'm not sure if other DNSSEC signing tools handle this the same
way.

Validns throws an error when the number of content fields for a TXT records exceeds 20, a total of 5100 bytes. Did you find a hard limit in one of the major resolvers or did this just sound like a sane upper limit?

RFC8080 has recently come out for DNSSEC algorithms 15 and 16.

Could support for this be added to ValiDNS?

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

This seems relevant (it was the change for algo 13 and 14):

9933f9e#diff-a0852e4180b9be371d862a8d62070cdc

Issue #51 also seems relevant.

When reading a zone file, the number of RR per type should be counted and reported at the end. The output can be used to do further validation, e.g. compare the number of records with a master database or with previous runs.

Example:

record count by type:
             A: 1234
            NS: 1234
           SOA: 1
            MX: 1234
          AAAA: 1234
           SRV: 1
            DS: 1234
         RRSIG: 1234
        DNSKEY: 2
         NSEC3: 1234
    NSEC3PARAM: 1

Regards,
Patrick

RFC 6844

Trying to validate our zones before signing, found one zone which causes multiple reported errors by validns (version 0.7, also the current github master), but is reported as correct by named-checkzone (and bind 9.9.4), as well as by ldns-verify-zone (apart from one bug in that validator). Also the bind loads and serves that zone correctly.

The issue is mainly about parsing labels containing special characters like UTF-8 and spaces. As far as I can tell these are correctly quoted according to RFC 1035 zone file format. The two "name server domain name is not valid" errors are especially weird.

This is the result of running validns on that file, no command line options:

db-test:13: name server domain name is not valid
db-test:14: a dot within a label is not currently supported
db-test:15: name server domain name is not valid
db-test:18: record name is not valid
db-test:19: cannot assume previous name for it is not known
db-test:20: a dot within a label is not currently supported
db-test:21: cannot assume previous name for it is not known
db-test:22: record name is not valid
db-test:23: cannot assume previous name for it is not known
db-test:28: record name expected
db-test:29: record name expected
db-test:30: record name is not valid

And here is the zone file db-test (I hope the 8-bit bytes will be preserved in the following quotation):

$ORIGIN ijs.si.
$TTL 3600
@   86400   IN  SOA niobe.ijs.si. hostmaster.ijs.si. (
              2013110961 28800 3600 2419200 3600 )
            NS  niobe.ijs.si.
niobe                   A       193.2.4.24
niobe                   AAAA    2001:1470:ff80::24
www         A   193.2.4.17
www         AAAA    2001:1470:ff80::80:1
nabiralnik      A   193.2.4.16
nabiralnik      AAAA    2001:1470:ff80::80:16

_http._tcp  PTR 01\ Institut\ \"Jožef\ Stefan\"._http._tcp
        PTR 02\ Koledar\.prireditev._http._tcp
        PTR 03\ WLAN\ @\ IJS,\ Eduroam._http._tcp
        PTR 04\ Web\ access\ to\ IJS\ mailboxes._http._tcp

01\ Institut\ \"Jožef\ Stefan\"._http._tcp SRV 0 0 80 www
        TXT "path=/"
02\ Koledar\.prireditev._http._tcp      SRV 0 0 80 www
        TXT "path=/ijsw/Koledar_prireditev"
03\ WLAN\ @\ IJS,\ Eduroam._http._tcp       SRV 0 0 80 www
        TXT "path=/ijsw/Brez%C5%BEi%C4%8Dno_omre%C5%BEje"
04\ Web\ access\ to\ IJS\ mailboxes._http._tcp  SRV 0 0 80 nabiralnik
        TXT "path=/"

test-lat1   TXT  "ma\241ana en M\252nchen"
"ma\241ana" TXT  "ma\241ana en M\252nchen"
"la manyana"    TXT  "ma\241ana en M\252nchen"
la-mañana  TXT  "ma\241ana en M\252nchen"

It would be nice if the unrecognized directive error gave more information on the directive so it is easier to separate out BIND or other proprietary directives from other errors. For example the $GENERATE option in BIND zone files which can be numerous.

Or maybe this is also something that can be handled with the future lua policy files (having a BIND specific exception file, etc).

https://github.com/tobez/validns/blob/master/main.c#L79

Here is a working brew formula.

Odds of getting into brew official are slim/none even though validns is important and really handy.

Closing, it's done.

validns currently fails to verify the zone if there are any fingerprints with algorithm 4 (Ed25519)

When there is a DS-RR for a domain name, there must also be at least 2 NS-RR. This is a requirement of the german registry DENIC.

Regards,
Patrick

Should be fairly easy to implement. They are described in section 3.1 and 3.2 of RFC7344

It seems that if you specify TTL for the first RR of an RRset, the TTL is not propagated to the rest of the RRset, e.g.:

@       300     MX      0 spg.kirei.se.
                MX      5 spg-ipv4.kirei.se.

results in:

"TTL values differ within an RR set"

Even if you're using algorithm 253 (which is private), I don't think that validns should complain about delegation data such as the quality of the DS records (only if they break really bad). Now validns complains if the DS is using algorithms it doesn't recognize. Maybe this should be configurable?

Currently a ietf draft, but expected to be RFC in a few weeks. https://tools.ietf.org/html/draft-ietf-dane-smime-15

Validns 0.8 reports inconsistencies in the NSEC3 chain regarding mixed hash-alogrithms. Like those two NSEC3 RRs:

nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 I N NSEC3 2 1 16 0947e8799e2a1326 o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
5pi10b6oo32ackimi5entgjkhtasdtru.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 5q1jgrrol77ft0873j0pr9f41r5mtha3 A RRSIG

Unfortunately it does not detect if there is a mismatch of the salt and iterations or the Opt-In / Opt-Out Flag.
Here are some examples for the cases which are not detected:

Opt-In/Opt-Out:
nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 IN NSEC3 1 0 16 0947e8799e2a1326 o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
ljpe46seqcufhqtbho12nd877sgvohlt.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 lm8cmbau3njoq7mhakq35btbohposf1q A RRSIG

Iterations:
nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 IN NSEC3 1 1 17 0947e8799e2a1326 o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
db4dqnt03hg68utinuksrifbirrtm969.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 dbjimap2ouup2nfmh1digdu2fbvkrof5 NS DS RRSIG

Salt:
nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 IN NSEC3 1 1 16 DEADBEEF o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
vq0lr2sjgbblgehekbf6n6bv52fl3mno.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 vvg7t4t2mqchdinbkl7b4ms8ii9l6l35 A RRSIG

The easiest way to check this is to check if each NSEC3-Record matches any NSEC3PARAM.
This implies that all NSEC3 records matching a specific NSEC3PARAM have consistent salt and iterations.

The branch supporting them appears to be simply missing at

The german registry DENIC knows two kind of domains:

1. Domains with nameserver. These domains have at least 2 NS records, pointing to the customers nameserver. They could also have DS-RR and glue records (A, AAAA)
2. Domains without nameserver (called nsentry-domains). The customer could provide a couple of A-, AAAA- and MX-records, which will be written directly into the .de-Zone.

A domain with NS-RR must not have A-, AAAA- or MX-RR (except glue records).

I believe this issue could be pretty DENIC specific, so I'm not sure if this should be officially implement in validns.

Regards,
Patrick

There are certain constraints on the format of the tag values, which validns currently ignores.

When using the Best Current Practice RFC 2317 for class-less delegation, the suggested syntax is to use a "/" (slash). For example:

0/25 NS ns.A.domain.
0/25 NS some.other.name.server.
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.

validns breaks when validating the signed zone. Some of the reported errors:

1.0/25.2.0.192.in-addr.arpa. 86400 IN CNAME 1.0/25.2.0.192.in-addr.arpa.
-> cname is not valid

0.2.0.192.in-addr.arpa. 1800 IN NSEC 0/25.2.0.192.in-addr.arpa. CNAME RRSIG NSEC
-> next domain is not valid
-> type list expected

0/25.2.0.192.in-addr.arpa. 86400 IN NS ns.A.domain.
-> record name is not valid

Seems like validns does not accept the "/"

RFC 6672 will be published in a few days, replacing RFC 2672, and it insists that only one DNAME is allowed per name. Example of a wrong zone:

sub IN DNAME example.org.
sub IN DNAME example.net.

BIND 9.9.1 refuses to load zones with this error:

23-May-2012 22:39:35.847 dns_master_load: foobar.example:20: sub.foobar.example: multiple RRs of singleton type
23-May-2012 22:39:35.847 zone foobar.example/IN: loading from master file foobar.example failed: multiple RRs of singleton type
23-May-2012 22:39:35.847 zone foobar.example/IN: not loaded due to errors.

But validns (git HEAD of today) accepts:

% ./validns -z foobar.example /tmp/bind/foobar.example
% 

A policy check which could recover the private key would be interesting.

See http://bitcoin.stackexchange.com/questions/35848/recovering-private-key-when-someone-uses-the-same-k-twice-in-ecdsa-signatures

BIND 9.9.6 and newer support CAA records.

It would be cool, if validns supports this RR (https://tools.ietf.org/html/rfc6844).

dnssec-signzone from BIND 9.10.3-P4 or BIND 9.9.8-P4 and earlier have a bug which does not remove unnecessary rrsigs from zone. It is fixed for upcoming releases:

1. [bug] dnssec-signzone was not removing unnecessary rrsigs
   from the zone's apex. [RT #41483]

Specifically, it was fixed on the 28th Jan 2016:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=832ab79d1f8bc4edf638780b306888da30ac3a1e

validns will detect these signatures. e.g.:

validns 8.example.com.signed
8.example.com.signed:47: 8.example.com. RRSIG exists for non-existing type A

Note that both ldns-verify-zone or dnssec-verify ignore these rrsigs:

ldns-verify-zone 8.example.com.signed
Checking: 8.example.com.
Checking: www.8.example.com.
Zone is verified and complete

dnssec-verify -x -o 8.example.com. 8.example.com.signed
Loading zone '8.example.com.' from file '8.example.com.signed'
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 present, 0 revoked

Instead of permanently ignore unnecessary rrsigs I think a policy check for this explicit case is appropriate.

The .se zone has RP records in the zone, with RRSIGS over it. This gives you the following errors:

se.new:6187555: invalid or unsupported rdtype rp
se.new:6187556: class or type expected
se.new:6187557: class or type is not valid

on this data:

a.ns.se. 172800 IN RRSIG RP 5 3 172800 20111112001420 (
20111030010504 33951 se.
BPJxbZ2muS/TtcwJktVNMxXPSqLbzKC7SryPfhIfLZhuY
ihCLQfhnfyRmYbCj1cXqKpX7LH2Hnwp1hkuI19nIS8EWl
oxPt5FrlkHgjzO9I4r/44lKcwzn9dh0OB/I617n8jHDEc
x4KtYrsitbhSH9AFiMAO26TP+aaoKJ6kDWN8= )

dito

Hi,

the implementation of a possibility ( policy ) to check for an existing KSK record and the appropriate RRSIG in the zone. This offers the possibility to verify the validation of the signatures against the whole chain.

This would be a nice feature..

Thanks

greetz

Christian

Should be simple to add I guess.

Hi,

the implementation of a possibility ( policy ) to check for an existing KSK record and the appropriate RRSIG in the zone. This offers the possibility to verify the validation of the signatures against the whole chain.

This would be a nice feature..

Thanks

greetz

Christian

Daniel Stirnimann writes:

I have a question regarding the DNSSEC check "NSEC3 without a
corresponding record (or empty non-terminal)".

My sample zone example.com looks as follow:

$TTL    1d
$INCLUDE Kexample.com.+008+18169.key
$INCLUDE Kexample.com.+008+57699.key
@       IN      SOA     ns.example.com. hostmaster.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

        IN      NS      ns1.example.net.
1.1.1.1.1.1.1.1.1.1.33  IN      NS      ns1.example.net.

I sign the zone with the following command:
dnssec-signzone -t -3 94CD -H 1 example.com

validns (v0.4) gives me ten validation errors for the above mentioned
"empty non-terminal" check.

Why is this considered an error? Empty non-terminals have NSEC3 records.
So where is the problem?

funny how I got to be the one to have http://dlv.isc.org/ support the case when the zone had a dname record, and now, well, I try validns, and kaboom, it does not support dname either :-)

It's kinda like a CNAME, but an automatic one, in this : only the first and the last line really exit, the second one is generated by bind so that an old resolver would understand :

# dig +dnssec +noall +answer a webmail.absolight.info @127.0.0.1
absolight.info.         86400   IN      DNAME   absolight.fr.
absolight.info.         86400   IN      RRSIG   DNAME 7 2 86400 20111121053253 20111114080145 33560 absolight.info. p0wI0qeCigft8q/OAoADieU+FVYoRigembraellIOEFJX+bOLCcPTnTg z7ihA02Kh78ascKum8dA5eSfjN8hV/TNwv3Qi3kDUoJdzeBnxE16vyHZ u3k6sCk241w27RvoUGmuoBcwg1U+UresJrUS+Xfnur8+rUj/OLrmDn3f btI=
webmail.absolight.info. 86400   IN      CNAME   webmail.absolight.fr.
webmail.absolight.fr.   86400   IN      A       193.30.224.134
webmail.absolight.fr.   86400   IN      RRSIG   A 7 3 86400 20111122131429 20111115042533 60623 absolight.fr. cKmZd878iyhHanl4cg6AAzJAdfuQqI5b6DCU1VpYLIWbkGXqo3EE99Ow Ht8RILd5fe991xCff5jK1DrENiC/TdoTlnLODRcfzpM8lT/EpyiqFQLf nOqkRLzA01CDwpnSctKa+7paEGbFIqLzNhRKggcnBaOJXMa9E5wlyhGd cxc=

The codes for the four ILNP records (NID, L64, L32 and LP) have been added to the IANA registry http://www.iana.org/assignments/dns-parameters. The future RFC is in the RFC Editor Queue http://www.rfc-editor.org/internet-drafts/draft-irtf-rrg-ilnp-dns-06.txt

It would be cool to have validns support for them.

I've just written a FreeBSD port skeleton for validns 0.4.
It builds and deletes cleanly on 9.0|8.2|7.4-RELEASE and 10-CURRENT.
https://gist.github.com/2488296

Feel free to tune MAINTAINER and Whom line in the Makefile and submit a PR