lantins / dns-zone

A Ruby library for building and parsing DNS zone files.
MIT License
22 stars 13 forks source link

Update domainname regex to work with relative names #5

Closed mrideout closed 9 years ago

mrideout commented 9 years ago

This example zone file:

$ORIGIN . mattrideout.com MX 10 mail.mattrideout.com

Was previously being incorrectly parsed as:

mattrideout.com. MX 10 mail.mattrideout.

This update prevents "com" in the exchange from being stripped off.

lantins commented 9 years ago

Hi @mrideout

The existing behaviour is correct, your zone has not parsed correctly, because the zone is incorrect.

Given your example:

$ORIGIN .
mattrideout.com MX 10 mail.mattrideout.com

For the MX record, both the label mattrideout.com and the exchange mail.mattrideout.com do not end with a dot, meaning they are relative.

Relative names need to be expanded, using the $ORIGIN, or if no $ORIGIN is set, using the zone name itself.

$ORIGIN . (with just a single dot) is not valid for your zone, its considered 'out of zone' data, as such it cannot be used to expand your relative names.

Please see RFC 1035 for more details.

The 'correct' way to write your zone would be as follows (ignoring SOA and NS records), using absolute names:

mattrideout.com. MX 10 mail.mattrideout.com.

Or using an $ORIGIN and relative names:

$ORIGIN mattrideout.com.
@ MX 10 mail

It's entirely possible your DNS software or provider is accepting the zone as is, and are 'fixing' it for you, its also possible this is how they export the zone, but if it is, its not standards compliant.

Luke

mrideout commented 9 years ago

@lantins Thanks for the follow up. It's not clear to me from RFC 1035 whether having an $ORIGIN of "." is valid, but BIND does throw "'out of zone' data" errors with that $ORIGIN set, so I think you're correct.

This came up while importing data from a system that's using pseudo zone files where no $ORIGIN is set, and all domains are intended to be absolute, but aren't actually terminated with a dot.

I'll add the missing dots before parsing the data with dns-zone.

Matt

lantins commented 9 years ago

Hey Matt,

You are right, I couldn't find anything to directly prohibit your example either, I guess its implied by the absolute/relative naming and . (dot) on its own being the root of the DNS hierarchy?

Hope the import goes (or has gone) well :)

Luke

lantins commented 9 years ago

For my own reference: