In DNS there are many types of record, and one of the new ones is a DNAME.

It is a non-terminal substitution of one point in the DNS for another. Unlike CNAME which only relates to the specific record and not any below it.

As an example, we have a DNAME for aaisp.net.uk pointing to aa.net.uk

The principle is simple: anything.aaisp.net.uk is mapped to anything.aa.net.uk.

The name server serves the DNAME record, allowing a modern resolver to remember this mapping and not ask for other records knowing they are mapped. However the name server also servers a zero TTL transient CNAME mapping the specific entry being looked up. If it then knows that entry too it will return that record.

In theory any older resolver will see the CNAME and following it. A newer one can cache and understand the DNAME. So it should be backwards compatible.

Interestingly we have found a snag. It seems some very old (and I mean very old) linux resolver libraries can't handle the DNAME. Specifically calls like gethostbyname barf at it. The clue is that the problem is logged in syslog. e.g.:-

Feb 15 08:37:26 a asterisk: gethostby*.getanswer: asked for "wasteless.ec.aaisp.net.uk IN A", got type "39"

Sadly there is no easy work around. Well, apart from the mopping up we are doing changing references to aaisp.net.uk to aa.net.uk. Maybe bind can be told to understand a DNAME but not serve it? Maybe it can be made to work out the resolver is old and not serve it. In fact, I think that is meant to be the case.

Anyway, we have cheated for now - pointing aaisp.net.uk at our own servers which now understand DNAME but don't serve it - they just serve the transient CNAME.


No comments:

Post a Comment

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

TOTSCO - the top level - ordering

This should give you some idea of the issues with a simple matter of providing a broadband service. Bear in mind the broadband service may h...