HIP record

[Miek Gieben]

Hello,

While playing with the HIP record I wanted to place some test records
in a zone. I used the examples from RFC 5205 (Section 6.).

;; Tests
t IN HIP ( 2 200100107B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )

t IN HIP ( 2 200100107B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
rvs.example.com. )

Checking these with named-checkzone yields:

loading "evilquery.nl" from "evilquery.nl" class "IN"
dns_rdata_fromtext: evilquery.nl:30: near '9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ': label too long
dns_rdata_fromtext: evilquery.nl:35: near '9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ': label too long
zone evilquery.nl/IN: loading from master file evilquery.nl failed: label too long
zone evilquery.nl/IN: not loaded due to errors.

This is with bind9.7.3. I think records are OK and bind should be able to parse
them?

grtz,

--
Miek

[Mark Andrews]

Both records are malformed. Remove the whitespace from the public key.

The Public Key field is represented as the Base64 encoding [RFC4648]
of the public key. The encoding MUST NOT contain whitespace(s) to
distinguish it from the Rendezvous Servers field.

In message <20120219135...@miek.nl>, Miek Gieben writes:
> Hello,
>
> While playing with the HIP record I wanted to place some test records
> in a zone. I used the examples from RFC 5205 (Section 6.).

And you failed to read the note immediately above them.

In the examples below, the public key field containing no whitespace
is wrapped since it does not fit in a single line of this document.

> ;; Tests
> t IN HIP ( 2 200100107B1A74DF365639CC39F1D578
> AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
> 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
> b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )

> =20

> t IN HIP ( 2 200100107B1A74DF365639CC39F1D578
> AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
> 9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
> b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
> rvs.example.com. )
>
> Checking these with named-checkzone yields:
>
> loading "evilquery.nl" from "evilquery.nl" class "IN"

> dns_rdata_fromtext: evilquery.nl:30: near '9+LrV4e19WzK00+CI6zBCQTdtWsu=
> xKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ': label too long
> dns_rdata_fromtext: evilquery.nl:35: near '9+LrV4e19WzK00+CI6zBCQTdtWsu=
> xKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ': label too long
> zone evilquery.nl/IN: loading from master file evilquery.nl failed: lab=

> el too long
> zone evilquery.nl/IN: not loaded due to errors.
>

> This is with bind9.7.3. I think records are OK and bind should be able to p=
> arse
> them?
>
> grtz,
>
> --
> Miek
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Miek Gieben]

[ Quoting <ma...@isc.org> at 07:09 on Feb 20 in "Re: HIP record..." ]

> Both records are malformed. Remove the whitespace from the public key.
>
> The Public Key field is represented as the Base64 encoding [RFC4648]
> of the public key. The encoding MUST NOT contain whitespace(s) to
> distinguish it from the Rendezvous Servers field.
>

> And you failed to read the note immediately above them.
>
> In the examples below, the public key field containing no whitespace
> is wrapped since it does not fit in a single line of this document.

Thanks for your reply.

But I have another query then. Is there a difference between:

blah ( bla1
bla2
)

and:

blah ( bla1
bla2
)

In other words: is the space significant in the second example?

grtz Miek

[Miek Gieben]

[Mark Andrews]

In message <20120219202...@miek.nl>, Miek Gieben writes:
> [ Quoting <ma...@isc.org> at 07:09 on Feb 20 in "Re: HIP record..." ]
> > Both records are malformed. Remove the whitespace from the public key.

> >=20

> > The Public Key field is represented as the Base64 encoding [RFC4648]
> > of the public key. The encoding MUST NOT contain whitespace(s) to
> > distinguish it from the Rendezvous Servers field.

> >=20

> > And you failed to read the note immediately above them.

> >=20

> > In the examples below, the public key field containing no whitespace
> > is wrapped since it does not fit in a single line of this document.
>
> Thanks for your reply.
>
> But I have another query then. Is there a difference between:
>
> blah ( bla1
> bla2
> )
>
> and:
>
> blah ( bla1
> bla2
> )
>
> In other words: is the space significant in the second example?

no.

> grtz Miek
>
>
> --dDRMvlgZJXvWKvBx
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk9BWfgACgkQJYuFzziA0PajUgCgqJCMu6hyX2ws2UWGowHjuoEu
> RG0AnRAxsW0VGjF8V7L6FKs05GKtU7v7
> =uDBu
> -----END PGP SIGNATURE-----
>
> --dDRMvlgZJXvWKvBx--
>
> --===============4591130730917447427==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============4591130730917447427==--

[Miek Gieben]

[ Quoting <ma...@isc.org> at 07:45 on Feb 20 in "Re: HIP record..." ]

> > But I have another query then. Is there a difference between:
> >
> > blah ( bla1
> > bla2
> > )
> >
> > and:
> >
> > blah ( bla1
> > bla2
> > )
> >
> > In other words: is the space significant in the second example?
>
> no.

Ok, that's in line with RFC 1035. But I'm confused now, if that space is
not significant, BIND should be able to correctly parse the HIP record
as emailed before (and not try to recognize it as an ownername) ?

Regards,
Miek Gieben

[Miek Gieben]

[Mark Andrews]

The presence of white space is significant, not whether the whitespace
is "<linebreak>" or "<linebreak> + <space>" or even "<space>". You
asked me if there was any difference between "<linebreak>" or
"<linebreak> + <space>" and there isn't.

And before you ask for named to be made to work with a base64 key
broken up arbitarially how many rendevous servers are there in this
example?

www IN HIP ( 2 200100107B1A74DF365639CC39F1D578

AwEA Abdx yhNu Sutc 5EMz xTs9 LBPC
IkOF H8cI vM4p 9+Lr V4e1 9WzK 00+C
I6zB CQTd tWsu xKbW Iy87 UOoJ TwkU
s7lB u+Up r1gs Nrut 79ry ra+b SRGQ
b1sl ImA8 YVJy uIDs j7kw zG7j nERN
qnWx Z48A Wksk mdHa VDP4 Bcel rTI3

rMXd XF5D QWER rSv1 RsV2 )

The examples can not be cut-and-pasted. They need to have the
public key turned into a single string first.

Mark

[Miek Gieben]

[ Quoting <ma...@isc.org> at 10:51 on Feb 20 in "Re: HIP record..." ]

> The presence of white space is significant, not whether the whitespace
> is "<linebreak>" or "<linebreak> + <space>" or even "<space>". You
> asked me if there was any difference between "<linebreak>" or
> "<linebreak> + <space>" and there isn't.

Where is this specified? The closest I can find is 1035, but it
only says:

( ) Parentheses are used to group data that crosses a line
boundary. In effect, line terminations are not
recognized within parentheses.

Regards,
Miek Gieben