#djbdns — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #djbdns, aggregated by home.social.
-
Internal changes to redo that you will only see if building from source are that it now uses itself to build, re-building only the parts of itself that have changed rather than explicitly re-building the whole of itself unconditionally every time.
This has meant creating a minimal 'bootstrap' #redo, with just 3 command-line options.
But it has enabled switching the manual sources to the more expressive DocBook XML like they are in #djbdns and #nosh, nicking their default.1.do programs.
-
Internal changes to redo that you will only see if building from source are that it now uses itself to build, re-building only the parts of itself that have changed rather than explicitly re-building the whole of itself unconditionally every time.
This has meant creating a minimal 'bootstrap' #redo, with just 3 command-line options.
But it has enabled switching the manual sources to the more expressive DocBook XML like they are in #djbdns and #nosh, nicking their default.1.do programs.
-
Internal changes to redo that you will only see if building from source are that it now uses itself to build, re-building only the parts of itself that have changed rather than explicitly re-building the whole of itself unconditionally every time.
This has meant creating a minimal 'bootstrap' #redo, with just 3 command-line options.
But it has enabled switching the manual sources to the more expressive DocBook XML like they are in #djbdns and #nosh, nicking their default.1.do programs.
-
Internal changes to redo that you will only see if building from source are that it now uses itself to build, re-building only the parts of itself that have changed rather than explicitly re-building the whole of itself unconditionally every time.
This has meant creating a minimal 'bootstrap' #redo, with just 3 command-line options.
But it has enabled switching the manual sources to the more expressive DocBook XML like they are in #djbdns and #nosh, nicking their default.1.do programs.
-
Internal changes to redo that you will only see if building from source are that it now uses itself to build, re-building only the parts of itself that have changed rather than explicitly re-building the whole of itself unconditionally every time.
This has meant creating a minimal 'bootstrap' #redo, with just 3 command-line options.
But it has enabled switching the manual sources to the more expressive DocBook XML like they are in #djbdns and #nosh, nicking their default.1.do programs.
-
Because I'm a DNS implementor too.
The main people to have adopted that are the people who were already doing things its way.
Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.
Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.
I was pointing this out when it was still a draft.
https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J
-
Because I'm a DNS implementor too.
The main people to have adopted that are the people who were already doing things its way.
Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.
Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.
I was pointing this out when it was still a draft.
https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J
-
Because I'm a DNS implementor too.
The main people to have adopted that are the people who were already doing things its way.
Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.
Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.
I was pointing this out when it was still a draft.
https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J
-
Because I'm a DNS implementor too.
The main people to have adopted that are the people who were already doing things its way.
Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.
Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.
I was pointing this out when it was still a draft.
https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J
-
Because I'm a DNS implementor too.
The main people to have adopted that are the people who were already doing things its way.
Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.
Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.
I was pointing this out when it was still a draft.
https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J
-
Sugar for AAAA records was done in 2025 by me. Felix von Leitner did it differently 25 years earlier, but I didn't like that it required two parallel toolsets and sets of record types. My way, it's just an IPv6 address in the same '+' records.
That's been available for a *long* time.
-
Sugar for AAAA records was done in 2025 by me. Felix von Leitner did it differently 25 years earlier, but I didn't like that it required two parallel toolsets and sets of record types. My way, it's just an IPv6 address in the same '+' records.
That's been available for a *long* time.
-
Sugar for AAAA records was done in 2025 by me. Felix von Leitner did it differently 25 years earlier, but I didn't like that it required two parallel toolsets and sets of record types. My way, it's just an IPv6 address in the same '+' records.
That's been available for a *long* time.
-
Sugar for AAAA records was done in 2025 by me. Felix von Leitner did it differently 25 years earlier, but I didn't like that it required two parallel toolsets and sets of record types. My way, it's just an IPv6 address in the same '+' records.
That's been available for a *long* time.
-
Sugar for AAAA records was done in 2025 by me. Felix von Leitner did it differently 25 years earlier, but I didn't like that it required two parallel toolsets and sets of record types. My way, it's just an IPv6 address in the same '+' records.
That's been available for a *long* time.
-
That rather depends from the claim that something that was deliberately designed, and is documented as working that way, even *is* a bug. Bernstein did design to make things less suprisingly odd than 'zone' files.
Because this was and is unintuitive. I was one of the people who sometimes explained to users that there were implied interior nodes that stopped wildcards from working. As well as the other ways that BIND wildcarding didn't work like MaraDNS, Microsoft DNS, and #djbdns.
-
That rather depends from the claim that something that was deliberately designed, and is documented as working that way, even *is* a bug. Bernstein did design to make things less suprisingly odd than 'zone' files.
Because this was and is unintuitive. I was one of the people who sometimes explained to users that there were implied interior nodes that stopped wildcards from working. As well as the other ways that BIND wildcarding didn't work like MaraDNS, Microsoft DNS, and #djbdns.
-
That rather depends from the claim that something that was deliberately designed, and is documented as working that way, even *is* a bug. Bernstein did design to make things less suprisingly odd than 'zone' files.
Because this was and is unintuitive. I was one of the people who sometimes explained to users that there were implied interior nodes that stopped wildcards from working. As well as the other ways that BIND wildcarding didn't work like MaraDNS, Microsoft DNS, and #djbdns.
-
That rather depends from the claim that something that was deliberately designed, and is documented as working that way, even *is* a bug. Bernstein did design to make things less suprisingly odd than 'zone' files.
Because this was and is unintuitive. I was one of the people who sometimes explained to users that there were implied interior nodes that stopped wildcards from working. As well as the other ways that BIND wildcarding didn't work like MaraDNS, Microsoft DNS, and #djbdns.
-
That rather depends from the claim that something that was deliberately designed, and is documented as working that way, even *is* a bug. Bernstein did design to make things less suprisingly odd than 'zone' files.
Because this was and is unintuitive. I was one of the people who sometimes explained to users that there were implied interior nodes that stopped wildcards from working. As well as the other ways that BIND wildcarding didn't work like MaraDNS, Microsoft DNS, and #djbdns.
-
Anyway, who the Hell is this community that thinks that the original #djbdns is the be-all and end-all?
Let me know, and I'll show them #djbwares, where I've got a whole long list of things that have been improved, from IPv6 support through a non-hexdump way of doing SRV records to not letting ANY queries be amplification attack puppets.
-
Anyway, who the Hell is this community that thinks that the original #djbdns is the be-all and end-all?
Let me know, and I'll show them #djbwares, where I've got a whole long list of things that have been improved, from IPv6 support through a non-hexdump way of doing SRV records to not letting ANY queries be amplification attack puppets.
-
Anyway, who the Hell is this community that thinks that the original #djbdns is the be-all and end-all?
Let me know, and I'll show them #djbwares, where I've got a whole long list of things that have been improved, from IPv6 support through a non-hexdump way of doing SRV records to not letting ANY queries be amplification attack puppets.
-
Anyway, who the Hell is this community that thinks that the original #djbdns is the be-all and end-all?
Let me know, and I'll show them #djbwares, where I've got a whole long list of things that have been improved, from IPv6 support through a non-hexdump way of doing SRV records to not letting ANY queries be amplification attack puppets.
-
Anyway, who the Hell is this community that thinks that the original #djbdns is the be-all and end-all?
Let me know, and I'll show them #djbwares, where I've got a whole long list of things that have been improved, from IPv6 support through a non-hexdump way of doing SRV records to not letting ANY queries be amplification attack puppets.
-
It probably would be possible, but it was genuinely a design decision by Bernstein to make wildcards work that way. There were several mailing list discussions.
https://marc.info/?l=djbdns&m=104636747625737&w=2
In this case, working like #djbdns means taking unmodified cdb files and providing the same responses from those data; which is what your WWW page currently says is the #shibari goal.
If taking unmodified data files and giving non-tinydns behaviour instead is the goal, then that WWW page misleads.
-
It probably would be possible, but it was genuinely a design decision by Bernstein to make wildcards work that way. There were several mailing list discussions.
https://marc.info/?l=djbdns&m=104636747625737&w=2
In this case, working like #djbdns means taking unmodified cdb files and providing the same responses from those data; which is what your WWW page currently says is the #shibari goal.
If taking unmodified data files and giving non-tinydns behaviour instead is the goal, then that WWW page misleads.
-
It probably would be possible, but it was genuinely a design decision by Bernstein to make wildcards work that way. There were several mailing list discussions.
https://marc.info/?l=djbdns&m=104636747625737&w=2
In this case, working like #djbdns means taking unmodified cdb files and providing the same responses from those data; which is what your WWW page currently says is the #shibari goal.
If taking unmodified data files and giving non-tinydns behaviour instead is the goal, then that WWW page misleads.
-
It probably would be possible, but it was genuinely a design decision by Bernstein to make wildcards work that way. There were several mailing list discussions.
https://marc.info/?l=djbdns&m=104636747625737&w=2
In this case, working like #djbdns means taking unmodified cdb files and providing the same responses from those data; which is what your WWW page currently says is the #shibari goal.
If taking unmodified data files and giving non-tinydns behaviour instead is the goal, then that WWW page misleads.
-
It probably would be possible, but it was genuinely a design decision by Bernstein to make wildcards work that way. There were several mailing list discussions.
https://marc.info/?l=djbdns&m=104636747625737&w=2
In this case, working like #djbdns means taking unmodified cdb files and providing the same responses from those data; which is what your WWW page currently says is the #shibari goal.
If taking unmodified data files and giving non-tinydns behaviour instead is the goal, then that WWW page misleads.
-
@JdeBP Real talk: shibari working like #djbdns is not the goal. It has never been the goal. It will never be the goal. And I am getting increasingly annoyed at the djbware community who tends to believe that the original djbware is the be-all end-all of software design. djbware was excellent 30 years ago and is sometimes still serviceable; this does not mean it cannot be improved upon. Pretending otherwise is being in a cult.
In fact, the reason why I wrote shibari was twofold:
- axfrdns is not RFC-compliant, and at some point BIND became more conservative in what it accepted, so one of my secondaries stopped working.
- djbdns does not implement dns-0x20, so at some point some resolvers stopped working and my site became inaccessible.
(Also, of course, IPv6, but this was not the deciding factor.)
Did I try patching djbdns in order to solve my issues? Yes, I did. And it soon became apparent that although the djbdns design is stellar, the code is less than, and finding out where and how to patch it in order to change what I wanted was seriously threatening the few hairs I have left. I found it easier to write an entirely different DNS server from the ground up than to actually patch djbdns. That's how unmaintainable the code is.
So no, shibari's goal isn't to work like djbdns. It is to be a replacement that is, you know, actually compliant with the specifications, because that is what most people expect from their software. And also, a replacement that is actually maintainable and maintained, as proven by the fact that it only took me a few hours to fix the wildcard bug in shibari and make it RFC-compliant, whereas you seem to be saying it would be more or less impossible with djbdns - which I'm fully willing to believe.
-
@JdeBP Real talk: shibari working like #djbdns is not the goal. It has never been the goal. It will never be the goal. And I am getting increasingly annoyed at the djbware community who tends to believe that the original djbware is the be-all end-all of software design. djbware was excellent 30 years ago and is sometimes still serviceable; this does not mean it cannot be improved upon. Pretending otherwise is being in a cult.
In fact, the reason why I wrote shibari was twofold:
- axfrdns is not RFC-compliant, and at some point BIND became more conservative in what it accepted, so one of my secondaries stopped working.
- djbdns does not implement dns-0x20, so at some point some resolvers stopped working and my site became inaccessible.
(Also, of course, IPv6, but this was not the deciding factor.)
Did I try patching djbdns in order to solve my issues? Yes, I did. And it soon became apparent that although the djbdns design is stellar, the code is less than, and finding out where and how to patch it in order to change what I wanted was seriously threatening the few hairs I have left. I found it easier to write an entirely different DNS server from the ground up than to actually patch djbdns. That's how unmaintainable the code is.
So no, shibari's goal isn't to work like djbdns. It is to be a replacement that is, you know, actually compliant with the specifications, because that is what most people expect from their software. And also, a replacement that is actually maintainable and maintained, as proven by the fact that it only took me a few hours to fix the wildcard bug in shibari and make it RFC-compliant, whereas you seem to be saying it would be more or less impossible with djbdns - which I'm fully willing to believe.
-
@JdeBP Real talk: shibari working like #djbdns is not the goal. It has never been the goal. It will never be the goal. And I am getting increasingly annoyed at the djbware community who tends to believe that the original djbware is the be-all end-all of software design. djbware was excellent 30 years ago and is sometimes still serviceable; this does not mean it cannot be improved upon. Pretending otherwise is being in a cult.
In fact, the reason why I wrote shibari was twofold:
- axfrdns is not RFC-compliant, and at some point BIND became more conservative in what it accepted, so one of my secondaries stopped working.
- djbdns does not implement dns-0x20, so at some point some resolvers stopped working and my site became inaccessible.
(Also, of course, IPv6, but this was not the deciding factor.)
Did I try patching djbdns in order to solve my issues? Yes, I did. And it soon became apparent that although the djbdns design is stellar, the code is less than, and finding out where and how to patch it in order to change what I wanted was seriously threatening the few hairs I have left. I found it easier to write an entirely different DNS server from the ground up than to actually patch djbdns. That's how unmaintainable the code is.
So no, shibari's goal isn't to work like djbdns. It is to be a replacement that is, you know, actually compliant with the specifications, because that is what most people expect from their software. And also, a replacement that is actually maintainable and maintained, as proven by the fact that it only took me a few hours to fix the wildcard bug in shibari and make it RFC-compliant, whereas you seem to be saying it would be more or less impossible with djbdns - which I'm fully willing to believe.
-
@JdeBP Real talk: shibari working like #djbdns is not the goal. It has never been the goal. It will never be the goal. And I am getting increasingly annoyed at the djbware community who tends to believe that the original djbware is the be-all end-all of software design. djbware was excellent 30 years ago and is sometimes still serviceable; this does not mean it cannot be improved upon. Pretending otherwise is being in a cult.
In fact, the reason why I wrote shibari was twofold:
- axfrdns is not RFC-compliant, and at some point BIND became more conservative in what it accepted, so one of my secondaries stopped working.
- djbdns does not implement dns-0x20, so at some point some resolvers stopped working and my site became inaccessible.
(Also, of course, IPv6, but this was not the deciding factor.)
Did I try patching djbdns in order to solve my issues? Yes, I did. And it soon became apparent that although the djbdns design is stellar, the code is less than, and finding out where and how to patch it in order to change what I wanted was seriously threatening the few hairs I have left. I found it easier to write an entirely different DNS server from the ground up than to actually patch djbdns. That's how unmaintainable the code is.
So no, shibari's goal isn't to work like djbdns. It is to be a replacement that is, you know, actually compliant with the specifications, because that is what most people expect from their software. And also, a replacement that is actually maintainable and maintained, as proven by the fact that it only took me a few hours to fix the wildcard bug in shibari and make it RFC-compliant, whereas you seem to be saying it would be more or less impossible with djbdns - which I'm fully willing to believe.
-
@JdeBP Real talk: shibari working like #djbdns is not the goal. It has never been the goal. It will never be the goal. And I am getting increasingly annoyed at the djbware community who tends to believe that the original djbware is the be-all end-all of software design. djbware was excellent 30 years ago and is sometimes still serviceable; this does not mean it cannot be improved upon. Pretending otherwise is being in a cult.
In fact, the reason why I wrote shibari was twofold:
- axfrdns is not RFC-compliant, and at some point BIND became more conservative in what it accepted, so one of my secondaries stopped working.
- djbdns does not implement dns-0x20, so at some point some resolvers stopped working and my site became inaccessible.
(Also, of course, IPv6, but this was not the deciding factor.)
Did I try patching djbdns in order to solve my issues? Yes, I did. And it soon became apparent that although the djbdns design is stellar, the code is less than, and finding out where and how to patch it in order to change what I wanted was seriously threatening the few hairs I have left. I found it easier to write an entirely different DNS server from the ground up than to actually patch djbdns. That's how unmaintainable the code is.
So no, shibari's goal isn't to work like djbdns. It is to be a replacement that is, you know, actually compliant with the specifications, because that is what most people expect from their software. And also, a replacement that is actually maintainable and maintained, as proven by the fact that it only took me a few hours to fix the wildcard bug in shibari and make it RFC-compliant, whereas you seem to be saying it would be more or less impossible with djbdns - which I'm fully willing to believe.
-
I hope not, if working like #djbdns is the goal.
RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.
Using the RFC4592 example:
When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .
In the RFC4592 model, the *.example. wildcard does not get applied.
-
I hope not, if working like #djbdns is the goal.
RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.
Using the RFC4592 example:
When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .
In the RFC4592 model, the *.example. wildcard does not get applied.
-
I hope not, if working like #djbdns is the goal.
RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.
Using the RFC4592 example:
When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .
In the RFC4592 model, the *.example. wildcard does not get applied.
-
I hope not, if working like #djbdns is the goal.
RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.
Using the RFC4592 example:
When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .
In the RFC4592 model, the *.example. wildcard does not get applied.
-
I hope not, if working like #djbdns is the goal.
RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.
Using the RFC4592 example:
When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .
In the RFC4592 model, the *.example. wildcard does not get applied.
-
An additional fun factor is that wildcards in #djbdns by design don't work like wildcards in BIND. The difference was much discussed a quarter of a century ago.
So any bug reports that assume that wildcards in djbdns databases are supposed to behave like they do in BIND's 'zone' files need to be checked for proper foundation.
And with RFC 4592 an even greater divergence then happened.
-
An additional fun factor is that wildcards in #djbdns by design don't work like wildcards in BIND. The difference was much discussed a quarter of a century ago.
So any bug reports that assume that wildcards in djbdns databases are supposed to behave like they do in BIND's 'zone' files need to be checked for proper foundation.
And with RFC 4592 an even greater divergence then happened.
-
An additional fun factor is that wildcards in #djbdns by design don't work like wildcards in BIND. The difference was much discussed a quarter of a century ago.
So any bug reports that assume that wildcards in djbdns databases are supposed to behave like they do in BIND's 'zone' files need to be checked for proper foundation.
And with RFC 4592 an even greater divergence then happened.
-
An additional fun factor is that wildcards in #djbdns by design don't work like wildcards in BIND. The difference was much discussed a quarter of a century ago.
So any bug reports that assume that wildcards in djbdns databases are supposed to behave like they do in BIND's 'zone' files need to be checked for proper foundation.
And with RFC 4592 an even greater divergence then happened.
-
An additional fun factor is that wildcards in #djbdns by design don't work like wildcards in BIND. The difference was much discussed a quarter of a century ago.
So any bug reports that assume that wildcards in djbdns databases are supposed to behave like they do in BIND's 'zone' files need to be checked for proper foundation.
And with RFC 4592 an even greater divergence then happened.
-
Missing from @drscriptt 's list are AAAA, HTTPS, and SVCB records.
AAAA has plenty of obvious choices.
You'll know the . convention for SRV, SVCB, and MX resource record sets, of course.
I shall just drop in my personal experience from earlier this year that an accidentally supplied HTTPS resource record can *definitely* break WWW traffic; because browsers in practice do not obey RFC9460 §2.4.2.
#djbdns
#DomainNameSystem
#SplitHorizon
#ReservedSuperDomains #DNS #HTTPS #SVCB -
Missing from @drscriptt 's list are AAAA, HTTPS, and SVCB records.
AAAA has plenty of obvious choices.
You'll know the . convention for SRV, SVCB, and MX resource record sets, of course.
I shall just drop in my personal experience from earlier this year that an accidentally supplied HTTPS resource record can *definitely* break WWW traffic; because browsers in practice do not obey RFC9460 §2.4.2.
#djbdns
#DomainNameSystem
#SplitHorizon
#ReservedSuperDomains #DNS #HTTPS #SVCB -
Missing from @drscriptt 's list are AAAA, HTTPS, and SVCB records.
AAAA has plenty of obvious choices.
You'll know the . convention for SRV, SVCB, and MX resource record sets, of course.
I shall just drop in my personal experience from earlier this year that an accidentally supplied HTTPS resource record can *definitely* break WWW traffic; because browsers in practice do not obey RFC9460 §2.4.2.
#djbdns
#DomainNameSystem
#SplitHorizon
#ReservedSuperDomains #DNS #HTTPS #SVCB -
Missing from @drscriptt 's list are AAAA, HTTPS, and SVCB records.
AAAA has plenty of obvious choices.
You'll know the . convention for SRV, SVCB, and MX resource record sets, of course.
I shall just drop in my personal experience from earlier this year that an accidentally supplied HTTPS resource record can *definitely* break WWW traffic; because browsers in practice do not obey RFC9460 §2.4.2.
#djbdns
#DomainNameSystem
#SplitHorizon
#ReservedSuperDomains #DNS #HTTPS #SVCB -
There are actually quite a few, nowadays. See RFCs 6762, 7686, and 8375.
example. is not the worst choice, although you could have gone with test. or internal. or intranet. .
Given your objective, any of the further ones that imply a residence or a corporation seem less well suited.
Although home.arpa.'s public delegation to the blackhole-{1,2}.iana.org. names is re-used.
https://github.com/jdebp/nosh/blob/trunk/source/examples/tinydns/split-horizon#L96
#djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS
-
There are actually quite a few, nowadays. See RFCs 6762, 7686, and 8375.
example. is not the worst choice, although you could have gone with test. or internal. or intranet. .
Given your objective, any of the further ones that imply a residence or a corporation seem less well suited.
Although home.arpa.'s public delegation to the blackhole-{1,2}.iana.org. names is re-used.
https://github.com/jdebp/nosh/blob/trunk/source/examples/tinydns/split-horizon#L96
#djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS
-
There are actually quite a few, nowadays. See RFCs 6762, 7686, and 8375.
example. is not the worst choice, although you could have gone with test. or internal. or intranet. .
Given your objective, any of the further ones that imply a residence or a corporation seem less well suited.
Although home.arpa.'s public delegation to the blackhole-{1,2}.iana.org. names is re-used.
https://github.com/jdebp/nosh/blob/trunk/source/examples/tinydns/split-horizon#L96
#djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS
-
There are actually quite a few, nowadays. See RFCs 6762, 7686, and 8375.
example. is not the worst choice, although you could have gone with test. or internal. or intranet. .
Given your objective, any of the further ones that imply a residence or a corporation seem less well suited.
Although home.arpa.'s public delegation to the blackhole-{1,2}.iana.org. names is re-used.
https://github.com/jdebp/nosh/blob/trunk/source/examples/tinydns/split-horizon#L96
#djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS
-
There are actually quite a few, nowadays. See RFCs 6762, 7686, and 8375.
example. is not the worst choice, although you could have gone with test. or internal. or intranet. .
Given your objective, any of the further ones that imply a residence or a corporation seem less well suited.
Although home.arpa.'s public delegation to the blackhole-{1,2}.iana.org. names is re-used.
https://github.com/jdebp/nosh/blob/trunk/source/examples/tinydns/split-horizon#L96
#djbdns #DomainNameSystem #SplitHorizon #ReservedSuperDomains #DNS
-
Scanning for publicly-reachable proxy DNS servers is old-hat. I've been warning people about such since the turn of the century, and #tinydns is never going to be vulnerable in that way.
The more interesting attack, not least because Bernstein got it right all along, is the people that send queries with huge EDNS0 buffer sizes, asking for ANY against fsf.org (which is nearly 5KiB of response) and direct the responses at the tram port of some victim's router.
-
Scanning for publicly-reachable proxy DNS servers is old-hat. I've been warning people about such since the turn of the century, and #tinydns is never going to be vulnerable in that way.
The more interesting attack, not least because Bernstein got it right all along, is the people that send queries with huge EDNS0 buffer sizes, asking for ANY against fsf.org (which is nearly 5KiB of response) and direct the responses at the tram port of some victim's router.
-
Scanning for publicly-reachable proxy DNS servers is old-hat. I've been warning people about such since the turn of the century, and #tinydns is never going to be vulnerable in that way.
The more interesting attack, not least because Bernstein got it right all along, is the people that send queries with huge EDNS0 buffer sizes, asking for ANY against fsf.org (which is nearly 5KiB of response) and direct the responses at the tram port of some victim's router.