I admit that this thread rolled off my screen before I noticed it. I’m going to pick on a few things said here that extend backwards in the thread a bit.
On 2/22/15, 15:53, "Mark Andrews" <[email protected]> wrote: >master files are ASCII files. Maybe they are supposed to be. But what got my goat recently was trying to parse a zone file that had UTF-8 in it. There are zone master files that are not purely ASCII in the wild. Not saying that it is right. Saying that they deserve to be recognized. I mean, there’s every reason that the file can be put to use. I had considered extending the parser I had to do so, then decided for my use case the effort wasn’t worth it. >If you have a file that contains u-labels it is not as master file. Walks like a duck, talks like a duck, smells like a duck…but yes, according to some dusty old documents - written before u-labels were imagined [by the community producing the documents] - they aren’t. >It can be converted to a master file by processing the labels and >turning them into a-labels. Bingo! >Master files are supposed to be able to be processed by nameservers >that are not IDNA aware. There’s no reason that we can’t add an adjective to "master file.” Then folks writing RFPs, contracts, work orders can specify what is best. If I choose to run antiquated software I’ll ask for antiquated master files. If I choose software that reflect the native language of my staff, I might want master files that have a different formatting. Orthogonal to my desire to document this is the desire to see how far we can get away from assuming everyone has ASCII knowledge. NOCs shouldn’t have to list a particular (human) language as a requirement. >If you use master files extensions such as $TTL, $DATE and $GENERATE >then you need to ensure that the nameserver can process them. A >cannonical version of the master file contains none of these >extensions. I know of name servers that do not read master files at all, so no, you can’t “ensure." >Additionally you need to be aware of what types the nameservers >supports otherwise you should encode all non RFC 1034 records as >unknown types. Unfortunately RFC 103[45] failed to specicify how >to encode unknown types in master files which makes it impossible >to have a master files that contains new types be readable by all >nameservers in existence. I’m well aware of this. RFC 1034/1035 didn’t specify how you’d include write an RRTYPE they didn’t invent, not even the ones in "New DNS RR Definitions” RFC 1183 (October 1990, Experimental - ok, outside of RP non are in use and RP may or may not be). It’s a shame RFC 1034/1035 didn’t cover this (but there were many omissions, so it’s not surprising) but we deal with that. The printed form of unknown record types is no different that the printed form of, say AAAA (in some use [wink], not in RFC 1034/1035). The point is to define a way to print data into a file. And not even “a” way, but have a lowest common denominator and then more useful “adjectives.” It doesn’t matter if parsers today “break” or “fail” to consume a particular format - if that happens, operators can perform “tech refresh” if they need. PS - I want to emphasize that LDH is not a requirement for a domain name. (I think that point was made already.) A label can have only LDH, it can have punydode, it can have arbitrary binary code. Printing a label (as it is seen in a file) isn’t the same as converting a name for registration.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
