[12:32:48] --- dcrocker has joined
[12:49:57] --- jlcjohn has joined
[14:00:59] --- willix has joined
[14:10:12] --- gordonf has joined
[14:25:39] --- dcrocker has left: Replaced by new connection
[14:34:51] --- dcrocker has joined
[14:56:18] --- mrose has joined
[14:56:48] <resnick> Hmmmm.....awfully lonely in here.
[14:56:49] <mrose> sorry, bad traffic on memorial day here.
[14:56:56] <mrose> are we ready to get started?
[14:57:01] <gordonf> Raining in most of WesternCanada too
[14:57:51] <mrose> ok: dave anything to discuss re: csv before we get to wildcards?
[14:58:17] <gordonf> <rts to Dave>
[14:58:34] <mrose> ok, dave's not watching his screen.
[14:58:37] <mrose> let's move on.
[14:58:43] <mrose> it's wildcard time.
[14:58:48] <mrose> usual protocol in effect. begin.
[14:59:07] <gordonf> <rts>
[14:59:34] <mrose> gordonf - go
[14:59:39] <gordonf> While I haven't had a chance to read, what little I'm reading is suggesting changing some core semantics of how DNS implementations handle wildcards.
[15:00:04] * dcrocker now screen-watching
[15:00:18] <gordonf> I haven't yet read how they will handled - has there been discussion prior other than what's onthe list ? <eot>
[15:00:58] <mrose> pete - can you summarize this?
[15:01:25] * resnick tries to formulate...
[15:01:40] <gordonf> <rts - to clarify the question>
[15:02:15] <willix> rts
[15:02:22] <mrose> all - given the small number of people on today, let's discard the queuing protocol. i'll leave it to folks good judgement not to step on each other
[15:02:27] <resnick> (Let others go for a bit.)
[15:02:50] <gordonf> I've just read a lot of, well, religious howling but little else.
[15:02:55] --- resnick has left: Disconnected
[15:02:58] --- resnick has joined
[15:03:12] <dcrocker> gordon - huh?
[15:03:42] <gordonf> "You can't do this, it'll break that, " etc
[15:04:11] <willix> I asked Paul Vixie if its possible to extend wildcards to handle name.* on zone boundary. He said it maybe possible but will take several years and unlikely to help in our immediateproblems
[15:04:34] <gordonf> Several years? Did he explain why?
[15:05:03] <dcrocker> changing infrastructure takes a long time. dns core services are infrastructure.
[15:05:26] <resnick> I'm not even clear how name.*.domain would work.
[15:05:56] <willix> I thought it may something that needs to be changed in dns servers. But the way dns operators do it is that these changes will require RFC standartization and going through WG consensus and then several more years until dns servers are changed
[15:06:04] <willix> He said 5 years
[15:06:19] <dcrocker> he was being _extremely_ optimiatic.
[15:06:24] <gordonf> For our purposes that doesn't seem practical or workable.
[15:06:33] <resnick> Wouldn't a server be required to walk up the tree looking for matches? Would "joe.stupid.example.com" match if there was a * in example.com?
[15:06:42] <dcrocker> (optimiatic -> optimistic)
[15:07:16] <resnick> Either way, allowing name.* seems like a non-starter.
[15:07:29] <gordonf> I played a lot with wildcards when writing DMP and eventually decided they wouldn't be required. Too many potential problems down a given DNS zone.
[15:07:51] <resnick> Gordon: That there were problems != not required.
[15:08:23] <gordonf> It was a matter of - make the spec work without them and places could use them if they wanted.
[15:09:02] <gordonf> And I also believe "name.*" is a non-starter.
[15:09:36] <resnick> So, let me give an example:
[15:10:06] <resnick> QUALCOMM, for assorted reasons, has all of it's machines with names of "<name>.qualcomm.com"
[15:10:33] <resnick> I can imagine that they would have a bunch of different MARID statements for a bunch of hosts,
[15:10:46] <resnick> but they wouldn't want to type in one for each and every one of them.
[15:10:59] <resnick> There are going to be a bunch that are all the same.
[15:11:09] <resnick> They'd want to put in "*.qualcomm.com" for all of those.
[15:11:20] <gordonf> I remember this
[15:11:39] <resnick> Are we saying that (a) that can't be done, or (b) we'll come up with some way that still works without the *?
[15:12:04] <jlcjohn> How about, "It's a really bad idea." ?
[15:12:06] <gordonf> OK, I attempted this once actually, and I can verify my results in a couple of seconds if I can.
[15:12:29] <resnick> jlc: Why a bad idea? Seems logical to me.
[15:12:59] <resnick> Especially if the wildard says, "Don't accept mail from me"
[15:13:19] <gordonf> The results were... given *.pan-am.ca [any] [value], I could query someunknownhost.pan-am.ca for [any] and get [value]...
[15:13:47] <gordonf> ...however, if www.pan-am.ca existed or mail.pan-am.ca existed, if I queried www.pan-am.ca or mail.pan-am.ca for [any] I'd get NXDOMAIN.
[15:14:07] <gordonf> I verified this on WIn2K DNS, NT4 DNS and BIND 9.
[15:14:11] <willix> I though about doing things with ANY. The problem is that ANY will cause only actively cached records to be returned if its caching name server
[15:14:31] <gordonf> I'monly using "[any]" as a particular record type, such as MX, TXT, A or hypothetically, MARID.
[15:14:49] <gordonf> Regardless of the type I was querying.
[15:15:08] <gordonf> I shoud;ve been mroe clear.
[15:15:36] <gordonf> Ultimately, if a node up the DNS tree is defined, it overrides the wildcard.
[15:16:02] <gordonf> er, should I say "down?"
[15:16:51] <willix> Too many queries would be required to work down the tree in full.
[15:17:46] <resnick> jlc: Still waiting for why it would be a bad idea.
[15:17:56] <gordonf> You'd have to define a MARID record for each node in the zone if you wanted that. Which could be done automatically with DDNS and a smart MARID client, but a little crazy in my opinion.
[15:18:19] <jlcjohn> OK, Pete: It's a bad idea because it's so tempting to say things like
[15:18:31] <jlcjohn> don't accept email from any of these.
[15:18:43] <gordonf> I came up with a workaround which I'll explain when jlcjohn's finished.
[15:19:02] <jlcjohn> It's better to try to do things like that with perl modules.
[15:19:21] <jlcjohn> which, at least, do exactly what you program them to do <eot>
[15:19:48] <gordonf> <rts?>
[15:20:19] <jlcjohn> Go Gordon!
[15:20:31] * resnick tries to figure out what jlc meant by "doing it with perl modules"
[15:21:00] * dcrocker <rts>
[15:21:01] <gordonf> Thanks - the workaround was to define a placeholder record - for each domain that handles mail and wants to publish MARID records, have some kind of record that says so.
[15:21:39] <gordonf> In DMP I called it @ IN TXT "dmp=" which was just a null record that says "this domain has DMP records." could something similar be done for us?
[15:21:43] <gordonf> ,eot>
[15:22:21] <dcrocker> I'd like to step back for a minutes and do some sanity-checking.
[15:22:29] <dcrocker> The dns is the dns. There is a difference between
[15:22:38] <dcrocker> adding a new use for an existing record, versus
[15:22:42] <dcrocker> adding a new record, versus
[15:23:03] <dcrocker> changing existing DNS protocol semantics. Each gets progressively deeper and more difficult.
[15:23:35] <dcrocker> It feels as if people are mixing things to the level of saying that having underlying DNS semantics be adapted for this particular application is what we should do. It is difficult
[15:23:46] <dcrocker> to imagine such changes being successful. <eot>
[15:24:21] <resnick> Dave: In this case, you're talking about tree walking when you refer to changed semantics?
[15:24:51] <dcrocker> that's an example. i'm sensing an underlying problem with the entire approach to discussing DNS issues such as tree walking. /
[15:24:59] <gordonf> I don't want to require changes to DNS semantics, and I would rather avoid sites changing DNS software at all. We're trying to change e-mail only.
[15:25:24] <resnick> Gordon: What dave is saying is that by entering a record
[15:25:35] <resnick> that means something other than "this node here", you've
[15:25:38] <resnick> changed semantics.
[15:25:54] <gordonf> Understood
[15:26:01] <gordonf> I want to avoid that too.
[15:26:07] <willix> I'm curious why we don't want to it by specifying that _marid is preferred location for these records but that for wildcard use the record would have to be placed directly in zone with *
[15:26:22] <dcrocker> _a._b.*.example.com is another example of changing underlying dns semantics.
[15:27:05] <resnick> So far we have no takers for _a._b.*.example.com, as far as I know.
[15:27:27] <dcrocker> ok
[15:27:44] <dcrocker> do we have an agenda?
[15:28:22] <mrose> agenda for today?
[15:28:31] <gordonf> Pete: Would an "intelligent" implementation, that added MARID-type records for each name in qualcomm.com, for example, serve a similar purpose as a wildcard for *.qualcomm.com but without using the wildcard or changing DNS semantics?
[15:28:38] <dcrocker> yes. what are we trying to resolve today?
[15:28:48] <mrose> today's agenda is all about the MX stuff
[15:29:15] <gordonf> I think I brought this up before ad it was shot down for some reason, but I forget what.
[15:29:27] <resnick> Gordon: implementation of a DNS server?
[15:29:46] <gordonf> Implementation of MARID, using DDNS to add records for each existing node.
[15:30:03] <resnick> So DDNS would be required for MARID?
[15:30:07] <gordonf> I'm thinking of the MARID implementation as being a DNS client.
[15:30:24] <gordonf> Recommended I'm thinking, required? That might be asking for a lot, I don't know for certain.
[15:30:40] <gordonf> Is DDNS common enough to do so?
[15:31:38] <willix> DDNS = Dynamic DNS?
[15:31:40] * resnick contemplates how DDNS is part of a *client* implementation...
[15:32:06] <resnick> I don't get it.
[15:32:29] <gordonf> Can an application submit records to a DDNS server to be added to a zone? Like when a machine boots up and registers itself with DDNS?
[15:33:22] <resnick> Ah.....that. Think of very tiny snowballs on a very hot day in Hades if you think QUALCOMM's going to allow that on their DNS servers.
[15:33:41] <gordonf> Security issue?
[15:33:51] <dcrocker> and reliability and culture and ...
[15:34:02] <resnick> and management and.....
[15:34:08] <resnick> Yeah, ain't gonna fly.
[15:34:20] <jlcjohn> I'd rather think in terms of keeping DNS _records_ simple, and running some script (perhaps under cron) to generate them.
[15:34:28] <gordonf> I don't know - it won't fly because of social and management issues - are there technical issues preventing such a thing?
[15:34:50] <dcrocker> yes. we do not know how to design technology that is insensitive to social and management issues.
[15:35:06] <gordonf> Let's be serious - Active Directory works on this very idea - a DC registers all kinds of records automatically with DNS.
[15:35:08] <resnick> Gordon: It would be a big operational change, which seems like something of which we want to stay out of the business.
[15:35:40] <gordonf> No bigger than changing DNS semantics to allow name.*.example.com?
[15:35:52] <dcrocker> reality check: getting dns operators to add new types of information -- even in existing RR types -- is a big deal. each thing
[15:35:55] <resnick> jlc: You're kidding, right? We've got a perfectly sane mechanism like a single wildcard entry, and you want me to put in a cron job to generate thousands of records?
[15:36:10] <dcrocker> we ask them to do differently beyond that creates an essentially
[15:36:11] <jlcjohn> resnick: yes.
[15:36:22] <dcrocker> insurmountable barrier to adoption for the marid effort.
[15:36:55] <jlcjohn> actually, I'd like to discourage folks from _wanting_ wildcards...
[15:37:20] <gordonf> I'm thinking DDNS servers already do this - it's why I could tun Active Directory with BIND 9 servers instead of MS DNS servers. We're not changing DNS servers or semantics by dynamically adding MARID records, just taking advantage of existing functionality.
[15:37:23] <dcrocker> jlc - and you want to put that bit of dns culture change effort into the critical path of marid?
[15:38:18] <jlcjohn> Certainly, I don't want to put _anything_ in the critical path!
[15:38:46] <jlcjohn> but, almost anything is better than trying to change "bind" semantics.
[15:39:11] <resnick> jlc: So you're assuming that the only choice here is _marid.*.foo.bar?
[15:39:13] <willix> Question - what happens when we have normal TXT (or any other type) of record and wildcard record in the same zone?
[15:39:26] <gordonf> Example?
[15:40:25] <jlcjohn> willix: it's confusing -- most people get it wrong when they try to explain.
[15:41:20] <resnick> You can't have a wildcard TYPE, as far as I know. You have a wildcard NAME.
[15:41:30] <jlcjohn> yes
[15:41:57] <resnick> will: does that answer your question?
[15:41:59] <willix> If we have *.name TXT ..." and "name TXT .." then you should presumably only see "name", right?
[15:42:27] <jlcjohn> depends on the query...
[15:42:42] <willix> QTYPE=TXT
[15:42:58] <jlcjohn> I meant the NAME in the query.
[15:42:58] <willix> QNAME="name"
[15:43:12] <jlcjohn> yes, in that case, you never see *.name
[15:43:32] <gordonf> If you query QNAME="foobar.name" then you see *.name, right?
[15:43:47] <jlcjohn> unless something else matches
[15:44:09] <resnick> You don't "see the wildcard". It matches that entry and you get back that answer.
[15:44:20] <gordonf> right, that goes back to an older problem - how to prevent spoofing a sub-node.
[15:44:45] <gordonf> Without changing DNS semantics that is
[15:46:03] <willix> The reason I asked is if we allow "*.domain. TXT" for cases where it needs to cover *.domain. and in the future somebody
[15:46:34] <willix> wants to add different kind of TXT record just for "domain." for different application, it may screw up marid
[15:46:43] <jlcjohn> yes
[15:46:45] <willix> and will require separate TXT record directly for domain
[15:46:49] <gordonf> willx: There's a workaround for that
[15:47:26] <gordonf> Can you have more than one TXT record at a given node? My DNS server seems to think I can.
[15:47:38] <jlcjohn> yes
[15:48:06] <willix> You can have more then one txt record. Its not a problem for multiple applications to add different TXT records, but it leads to subtyping
[15:48:22] <gordonf> Assuming for a moment we use TXT to hold MARID info (just assume for a moment.. bear with me)...
[15:48:47] <mrose> let's wrap in 10 mins
[15:49:07] <gordonf> query fecyk.ca for TXT right now if you'd please
[15:49:27] <willix> In case any application has previously used wildcard txt record for that domain, it'll have to be replicated too directly for domain, this maybe confusing for dns administrators and for prorgrams designed to do it
[15:50:24] <jlcjohn> willix: yes, IMHO.
[15:50:38] <jlcjohn> Understand, DNS must return _all_ TXT records for "foobar.name", or announce failure.
[15:51:09] <gordonf> that's OK john, and the DNS client has to parse all returned records, right?
[15:51:29] <jlcjohn> at least enough to figure out which to use...
[15:51:41] <gordonf> doesn't seem that hard to me.
[15:52:17] <gordonf> That's what RFC 1464 touched on.
[15:52:40] <gordonf> Doesn't have to be TXT records, that's just one example.
[15:53:26] <jlcjohn> Has anyone thought about *.domain CNAME ?
[15:53:37] <willix> Seems that only ok workarounds are to have our own DNS record type or use some kind of SRV-like record that supports wildcard and subtyping to specify default location
[15:53:42] <willix> You can't have wildcard CNAMEs
[15:53:47] <gordonf> Aren't CNAMEs subject to the same wildcard semantics?
[15:53:52] <gordonf> If they're permitted at all?
[15:54:46] <willix> See wildcard clarification draft by Ed Lewis
[15:54:54] <gordonf> Meta: it's 16:05 CDT
[15:56:15] <jlcjohn> willix: URL?
[15:57:37] <mrose> right.
[15:57:47] <willix> http://ietfreport.isoc.org/idref/draft-ietf-dnsext-wcard-clarify/
[15:57:51] <mrose> does anyone have anything absolutely pressing?
[15:58:07] <resnick> not i.
[15:58:47] <gordonf> I'd still like to know what the political/social problems are with feeding DDNS servers MARID stuff dynamically.
[15:58:47] <mrose> ok, thanks very much everyone... please continue the discussion on the mailing list...
[15:59:24] <willix> I wanted to get an idea what people though of NAPTR records and putting URLs instead of URNs there
[15:59:29] <resnick> gordon: I'll try in e-mail. Remind me if you don't hear from me.
[15:59:38] <gordonf> OK pete, thanks.
[16:00:12] <gordonf> If it's a stupid idea I want to know why so I can avoid it next time.
[16:00:33] --- DouglasOtis has joined
[16:00:57] --- resnick has left
[16:01:22] --- mrose has left
[16:01:32] --- gordonf has left
[16:07:03] --- dcrocker has left
[16:12:40] --- willix has left
[16:22:03] --- dcrocker has joined
[16:25:41] --- DouglasOtis has left